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
Instituto de Ciências Exatas
Departamento de Ciência da Computação
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.
101 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:
Universidade de Brası́lia
Campus Universitário Darcy Ribeiro – Asa Norte
CEP 70910–900
Brası́lia – DF – Brasil
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
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, 06 de Dezembro de 2008
Agradecimentos
Agradeço, restritivamente, a Deus pela força e saúde que me constituem.
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 nela transitam, isto é, o controle de acesso fı́sico às suas dependências.
Com mesma importância, certificar-se de que cada um dos usuários transitantes, dentre pacientes, médicos, visitantes, funcionários e colaboradores, 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. Esta equipe é responsável pelo
zelo do patrimônio hospital e age proativamente contra qualquer de adversidade
que possa colocar em risco a ordem do estabelecimento. Neste sentido, há dificuldades implı́citas 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 dentro
de um hospital querer a disponibilização de pelo menos um agente para observálo. 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 estariam de fato sendo monitorados.
O presente trabalho propõe um sistema informatizado que cujo o objetivo é
auxiliar o controle e garantia da acesso de pessoas aos diversos espaços fı́sicos que
constituem o HUB - Hospital Universitário de Brası́lia. A solução proposta baseiase na utilização da tecnologia de identificação por rádio frequência, RFID. Em se
tratando deste elemento, a tecnologia RFID, 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
Sumário
Capı́tulo 1 Introdução
8
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 . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
11
11
15
16
Capı́tulo 3 Fundamentação Teórica
3.1 A tecnologia RFID . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 A História da RFID . . . . . . . . . . . . . . . . . . . . .
3.1.3 A Arquitetura da tecnologia RFID . . . . . . . . . . . . .
3.1.4 Padrão EPCGlobal . . . . . . . . . . . . . . . . . . . . . .
3.1.5 Redes RFID Distribuı́das . . . . . . . . . . . . . . . . . . .
3.1.6 Aplicações da tecnologia de identificação por rádio frequência
3.1.7 Computação Ubı́qua . . . . . . . . . . . . . . . . . . . . .
18
18
18
18
20
26
29
36
37
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 Apresentação do software I-Locate . . . . . . . .
4.4.1 Gerenciar acesso a dependências fı́sicas .
4.4.2 Gerenciar usuários . . . . . . . . . . . .
4.4.3 Gerenciar etiquetas . . . . . . . . . . . .
4.4.4 Administrar usuários do sistema . . . . .
4.4.5 Administrar sistema . . . . . . . . . . .
43
43
47
47
48
66
66
69
69
73
73
75
80
82
85
90
90
90
acesso:
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
I-Locate
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Capı́tulo 5 Conclusão
5.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . .
Referências
98
98
100
7
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 Hospital Universitário de Brası́lia (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 as 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
8
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 Hospital Universitário de
Brası́lia. 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.
9
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 Hospital Universitário de Brası́lia - HUB - atualmente carece de um controle
eficaz deste processo, conforme levantamento e estudo apresentado em
10
[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 Hospital Universitário de Brası́lia (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 1990, foi cedido à Universidade de Brası́lia
(UnB) em ato assinado pelo Presidente Fernando Collor e passou a se chamar
Hospital Universitário de Brası́lia (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.
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
11
Figura 2.1: Visão áerea do HUB.
Figura 2.2: Visão frontal do HUB.
12
Figura 2.3: Estrutura organizacional do HUB.
13
pela reitoria, tem-se o conselho deliberativo o qual compete promover o relacionamento institucional do HUB com as atividades que a ele compete. Subordinado ao
conselho deliberativo tem-se a diretoria cuja responsabilidade 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 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 efetiva 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.
Atualmente não existe controle de acesso neste complexo sendo a entrada para
funcionários, visitantes ou pacientes. 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
14
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 para 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 Hospital
Universitário de Brası́lia.
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
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,
15
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
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
de identificação por rádio frequência, ou seja, 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
16
existentes com a integração da tecnologia RFID. Além, da arquitetura do software será apresentada a interface final com usuário e a documentação dos casos
de usos pertinentes às funcionalidades oferecidas pelo sistema.
17
Capı́tulo 3
Fundamentação Teórica
3.1
3.1.1
A tecnologia RFID
Introdução
A tecnologia de RFID (Radio Frequency Identification - identificação por rádio
frequência) 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 de 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
computacionais 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.1.2
A História da RFID
A história da tecnologia RFID pode ser descrita segundo as indicações em
[RfiIdJournal, 2007] e [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 freqüência, boa parte é devida a, 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,
18
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 que o
avião era 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
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 dispositivo 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.
19
3.1.3
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[Himanshu Bhatt, 2006a]. Esta ação, no
contexto do sistema de informação que a utiliza, desencadeia 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.1.3.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, etiquetas, chips, ou rótulos. De maneira geral, uma etiqueta de RFID
podem 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.
20
Etiquetas Ativas
Em contraposição à idéia 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 ser alimentadas
por um campo próximo gerado pela antena do leitor podendo por conseqüência
transmitir e receber a maiores distâncias do que as etiquetas 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 e 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.1 a 3.5 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
21
Figura 3.1: Etiquetas RFID diversas
Figura 3.2: Etiquetas RFID em uma carcaça de plástico
22
Figura 3.3: Etiqueta em formato de cartão de crédito (Smart Card)
Figura 3.4: Chip RFID embutido em relógios
Figura 3.5: Chips RFID em braceletes
23
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, freqüências que foram
reservadas especificamente para aplicações industriais, cientı́ficas ou médicas como
como frequência de operação das etiquetas RFID. Tais freqüências são conhecidas
como faixa de freqüência ISM (Industrial-Scientific-Medical). As tabelas 3.1 e 3.2,
sumarizam as faixas de freqüê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.1: Classificação de raios de frequências para dispositivos RFID
[Himanshu Bhatt, 2006b].
O raio da leitura em função das freqüê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.2: Raio máximo de leitura para etiquetas passivas de acordo com a
freqüência [Himanshu Bhatt, 2006b].
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[Himanshu Bhatt, 2006c].
24
3.1.3.2
Leitor
O segundo componente básico de um sistema RFID é chamado de leitor ou interrogador.
Figura 3.6: Exemplo de leitor RFID
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
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 transmite 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.7) .
Figura 3.7: Organização lógica de um leitor
3.1.3.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.
25
A figura 3.8 demonstra a visão lógica da arquitetura de um middleware para
sistemas RFID:
Figura 3.8: Arquitetura de um middleware para sistemas RFID
Um middleware para um sistema RFID 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;
• 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.1.4
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. Acomoda as informações do GTIN - Identificador Global de
Item Comercial, que identifica os produtos no Sistema GS1.
• 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.
26
• Leitor de Radiofreqüê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
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: Sistema de informação 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.1.3.2 e
3.1.3.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 (Eletronic Product Code) os quais são
definidos por entidades especı́ficas, que possuem as classes de objetos fı́sicos envolvidos. A tabela 3.3 mostra as diferentes classificações das etiquetas reconhecidas pela ECPGlobal:
Classe
Classe
Classe
Classe
Classe
Classe
0
1
2
3
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 ativa com leitores e outras etiquetas ativas.
Todas funcionalidades da classe 4 somadas a capacidade de comunicação com etiquetas passivas. Conceitualmente leitoras.
Tabela 3.3: Classes de etiquetas do padrão EPCGlobal[Himanshu Bhatt, 2005]
Código eletrônico de produtos - EPC
27
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:
•
•
•
•
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
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).
28
Serviço de nomeação de objetos
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 seqüência de bits em URI (identificador uniforme
de recursos);
3. Depois de convertida a seqüê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.1.5
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.9). 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.10.
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.
29
Figura 3.9: Sistema RFID centrado na aplicação
Figura 3.10: Sistema RFID centrado na rede.
30
3.1.5.1
Elementos da concepção de redes RFID distribuı́das
Redes Dedicadas e Amontoadas
Todos os objetos exceto para a aplicação RFID A, B e middleware na porção
superior da figura 3.10 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
expansabilidade 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.11, 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.12, 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.
Figura 3.11: Arquitetura amontoada.
31
Figura 3.12: Arquitetura dedicada.
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.
32
Arquitetura
Facilidade
Sub-redes
VLAN
Tratamento de segurança na sobrecarga
de tráfego
Escalabilidade
Tabela 3.4:
Principais
RFID[Yi Zhi Zhao, 2007].
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
caracterı́sticas
33
das
Dedicada
Disponibilidade
de
portas no switches 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 por M/W no
interior da rede RFID,
ou por roteadores do
tipo firewall dedicados.
Flexı́vel
arquiteturas
de
rede
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 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.5 mostra uma amostra de um EPC de 96 bits.
Assumindo-se que o EPC é a única coisa armazenada no chip, e por conseqüência, é o único dado que é passada da etiqueta para o leitor, o leitor tem
34
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
subseqüentes
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.5: 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
35
nesta camada deve ser quantificado de acordo com a especificação da aplicação.
3.1.6
Aplicações da tecnologia de identificação por rádio
frequência
Por conseqüê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 radiofreqüê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.1.6.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 microchipes RFID contidos no cartão de ingresso
emitem um sinal de rádio que é captado por leitores on-line nas entradas dos
estádios[theregister, 2008b].
Na área médica, é a identificação humana através de microchipes 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
36
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[Finkenzeller, 2003a], além da bilhetagem, etiquetas são
utilizadas também em corridas, aplicadas no cadarço dos corredores, figura 3.13
para saber com exatidão o tempo percorrido. Este tipo de aplicação torna-se util
principalmente em provas onde a quantidade de corredores é muito grande.
Figura 3.13:
Uma etiqueta
corrida[Finkenzeller, 2003b].
3.1.7
Computação Ubı́qua
3.1.7.1
Apresentação
afixada
em
cadarço
de
tênis
de
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
37
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
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 freqüentemente um foco de atenção, e, por vezes, um obstáculo
a esse trabalho ([Mark Weiser, 1993]). Baseado nessas questões, em 1988 Mark
Weiser e vários de seus companheiros do PARC elaboraram as primeiras idéias 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, 1996] 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
38
canetas, roupas, relógios, portas e cadeiras.
A miniaturização do computador e a diminuição dos custos de seus componentes 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 idéia 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 [Mark Weiser, 1993].
Nesse artigo, os autores descrevem a utilização de sensores de localização (que
utilizam a tecnologia RFID, a ser descrita mais adiante neste trabalho) 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].
3.1.7.2
Computação Móvel, Computação Pervasiva e Computação Ubı́qua
A Computação Ubı́qua possui uma forte relação com outras áreas de pesquisa:
a Computação Móvel e a Computação Pervasiva. De fato, elas são por vezes
confundidas entre si, e é comum que a Computação Ubı́qua seja chamada de
pervasiva ou móvel. Existem, porém, diferenças entre esses conceitos, conforme
[de Araújo, 2003]:
39
Computação Móvel
A Computação Móvel tem por princı́pio garantir que um determinado dispositivo computacional possa ser movido fisicamente de um ponto A para um ponto
B sem que perca suas funcionalidades. É a tecnologia aplicada em notebooks e
telefones celulares, por exemplo, e, aliada à popularização do acesso wireless à internet, é capaz hoje de permitir que computadores sejam deslocados por grandes
distâncias e ainda assim possam ser utilizados plenamente.
A Computação Móvel tem por limitação o fato de não permitir uma reconfiguração dinâmica do contexto em que se encontra, por questões de segurança
e limitação de hardware. Além disso, a Computação Móvel compartilha alguns
obstáculos com a Computação Ubı́qua, a se destacar as limitações atuais nas tecnologias de baterias e outras fontes de alimentação de energia.
Computação Pervasiva
A Computação Pervasiva é baseada na capacidade de um computador de interagir com o ambiente à sua volta, e dele retirar informações que permitam
reconfigurar dinamicamente uma aplicação que ele execute ou outro dispositivo
que esteja inserido nesse ambiente, de modo a ajustar o serviço prestado para um
determinado usuário. Essa propriedade é o que permite a pró-atividade e a adaptabilidade de um computador em um determinado ambiente, e é o que torna um
computador pervasivo ”inteligente”. Segundo os fundamentos da Computação
Pervasiva, é fundamental também que um computador seja capaz de identificar
outros computadores dentro de seu raio de atuação.
Computação Ubı́qua
A Computação Ubı́qua é nada mais que uma combinação da Computação
Móvel com a Computação Pervasiva. Assim sendo, o objetivo da Computação
Ubı́qua é aliar a capacidade da Computação Pervasiva de integrar dinamicamente
diversos dispositivos em um determinado ambiente à capacidade da Computação
Móvel de permitir o deslocamento desses dispositivos pelo espaço.
É importante destacar que num ambiente ubı́quo nem sempre é necessário
que um dispositivo seja móvel, mas é fundamental que seja pervasivo. Uma
lâmpada que acende automaticamente de acordo com a chegada de uma pessoa
na sala não é móvel, por que não há necessidade de que se mova, mas é ubı́qua
por interagir com o ambiente e fornecer um serviço adequado para o usuário.
Um dispositivo que não interage com o ambiente, porém, e cumpre sua função
de maneira pré-estabelecida e constante, ainda que a cumpra sem ressalvas, não
pode ser considerado ubı́quo.
Outro conceito fundamental para a Computação Ubı́qua e Pervasiva é o conceito de Smart Spaces, os espaços inteligentes, que tem por objetivo integrar
espaços fı́sicos à computadores. Um exemplo de Smart Space seria uma determinada sala onde a iluminação se regulasse automaticamente de acordo com a
presença de uma pessoa no ambiente, ou com o fato de uma TV estar ligada ou
desligada, ou ainda com a posição do usuário na sala.
Por fim, a confusão entre os conceitos de Computação Móvel, Pervasiva e
Ubı́qua é devida à pouca idade da Ubicomp como área de pesquisa, e tende a
40
diminuir à medida que essa pesquisa evolui com o tempo.
Figura 3.14: Comparação entre os paradigmas computacionais.
41
Figura 3.15: A Computação Ubı́qua é uma interseção entre os modelos das Computações Móvel e Pervasiva.
42
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:
43
• 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 nns 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
44
Figura 4.1: Diagrama de atividade do cadastro de entrada do usuário do tipo
visistante.
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.
45
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
46
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 middware 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;
47
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”.
48
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”.
49
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”.
50
Figura 4.10: Diagrama do caso de uso do ator ”gestor do sistema”.
A seguir são descritos detalhes as funcionalidades do sistema para cada ator
envolvido.
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 extemdem os comportamentos deste ator
como mostrado na Figura 4.5.
51
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;
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 confimaç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.
52
Nome do caso de uso
Objetivo
Fluxo principal
Incluir registro de etiqueta
Inserir informações de uma nova etiqueta no sistema;
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;
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
cadastradas no sistema.
de
etiquetas
previamente
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;
53
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.
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;
54
Nome do caso de uso
Objetivo
Fluxo principal
Pesquisar interessados
Pesquisar usuário interessados existentes no sistema.
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;
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, 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;
4. O sistema atualiza os dados do usuário caso nenhum
dos campos for vazio;
55
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;
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;
56
Nome do caso de uso
Objetivo
Fluxo principal
Consultar localização de usuário
Consulta a atual localização fı́sica do usuário no HUB.
1. O ator insere os dados de registro de acesso para
pesquisa de registros de acesso em aberto: ID do
registro de acesso, 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;
57
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;
58
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.
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;
59
Nome do caso de uso
Objetivo
Fluxo principal
Consultar registro de interessado existente
Pesquisar usuários interessados registrados no sistema.
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, sexo,
código da identificação ou o tipo de identificação;
3. Funcionário: O nome, sobrenome, idade, sexo,
código da identificação, tipo de identificação ou o
telefone;
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.
Nome do caso de uso
Objetivo
Fluxo principal
Consultar relatório de monitoração
Pesquisa os registros de monitoração de etiquetas no HUB.
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
60
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;
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;
61
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;
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;
62
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;
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;
63
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 existe as informações da pesquisa;
Nome do caso de uso
Objetivo
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
Descrição do ator: Responsável por gerir os usuários e seus respectivos perfis
de acesso ao sistema.
64
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;
Nome do caso de uso
Objetivo
Fluxo principal
Atualizar cadastro de usuário do sistema
Atualizar os cadastros dos usuários do sistema existentes.
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;
65
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;
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.
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.
66
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.
67
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.1.4.
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.
68
• 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, 2008], 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 aplicações
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.
69
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́
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.
70
exposta como um webservice 5 , permitindo seus clientes acessá-lo via SOAP
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
5
É uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. 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.
71
fı́sicos e a agregação das etiquetas lidas pelos mesmos através de adaptadores, 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.
72
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,
deve-se 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.
73
Figura 4.13: Visão geral da arquitetura do repositório EPCIS.
74
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
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.
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.
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.
75
• 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
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.
16
Acrônimo em inglês para Java Authentication and Authorization Service.
mentação da segurança e controle de acessos da máquina virtual java.
76
É a imple-
Figura 4.14: Diagrama de classes do módulo ILOCATEWEB.
77
Na figura 4.15 é apresentado o modelo de dados utilizado para armazenar os
dados referentes ao módulo em questão.
78
Figura 4.15: Diagrama de modelo de dados utilizado.
79
A figura 4.16 demonstra o diagrama de implantação dos componentes necessários
para executar os serviços do I-Locate.
Figura 4.16: Diagrama de implantação do módulo ILOCATE.
4.4
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.
80
Figura 4.17: Tela de login do sistema.
Figura 4.18: Tela de login do sistema.
81
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.
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.
4.4.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”.
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
ı́cones, é possı́vel obter a breve descrição do registro de aceso do portador da
82
Figura 4.19: Formulário de inserção de registro de acesso às dependências fı́sicas.
83
Figura 4.20: Opções de monitoração de etiquetas RFID.
84
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.4.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.
85
Figura 4.22: Formulário para localização de etiquetas.
86
Figura 4.23: Resultado para a busca de etiquetas.
87
Figura 4.24: Formulário para geração de relatórios de ocorrências de monitoração
de etiquetas.
88
Figura 4.25: Gerenciamento de usuários cadastrados no sistema.
89
4.4.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.
Figura 4.26: Gerenciamento de etiquetas cadastrados no sistema.
4.4.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.4.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.
90
Figura 4.27: Administração dos usuários do sistema.
91
Figura 4.28: Administração do sistema.
92
• Informações sobre etiquetas detectadas no sistema - Esta opção exibe os
valores atualizados das etiquetas que foram detectadas pelo sistema, figura
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: Administração do 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
93
Figura 4.30: hosts inscritos para recepção de eventos do middleware.
94
Figura 4.31: Especificações de relatórios de eventos.
95
fı́sica existente na base de dados. Para remover um leitor fı́sico, basta informar o identificador que o mesmo possui.
Figura 4.32: Leitores lógicos.
• 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.
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.4.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
96
Figura 4.33: Leitores fı́sicos.
97
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.
98
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
Nesta seção são apresentadas algumas funcionalidades 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
99
um serviço SOAP para que os sistemas informatizados no HUB pudessem
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.
• Disponibilização de informações de pacientes: Com a consideração do item
acima, poderia ser implementado no I-Locate o serviço de consulta ao paciente com informações detalhadas como por exemplo a temperatura do paciente, localização e quantidade de batimentos cardı́acos. O sistema poderia
alertar a médicos e enfermeira acerca das situações que são provavelmente
perigosas para a vida do paciente do mesma maneira que os agentes da
equipe de segurança monitoram o espaço fı́sico do hospital.
• 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.
100
Referências
[Brown and Wiggers, 2005] Brown, D. and Wiggers, E. (2005). Planning for proliferation: The impact of rfid on the network. IDC White Paper.
[CUHK, 2008] CUHK
(2008).
Cuhk
rfid
http://mobitec.ie.cuhk.edu.hk/rfid/middleware/index.htm.
midldleware.
[Davi Silva, 2006] Davi Silva, A. V. (2006). Modelagem de processos organizacionais - controle de acesso de pessoas no hospital universitário de brası́lia.
[de Araújo, 2003] de Araújo, R. B. (2003). Computação ubı́qua: Princı́pios, tecnologias e desafios. XXI Simpósio Brasileiro de Redes de Computadores, pages
01–72.
[EPCIS, 2008] EPCIS (2008). Accada epcis. http://www.fosstrak.org/.
[Finkenzeller, 2003a] Finkenzeller, K. (2003a). RFID Handbook: Fundamentals
and Application in Contactless Smart Cards and Identification, 2. ed, chapter 13, page 179. Wiley.
[Finkenzeller, 2003b] Finkenzeller, K. (2003b). 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.
[Himanshu Bhatt, 2005] Himanshu Bhatt, B. G. (2005). RFID Sourcebook, chapter Tópico 10.4.1.1.1. Prentice Hall PTR.
[Himanshu Bhatt, 2006a] Himanshu Bhatt, B. G. (2006a).
chapter Tópico 2.3.1. O’Reilly.
RFID Essentials,
[Himanshu Bhatt, 2006b] Himanshu Bhatt, B. G. (2006b). RFID Essentials,
chapter Tópico 3.4.1. O’Reilly.
[Himanshu Bhatt, 2006c] Himanshu Bhatt, B. G. (2006c).
chapter Tópico 3.5. 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. IEEE International Conference on Robotics and
Automation, pages 01–07.
101
[Mark Weiser, 1993] Mark Weiser, J. S. B. (1993). Some computer science issues
in ubiquitous computing. CACM, pages 01–08.
[NetworkTM, 2006] NetworkTM, E. (2006). RFID EPC Essential. EPCglobal.
[RfiIdJournal, 2007] RfiIdJournal
(2007).
http://www.rfidjournal.com/article/articleview/1338/1/129/.
Rfiidjournal.
[teleco, 2008] teleco
(2008).
Rfid:
http://www.teleco.com.br/tutoriais/tutorialrfid2/pagina3 .asp.
Aplicações.
[theregister, 2008a] theregister (2008a). Feds approve human rfid implants.
http://www.theregister.co.uk/2004/10/14/humanr f idi mplants/.
[theregister, 2008b] theregister (2008b). World cup tickets will contain rfid chips.
http://www.theregister.co.uk/2005/04/04/worldc upr f id/.
[Weiser, 1996] Weiser, M. (1996). A revised version of: The coming age of calm
technology. PowerGrid Journal, pages 01–05.
[Yi Zhi Zhao, 2007] Yi Zhi Zhao, O. P. G. (2007). Distributed design of rfid
network for large-scale rfid deployment. Industrial Informatics, 2006 IEEE
International Conference on.
102