SISTEMA DE SUPERVISIN Y TELECONTROL DE UNA RED DE RADIO DIFUSIN A TRAVES DE INTERNET

Joan Aranda Dep. Enginyeria de Sistemes, Automtica i Informtica Industrial Universitat Politcnica de Catalunya (UPC) Pau Gargallo,5. 08028 Barcelona aranda@esaii.upc.es Eduard Sanz Cap de Sistemes de Telecontrol Difusi Digital S.T.S.A-Tradia

Resumen
En esta comunicacin se presenta una aplicacin reciente que utiliza internet como herramienta de supervisin y telecontrol de una red de radio difusin 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, Supervisin Remota, Internet, seguridad, SCADA, Radio difusin.

OBJETIVOS

El objetivo del proyecto consiste en analizar los requerimientos y disear 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 travs de un medio de comunicacin de ancho de banda reducida (red telefnica conmutada, por ejemplo). A partir del conocimiento que dispone el Operador de las problemticas de gestin de red, este considera que las funcionalidades necesarias para hacer atractivo el producto al cliente son las siguientes: 1. 2. Visualizacin de datos de Telecontrol personalizadas a nivel de cliente (1 cliente n sealizaciones). La visualizacin de estados digitales de canales conectados al sistema de Telecontrol corporativo en tiempo real(dependiendo nicamente del ancho de banda disponible). La visualizacin de medidas analgicas en tiempo real. Posibilidad de visualizacin de un listado con los ltimos eventos generados por los canales que pertenecen a un determinado cliente. Posibilidad de incluir enlaces a otras pginas estticas contenidas al mismo o a otros servidores, o envio de e-mail a la persona de contacto (webmaster). Conexin segura.La conexin con el cliente deber hacerse a travs de una conexin segura, con algn tipo de certificado y encriptacin en el caso de envo de comandos. Ejecucin de comandos. Se permitir al cliente la actuacin sobre determinados canales de

INTRODUCCIN

Un operador de una red de telecomunicaciones (el operador, de ahora en adelante) dispone de un sistema de telecontrol y telesupervisin de su red de radio, incluyendo infraestructuras y equipamientos. La aplicacin 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 implementacin de un aplicativo que permita solventar las limitaciones de seguridad de su sistema Scada y que posibilite la supervisin y telecontrol de terceros a infraestructuras propiedad del Operador conectadas a la red de telecontrol corporativa. La incorporacin de nuevas funcionalidades que sean atractivas para este tipo de usuarios, pretende ser un valor aadido para el cliente, que le decante a la hora de tomar la decisin de contratar unos determinados servicios de housing con el operador.

3. 4. 5.

6.

7.

Cliente Servidor WEB SCADA Front-End http (TCP/IP) INTERNET SNMP/OBDC Centros de difusin

Figura 1. Arquitectura general del sistema tipo salida digital, con la interfcie necesaria de aviso y reconocimiento por parte del usuario del tipo de envo 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 sinpticos. Se permitir al administrador la facilidad de enlazar varias pginas de clientes, dando la posibilidad de pasar de una pgina a otra haciendo click sobre algn icono dentro del rea de visualizacin. Se generar un registro de visitas. 9. Almacenamiento de medidas analgicas. Se guardarn los valores analgicos con marca de tiempo, en intervalos definidos por el cliente y a con un nmero mximo de valores definido por el administrador. Esto deber hacerse a travs de la interrogacin automtica de las variables del sistema Scada sin intervencin del cliente. Se disear la interfcie necesaria para la seleccin de estos parmetros. 10. Funcin de conversin y limites de medidas analgicas. Se implementar una funcin de conversin simple (proporcional y offset), por la presentacin de los valores analgicos. Adems, se darn unos valores mximo y mnimo de la medida, de manera que, superados aquellos lmites, se presente el valor correspondiente. 11. Grfica de evolucin de medidas analgicas. Se crear una grfica dinmicamente con los valores de las medidas analgicas obtenidos de la interrogacin peridica 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 pgina por la elaboracin rpida de informes para uso interno, con el filtrado de eventos descrito anteriormente. 14. Aviso automtico por e-mail de determinados eventos. Por cada canal que tenga activada esta funcionalidad se dar un tiempo de histresis a 0 y a 1. La activacin de esta funcionalidad as como la direccin de correo podr ser elegida por el usuario. Se generar un log con los mensajes enviados. 15. Aviso automtico por SMS a telfonos mviles GSM. Se determinar una histresis, y posibilidad de activacin por el cliente. El nmero de telfono ser escogido por el usuario y se dar un nmero mximo de mensajes a enviar. Se generar un log con los mensajes enviados. El mecanismo de envio se coordinar con personal del Operador. 16. Pgina visualizacin de vdeo lento. Se disear un pgina tipo donde se podr visualizar vdeo lento (imgenes jpeg, gif,...) que se volcarn desde un sistema externo en un directorio del servidor web. El tiempo de refresco ser parametrizable y la pgina deber poder enlazarse con otras pginas del web. Los procesos ms importantes debern dejar ficheros de log, dando la posibilidad de rastrear posibles malfuncionamientos. El operador pretende en un primer momento dar un servicio de supervisin y control integral a

distancia a un nmero indeterminado de sus clientes. Por tanto, el dimensionado del sistema no es posible a priori. Bajo esta premisa, el sistema ha de ser fcilmente escalable.

3
3.1

ESPECIFICACIONES DISEO DEL SISTEMA

Consideraciones previas

garantizar en todo momento la continuidad de servicio. As, los trabajos de mantenimiento y seguimiento de averas o incidencias, sern mucho ms eficaces con un sistema de las caractersticas planteadas. La determinacin del origen de un problema ser considerablemente ms rpida, y repercutir en un servicio de una calidad superior. Para entender la problemtica implcita, pondremos un ejemplo sencillo. Un cliente tipo del Operador podra ser un difusor de radio. Un tcnico al cargo de las emisoras y reemisores de dicho difusor de FM, podra necesitar conocer la potencia nominal de salida y los parmetros 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 da que pueda monitorizar desde los estudios la continuidad de la emisin. As, la posibilidad de conexin desde un PC personal desde el domicilio particular de la persona de guardia, permitira evitar desplazamientos innecesarios. Por eso se piensa que la solucin final no ha de estar ligada a una nica plataforma, ni medio de comunicacin. El aplicativo deber permitir la conexin remota utilizando la red telefnica conmutada, o incluso la conexin mediante una lnea de datos de un telfono mvil GSM. Dada la incertidumbre en cuanto a nmero de usuarios concurrentes, se valora muy positivamente la utilizacin 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 implantacin de un sistema de estas caractersticas en un futuro. 3.2 Sistema de telecontrol corporativo

En primer lugar, es necesario conocer que el operador pretende que el proyecto tenga entidad de prueba piloto. Coherente con este planteamiento, la solucin final, no puede estar ligada a un nico proveedor. Mas all de los inconvenientes obvios que tiene esta situacin 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 nmero de usuarios. Una re-ingenieria del sistema Scada por parte del proveedor del software, hara difcil en el futuro a otros proveedores ofertar una ampliacin del sistema para cubrir nuevas necesidades. Es imprescindible asegurar que el proveedor facilite los ficheros fuente de la solucin final del aplicativo y una documentacin suficiente al Operador. La filosofa 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 ampliacin de funcionalidades del actual sistema Scada. A continuacin, se debe tener en cuenta la infraestructura de sistemas existente dentro del entorno de telecontrol. A travs de la aplicacin Scada no es posible el filtrado necesario de los datos para permitir a un cliente del operador una conexin directa contra la aplicacin, como un usuario ms. Debemos considerar tambin cuales sern los medios de comunicacin que dispondr el cliente para conectarse al aplicativo. En la mayora de los casos, de entre los clientes que han demostrado inters en este tipo de servicio, la conexin deber establecerse a travs de la red telefnica conmutada, por lo que el ancho de banda ser limitado. Por este motivo, no es viable una solucin basada en X-Windows, como extensin del propio sistema Scada, por los requerimientos de ancho de banda que este sistema de visualizacin necesita. El aplicativo se presenta como una herramienta de incalculable valor para el cliente del Operador, por

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 grficas 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 alimentacin y ventilacin, 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 gestin de datos se realiza con una base de datos relacional Oracle, para los datos histricos y de configuracin, 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 funcin de su criticidad, y las actuaciones del operador como respuesta a estos eventos. El sistema permite la supervisin de hasta 254 estaciones remotas de telecontrol sobre una misma lnea de comunicaciones, usando protocolo Gestel. La conexin de stas se hace a travs de la red corporativa de nodos cross-connect, utilizando interficies V-24 y estructuras punto-multipunto. Actualmente hay operativas 10 lneas remotas y podran llegar a ser 16, con el hardware existente. En su configuracin 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 configuracin de 7400 canales de entrada digital, 1700 salidas digitales y 500 medidas analgicas. Esta informacin es captada por las estaciones remotas a travs de tarjetas de entrada/salida o va protocolo RS-232. El sistema tambin permite la comunicacin con otros servidores a travs de UDP y TCP/IP, utilizando el estndar SNMP (Simple Network Management Protocol).

365 dias al ao, su escalabilidad y su seguridad. Para WNT juegan a su favor la facilidad de implementacin en poco tiempo y los costes de programador, productos y hardware asociado ms barato. El presupuesto asignado a la creacin de este aplicativo por parte del Operador no permite la implementacin 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 generacin ha demostrado ser suficiente para soportar el potencial nmero inicial de usuarios. La solucin planteada, consta de los siguientes elementos (figura 3): 1. Base de datos SQL Server 7.0 Con informacin de los clientes, canales, parmetros, etc. Los datos de tipo histrico estn almacenados en la base de datos Oracle del servidor donde corre el SCADA. 2. Base de datos ORACLE Contiene la informacin histrica de alarmas y ciertos parmetros de configuracin de las seales de salida digital. 3. El servidor WWW Actua como interficie de la aplicacin. El usuario lo utiliza para efectuar diversas consultas y como mecanismo de configuracin de los servicios de seguimiento de canales. El administrador del sistema, dispone de la correspondiente interficie web de administracin. 4. Componentes ActiveX Proporcionan un conjunto de utilidades esenciales para la aplicacin. 5. Servicios NT El sistema dispone de tres servicios propios en ejecucin: seguimiento de canales digitales, seguimiento de canales analgicos y registro de la informacin capturada.

Figura 2. Interfcie SCADA: Pantalla de sinpticos para la operacin en tiempo real de un sistema reemisor de televisin.

IMPLEMENTACIN

La primera decisin corresponde a seleccionar el sistema operativo sobre el que se montar el aplicativo. Teniendo en cuenta la experiencia prvia, se barajan dos posibilidades: UNIX y Windows NT. Las ventajas del primero radican en su fiabilidad probada en sistemas funcionando 24h,

4.1 Funcionamiento La comunicacin se establece a travs de la siguiente secuencia de operaciones: 1. El servidor web recibe peticiones de los clientes http (navegadores de internet), descargando las imgenes estticas i dinmicas, que se guardan en el disco duro del PC del cliente. El cliente hace la peticin de la informacin de telecontrol de los servicios contratados.

3. 4.

5.

2.

El servidor pide la informacin en tiempo real a travs del protocolo SNMP al sistema de telecontrol corporativo. El servidor ofrece la informacin al cliente y este refresca la representacin en la mquina local. La operacin se efecta a la frecuencia fijada por el administrador del sistema. Adems de la informacin en tiempo real, el cliente puede solicitar informacin histrica que el servidor web adquiere de la base de datos del sistema de control corporativo.

Datos en tiempo real: MIB SNMP Aplicacin cliente: Navegador SERVIDOR Datos histricos: BBDD ORACLE

WEB

Datos de configuracin: BBDD SQLServer CLIENTE SERVIDOR SISTEMA SCADA

Figura 3. Estructura de datos de la aplicacin

PC CLIENTE (NAVEGADOR)

SERVIDOR WEB

SISTEMA SCADA

Internet

Zona segura (DMZ)

Figura 4. Funcionamiento del sistema

Red Operador

SEGURIDAD DE REDES

La necesidad de implementacin de mecanismos de seguridad sobre internet, proviene de dos necesidades bsicas. En primer lugar es necesario controlar quien puede navegar en nuestro site. Se necesitan garantas de seguridad del sistema, para evitar el acceso fraudulento a la informacin 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 informacin contenida en el sistema. Por otro lado, se debe garantizar la seguridad de comunicaciones. Se debe asegurar que la informacin transportada a travs 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 informacin confidencial que se enva 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 polticas totalmente diferentes. La autentificacin 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. En nuestro caso concreto, el control de quien puede conectarse a nuestra web-site y acceder a determinados ficheros, est gestionado a travs de la combinacin de la seguridad implementada en el sistema operativo Windows NT y Internet Information Server. En cambio, la funcin de hacer posible la transmisin de la informacin de forma segura pertenece a Secure Sockets Layer. 5.1 Seguridad de Windows NT El sistema operativo escogido involucra algn tipo de comprobacin de seguridad a cualquier accin ejecutada (intentos de acceso a ficheros, logon sobre una estacin 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 mquina (por ejemplo actuando como administrador).

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 mquina, 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 mquina local. Para permitir una gestin ordenada de los usuarios por parte del administrador o administradores de un sistema, los usuarios se organizan en grupos. Estos grupos estn 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 accin sobre el sistema, estn asociados al propio servicio de la mquina 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 informacin relativa al usuario, esta informacin se guarda con el propio fichero al cual se pretende acceder. Esta afirmacin es igualmente cierta para el registro del sistema. As, las polticas de seguridad del sistema se guardan en un lugar centralizado, con derechos de acceso a l. El hecho de que toda esta informacin es independiente de la informacin 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). 5.2 Secure Sockets Layer (SSL) La tecnologa SSL proporciona dos funcionalidades. Por un lado encripta el flujo de informacin entre el cliente y el servidor, y por otro lado fija las bases para la autentificacin entre cliente-servidor. SSL fue desarrollado por Netscape el ao 1994 y actualmente se encuentra en la tercera revisin. SSL se basa en el concepto de canal seguro. Este canal garantiza confidencialidad puesto que todos los mensajes que pasan por l estn encriptados. SSL no encripta ninguna informacin guardada en el cliente o en el servidor. SSL integra seguridad sobre protocolos al nivel de aplicacin como HTTP, NNTP, y Telnet. SSL proporciona un handshake de seguridad al iniciar una conexin TCP/IP, resultando en una negociacin entre servidor y cliente del nivel de seguridad

utilizado, y satisfaciendo cualquier requerimiento de firma digital por la conexin. Desde este momento, si la encriptacin del mensaje es activa (estado por defecto), SSL encripta y desencripta la cadena de byte del protocolo de aplicacin utilizado en el momento. Esto quiere decir que la informacin en la peticin HTTP y la respuesta estn totalmente encriptadas, incluyendo la URL que el cliente est pidiendo, cualquier contenido de formulario enviado, cualquier informacin de acceso HTTP y toda la informacin enviada por el servidor hacia el cliente. SSL utiliza el sistema de clave pblica para intercambiar una clave entre cliente y servidor. Esta clave de sesin es exclusivamente generada por cada una de las conexiones cliente-servidor y se utiliza para encriptar la transaccin GTTP. La criptografa de clave pblica se utiliza nicamente para la verificacin mutua y para encriptar la llave de la sesin; SSL utiliza la encriptacin de llave simtrica (significativamente ms rpida que la criptografa de llave pblica) para encriptar la sesin. Cada una de las transacciones utiliza una clave de sesin diferente, por lo que aunque alguien robase una clave no implica conseguir la clave para desencriptar mltiples sesiones. Al aadir cualquier capa de seguridad a una transaccin se ralentizan los procesos del servidor de alguna manera y SSL no es ninguna excepcin. La sobrecarga, no obstante, es ligera, y los beneficios all donde la seguridad es necesaria superan los riesgos que se corren al no implementar ningn sistema de seguridad.

mostrar el estado del tiempo en diferentes lugares, etc. (figura 7).

Figura 5. Red de difusin del operador

RESULTADOS

Figura 6. Acceso a histricos

Se ha diseado 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 gestin masiva de alarmas. En este contexto, el aplicativo desarrollado hace rentable en parte la inversin slo como herramienta de confeccin de informes internos, para la gestin de calidad de servicio propio del operador (figura 6). Adems se han introducido de manera satisfactoria, funcionalidades que pueden llamar la atencin del cliente y derivar en la prestacin de nuevos servicios a contratar, como puede ser la transmisin de vdeo lento, para la inclusin de imgenes a su propia web, cmaras de vigilancia, trnsito (a travs 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 parmetros del sistema. As puede parametrizar el tiempo entre capturas de valores analgicos o la direccin de email donde recibir la notificacin de los sucesos que l mismo decida (figura 8).

LINEAS FUTURAS

Es necesario tener en cuenta el carcter de prueba piloto que tiene el proyecto. El objetivo principal reside en la evaluacin de las ventajas competitivas que el servicio de telesupervisin ofrece a travs 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: Nmero de clientes a los que se pretende ofrecer el servicio, para dimensionar correctamente la maquinaria. Nmero de conexiones concurrentes, a fin y efecto de dimensionar el throughput necesario par dar altos ndices de calidad (tiempo de respuesta del servidor). En funcin 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 modificacin de parmetros

CONCLUSIONES

A partir de este anlisis posterior a la prueba piloto, el Operador podr ofrecer un SLA (Service Level Agreement) que permitir incluir la tarificacin 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

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 aplicacin 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 telesupervisin y telecontrol de los equipamientos de terceros a infraestructuras del operador. La solucin mejora algunos aspectos en cuanto a la funcionalidades del sistema Scada, como el seguimiento y almacenamiento de medidas analgicas, las grficas histricas, y el aviso de determinados eventos a travs de medios de comunicacin prximos al los clientes del operador, como son el e-mail y el telfono mvil GSM. Dentro del entorno de la prueba piloto se ha parametrizado el aplicativo para servir datos de un sistema de difusin de FM en configuracin 1+1, de 10 y 5Kw de potencia de salida, respectivamente. El personal tcnico del difusor ha valorado muy positivamente la prueba, pidiendo una ampliacin del mbito de la misma.