sistema de supervisión y telecontrol de una red de radio

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