Software para Sistemas de Control de
Acceso Físico
Alumno: Lionel Oscar Siclari, Director: Ing. Raúl Rivera
Facultad de Ingeniería de Mar del Plata, Marzo de 2009
Resumen: Se presenta un desarrollo de
software para un sistema de control de acceso
físico para estadios deportivos.
La implementación del proyecto requirió
desarrollar una integración a nivel de software
entre el Servidor de Control de Acceso y el
Sistema de Venta de localidades (tickets). Tal
integración permite a los sistemas externos
incorporar datos de personas y permisos
especiales, y se desarrolló implementando un
mecanismo de actualización de datos empleando
un WebService provisto por el Sistema de Venta
de Tickets.
Los espectadores adquieren en las boleterías
del estadio un ticket de proximidad con
tecnología MIFARE que opera a una frecuencia
de 13.56MHz. El número de serie (CSN) junto
con la información de la ubicación asociada al
ticket se transfiere al sistema de Control de
Acceso mediante el módulo desarrollado en este
proyecto. Se accede al interior del estadio a
través de molinetes que incorporan lectores de
proximidad para validar los datos de los tickets
adquiridos por los espectadores.
El sistema incluye una página Web que
permite visualizar en tiempo real el flujo de
ingreso de los espectadores por los distintos
puntos de acceso al estadio. Esta información se
utiliza para tomar diferentes acciones como por
ejemplo redireccionar el ingreso de espectadores
por los distintos sectores en caso de congestión
de alguno de los accesos.
I. INTRODUCCION
Los sistemas de Control de Acceso han ido
evolucionando a lo largo de los años en principio
debido al avance de la tecnología pero por otro
lado también debido a la necesidad de mayor
seguridad de la sociedad actual. El control de
Acceso se basa en dos conceptos principales:
Autenticación y Autorización. Autenticación es
el proceso de determinar la identidad de una
entidad, en cambio, Autorización tiene que ver
con permitir el acceso a determinados recursos
solo a las personas con los permisos suficientes
para hacerlo.
En general, la Autenticación de una persona
involucra un elemento conocido por la persona,
como por ejemplo una clave de seguridad, un
elemento que posee la persona, como una tarjeta
de acceso, o un atributo físico o de
comportamiento de la persona, como por
ejemplo su huella digital, iris, voz, etc. La
combinación de estos elementos de autenticación
permite manejar diferentes niveles de seguridad.
El proceso de Autorización se ejecuta en una
etapa posterior a la Autenticación de la persona.
En esta instancia es importante identificar cuales
son los permisos asociados a la persona en base a
las credenciales provistas durante la autorización.
En ambos procesos intervienen componentes
de Hardware y de Software. En este proyecto el
foco estará puesto en el Software de Gestión que
permite administrar los datos del sistema de
Control de Acceso.
El software fue implementado utilizando el
lenguaje de programación Java[1] e interfaces de
comunicación estándar que permiten la
integración entre distintos sistemas desarrollados
en diferentes lenguajes y plataformas.
II. ALCANCE DEL PROYECTO
A continuación se detallan las especificaciones
típicas para un control de acceso que dieron
origen al presente proyecto.
Req. 1: Se requiere que el Sistema de
Control de Acceso implemente un mecanismo
que permita incorporar la información de las
localidades vendidas por el Sistema de Venta de
Tickets. Esta información se encuentra
disponible a través de un WebService
desarrollado por el cliente.
El sistema debe manejar la condición de tickets
cancelados, es decir tickets que fueron vendidos
pero que antes del comienzo del partido fueron
cancelados por el espectador. No se debe
permitir el acceso al estadio a ningún espectador
con ticket cancelado.
Tampoco se debe permitir que un mismo ticket
sea utilizado más de una vez para el ingreso al
estadio. Se requiere en todos los casos que el
sistema de control de acceso actualice la
información de los tickets vendidos en forma
automática sin necesidad de intervención del
operador del sistema. El sistema debe estar
dimensionado para soportar las 20000
localidades disponibles para la venta.
Req2: Se debe brindar una interfase para
que el Sistema de Servicio de Atención al Cliente
obtenga información de los ingresos de los
espectadores al estadio (fecha, hora, sector de
ingreso, número de ticket).
Req 3: El sistema de Control de Acceso
debe proveer una interfase que permita
configurar los datos de comienzo y fin de un
evento de manera de poder consumir el Servicio
Web para obtener la información de los tickets
vendidos y actualizar los permisos de acceso al
estadio.
Figura 1. Alcance del Proyecto
III. SISTEMA DE GESTION
El Software de Gestión del Sistema de
Control de Acceso ofrece una interfase de
configuración de las distintas entidades del
sistema, como por ejemplo los usuarios,
permisos, dispositivos, reglas de acceso, eventos
y alarmas, etc. El sistema debe estar diseñado
para soportar la administración en forma remota,
concurrente y en un ambiente multiusuario. Debe
ser capaz de transferir los permisos de acceso en
forma automática a los dispositivos de Hardware
y mantener dicha información sincronizada. Es
responsable también de recolectar las alarmas y
eventos de los distintos elementos del sistema y
permitir manejar un esquema de reconocimiento
y cancelación de alarmas.
A cada usuario del sistema se le asigna un
esquema de Permisos de Acceso que permite
definir qué días, en qué horario y por cuales
dispositivos se le permite el acceso.
El esquema de permisos debe ser lo
suficientemente flexible como para soportar la
mayoría de los casos posibles como por ejemplo
horarios nocturnos, feriados, etc. La siguiente
figura muestra el esquema de permisos soportado
por el Sistema de Control de Acceso.
Permiso de Acceso Usuarios
Quién ?
Dónde y Cuándo ?
Código de
Acceso
Cuándo ?
Grupo de
Grupos de
Puertas de
Acceso
Tiempo
Qué días y qué horas ?
Código de
Feriados
Tiempo
Figura 2. Esquema de Permisos de Acceso
Uno de los objetivos de este proyecto es el
diseño de los datos que permita incorporar la
información de los tickets vendidos al esquema
actual de permisos del sistema de Control de
Acceso.
IV. ANTEPROYECTO
Se comenzó por analizar la información que
el sistema de Venta de Tickets retorna como
resultado de la ejecución del Servicio Web. Este
servicio implementa un mecanismo de consulta
mediante documentos XML[2] que permite
obtener la lista de tickets vendidos y tickets
cancelados para un determinado evento.
Cada ticket vendido se asocia a una
ubicación dentro del estadio identificado con una
clave primaria compuesta por sección, fila y
asiento. Además, cada ticket posee un número de
Identificación único asociado con el número de
Serie (CSN) grabado en el chip de la tarjeta
RFID. De este análisis surge el modelo de
Entidad-Relación En el contexto del análisis
estructurado, el DER define todos los datos que
se introducen, almacenan, transforman y se debe procesar la información recibida y
producen dentro de una aplicación. Está centrado actualizar los permisos de acceso de los tickets
vendidos. Dado que se pretende recibir una gran
solo en los datos y no en los procesos que los
cantidad de tickets con esta consulta (aprox. el
transforman. 60% del total de ubicaciones disponibles) se
En base a estas premisas, se diseñó la Base debe configurar el tiempo tglobal para que los
de Datos del sistema donde se almacenará la tickets vendidos sean válidos en el sistema antes
información de las ubicaciones disponibles en el que se abran las puertas del estadio.
estadio. tapertura: indica el momento en que se abren las
El siguiente diagrama muestra la relación puertas del estadio y los espectadores comienzan
entre las Tablas propias del sistema de Control a ingresar al mismo. La siguiente consulta de
de Acceso (Usuario y Permiso_Acceso) y la tickets vendidos (incremental) debería ocurrir
nueva tabla creada para almacenar la inmediatamente después de este momento.
información de las ubicaciones vendidas. tinicio: es el momento a partir del cual el sistema
alterna cada x tiempo configurable la consulta de
USUARIO UBICACION tickets vendidos y tickets cancelados. El tiempo
x debe tomarse lo suficientemente pequeño
ID CardId Section
Row
(típico 1 minuto) para permitir al sistema
CSN =
ID Place actualizar la información de los tickets vendidos
Level
StartTime CSN en las propias boneterías del estadio.
EndTime TicketNumber tfin: se corresponde con el momento de
Price finalización del partido, a partir del cual el
Canceled sistema de control de acceso detiene la consulta
StartTime de tickets vendidos.
EndTime
PERMISO_ACCESO
Level
Level V. SOFTWARE
ID = Processed
Description ID CardId
En esta etapa del proyecto se desarrolla el
software que cumple con el diseño planteado en
Figura 3. Modelo de Entidad Relación
la sección anterior. Para ello, se utilizaron un
El siguiente paso en la etapa de diseño de conjunto de clases Java que conforman lo que
este proyecto es implementar un mecanismo normalmente se denomina como API
automático que permita ejecutar periódicamente (Application Programming Interface). Una API
la consulta de tickets vendidos y cancelados. La es un conjunto de clases e interfases que ofrece
frecuencia con que se ejecute esta consulta una solución a una funcionalidad específica. En
dependerá en gran medida de la cantidad de
Java podemos encontrar por ejemplo API’s para
información a procesar como resultado de la
consulta misma y del tiempo máximo tolerado conexión a Base de Datos (JDBC), para manejo
para que los datos de los tickets vendidos se vean de XML (dom4j), para Logging (log4j), etc. En
reflejados en el sistema de Control de Acceso. este caso utilizamos una API denominada
Es lógico pensar que la primera ejecución de Quartz[3] que implementa un programador de
la consulta de tickets vendidos deberá arrojar tareas. Quartz[3] permite agendar diferentes
gran cantidad de resultados. Esto se debe a que la
mayoría de los espectadores son socios del club y trabajos que se ejecutarán en momentos
adquieren sus entradas con anticipación para determinados. Para la configuración de los
todos los partidos de la temporada. Es por ello tiempos de disparo de la tarea periódica se
que se plantea el siguiente flujo de consultas: desarrolló un panel Java utilizando componentes
Swing[4] según la siguiente figura:

Figura 4. Flujo de de consulta

tglobal indica el momento en que el sistema de

Control de Acceso ejecuta la primera consulta A
partir de ese momento, y hasta que comiencen a
ejecutarse las llamadas incrementales, el sistema
Figura 5. Configuración de eventos

Una vez programada la tarea, se debe aguardar a
que se cumpla la condición de disparo (Trigger).
En este momento, se ejecuta el cuerpo de la tarea
cuyas principales actividades son:
● Ejecutar la consulta al WebService (Global,
Incremental o Cancelados)
● Procesar la información XML recibida y
convertirla en Objetos del dominio de la
solución.
● Actualizar los datos de acceso con la
información recibida.
● Informar la finalización del procesamiento
con el correspondiente comando de
reconocimiento Ack.
Estos pasos se muestran en la siguiente figura:
Aguardar condiciones
de disparo
WebService
Agenda Trigger Tarea
XML
Actualización
de Datos
Figura 6. Procesamiento de los datos.
VI. RESULTADOS
Para verificar el funcionamiento del
software se plantearon dos etapas de ensayos. El
primero consistió en ensayos de laboratorio en el
ambiente de desarrollo. En esta etapa se
efectuaron modificaciones al software para
mejorar la performance al procesar gran cantidad
de datos (20000 tickets simulados). En los
ensayos se alcanzaron tiempos de respuesta del
orden de los 7 minutos. La limitación en la
velocidad estuvo dada por la capacidad de
procesamiento del servidor (PIV con 2Gb RAM).
En la segunda etapa se efectuaron ensayos
en el ambiente de preproducción, es decir con los
servidores definitivos y se lograron tiempos de
procesamiento del orden de los 3 minutos para la
misma simulación.
Estos resultados, sumados a la posibilidad de
ajustar la frecuencia con que se ejecuta la
actualización de los datos de tickets vendidos
hacen que la solución planteada se ajuste a las
distintas necesidades y esté preparada para un
eventual aumento de las localidades vendidas sin
necesidad de modificar el software desarrollado.
VII. CONCLUSIONES
A lo largo del desarrollo de este proyecto se
siguieron las metodologías que normalmente se
aplican en la Ingeniería de Software.
El desarrollo de software debe llevarse a cabo en
un entorno con Procesos definidos. Esto lleva a
que los proyectos sean más predecibles y el
equipo de trabajo desarrolle sus actividades de
manera ordenada y sistemática.
Gracias a la aplicación de estas metodologías de
desarrollo fue posible lograr la integración con
diferentes equipos de trabajo que desarrollan
software inclusive en diferentes tecnologías
(Java, Visual Basic, etc.)
La integración del Sistema de Control de
Acceso con otros sistemas como por ejemplo los
de Recursos Humanos, CRM, Tiempos y
Asistencia, etc., es una funcionalidad deseable
que no todos los sistemas poseen. En ocasiones,
agregar una nueva funcionalidad como la
presentada en este proyecto a los sistemas de
Control de Acceso requiere de un esfuerzo en
horas y costo tal que hacen inviable la
implementación de la solución. El uso de
componentes y protocolos estándar como JDBC,
HTTP, XML, etc. ayudan a que la integración
entre los sistemas sea más sencilla y natural.
El software fue implementado utilizando el
lenguaje de programación Java, de naturaleza
abierta, multiplataforma, robusto y confiable. A
pesar de ser un lenguaje que se ejecuta sobre una
máquina virtual, no se perciben diferencias de
performance en comparación con otros lenguajes
nativos como C o C++.
Actualmente, Java es soportado por una
extensa comunidad de desarrolladores de todo el
mundo. La ventaja de utilizar Java, entre otras, es
que el software se depura constantemente. Es la
misma comunidad de desarrolladores la que hace
crecer al lenguaje agregando nuevas
funcionalidades, detectando y corrigiendo
defectos e incorporando nuevos patrones de
diseño y estándares.
VIII. BIBLIOGRAFIA
[1] Java. http://java.sun.com/
[2] XML http://www.w3.org/XML/
[3] Quartz
http://www.opensymphony.com/quartz/
[4] Swing
http://java.sun.com/docs/books/tutorial/uiswing/