ver/abrir - Repositório do Departamento de Ciência da Computação

Transcrição

Universidade de Brası́lia
Instituto de Ciências Exatas
Departamento de Ciência da Computação
I-Locate: Sistema de monitoramento e
localização de usuários no HUB utilizando a
tecnologia RFID
Ilmar Ferreira Marques
Monografia apresentada como requisito parcial
para conclusão do Curso de Computação – Licenciatura
Orientadora
Prof a.̄ Dr a.̄ Carla Denise Castanho
Brası́lia
2008
Universidade de Brası́lia – UnB
Curso de Computação – Licenciatura
Coordenador: Prof. Dr. Flá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.̄ Célia Ghedini Ralha – CIC/UnB
CIP – Catalogação Internacional na Publicação
Marques, Ilmar Ferreira.
I-Locate: Sistema de monitoramento e localização de usuários no HUB
utilizando a tecnologia RFID / Ilmar Ferreira Marques. Brası́lia : UnB,
2008.
110 p. : il. ; 29,5 cm.
Monografia (Graduação) – Universidade de Brası́lia, Brası́lia, 2008.
1. Identificação por rádio frequência, 2. auto-identificação,
3. sistema de localização, 4. RFID
CDU 004
Endereço:
Campus Universitário Darcy Ribeiro – Asa Norte
CEP 70910–900
Brası́lia – DF – Brasil
I-Locate: Sistema de monitoramento e
localização de usuários no HUB utilizando a
tecnologia RFID
Ilmar Ferreira Marques
Monografia apresentada como requisito parcial
para conclusão do Curso de Computação – Licenciatura
Prof a.̄ Dr a.̄ Carla Denise Castanho (Orientadora)
CIC/UnB
Prof. Dr. Ricardo Pezzuol Jacobi
CIC/UnB
Prof a.̄ Dr a.̄ Célia Ghedini Ralha
CIC/UnB
Prof. Dr. Flávio Leonardo Cavalcanti de Moura
Coordenador do Curso de Computação – Licenciatura
Brası́lia, 17 de Dezembro de 2008
Agradecimentos
Primeiramente agradeço a Deus pela força e saúde que me constituem. À
minha orientadora Carla Denise Castanho por me ajudar a consolidar este trabalho de graduação de maneira a reconhecer seu o empenho na minha orientação.
Agradeço ainda à minha famı́lia e meus amigos por entenderem a distância
e isolamento consequente da realização deste trabalho. Por último, e não menos
importante, agradeço a todos pela força e otimismo quando nas horas mais difı́ceis
e árduas que se passaram na implementação deste projeto.
Resumo
A importância do controle de acesso de pessoas em um ambiente hospitalar
se torna fundamental quando se leva em consideração o papel do mesmo, que é a
prestação de serviços na área de saúde com qualidade, eficiência e eficácia. Com
isso, é relevante assegurar a finalidade do serviço hospitalar através do controle das
pessoas que nele transitam, isto é, o controle do acesso fı́sico às suas dependências.
Com mesma importância, certificar-se de que cada um dos usuários e colaboradores transitantes, entre pacientes, médicos, visitantes e funcionários estão nas
dependências fı́sicas autorizadas requer monitoração constante da movimentação
dos mesmos pela equipe de segurança do hospital. Essa equipe é responsável pelo
zelo do patrimônio hospitalar e age proativamente contra qualquer tipo de adversidade que possa colocar em risco a ordem do estabelecimento. Nesse sentido, há
dificuldades relacionadas à própria atividade de monitoração, caso a mesma seja
realizada contando apenas com agentes de segurança desprovidos de equipamento
e tecnologia para tal finalidade. Uma atividade tı́pica de monitoração de usuários
e colaboradores dentro de um hospital requer a disponibilização de pelo menos
um agente para observá-los. Levando em conta que o número de usuários dentro
de um hospital ultrapassa com facilidade o número de vigilantes, numa condição
ideal de monitoração, seria inviável que todos os usuários fossem monitorados
individualmente.
O presente trabalho propõe um sistema informatizado cujo objetivo é auxiliar
o controle e garantia do acesso de pessoas aos diversos espaços fı́sicos que constituem o Hospital Universitário de Brası́lia (HUB). A solução proposta baseia-se
na utilização da tecnologia de identificação por rádio frequência ou RFID, a qual,
ainda em processo de maturação no Brasil, destaca-se por ser um método de
identificação automatizada que utiliza ondas eletromagnéticas para acessar dados
armazenados em um microchip.
Palavras-chave: Identificação por rádio frequência, auto-identificação, sistema
de localizaçã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
Sumário
Lista de Figuras
9
Lista de Tabelas
11
Capı́tulo 1 Introdução
12
Capı́tulo 2 Análise do problema
2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . .
2.2 O Hospital Universitário de Brası́lia . . . . . . . . . .
2.2.1 Apresentação, estrutura fı́sica e organizacional
2.2.2 Nı́veis de Acesso e Problemas de Segurança .
2.3 Objetivos e Proposta . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
14
14
18
20
Capı́tulo 3 Fundamentação Teórica
3.1 Sistemas de informação . . . . . . . . . . .
3.1.1 Tipos de sistemas de informação . .
3.1.2 Tecnologia da informação . . . . .
3.2 A tecnologia RFID . . . . . . . . . . . . .
3.2.1 A História da RFID . . . . . . . .
3.2.2 A Arquitetura da tecnologia RFID
3.2.3 Padrão EPCGlobal . . . . . . . . .
3.2.4 Redes RFID Distribuı́das . . . . . .
3.2.5 Aplicações da tecnologia RFID . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
22
25
26
26
27
34
37
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Capı́tulo 4 Sistema de controle e monitoração de
4.1 Processos de negócio existentes na instituição .
4.2 Necessidades do sistema . . . . . . . . . . . . .
4.2.1 Introdução . . . . . . . . . . . . . . . . .
4.2.2 Requisitos funcionais . . . . . . . . . . .
4.2.3 Premissas de funcionamento . . . . . . .
4.3 Arquitetura do software . . . . . . . . . . . . .
4.3.1 Módulo do leitor RFID . . . . . . . . . .
4.3.2 Módulo do middleware . . . . . . . . .
4.3.3 Gerador de eventos EPCIS . . . . . . . .
4.3.4 Módulo EPCIS . . . . . . . . . . . . . .
4.3.5 Mó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
Apresentação do software I-Locate . .
4.5.1 Gerenciar acesso a dependências
4.5.2 Gerenciar usuários . . . . . . .
4.5.3 Gerenciar etiquetas . . . . . . .
4.5.4 Administrar usuários do sistema
4.5.5 Administrar sistema . . . . . .
4.5.6 Considerações finais . . . . . . .
. . . .
fı́sicas
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
74
76
78
78
78
88
Capı́tulo 5 Conclusão
5.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
89
Capı́tulo 6 Anexo
91
6.1 Detalhamento da especificação dos casos de uso do sistema I-Locate 91
Referências
109
8
Lista de Figuras
2.1
2.2
2.3
Visão áerea do HUB. . . . . . . . . . . . . . . . . . . . . . . . . .
Visã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 plástico, retirado de [SANTINI, 2006]
Etiqueta em formato de cartão de crédito (Smart Card), retirado
de [SANTINI, 2006] . . . . . . . . . . . . . . . . . . . . . . . . .
Etiqueta RFID embutido no relógio, retirado de [SANTINI, 2006]
Etiqueta RFID afixado em um bracelete, retirado de [SANTINI, 2006]
Exemplo de leitor RFID, retirado de [Himanshu Bhatt, 2005] . . .
Organização ló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 aplicação . . . . . . . . . . . . . . . .
Sistema RFID centrado na rede. . . . . . . . . . . . . . . . . . . .
Arquitetura amontoada. . . . . . . . . . . . . . . . . . . . . . . .
Arquitetura dedicada. . . . . . . . . . . . . . . . . . . . . . . . .
Etiqueta RFID afixada em cadarço de tê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 usuário do tipo
visitante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Diagrama de atividade do cadastro de entrada do usuário do tipo
acompanhante. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Diagrama de atividade do cadastro de entrada do usuário casual. .
4.4 Diagrama de fluxo de dados . . . . . . . . . . . . . . . . . . . . .
4.5 Diagrama do caso de uso do ator “usuário genérico”. . . . . . . .
4.6 Diagrama do caso de uso do ator “gerenciador de etiquetas”. . . .
4.7 Diagrama do caso de uso do ator “funcionário da segurança”. . . .
4.8 Diagrama do caso de uso do ator “supervisor da segurança”. . . .
4.9 Diagrama do caso de uso do ator “suporte técnico do sistema”. . .
4.10 Diagrama do caso de uso do ator “gestor do sistema”. . . . . . . .
4.11 Arquitetura lógica do sistema I-Locate, e a integração dos seus 5
módulos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.12 Visã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 Visão geral da arquitetura do repositório EPCIS, adaptado de
[CUHK, 2008b] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.14 Diagrama de classes do módulo ILOCATEWEB. . . . . . . . . . .
4.15 Diagrama de modelo de dados do I-Locate. . . . . . . . . . . . . .
4.16 Diagrama de implantação do módulo ILOCATE. . . . . . . . . . .
4.17 Tela de login do sistema. . . . . . . . . . . . . . . . . . . . . . . .
4.18 Página inicial do I-Locate. . . . . . . . . . . . . . . . . . . . . . .
4.19 Formulário de inserção de registro de acesso às dependências fı́sicas.
4.20 Opções de monitoração de etiquetas RFID. . . . . . . . . . . . . .
4.21 Monitoração de usuários no espaço nas dependências fı́sicas. . . .
4.22 Formulário para localização de etiquetas. . . . . . . . . . . . . . .
4.23 Resultado para a busca de etiquetas. . . . . . . . . . . . . . . . .
4.24 Formulário para geração de relatórios de ocorrências de monitoração
de etiquetas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.25 Gerenciamento de usuários cadastrados no sistema. . . . . . . . .
4.26 Gerenciamento de etiquetas cadastrados no sistema. . . . . . . . .
4.27 Administração dos usuários do sistema. . . . . . . . . . . . . . . .
4.28 Administração do sistema. . . . . . . . . . . . . . . . . . . . . . .
4.29 Opção Conexões do menu Administrar sistema. . . . . . . . . . .
4.30 Hosts inscritos para recepção de eventos do middleware. . . . . . .
4.31 Especificações de relatórios de eventos. . . . . . . . . . . . . . . .
4.32 Leitores ló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] . . .
Classificação de raios de frequências para dispositivos RFID. Tópico
3.4.1 em [Himanshu Bhatt, 2006]. . . . . . . . . . . . . . . . . . .
Raio máximo de leitura para etiquetas passivas de acordo com a
freqüência. Tópico 3.4.1 em [Himanshu Bhatt, 2006]. . . . . . . .
Classes de etiquetas do padrão EPCGlobal. Tópico 10.4.1.1.1 em
[Himanshu Bhatt, 2005]. . . . . . . . . . . . . . . . . . . . . . . .
Principais caracterı́sticas das arquiteturas de rede RFID, retirado
de [Yi Zhi Zhao, 2007]. . . . . . . . . . . . . . . . . . . . . . . . .
Código eletrônico de produtos: EPC . . . . . . . . . . . . . . . .
42
44
4.1
Acessibilidade das opões do menu principal do I-Locate. . . . . . .
73
3.3
3.4
3.5
24
32
32
35
Capı́tulo 1
Introdução
Garantir a segurança em hospitais significa prover meios de proteção para todos
as pessoas que interagem na execução do serviço de saúde, zelando por áreas
públicas e privadas contra ações diversas que possam afetar tal execução. Em um
hospital as áreas publicas são aquelas onde não há controle de acesso, ou seja,
são de acesso livre e indiscriminado, diferentemente das á áreas privadas, as quais
são tipicamente áreas onde deve prevalecer a fiscalização quanto ao propósito
do usuário no local onde se encontra. De maneira geral, os hospitais formam
uma mescla de áreas com acesso restrito e irrestrito, com equipamentos de alto
custo, e uma diversidade de pessoas, dentre funcionários, pacientes, médicos,
visitantes e colaboradores, movendo-se em seu interior. Tais caracterı́sticas peculiares deste ambiente tornam o aspecto do controle e monitoração de acesso as
suas dependências uma questão de fundamental importância.
Neste contexto, garantir a segurança é função da equipe de segurança interna
do hospital. A esta equipe cabe estabelecer e zelar pela ordem no recinto hospitalar através de ações ativas de segurança. Um hospital que não possa desempenhar,
neste aspecto, seu papel abre possibilidades para a proliferação de ocorrências que
podem afetar a qualidade da execução do serviço hospitalar. Furtos de equipamentos de alto custo, adversidades causadas pelo estado emocional dos pacientes,
e acesso a áreas de risco de contaminação, são alguns exemplos destas ocorrências.
Levando-se em conta que em uma condição real de monitoração do espaço
fı́sico privado deve ser feito aos olhos humanos, diretamente - a olho nu, ou
indiretamente - através de câmeras, a todos os usuários que nela transitam, a
mobilização de um alto grau de recursos da equipe de segurança é realizado. O
motivo é inerente a própria atividade de monitoração e sua execução em estado
ideal custaria caro para a organização.
Neste sentido, aborda-se o ponto acima como motivação da presente monografia no contexto do HUB, que atualmente conta somente com algumas câmeras
de monitoração espalhadas em pontos estratégicos do hospital. A instituição
não dispõe de nenhuma ferramenta informatizada para monitoração e controle
de acesso às suas dependências. O serviço de segurança hospitalar carece de um
sistema informatizado que possa auxiliar na solução deste problema de maneira
eficiente e eficaz.
Diversas tecnologias, como código de barras, biometria, identificação por voz, e
reconhecimento por caracterı́stica ótica (OCR), tem sido amplamente estudadas e
12
utilizadas para auto-identificação de objetos e/ou seres humanos. Entretanto, nos
últimos anos, a tecnologia RFID (Radio-frequency identification), ou identificação
por rádio frequência, tem ganhado espaço nas pesquisas relacionadas a autoidentificação e ao controle de acesso de pessoas a ambientes monitorados. Um
sistema baseado na tecnologia RFID é capaz de identificar uma pessoa ou objeto
com eficiência, podendo também fornecer informações acerca do mesmo a fim de
possibilitar a tomada de decisão com base na localização da pessoa ou objeto
identificado.
O objetivo deste trabalho é propor um sistema informatizado de monitoramento e controle de usuário no HUB utilizando a tecnologia RFID.
Esta monografia está organizada da seguinte forma: O Capı́tulo 2 aborda
o problema atacado por este trabalho no contexto do HUB. No Capı́tulo 3 são
introduzidos os fundamentos teóricos da tecnologia RFID, bem como os elementos
base para a construção de um sistema RFID. No Capı́tulo 4 é 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 além
de indicar alguns trabalhos futuros para continuidade desta pesquisa.
13
Capı́tulo 2
Análise do problema
2.1
Introdução
O controle do fluxo de pessoas em qualquer organização é vital para o seu bom
funcionamento. Desde motivos mais triviais até os mais relevantes, o controle e a
segurança contribuem de forma bastante positiva para que a organização venha
a ter um ótimo desempenho. Isso se intensifica ainda mais em se tratando de um
hospital, já que o atendimento a pessoas é o fator primordial para o sucesso da
organização.
O HUB atualmente carece de um controle eficaz deste processo, conforme
levantamento e estudo apresentado em [Davi Silva, 2006]. O trâmite do controle
de entrada e saı́da de pessoas é prejudicado, fazendo com que o atendimento ao
público reduza sua qualidade, haja vista a importância do controle e monitoração
de acesso nas dependências fı́sicas da organização. Tem-se então, uma situação
com alta sensibilidade já que esse cenário se reflete não só nos pacientes, que
podem ter sua recuperação prejudicada pelo excesso de pessoas, mas também nos
médicos, que tem seus trabalhos interferidos de maneira inesperada e na garantia
de segurança de áreas de acesso selecionado, como por exemplo os laboratórios.
Além disso, problemas de furto de medicamentos e pequenos objetos hospitalares,
alguns de alto valor, tem maior probabilidade de ocorrência caso não seja cedida
a devida atenção ao ponto citado.
É diante deste cenário que o controle de acessos atua. Uma boa administração
neste processo da organização atinge todos os envolvidos nela, desde os médicos
e funcionários, até os pacientes e visitantes.
2.2
2.2.1
O Hospital Universitário de Brası́lia
Apresentaçã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 Pensão
e Aposentadoria dos Servidores do Estado (IPASE). Foi inaugurado, oficialmente,
em agosto de 1972, pelo então Presidente da República, General Emı́lio Garrastazu Médici, recebendo o nome de Hospital dos Servidores da União (HSU). Em
14
1990, foi cedido à 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 Ambulatório e 41.170
metros quadrados de área construı́da. Seu corpo clı́nico é formado por diversos
profissionais da área de saúde: Professores da UnB, servidores do Ministério da
Saúde e profissionais contratados.
Segundo informações [HUB, 2007], seu atendimento ambulatorial é, em média,
de 16.000 consultas, com cerca de 900 internações. O Pronto Socorro realiza,
aproximadamente, 3.500 consultas. No total, o HUB faz 36.000 atendimentos a
cada mês. São feitos cerca de 60.000 exames complementares e 500 intervenções
cirúrgicas/mês.
O HUB, contando atualmente com 33 especialidades médicas, serve à comunidade do Distrito Federal nos nı́veis primário, secundário e terciário, recebendo
ainda pacientes das cidades do entorno de Brası́lia e oriundos de várias outras
unidades da federação.
As figuras 2.1 e 2.2 mostram as fotos do hospital na visão aérea e frontal.
Figura 2.1: Visão aérea do HUB.
Da perspectiva da hierarquia organizacional, o HUB é parte da Universidade
de Brası́lia, portanto fica sujeito às imposiçõ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 decisõ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: Visão frontal do HUB.
conselho deliberativo tem-se a diretoria cuja responsabilidade é de superintender,
coordenar e fiscalizar as atividades do HUB. A Figura 2.3 mostra a organização de
forma hierárquica e as relaçõ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 é formado por trê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 prédio da administração, esses três
centros apresentam problemas mais crı́ticos com relação ao controle de acesso de
pessoas, pois são os que possuem um fluxo maior de público externo. A descrição
do funcionamento destes complexos são feitas abaixo.
Ambulatório
O Ambulatório é o local responsável pelo atendimento clı́nico de pacientes.
Praticamente todas as especialidades da saúde atuam neste complexo, prestando
atendimento aos pacientes que possuam hora marcada. Mensalmente, após o dia
15, são abertas novas vagas para atendimento. O número de vagas para cada área
varia, observando a disponibilidade médica. Sendo assim os pacientes, a partir
deste dia, entram em contato com o setor de informações do Ambulatório que os
encaminha para a marcação de consultas caso haja a disponibilidade requerida
pela pessoa. A marcação também pode ser efetivada pessoalmente, o quê não
garante a existência de vagas.
Devido a essa intermitência, o número de pessoas no complexo varia muito.
A arquitetura do local também dificulta, pois embora apenas duas entradas estejam operando atualmente, o número de corredores e a disposição dos locais
de marcação de consulta não são centralizados em ponto único, sendo que ao
invés disso cada consulta é marcada localizações nas respectivas localizações da
especialidade em questão.
16
Figura 2.3: Estrutura organizacional do HUB.
17
Atualmente não existe controle de acesso neste complexo sendo a entrada para
funcionários, visitantes ou pacientes sempre autorizada.
Anexo I e Anexo II
O Anexo I possui uma grande diversidade de funções. UTI, laboratórios,
centro cirúrgico, e Diretoria de Estudos de Graduação, são alguns exemplos. No
Anexo II a situação não é diferente. Capela, Central telefônica, Fisioterapia e
Odontologia integram alguns dos setores que atuam neste prédio. Diante disso,
constata-se que o interesse das pessoas de entrar nas dependências deste local
varia muito.
O controle atual é centralizado, ou seja, para qualquer um dos Anexos o
acesso deve ser adquirido em um guichê situado no Anexo I. Os nı́veis de acesso
são variados, dependendo da pessoa e do andar que tenta acessar. Um problema
recorrente, por exemplo, é na Odontologia (1o andar Anexo II), onde o acesso
é livre, e na Internação (2o andar Anexo II), onde o acesso é restrito. Muitas
pessoas sobem até a Internação clamando ir para a Odontologia. Isso, sem mencionar os problemas no próprio andar da Odontologia. Lá a exposição de vários
equipamentos pequenos e valiosos ficam a disposição para furto, de modo a trazer
vários prejuı́zos ao hospital.
O controle é totalmente manual, sendo realizado um registro em cadernos e
guias, além do controle dos seguranças, que abrem e fecham a porta de acordo com
a liberação de entrada. A monitoração da regularidade dos usuários que estão
adentro da dependências fı́sicas é realizado pela seguranç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 dependências torna o processo debilitado. De maneira diferente os funcionários não precisam utilizar tais
adesivos pois o trâmite no hospital é restringido pelo crachá ou pelos uniformes
relativos as funções do hospital (Ex.: jaleco).
2.2.2
Nı́veis de acesso e problemas de segurança
Nesta seção são apresentadas, para cada um dos principais prédios do hospital,
as principais deficiências relacionadas ao controle de acesso de pessoas no HUB.
Antes, é preciso destacar duas importantes normas administrativas que dizem
respeito ao número e acesso de visitantes ao hospital:
• Acompanhante e Visitante: Alguns pacientes podem ter uma pessoa os
acompanhando fora do horário de visita. Idosos, crianças e os em situação especial
são os casos que tem direito a acompanhante. Já o visitante só tem autorização
para entrar nos horários determinados para visita;
• Paciente conveniado e Paciente sem convênio: a diferença é o número de
visitantes que cada um pode receber simultaneamente. O conveniado pode receber dois visitantes, e o sem convênio pode receber apenas um. Note que o
acompanhante conta para este limite. No caso de um paciente sem convênio, por
exemplo, no horário de visita, o acompanhante deverá se retirar do hospital para
18
que outra pessoa visite o paciente.
Anexo I
• Térreo e 1o andar: o acesso é restrito. Não há um número limite de pessoas
em cada setor e as atividades efetuadas neste andar são muito variadas. Ali existem salas de exames, laboratórios, refeitórios e lavanderias, setor de faturamento,
internação e alta, além da Diretoria Adjunta de Ensino e Pesquisa. Diante deste
cenário no qual os motivos de acesso são variados percebe-se a dificuldade de se
implementar um controle que garanta que um certo indivı́duo vá para onde se
prontificou a ir no momento da identificação na portaria. O controle acaba recaindo no processo de controle do trâmite interno, por meio dos adesivos entregues
na portaria.
• 2o ,3o e 4o andares: locais de internações. O controle se torna facilitado
já que existe um horário pré-determinado para as visitas (todos os dias - 15hs
às 16hs). Conforme descrito acima, o limite de visitantes por paciente são dois
para os pacientes conveniados, e apenas um para os demais. Nos outros horários
o acesso ao público fica proibido, salvo no caso dos acompanhantes. Pacientes
idosos, crianças e alguns casos especı́ficos tem direito a um acompanhante cada,
ou seja, uma pessoa pode acompanhá-los independente do horário.
Anexo II
• Térreo e 1o andar: o acesso é livre. O problema recorrente é que a Odontologia (1o andar) sofre furtos já que seus equipamentos são pequenos e de fácil
ocultamento.
• 2o andar: local de internações. O número de visitantes também segue os
padrões do Anexo I. Um outro problema apontado neste local é que, como no
1o andar e no térreo o acesso é livre, muitos usuários informam seu destino final
como a odontologia, mas sobem para o 2o andar, onde encontram-se os pacientes
internados. Somente em alguns horários é designado um agente de segurança
para vigiar o acesso ao 2o piso.
• Além dos problemas de segurança do local descritos acima, foi identificado
uma deficiência relacionada ao fluxo de pessoas. Visitantes que se dirigem a certos pontos precisam requerer uma autorização em um guichê do Anexo I, gerando
um deslocamento desnecessário.
Ambulatório
• Térreo: local de consultas previamente agendadas. Aqui o principal problema é a arquitetura e a organização do ambiente. A disposição do local de
marcação de consultas dificulta o estabelecimento de um bom local para a recepção dos pacientes.
Além das questões apresentadas, outros dois fatores fundamentais a serem
considerados para a realização deste projeto são: (1) a necessidade de silêncio
constante na maior parte das dependências do hospital, por razões ó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 regiões onde podem ser
passados fios ou instalados equipamentos no HUB.
2.3
Objetivos e proposta
Com o objetivo de minimizar as questões apresentadas na seção anterior, que comprometem tanto a segurança do hospital, como a qualidade dos serviços prestados, este trabalho propõe um sistema informatizado como ferramenta de apoio à
equipe de segurança HUB. A ferramenta possibilitará a equipe controlar o acesso
de qualquer usuário às dependências do hospital, bem como monitorar a localização dos mesmos. Dessa forma, pretende-se alcançar a realização da atividade
de controle e monitoração de pessoas de forma mais eficiente, sem a demanda de
novos recursos humanos da equipe de segurança.
A ferramenta de software proposta neste trabalho, será baseada na tecnologia
RFID. O sistema será desenvolvido através de técnica de modelagem de dados estruturada, e diagramas de atividades UML para entender os processos de negócios
existentes na área de controle de acesso e monitoração de usuários. Além disso,
serão expostos os requisitos funcionais do sistema juntamente com a proposta
de melhoria para as atividades existentes com a integração da tecnologia RFID.
Além da arquitetura do software serão apresentados a interface final com usuário
e a documentação dos casos de usos pertinentes às funcionalidades oferecidas pelo
sistema.
20
Capı́tulo 3
Fundamentação teórica
3.1
Sistemas de informação
Um sistema de informação (SI) pode ser definido tecnicamente como um conjunto de componentes inter-relacionados que coletam, processam, armazenam e
distribuem informações destinadas à coordenação e ao controle dos processos de
negócio1 de uma organização2 [LAUDON, 2007].
Três atividades em um SI produzem as informações de que as organizações
necessitam para controlar operações, analisar problemas e criar novos produtos
e serviços. Essas atividades são a entrada, o processamento e a saı́da. A entrada envolve a captação ou coleta dos dados, o processamento envolve processos
de transformação que converte insumo a entrada em produto e a saı́da envolve a
transferência da informação processada para o usuá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
São atividades previamente estabelecidas que têm como objectivo determinar a forma como
o trabalho é realizado numa organização. Constituem um conjunto de ações, relacionadas entre
si de forma lógica e coerente a fim de promover um resultado favorável à organização, tanto a
nı́vel interno como externo [LAUDON, 2007].
2
É uma combinação de esforços individuais que tem por finalidade realizar propósitos coletivos. Por meio de uma organização torna-se possı́vel perseguir e alcançar objetivos que
seriam inatingı́veis para uma pessoa. Uma grande empresa ou uma pequena oficina, um laboratório ou o corpo de bombeiros, um hospital ou uma escola são todos exemplos de organizações
[Maximiano, 1995].
21
brutos e transformá-los em informações inteligı́veis, existe uma diferença entre um
computador e um software, de um lado, e um SI, de outro. Os computadores são
ferramentas modernas que permitem aos SIs executar suas finalidades, enquanto
que o SI pode não utilizar-se necessariamente de computadores para a execução
de seus processos [LAUDON, 2007].
3.1.1
Tipos de Sistemas de Informação
Por causa de diferentes interesses, especialidades, e nı́veis na organização, existem
diferentes tipos de sistemas. Nenhum sistema pode prover todas as informações
que uma organização necessita [LAUDON, 2007]. A Figura 3.2 ilustra a maneira
de classificar os tipos de sistemas encontrados em uma organização. Ela demonstra a organização dividida em nı́veis estratégicos, gerenciais, de conhecimento e
operacionais, além de serem subdivididas do ponto de vista funcional nas áreas
de vendas e marketing, fabricação, finanças, contabilidade e recursos humanos.
Figura 3.2: Tipos de SIs, retirado de [LAUDON, 2007]
A seguir têm-se a descrição de cada classificação dos nı́veis de um SI.
• Sistemas de nı́vel operacional: sistemas que suportam os gestores operacionais na definição das atividades elementares e transacionais das organizações, tais como vendas, recepção de encomendas, faturação, aprovisionamento, decisões de crédito e fluxo de materiais. O principal objetivo destes
sistemas é dar resposta a questões de rotina e traçar o fluxo de transações
das organizações.
22
• Sistemas de nı́vel do conhecimento: sistemas que suportam os “trabalhadores do conhecimento”nas organizações. Estes sistemas têm como propósito
ajudarem as organizações a integrarem conhecimento novo no negó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 táctico/gestão: sistemas construı́dos para servirem os
gestores intermédios nas atividades de monitoragem, controle, tomada de
decisão e administrativas. Geralmente disponibilizam relatórios periódicos
em vez de informações sobre as operações do momento. Alguns destes
sistemas suportam tomadas de decisão não rotineiras e tendem a focarse sobre tomadas de decisão não estruturadas para as quais os requisitos
de informação não são claros. Muitas vezes estes sistemas dão resposta a
questões do tipo “e se”que permitem estudar vários cenários. As respostas a
estas questões requerem frequentemente dados novos vindos do exterior das
organizações, bem como dados de dentro da organização, que não podem
ser obtidos a partir dos sistemas de nı́vel operacional.
• Sistemas de nı́vel estratégico: sistemas que ajudam os gestores principais a
encontrar e a definir estratégias de longa duração. Estes têm como principal
objetivo encontrar alterações no ambiente externo das organizações. Estes
sistemas devem ser capazes de dar resposta a questões do tipo: que produtos
podemos/devemos produzir durante os próximos anos? etc. Os sistemas
estratégicos geralmente diferem dos não estratégicos em muitos atributos:
benefı́cios difı́ceis de avaliar; podem levar a poderosas mudanças internas;
podem transformar drasticamente os padrões de trabalho; são usualmente
caros, em termos de custos de oportunidades e riscos; têm por objetivo
proporcionar vantagens competitivas sustentadas; e pouca experiê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
Função
Gestão
de
vendas,
pesquisa de mercado,
promoção, definição de
preços, novos produtos.
Fabricação e produção
Estabelecimento
de
metas
de
produção,
compras,
expedição,
recepção,
engenharia,
operações.
Controle de estoques
Orçamento, livro-caixa,
cobrança, contabilidade
de custos.
Recursos humanos
Registros de pessoal,
benefı́cios, remuneração,
relações
trabalhistas,
treinamento.
Aplicação
Sistemas de acompanhamento de pedidos, sistema de pesquisa de mercado, sistema de estabelecimento de preç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,
orçamento, sistemas de
gestão financeira.
Folha de pagamentos,
registros de funcioná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 informação
Entende-se como a tecnologia da informação (TI), o hardware e o software usado para adquirir, transmitir, processar e disseminar informação, bem como sistemas de gerenciamento de banco de dados e tecnologias de comunicação de dados
[GORDON, 2006].
O hardware de computador refere-se ao equipamento utilizado no processamento eletrônico das informações. Hoje em dia, computadores de mesa e computadores portáteis podem exceder em desempenho os enormes computadores de
um milhão de dólares de dez anos atrás.
• O hardware de entrada captura dados no seu formato bruto, primário, e
informaçõ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 rápido às informações.
• O hardware de saı́da fornece cópias dos dados em papel, microfilmes, e telas
de vı́deo.
O software de computador fornece as instruções, na forma de código de computador, e sua documentação correspondente, para processar eletronicamente os
dados.
• O software de sistemas dirige o funcionamento do hardware.
• O software de aplicação atua na aquisição, processamento, armazenamento,
recuperação e comunicação da informação.
• Ferramentas de desenvolvimento de software facilitam a construção e modificação do software para melhor responder às necessidades de informação
de uma organização.
Os sistemas de gerenciamento de banco de dados oferecem veı́culos para armazenar e dar suporte ao processamento de grandes quantidades de informações
de negó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 informação das mais variadas formas.
As tecnologias de comunicação de dados, especificamente as redes das empresas e a Internet, uma rede de redes de alcance mundial, aperfeiçoaram dramaticamente a comunicação das informações entre pequenas e grandes distâncias,
tornando-se um fator importante na TI [GORDON, 2006].
Em se tratando do avanço da TI, esta torna-se uma tecnologia para grande
amparo de um SI, pois possibilita o eficiente monitoramento e manipulação de
dados. É possı́vel não só reduzir o gasto de papel, canetas, tinta de impressão,
mas além da economia financeira, a possibilidade da economia de tempo e esforço relacionados às atividades de manipulação de dados de um SI. Como exemplo, pode-se citar a implementação dos processos de identificação de pessoas
25
no para o controle de acesso no hospital através do registro manuscrito em atas
pelos agentes de segurança. O mesmo controle pode ser feito utilizando-se os
sistemas computacionais, o que garantiria a consistência dos dados de entrada e
saı́da deste processo, alé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 dependências fı́sicas que a mesma está autorizado a
transitar.
3.2
A Tecnologia RFID
A tecnologia RFID oferece benefı́cios para os tipos de problemas que precisam
identificar a localização de itens fı́sicos. Ela utiliza ondas de rádio para identificação automática, reconhecendo desde itens inanimados até seres humanos.
Com isso, pode-se incluir identificação para os itens fı́sicos, atribuindo para cada
objeto uma identificação única, assemelhando-se assim aos códigos de barra que
existem hoje para individualização de itens de um supermercado. A maneira de
atribuir informação aos objetos é 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 rádio, fazendo com que as mesmas enviem na
forma de onda modularizada a identificação única da etiqueta. Os receptores de
tais ondas modularizadas, denominados de leitores RFID, decodificam os dados
recebidos gerando a informação de presença de etiquetas no campo de ação dos
mesmos e logo após tornam o evento disponı́vel para interpretação de um sistema
computacional onde será associada as informações ao portador da etiqueta com
o respectivo identificador captado. Logo, RFID é um meio para identificação
automatizada em que uma informação é, unicamente relacionada com o objeto
fı́sico e está inclusa na mesma classe de tecnologias de Auto-ID, como o código
de barras, biometria (identificação por digitais, retina), identificação por voz, e
sistemas de reconhecimento ótico de letras (OCR).
3.2.1
A História da RFID
A história da tecnologia RFID pode ser descrita segundo as indicações em
[RfiIdJournal, 2007]. Como diversas das invenções hoje comuns no cotidiano,
nasceu para fins militares. Se hoje há tanta sofisticação na comunicação por
rádio frequência, boa parte é devida ao fı́sico escocês responsável pela invenção,
em 1935, dos sistemas de RADAR (Radio Detection And Ranging ) britânicos
durante a segunda guerra mundial. Na mesma época, foi desenvolvido o primeiro
sistema ativo de identificação. Seu funcionamento era bem simples, pois em
cada avião britânico foi colocado um transmissor que, quando recebia sinais das
estações de radar no solo, transmitia um sinal de volta para identificar se o avião
aliado.
Entretanto, a história da tecnologia RFID propriamente dita, começa em 1973,
quando Mario W. Cardullo requisitou a primeira patente americana para um
sistema ativo de RFID com memória regravável. No mesmo ano, Charles Walton,
um empreendedor da Califórnia, recebeu a patente para um sistema passivo, o
26
qual era usado para destravar uma porta sem a ajuda de chaves.
Na década de 70, o governo americano també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.
Até então, as etiquetas usadas eram as de baixa freqüência (LF - Low Frequency), ou seja 125 kHz, até que as empresas que comercializavam estes sistemas mudaram para os sistemas de alta freqüência (HF - Low Frequency), de
13.56 MHz, o qual seu uso era irregular e incomum em várias partes do mundo.
Hoje, estes sistemas são usados em diversas aplicações, como controle de acesso,
sistemas de pagamento e dispositivos de anti-roubo de carros.
No começo dos anos 80, a IBM patenteou os sistemas de Freqüência Ultra Alta
(UHF - Ultra High Frequency), possibilitando o uso da RFID para realizar leituras
a distâncias superiores a dez metros. Hoje, a IBM não é mais detentora desta
patente, que foi vendida, devido a problemas financeiros ainda na década de 90,
para a Intermec, uma empresa provedora de códigos de barra. O grande crescimento da tecnologia RFID na frequê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,
berço de vários avanços tecnológicos.
Os professores David Brock e Sanjay Sarma do Auto-ID Center foram os
grandes responsáveis em difundir a tecnologia RFID entre as grandes empresas.
Inicialmente as etiquetas RFID apenas informavam a identificaçã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
informaçõ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, além do Departamento de Defesa dos Estados Unidos. Nesta mesma
época foram abertos laboratórios em vários outros paı́ses, que desenvolveram dois
protocolos de interface aérea (Classe 1 e Classe 0), o Código Eletrônico de Produto
(EPC - Eletronic Product Code), o qual determina um esquema de numeração
única de etiquetas RFID, e arquitetura de rede para a associação de RFID na
Internet. Em 2003 o Auto-ID Center fechou, repassando suas responsabilidades
para o Auto-ID Labs.
Em 2004, a instituição EPCglobal ratificou uma segunda geração de padrões,
melhorando o caminho para amplas adoções da tecnologia RFID.
3.2.2
A Arquitetura da Tecnologia RFID
A arquitetura de identificação por rádio freqüência consiste em leitores e etiquetas. O leitor faz uma requisição para a etiqueta, obtém a informação, e então
executa uma ação baseada naquela informação, como indicado no tópico 2.3.1 em
[Himanshu Bhatt, 2006]. Esta ação, no contexto do SI que a utiliza, desencadeia
27
uma série de eventos em aplicativos que gerenciam tais informações. Nas seções
que se seguem, serão abordados os principais componentes da tecnologia RFID,
tais como etiquetas e leitores.
3.2.2.1
Etiquetas
As etiquetas de RFID estão em uma classe de dispositivos de rádio definidos
como transponders. Um transponder é uma combinação entre um transmissor
e um receptor, o qual é responsável por receber um sinal especı́fico de rádio e
automaticamente transmitir uma resposta. Uma simples implementação de um
transponder ouve passivamente os sinais de rádio e, de maneira automatizada,
responde ao perceber a presenç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 transmissão. Além disso, um sistema avançado de
transponder pode realizar cálculos ou até um processo de verificação, que incluem
rádio transmissão encriptada, a qual evita que pessoas não autorizadas obtenham
a informação a ser transmitida.
Os transponders utilizados em dispositivos RFID podem ser referidos como
etiquetas, chips, ou rótulos. De maneira geral, uma etiqueta de RFID pode conter
os seguintes itens:
•
•
•
•
•
Circuito de codificação e decodificação;
Memória;
Antena;
Fonte de alimentação;
Controle de comunicação;
Ainda assim elas se dividem em três categorias: ativas, passivas e semipassivas, que serão detalhadas a seguir.
Etiquetas Passivas
Etiquetas RFID passivas não contém baterias ou outra fonte de alimentação
ativa e por esta razão elas precisam esperar por um sinal emitido a partir de um
leitor RFID. A etiqueta contém um circuito sensı́vel capaz de absorver energia
da antena do leitor. Para tanto a etiqueta passiva utiliza a propriedade eletromagnética conhecida como “campo próximo”. Como o próprio nome sugere, o
dispositivo (etiqueta) deve estar relativamente perto do leitor para ser ativado. O
campo próximo então supre, por curto tempo, energia suficiente para a etiqueta
passiva ser capaz de enviar uma resposta.
Etiquetas Ativas
Em contraposição à ideia de recurso de alimentação, as etiquetas RFID ativas têm seus próprios meios de alimentação, isto é, não necessitam de serem
alimentadas por um campo próximo gerado pela antena do leitor, podendo por
consequência transmitir e receber dados a maiores distâncias do que as etiquetas
28
passivas.
Etiquetas Semi-passivas
As etiquetas semi-passivas possuem bateria para alimentar o seu circuito de
memória, porém utilizam o campo próximo para alimentar o circuito de rádio no
momento da transmissão e recepção de dados.
Propriedades das Etiquetas RFID
A proposta de uma etiqueta RFID é essencialmente vincular uma informação
a um objeto fı́sico. Para isso, cada etiqueta tem um mecanismo interno para
armazenar dados e uma maneira de transmiti-los. Além da divisão das etiquetas
em ativas, passivas, e semi-passivas, realiza-se também a classificação quanto aos
seguintes aspectos: caracterı́sticas fı́sicas, interface aé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 botões ou discos em PVC ou plástico.
• Etiquetas em formato de cartões de crédito.
• Etiquetas em formato de camadas de papel, também conhecidos como
“rótulos inteligentes”, similar àqueles utilizados pelos có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 aérea
A interface aérea descreve a maneira como a etiqueta se comunica com o leitor.
Sabendo-se a interface aérea da etiqueta, pode-se determinar o raio de leitura e
identificar os leitores compatı́veis com ela. Nos tópicos “Frequência de operação”e
“Capacidade armazenamento”são descritos os principais atributos que compreendem a definição de interface aérea.
Frequência de operação
Frequência de operação é a frequência eletromagnética utilizada pela etiqueta
para se comunicar ou obter energia. Considerando que o sistema de RFID não
deve interferir em transmissões próximas de rádio e televisão, serviços móveis de
rádio (polı́cia, serviços de segurança, indústria), serviços de rádio da marinha e
aeronáutica, nem telefones móveis, utilizam-se, em geral, frequências que foram
29
Figura 3.3: Etiquetas RFID diversas, retirado de [Himanshu Bhatt, 2006]
Figura 3.4: Etiquetas RFID afixadas em plástico, retirado de [SANTINI, 2006]
30
Figura 3.5: Etiqueta em formato de cartão de crédito (Smart Card ), retirado de
[SANTINI, 2006]
Figura 3.6: Etiqueta RFID embutido no relógio, retirado de [SANTINI, 2006]
Figura 3.7: Etiqueta RFID afixado em um bracelete, retirado de [SANTINI, 2006]
31
reservadas especificamente para aplicações industriais, cientı́ficas ou médicas como
como frequência de operação das etiquetas RFID. Tais frequências são conhecidas
como faixa de freqüência ISM (Industrial-Scientific-Medical). As tabelas 3.2 e 3.3,
sumarizam as faixas de frequências, bem como suas caracterı́sticas e aplicações
tı́picas.
Nome
LF
HF
Raio de frequência
30300kHz
330M Hz
UHF
300M Hz − 3GHz
Microondas
> 3GHz
Frequê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: Classificação de raios de frequências para dispositivos RFID. Tópico
3.4.1 em [Himanshu Bhatt, 2006].
O raio da leitura em função das frequências é mostrado na Tabela 3.2.
Nome
LF
Raio de leitura
50 centı́metros
HF
3 metros
UHF
9 metros
Microondas
> 10 metros
Aplicação
Identificação de animais
e leitura a curta distância
Controle de acesso
a dependências fı́sicas.
Identificação de
caixas e paletes.
Identificação de veı́culos.
Tabela 3.3: Raio máximo de leitura para etiquetas passivas de acordo com a
freqüência. Tópico 3.4.1 em [Himanshu Bhatt, 2006].
Capacidade de armazenamento
A capacidade de armazenamento também varia de acordo com o tipo de microchip. Algumas etiquetas, mais simples, podem armazenar somente 1 bit, e
são utilizadas, por exemplo, em bibliotecas para verificação da situação dos livros
que saem de seus recintos. Outras podem armazenar uma quantidade maior de
dados, que pode chegar a até 256 kilobytes, como indicado no tópico 3.5 em
[Himanshu Bhatt, 2006].
3.2.2.2
Leitor
O segundo componente básico de um sistema RFID é chamado de leitor ou interrogador.
Eles funcionam como transmissores e receptores de sinais de rádio frequência.
Estes sinais são espalhados por radiofusão, e são recebidos e transmitidos pelas
32
Figura 3.8: Exemplo de leitor RFID, retirado de [Himanshu Bhatt, 2005]
antenas que são conectadas aos leitores. Através de uma unidade de controle, eles
processam as informações/dados enviados e recebidos por radiofusão e, se preciso,
os transmitem por canais de comunicação, via conexão de rede, serial ou USB,
para os middlewares, que são softwares cuja função é desempenhar o papel de
gerência de eventos, detecção, leitura e escrita das etiquetas RFID (Figura 3.9) .
Figura 3.9: Organização lógica de um leitor, adaptado de [Himanshu Bhatt, 2006]
3.2.2.3
Middleware
Middleware é 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 aplicação cliente, e atua como um elemento
encapsulador da interface dos dispositivos leitores de etiquetas. Além disso, ele
atua como um filtro de informação, evitando a sobrecarga desnecessária de processamento de informações ao sistema RFID. Não é necessário enviar informações
duplicadas acerca de uma etiqueta RFID, bem como alertar a aplicação cliente
todo o momento que uma etiqueta estiver no raio de leitura dos interrogadores.
A Figura 3.10 demonstra a visão lógica da arquitetura de um middleware para
sistemas RFID:
Um middleware para um sistema RFID é composto por três módulos:
• Interface em nı́vel de aplicação: Interface responsável por prover serviços
comuns às aplicaçõ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 informações, evitando sobrecarga de dados no sistema;
• Adaptador do leitor : Camada de adaptação de serviços aos leitores. Esta
camada é responsável por encapsular as interfaces proprietárias dos diferentes
leitores RFID em uma interface padrão. Com isso, evita-se que os desenvolvedores das aplicações cliente tenham que aprender o funcionamento das diferentes
interfaces dos leitores RFID disponı́veis no mercado.
3.2.3
Padrão EPCGlobal
A EPCGlobal, Inc. é uma organização sem fins lucrativos criada para controlar, desenvolver e promover padrões baseados na tecnologia RFID. Seu objetivo
é orientar a adoção deste sistema como o padrão mundial para a identificação
imediata, automá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 especificações e podem ser implementadas por qualquer linguagem de programação, desde que implemente os serviços
definidos nas especificações. Os componentes definidos pela EPCGlobal são:
• Número EPC: Identificador global e único, utilizado para acessar os dados
na rede EPC.
• Etiqueta EPC: É composta de um componente eletrônico (microchip) que
tem o seu número de identificação gravado e um transmissor conectado a
uma antena. As etiquetas podem ser confeccionadas em todos os tamanhos
e formatos, com espessura tão fina que permite a aplicação na superfı́cie dos
produtos. Algumas têm a capacidade adicional de registrar novos dados.
• Leitor de Radiofrequência: Emite ondas magnéticas que aciona a etiqueta
RFID, permitindo que transmita de volta a informação armazenada no
micro-chip. Decodifica, verifica, armazena os dados e se comunica com
o computador.
• Savant: Também chamado de EPC middleware, recebe o código pelo leitor,
pergunta ao ONS onde encontrar informação sobre um produto, e então
34
busca os dados na rede, conforme definido pelo ONS.
• Serviço de Nomeação de Objeto (ONS): Bastante semelhante ao Serviço de
Nome de Domı́nio (DNS) da Internet. O serviço ONS traduz números EPC
para endereços da Internet. Isso faz com que as consultas de informações
baseadas em número EPC sejam remetidas para os bancos de dados que
contenham as informações solicitadas.
• EPCIS: SI que mantém todos os dados EPC com regras de acesso, controle,
autorização e autenticação. O PML (Physical Markup Language), é o vocabulário definido em XML, que permite a consulta e a obtenção de dados
relativos aos números EPC.
Nos tópicos a seguir são esclarecidos os componentes definidos pela EPCGlobal, com exceção do leitor e middleware, esclarecidos nas seções 3.2.2.2 e
3.2.2.3 respectivamente.
Etiquetas do padrão EPCGlobal
A EPCGlobal classifica as etiquetas RFID de acordo com as funcionalidades
estipuladas, o protocolo de comunicação utilizado e a forma de alimentação das
etiquetas. As etiquetas de acordo com este padrão têm a intenção de carregar
identificadores únicos chamados de EPC, os quais são definidos por entidades
especı́ficas, que possuem as classes de objetos fı́sicos envolvidos. A Tabela 3.4
mostra as diferentes classificações das etiquetas reconhecidas pela ECPGlobal:
Classe
Classe
Classe
Classe
Classe
0
1
2
3
Classe 4
Classe 5
Descrição
Passivas, somente leitura.
Passivas, somente leitura e escrita somente única vez.
Passivas, de leitura e gravação.
Regraváveis, de leitura e gravação com fonte própria de
energia.
Todas funcionalidades da classe 3 somadas a capacidade
de comunicação de maneira ativa com leitores e outras
etiquetas ativas.
Todas funcionalidades da classe 4 somadas a capacidade
de comunicação com etiquetas passivas. Conceitualmente leitores.
Tabela 3.4: Classes de etiquetas do padrão EPCGlobal. Tópico 10.4.1.1.1 em
[Himanshu Bhatt, 2005].
Código eletrônico de produtos - EPC
O EPC foi criado pelo Auto-Id Center como o eventual sucessor do código de
barras. É o identificador único de uma etiqueta, podendo ser comumente constituı́do de um número de 64 ou 96 bits. Ele se divide nas seguintes partições:
35
•
•
•
•
Cabeçalho - descritor do formato do EPC;
Código do gerenciador do EPC;
Classe de objeto
Número de série
As primeiras duas propriedades são definidas pela EPCGlobal e as últimas
duas pela entidade que gerencia a etiqueta RFID.
Linguagem de marcação fı́sica - PML(Physical Markup Language)
O PML é uma coleção de vocabulários XML padronizados para representar e
distribuir informações a objetos relacionados em sistemas de auto-identificação.
Ela é dividida em dois módulos:
• PML Core: Fornece um formato padronizado para troca de dados capturados em sistemas de auto-identificação baseados no EPC. Ela fornece um
formato padrão para troca de dados que são capturados por sensores, como
leitores de RFID, dentro de uma arquitetura de auto-identificação, fazendo
com que mensagens baseadas no esquema PML Core possam ser trocadas
entre sistemas em uma rede EPC. Informaçõ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 último evento registrado de um item são exemplos dos
dados disponı́veis neste módulo.
• PML Extensions: A PML Extensions fornece extensões especificas que
ofereçam suporte as gerenciadoras da etiqueta RFID. Informações de qual
a dimensão, o peso, qualidade ou cor do objeto portador da etiqueta são
exemplos de informações providos por este módulo.
Serviços de informação de EPC
EPCIS (Serviços de informação de EPC) são serviços que utilizam vocabulários
XML padronizados para trocar informações acerca de eventos ou da descrição
fı́sica dos objetos com o EPC correspondente. São referenciados também como
PML Servers ou PML Services. As principais funções do EPCIS são:
• Representar um repositório que garanta a manutenção a longo prazo da
informação recolhida pelos middlewares.
• Permitir acesso a informação que possa ser derivada dos eventos recolhidos
pelos middlewares com outra informaçã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 criação da etiqueta).
Serviço de nomeação de objetos
36
ONS, serviço de nomeação de objetos, fornece um serviço de busca para
traduzir um EPC em uma ou várias URLs (Uniform Resource Locator ),
assemelhando-se ao DNS (Domain Name System), onde maiores informações sobre o objeto correspondente a etiqueta RFID podem ser encontradas. Os passos
a seguir exemplificam este procedimento:
1. Uma sequência de bits contendo um EPC é lida de uma etiqueta RFID:
0100000000000000000001000000000000011000000000000000000110010000
2. O leitor então transmite a mensagem, através do middleware, para um
servidor destinado a converter a sequência de bits em URI (identificador uniforme
de recursos);
3. Depois de convertida a sequência de bits em um URI, este servidor envia
um a requisição ao servidor ONS local a seguinte resolução: urn:epc:1.2.24.400;
4. O servidor ONS converte a URI em identificador de domı́nio e então passa
ao DNS a requisição: 24.2.1.unb.br;
5. A rede DNS pesquisa e retorna URL que indica a informação sobre o
servidor de EPCIS correspondente;
6. O servidor local ONS obté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 através da URL
para o EPC em questão;
3.2.4
Redes RFID Distribuı́das
Os leitores RFID originalmente são vistos como periféricos que normalmente são
conectados a um computador host através de uma porta serial dedicada para
responder a um pedido. Este tipo de configuração é conhecido como centrada
na aplicação (Figura 3.11). Embora esta seja uma abordagem simples de leitores
em conexão com o sistema oferecendo as funcionalidades adequadas, a forma
de conexão envolve um modesto número de leitores para executar uma função
especı́fica direcionada as regras de negócio.
Para acomodar implementações de serviços RFID em larga escala, uma nova
geração de leitores foi desenvolvido. Estes dispositivos de rede possuem suporte
TCP/IP e são conectadas através redes cabeadas (Ethernet ) ou sem fio (802.11).
Uma rede de leitores que captura os dados necessários para aplicações cliente
RFID, aplicação A e aplicação B por exemplo, através dos middlewares , os quais
localizam-se entre os leitores, são definidos como uma rede RFID. Este tipo de
configuração de rede é dita ser como centrada na rede, Figura 3.12.
Na concepção de uma rede RFID, várias questões que devem ser consideradas
afim de satisfazer as necessidades da cobertura de interrogatórios das etiquetas
e no compartilhamento das informações dos eventos gerados por estes para as
aplicações cliente. Segue-se na próxima seção os elementos que devem ser relevados quando na concepção de redes RFID distribuı́das.
3.2.4.1
Elementos da concepção de redes RFID distribuı́das
Redes Dedicadas e Amontoadas
37
Figura 3.11: Sistema RFID centrado na aplicação
Figura 3.12: Sistema RFID centrado na rede.
38
Todos os objetos exceto para a aplicação RFID A, B e middleware na porção
superior da Figura 3.12 apresenta os principais componentes de uma rede tı́pica
em uma organização, que incluem servidores e clientes que executam diversas
aplicações, tais como por exemplo ERP, Inventory Management System (IMS)
e um sistema de RH. A banda de rede exigida pelas aplicações varia de organização para organização, e também dependendo da natureza das aplicações.
Eles compõem o maior consumo no tráfico da rede e é muito comum que algumas portas dos roteadores centrais e secundários estejam relacionadas com a
expansibilidade de nós da rede.
Há dois pontos para escolher quando na adição de rede RFID em uma rede
existente: amontoada ou dedicada. Na arquitetura amontoada, Figura 3.13, a
adição de rede RFID (principalmente dos leitores, middleware e as aplicações
RFID) irá situar-se no topo da rede, e eles poderão, por exemplo, estar conectados diretamente às portas disponı́veis nos switches secundários e principais. Tal
arquitetura de rede irá se misturar com a rede da organização e limitar sua escalabilidade. Na arquitetura dedicada, Figura 3.14, os leitores RFID são conectados
a switches dedicados os quais se conectam aos switches principais.
O middleware, também se conecta a este switch, filtra os dados do leitor RFID
e converte os dados em informação para que sejam utilizadas pelas aplicações
RFID. A aplicação RFID, como um tipo de aplicação da organização, comunica-se
com o middleware através de um roteador firewall, que alterna entre a rede RFID
por motivos de segurança. Tal arquitetura de rede provê a rede RFID grande
escalabilidade e resiliência na restrição gerencial da rede com segmentação.
39
Figura 3.13: Arquitetura amontoada.
40
Figura 3.14: Arquitetura dedicada.
41
Se o switch secundário 1 e 2 numa organização são atribuı́dos para a mesma
rede, então os leitores conectados aos switches devem herdar tal segmentação,
mesmo que a aplicação RFID precise que os leitores estejam em diferentes redes ou
VLANS. Outra caracterı́stica é que a segurança é tratada como o enorme tráfego.
A arquitetura amontoada traz vulnerabilidade dentro da rede da organização. Um
hacker pode colocar um número de etiquetas dentro de um campo de interrogação
dos leitores conectados ao switch 1, o qual gera um enorme tráfego no segmento
da etiqueta até o switch. Se não há nenhuma LAN virtual configurada no switch,
então o tráfego de etiquetas irá sobrecarregar a sub-rede do switch, e poderá
causar sobrecarga nas aplicações de rede que estão executando na sub-rede do
mesmo switch . A escalabilidade é muito confinada na arquitetura amontoada
por causa de suas caracterı́sticas, em contraste com a arquitetura dedicada, que
oferece escalabilidade diversificada na sua implantação.
Arquitetura
Facilidade
Sub-redes
VLAN
Tratamento de segurança na sobrecarga
de tráfego
Escalabilidade
Amontoada
Disponibilidade
de
portas nos switches
secundários e principal.
É
limitado
pela
existência de configuração nos switches
secundários. Se a rede
local virtual não é
suportada o tráfego
de RFID vai impactar
na banda disponı́vel
para as aplicações da
rede da organização.
Conecta as portas
disponı́veis para a
mesma rede local
virtual
de
RFID
(precisa de switches
secundários
para
suportar a VLAN).
Vulnerável por causa
de restrições da segmentação e a posição
do middleware na
rede.
Limitado
Dedicada
Disponibilidade
de
portas no switch e
principal somente.
É
limitado
pela
existência de configuração nos switches
secundários. Se a rede
local virtual não é
suportada o tráfego
de RFID vai impactar
na banda disponı́vel
para as aplicações da
rede da organização.
Sem restriçã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 aplicação
Imagine, como exemplo, que os revendedores de um varejo pretendam aumentar suas vendas com a utilização da tecnologia RFID principalmente a partir das
seguintes perspectivas: inventário no contexto da loja, controle de gestão, balanço
rápido com suporte contagem de itens, capacidade de monitorar e rastrear e prevenção de faltas no estoque. É então citado os seguintes conceitos e métodos para
atender aos requerimentos desta aplicação RFID:
1) Ponto Cobertura: atribuição de um grupo de leitores para cobrir muitos
objetos no chão da sala de vendas. Este método de alocação de leitores atende a
dois requisitos da aplicação: contagem rápida de estoque e prateleiras inteligente.
As informações de contagem do estoque, como qual e quantos produtos estão
atualmente no departamento de vendas, podem ser obtidos em diferentes tipos
de granularidades. Para prateleiras inteligentes, quanto o nú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 é configurável de acordo com as necessidades da aplicação, o middleware, verificando a situação baseada na cobertura,
irá alertar o sistema através de um pedido do produto.
2) Limite de separação: atribuição de dois grupos de leitores ao longo dos limites de duas áreas para construir uma fronteira separação. Suporta a capacidade
de monitorar e rastrear com granularidades diferenciadas.
3) Leitores móveis: montando o leitor sobre uma base móvel ao longo da faixa
fornece cobertura eficaz em termos de custos de utilização leitor.
Número de Leitores
O número de leitores RFID em uma rede que pode ser obtido a partir do
número de zonas de leitura levantada com base na análise do espaço fı́sico. O
número de zonas leitura, por sua vez, é determinado pela cobertura interrogação
exigida pela aplicação. No processo de determinar o número de leitores, muitas
opções para monitorar e rastrear em diversas escalas e cobertura de interrogação
das etiquetas devem ser fornecidos para os usuários finais do sistema RFID.
Exigência da banda de tráfego na rede RFID
Para projetar uma boa relação custo-benefı́cio e uma rede de RFID, é necessário
realizar análise quantitativa sobre as exigências da banda de tráfego na rede RFID.
O EPC é o número de identificação padronizado de objetos da EPCglobal Network. A EPCGlobal Network fornece um framework flexı́vel para a estrutura
dados EPC e suporta vários esquemas de numeração (por exemplo, GTIN, SSCC,
GLN, GRAI, GIAI, GID, EAN.UCC; VTN, CAGE) [NetworkTM, 2006]. Os esquemas de numeraçã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 é a única coisa armazenada no chip, e por consequência, é o único dado que é passada da etiqueta para o leitor, o leitor tem
43
01
8 bits
Cabeçalho
Determina a estrutura de dados
da etiqueta.
OOOOA89
28 bits
Gerente
do
domı́nio
Identifica a entidade responsável
por manter os
números subsequentes
00016F
24 bits
Classe do objeto
0001S9DC0
36 bits
Número serial
Representa
a
classe do objeto
Identificação
única do objeto.
Tabela 3.6: Código eletrônico de produtos: EPC
a acrescentar sobre outra camada de informações básicas, a fim de atender o
middleware, como o a assinatura de hora da leitura e o identificador da antena.
Do mesmo modo, middleware também tem a acrescentar mais uma camada de
informações básicas para que o seu próprio uso além das aplicaçõ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 informações de determinado
leitor. Portanto, a largura de banda necessária para o tráfego da etiqueta EPC
para cada leitor é calculada em três nı́veis: etiqueta para o leitor, leitor para o
middleware e middleware para a aplicação.
P
1) Etiqueta para o leitor: BW t = N
i=1 (St ∗ XAi)
Onde S t é o tamanho do ID da etiqueta EPC (por exemplo, 96-bit); X ai é
o número médio de chegadas evento por segundo para antena i (por exemplo, 600
são limites superiores na Europa); N é o número de antena do leitor (por exemplo,
4); BW t é a largura de banda necessária para o leitor a obter as informaçõ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 é 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 última leitura dentro
intervalo de tempo. Sc é o tamanho do contador de leituras (8-bit), e Ia é
o identificador da antena (8-bit);Sip é tamanho de endereços IP de Origem e
destino. BWr é a largura de banda necessária para o middleware obter os dados
da etiqueta captada pelo leitor.
3) Middleware para as aplicações:
A exigência de banda depende da natureza das aplicações. Em primeiro lugar,
para a aplicação que necessita constantemente, alta freqüência, de interrogação
das etiquetas(alto valor de ai ), exige banda de rede elevada. Em segundo lugar,
o volume de dados potencialmente transmitido através da rede não é apenas um
fator do número de etiquetas e comprimento do EPC ID. O padrão EPCGlobal
contém um Object Naming Service (ONS), que permite uma etiqueta para especificar o local (endereço IP), de informação sobre os produtos armazenados noutro
local na rede [Brown and Wiggers, 2005]. Assim, uma etiqueta pode gerar ou requisitar e recuperação de dados a partir de qualquer ponto da rede. Logo, o tráfego
44
nesta camada deve ser quantificado de acordo com a especificação da aplicação.
3.2.5
Aplicações da Tecnologia RFID
Por consequência das vantagens oferecidas na tecnologia RFID, como não requer contato visual, leitura automática e robustez, existe atualmente diversas
aplicações da RFID. Ela é usada em todas as áreas que necessitam da captura
automática de dados, permitindo a identificação de objetos sem contato fı́sico,
via radiofrequência. Pode-se citar as aplicações em pedágios, aplicações médicas,
controle de acesso, proteção pessoal e logı́stica como destacado em [teleco, 2008].
3.2.5.1
RFID na Identificação humana
Na área de identificação humana, uma das principais aplicações da tecnologia
RFID é no controle de acesso, tanto a prédios como a salas especı́ficas, automatizando a verificação de permissão de acesso. Os sistemas de controle de acesso e
autorização podem ser divididos em dois principais grupos: on-line e off-line.
Os sistemas on-line são sistemas onde todos os terminais estão conectados
a uma central através de uma rede. Este computador central roda um banco
de dados, e comunica-se com os terminais para autorizar o não a entrada de
determinada etiquetas que está fazendo um requisição. Este tipo de sistema é
utilizado, por exemplo, no acesso a prédios comerciais e escritórios. Se alguma
alteração no controle de acesso for necessária, esta pode ser feita de maneira
mais simples, através do computador central, sem a necessidade da etiqueta estar
presente, pois nela contem apenas um número de acesso.
Nos sistemas off-line, não há uma comunicação em rede entre os terminais e
um computador central, cada terminal contém uma tabela de autorizações. Este
tipo de sistema é utilizado onde há muitas salas individuais, as quais poucas pessoas possuem acesso. A etiqueta também contem uma tabela de autorizações onde
são armazenados sua permissões, como por exemplo, sala 1, térreo ou depósito.
O leitor compara então a sua tabela de autorizações com a da etiqueta, e autoriza
ou nega o acesso. A etiqueta é programada em uma central, como a recepção de
um hotel ou a seção de uma empresa, com os acessos a que ela tem direito, além
de outros dados como, por exemplo, a data de expiração para os acessos.
Uma outra aplicação da RFID para identificação humana é 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 falsificação e ação de cambistas. Os microchips RFID contidos no cartão de ingresso
emitem um sinal de rádio que é captado por leitores on-line nas entradas dos
[theregister, 2008b].
Na área médica, a identificação humana através de microchips implantados
tem despertado o interesse de muitos pesquisadores. Em outubro de 2004, a
FDA (Food and Drug Administration ), agência que regula o uso de medicamentos e alimentos nos Estados Unidos, liberou o implante de etiquetas em humanos
para uso médico [theregister, 2008a]. O VeriChip , com dimensões próximas a
45
do grão de arroz, é uma etiqueta do tipo passiva inserida sobre a pele do paciente que contém unicamente um identificador de 16 dı́gitos. Esta tecnologia
permite a identificação imediata do paciente pela equipe médica. Entretanto, um
problema levantado muito recentemente diz respeito quanto à seguranç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 demonstração
na conferência HOPE (Hackers on Planet Earth ) Number Six , em Nova York
[theregister, 2008a].
Na área de entretenimento, já 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 serviços VIP, tal como
pagar suas respectivas contas sem a necessidade de apresentar nenhum
documento [Gazette, 2008].
Nos eventos esportivos, além da bilhetagem, etiquetas são utilizadas também
em corridas, aplicadas no cadarço dos corredores, Figura 3.15 para saber com
exatidão o tempo percorrido como citado em [Finkenzeller, 2003], página 179.
Este tipo de aplicação torna-se útil principalmente em provas onde a quantidade
de corredores é muito grande.
Figura 3.15: Etiqueta RFID afixada em cadarço de tênis [Finkenzeller, 2003].
3.2.5.2
Computação Ubı́qua
A Computação Ubı́qua, também conhecida como Ubicomp ou Computação Invisı́vel, é um paradigma que propõe um modelo de integração entre processamento
de dados e atividades cotidianas de modo invı́sivel ao ser humano, baseando-se
na fusão de computadores ao mundo fı́sico de maneira que serviços possam ser
prestados por eles de maneira pró-ativa, e contextualizada de acordo com as necessidades apresentadas pelas situações da vida real.
No final da década de 1980, Mark Weiser, então Tecnólogo-Chefe do PARC
(Palo Alto Research Center), um centro de pesquisa da multinacional norteamericano XEROX, idealizou o conceito de Computação Ubı́qua em resposta
ao desafio de elaborar um novo paradigma computacional capaz de se tornar uma
evolução da visão que se tinha do uso do computador e de sua maneira de solucionar problemas cotidianos. Inspirado por questões levantadas por diversas áreas
46
das ciências humanas, como filosofia, antropologia, psicologia, sociologia cientı́fica
e pelo pensamento pós-modernista, Weiser buscou uma solução que fosse capaz de
integrar o processamento de dados às situações e problemas diariamente vividos
pelas pessoas, tendo em mente que a compreensão dessas ciências o levaria à tal
solução. Os estudos pesquisados por Weiser o levaram à perceber que, mais do
que uma ferramenta de trabalho, que deveria ser invisı́vel ao usuário, o computador se torna frequentemente um foco de atenção, e, por vezes, um obstáculo a esse
trabalho [Weiser, 1993]. Baseado nessas questões, em 1988 Mark Weiser e vários
de seus companheiros do PARC elaboraram as primeiras ideias e os primeiros artigos sobre Computação Ubı́qua, que conferiram à eles (e a Weiser principalmente)
o status de pais da Ubicomp.
A Computação Ubı́qua tem, portanto, como cenário ideal, um determinado
ambiente fı́sico em que um ou mais elementos, através do uso de computadores de
tamanho, formato e capacidade de processamento adequados a cada um, sejam
capazes de prestar serviços convenientes ao ser humano sem que este tenha que
requisitá-los, ou mesmo tome conhecimento de quem os fornece. Para tanto, é
indispensável que esses elementos sejam capazes de avaliar, pró-ativamente, o
momento em que se tornam necessários, de comunicar-se entre si quando assim
for devido, e de responder adequadamente de maneira que o processamento por
trás da tarefa realizada seja invisı́vel para o cliente. Em suma, é necessário que
o computador cumpra tarefas do dia-a-dia sem que seja notado como meio de
consecução dessas tarefas, assim como na maior parte do tempo não atentamos
para os ó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 computação ubı́qua, pois diminui o espaço entre a monitoração real dos objetos e o
processamento de informações acerca do portador, dado que é possı́vel identificar
a etiqueta utilizada, por possuir uma numeração única, e o lugar onde a etiqueta
foi lida. Como uma aplicação ubı́qua é sensı́vel contexto em que está inserida,
isto é, seu comportamento é influenciado por outros dispositivos ubı́quos presentes
e a presença do homem, identificar a presença dos mesmos através de sensores
RFID têm se mostrado ferramenta ideal para computação ubı́qua pois de forma
automática difere cada dispositivo ubı́quo ou ser humano presente no contexto.
[Weiser and Brown, 1997] apresenta a Ubicomp como a terceira geração de
paradigmas computacionais. A primeira geração é apresentada por ele como a era
dos Mainframes, em que o processamento de dados era centralizado por máquinas
de grande porte que executavam inúmeras tarefas simultaneamente, atendendo a
incontáveis usuários. A miniaturização dos processadores, memórias e de diversos outros componentes eletrônicos utilizados no computador trouxe consigo a segunda geração de paradigmas computacionais, a era do PC, o computador pessoal,
que levou o computador das grandes empresas e universidades para as casas dos
cidadãos comuns, individualizando o seu uso. A terceira geração, a Computação
Ubı́qua, propõe expandir ainda mais o horizonte dos computadores, e torná-los
comuns não apenas nos locais de trabalho e escrivaninhas das residências, mas
em todo lugar onde o esforço humano é demandado, e nos objetos mais triviais,
como canetas, roupas, relógios, portas e cadeiras.
A miniaturização do computador e a diminuição dos custos de seus compo47
nentes permitiu que sua utilização, originalmente restrita à aplicações cientı́ficas
ou militares, para realização de cálculos extremamente complexos, fosse expandida
para tarefas simples como escrever textos ou ouvir música. A proposta da Ubicomp é que essa miniaturização continue, de modo a permitir que junto com ela
se expandam os horizontes de aplicação dos computadores, permitindo que não
apenas um, dois, ou três computadores atendam simultaneamente um indivı́duo,
mas tantos quantos forem necessá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, porém, é necessário que os computadores possam ser aplicados à tarefas mais básicas, nas quais não é conveniente
que o homem tenha que interagir diretamente com um computador (nesse caso, a
atual geração de desktops já é capaz de suprir a maior parte das necessidades), e
que sejam altamente especializadas. Da mesma maneira que os mainframes ainda
são vastamente utilizados para execução de processamentos muito complexos e
manipulação de grande volume de dados (como em instituições bancárias ou estudos cientı́ficos), mas tiveram seu uso muito diminuı́do com a popularização dos
desktops (que assumiram antigas funções dos mainframes além de gerar muitas
novas aplicações) a ideia por trás da Ubicomp não é substituir desktops ou mainframes totalmente, mas apenas onde sua utilização for mais conveniente, e permitir o alcance do computador aonde as tecnologias correntes não são aplicáveis.
Um exemplo de ambiente ubı́quo pode ser verificado em [Weiser, 1993]. Nesse
artigo, os autores descrevem a utilização de sensores de localização para monitorar os movimentos de visitantes voluntários dentro de um museu na cidade de
Osaka, no Japão. Esses sensores localizam os voluntários através de uma pulseira
utilizada por eles, com uma etiqueta de localização. A partir dos dados coletados por esses sensores, é feita uma avaliação por um programa de computador,
baseada no percurso feito pelo visitante no museu e nos seus dados pessoais, de
suas áreas de interesse. Essa avaliação é utilizada por robôs espalhados pelo museu
para interagir com os visitantes de acordo com seu perfil pessoal, localizando-os
através de outros sensores embutidos nos próprios robôs, endereçando-os pessoalmente e orientando-os ou entretendo-os de acordo com suas preferências. Desta
maneira, os visitantes que se voluntariaram interagiram com os robôs sem que notassem o uso do computador como intermediário, já que as pulseiras não atraı́am
a atenção desses voluntários; os robôs, por sua vez, prestaram um serviço personalizado aos visitantes do museu, captando dinamicamente as necessidades de
cada um, através da localização por sensores ubı́quos [Kanda, 2007].
48
Capı́tulo 4
Sistema de controle e
monitoração de acesso: I-Locate
Neste capı́tulo é apresentado uma proposta para a motivação apontada no Capı́tulo
2, o sistema I-Locate.
Nas seções que se seguem é apresentada a ordem em que a proposta é desenvolvida e compreende a modelagem de negócio do sistema, arquitetura do software
e apresentação do software.
4.1
Processos de negócio existentes na instituição
O objetivo desta seção é apresentar elementos suficientes para o entendimento
dos atuais processos de negócios relacionados ao controle e a monitoração dos
usuários que acessam as dependências fı́sicas do HUB. Tais informações foram
obtidas por meio de entrevistas, realizados com a equipe da segurança do HUB.
Atualmente, no controle de entrada, saı́da e deslocamento do usuário na dependências fı́sicas do hospital são empregados três processos de negócios:
1. Registrar entrada do usuário: é necessário que o interessado dirija-se a algum ponto de entrada. Neste ponto de entrada, o interessado deve identificarse com algum documento de identificação válido, tais como: Identidades
expedidas por órgãos oficiais, identidade funcional ou carteira estudantil
da Universidade de Brası́lia. Após a identificaçã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;
• Funcionário;
• Usuário casual;
Após são analisadas as seguintes regras de negócio para cada modalidade
de interessado:
49
• Visitante de paciente
– Se o interessado for um visitante de pacientes, então é liberado o
acesso de acordo com o horário de visitas das 15:00 as 16:00, de
Segunda a Sexta;
– Se o interessado for um visitante para um paciente conveniado,
então terá o acesso liberado caso o número de visitantes naquele
momento para o paciente for menor do que 2;
– Se o interessado for um visitante para um paciente não-conveniado,
então o acesso será liberado caso o nú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 têm seu acesso às dependências do hospital através de
ordem médica;
• Funcionário - Estes têm acesso liberado em qualquer dia da semana e
em qualquer horário sem a necessidade do registro de entrada, desde
que portem a identidade funcional;
• Usuário casual - Este têm acesso liberado somente com a autorização
um funcionário do HUB;
Caso o interessado seja liberado para o acesso é efetivado o registro de
entrada. Neste passo são registrados em uma ata dados como nome, telefone, endereço, número da identidade, lugar de destino, horário de entrada.
Após, é cedido uma etiqueta adesiva as cores das etiquetas sã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 decisões envolvidas na
autorização de acesso de usuários às dependências fı́sicas do HUB, considere
os diagramas de atividades nas figuras 4.1, 4.2 e 4.3.
2. Monitorar usuários
Na parte da monitoração, o controle é feito pelo contato visual dos agentes
de segurança com a cor da etiqueta. Ás 18:00 horas não é permitido a
permanência de uma pessoa portando a etiqueta verde na Unidade 1, pois
50
Figura 4.1: Diagrama de atividade do cadastro de entrada do usuário do tipo
visitante.
Figura 4.2: Diagrama de atividade do cadastro de entrada do usuário do tipo
acompanhante.
Figura 4.3: Diagrama de atividade do cadastro de entrada do usuário casual.
51
o horário de visitas encerra as 16:00. Esta atividade é bastante onerosa
para a equipe de segurança, pois necessita de pelo menos um agente para
monitorar cada dependência fı́sica.
A monitoração deve obedecer as seguintes regras de negócio:
Se não for de 15:00 as 16:00 do dia corrente então o visitante deve ser
retirado do HUB;
Se o interessado portador da etiqueta estiver em dependência não autorizada, então o mesmo deve ser levado para a respectiva área autorizada ou
para fora do hospital;
3. Registrar saı́da de usuários
O usuário deve devolver ao segurança a etiqueta adesiva por ele utilizada e
seu horário de saı́da é registrado na ata.
Com as informaçõ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 visão estruturada das funções do atual sistema e as entidades de negócio relacionadas com as respectivas funções.
Figura 4.4: Diagrama de fluxo de dados
52
4.2
4.2.1
Necessidades do sistema
Introdução
Com base nas informações expostas na Seção 4.1, propõe-se um sistema informatizado que utilize a tecnologia RFID, com o objetivo de implementar as regras de
negócio existentes, além de oferecer vantagens e facilidades em seu emprego.
Quando na tentativa de adentrar no hospital o interessado deve identificarse com algum documento de identificação válido e o sistema deve decidir, com
base nas regras de negócio existentes, se o usuário terá ou não permissão para
prosseguir nas dependências fı́sicas do hospital. Caso positivo será cedida ao
usuário um crachá,com uma etiqueta RFID anexada, e deverá ser devolvido na
saı́da. O sistema deverá registrar a entrada do usuário, os locais e horários por
onde o mesmo transita durante sua permanência, além da saı́da do mesmo. Este
monitoramento será realizado através do emprego de elementos de uma rede
RFID, ou seja uma rede capaz de capturar sinais da etiquetas anexadas aos
crachás portados pelos usuários que passam nas proximidades dos leitores RFID.
Este dados permitirão ao sistema identificar acessos e permanências não autorizadas, tanto no que se refere a localização como no horário irregulares.
O uso dos crachás e o registro de acesso deverão ser obrigatório para todo
e qualquer tipo de interessado que adentrar as dependências do hospital, salvo
no caso do mesmo ser funcionário identificado do HUB, sendo para este o uso e
registro opcionais.
Acerca da monitoração, esta deverá apresentar uma interface gráfica para
localização visual do usuário do HUB nas plantas do hospital. Ainda assim, a
monitoração deverá agir de forma proativa, isto é, informar ao usuário do sistema
acerca da irregularidade do usuário do HUB;
Além disso, o sistema deverá:
• Ser desenvolvido na plataforma WEB: um serviço acessado através de um
explorador de internet. Tal caracterı́stica visa facilitar o seu acesso quanto
a restrição fı́sica e a portabilidade do mesmo quanto a plataforma do computador cliente utilizado;
• Ter acesso restrito, isto é, somente usuários com autorização poderão utilizar
o serviço;
• Prover serviços de gerenciamento de informações - prática sistemática de
criação, atualização, remoção e pesquisa de registros na base de dados, de
usuários que entram no hospital, usuários que utilizam o sistema, leitores
RFID, etiquetas RFID, registros de eventos de acesso monitorados e configurações relevantes do middleware e o EPCIS utilizados na rede RFID;
• Utilizar-se de programas de código aberto para tornar o sistema isento de
pagamento por uso de softwares externos;
53
4.2.2
Requisitos funcionais
Esta seção visa formalizar e esclarecer as necessidades do sistema através da utilizaçã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 são
descritos de modo sucinto abaixo.
Usuário do sistema: Usuário genérico do sistema (Figura 4.5);
Gerenciador de etiquetas RFID: Usuário cuja finalidade é de gerenciar informações acerca de etiquetas RFID no sistema (Figura 4.6).
Funcionário da segurança HUB: Usuário cuja finalidade é de controlar o acesso
as dependências fı́sicas autorizando ao negando o acesso dos usuários interessados
ao do hospital (Figura 4.7).
Supervisor da equipe de segurança do HUB: Usuário supervisor da equipe de
segurança do hospital (Figura 4.8).
Suporte técnico do sistema: Usuário que provê suporte técnico ao sistema e
está intimamente ligado a gerenciar configurações para o correto funcionamento
do sistema (Figura 4.9).
Gestor do sistema: Responsável por gerir os usuários e seus respectivos perfis
de acesso ao sistema (Figura 4.10).
Figura 4.5: Diagrama do caso de uso do ator “usuário gené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 “funcionário da segurança”.
55
Figura 4.8: Diagrama do caso de uso do ator “supervisor da segurança”.
Figura 4.9: Diagrama do caso de uso do ator “suporte té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
são detalhados em anexo na Seção 6.1.
4.2.3
Premissas de funcionamento
Para o correto funcionamento do sistema é necessário que:
1. Ocorra o controle fı́sico de acesso nas entradas do hospital para qualquer
pessoa que adentrar suas dependências, salvo os funcionários, desde que seja
opção da diretoria do hospital de não monitora-los;
2. Nos pontos de controle de acesso fı́sico deve ser entregue um crachá ao
usuário do HUB, o qual só poderá sair do recinto ao entregar o respectivo
crachá.
3. Cada crachá deve portar uma etiqueta RFID para a detecção da mesma
pelo sistema;
4. Cada dependência fı́sica deve ter um leitor de RFID em cada entrada, isto
é, no inı́cio de cada alternativa de acesso à dependência fı́sica.
5. Em cada entrada monitorada deve existir um computador conectado a uma
intranet para que através desta seja possı́vel a conexão aos serviços do sistema.
57
6. Que o computador definido para acessar os serviços do sistema tenha instalado pelo menos um explorador de internet.
4.3
Arquitetura do software
Esta seção descreve em detalhes a arquitetura do sistema, seus elementos e a
integração do mesmo com uma rede RFID.
O sistema I-Locate é constituı́do por 5 módulos que se comunicam-se através
de interfaces e são apresentados na Figura 4.11.
Figura 4.11: Arquitetura lógica do sistema I-Locate, e a integração dos seus 5
módulos.
58
Os módulos situados abaixo do módulo ILOCATEWEB são módulos para
implementação e funcionamento da rede RFID do hospital. Estes módulos são o
EPCIS, o gerador de eventos EPCIS, um middleware e leitores RFID. O módulo
ILOCATEWEB trata de uma aplicação WEB que é executado em um servidor
HTTP e faz interface com os usuários da aplicação via explorador de internet. A
organização e integração destes módulos são uma implementação do framework
de arquitetura de rede RFID proposto pela EPCGlobal, como elucidado na Seção
3.2.3.
Segue na Figura 4.11 uma breve descrição de cada interface e componente do
sistema I-Locate.
• Interface aérea da etiqueta RFID: meio de comunicação comum entre o leitor
e as etiquetas RFID. Não é utilizado atualmente no sistema I-LOCATE pela
escolha dos leitores RFID ser opção exclusiva do HUB, isto é, o custo e o
preço de diversos leitores presentes no mercado dependerá do que mais se
adequará ao interesse da instituição.
• Leitores RFID: hardwares responsáveis por notificar o middleware acerca
da presença de etiquetas no campo de leitura. Estes devem ser instalados
em cada meio de acesso às dependências fı́sicas que serã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 informações de leitura para o middleware. Este meio de comunicação deve ser
exclusivamente feito sobre o protocolo TCP/IP para que os leitores possam
alcançar as mais diversas dependências fı́sicas do HUB.
• Módulo do middleware: módulo responsável por centralizar os eventos gerados pelo leitores fı́sicos. Aplica formatação, filtro e lógica aos dados das
etiquetas captadas pelos leitores para que o módulo cliente, EPCIS, possa
processar estes eventos. É papel também deste módulo desacoplar qualquer
meio de acesso do leitor, que podem ser de várias marcas diferentes, das
aplicações que desejam capturar os eventos advindos dos mesmos.
• Interface de filtro e coleção de eventos: Interface utilizada para o envio de
relatórios de eventos a serem processados posteriormente pelo gerador de
eventos EPCIS.
• Gerador de eventos EPCIS: Este módulo é responsável por converter os
relatórios advindos do middleware para os relatórios que o EPCIS possa
compreender.
• Interface de captura EPCIS: Serviço para o qual o EPCIS aguarda por
relatórios do gerador de eventos EPCIS. Os relatórios recebidos por este
serviço, serão armazenados pelo EPCIS.
• Módulo do EPCIS: Módulo responsável por receber os relatórios de eventos
de detecção de etiquetas e armazená-los para futuras consultas ou redirecioná-los para qualquer aplicação cliente interessada.
59
• Interface de consulta EPCIS: Interface responsável por prover meio de consulta de maneira lógica aos dados constates no módulo EPCIS.
• Módulo I-Locate: Serviço WEB,o qual disponibiliza ao usuários a interface
gráfica para realizar os casos de uso indicados na Seção 4.2.2;
A seguir segue a descrição detalhada de cada módulo citado acima.
4.3.1
Módulo do leitor RFID
Este módulo é representado no sistema por um ou mais leitores RFID. Tais leitores
RFID devem integrar-se com o middleware através de uma conexão de rede sobre
o protocolo TPC/IP. É necessário que os mesmos sejam previamente configurados para redirecionar os eventos para o host onde se encontra o middleware. É
importante frisar que o middleware unifica qualquer tipo de protocolo de alerta
de eventos de diferentes marcas e modelos de leitor através de um adaptador. Tal
adaptador, é uma interface a ser implementada do ponto de vista da linguagem
de programaçã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, é necessário que seja interposto um driver que traduza o
protocolo nativo do leitor para a implementaçã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 endereço do servidor onde está sendo executado
o middleware e a etiqueta que está disparando o evento. Em seguida, o evento
enviado para o adaptador do leitores no middleware através do uso do framework
EJB.
4.3.2
Módulo do middleware
Este módulo é necessá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 propósito
foi selecionado o middleware CUHK-RFID Middleware [CUHK, 2008a], desenvolvido pela Universidade de Honk Kong.
Este software é uma implementação da especificação de serviços de um middleware padrão estabelecido pela EPCGlobal, além de prover interface para
1
Java é uma linguagem de programação orientada a objeto desenvolvida na década de 90
por uma equipe de programadores chefiada por James Gosling, na empresa Sun Microsystems.
Diferentemente das linguagens convencionais, que são compiladas para código nativo, a linguagem Java é compilada para um “bytecode”que é executado por uma máquina virtual, o que
a torna linguagem executada independentemente de plataforma foi cada plataforma possui sua
própria máquina virtual.
2
É um dos principais componentes da plataforma J2EE - Java 2 Enterprise Edition. É um
componente do tipo servidor que executa no container do servidor de aplicação. Os principais
objetivos da tecnologia EJB são fornecer um rápido e simplificado desenvolvimento de aplicações
Java baseado em componentes distribuı́das, transacionais, seguras e portáveis.
60
aplicações clientes para redes RFID. Esta interface é estendida para suportar
leitura e escrita das memórias da etiquetas. Com ele é possı́vel que os leitores
RFID sejam conectados através de uma rede TCP/IP ou através de adaptadores
RS-232. Acerca da execução do middleware, este é um software desenvolvido na
linguagem Java e disponibiliza seus serviços através do servidor de aplicações Java
JBOSS3 distribuição 4.0.4.GA - Zion, customizado pela própria equipe que desenvolveu o middleware. A arquitetura e a interface com os módulos do I-Locate
podem ser observadas na Figura 4.12.
Figura 4.12: Visão geral da arquitetura do CUHK Middleware.
Abaixo a descrição dos elementos da Figura 4.12:
• ALEService - É um stateless session bean 4 , compreendido como ALEServiceBean. Ela implementa a classe principal da API do middleware e é
exposta como um webservice 5 , permitindo seus clientes acessá-lo via SOAP
3
É um servidor de aplicação de código fonte aberto baseado na plataforma J2EE - Java 2
Enterprise Edition, implementada completamente na linguagem de programação Java. Como é
baseada em Java, o JBoss pode ser usado em qualquer Sistema Operacional que suporte Java.
4
É um tipo de componente especificado pelo framework EJB. Estes componentes realizam
serviços transientes e atuam como agentes da camada de negócio de uma aplicação web. São
executados remotamente e têm o escopo de sessão.
5
É uma solução utilizada na integração de sistemas e na comunicação entre aplicações difer-
61
6
.
• TagDataService - É um stateless session bean, compreendido como TagDataServiceBean. Ela implementa os serviços estendidos de leitura e escrita
de etiquetas do middleware e é exposta via webservice, através do SOAP.
• ECSpecValidator - É uma classe java utilitária padrão. Ela valida as especificações de relatórios.
• ECSpecInstance - É um entity bean 7 , compreendido como ECSpecInstanceBean. Ela representa uma especificação de relatório (ECSpec) definida no
middleware. Ela também modela o ciclo de vida de uma especificação de
relatório suportando as transições de estados não-requerido, requerido e
ativo. Ela trabalha com o temporizador (Timer) para gerenciar a transição
de estados disparados por timeout 8 .
• ReportGenerator - É um stateless session bean.
(ECReports) para um dado ciclo de evento.
Ele gera os relatórios
• Notifier - É um message driven bean 9 . Ela realizar as notificações de relatórios aos clientes escritos, via HTTP(POST) e TCP(XML), e é disparado
pelo temporizador (Timer).
• Timer - É um serviço temporizador embutido. Ele suporta várias operações
relacionadas com o timeout.
• ReaderManager - É um stateless session bean. É um ponto de acesso ao middleware exposto como um serviço EJB. Ele permite o registro de leitores
fı́sicos e a agregação das etiquetas lidas pelos mesmos através de adapentes. Com esta tecnologia é possı́vel que novas aplicações possam interagir com aquelas que
já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatı́veis. Os Web
Services são componentes que permitem às aplicações enviar e receber dados em formato XML.
Cada aplicação pode ter a sua própria “linguagem”, que é traduzida para uma linguagem universal, o formato XML.
6
Originado do acrônimo inglês Simple Object Access Protocol, é um protocolo para troca
de informações estruturadas em uma plataforma descentralizada e distribuı́da, utilizando tecnologias baseadas em XML. Sua especificação define um framework que provê maneiras para
se construir mensagens que podem trafegar através de diversos protocolos e que foi especificado de forma a ser independente de qualquer modelo de programação ou outra implementação
especı́fica.
7
É um componente definido na especificação do EJB que representa uma entidade a ser
persistida em um banco de dados.
8
Tempo de espera definido como tempo máximo a ser aguardado para execução de um
serviço.
9
É um componente definido na especificação do EJB que provê comunicação assı́ncrona entre
cliente e servidor. A mensagem enviada por um cliente chega através do JMS - Java Message
Service e é transferida para a respectiva instância do message-driven bean através do container
EJB.
62
tadores, utilizando a tecnologia RMI10 /JRMP11 . As etiquetas lidas são armazenadas em um banco de dados feito na memória para o uso centralizado
e compartilhado do middleware.
• Adaptador do leitor - É um driver, com qual há 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 vários leitores
ativos ao mesmo tempo. Para gerenciar tal circunstância sem impacto na
performace, são utilizadas instâncias de banco de dados em memória e outra
em disco. Na instância presente na memória, são armazenadas os eventos
de etiquetas lidas pelos leitores e a instância em disco são gravados somente
os eventos de leitura que interessam aos cliente especificados através da
definição de relatórios a serem enviados aos clientes inscritos no middleware.
• Serviço de definição de especificação de relatórios - Serviço externo ao middleware com o objetivo de definir como serão os relatórios a serem recebidos
pelo serviço de captura de relatórios. Cada especificação de relatório define
o conjunto de dados de quais informações o relatório deverá incluir, o intervalo de tempo que será enviado e o endereço HTTP ou TCP de destino.
Este serviço é implementado no módulo “ILOCATEWEB”, Figura 4.11, e
será descrito no momento oportuno da descrição do módulo em questão.
• Serviço de captura de relatórios - Serviço externo responsável por receber
os relatórios de eventos do middleware, convertê-los para o tipo de relatório
do EPCIS e envia-los para o serviço de captura do EPCIS. Este serviço é
implementado pelo módulo “GERADOR DE EVENTOS EPCIS”da Figura
4.11;
• Módulo de gerenciamento do middleware - Módulo responsável por implementar os serviços diversos de gerenciamento de dados que estão no middleware. Este componente é um submódulo embutido no “ILOCATEWEB”,
Figura 4.11.
10
Acrônimo em inglês para Remote Method Invocation. É uma interface de programação que
permite a execução de chamadas remotas no estilo RPC em aplicações desenvolvidas em Java.
É uma forma de implementar um sistema distribuı́do em plataforma Java. A API RMI provê
ferramentas para que seja possı́vel ao programador desenvolver uma aplicação sem se preocupar
com detalhes de comunicação entre os diversos possı́veis elementos hosts de um sistema. A
grande vantagem do RMI em relação ao RPC se dá ao fato de ser possı́vel invocar métodos de
objetos remotos e transferir objetos complexos entre estes.
11
Acrônimo em inglês para Java Remote Method Protocol, Protocolo de Método Remoto Java)
é o protocolo nativo da RMI, mas não é necessariamente o ú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 módulo é responsável por capturar os relatórios advindos do middleware via
HTTP(POST) e enviá-los no formato reconhecido pelo EPCIS. Para isso, devese criar um novo relatório, o qual deverá ter sentido de negócio aos seus dados,
como por exemplo a localização fı́sica dos leitores lógicos informados no relatório
do middleware. Após tal criação, o relatório é encaminhado ao host onde está
executando o serviço de captura do EPCIS via HTTP(POST). Este módulo é
implementado como sub-módulo do “ILOCATEWEB”e será explanado na Seção
4.3.5 na descrição da classe IlocateALEReportListener.
4.3.4
Módulo EPCIS
O objetivo do uso deste módulo é de habilitar as aplicações clientes a incorporar dados relacionados com o código EPC ao seu negócio. Ele provê meios de
armazenar dados acerca de eventos advindo do middleware e oferece um framework para adicionar dados ao repositório assim como para consultá-los. Para este
propósito foi selecionando o software Accada EPCIS Repository [EPCIS, 2008] na
versão 0.3.1, licença de uso LGPL (Lesser General Public License) 3.0, que desempenha o papel descrito acima, além de implementar a especificação de EPCIS
descrita pelo framework da EPCGlobal.
A Figura 4.13 ilustra as interfaces do EPCIS. Através da interface de captura de relatórios, o repositório recebe via HTTP(POST) os relatórios convertidos do middleware pelo módulo de “GERADOR DE EVENTOS EPCIS”e os
grava em sua base de dados. Já a interface de consulta permite ao módulo
“ILOCATEWEB”, via SOAP, consultar eventos relacionados com etiquetas que
estejam armazenados no EPCIS, além de inscrever um host para recebimento
assı́ncrono de relatórios que o interessa.
64
Figura 4.13: Visão geral da arquitetura do repositório EPCIS, adaptado de
[CUHK, 2008b]
4.3.5
Módulo ILOCATEWEB
Este módulo centraliza os serviços de interface com o usuário implementando os
casos de uso idealizados na Seção 4.2.2.
Ele foi desenvolvido com linguagem de programação Java e a utilização do
framework JSF12 1.2. A execução deste módulo é realizado em um servidor Tomcat13 para que os serviços provenientes deste tornem-se acessı́veis através de rede
intranet.
Segue na Figura 4.14 os pacotes que compõem a aplicação deste módulo. A
descrição do papel de cada um segue abaixo:
• Pacote br.edu.unb.hub - Pacote principal que contém os demais pacotes
constantes neste módulo.
• Pacote br.edu.unb.hub.apresentacao - Pacote que contém classes que dão
suporte a camada de apresentação da aplicação. Cada classe deste pacote
12
É a API padrão Java para construção de componentes de interface com o usuário nas
aplicações WEB, implementando a arquitetura MVC. Ela oferece um conjunto amplo de componentes prontos para serem utilizados nas aplicações WEB.
13
É um servidor WEB Java, mais especificamente, um container de servlets. O Tomcat possui
algumas caracterı́sticas próprias de um servidor de aplicação, porém não pode ser considerado
um servidor de aplicação por não preencher todos os requisitos necessários. Por exemplo, o
Tomcat não tem suporte a EJB. Desenvolvido pela Apache Software Foundation, é distribuı́do
como software livre dentro do conceituado projeto Apache Jakarta.
65
representa a lógica das páginas JSP exibidas ao usuário. Quando executadas, as ações do usuário são processadas pela lógica de apresentação da
página em questão, formatação e validade dos campos, e após o fluxo de execução é passado para o pacote br.edu.unb.hub.negocio onde são executadas
as regras de negócio para a funcionalidade em questão.
• Pacote br.edu.unb.hub.negocio.dao.util - Pacote responsável por centralizar
as classes relacionadas com a lógica de negócio da aplicaçã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 execução de funcionalidades que requeiram alguma transação no módulo EPCIS, e do pacote
br.edu.unb.hub.negocio.dao.util para serviços de cunho utilitário da camada
de acesso a dados.
• Pacote br.edu.unb.hub.negocio.dao.hibernate - Pacote responsável por realizar o acesso à persistência representando a camada de acesso ao banco
de dados da aplicação. É 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 módulo.
• Pacote br.edu.unb.hub.negocio.dao.util - Pacote de contém classes utilitárias
para acesso ao banco de dados.
• Pacote br.edu.unb.hub.seguranca - Pacote responsável por implementar a
proteção de acesso ao módulo ILOCATEWEB. Está proteção é implementada utilizando-se o framework JAAS16 no servidor TOMCAT que executa
o módulo em questão. Ele autentica os usuários da aplicação disponibilizando para toda a aplicação o login do usuário e os perfis de acesso que
o mesmo deté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
usuário do sistema.
• Pacote br.edu.unb.hub.infraestrutura - Pacote responsável por centralizar
todas as funcionalidades de integração com os mó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 serviços
utilitários. Suas principais classes são:
– ControladorEPCIS - Classe que contém o serviço de inı́cio de monitoramento de etiquetas, inscrevendo a classe IlocateEPCISReportListener
14
É uma técnica de desenvolvimento utilizada para reduzir a impedância da programação
orientada aos objetos utilizando bancos de dados relacionais. As tabelas do banco de dados são
representadas através de classes e os registos de cada tabela são representados como instâncias
das classes correspondentes. Com esta técnica, o programador não precisa de se preocupar com
os comandos em linguagem SQL; irá usar uma interface de programação simples que faz todo
o trabalho de persistência.
15
É um framework para o mapeamento objeto-relacional escrito na linguagem Java.
16
Acrônimo em inglês para Java Authentication and Authorization Service. É a implementação da segurança e controle de acessos da máquina virtual java.
66
para receber os relatórios de eventos ocorridos com a respectiva etiqueta, serviço de encerramento de monitoração de etiqueta, serviço
de consulta de eventos ocorridos no EPCIS, serviço de atualização de
informações da localização de etiquetas na aplicação, e o serviço de
consulta de etiquetas monitoradas no contexto da aplicação.
– IlocateALEInit - Classe que contém o serviço responsável por configurar o módulo do middleware para envio de relatórios de eventos para o
host onde se encontra o módulo “GERADOR DE EVENTOS EPCIS”.
O serviço de configuração é automaticamente executado todas as vezes
que o servidor Tomcat é inicializado.
– IlocateALEReportListener - Classe responsável por implementar o papel definido no módulo “GERADOR DE EVENTOS EPCIS”. Ele
recebe de forma sı́ncrona os relatórios de eventos do middleware e
os transforma em relatórios que contenham sentido de negócio e em
seguida os envia para o EPCIS.
– IlocateEPCISReportListener - Classe responsável por receber de forma
assı́ncrona os relatórios de eventos advindos do EPCIS. Ela publica as
informações contidas nestes relatórios no contexto da aplicação, atualizando as informações de monitoração de etiquetas.
67
Figura 4.14: Diagrama de classes do módulo ILOCATEWEB.
68
Na Figura 4.15 é apresentado o modelo de dados utilizado para armazenar os
dados referentes ao módulo em questão.
69
Figura 4.15: Diagrama de modelo de dados do I-Locate.
70
A Figura 4.16 demonstra o diagrama de implantação dos componentes necessários
para executar os serviços do I-Locate.
4.4
Requisitos de infra-estrutura
A infra-estrutura da rede do HUB em que trafegam informações organizacionais
deve ser separada da rede RFID para que nã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 vão desde os leitores até o middleware. Esta
estrutura de rede é identificada como rede RFID dedicada e está esplanada no
item 3.2.4.1.
4.5
Apresentação do software I-Locate
Nesta seção é descrito o exemplo de uso do sistema I-Locate. Para acesso ao ILocate é necessário que o usuário esteja previamente cadastrado no mesmo. Este
teste é realizado utilizando-se a autenticação do usuário (Figura 4.17). Realizado
o login do usuário com sucesso, o usuário é redirecionado para a página de inı́cio
do I-Locate como indicado na Figura 4.18. Esta figura descreve a visão das
funcionalidades disponı́veis para usuários que detenham todos os perfis de acesso,
pois o sistema disponibiliza ao usuário somente as opções de serviços em que o
usuário está permitido a realizar. Logo, para usuários com diferentes perfis de
acesso, o menu principal altera o número de opções disponı́veis de acordo com a
permissão para execução das mesmas.
A Tabela 4.1, dispõe as opções disponı́veis de acordo com os perfis de acesso
existentes no sistema. A lista abaixo descreve as funcionalidades relacionadas
com as opções da Tabela 4.1.
As opções do menu principal são as seguintes:
• Opção 1: Gerenciar acesso a dependências fı́sicas;
• Opção 2: Gerenciar usuários;
• Opção 3: Gerenciar etiquetas;
• Opção 4: Administrar usuários do sistema;
• Opção 5: Administrar sistema;
Observa-se que os usuários com o perfil ILOC300 não possuem acesso a qualquer opção do sistema por se tratar de um perfil de acesso dependente do perfil
ILOC200 para funcionar. Isto ocorre por que o usuários com perfil ILOC300 são
uma extensão do perfil de acesso ILOC200.
A seguir são descritos os funcionamentos do menu.
71
Figura 4.16: Diagrama de implantação do módulo ILOCATE.
72
Figura 4.17: Tela de login do sistema.
Figura 4.18: Página inicial do I-Locate.
Perfil/Menu
ILOC100
ILOC200
ILOC300
ILOC400
ILOC500
Opção 1
Opção 2
X
X
Opção 3
X
Opção 4
Opção 5
X
X
Tabela 4.1: Acessibilidade das opões do menu principal do I-Locate.
73
4.5.1
Gerenciar acesso a dependências fı́sicas
Esta opção permite ao usuário do sistema gerir o registro de acesso às dependências
fı́sicas bem como monitorar a localização dos usuários que adentraram no HUB
através com o crachá do portador.
A Figura 4.19 demonstra o formulário em que é possı́vel inserir os dados do registro de acesso de um indivı́duo nas dependências do HUB. Este formulário muda
dinamicamente conforme o tipo de indivı́duo quanto a finalidade (funcionário, paciente, visitante, acompanhante). Preenchido os dados necessários, deve-se salvar
o registro de acesso apertando o botão “Salvar registro de acesso”.
Figura 4.19: Formulário de inserção de registro de acesso às dependências fı́sicas.
Nas ocasiões em que o usuário estiver saindo do HUB, é necessário buscar
o registro de acesso em aberto preenchendo-se o campo de código de etiqueta e
apertando-se em “Buscar registro de acesso existente”. Após, aperta-se no botão
“Encerrar registro de acesso”.
A Figura 4.20 mostra a aba de monitoração de etiquetas. Ela disponibiliza as
seguintes opções:
• Monitorar espaço fı́sico - Opção que permite monitorar todo o espaço fı́sico.
Os portadores da etiquetas identificados quando na entrada do HUB são representados nas dependências fı́sicas atravé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: Opções de monitoração de etiquetas RFID.
75
ı́cones, é possı́vel obter a breve descrição do registro de aceso do portador da
etiqueta. Etiquetas cujos portadores estão em estado irregular, isto é, local
indevido ou horário não permitido aparecem com um indicador vermelho
para facilitar ao usuário da aplicação a visualização da irregularidade.
• Localizar etiquetas - Esta opção permite ao usuário localizar a etiqueta pelo
seu código de sistema ou identificação do usuário. A Figura 4.22 demonstra
o formulário onde serão inseridos os dados requeridos para localização. Caso
seja localizada a etiqueta, é mostrado o ı́cone representando o portador da
etiqueta na respectiva localização fı́sica como mostra a Figura 4.23.
• Relatório de monitoração de etiquetas - Esta opção está disponı́vel somente
para usuários que contem o perfil de acesso ILOC300. Ela permite gerar
relatórios de monitoração de etiquetas de acordo com os critérios de geração.
A Figura 4.24. mostra um exemplo de relatório gerado.
Figura 4.21: Monitoração de usuários no espaço nas dependências fı́sicas.
4.5.2
Gerenciar usuários
Esta opção permite gerenciar os usuários cadastrados no sistema. Ela oferece
as opções de pesquisa, criação, atualização e exclusão de registros de usuários
utilizados pelo sistema para registro de acesso. A Figura 4.25 mostra o formulário
com os campos providos para tais finalidades.
76
Figura 4.22: Formulário para localização de etiquetas.
77
Figura 4.23: Resultado para a busca de etiquetas.
4.5.3
Gerenciar etiquetas
Esta opção permite gerenciar as etiquetas RFID cadastrados no sistema. Ela
oferece as opções de pesquisa, criação, atualização e exclusão de registros de
etiquetas. A Figura 4.26 mostra o formulário com os campos providos para tais
finalidades.
4.5.4
Administrar usuários do sistema
Esta opção permite gerenciar os usuários do sistema bem como seus respectivos
perfis de acesso no sistema. Ela oferece as opções de pesquisa, criação, atualização
e exclusão de registros de usuário do sistema. A Figura 4.27 mostra o formulário
com os campos providos para tais finalidades.
4.5.5
Administrar sistema
Esta opção tem a finalidade de prover funcionalidades utilitárias acerca dos módulos
externos ao ILOCATEWEB. A Figura 4.28 mostra as funcionalidades disponı́veis
nesta opção.
• Informações sobre etiquetas detectadas no sistema - Esta opção exibe os
valores atualizados das etiquetas que foram detectadas pelo sistema, Figura
78
Figura 4.24: Formulário para geração de relatórios de ocorrências de monitoração
de etiquetas.
79
Figura 4.25: Gerenciamento de usuários cadastrados no sistema.
80
Figura 4.26: Gerenciamento de etiquetas cadastrados no sistema.
81
Figura 4.27: Administração dos usuários do sistema.
82
Figura 4.28: Administração do sistema.
83
4.28. Este valores são os mesmos utilizados para localizar etiquetas no
sistema e tem a finalidade de depurar o funcionamento de tal funcionalidade.
• Conexões - Esta opção tem a finalidade de exibir de forma gráfica as conexões
entre os leitores fı́sicos, lógicos, especificações de relatórios registrados no
middleware e o host para o qual deve ser enviadas as informações dos relatórios. A Figura 4.29 demonstra um exemplo de utilização deste opção.
Figura 4.29: Opção Conexões do menu Administrar sistema.
• hosts Inscritos - A finalidade desta opção é de apresentar todos os hosts
inscritos para recebimento de relatórios de eventos de detecção de etiquetas
realizadas pelo middleware de acordo com a especificação do relatório. A
Figura 4.29 demostra um exemplo de utilização desta opção.
• Especificações de relatórios - Esta opção tem a finalidade de demonstrar
todas as especificações de relatórios que estão registradas no middleware.
Um exemplo de utilização desta opção é exibida na Figura 4.31.
• Leitores Lógicos - Esta opção tem a finalidade adicionar, remover e visualizar os leitores lógicos reconhecidos no middleware, Figura 4.32. Para
adicionar um novo leitor lógico é necessário conectá-lo com um dependê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 recepção de eventos do middleware.
85
Figura 4.31: Especificações de relatórios de eventos.
86
Figura 4.32: Leitores lógicos.
87
• Leitores Fı́sicos - Esta opção tem a finalidade adicionar, remover e visualizar
os leitores fı́sicos reconhecidos no middleware, além de conectar e desconectar os leitores fı́sicos com leitores lógicos, Figura 4.33. Para adicionar um
novo leitor fı́sico é necessário informar os dados do leitor fı́sico como por
exemplo o identificador, a marca, o modelo e o endereço IP do mesmo.
Para remover um leitor fı́sico basta selecioná-lo na lista de leitores fı́sicos
existentes.
Figura 4.33: Leitores fı́sicos.
A opção de conectar um leitor fı́sico a um lógico permite agrupar leitores
fı́sicos com o mesmo sentido de negócio em um só leitor lógico. Já a opção
de desconectar um leitor fı́sico de um lógico tem a finalidade de desagrupar
o leitor fı́sico de um grupo lógico.
4.5.6
Considerações finais
Para a correta execução do software na parte cliente, é indicado o explorador
de internet Mozilla Firefox na versão 2.0.0, pois na presente data a mais
nova versão do mesmo explorador, versão 3.0.0, não dava suporte à execução
dos serviços do I-Locate de forma satisfatória.
88
Capı́tulo 5
Conclusão
O principal objetivo do trabalho foi desenvolver um software para auxiliar o
controle e monitoração de acesso de usuário no HUB utilizando a tecnologia RFID.
Para isso foi necessário um estudo aprofundado da RFID bem como os elementos
de uma rede RFID proposto pela EPCGlobal. Além disso, foi necessário investigar
os processos de negócio existentes, por meio de pesquisas e entrevistas, no HUB
para que a especificação dos requisitos funcionais do software pudesse ser definida.
O resultado de tais estudos foi a elaboração o sistema I-Locate, que utiliza a
tecnologia RFID para localização de pessoas nas dependências fı́sicas do hospital.
Sua arquitetura obedece ao padrão de arquitetura especificado pela EPCGlobal, o que lhe garante credibilidade neste ponto de vista. Na visão de atendimento aos requisitos funcionais, o sistema atende plenamente todos os requisitos
definidos sendo uma proposta pronta para uso exceto pelo fato da ausência da implementação adaptadores para os leitores fı́sicos, os quais deveriam ser escolhidos
pelo próprio HUB no momento da implantação.
Caso fosse implantado em situações reais, este sistema refletiria na redução da
quantidade de agentes de segurança que necessitem monitorar as dependências
fı́sicas, além de assegurar maior organização e confiabilidade dos dados dos registros de acesso, permitindo inclusive auditoria por parte do sistema, uma vez que
os registros de acesso não podem ser excluı́dos por nenhum usuário do sistema.
5.1
Trabalhos futuros
Abaixo são apresentadas algumas funcionalidades e caracterı́sticas que podem ser
adicionadas ao sistema I-Locate conforme a maturação do software.
• Auditoria de registro de monitoração de eventos de etiquetas na forma
gráfica: Atualmente o sistema oferece este serviço, entretanto ele disponibiliza os resultados em forma de tabela. Uma forma de representação gráfica
desta mesma funcionalidade permitia melhor visualização da auditoria por
parte dos usuário do sistema.
• Interoperabilidade das funcionalidades do sistema I-Locate com o sistema
de registro de pacientes existentes no HUB. É de grande valia disponibilizar
um serviço SOAP para que os sistemas informatizados no HUB pudessem
89
registrar os pacientes que estão atualmente nas dependências fı́sicas. Com a
implementação deste item seria possı́vel consultar a localização do paciente
no hospital por meio de outros sistemas.
• Implementação de um caso de uso para atualizar a regularidade de do
usuário que está em horário irregular, isto é, se o usuário ultrapassar da
hora estimada o agente de segurança poderá atualizar a hora prevista para
saı́da se julgar necessário.
• Implementaçã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. É de grande utilidade
implementar o adaptador do driver nativo do leitor para que o sistema se
torne realmente funcional.
• Implementação de serviços de monitoração de objetos para o HUB: O sistema foi projetado para monitorar somente pessoas que adentrassem nas
dependências do hospital. Um serviço de monitoração de objetos seria de
grande importância, pois o ambiente hospitalar possui uma grande variedade de objetos pequenos, porém valiosos, visando aumentar a segurança
do recinto contra furtos dos objetos citados.
• Generalização da estrutura da rede RFID e o sistema de controle e monitoração de acesso propostos neste trabalho para que seja aplicada a qualquer
organização que queira utilizar tais serviços.
• Criação de procedimentos que evitem a separação fı́sica do portador da
etiqueta da mesma quando o portador tiver o registro de acesso aberto, para
que não seja possı́vel passar a etiqueta a outro portador mal intencionado.
90
Capı́tulo 6
Anexo
6.1
Detalhamento da especificação dos casos de
uso do sistema I-Locate
Usuário do sistema
Descrição do ator: Qualquer usuário do sistema será 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 usuá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 pré-definidos para o ator:
- ILOC100: Gerenciador de etiquetas précadastradas.
- ILOC200: Funcionário genérico da segurança do
hospital.
- ILOC300: Supervisor da segurança.
- ILOC400: Suporte té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 usuário está
com o perfil ativo no sistema;
3. Sistema redireciona usuário para página de
serviços do sistema;
91
Nome do caso de uso
Objetivo
Fluxo principal
Alterar senha de acesso
Alterar a senha do usuário do sistema;
1. Ator insere login, senha atual, nova senha e
a confirmação para a nova senha;
2. Sistema valida os dados de entrada e altera
a senha do usuário;
Gerenciador de etiquetas RFID
Descrição do ator: Pessoa responsável por manter informações no sistema acerca das etiquetas utilizadas no processo de controle e monitoração de usuários
que adentram no HUB, já que o sistema somente irá monitorar etiquetas previamente registradas por este ator.
Nome do caso de uso
Objetivo
Incluir registro de etiqueta
Inserir informações de uma nova etiqueta no sistema;
Fluxo principal
1. Ator insere informações sobre a etiqueta:
código EPC, marca, modelo;
2. O sistema grava as informações caso o
código EPC da etiqueta não existir e se nenhum dos campos informados não estiver em
branco;
92
Nome do caso de uso
Objetivo
Pesquisar registro de etiquetas
Pesquisar registros de etiquetas que estão
cadastradas no sistema.
Fluxo principal
1. Ator insere informações sobre a etiqueta:
código EPC, marca, modelo ou có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 informações de etiquetas previamente
cadastradas no sistema.
Fluxo principal
1. Ator pesquisa a etiqueta a ser atualizada;
2. Ator altera o código EPC, marca ou modelo
da etiqueta;
3. Sistema registra as alterações somente se
nenhum dos campos está em branco;
93
Nome do caso de uso
Objetivo
Remover registro de etiqueta
Excluir um registro de etiqueta previamente
cadastrado no sistema. Observação: Só será
possı́vel realizar este caso de uso caso o registro
da etiqueta não estiver sendo utilizado pelo sistema, isto é, não possuir dependê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 não
possua registros relacionados com o registro
de acesso de usuários gravados até o momento da exclusão;
Funcionário da segurança HUB
Descrição do ator: Usuário cuja finalidade é de controlar o acesso as dependências fı́sicas autorizando, denegando o acesso fı́sico dos usuários interessados ao HUB.
94
Nome do caso de uso
Objetivo
Incluir interessado
Incluir informações de identificação do usuário interessado no sistema.
Fluxo principal
1. Ator insere informações sobre o interessado
de acordo com o tipo de interessado:
-Usuário casual: O nome, sobrenome,
idade, sexo, código da identificação e tipo
de identificação;
-Funcionário: O nome, sobrenome, idade,
sexo, código da identificação, tipo de identificação e telefone;
-Paciente: O nome, sobrenome, idade, sexo,
código da identificação, tipo de identificação
e se o paciente possui convênio com o HUB;
2. O sistema registra as informações caso não
exista registro de usuário interessado com
o mesmo código de identificação e tipo de
identificação;
Nome do caso de uso
Objetivo
Pesquisar interessados
Pesquisar usuário interessados existentes no sistema.
Fluxo principal
1. O ator insere para cada tipo de usuário:
- Usuário casual: o nome, sobrenome, idade,
sexo, código da identificação ou o tipo de
identificação;
- Funcionário: O nome, sobrenome, idade,
sexo, código da identificação, tipo de identificação ou o telefone;
- Paciente: O nome, sobrenome, idade,
sexo, código da identificação e se o paciente
possui convênio com o HUB;
2. O sistema pesquisa todos os registros de
usuários que satisfaçam os critérios de consulta;
95
Nome do caso de uso
Objetivo
Atualizar dados do interessado
Atualizar as informações de usuários interessados
no sistema.
Fluxo principal
1. O ator pesquisa o usuário cujos dados serão
atualizados;
2. O ator seleciona o usuário a ser atualizado;
3. O ator modifica os dados do usuário conforme o tipo:
- Usuário casual: o nome, sobrenome, idade,
identificação;
- Funcionário: O nome, sobrenome, idade,
- Paciente: O nome, sobrenome, idade,
sexo, código da identificação e se o paciente
possui convênio com o HUB;
4. O sistema atualiza os dados do usuário
caso nenhum dos campos for vazio;
Nome do caso de uso
Objetivo
Excluir interessado
Excluir registro de interessados do sistema. Observação: Só será possı́vel realizar este caso de uso
caso o registro do usuário interessado não estiver
sendo utilizado pelo sistema, isto é, não possuir
dependência com outros registros no sistema.
Fluxo principal
1. O ator pesquisa o usuário cujos dados serão
excluı́dos;
2. O ator seleciona o usuário a ser excluı́do;
3. O Ator indica ao sistema para remover o
usuário selecionado;
4. O sistema remove o usuário indicado caso
o usuário não possua nenhum registro de
acesso até o momento da exclusão;
96
Nome do caso de uso
Objetivo
Monitorar usuários
Monitorar localização e regularidade dos usuários
que têm o registro de acesso aberto no HUB. A irregularidade deverá ser refletida graficamente nas
dependências fı́sicas não autorizadas ou horá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
usuários atualmente nas dependências do
hospital que portam a etiqueta RFID;
3. O sistema alerta ao usuário do sistema caso
algum ı́cone esteja fora da dependência ou
horário autorizado;
Nome do caso de uso
Objetivo
Consultar localização de usuário
Consulta a atual localização fı́sica do usuá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, código
de sistema da etiqueta que o usuário porta
ou código de identificação e tipo de identificação do usuário do HUB;
2. O sistema retorna uma lista de todos os registros de acesso em aberto que satisfaçam os
critérios de consulta;
3. O ator seleciona o registro de acesso para
qual deseja localizar o usuário;
4. O sistema exibe na forma de ı́cone a localização atual do usuá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 informações de identificação do
usuário do HUB, as dependências fı́sicas autorizadas, o horário estipulado para saı́da, o código
da etiqueta RFID utilizada e informações adicionais que variam de para o tipo de usuário. A
partir desta funcionalidade o sistema irá começar
a registrar os eventos de monitoração nas localizações em que a etiqueta for detectada.
Fluxo principal
1. O ator insere o código de sistema da etiqueta que o interessado irá portar se for autorizado a entrar;
2. O ator pesquisa o tipo de interessado para
adentrar no hospital que poderá ser:
- Usuário casual: pesquisa pelo nome, sobrenome, idade, sexo, código de identificação e tipo de identificação;
- Acompanhante de pacientes: pesquisa
pelo nome, sobrenome, idade, sexo, código
de identificação e tipo de identificação;
- Visitante de paciente: pesquisa pelo nome,
sobrenome, idade, sexo, código de identificação e tipo de identificação;
- Funcionário: pesquisa pelo nome, sobrenome, idade, sexo, código de identificação e tipo de identificação e telefone;
- Paciente: pesquisa pelo nome, sobrenome,
idade, sexo, código de identificação, tipo de
identificação e o estado de convênio;
3. O ator escolhe as dependências fı́sicas autorizadas que o interessado poderá transitar;
4. O ator insere o horário e data prevista para
saı́da do interessado;
5. O ator insere as observações que julgar
necessária acerca do registro de acesso;
98
Fluxo principal (Cont.)
6. O sistema valida os dados de entrada, isto
é, verifica se são verdadeiros caso o interessado seja:
- Paciente: verifica se o nome, sobrenome,
idade, sexo código da identificação e tipo
de identificação não são vazios e se são
verossı́meis;
- Funcionário: verifica se o nome, sobrenome, idade, sexo, código da identificação e tipo de identificação não são
vazios e se são verossı́meis;
- Usuário casual: verifica se o nome, sobrenome, idade, sexo, código da identificação e tipo de identificação não são
vazios e se os dados do funcionário autorizante e do usuário casual sã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
são verossı́meis;
- Visitante de paciente: verifica que o
número de visitante para o paciente em
questão não é o máximo e se os dados do
visitante sã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
usuário nas dependências fı́sicas do HUB, o qual
deverá ser feito na saı́da do usuário do HUB. A
partir dessa funcionalidade o sistema não irá mais
monitorar a etiqueta em questão.
Fluxo principal
1. O ator insere o código de identificação do
sistema da etiqueta;
2. O sistema pesquisa os registros que contém
o código de etiqueta em questão e se existem
registros em aberto para a mesma;
3. O sistema retorna os dados do registro de
acesso gravados na entrada do usuário interessado;
4. O ator encerra o registro de acesso;
100
Nome do caso de uso
Objetivo
Consultar registro de interessado existente
Pesquisar usuários interessados registrados no sistema.
Fluxo principal
1. O ator insere os dados do usuário interessado, os quais variam para o tipo de interessado:
2. Usuário casual: o nome, sobrenome, idade,
identificação;
3. Funcionário: O nome, sobrenome, idade,
4. Paciente: O nome, sobrenome, idade, sexo,
código da identificação e se o paciente possui convênio com o HUB;
5. O sistema pesquisa o usuário interessado
cujos registros satisfaçam os critérios de
consulta;
6. O sistema exibe o resultado da consulta;
Supervisor da equipe de segurança do HUB
Descrição do ator: Usuário supervisor da equipe de segurança do hospital cuja
finalidade é de auditar os registros de monitoração quanto a regularidade da localização e horário dos portadores das etiquetas.
101
Nome do caso de uso
Objetivo
Consultar relatório de monitoração
Pesquisa os registros de monitoração de etiquetas
no HUB.
Fluxo principal
1. O ator insere os critérios de consulta: data
de inı́cio da monitoração, data do fim da
monitoração, número do código de sistema
da etiqueta, regularidade da ocorrência do
evento de monitoração, ou a dependência
fı́sica em que ocorreu a monitoração.
2. O sistema pesquisa os registros de acesso
que satisfaçam os critérios de consulta;
3. O sistema exibe resultado da consulta;
Suporte técnico do sistema
Descrição do ator: Responsável por realizar suporte técnico do sistema. Este
ator é responsável pelas configurações do middleware, EPCIS e do mó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. Observação: Entende-se por leitores
fı́sicos, os leitores RFID fisicamente localizados
nas dependê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 informações: Marca do leitor,
modelo do leitor, endereç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
serão gerenciados pelo middleware. Observação:
Entende-se por leitores fı́sicos, os leitores RFID
fisicamente localizados nas dependências fı́sicas
do HUB e se conectam ao middleware
Fluxo principal
1. O ator insere informações do leitor fı́sico:
Marca do leitor, modelo do leitor, endereç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. Observação: Entende-se por
leitores fı́sicos, os leitores RFID fisicamente localizados nas dependê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 lógico
Conectar um leitor fı́sico a um leitor lógico.
Esta conexão é necessária para agrupar todos os
leitores fı́sicos com o mesmo sentido de negócio
em um só leitor lógico. O leitor lógico por sua vez
é configurado no middleware RFID do sistema.
Fluxo principal
1. O ator insere o nome do leitor fı́sico e o
nome do leitor lógico existente para o qual
o leitor fı́sico fará parte;
2. O sistema conecta o leitor fı́sico ao leitor
lógico;
103
Nome do caso de uso
Objetivo
Fluxo principal
Desconectar leitor fı́sico com leitor lógico
Desconecta um leitor fı́sico de um leitor lógico.
1. O ator insere o nome do leitor fı́sico e o
nome do leitor lógico existente para o qual
o leitor fı́sico faz parte;
2. O sistema separa a ligações do leitor fı́sico
do leitor lógico;
Nome do caso de uso
Objetivo
Incluir leitor lógico
Incluir um leitor lógico no sistema e relaciona-lo
com uma dependência fı́sica.
Fluxo principal
1. O ator insere a identificação do leitor lógico
e a dependência fı́sica que o leitor representará;
2. O sistema atualiza as informações na base
de dados;
Nome do caso de uso
Objetivo
Excluir leitor lógico
Excluir um leitor lógico do sistema e suas ligações
com a dependência fı́sica e os leitores fı́sicos relacionados.
Fluxo principal
1. O ator insere a identificação do leitor lógico
a ser excluı́do;
2. O sistema remove o leitor lógico da base de
dados;
104
Nome do caso de uso
Objetivo
Pesquisar todos os leitores lógicos
Pesquisar todos os leitores lógicos existentes no
sistema e suas respectivas ligações com as dependências fı́sicas.
Fluxo principal
1. O sistema pesquisa todos os leitores lógicos
existentes no middleware.
2. O sistema exibe todos os leitores lógicos encontrados bem como a sua respectiva dependência e os leitores fı́sicos conectados a
ele;
Nome do caso de uso
Pesquisar todas as especificações de relatórios de
eventos no middleware.
Objetivo
Pesquisar todos os relatórios de eventos de etiquetas registrados no middleware. Estes relatórios
definem quais dados serão enviados ao cliente inscrito quando uma etiqueta for detectada pelo
leitor lógico.
Fluxo principal
1. O sistema insere todas as especificações de
relatórios que o middleware está destinado a
gerar quando alguma etiqueta for detectada
pelos leitores fı́sicos;
2. O sistema exibe todas as especificações encontradas, bem o respectivo arquivo XML
definindo a mesma;
105
Nome do caso de uso
Objetivo
Pesquisar hosts inscritos para recepção de relatórios do middleware
Pesquisar os hosts inscritos para receberem os relatórios definidos segundo a especificação dos relatórios do middleware.
Fluxo principal
1. O sistema pesquisa o hosts inscritos para
recepção de relatórios de eventos do middleware;
2. O sistema exibe as informações na tela;
Nome do caso de uso
Pesquisar nó de conexões do middleware para envio de eventos
Objetivo
Mostrar de maneira gráfica as conexões dos
leitores fı́sicos para o lógico e do lógico para os
hosts inscritos a receberem informações acerca de
eventos gerados pelo leitor fı́sico definido na especificação de relatório.
Fluxo principal
1. O sistema pesquisa informações acerca de
conexões entre os leitores fı́sicos, leitores
lógicos, especificações de eventos do middleware e o host de destino para cada relatório;
2. O sistema
pesquisa;
Nome do caso de uso
Objetivo
existe
as
informações
da
Pesquisar etiquetas monitoradas pelo sistema
Pesquisar os últimos eventos gerados pelas presenças das etiquetas nas dependências fı́sicas do
HUB.
Fluxo principal
1. O sistema pesquisa os últimos eventos de
etiquetas monitoradas detectada pelo sistema;
2. O sistema exibe as informações na tela;
Gestor do sistema
106
Descrição do ator: Responsável por gerir os usuários e seus respectivos perfis
de acesso ao sistema.
Nome do caso de uso
Objetivo
Incluir usuário de sistema
Incluir um novo usuário do sistema e definir seu
perfil de acesso.
Fluxo principal
1. O ator insere as informações sobre o usuário
do sistema a ser incluı́do: nome, sobrenome,
idade, sexo, código de identificação, tipo de
identificação, login, a informação de se o
usuário está ativo no sistema e os perfis de
acesso;
2. O sistema insere o usuário em questão se
não existirem usuários no sistema que tenham o mesmo código de identificação e o
mesmo tipo de identificação;
Nome do caso de uso
Objetivo
Fluxo principal
Pesquisar usuário do sistema
Pesquisar os usuários existentes no sistema.
1. O ator insere as informações de pesquisa:
nome, sobrenome, idade, sexo, código de
identificação, tipo de identificação e o login;
2. O sistema pesquisa os registros de usuários
do sistema que satisfaçam os critérios de
consulta;
3. O sistema existe o resultado na tela;
107
Nome do caso de uso
Objetivo
Atualizar cadastro de usuário do sistema
Atualizar os cadastros dos usuários do sistema existentes.
Fluxo principal
1. O ator pesquisa o usuário de sistema;
2. O ator indica o usuário de sistema a ser atualizado;
3. O ator modifica o nome, sobrenome, sexo,
idade, informação de se o usuário está ativo
no sistema;
4. O sistema atualiza as informações do
usuário interessado em questão se o código
de identificação e o tipo de identificação existir no sistema;
Nome do caso de uso
Objetivo
Excluir usuário do sistema
Exclui um registro do usuário do sistema existente. Observação: Só será possı́vel realizar este
caso de uso caso o registro do usuário do sistema
não estiver sendo utilizado, isto é, não possuir dependência com outros registros no sistema.
Fluxo principal
1. O ator pesquisa o usuário do sistema;
2. O ator indica o usuário de sistema a ser excluı́do;
3. O sistema exclui o usuário de sistema selecionado se o mesmo não tiver registros de
acesso, de acompanhamento, de visita ou de
autorização de entrada de usuários casuais
gravados até o momento da exclusão;
108
Referê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.
Página 14.
[Davi Silva, 2006] Davi Silva, A. V. (2006). Modelagem de processos organizacionais - controle de acesso de pessoas no hospital universitário de brası́lia.
Dept. Ciências da Computaçã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 informaçã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 Informação Gerenciais.
Pearson Education.
109
[Maximiano, 1995] Maximiano, A. C. A. (1995). Introdução à Administraçã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 Conclusão de Curso
(Bacharelado em Sistemas de Informação) Centro Universitário de Votuporanga. Votuporanga, São Paulo - Brasil.
[teleco, 2008] teleco
(2008).
Rfid:
http://www.teleco.com.br/tutoriais/tutorialrfid2/pagina 3.asp.
Aplicaçõ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

ver/abrir - Repositório do Departamento de Ciência da Computação

Transcrição

Documentos relacionados

bibliotheca selfCheck™ Components

Smart Shelf: base para integrar os cartuchos de tinta HP com a

Preparatório CompTIA RFID+

Testador Ultrasom Intrinsicamente Seguro UT5000

Manual de etiquetas para viajantes

Sabesp faz conferência de hidrômetros com agilidade e segurança

Fra-TV - InfoBrasil

pulseira de radiofrequência de silicone chips de 125 khz e de 13.56

Controlo de Acessos_CA.120

Juno T41 R Handheld Computer