SISTEMA DE SUPERVISIÓN Y TELECONTROL DE UNA RED DE RADIO DIFUSIÓN A TRAVES DE INTERNET Joan Aranda Dep. Enginyeria de Sistemes, Automàtica i Informàtica Industrial Universitat Politècnica de Catalunya (UPC) Pau Gargallo,5. 08028 Barcelona [email protected] Eduard Sanz Cap de Sistemes de Telecontrol Difusió Digital S.T.S.A-Tradia Resumen En esta comunicación se presenta una aplicación reciente que utiliza internet como herramienta de supervisión y telecontrol de una red de radio difusión para ofrecer un mejor servicio a posibles clientes. El aplicativo se ha implementado sobre un PC equipado con Windows NT 4.0 y se ha desarrollado utilizando herramientas VisualStudio6.0. Se han cuidado especialmente los aspectos de seguridad de acceso y comunicaciones. Palabras Clave: Telecontrol, Supervisión Remota, Internet, seguridad, SCADA, Radio difusión. 1 INTRODUCCIÓN Un operador de una red de telecomunicaciones (el operador, de ahora en adelante) dispone de un sistema de telecontrol y telesupervisión de su red de radio, incluyendo infraestructuras y equipamientos. La aplicación central de este sistema cuenta con un Scada en tiempo real con un sistema de polling continuo contra un front-end de comunicaciones que concentra las comunicaciones con diferentes estaciones remotas de telecontrol (fig. 1) El operador se plantea la viabilidad de llevar a cabo la implementación de un aplicativo que permita solventar las limitaciones de seguridad de su sistema Scada y que posibilite la supervisión y telecontrol de terceros a infraestructuras propiedad del Operador conectadas a la red de telecontrol corporativa. La incorporación de nuevas funcionalidades que sean atractivas para este tipo de usuarios, pretende ser un valor añadido para el cliente, que le decante a la hora de tomar la decisión de contratar unos determinados servicios de housing con el operador. 2 OBJETIVOS El objetivo del proyecto consiste en analizar los requerimientos y diseñar un sistema de telecontrol abierto, utilizando la infraestructura de estaciones remotas de telecontrol y el sistema Scada existentes, propiedad del Operador. Inicialmente, se pretende dar este servicio de telecontrol a clientes del Operador, a través de un medio de comunicación de ancho de banda reducida (red telefónica conmutada, por ejemplo). A partir del conocimiento que dispone el Operador de las problemáticas de gestión de red, este considera que las funcionalidades necesarias para hacer atractivo el producto al cliente son las siguientes: 1. 2. 3. 4. 5. 6. 7. Visualización de datos de Telecontrol personalizadas a nivel de cliente (1 cliente – n señalizaciones). La visualización de estados digitales de canales conectados al sistema de Telecontrol corporativo en “tiempo real”(dependiendo únicamente del ancho de banda disponible). La visualización de medidas analógicas en “tiempo real”. Posibilidad de visualización de un listado con los últimos eventos generados por los canales que pertenecen a un determinado cliente. Posibilidad de incluir enlaces a otras páginas estáticas contenidas al mismo o a otros servidores, o envio de e-mail a la persona de contacto (webmaster). Conexión segura.La conexión con el cliente deberá hacerse a través de una conexión segura, con algún tipo de certificado y encriptación en el caso de envío de comandos. Ejecución de comandos. Se permitirá al cliente la actuación sobre determinados canales de Cliente Servidor WEB SCADA Front-End http (TCP/IP) INTERNET SNMP/OBDC Centros de difusión Figura 1. Arquitectura general del sistema tipo salida digital, con la interfície necesaria de aviso y reconocimiento por parte del usuario del tipo de envío que se está a punto de realizar. Se generará un archivo de log de los comandos efectuados por todos los usuarios. 8. Movimiento entre pantallas de sinópticos. Se permitirá al administrador la facilidad de enlazar varias páginas de clientes, dando la posibilidad de pasar de una página a otra haciendo click sobre algún icono dentro del área de visualización. Se generará un registro de visitas. 9. Almacenamiento de medidas analógicas. Se guardarán los valores analógicos con marca de tiempo, en intervalos definidos por el cliente y a con un número máximo de valores definido por el administrador. Esto deberá hacerse a través de la interrogación automática de las variables del sistema Scada sin intervención del cliente. Se diseñará la interfície necesaria para la selección de estos parámetros. 10. Función de conversión y limites de medidas analógicas. Se implementará una función de conversión simple (proporcional y offset), por la presentación de los valores analógicos. Además, se darán unos valores máximo y mínimo de la medida, de manera que, superados aquellos límites, se presente el valor correspondiente. 11. Gráfica de evolución de medidas analógicas. Se creará una gráfica dinámicamente con los valores de las medidas analógicas obtenidos de la interrogación periódica del punto 9. 12. Filtrado de eventos. Se permitirá al usuario filtrar los eventos por los posibles valores obtenidos, en cada uno de los campos mostrados. Se permitirá al administrador seleccionar los campos a mostrar y el orden en que aparezcan. 13. Pantalla de informes. Se creará una página por la elaboración rápida de informes para uso interno, con el filtrado de eventos descrito anteriormente. 14. Aviso automático por e-mail de determinados eventos. Por cada canal que tenga activada esta funcionalidad se dará un tiempo de histéresis a 0 y a 1. La activación de esta funcionalidad así como la dirección de correo podrá ser elegida por el usuario. Se generará un log con los mensajes enviados. 15. Aviso automático por SMS a teléfonos móviles GSM. Se determinará una histéresis, y posibilidad de activación por el cliente. El número de teléfono será escogido por el usuario y se dará un número máximo de mensajes a enviar. Se generará un log con los mensajes enviados. El mecanismo de envio se coordinará con personal del Operador. 16. Página visualización de vídeo lento. Se diseñará un página tipo donde se podrá visualizar vídeo lento (imágenes jpeg, gif,...) que se volcarán desde un sistema externo en un directorio del servidor web. El tiempo de refresco será parametrizable y la página deberá poder enlazarse con otras páginas del web. Los procesos más importantes deberán dejar ficheros de log, dando la posibilidad de rastrear posibles malfuncionamientos. El operador pretende en un primer momento dar un servicio de supervisión y control integral a distancia a un número indeterminado de sus clientes. Por tanto, el dimensionado del sistema no es posible a priori. Bajo esta premisa, el sistema ha de ser fácilmente escalable. 3 ESPECIFICACIONES DISEÑO DEL SISTEMA 3.1 Consideraciones previas Y En primer lugar, es necesario conocer que el operador pretende que el proyecto tenga entidad de prueba piloto. Coherente con este planteamiento, la solución final, no puede estar ligada a un único proveedor. Mas allá de los inconvenientes obvios que tiene esta situación de fuerza por parte del proveedor en cualquier proyecto, la falta de datos para el correcto dimensionado del sistema, hace pensar en la necesidad de realizar modificaciones en un futuro, cuando sea necesario ampliar el sistema para soportar un mayor número de usuarios. Una re-ingenieria del sistema Scada por parte del proveedor del software, haría difícil en el futuro a otros proveedores ofertar una ampliación del sistema para cubrir nuevas necesidades. Es imprescindible asegurar que el proveedor facilite los ficheros fuente de la solución final del aplicativo y una documentación suficiente al Operador. La filosofía de empresa del proveedor del software del sistema Scada de telecontol corporativo del Operador no considera la posibilidad de entregar los ficheros fuentes de sus desarrollos al cliente. Por tanto, se desestima el enfoque del proyecto como una ampliación de funcionalidades del actual sistema Scada. A continuación, se debe tener en cuenta la infraestructura de sistemas existente dentro del entorno de telecontrol. A través de la aplicación Scada no es posible el filtrado necesario de los datos para permitir a un cliente del operador una conexión directa contra la aplicación, como un usuario más. Debemos considerar también cuales serán los medios de comunicación que dispondrá el cliente para conectarse al aplicativo. En la mayoría de los casos, de entre los clientes que han demostrado interés en este tipo de servicio, la conexión deberá establecerse a través de la red telefónica conmutada, por lo que el ancho de banda será limitado. Por este motivo, no es viable una solución basada en X-Windows, como extensión del propio sistema Scada, por los requerimientos de ancho de banda que este sistema de visualización necesita. El aplicativo se presenta como una herramienta de incalculable valor para el cliente del Operador, por garantizar en todo momento la continuidad de servicio. Así, los trabajos de mantenimiento y seguimiento de averías o incidencias, serán mucho más eficaces con un sistema de las características planteadas. La determinación del origen de un problema será considerablemente más rápida, y repercutirá en un servicio de una calidad superior. Para entender la problemática implícita, pondremos un ejemplo sencillo. Un cliente tipo del Operador podría ser un difusor de radio. Un técnico al cargo de las emisoras y reemisores de dicho difusor de FM, podría necesitar conocer la potencia nominal de salida y los parámetros vitales de la emisora bajo la cual está realizando medidas de campo. Otro ejemplo: muchos difusores no disponen de personal permanente las veinticuatro horas del día que pueda monitorizar desde los estudios la continuidad de la emisión. Así, la posibilidad de conexión desde un PC personal desde el domicilio particular de la persona de guardia, permitiría evitar desplazamientos innecesarios. Por eso se piensa que la solución final no ha de estar ligada a una única plataforma, ni medio de comunicación. El aplicativo deberá permitir la conexión remota utilizando la red telefónica conmutada, o incluso la conexión mediante una línea de datos de un teléfono móvil GSM. Dada la incertidumbre en cuanto a número de usuarios concurrentes, se valora muy positivamente la utilización de una infraestructura de red existente como Internet, frente al montaje de un sistema remoto de acceso para los clientes usuarios de este servicio. Sin embargo, no se descarta la implantación de un sistema de estas características en un futuro. 3.2 Sistema de telecontrol corporativo La arquitectura hardware del centro de control está formada por dos servidores HP9000, un array de disco y dos servidores de terminales de 16 puertos cada uno, que conectan con el front-end de comunicaciones, así como dos consolas gráficas con monitores de 21”. Los servidores forman un cluster MC/Service Guard, conectados por red y con la redundancia suficiente para que un error en uno de los componentes no interrumpa de forma significativa el servicio. Se cuenta con redundancia de interfaces de LAN, discos con espejo y duplicidad de fuentes de alimentación y ventilación, y redundancia de CPUs en el servidor principal. Los servidores de terminales conectan con el front-end de comunicaciones a traves de un commutador pasivo que está controlado por uno de los procesos del sistema de alta disponibilidad MC/Service Guard. La gestión de datos se realiza con una base de datos relacional Oracle, para los datos históricos y de configuración, una base de datos de tiempo real que almacena los valores y estados del sistema, y una base de datos de alarmas que gestiona los diferentes eventos en función de su criticidad, y las actuaciones del operador como respuesta a estos eventos. El sistema permite la supervisión de hasta 254 estaciones remotas de telecontrol sobre una misma línea de comunicaciones, usando protocolo Gestel. La conexión de éstas se hace a través de la red corporativa de nodos cross-connect, utilizando interficies V-24 y estructuras punto-multipunto. Actualmente hay operativas 10 líneas remotas y podrían llegar a ser 16, con el hardware existente. En su configuración actual, el sistema reporta estados, alarmas y es capaz de ejecutar comandos en un total de 92 ubicaciones remotas, sobre un total de 780 equipos. El control efectuado sobre estos equipos, implica la configuración de 7400 canales de entrada digital, 1700 salidas digitales y 500 medidas analógicas. Esta información es captada por las estaciones remotas a través de tarjetas de entrada/salida o vía protocolo RS-232. El sistema también permite la comunicación con otros servidores a través de UDP y TCP/IP, utilizando el estándar SNMP (Simple Network Management Protocol). 365 dias al año, su escalabilidad y su seguridad. Para WNT juegan a su favor la facilidad de implementación en poco tiempo y los costes de programador, productos y hardware asociado más barato. El presupuesto asignado a la creación de este aplicativo por parte del Operador no permite la implementación en entornos Unix, por lo que finalmente se decide utilizar WNT 4.0 como sistema operativo y Visual Studio 6.0 como herramienta de desarrollo. El software utilizado se compone de: • Sistema Operativo: Windows NT 4.0 • Software de base: IIS 4.0 (Internet Information Server) • Seguridad: SSL (Secure Sockets Layer) • Base de datos: SQL Server 7.0 • Protocolo de intercambio: SNMP (Simple Network Management Protocol) • Ficheros de log: XML • Componentes ActiveX. En cuanto al hardware un PC de última generación ha demostrado ser suficiente para soportar el potencial número inicial de usuarios. La solución planteada, consta de los siguientes elementos (figura 3): 1. Base de datos SQL Server 7.0 Con información de los clientes, canales, parámetros, etc. Los datos de tipo histórico están almacenados en la base de datos Oracle del servidor donde corre el SCADA. 2. Base de datos ORACLE Contiene la información histórica de alarmas y ciertos parámetros de configuración de las señales de salida digital. Figura 2. Interfície SCADA: Pantalla de sinópticos para la operación en tiempo real de un sistema reemisor de televisión. 4 IMPLEMENTACIÓN La primera decisión corresponde a seleccionar el sistema operativo sobre el que se montará el aplicativo. Teniendo en cuenta la experiencia prévia, se barajan dos posibilidades: UNIX y Windows NT. Las ventajas del primero radican en su fiabilidad probada en sistemas funcionando 24h, 3. El servidor WWW Actua como interficie de la aplicación. El usuario lo utiliza para efectuar diversas consultas y como mecanismo de configuración de los servicios de seguimiento de canales. El administrador del sistema, dispone de la correspondiente interficie web de administración. 4. Componentes ActiveX Proporcionan un conjunto de utilidades esenciales para la aplicación. 5. Servicios NT El sistema dispone de tres servicios propios en ejecución: seguimiento de canales digitales, seguimiento de canales analógicos y registro de la información capturada. 4.1 Funcionamiento 3. La comunicación se establece a través de la siguiente secuencia de operaciones: 4. 1. 2. El servidor web recibe peticiones de los clientes http (navegadores de internet), descargando las imágenes estáticas i dinámicas, que se guardan en el disco duro del PC del cliente. El cliente hace la petición de la información de telecontrol de los servicios contratados. 5. El servidor pide la información en tiempo real a través del protocolo SNMP al sistema de telecontrol corporativo. El servidor ofrece la información al cliente y este refresca la representación en la máquina local. La operación se efectúa a la frecuencia fijada por el administrador del sistema. Además de la información en tiempo real, el cliente puede solicitar información histórica que el servidor web adquiere de la base de datos del sistema de control corporativo. Datos en tiempo real: MIB SNMP Aplicación cliente: Navegador SERVIDOR WEB Datos históricos: BBDD ORACLE Datos de configuración: BBDD SQLServer CLIENTE SERVIDOR SISTEMA SCADA Figura 3. Estructura de datos de la aplicación PC CLIENTE (NAVEGADOR) Internet SERVIDOR WEB Zona segura (DMZ) Figura 4. Funcionamiento del sistema SISTEMA SCADA Red Operador 5 SEGURIDAD DE REDES La necesidad de implementación de mecanismos de seguridad sobre internet, proviene de dos necesidades básicas. En primer lugar es necesario controlar quien puede navegar en nuestro site. Se necesitan garantías de seguridad del sistema, para evitar el acceso fraudulento a la información mediante la red. De esta manera se necesita un control de acceso que evite que cualquier persona no autorizada, sean cuales sean sus intenciones, sea capaz de hacer uso de recursos o información contenida en el sistema. Por otro lado, se debe garantizar la seguridad de comunicaciones. Se debe asegurar que la información transportada a través de la red no pueda ser interceptada por un observador no deseado. Por tanto, es necesario asegurar la identidad del usuario conectado a nuestro sistema, con el objetivo de tener la fiabilidad de que la información confidencial que se envía será solamente conocida por el destinatario. Ambos entornos se encuentran estrechamente relacionados en muchos aspectos, pero las soluciones asociadas suelen ser atribuidas a diferentes niveles y siguiendo políticas totalmente diferentes. La autentificación del usuario (control de acceso) suele ser una labor generalmente atribuida al sistema operativo, o a elementos propios de la red, como son los firewalls. En cambio, la responsabilidad de la seguridad de comunicaciones recae normalmente en el aplicativo, o a elementos con entidad propia integrados en el mismo. Toda la seguridad de Windows NT, así como otros sistemas operativos susceptibles de recibir ataques, está basada en cuentas de usuario. En el escenario que nos ocupa, donde el usuario ha de entrar dentro de una única máquina, no tenemos la necesidad de autentificar nuestro visitante como usuario de dominio de nuestra red. Esto implica directamente, que únicamente estará dado de alta en la base de datos de usuarios de la máquina local. Para permitir una gestión ordenada de los usuarios por parte del administrador o administradores de un sistema, los usuarios se organizan en grupos. Estos grupos están basados en un conjunto de rols comunes a todos los usuarios que pertenecen a ellos, definiendo en cada caso un nivel de privilegios y de derechos. Los derechos de un usuario a realizar cualquier acción sobre el sistema, están asociados al propio servicio de la máquina a la que se está accediendo. Esto quiere decir que, en lugar de almacenar lo que cada usuario está autorizado o no a hacer con la información relativa al usuario, esta información se guarda con el propio fichero al cual se pretende acceder. Esta afirmación es igualmente cierta para el registro del sistema. Así, las políticas de seguridad del sistema se guardan en un lugar centralizado, con derechos de acceso a él. El hecho de que toda esta información es independiente de la información de la cuenta de usuario, tiene una consecuencia importante: el objetivo principal de una cuenta de usuario es tener un listado de las credenciales de usuario. Esto quiere decir que todos los derechos de acceso acaban en una cuenta de usuario (los derechos de modificar el registro de sistema son derechos de acceso a un fichero determinado). En nuestro caso concreto, el control de quien puede conectarse a nuestra web-site y acceder a determinados ficheros, está gestionado a través de la combinación de la seguridad implementada en el sistema operativo Windows NT y Internet Information Server. En cambio, la función de hacer posible la transmisión de la información de forma segura pertenece a Secure Sockets Layer. 5.2 Secure Sockets Layer (SSL) 5.1 Seguridad de Windows NT SSL se basa en el concepto de canal seguro. Este canal garantiza confidencialidad puesto que todos los mensajes que pasan por él están encriptados. SSL no encripta ninguna información guardada en el cliente o en el servidor. El sistema operativo escogido involucra algún tipo de comprobación de seguridad a cualquier acción ejecutada (intentos de acceso a ficheros, logon sobre una estación de trabajo...), que habitualmente es transparente para el usuario. Esto sucede cuando un determinado usuario tiene los permisos suficientes para ejecutar acciones sobre la propia máquina (por ejemplo actuando como administrador). La tecnología SSL proporciona dos funcionalidades. Por un lado encripta el flujo de información entre el cliente y el servidor, y por otro lado fija las bases para la autentificación entre cliente-servidor. SSL fue desarrollado por Netscape el año 1994 y actualmente se encuentra en la tercera revisión. SSL integra seguridad sobre protocolos al nivel de aplicación como HTTP, NNTP, y Telnet. SSL proporciona un handshake de seguridad al iniciar una conexión TCP/IP, resultando en una negociación entre servidor y cliente del nivel de seguridad utilizado, y satisfaciendo cualquier requerimiento de firma digital por la conexión. mostrar el estado del tiempo en diferentes lugares, etc. (figura 7). Desde este momento, si la encriptación del mensaje es activa (estado por defecto), SSL encripta y desencripta la cadena de byte del protocolo de aplicación utilizado en el momento. Esto quiere decir que la información en la petición HTTP y la respuesta están totalmente encriptadas, incluyendo la URL que el cliente está pidiendo, cualquier contenido de formulario enviado, cualquier información de acceso HTTP y toda la información enviada por el servidor hacia el cliente. SSL utiliza el sistema de clave pública para intercambiar una clave entre cliente y servidor. Esta clave de sesión es exclusivamente generada por cada una de las conexiones cliente-servidor y se utiliza para encriptar la transacción GTTP. La criptografía de clave pública se utiliza únicamente para la verificación mutua y para encriptar la llave de la sesión; SSL utiliza la encriptación de llave simétrica (significativamente más rápida que la criptografía de llave pública) para encriptar la sesión. Cada una de las transacciones utiliza una clave de sesión diferente, por lo que aunque alguien robase una clave no implica conseguir la clave para desencriptar múltiples sesiones. Figura 5. Red de difusión del operador Al añadir cualquier capa de seguridad a una transacción se ralentizan los procesos del servidor de alguna manera y SSL no es ninguna excepción. La sobrecarga, no obstante, es ligera, y los beneficios allí donde la seguridad es necesaria superan los riesgos que se corren al no implementar ningún sistema de seguridad. 6 RESULTADOS Figura 6. Acceso a históricos Se ha diseñado una interficie amigable y funcional, que permite al cliente percibir el trabajo llevado a cabo y los niveles de los detalles considerados (figura 5). Resuelve limitaciones funcionales del sistema Scada para uso interno del Operador, como la gestión masiva de alarmas. En este contexto, el aplicativo desarrollado hace rentable en parte la inversión sólo como herramienta de confección de informes internos, para la gestión de calidad de servicio propio del operador (figura 6). Además se han introducido de manera satisfactoria, funcionalidades que pueden llamar la atención del cliente y derivar en la prestación de nuevos servicios a contratar, como puede ser la transmisión de vídeo lento, para la inclusión de imágenes a su propia web, cámaras de vigilancia, tránsito (a través de Digital Audio Broadcasting, por ejemplo), beautycams para Figura 7. Imagen de un concentrador Por otro lado se ha creado la interficie necesaria para permitir al cliente parametrizar ciertos aspectos del aplicativo, con el fin de que no dependa de la disponibilidad del administrador del sistema para efectuar modificaciones de alguno de los parámetros del sistema. Así puede parametrizar el tiempo entre capturas de valores analógicos o la dirección de email donde recibirá la notificación de los sucesos que él mismo decida (figura 8). 8 LINEAS FUTURAS Es necesario tener en cuenta el carácter de prueba piloto que tiene el proyecto. El objetivo principal reside en la evaluación de las ventajas competitivas que el servicio de telesupervisión ofrece a través de la web a los clientes, en el momento de vender por parte del Operador un servicio de red. Por tanto, una vez puesta en marcha la prueba piloto será necesario analizar: • Número de clientes a los que se pretende ofrecer el servicio, para dimensionar correctamente la maquinaria. • Número de conexiones concurrentes, a fin y efecto de dimensionar el throughput necesario par dar altos índices de calidad (tiempo de respuesta del servidor). • En función de la criticidad del servicio, se deberá considerar la posibilidad de implementar una estructura de servidores redundante. • Habilitar redundancia en los enlaces que proveen conectividad del servidor con Internet. Figura 8. Pantalla para modificación de parámetros 7 CONCLUSIONES El aplicativo desarrollado responde punto por punto a los requerimientos especificados al inicio del proyecto. El seguimiento exhaustivo y las pruebas conjuntas entre quien desarrolla y el personal del operador han sido imprescindibles para el éxito del proyecto. La aplicación permite parametrizar la interficie de acuerdo con las necesidades del cliente y proporciona la flexibilidad necesaria para adaptarse a las funcionalidades que puedan ser necesarias para la telesupervisión y telecontrol de los equipamientos de terceros a infraestructuras del operador. La solución mejora algunos aspectos en cuanto a la funcionalidades del sistema Scada, como el seguimiento y almacenamiento de medidas analógicas, las gráficas históricas, y el aviso de determinados eventos a través de medios de comunicación próximos al los clientes del operador, como son el e-mail y el teléfono móvil GSM. Dentro del entorno de la prueba piloto se ha parametrizado el aplicativo para servir datos de un sistema de difusión de FM en configuración 1+1, de 10 y 5Kw de potencia de salida, respectivamente. El personal técnico del difusor ha valorado muy positivamente la prueba, pidiendo una ampliación del ámbito de la misma. A partir de este análisis posterior a la prueba piloto, el Operador podrá ofrecer un SLA (Service Level Agreement) que permitirá incluir la tarificación del servicio dentro del marco de un contrato. Referencias [1] Orfali R., Harkey D. (1998) “Client/Server Programming with Java and CORBA” Second Edition. John Wiley & Sons, Inc., New York. [2] Stallings, William, SNMP, SNMPv2, and CMIP: The practical Guide to NetworkManagement Standards, Addison-Wesley Publishing Company 1994. [3] www.verising.com; Implementing Web Site Client Authentification Using Digital Ids. [4] www.Microsoft.com: ASP Tchnology Overview. [5] www.Microsoft.com: Implementing a Secure Site with ASP