Un sistema de control inteligente de
entrada/salida de humanos a un recinto
siguiendo la metodología VigilAgent
Tomás de Teresa Trancón
Tomás de Teresa Trancón, Un sistema de control inteligente de entrada/salida de humanos a un recinto siguiendo la metodología VigilAgent. Proyecto fin de carrera, Departamento de Sistemas Informáticos, Universidad de Castilla-La Mancha, 2010.
Este documento puede descargarse desde:
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INGENIERÍA INFORMÁTICA
Departamento de Sistemas Informáticos
PROYECTO FIN DE CARRERA
Un sistema de control inteligente de entrada/salida de
humanos a un recinto siguiendo la metodología VigilAgent
Autor: Tomás de Teresa Trancón
Directores: Antonio Fernández-Caballero
José Manuel Gascueña Noheda
Resumen
Los sistemas de control de entrada/salida de humanos basan su funcionamiento en la identificación de usuarios y el uso de barreras para impedir el paso a usuarios no autorizados. Muchas veces los mecanismos de identificación y las barreras no son suficientes para evitar situaciones no deseadas, por lo que en ocasiones los sistemas se complementan con vigilantes de seguridad. En este proyecto se propone como alternativa utilizar un Sistema Multi-Agente para solucionar los problemas de identificación, control y detección de situaciones anómalas en sistemas de control de entrada/salida de humanos.
A lo largo de la presente memoria se describe el proceso llevado a cabo para modelar e implementar un sistema inteligente que simula la colaboración necesaria para controlar automáticamente la entrada/salida de humanos a/de un recinto cerrado. Este proceso sigue las fases de la metodología VigilAgent, específica para la creación de sistemas de seguridad basados en organizaciones de agentes.
VigilAgent se basa en dos metodologías de agentes suficientemente maduras, Prometheus e INGENIAS, con el fin de guiar al desarrollador en las fases de análisis, diseño e implementación. Durante las dos primeras fases de la metodología se obtiene un modelo conforme a Prometheus, que posteriormente se transforma en otro modelo expresado con el lenguaje utilizado en INGENIAS. Para la fase de implementación, se genera automáticamente código para la infraestructura ICARO-T, tomando como base el modelo desarrollado finalmente en INGENIAS. Por último, se completa el código referente a la interacción entre entidades y se crean los interfaces gráficos pertinentes.
Agradecimientos
En primer lugar, Antonio Fernández-Caballero y a José M. Gascueña, por brindarme la oportunidad de realizar este proyecto, por la ayuda prestada a lo largo de todo este tiempo y por los conocimientos compartidos conmigo. Su dedicación y paciencia han sido
fundamentales para la finalización de este trabajo.
A mis padres, por todo lo que me han ayudado durante estos años, especialmente a mi madre, por su confianza y por el ánimo que me ha dado en todo momento.
Por último y no menos importante, a Olaya, por haber sido para mi una fuente inagotable de inspiración. De otra manera no habría llegado este momento.
ÍNDICE
1. INTRODUCCIÓN ... 1
1.1. Motivación ... 1
1.2. Objetivos y límites del proyecto ... 2
1.3. Estructura de la memoria ... 4
2. ESTADO DEL ARTE ... 5
2.1. Metodología Prometheus ... 7
2.2. Metodología INGENIAS ... 10
2.3. Metodología VigilAgent ... 12
2.4. ICARO-T ... 16
2.5. Sistemas de control de acceso de entrada/salida... 20
2.6. Sensores ... 21
2.7. Metodología de desarrollo de redes de sensores mediante SMA ... 22
3. MODELADO DEL SISTEMA ... 25
3.1. Descripción del problema ... 25
3.2. Fase de especificación del sistema ... 28
3.2.1. Identificación de la interacción del sistema con el entorno ... 28
3.2.2. Desarrollo de escenarios ... 29
3.2.3. Especificación de objetivos del sistema ... 33
3.2.4. Descripción de roles ... 34
3.3. Fase de diseño arquitectónico ... 35
3.3.1. Identificación de tipos de agentes ... 35
3.3.2. Especificación de acoplamiento de datos ... 35
3.3.3. Descripción de las interacciones ... 36
3.3.4. Descripción de la arquitectura global del sistema ... 41
3.4. Fase de diseño detallado ... 43
3.4.1. Transformación de estructuras de Prometheus a INGENIAS ... 43
3.4.2. Identificación de tareas ... 54
3.4.3. Especificación del modelo de comportamiento de los agentes ... 59
3.4.4. Crear diagrama de componentes ... 73
3.4.5. Crear diagrama de despliegue ... 74
4. IMPLEMENTACIÓN ... 77
4.1. Fase de generación de código ... 77
4.2. Mejora de la aplicación ... 88
5. CONCLUSIONES Y TRABAJOS FUTUROS ... 95
5.1. Métricas ... 95
5.2. Conclusiones ... 98
5.3. Trabajos futuros ... 100
6. ANEXO: CONFIGURACIÓN Y USO ... 101
6.1. Configuración de la aplicación ... 101
6.2. Uso de la aplicación ... 102
ÍNDICE DE FIGURAS
Figura 2.1. Modelo de agente ... 5
Figura 2.2. Ventana de la herramienta PDT ... 9
Figura 2.3. Ventana de la herramienta IDK ... 12
Figura 2.4. Fases de la metodología VigilAgent ... 15
Figura 2.5. Ciclo de trabajo básico de un agente reactivo ... 17
Figura 2.6. Capas de una aplicación ICARO-T ... 19
Figura 2.7. MDD de aplicaciones ICARO-T utilizando IDK ... 20
Figura 2.8. Proceso de desarrollo en redes de sensores ... 23
Figura 3.1. Vista general ... 26
Figura 3.2. Módulo de entrada ... 26
Figura 3.3. Diagrama de visión general del análisis ... 29
Figura 3.4. Diagrama de escenarios ... 30
Figura 3.5. Escenario Controlar Entrada scenario ... 31
Figura 3.6. Escenario Controlar Salida scenario ... 31
Figura 3.7. Escenario Bloquear Puerta scenario ... 32
Figura 3.8. Escenario Tailgating scenario ... 32
Figura 3.9. Escenario Deshabilitar Modulo scenario ... 33
Figura 3.10. Diagrama de visión general de objetivos ... 33
Figura 3.11. Diagrama de roles del sistema ... 34
Figura 3.12. Diagrama de agrupamiento Agente-Rol ... 35
Figura 3.13. Diagrama de acoplamiento de datos ... 36
Figura 3.14. Protocolo PI Identificación ... 37
Figura 3.15. Protocolo PI Acceso ... 39
Figura 3.16. Protocolo PI Tailgating ... 40
Figura 3.17. Protocolo PI Puerta Bloqueada Usuario ... 41
Figura 3.18. Diagrama de visión general del sistema ... 42
Figura 3.19. Diagrama de comunicación de agentes ... 42
Figura 3.20. Transformación de una percepción ... 44
Figura 3.21. Transformación de una acción ... 44
Figura 3.22. Transformación de un mensaje ... 45
Figura 3.23. Transformación de un dato ... 45
Figura 3.24.a. Diagrama de entorno ... 51
Figura 3.24.b. Diagrama de entorno ... 52
Figura 3.25.a. Diagrama de interacción ... 53
Figura 3.25.b. Diagrama de interacción ... 54
Figura 3.26. Comportamiento de un agente ... 59
Figura 3.27.a. Autómata del agente agLector obtenido en INGENIAS ... 60
Figura 3.27.b. Autómata del agente agLector ... 61
Figura 3.28.b. Autómata del agente agPuerta ... 62
Figura 3.29.a. Autómata del agente agSensorInfrarrojo obtenido en INGENIAS ... 64
Figura 3.29.b. Autómata del agente agSensorInfrarrojo ... 64
Figura 3.30.a. Autómata del agente agSensorContacto obtenido en INGENIAS ... 66
Figura 3.30.b. Autómata del agente agSensorContacto ... 67
Figura 3.31.a. Autómata del agente agTailgating obtenido en INGENIAS ... 68
Figura 3.31.b. Autómata del agente agTailgating ... 69
Figura 3.32.a. Autómata del agente agPuertaBloqueada obtenido en INGENIAS ... 70
Figura 3.32.b. Autómata del agente agPuertaBloqueada ... 71
Figura 3.33.a. Autómata del agente agIntercomunicador obtenido en INGENIAS ... 72
Figura 3.33.b. Autómata del agente agIntercomunicador ... 73
Figura 3.34. Diagrama de componentes ... 74
Figura 3.35. Diagrama de despliegue ... 75
Figura 4.1. Fragmento del fichero XML del despliegue de la aplicación ... 78
Figura 4.2. Descripción de una instancia del agente agSensorInfrarrojo ... 78
Figura 4.3. Descripción de la instancia del recurso BDD ... 79
Figura 4.4. Estructura de paquetes de la aplicación ... 80
Figura 4.5. Fragmento de código del autómata del agente agTailgating ... 80
Figura 4.6. Esqueleto generado para la acción aNotificarTailgating ... 81
Figura 4.7. Implementación final de la acción NotificarTailgating ... 82
Figura 4.8. Método cortarInfrarrojo del recurso acSensorInfrarrojo ... 83
Figura 4.9. Fragmento de la acción semántica ComunicarInfrarrojoCortado del agente agSensorInfrarrojo ... 84
Figura 4.10. Paquete del recurso acSensorInfrarrojo ... 84
Figura 4.11. Diagrama de clases relacionadas con el recurso acSensorInfrarrojo ... 85
Figura 4.12. Ventana que genera la clase InterfazCentralita ... 86
Figura 4.13. Ventana que genera la clase InterfazLector ... 86
Figura 4.14. Ventana que genera la clase InterfazSensorInfrarrojo ... 87
Figura 4.15. Ventana que genera la clase InterfazSensorContacto ... 87
Figura 4.16. Recurso de trazas de ICARO-T ... 87
Figura 4.17. Aspecto de la aplicación tras su lanzamiento ... 88
Figura 4.18. Fragmento del diagrama de entorno ... 90
Figura 4.19.a. Automáta del agente agLector en INGENIAS ... 91
Figura 4.19.b. Automáta del agente agLector ... 92
Figura 4.20. Fragmento del fichero entradaLectores.xml ... 93
Figura 4.21. Interfaz de la aplicación Reloj ... 93
Figura 5.1. Tiempo de desarrollo del proyecto por fases ... 96
Figura 5.2. Tiempo dedicado a la implementación de cada módulo ... 97
Figura 6.1. Estructura de directorios propuesta ... 102
Figura 6.3. Ventana L 1 ... 103
Figura 6.4. Ventana C1 ... 103
Figura 6.5. Ventana IR 1 ... 104
Figura 6.6. Ventana Reloj ... 104
ÍNDICE DE TABLAS
Tabla 3.1. Descripción de las entidades ... 27
Tabla 3.2. Descripción de los roles ... 34
Tabla 3.3. Equivalencia entre conceptos de Prometheus e INGENIAS ... 46
Tabla 3.4. Agentes obtenidos desde Prometheus ... 46
Tabla 3.5. Aplicaciones obtenidas a partir de los actores de Prometheus ... 47
Tabla 3.6. Leyenda ... 47
Tabla 3.7. Aplicación acLector ... 47
Tabla 3.8. Aplicación acPuerta ... 47
Tabla 3.9. Aplicación acSensorInfrarrojo ... 48
Tabla 3.10. Aplicación acSensorContacto ... 48
Tabla 3.11. Aplicación acCentralita ... 48
Tabla 3.12. Aplicación BDD ... 49
Tabla 3.13. Métodos auxiliares de la aplicación acLector ... 49
Tabla 3.14. Métodos auxiliares de la aplicación acSensorInfrarrojo ... 49
Tabla 3.15 Métodos auxiliares de la aplicación acSensorContacto ... 50
Tabla 3.16. Métodos auxiliares de la aplicación acCentralita ... 50
Tabla 3.17. Acciones ejecutadas por el agente agLector ... 55
Tabla 3.18. Acciones ejecutadas por el agente agPuerta ... 55
Tabla 3.19. Acciones ejecutadas por el agente agSensorInfrarrojo ... 55
Tabla 3.20. Acciones ejecutadas por el agente agSensorContacto ... 56
Tabla 3.21. Acciones ejecutadas por el agente agTailgating ... 57
Tabla 3.22. Acciones ejecutadas por el agente agPuertaBloqueada ... 57
Tabla 3.23. Acciones ejecutadas por el agente agIntercomunicador ... 58
Tabla 3.24. Eventos recibidos por el agente agLector ... 60
Tabla 3.25. Eventos recibidos por el agente agPuerta ... 61
Tabla 3.26. Eventos recibidos por el agente agSensorInfrarrojo ... 63
Tabla 3.27. Eventos recibidos por el agente agSensorContacto ... 66
Tabla 3.28. Eventos recibidos por el agente agTailgating ... 68
Tabla 3.29. Eventos recibidos por el agente agPuertaBloqueada ... 70
Tabla 3.30. Eventos recibidos por el agente agIntercomunicador ... 71
Tabla 4.1. Aplicación Reloj ... 89
Tabla 4.2. Métodos añadidos a la aplicación acLector ... 90
Tabla 4.3. Acciones semánticas añadidas al agente agLector ... 91
1. INTRODUCCIÓN
1.1. Motivación
En la actualidad se está produciendo una demanda cada vez mayor de sistemas de control de accesos para llevar a cabo la organización del tránsito humano, la gestión de diversas zonas de seguridad y el registro de sucesos en tiempo real. La mayoría de estos sistemas basan su uso en la identificación mediante tarjetas o mediante el código introducido utilizando un teclado. Generalmente, los sistemas de control de entrada/salida incorporan además una barrera, una puerta o un sistema de barreras y/o puertas para impedir el paso a usuarios no autorizados. Los costos de estos sistemas varían ampliamente en función del nivel de seguridad que son capaces de proporcionar. En muchas ocasiones, los sistemas se acompañan de presencia humana para evitar situaciones en las que los sistemas pueden fallar. Un ejemplo son las intrusiones que se producen aprovechando el acceso de usuarios autorizados. El problema en muchos casos es que la introducción de vigilantes de seguridad no compensa el perjuicio económico que tratan de evitar.
Los Sistemas Multi-Agente (SMA) pueden resolver el compromiso entre pérdidas e inversión ofreciendo sistemas inteligentes más asequibles y baratos de mantener. En primer lugar, sustituyendo las costosas barreras mecánicas por puertas sencillas pero efectivas, provistas de sensores capaces de proporcionar información a los agentes. En segundo lugar, haciendo innecesaria la utilización de vigilantes en cada punto de acceso o salida, siendo suficiente con un vigilante de seguridad para supervisar todo lo que ocurre desde una centralita. Por lo tanto, el trabajo de vigilancia puede efectuarse por una organización de agentes que cooperan para detectar la intrusión de personas no autorizadas, basándose en la información proporcionada por los sensores y alertando al vigilante cuando sucedan situaciones anómalas.
Un sistema de vigilancia se puede entender como una red compleja, compuesta por un gran número de sensores distribuidos por el entorno físico que producen diferentes tipos de información. Dicha información es percibida del entorno con el fin de contribuir a realizar una labor de vigilancia determinada. Los SMA pueden utilizarse para el desarrollo de este tipo de sistemas mediante el modelado flexible de entidades autónomas. El concepto de agente aplicado a sensores permite convertir a éstos en entidades inteligentes que, además de percibir el entorno, pueden reaccionar ante los cambios que se producen y comunicarse entre sí con el fin de alcanzar objetivos comunes. Por cada sensor existe un agente software que lo gestiona. Esta aproximación al problema simplifica sustancialmente la manera de controlar y coordinar los sensores, a la vez que distribuye la carga de trabajo entre los agentes que forman el sistema. Los SMA se presentan como una tecnología idónea para su uso en redes de sensores, contribuyendo a mejorar su escalabilidad y dotándolas de flexibilidad, robustez y autonomía. En resumen, debido a la analogía descrita previamente
entre las redes de sensores y los sistemas de vigilancia, la tecnología de los SMA también resulta adecuada para aplicarla en el desarrollo de los sistemas de vigilancia inteligentes.
Actualmente no se conoce la existencia de un sistema de control de entrada/salida de humanos basado en agentes que esté implementado en un entorno complejo, como puede ser por ejemplo, en una entrada/salida al/del metro en horas punta. La aplicación de la metodología VigilAgent resulta interesante para comprobar la viabilidad del desarrollo de un sistema de control inteligente de entrada/salida porque se trata de una metodología que puede facilitar y mejorar la labor de desarrollo de SMAs orientados a la vigilancia de sistemas complejos. VigilAgent está basada en dos metodologías suficientemente maduras, Prometheus e INGENIAS, con el fin de guiar al desarrollador durante las fases de análisis, diseño e implementación, utilizando la infraestructura ICARO-T en la realización de la última fase. Este proyecto permite estudiar más a fondo la problemática asociada al control de entrada/salida, así como sentar las bases para futuros desarrollos basados en la metodología VigilAgent. El problema se abordará en un entorno simulado.
1.2. Objetivos y límites del proyecto
El objetivo global que se plantea en el presente trabajo se puede resumir como sigue: “Desarrollar un sistema inteligente, siguiendo la metodología de agentes VigilAgent, capaz de detectar las situaciones anómalas que se producen en un entorno que simula la entrada y salida de humanos en un recinto cerrado”.
El objetivo global mencionado anteriormente, se puede descomponer a su vez en los objetivos particulares que se detallan a continuación:
1. Estudio de los Sistemas Multi-Agente. Se estudiará la rama de la inteligencia artificial distribuida que trata los agentes y sistemas de agentes: sus características y los problemas que pueden resolver.
2. Conocimiento de la Ingeniería del Software Orientada a Agentes (AOSE). Se estudiarán diferentes metodologías para el desarrollo de software orientado a agentes, centrando especialmente la atención en aquellas en las que se basa VigilAgent.
3. Estudio de sistemas de control para la entrada y salida. Se investigará acerca de los sistemas de control de entrada/salida para adquirir los conocimientos necesarios en el tema en cuestión.
4. Investigación en sensores aplicados a la vigilancia y control automáticos. Se investigarán los tipos de sensor más utilizados en sistemas automáticos de vigilancia y control.
5. Prevención de situaciones anómalas en el funcionamiento del sistema. Se identificarán las situaciones anómalas que pueden alterar el funcionamiento normal del sistema.
6. Toma de decisiones y previsión de sus efectos durante las fases de diseño de
software. Las decisiones de diseño se tomarán con sumo cuidado, tratando de
evitar errores que puedan afectar negativamente al sistema.
7. Integración de las metodologías Prometheus e INGENIAS para el diseño de
software orientado a agentes. La integración se realizará tal y cómo describe la
metodología VigilAgent.
8. Conocimiento de la plataforma ICARO-T. Se aprenderán los conceptos utilizados en la infraestructura ICARO-T para implementar aplicaciones distribuidas de organizaciones de agentes.
9. Procesos de intercomunicación entre agentes. Se estudiará cómo se implementa la comunicación entre agentes en ICARO-T.
10. Implementación del software siguiendo los modelos definidos en el diseño. Se implementará el software conforme al diseño realizado.
11. Adición de nuevas funcionalidades en la aplicación. Una vez entregada la aplicación que satisface los requisitos iniciales se nos plantea la incorporación de un nuevo requisito. Para ello, se volverá a iterar en el ciclo de vida de desarrollo de software para integrar la nueva funcionalidad en la aplicación.
12. Documentación del proceso de desarrollo de software. Se detallará todo el proceso seguido para desarrollar la aplicación.
Dados los objetivos del proyecto es necesario establecer unos límites para centrar la atención de la problemática concreta a abordar en el caso de estudio. No se pretende obtener un sistema aplicable al mundo real, sino un sistema que funcione en un entorno simulado. Se desea que el sistema permita la realización de múltiples pruebas, así como el estudio de la problemática abordada, con la finalidad de poder aplicarlo en el futuro al desarrollo de otros sistemas basados en la misma tecnología y cuyo fin sea su aplicación en un entorno simulado o real. Por lo tanto, las situaciones que sucedan durante la simulación pueden no ajustarse a lo esperado en casos reales. Tampoco se pretende obtener fórmulas óptimas para detectar todas las situaciones anómalas posibles que se pueden presentar en un sistema de control de entrada salida, sino tan sólo aquellas que se planteen en la descripción del problema a abordar en el presente proyecto.
1.3. Estructura de la memoria
El capítulo 1, “Introducción”, explica el motivo por el que se ha desarrollado este proyecto así como los objetivos que se desean alcanzar.
El capítulo 2, “Estado del arte”, introduce conceptos de los Sistemas Multi-Agente y describe algunas de las principales metodologías de desarrollo software orientado a agentes. En particular se detalla la metodología VigilAgent utilizada en el desarrollo de este proyecto, así como las metodologías Prometheus e INGENIAS que dieron origen a VigilAgent, y la infraestructura orientada a agentes ICARO-T.
El capítulo 3, “Modelado del sistema”, explica todo el proceso de modelado del sistema siguiendo la metodología VigilAgent. Las dos primeras fases, especificación del sistema y diseño arquitectónico, se desarrollan utilizando la herramienta Prometheus Design Tool (PDT) que ofrece soporte a la metodología Prometheus. La tercera fase, diseño detallado, se desarrolla utilizando la herramienta INGENIAS Development Kit (IDK) que ofrece soporte a la metodología INGENIAS.
El capítulo 4, “Implementación”, detalla el proceso de implementación del sistema a partir del diseño desarrollado en el capítulo anterior. Se detalla la generación de código obtenida utilizando la herramienta IDK y cómo se completa la implementación de la aplicación.
El capítulo 5, “Conclusiones y trabajos futuros”, describe las conclusiones obtenidas tras la finalización de la aplicación, indicando sugerencias para posibles mejoras en Sistemas Multi-Agente de características similares, así como sistemas que utilicen la metodología VigilAgent.
2. ESTADO DEL ARTE
Los agentes nacieron de la investigación en Inteligencia Artificial (IA) y más concretamente de la Inteligencia Artificial Distribuida (IAD), que integra la IA con los Sistemas Distribuidos. Un agente (véase figura 2.1) es una entidad física o abstracta que percibe su ambiente a través de sensores, es capaz de evaluar las percepciones y tomar decisiones por medio de mecanismos de razonamiento, comunicarse con otros agentes para obtener información y actuar sobre su entorno a través de efectores (Fernández-Caballero, Gascueña, 2009).
Figura 2.1 Modelo de agente
Un agente puede trabajar solo o en cooperación con otros agentes con el fin de satisfacer uno o varios objetivos. En el segundo caso se habla de Sistemas Multi-Agente (SMA), es decir, sistemas formados por un conjunto de agentes que interaccionan entre sí para alcanzar objetivos comunes. Estos sistemas se sitúan en un entorno que proporciona a cada agente información que modifica su estado mental, activando mecanismos de razonamiento que desencadenan la ejecución de acciones y la comunicación con otros agentes para alcanzar los objetivos marcados. Integrados en el entorno, debe haber objetos de tal forma que puedan ser percibidos, creados, destruidos o modificados por los agentes. Por esto, cada agente debe disponer de un conjunto de operaciones que le permitan percibir, producir, consumir, transformar y manipular dichos objetos. Además, cada agente debe perseguir uno o varios objetivos. Por lo tanto, para poder hablar de un SMA, es necesario que el sistema reúna los siguientes elementos: un conjunto de agentes, un entorno y un conjunto de objetos.
Existen varias metodologías para desarrollar estos sistemas y cada una de ellas tiene unas características particulares que la hacen más adecuada para ciertos proyectos. A continuación se describen brevemente algunas de las metodologías más utilizadas en el desarrollo de SMA. Percepción Acción AGENTE Entorno EFECTOR SENSOR
- MAS-CommonKADS. Extiende al campo de los SMA la metodología
CommonKADS, para sistemas expertos, utilizando estructuración orientada a objetos y lenguajes de especificación de protocolos. Gira alrededor del modelo de experiencia y está pensada para desarrollar sistemas expertos que interactúen con el usuario. Además, plantea el desarrollo de SMA integrado en el ciclo de vida software denominado espiral.
- MaSE (Multi-agent systems Software Engineering). Parte del paradigma orientado
a objetos y asume que un agente es la especialización de un objeto. Los agentes se coordinan unos con otros vía conversaciones y actúan proactivamente para alcanzar metas individuales y globales. El proceso de desarrollo en MaSE consta de las siguientes etapas: captura de objetivos, aplicación de casos de uso, refinamiento de roles, creación de las clases de agentes, construcción de las conversaciones, ensamblaje de las clases de agentes y diseño del sistema. La mayoría de estas fases están soportados por la herramienta AgentTool.
- ZEUS. Combina distintos resultados de investigación en agentes (planificación,
ontologías, asignación de responsabilidades, relaciones sociales entre agentes) en un sistema ejecutable. ZEUS propone un desarrollo en cuatro etapas: el análisis del dominio, el diseño de los agentes, la realización de los agentes y el soporte en tiempo de ejecución. Estas etapas están basadas en el uso de roles para analizar el dominio y la asignación de roles a agentes.
- GAIA. Propone cómo realizar un análisis basado en los roles del SMA. El objetivo es comprender el sistema y su estructura, sin referenciar ninguna característica de la implementación, con el fin de de obtener un diseño suficientemente detallado como para poder ser implementado directamente. Esto se consigue a través de la idea de organización, la cual es una colección de roles que mantienen relaciones entre sí y toman parte en patrones institucionalizados de interacción con otros roles. Los roles agrupan cuatro aspectos: las responsabilidades del agente, los recursos que se le permite utilizar, las tareas asociadas y las interacciones.
Las metodologías Prometheus e INGENIAS son de especial interés por ser la base de la metodología VigilAgent, utilizada en el desarrollo de este proyecto. En las siguientes secciones se describen detalladamente ambas metodologías.
2.1. Metodología Prometheus
La metodología Prometheus define un proceso detallado para especificar, diseñar, implementar y probar/depurar sistemas software orientados a agentes. Propone un proceso de desarrollo iterativo que consta de tres fases: especificación del sistema, diseño arquitectónico y diseño detallado. Además, detalla cómo seguir el proceso y qué resultados se obtienen en cada fase (Padgham, Winikoff, 2004).
La fase de especificación del sistema consiste en identificar los objetivos y funcionalidades básicas del sistema, desarrollar los escenarios que ilustran el funcionamiento del sistema y especificar las entradas y salidas del sistema (percepciones y acciones, respectivamente). Los objetivos son un mecanismo para especificar los requisitos del sistema, es decir, permiten identificar por qué razones se está construyendo el sistema. El proceso de especificación de objetivos se recomienda hacer en dos pasos. El primero consiste en identificar los objetivos iníciales a partir de los requisitos proporcionados. El segundo paso consiste en refinar los objetivos agrupándolos por sus similitudes, de tal modo que pueda obtenerse un grupo de objetivos por cada funcionalidad que deba soportar el sistema. Es preciso resaltar que una funcionalidad describe un fragmento del comportamiento del sistema. Los escenarios describen el funcionamiento del sistema ilustrando la ejecución normal del sistema, así como las situaciones en las que se den sucesos anormales (alternativos). Un escenario se especifica en varios pasos, haciendo evidente dónde se necesita información del entorno y dónde es necesario realizar actuaciones. La información recogida del entorno se denomina percepción en la metodología Prometheus y constituye la entrada al sistema.
La fase de diseño arquitectónico toma los artefactos producidos en la fase anterior para identificar los tipos de agentes que existirán en el sistema y cómo interactuarán entre ellos para alcanzar los objetivos del sistema. Cada agente debe ser responsable de al menos una de las funcionalidades identificadas en la fase anterior. Por ello, para identificarlos se agrupan funcionalidades considerando todas las alternativas posibles de tal modo que finalmente se considere aquella agrupación que tenga una mayor cohesión y un mínimo acoplamiento. Otra tarea importante en esta fase consiste en especificar las interacciones que se producen entre agentes. En este caso, estas se describen mediante protocolos de interacción que incluyen los mensajes que se envían los agentes entre sí, qué percepciones llegan a los agentes y qué acciones efectúan sobre el entorno.
Por último, la fase de diseño detallado consiste en desarrollar la estructura interna de cada agente identificado previamente y detallar cómo llevar a cabo sus tareas dentro del sistema global. Para ello, se especifican las capacidades necesarias que cada agente tiene para satisfacer sus responsabilidades, además de desarrollar los protocolos con el objetivo de indicar el procesamiento interno de cada agente individualmente.
Una vez especificado el sistema se utiliza la herramienta Prometheus Design Tool (PDT) (Padgham, Thangarajah, Paul) para generar el código que sirve de base para implementar la aplicación en el lenguaje de programación Jack.
La herramienta PDT permite llevar a cabo el diseño de un SMA siguiendo la metodología Prometheus. Proporciona una ventana principal dividida en cuatro áreas: la lista de diagramas, la vista del diagrama, la lista de entidades y la vista de descripción de entidades (véase figura 2.2).
La lista de diagramas presenta de manera ordenada cada una de las fases de la metodología (especificación del sistema, diseño arquitectónico y diseño detallado) e incluye los diferentes tipos de diagramas que se crean en cada una de ellas.
La vista del diagrama permite visualizar y especificar el diagrama seleccionado en la lista de diagramas. Para ello ofrece una paleta con las entidades que pueden incluirse en el diagrama seleccionado.
La lista de entidades muestra de forma ordenada todas y cada una de las entidades existentes en el diseño del sistema, es decir, muestra todos los agentes, los actores, las percepciones, las acciones, los mensajes, los roles, los datos, los escenarios y los protocolos de interacción que forman parte de cada uno de los diagramas que componen el diseño del sistema.
La vista de descripción de entidades muestra una descripción detallada de la entidad seleccionada en la lista de entidades o en la vista del diagrama. Además, permite añadir o modificar cualquier detalle de la descripción.
El menú de la herramienta ofrece, a parte de las opciones esperadas en una herramienta de este tipo, una opción denominada Crosscheck para comprobar la consistencia del diseño y conocer, antes de generar el código, si el diseño obtenido se ajusta por completo a lo especificado en la metodología Prometheus. Otro detalle relevante es la posibilidad de utilizar la opción Complete HTML Report para generar automáticamente un informe completo de la especificación en HTML. Por último, comentar que tras completar el diseño, comprobar la consistencia y generar el informe, se puede utilizar la opción Generate Code para generar automáticamente una base de código que permitirá iniciar la implementación del sistema en el lenguaje JACK1.
1 JACK Intelligent Agents (JACK) es un entorno de desarrollo orientado a agentes construido sobre y
Figura 2.2. Ventana de la herramienta PDT
A continuación se describen algunos conceptos fundamentales utilizados en la metodología Prometheus:
- Percepción. Ítem de información del entorno recogida por algún tipo de sensor.
- Acción. Aquello que hace el agente y que puede ser de dos tipos, acción externa y
acción interna. Una acción externa es la que produce cambios en el entorno, mientras que una acción interna es aquella que no afecta al entorno y que necesita realizar el agente, como por ejemplo, el acceso a una base de datos.
- Objetivo. Algo en lo que está trabajando el agente y hacia lo que se dirige.
- Evento. Un suceso significativo al que el agente debe responder de alguna forma.
Una percepción es un tipo particular de evento.
- Mensaje. Unidad de interacción entre agentes, la cual se utiliza siguiendo un
protocolo definido.
2.2. Metodología INGENIAS
La metodología INGENIAS (Gómez, Pavón) propone un proceso de desarrollo basado en el Proceso Unificado de Desarrollo de Software (Unified Software Development Process o RUP) para desarrollar SMA2. Durante este proceso se generan una serie de modelos que se detallan a continuación:
- Modelo de organización. Describe la estructura del SMA, los roles y los flujos de
trabajo (workflows).
- Modelo de entorno. Describe las entidades y relaciones con el entorno del SMA.
- Modelo de agente. Describe los agentes del sistema, así como sus
responsabilidades, control y estado mental.
- Modelo de objetivos y tareas. Identifica los objetivos y tareas generales del
sistema, los cuales pueden asignarse a agentes.
- Modelo de interacción. Describe las interacciones existentes entre agentes.
Estos modelos se especifican en los flujos de análisis y diseño (Gómez, 2002), los cuales se dividen a su vez en tres fases, inicio, elaboración y construcción, de acuerdo al modelo iterativo RUP. La fase de análisis-inicio identifica los componentes que utilizan los agentes para interactuar con el entorno y especifica los casos de uso más relevantes. Los componentes se traducen en aplicaciones que especifican las acciones que pueden ejecutar los agentes, así como las percepciones de los agentes. La fase de diseño-inicio consiste en elaborar un prototipo del sistema que muestra cómo interactúa el usuario con la aplicación y qué tipo de resultados se esperan. En la fase de análisis-elaboración se analizan los casos de uso, obtenidos en la etapa anterior, para generar la arquitectura del sistema. Para ello se refinan los casos de uso y se asocian con modelos de interacciones. La fase de diseño-elaboración aumenta el nivel de detalle de la especificación determinando cómo se llevan a cabo los casos de uso identificados. Los resultados que se obtienen se centran en refinar los flujos de trabajo y las tareas asociadas, las interacciones, cómo es el control del agente y cómo se satisfacen los objetivos del sistema. El modelo de organización se refina asociando tareas a los flujos de trabajo. El modelo de interacción se detalla añadiendo relaciones con los flujos de trabajo. Tras desarrollar los casos de uso necesarios para determinar la arquitectura del sistema, se pasa a la fase de análisis-construcción para identificar los casos de uso restantes sin modificar sustancialmente la visión del sistema que se tiene hasta ahora del sistema. En la fase de diseño-construcción se detallan las relaciones sociales, principalmente las relaciones de subordinación y las relaciones cliente-servidor.
2 Recientemente también se ha formalizado el proceso de acuerdo a SCRUM, pudiéndose elegir
INGENIAS Development Kit (IDK) es una colección de herramientas para especificar, verificar e implementar SMA. La primera de estas herramientas es un editor gráfico, que permite al desarrollador crear y modificar especificaciones de un SMA utilizando conceptos del lenguaje de INGENIAS. Cada entidad puede visualizarse gráficamente con la notación de UML o utilizando la notación propia definida en la metodología INGENIAS. La ventana principal del editor se divide en cuatro áreas de forma muy similar a la herramienta PDT descrita previamente (véase figura 2.3).
El área de proyecto muestra en una estructura arbórea todos los diagramas del proyecto. Estos pueden ser de los tipos siguientes: modelo de entorno, modelo de organización, modelo de tareas y objetivos, modelo de interacción, modelo de agente, diagrama de componentes, diagrama de actividad, diagrama de casos de uso, diagrama de interacción AUML y diagrama de despliegue.
En el área de diagramas se visualizan los diagramas seleccionados en el área del proyecto. En el área de diagramas se crea una pestaña por cada modelo visualizado y ofrece una paleta para crear las entidades específicas de cada tipo de diagrama.
El área de Logs, localizada en la parte inferior del área de diagramas, se utiliza para mostrar informes de la herramienta y para mostrar los detalles descriptivos de la entidad seleccionada.
El área de entidades muestra jerárquicamente todas las entidades existentes en el modelo.
El segundo tipo de herramientas disponibles en el IDK son los módulos o pluggins. Estos requieren de especificaciones de SMA modelados con el lenguaje INGENIAS para verificar sus propiedades y generar automáticamente el código asociado al modelo. El soporte de este tipo de herramientas permite a los desarrolladores extender la funcionalidad de IDK creando sus propios módulos de acuerdo a sus necesidades. Este es el caso del módulo disponible para generar, automáticamente, código para la plataforma ICARO-T. Este módulo se ha utilizado en el desarrollo de este proyecto como parte de la metodología VigilAgent, la cual se describe más adelante.
Figura 2.3. Ventana de la herramienta IDK
2.3. Metodología VigilAgent
El ciclo de vida software de VigilAgent se divide en cinco fases, tal y como se describe en (Gascueña, 2010). Dichas fases son: especificación del sistema, diseño arquitectónico, diseño detallado, implementación y despliegue (véase figura 2.4).
En la fase de especificación del sistema, el analista de software identifica, a partir de la descripción proporcionada por el cliente, los requisitos del sistema y el entorno en el que va a estar situada la aplicación. Esta fase se desarrolla mediante las siguientes actividades:
La primera de ellas consiste en determinar las interacciones existentes entre el sistema y el entorno. Para ello es necesario identificar, en primer lugar, los actores del sistema. Estos son cualquier entidad humana, software o hardware que interacciona con el sistema. Seguidamente deben identificarse las entradas y salidas del sistema, es decir, las percepciones y acciones, respectivamente. Estas se definen como la información del entorno que estará disponible para el sistema (percepciones) y lo que hará el sistema para interactuar sobre el entorno (acciones). Posteriormente, deben identificarse los escenarios iniciales que
describen el comportamiento del sistema. Por último, se establecen relaciones entre cada una de las entidades identificadas (actoracción, actorpercepción, escenarioacción y escenariopercepción).
La segunda actividad consiste en desarrollar los escenarios identificados previamente. Para ello debe describirse el flujo normal de un escenario. Además, también se deben describir todas las alternativas posibles a un escenario. Cada paso del escenario está etiquetado como una acción, una percepción, un objetivo u otro escenario.
La tercera actividad consiste en identificar los objetivos del sistema a partir de la descripción del problema. Un objetivo es aquello que debe poder conseguir o resolver el sistema. Es la razón por la que se construye. Por lo tanto, una vez identificados los objetivos iníciales, estos deben refinarse y reagruparse relacionando objetivos con subobjetivos.
La última actividad consiste en describir los roles del sistema. Un rol es un trozo de comportamiento del sistema. Un rol se obtiene a partir de la agrupación de objetivos y debe poder describirse mediante un nombre único, pues una descripción demasiado extensa indica que el rol debe dividirse en varios roles. La fase de diseño arquitectónico consiste en determinar los tipos de agente que hay en el sistema y cómo interactúan entre ellos. Esta fase se desarrolla con las cuatro actividades siguientes:
La primera actividad consiste en especificar el acoplamiento de datos, es decir, identificar los datos necesarios, para que el sistema pueda llevar a cabo el comportamiento asociado, y establecer las relaciones de lectura/escritura entre los datos identificados y los roles obtenidos en la fase previa.
La segunda actividad consiste en identificar los tipos de agente existentes en el sistema. Esta actividad se debe hacer agrupando los roles del sistema para obtener agentes independientes en su comportamiento, es decir, dos tipos de agente no deben compartir un mismo rol, por lo tanto deben evaluarse las agrupaciones obtenidas mediante criterios de cohesión3 y acoplamiento4. Se considera como mejor agrupación a aquella que tiene una mayor cohesión y un mínimo acoplamiento. A partir de la asignación de roles a un agente se obtienen los objetivos asociados al agente, las percepciones ante las que reacciona, las acciones que efectúa y los datos que consume y/o produce.
3 La cohesión hace referencia al agrupamiento de agentes que desempeñan la misma funcionalidad. 4 El acoplamiento hace referencia al grado de dependencia entre agentes.
La tercera actividad consiste en describir las interacciones entre agentes mediante protocolos de interacción. La representación gráfica se obtiene a partir de sentencias textuales. Los protocolos se desarrollan a partir de los escenarios especificados en la fase de especificación del sistema e incluyen las acciones, las percepciones y los mensajes mediante los cuales los agentes interaccionan entre sí, y éstos con sus actores asociados.
La última actividad consiste en diseñar la arquitectura global del sistema para recoger en una sola vista la información recogida en las actividades previas. Se obtiene un diagrama que muestra las relaciones que hay entre los agentes y las percepciones, los agentes y las acciones, los agentes y los datos, además de incluir los protocolos de interacción obtenidos previamente. Se debe mencionar que en esta fase se genera automáticamente, a partir de la información incluida en los protocolos de interacción, un diagrama de comunicación entre agentes que muestra las relaciones de comunicación existentes entre los agentes del sistema.
La fase de diseño detallado consiste en transformar los conceptos obtenidos en Prometheus en conceptos equivalentes en la metodología INGENIAS. Posteriormente se completa el diseño que servirá como entrada para la generación de código.
En primer lugar debe hacerse la transformación de conceptos de una metodología a otra, prestando especial atención a la obtención de un diseño equivalente al original mediante la terminología de INGENIAS.
A partir del modelo de interacción obtenido se puede deducir que por cada “evento” que recibe un agente debe haber una tarea asociada al agente para responder a la llegada de dicho “evento”. Por lo tanto, por cada mensaje y percepción recibida por un agente se crea una tarea que incluye las acciones y mensajes que ejecutará/enviará el agente a su recepción.
Otra tarea consiste en refinar las aplicaciones obtenidas al aplicar la transformación. Este refinamiento consiste en añadir métodos auxiliares que reflejen las acciones que no efectúan cambios en el entorno, sino acciones internas, como por ejemplo el acceso a una base de datos.
Una vez conocidas las tareas que ejecutará el agente y los mensajes que recibe se procede a especificar el autómata que describe el comportamiento del agente.
La última tarea consiste en establecer, en el diagrama de componentes, una relación entre la tarea de cada agente y un componente de código. Esto es necesario para la generación de código.
La fase de implementación consiste en obtener el código final de la aplicación a partir del esqueleto de código generado automáticamente mediante el módulo de generación de código. Se deben completar los métodos de las aplicaciones y las tareas porque el generador únicamente genera las cabeceras. Una vez implementados los métodos se puede actualizar el diseño, concretamente los componentes de código, con el código introducido manualmente. Este paso es necesario para que el código introducido no se pierda la próxima vez que se repita el proceso de generación de código. En la figura 2.7 de la siguiente sección se describe el proceso de generación de código desde INGENIAS y el procedimiento para salvar el código generado.
La fase de despliegue consta de una única tarea que consiste en la especificación del número de instancias que habrá de cada tipo de agente y aplicación al desplegar la aplicación. Esta tarea se realiza adjuntando, en un modelo del entorno, notas a los agentes y aplicaciones presentes en el diseño.
2.4. ICARO-T
ICARO-T (Garijo, Polo, Spina, 2009) es una infraestructura software que tiene como objetivo el desarrollo de aplicaciones distribuidas con organizaciones de agentes. Proporciona patrones de agente a partir de los cuales pueden generarse instancias de agentes de aplicación, dotados de comportamiento en incluidos en una organización formada por agentes y recursos. Estas organizaciones persiguen unos mismos objetivos globales, mediante la coordinación de sus actividades, además de unos patrones de actividad establecidos. De esta manera, permite gestionar aplicaciones distribuidas a gran escala, pues optimiza y regula la gestión de servicios y distribución de tareas, obteniendo gran eficiencia en la consecución de los objetivos del sistema.
ICARO-T proporciona tres tipos de modelos de componentes reutilizables para desarrollar una aplicación: modelos de organización de componentes para describir la estructura general del sistema, modelos de agentes basados en comportamientos reactivos y cognitivos, y modelos de recursos para encapsular las entidades computacionales que ofrecen servicios a los agentes. Además proporciona componentes más elementales como son los patrones software utilizados para construir los modelos de agentes y los modelos de recursos.
El patrón de agentes provee a los agentes de interfaces externos y estructuras internas comunes, facilitando su desarrollo, su evolución y la inclusión de los mismos dentro de aplicaciones ya desarrolladas. La arquitectura del agente reactivo se basa en tres componentes incluidos en el patrón de agente de ICARO-T: percepción, control y actuación. El agente recibe eventos a través de la percepción, los cuales se entregan al control bajo demanda. El control está definido mediante un autómata de estados finitos que consume los eventos almacenados en la percepción, provocando transiciones de estado y la ejecución de acciones por parte del componente de actuación. Las acciones generan cambios en el entorno que son de nuevo percibidas por los agentes provocando cambios en el autómata y la ejecución de nuevas acciones. Los mecanismos de percepción y control se encuentran definidos en el patrón de agente que ofrece ICARO-T. El patrón le permite al desarrollador definir el comportamiento de un agente reactivo mediante una tabla de transiciones localizada en un fichero XML y el modelo de ejecución mediante una clase de acciones semánticas.
El ciclo de trabajo de un agente reactivo se muestra en figura 2.5 (Gascueña, Fernández-Caballero, Garijo, 2010). El agente recibe eventos, procedentes de agentes y recursos a través de su interfaz de uso, que son encolados en su interfaz para su posterior consumo. Cuando el componente de control solicita un nuevo evento, el componente de percepción se lo proporciona a través de su interfaz de consumo. En ese momento el control del agente procesa el evento para obtener la información que contiene el evento y
provocar cambios internos en el autómata que describe su comportamiento. Estos cambios consisten en transiciones de estado, las cuales, al consumir un evento, provocan la ejecución de acciones semánticas por parte del componente de actuación. Una vez iniciada la acción, el agente espera a que ésta finalice para solicitar un nuevo evento a través del control.
Los agentes necesitan interactuar con el entorno para satisfacer sus objetivos. Para ello se utilizan unas entidades llamadas recursos, las cuales ofrecen información del entorno a los agentes y les permiten efectuar acciones sobre este. Los recursos de aplicación se encuentran encapsulados en componentes que aíslan su estructura interna. Además, al igual que los agentes, ofrecen interfaces bien definidas para su uso y gestión.
Una aplicación en ICARO-T se modela como una organización formada por los componentes de control y los recursos de aplicación. Esta organización se estructura en tres capas (véase figura 2.6): la capa de control está formada por los componentes de control, es decir, los agentes; la capa de recursos está formada por los componentes que sirven información o proveen de funcionalidad a los agentes para alcanzar sus objetivos; la capa de información contiene las entidades de información necesarias para modelar los datos de las aplicaciones (ontologías, clases, etc.).
El usuario arranca una aplicación pasando como parámetro la descripción de la organización de la aplicación. Esta descripción, denominada despliegue, consiste en un fichero XML. Su estructura se detallará posteriormente en el capítulo de implementación. En ese momento se crean tres componentes: el recurso de trazas, el componente de configuración y el repositorio de interfaces. El recurso de trazas es una interfaz gráfica que muestra los componentes de la organización, tanto recursos como agentes, y permite visualizar en un cuadro de texto toda la traza de ejecución de la aplicación. El componente de configuración interpreta la configuración que describe el fichero de despliegue y ordena la creación del agente gestor de la configuración, encargado de controlar la creación del agente gestor de recursos y del agente gestor de agentes. Estos últimos toman el control para crear y gestionar los recursos y agentes de aplicación, respectivamente. Por último, resaltar que cada entidad de la organización informa de su estado a la entidad que lo creó, la cual se encarga de tomar decisiones en función de la información recibida. Así, los agentes de aplicación informan al gestor de agentes, los recursos de aplicación al gestor de recursos y estos últimos informan al gestor de la organización.
Figura 2.6. Capas de una aplicación ICARO-T
En figura 2.7 se muestra el Desarrollo Dirigido por Modelos (Model Driven Development o MDD) de aplicaciones ICARO-T utilizando IDK (Gascueña, 2009). En primer lugar se crea un proyecto nuevo sobre el que poder trabajar (fase 1). Una vez creado el proyecto, se ejecuta el entorno IDK y se modela la aplicación utilizando el perfil específico para ICARO-T, el cual sólo permite utilizar entidades válidas para el desarrollo en ICARO-T (fase 2). Una vez finalizado el proceso de modelado se genera el código asociado el modelo obtenido (fase 3) para posteriormente modificar el código en Eclipse (fase 4). Si fuera necesario, se puede salvaguardar el código modificado en Eclipse para realizar cambios en el modelo (fase 5). Una vez realizados estos cambios se puede volver a generar el código, el cual incluirá las modificaciones realizadas anteriormente en Eclipse. Este proceso se puede repetir las veces que sea necesario.
Para conocer otros proyectos desarrollados con ICARO-T pueden consultarse (Benito, Valerón, 2009), (Fernández de Alba, 2009) y (Rodríguez, 2009).
Figura 2.7. MDD de aplicaciones ICARO-T utilizando IDK
2.5. Sistemas de control de acceso de entrada/salida
El control de acceso de humanos de entrada/salida tiene como objetivo proteger de accesos no autorizados a zonas de seguridad, gestionando el tráfico de personas e impidiendo el paso a individuos no autorizados. Los sistemas de control de acceso de humanos de entrada/salida son una solución difundida ampliamente: se utilizan en metros, bancos, hoteles, instituciones oficiales, centros de trabajo y todo tipo de áreas restringidas localizadas en hospitales, universidades y zonas militares, entre otras. Su configuración es amplia y variada, dependiendo de las necesidades de cada caso particular, aunque suelen compartir dos elementos comunes: por un lado, constan de un medio lógico para identificar al usuario en el sistema y, por otro lado, de un medio físico que impide o permite el acceso. Además, dichos elementos se utilizan conjuntamente con un componente de control encargado de comparar la información obtenida del usuario con la información almacenada de una base de datos. En caso de coincidir ordena la apertura del medio utilizado como barrera. En muchos casos este componente se encarga también de registrar información relativa al usuario, el momento y el acceso utilizado.
La identificación de usuarios en el sistema se realiza mediante uno o varios medios combinados. La utilización de uno u otro depende del nivel de seguridad y control deseado. Uno de los métodos más comunes es la identificación basada en la información codificada en la banda magnética de una tarjeta. Es un método similar al de los tickets, salvo que cada tarjeta suele ser única e intransferible por cada usuario y permite el acceso controlado. Muchas veces se suele combinar con la utilización de un código de seguridad personal (PIN) para evitar casos de robo o extravío de la tarjeta. Los sistemas que requieren un nivel más alto de seguridad utilizan también la biometría como método de identificación. Esta tecnología gestiona el acceso a través de la identificación de la huella dactilar, el escaneo de la palma de la mano u otras características físicas individuales tales como por ejemplo el iris.
Los medios físicos para controlar el acceso dependen del tipo de zona que se desea controlar. Para la entrada principal a edificios se suelen utilizar las puertas giratorias y las esclusas de seguridad. Son la solución más común en bancos e instituciones que requieren de cierto nivel de seguridad. Para áreas interiores se utilizan puertas y pasillos con tornos, los cuales pueden disponer de sensores para mayor seguridad. Estos pasillos son similares a los utilizados en los metros para el acceso de viajeros. En áreas más grandes, como pueden ser las áreas perimetrales, suelen utilizarse tornos de altura completa.
La combinación de medios lógicos y físicos produce diferentes sistemas de seguridad para el control de acceso de entrada/salida. Uno de los sistemas más difundidos por su eficacia es el de puertas esclusas. Este sistema consta de un espacio delimitado entre dos puertas que previene el paso de más de una persona a la vez. El funcionamiento es el siguiente: en primer lugar el usuario se identifica en la primera puerta, la cual le da acceso a la esclusa. Posteriormente, una vez cerrada la primera puerta, el usuario se identifica de nuevo ante la segunda puerta, la cual le da acceso al área restringida. Algunos de estos sistemas constan además de un sensor por ultrasonido de forma que si dos o más personas son detectadas en la esclusa se niega el acceso (Kaba, 2010).
2.6. Sensores
Un sensor es un dispositivo capaz de medir magnitudes físicas o químicas y transformar dichas medidas en variables eléctricas. Los sensores se utilizan para medir, por ejemplo, temperatura, intensidad lumínica, distancia, aceleración, presencia, color, inclinación, desplazamiento, presión, fuerza, torsión, humedad y pH. En general, convierten una señal física no eléctrica en otra eléctrica que, en alguno de sus parámetros (nivel de tensión, nivel de corriente o frecuencia) contiene la información correspondiente a su medición. Por otra parte, es necesario utilizar circuitos de acondicionamiento con el objeto de que éste genere una señal eléctrica normalizada (ya sea por el fabricante o
siguiendo pautas de organismos de normalización como IEC5 o IEEE6). Los sensores se pueden clasificar según múltiples características (Armesto, 2007), como son: el tipo de funcionamiento (activos y pasivos), el tipo de señal eléctrica que generan (analógicos, digitales y temporales), el rango de valores que proporcionan (de medida y todo-nada), el nivel de integración (discretos, integrados e inteligentes) y el tipo de variable física medida.
Los sensores más utilizados en los sistemas de vigilancia y control están destinados a percibir la presencia de personas y comprobar el estado de los elementos del sistema. En el primer caso se utilizan sensores de presencia, sensores de proximidad, sensores acústicos, sensores ópticos y sensores de presión, entre otros. En el segundo caso se utilizan sensores de temperatura, sensores de estado, sensores de desplazamiento y sensores de humo, entre otros. Resaltar que para el presente proyecto resultan de gran interés los sensores de presencia y los sensores de estado, concretamente los sensores infrarrojos y los sensores de contacto. Estos sensores resultan de gran utilizad para detectar el paso de una persona (corte del rayo infrarrojo) y para conocer el estado de una puerta (abierta o cerrada). Ambos sensores se clasifican en el tipo todo-nada, también conocido como on-off.
2.7. Metodología de desarrollo de redes de sensores mediante SMA
La red de sensores es una de las tecnologías más prometedoras para las próximas décadas gracias a la continua reducción de tamaño y precio que se está produciendo en los sensores (Vinyals, Rodríguez Aguilar, Cerquides, 2010). Se trata de un concepto relativamente nuevo en adquisición y tratamiento de datos que tiene múltiples aplicaciones en distintos campos tales como los entornos militares, la medicina, la industria, la domótica, la inteligencia ambiental y la eficiencia energética. Están formadas por un grupo de sensores dotados de capacidades sensitivas y de comunicación, los cuales permiten formar redes ad hoc7 sin una infraestructura física preestablecida ni administración central.
Los SMA pueden contribuir al desarrollo de este tipo de sistemas mediante el modelado flexible de entidades autónomas. En (Fuentes-Fernández, Guijarro, Pajares, 2009) se propone un proceso para el desarrollo de redes de sensores mediante SMA. Este proceso está basado en la metodología INGENIAS, al igual que VigilAgent. En figura 2.8 se puede observar cada uno de los pasos que componen este proceso, así como los puntos de toma de decisiones.
5 International Electrotechnical Commission (IEC) 6 Institute of Electrical and Electronics Engineers (IEEE)
7 Ad hoc se refiere a una red en la que no hay un nodo central, sino que todos los dispositivos están en
act Phase 1
1. Identificar contenedores y recursos
2. ¿Se deben generar más datos?
3. Identificar datos a generar
4. Identificar el equipo de procesamiento de
información
5. ¿Hay recursos reemplazables?
6. Identificar recursos reemplazables 7. Identificar el equipo de balanceo de carga 8. Refinar el PIM 9. Refinar el modelo especifico de plataforma PSM 10. Desarrollar el Modelo de plataforma PM 11. Desarrollar transformaciones 12. Aplicar transformaciones al modelo
13. Aplicar modelo a las transformaciones de texto
[Sí]
[No]
[Sí]
[No]
Figura 2.8. Proceso de desarrollo en redes de sensores
La actividad 1 Identificar contenedores y recursos consiste en determinar los dispositivos que van a percibir información del entorno y los que van a procesar la información suministrada por los sensores. Los primeros se identifican como sensores, mientras que los segundos pueden ser un ordenador o cualquier otro dispositivo informático. Cuando la respuesta a la pregunta que se formula en la decisión 2 “¿Se deben generar más datos?” es afirmativa, se continúa en la actividad 3 Identificar datos a generar, consistente en identificar los datos que van a ser generados por el sistema al margen de los datos que proveen los sensores. Para cada grupo de datos, la actividad 4 Identificar el equipo de procesamiento de información, asigna a cada sensor dos controladores para inicializar el sensor y permitir el acceso a los datos que genera el sensor, respectivamente. Las actividades siguientes permiten el estudio del
comportamiento dinámico de la red y su refinamiento. Así pues, la decisión 5 ¿Hay recursos reemplazables? conduce, en caso afirmativo, a la búsqueda de recursos que pueden fallar durante el funcionamiento del sistema, con las correspondientes modificaciones sobre el modelo (actividad 6 Identificar recursos reemplazables y actividad 7 Identificar el equipo de balanceo de carga). Una vez concluidas estas actividades se deben haber obtenido los dispositivos, los agentes y los roles que conforman el sistema, así como la información que intercambian y sus interacciones.
Las actividades siguientes se centran en el proceso de desarrollo en INGENIAS, las cuales se realizan sobre el modelo obtenido mediante las actividades expuestas previamente. La actividad 8 Refinar el PIM (Modelo Independiente de la Plataforma) consiste en modificar el modelo de actores y roles con objetivos adicionales, capacidades e información. Las actividades 9 y 10 acercan el modelo al siguiente nivel de desarrollo, añadiendo componentes de código a las entidades para hacerlas más específicas (actividad 9 Refinar el modelo especifico de plataforma PSM y la actividad 10 Desarrollar el Modelo de plataforma PM). Las actividades 11, 12 y 13 realizan las transformaciones necesarias para realizar el proceso semi-automático de generación de código mediante el IDK (actividad 11 Desarrollar transformaciones, actividad 12 Aplicar transformaciones al modelo y actividad 13 Aplicar modelo a las transformaciones de texto).
El proceso de desarrollo descrito cuenta con múltiples similitudes con la metodología VigilAgent. Se puede llegar a la conclusión de que las actividades 1 a 7 se asemejan a las actividades realizadas en Prometheus para la identificación de actores, agentes, roles y las interacciones posibles, además de los datos generados. Las actividades siguientes (8 a 13) se asemejan a las fases que usan INGENIAS en VigilAgent, consistentes en realizar las transformaciones necesarias al modelo de Prometheus y añadir componentes de código para realizar el proceso semi-automático de generación de código a partir del modelo final especificado en INGENIAS.
3. MODELADO DEL SISTEMA
3.1. Descripción del problema
El caso de estudio presentado en este capítulo ilustra todo el proceso de desarrollo considerado en la metodología VigilAgent para modelar una aplicación utilizando como base tecnológica los fundamentos de los SMA. En particular, se pretende modelar un sistema inteligente que simule la colaboración necesaria para controlar, automáticamente, la entrada/salida de humanos a un recinto a través de los módulos instalados (véase figura 3.1). Cada módulo facilita la entrada o la salida en función de su configuración. Un módulo está compuesto por un dispositivo lector de tickets, una puerta de apertura y cierre automático, un sensor de contacto y un sensor de infrarrojos (véase figura 3.2).
Inicialmente, el usuario introduce el ticket en el lector de un módulo y el sistema ilumina el led del lector con un determinado color para advertirle al usuario cuál ha sido el resultado de su autentificación. El led se ilumina de color rojo si se trata de un usuario no autorizado. En caso contrario, se ilumina de color verde y seguidamente se abre la puerta, dando tiempo a que el usuario la atraviese antes de que ésta se cierre. El sensor de infrarrojos se utiliza para contar el número de personas que pasan por el módulo.
El sistema lleva un control de la cantidad de usuarios que atraviesan cada puerta individualmente y un control global del número total de usuarios que se encuentran en el interior del recinto en cada instante. Evidentemente, los protocolos para entrar y salir del recinto son similares, es decir, la salida del recinto se puede ver como la “entrada” al exterior desde el interior del recinto. Además, el sistema debe controlar la ocurrencia de situaciones anómalas porque cualquier usuario puede realizar acciones no autorizadas, tanto en el proceso de entrada como en el de salida. Así, por una parte, se contempla la posibilidad de que el usuario pueda bloquear una puerta, en el momento en que ésta se abra para darle paso, impidiendo que se cierre. Por otra parte, se deben detectar las situaciones de tailgating, es decir, la práctica que siguen determinados usuarios que no se autentifican para atravesar la puerta aprovechando que está abierta porque otra persona ha introducido correctamente su ticket previamente. Resaltar que el tailgating puede darse porque la puerta está bloqueada y/o aprovechando el intervalo de tiempo durante el que la puerta permanece abierta para que el usuario autorizado pueda atravesarla.
Finalmente, otra funcionalidad que ofrece el sistema consiste en permitir que el vigilante de seguridad, responsable de supervisar todo el proceso de entrada y salida de usuarios al/del recinto, tenga capacidad para deshabilitar un módulo cuando su puerta esté cerrada. Además, le informa en todo momento del estado en que se encuentra cada dispositivo del sistema y las estadísticas obtenidas. Por ejemplo, el estado de una puerta, el
resultado de identificación de un usuario, el número de usuarios que hay dentro del recinto, etc.
Figura 3.1. Vista general
Figura 3.2. Módulo de entrada
Entrada Entrada Entrada Salida Salida Recinto cerrado Puerta de entrada Sensor de infrarrojos Sensor de contacto Lector de tarjetas Recinto cerrado
