MODELO CLIENTE-SERVIDOR PARA LA ADMINISTRACION REMOTA DE LA INFORMACION VISUAL EN EDIFICIOS

MODELO CLIENTE-SERVIDOR PARA LA ADMINISTRACION REMOTA DE LA INFORMACION VISUAL EN EDIFICIOS

Alfredo C. Castro, Eduardo M. Zavalla, Marcelo L. Martin

Instituto de Automática Facultad de Ingeniería Universidad Nacional de San Juan {acastro; ezavalla}@inaut.unsj.edu.ar

Resumen: En este trabajo se presenta el desarrollo e implementación de un sistema destinado a la administración de la información proveniente de un conjunto de cámaras CCD de vídeo orientado al monitoreo y supervisión de áreas en edificios. El sistema propuesto utiliza como medio de comunicación una LAN o WAN con recursos de Internet (Intranet) basado en el paradigma del modelo cliente-servidor. Se presentan los resultados obtenidos respecto a la calidad de imagen y los tiempos de transferencia. Abstract: This paper presents the development and implementation of a visual information management system to be used for local as well as remote monitoring and supervision of critical areas in buildings. The proposed system uses a network Internet-like based communication link and it has been built upon the client-server paradigm. Results about the image quality and delivery times are also shown. Palabras claves: Edificios Integrados por computador, programación orientada a objetos, visión artificial.

1

INTRODUCCIÓN.

La visualización de la actividad y presencia de individuos en ciertas áreas reservadas de edificios es un problema cuya solución convencional ha consistido generalmente en la instalación de circuitos cerrados de televisión (CCTV) compuestos por cámaras de video basculantes, multiplexores de señales de video, uno o más monitores y opcionalmente videograbadoras en las cuales registrar las imágenes diariamente. Aunque es posible combinar el CCTV con detectores de presencia para emitir alarmas de advertencia y eventualmente proceder al registro de imágenes, este método no provee la flexibilidad suficiente para realizar un seguimiento automático o manual de personas. Si bien existe tecnología disponible para estos servicios, su costo es considerable.

Los sistemas comerciales de visión orientados a la seguridad en edificios se basan generalmente en entornos de vigilancia locales [Gomes, et. al, 1997; Martín and Zavalla, 1997]. Si se propone realizar con estos dispositivos una supervisión remota, los costos crecen en forma proporcional con las distancias involucradas, y las tecnologías asociadas son, por lo general, propietarias y cerradas. En este trabajo se presenta un método alternativo de captura, registro, transmisión y visualización de imágenes, basado en el modelo cliente-servidor, y que utiliza los recursos de Internet en una red privada (Intranet) como medio de transporte (Fig. 1). La arquitectura propuesta consta de uno o más servidores de imágenes (SI) que realizan el procesamiento de imágenes comandados por uno o más clientes remotos.

B ro w s e r H T M L c o n s o p o rte J A V A

C li e n t e R e m o t o ( a p p le t J A V A )

P á g in a s W E B

IN T E R N E T

cámaras que simulan sensores virtuales de movimiento, indicando si existe actividad o no (movimiento).

C a m in o d e m e n s a j e s h a c ia y d e s d e s e r v i d o r e s E IC a l A p p le t G a te w a y

Movimientos de la cámara: Este comando esta destinado al control de movimientos de cámaras robotizadas a fin de ubicarlas en posiciones seleccionadas por el cliente.

C li e n t e L o c a l ( a p p le t o a p lic a c ió n J A V A ) A c c e so to ta l a re d

F ire w a ll

In tr a n e t

S e r v id o r H T T P 1 .0

S e r v id o r FTP

S e r v id o r p ro x y

3

ESTRUCTURA DEL SERVIDOR DE IMAGEN

S e r v id o r im á g e n e s

S e r v id o r e s e s p e c í f ic o s E I C

Fig. 1. Arquitectura cliente-servidor propuesta Los módulos servidores de imágenes (SI) están compuestos por un computador (tipo PC en la aplicación presente) dotado de un frame-grabber con capacidad de administrar varias cámaras y una interfase de red a través de la cual recibe comandos y envía respuestas e imágenes bajo protocolo TCP/IP, permitiendo varias conexiones simultaneas a distintos clientes. Una arquitectura como la propuesta solo requiere la instalación de los equipos locales (cámaras, servidores, etc.). Para la visualización remota, solo se requiere un computador equipado con un browser para Internet (capaz de ejecutar una máquina virtual Java) y una conexión adecuada a los servidores del edificio integrado por computador (por medio de Internet o una conexión privada intranet).

2

SERVICIOS

Los diálogos entre el servidor y el cliente son a través de mensajes de texto. Los servicios que puede brindar el SI propuesto se orientan a la administración de la imagen adquirida por la cámara y a los movimientos de las cámaras robotizadas (pant-tilt). Información de la cámara: Con este comando se brinda la información de la posición de la cámara y el tamaño de la imagen. Lectura de una imagen: Este comando envía la imagen que es adquirida por el frame grabber. Esta imagen se puede enviar sin comprimir ó utilizando compresión JPEG. Observación continua de una cámara: Existen dos comandos para este servicio, uno para entrar en modo observación continua y otro para salir. En este modo la imagen adquirida por el frame grabber sólo es enviada al cliente si existe un cambio significativo con respecto a la imagen enviada anteriormente. Monitoreo del estado de la cámara: Este comando es utilizado por una conexión especial del cliente de visualización y permite informar del estado de las

El servidor de imágenes esta realizado en Visual C++ 4.0 [Microsoft, 1995] y la cantidad de conexiones que puede atender solo esta limitada por la cantidad de memoria que tiene instalada la PC. La cantidad de cámaras que puede administrar depende del frame grabber instalado. En este trabajo se utilizó un frame grabber que soporta hasta 4 cámaras. 3.1

Módulo principal ejecutable

Este módulo es una aplicación de 32 bits ejecutable en plataforma Windows 95. Se encarga de todas las funciones del SI excepto de la adquisición de imágenes. Tiene soporte WINSOCK para la administración de conexiones, se encarga del enlace con el módulo de adquisición y del procesamiento digital de imágenes. 3.2

Módulo de adquisición

El desarrollo del SI se realizó de tal manera qué sea independiente del hardware de adquisición de imágenes (frame grabber) utilizado. Para lograr esto se desarrolló un módulo en una biblioteca de enlace dinámico (DLL), que posee procedimientos de bajo nivel capaz de manejar todas las características ofrecidas por el hardware de interés. Se pueden utilizar distintos frame grabber, o placas de adquisición de imágenes, implementando este módulo e indicándolo en el archivo de inicialización del servidor. Este módulo fue realizado en C estándar para Windows.

4

IMPLEMENTACIÓN DEL SI

La aplicación está desarrollada en C++ usando el paradigma de la Orientación a Objetos, por lo que esta aplicación se basa en objetos de distintas clases. La jerarquía de las principales clases se observa en la Fig.2. De acuerdo a su funcionalidad se pueden dividir en: 4.1

Clase básica de la aplicación

Clase CImageServerApp: Derivada de la clase CWinApp que encapsula la iniciación, ejecución y conclusión de una aplicación Windows, o sea lo que

se denomina hilo de ejecución principal (thread) de la aplicación. La aplicación actual tiene un solo hilo de ejecución. Aunque la plataforma permite múltiples hilos de ejecución, no se consideró necesaria esta técnica para el caso del servidor de imágenes, si bien no queda totalmente descartada su utilización en trabajos futuros. Existe un solo objeto de esta clase que se encarga de inicializar los otros objetos, principalmente el de la ventana de la aplicación. CObject

CWinApp

Aplicación

Enlace con Hardware CFrameGrabber

CImageServerApp CCamera CDialog

Soporte Winsock CServerSocket

CClientSocket

Fig. 2. Jerarquía de clases del SI 4.2

Clase de soporte de Windows

Clase CImageServerDlg: Derivada de la clase CDialog que atiende los eventos y funciones de la interfase visual. El objeto aplicación crea un solo objeto de este tipo con la única finalidad de tener un medio para interactuar con el servidor: arrancarlo, detenerlo y visualizar su estado. En la versión final, esta clase no sería necesaria. 4.3

Clases de soporte de red (Winsock)

Clase CServerSocket: Derivada de la clase CSocket que encapsula Windows Socket. Un objeto de esta clase es el encargado de atender cualquier petición de una nueva conexión y administrar estas conexiones, actualizando información cuando sea necesario. Clase CClientSocket: Tambien derivada de la CSocket. El objeto CServerSocket creará tantos objetos CClientSocket cómo conexiones aceptadas. Estos objetos se encargan del diálogo con el cliente y atienden sus solicitudes. 4.4

ACTUALIZACIÓN DE IMÁGENES

La actualización de imágenes en modo de observación continua sólo se realiza si se detecta una variación en la imagen adquirida con respecto a la anterior, simulando un sensor virtual de movimiento. Esto se logra, adquiriendo y procesando imágenes consecutivas detectando los cambios locales a la escena que se consideren significativos. El procesamiento digital de imágenes se realiza contrastando la imagen enviada por última vez y la imagen recién adquirida, si se detecta una modificación se envía utilizando compresión JPEG. El proceso consiste en las siguientes etapas:

Soporte de ventana CImageServerDlg

CSocket

5

Clases de enlace con el hardware

Clase CFrameGrabber: Un objeto de esta clase es el encargado de encapsular los accesos al hardware a través del módulo de adquisición. Clase CCamera: Esta clase es la que se encarga de la administración de la imagen, y del procesamiento digital de imágenes asociado, para la actualización ó no de la imagen en el cliente. Existe un objeto de esta clase por cada entrada de cámara que el Frame Grabber posea, en este caso cuatro.

5.1

Preparación

El objetivo de esta etapa es el de normalizar las imágenes con respecto a su luminosidad. Este procedimiento permite que los cambios de iluminación del ambiente no afecten al resultado del procesamiento, agregando robustez al algoritmo. El algoritmo utilizado es el denominado estiramiento de histograma, que permite ampliar el rango dinámico de luminosidad de las imágenes. A cada imagen obtenida se le aplica este estiramiento haciendo que sus histogramas ocupen todo el rango dinámico posible [Harley, et.al., 1993]. 5.2

Comparación

Con las imágenes normalizadas se calcula una imagen de luminosidad media contra la cual se contrasta una de ellas. El histograma de esta imagen diferencia da información de la variación de la imagen. Si existe una diferencia significativa, la imagen adquirida se envía a las conexiones que estén en modo de observación continua de imágenes ó solo se envía la información de actualización para las conexiones que estén monitoreando el estado de la cámara (sensor virtual de movimiento). Para detectar la diferencia se utiliza dos umbrales de decisión: uno denominado sensibilidad y es el que mide el tamaño mínimo de objeto de la imagen que será detectado como variación. Este umbral está relacionado con la cantidad de pixeles diferentes de la imagen. El segundo umbral, denominado dispersión, está relacionado con la mínima variación de luminosidad que se detectará y se regula según la iluminación ambiente. 5.3

Compresión

La utilización de compresión JPEG es muy útil para mantener el balance de carga de la red. Si el cliente detecta que la tasa de transmisión de bytes del enlace disminuye por aumento del tráfico en el mismo, tiene la posibilidad de solicitar una modificación en el parámetro de calidad de la imagen en el algoritmo de compresión del servidor, disminuyéndolo, de forma

6 Nº de pixeles con igual nivel de gris

Niveles de gris

Sensibilidad

Dispersión

ESTRUCTURA DEL CLIENTE

El módulo cliente, que permite visualizar la información de las cámaras de vídeo, forma parte de una aplicación de mayor envergadura destinada no solo a supervisar los aspectos de seguridad de un EIC en forma remota, sino también parámetros de consumo energético (iluminación, HVAC, etc.), y de confort (temperatura, humedad, etc.) [Lehto,1997]. Los clientes son módulos de software desarrollados totalmente en lenguaje Java v1.0.2, esta tecnología permite que el mismo programa pueda ejecutarse localmente como una aplicación stand-alone o bien como una mini-aplicación Java insertada en una página Web. Procediendo de esta forma se elimina totalmente la distribución de software, se reducen significativamente los tiempos de aprendizaje por parte de los operadores. y se brinda soporte multiplataforma.

Fig. 3. Histogramas imagen diferencia tal de incrementar la relación de compresión y disminuir el tamaño del paquete de bytes enviado al cliente. La relación de la compresión promedio obtenida para una calidad de imagen del 75% y una resolución de 200 por 160 pixels es de 10 a 1. El tiempo de transferencia obtenido para una imagen sin comprimir con la resolución dada, se encuentra entre 100 a 110 milisegundos, y comprimida en el orden del milisegundo, logrando una mejora de 1 a 100 en velocidad de transferencia.

7

IMPLEMENTACIÓN DEL CLIENTE

La aplicación de visualización está basada en la cooperación entre tres clases básicas y tres de soporte (Fig. 4). Para describir claramente el mecanismo de cooperación entre los diferentes objetos que intervienen en esta aplicación, es necesario dar una breve descripción de las funciones realizadas por cada uno de ellos. Object Interfase Runnable

Canvas

5.4

Resultados ImageLoader

El principal problema que se soluciona aplicando este procesamiento de imágenes es que las variaciones de globales de luminosidad de la escena no se detectan como movimientos. Estos cambios de luminosidad son ocasionados por la iluminación con tubos fluorescentes típica en los edificios actuales. Lo que se detecta como movimiento son los cambios locales de luminosidad. El primer histograma de la Fig. 3 surge de calcular la imagen diferencia de dos imágenes consecutivas de una misma escena, donde la variación de luminosidad es debida únicamente a la variación de la luz ambiente. El segundo histograma de la Fig. 3 corresponde a la diferencia entre dos imágenes que tienen una variación local de luminosidad. En este último se observa claramente que el histograma tiene un rango dinámico mayor que el anterior (mayor dispersión) lo cual es indicativo de una variación local en la escena, no solo de luminosidad sino de un cambio de imagen.

Frame

CameraBrowser

TCPClient ChannelOfInt TCPRedirectionLayer ISResponseParser

Fig. 4. Jerarquía de clases del cliente 7.1

Clases de soporte

Clase ISResponseParser: La definición de esta clase provee los métodos necesarios para analizar sintácticamente las respuestas recibidas desde el servidor de imágenes y proveer las definiciones

simbólicas para codificar los mensajes que serán enviados al mismo. El constructor de esta clase recibe como parámetro una cadena de caracteres conteniendo el mensaje de respuesta a ser analizado y la clase provee métodos para extraer del mismo los códigos de error, dimensiones de la imagen y código de servicio solicitado entre otras cosas.

Clase CameraBrowser: Esta clase, derivada de Frame (Java AWT) es la ventana que la aplicación muestra al usuario y le permite interactuar con la cámara remota. Posee dos áreas claramente definidas (Fig. 5): área de imagen y área de comandos.

Clase TCPRedirectionLayer: Esta clase es de vital importancia para toda la aplicación por cuanto establece en tiempo de ejecución la vía que seguirán los mensajes TCP/IP originados y recibidos por la misma. Dado que la aplicación puede ejecutarse tanto en modo stand-alone como en modo applet, es necesario discriminar en cada caso si las solicitudes de conexión a los servidores remotos serán directas a ellos (modo stand-alone) o a través de un servidor proxy (modo applet) [Campione, Walrath, 1997]. Clase TCPClient: Los métodos de la clase TCPClient implementan la interfase programática de conexiones TCP/IP entre la aplicación y los servidores del EIC. El constructor de la clase recibe como parámetros el nombre del host y el número de port al cual crear el enlace. Mediante una instancia de la clase TCPRedirectionLayer obtiene el socket y los canales entrada/salida por los cuales recibirá y enviará la información. 7.2

Clases básicas

Estas clases son las que brindan la interfase de usuario de la aplicación, permitiendo la visualización de la imagen remota, la selección del modo de actualización (a demanda o continuo) y el envío de los comandos de movimiento a la cámara. Debido a las características bloqueantes de los métodos de los objetos Socket para el enlace, estas clases hacen uso intensivo de las facilidades de “multithreading” provistas por Java. Clase ImageLoader: La clase ImageLoader es derivada de la superclase Canvas (Java AWT), la cual representa un objeto gráfico genérico cuyos métodos deben sobrecargarse para proporcionarle apariencia definida. En este caso, la clase ImageLoader tiene por misión recibir la información proveniente del SI, y en el caso de ser imágenes, visualizarlas. Los objetos instanciados de esta clase son capaces de detectar si el servidor está usando compresión JPEG o no, y actuar acorde con ello. Esta clase implementa la interfase Runnable [Campione and Walrath,1997] que le permite crear un thread de ejecución concurrente [Lea, 1997; Davis, 1996], en el cual se procesa toda la información proveniente del SI a medida que arriba. La clase ImageLoader está diseñada para trabajar en estrecha colaboración con la clase CameraBrowser, quien la contiene como variable de instancia.

Fig. 5. Aspecto del cliente El área de imagen corresponde a la imagen mostrada por la clase ImageLoader contenida. Esta área es actualizada cuando el usuario envía una petición de refresco al servidor, o bien cuando el usuario selecciona el modo de observación continua y el servidor decide actualizar la imagen del cliente. El área de comandos solo es un conjunto de botones que dan acceso a los servicios soportados por SI. En total existen ocho botones, cuatro de los cuales están destinados a los comandos de movimiento (Arriba, Abajo, Derecha, Izquierda), uno a la lectura a demanda, dos a la selección de modo de observación continua (entrar y salir de este modo) y el último para cerrar el visualizador. Esta clase también implementa la interfase Runnable para crear un hilo de ejecución concurrente destinado principalmente a actualizar el estado de algunos botones (por ejemplo deshabilitar el botón de comenzar monitoreo si el mismo ha comenzado y habilitar el botón de finalizar monitoreo en ese caso). Este proceso debe ejecutarse en forma concurrente por cuanto es preciso esperar la respuesta del servidor confirmando o rechazando la acción pedida y la decisión es tomada por el thread que se ejecuta en la clase ImageLoader. Clase ChannelOfInt: La presencia de esta clase obedece a la necesidad de sincronizar [Lea,1997] el thread de actualización del área de comandos de la clase CameraBrowser con el thread de recepción de la clase ImageLoader. Su implementación está basada en el mecanismo de sincronización de procesos secuenciales concurrentes utilizado por el lenguaje OCCAM para transputers. De esta forma se impide que un thread modifique en cualquier momento el estado de un objeto compartido por otro thread ya que es imposible conocer a priori en que estado se encuentra ese objeto en el momento del acceso al mismo y cual es el proceso que lo accede.

Solicitudes de actualización de usuario

Clase contenedora CameraBrowser

Actualización del estado de la ventana

Thread de CameraBrowser

M étodos de CameraBrowser

Objeto miembro compartido ChannelOfInt

objeto ISResponse Parser

M étodos de ImageLoader

Thread ImageLoader

objeto TCPClient Objeto M iembro ImageLoader

objeto TCPRedirection Layer

M odo de aplicación Stand-Alone

M odo applet Servidores del EIC

Fig. 6. Interacción de componentes del objeto CameraBrowser Dado que la implementación de ChannelOfInt es unidireccional (el thread de CameraBrowser lee y el de ImageLoader escribe) no existe posibilidad de dead-lock entre los procesos. La Fig.6 esquematiza la colaboración entre los distintos objetos que constituyen el visualizador remoto.

8

CONCLUSIONES

Se ha presentado un método alternativo a los sistemas convencionales de CCTV para la supervisión de áreas en edificios. Si bien no proporciona visualización de las imágenes en vivo, el procesamiento de las mismas por parte del servidor, su habilidad para la actualización automática simulando sensores de movimiento virtuales y la utilización de compresión JPEG para transferir imágenes permite reducir drásticamente los requerimientos de ancho de banda y de hardware necesario para llevar a cabo estas tareas, manteniendo aún las prestaciones del mismo nivel, con mayor flexibilidad de aplicación y menor costo, ignorando información redundante. Como paso posterior se incluirá el servicio de seguimiento de objetos en movimiento con las cámaras robotizadas (tracking).

9

BIBLIOGRAFÍA

Campione, M. and Walrath, K. (1997) The Java Tutorial - Object Oriented Programming for the Internet. - Addison Wesley.

Clark, G., Mehta P., et.al (1995) Intelligent integrated building management systems. Proceedings of IB/IC Intelligent Buildings Congress, Tel-Aviv, Israel. Davis, S.R. (1996) Learn Java Now. Microsoft Press. Gomes, L., Costa, A., et. al (1997) Campus-Guard: a domot targeted for integrated building monitoring and control. 2nd International Congress on Intelligent Buildings, Tel Aviv, Israel. Harley, R. Myler, Arthur R., Weeks (1993) Computer Imaging Recipes. Prentice Hall. Lea, D. (1997) Concurrent Programming in Java – Desing Principles and Patterns. Addison Wesley. Lehto Mervi (1997). Intelligent building research VTT Building Technology project. Martín, M., Zavalla, E.,(1997) Arquitectura distribuida para edificios integrados por computador. Anales I Wokshop SintEd, Bogotá, Colombia. Microsoft Corporation (1995). Programming with MFC. Microsoft Press.