Sistema de Control y Supervisión Industrial Multiplataforma

Sistema de Control y Supervisión Industrial Multiplataforma
Germán Mauricio Coral
Oscar Amaury Rojas
Fernando A. Campos
gcoral@unicauca.edu.co
orojas@unicauca.edu.co
fcampos@unicauca.edu.co
Grupo en Automática Industrial – Universidad del Cauca
Resumen
Debido a la incursión de sistemas operativos de
licencia libre y a su aceptación en los diferentes
sectores industriales, surge la necesidad de
integrar todos los sistemas de supervisión y control
a esta nueva tendencia de una forma eficiente y
totalmente interoperable. Por esta razón se
desarrolló un estudio enfocado a crear una
herramienta que permitiera controlar y supervisar
dichos procesos en cualquier tipo de sistema
operativo o plataforma, validándolo especialmente
en sistemas Linux, al utilizarse conceptos de
comunicaciones
industriales
y
sistemas
telemáticos, como son OPC (OLE for Process
Control) y Servicios Web.
Al utilizar estas herramientas se implementó un
sistema de supervisión y control de procesos
industriales con capacidad de ser ejecutado en
cualquier tipo de plataforma y sistema operativo,
con funciones de almacenamiento y acceso
remoto para los usuarios del sistema por medio de
Internet y dispositivos móviles, reduciendo así
sustancialmente los costos de implementación y
operación al utilizar herramientas de software libre.
Palabras claves. Java for Process Control,
Linux, Multiplataforma, OPC XML-DA, SCADA,
Servicios Web.
Abstract
After the wide expansion of the open source
operating systems and their acceptation in the
industrial field, it emerges the necessity of integrate
all the supervision and control systems into that
new tendency, increasing their interoperabily and
efficiency. Because of that it was done a study
focused in the development of a tool that would
allow controling and supervising industrial task in
any kind of operation system or platform,
especially, testing it in a Linux system by means of
industrial networks, telematic applications, OPC
(Ole for process control) and Web services.
This paper shows that it is possible supervise and
control an industrial tasks system without matters
of the platforms or operating system, with storage
services, remote access for the users of the
system using internet and mobile devices, reducing
substantially the implementation and operation
costs by means of the open source software.
Keywords. Java for Process Control, Linux,
OPC XML-DA, SCADA, Web Services.
1. Introducción
La necesidad de interoperabilidad entre los
equipos, no solo en el ambiente de las redes
telemáticas sino también en las soluciones de
protocolos de redes industriales, ha obligado a las
diferentes empresas desarrolladoras de software a
crear nuevos productos que permitan la
comunicación entre diferentes sistemas que fueron
diseñados para ser totalmente incompatibles.
Por ejemplo, en el ambiente industrial ha sido
muy agresiva la batalla entre protocolos de redes
de
bus
de
campo
(redes
industriales
especializadas
para
comunicar
sensores,
actuadores, controladores y otros dispositivos
industriales); batalla que obligaba al usuario a ser
fiel a una marca de dispositivos para toda su línea
de producción por su incompatibilidad con los
demás protocolos de comunicación.
Sin embargo, en los últimos años se ha
impulsado una unificación masiva de los sistemas
industriales por parte de los principales
desarrolladores de software del sector. La
Fundación OPC [1] con su conjunto de
especificaciones es una de las principales
organizaciones preocupada por reducir estos
problemas de compatibilidad.
Estas especificaciones basan las soluciones de
incompatibilidad en el manejo del modelo de
objetos Windows COM/DCOM (Component Object
Model / Distributed COM), el cual permite la
adquisición de datos de los dispositivos y su
utilización en cualquier máquina Windows local o
distribuida.
A pesar de estos esfuerzos, aún existe un gran
problema de compatibilidad para sistemas
operativos diferentes a Windows, como Macintosh,
UNIX, Solaris, y Linux, los cuales son grandes
opciones con múltiples ventajas.
Ante estas diferencias se presenta la necesidad
de crear un sistema de comunicación industrial
que sea ampliamente compatible con las demás
plataformas y que además, proporcione las
mismas o mejores respuestas comparativas con
los sistemas actualmente existentes.
Este artículo describe las diferentes tecnologías
que se pueden utilizar para desarrollar una
herramienta que permita una comunicación
industrial entre diversas plataformas. También
muestra el desarrollo de la herramienta utilizando
la mejor opción de comunicación dentro del
entorno de estudio particular presentando los
resultados obtenidos y sus ventajas en términos de
compatibilidad y rendimiento.
2. Conocimiento existente
En el mercado actual los lenguajes de
programación como Visual Basic .NET y Delphi,
proporcionan un amplio soporte para el manejo de
protocolos de redes industriales, debido a que la
mayoría de los dispositivos disponen de
controladores
para
entornos
Windows
y
comunicaciones COM/DCOM.
Sin embargo, cuando se quiere utilizar una
plataforma diferente a Windows, los mejores
lenguajes de desarrollo son C++ y JAVA; el
primero con una complejidad un poco mayor a
nivel de programación, y el segundo (basado en el
primero) con gran portabilidad e interoperabilidad
multiplataforma y gran variedad de herramientas
para comunicaciones, aunque actualmente es
poco utilizado en la industria por sus bajos tiempos
de respuesta y por no disponer de la capacidad de
acceder a memoria directamente, hecho que limita
el acceso a información de dispositivos externos
sin conocer su protocolo de comunicación.
Por lo tanto, existen dos formas para acceder a
las redes industriales y a los dispositivos de campo
por medio de estos dos lenguajes:
ƒ
ƒ
Puentes COM/DCOM y OPC-DA
OPC y XML
2.1. Puentes COM/DCOM y OPC-DA
OPC-DA (OPC Acceso a Datos), fue la primera
especificación creada por la fundación OPC [1]
para transferir datos en tiempo real desde
dispositivos de control a HMIs (Interfaces HombreMáquina), la cual basa su comunicación en el
modelo COM/DCOM. De esta forma los
desarrolladores utilizan librerías nativas para
comunicar aplicaciones .NET o C++ con
aplicaciones Java y los dos modelos de
componentes COM/DCOM y RMI (Invocación de
métodos remotos).
2.2. OPC y XML
La Fundación OPC desarrolló un estándar XML
(eXtensible
Marked
Lenguage)
para
las
capacidades de interoperabilidad de los sistemas
SCADA (Sistemas de Supervisión, Control y
Adquisición de Datos) que se ejecutan sobre
sistemas
distribuidos
COM/DCOM.
PLCs
(Controladores Lógicos Programables), DCSs
(Sistemas de Control Distribuido), HMIs y varios
programas usan los estándares OPC-COM para
intercambiar datos en tiempo real entre
dispositivos de campo, sistemas de control y otras
aplicaciones
de
una
manera
estándar,
proporcionando compatibilidad multi-vendedor e
interoperabilidad basada en Servicios Web.
Esta tecnología brinda fácil integración con las
aplicaciones existentes OPC-COM a través de
Internet, ya que éstas trabajan muy bien en el
entorno típico de una LAN (Red de Área Local).
Sin embargo, cuando se usa DCOM sobre
Internet, se tienen muchos inconvenientes y
limitaciones relacionados con la seguridad y el uso
de puertos TCP/IP dinámicamente asignados
(típicamente no permitido a través de firewalls
corporativos).
Otra gran ventaja es que XML es una
especificación del W3C diseñada para facilitar su
transporte con protocolos de Internet. Este es
frecuentemente transportado vía HTTP (Protocolo
de transferencia de Hipertexto) simplemente como
páginas Web HTML (Lenguaje marcado de
hipertexto) ordinarias, pero también se transporta
fácilmente por medio de otros protocolos, como
FTP (Protocolo de transferencia de archivos) y
SMTP (Protocolo de transporte de mensajes
simples).
De las dos formas presentadas anteriormente,
los puentes COM/DCOM han sido la opción más
antigua y por lo tanto la más utilizada por las
empresas para gestionar sus productos en
sistemas operativos diferentes a Windows,
especialmente en sistemas Linux y UNIX o para
hacer sus desarrollos en lenguaje JAVA. La
organización NetModule [2] ha sido los primera en
hacer algún tipo de desarrollo industrial con miras
a utilizar herramientas totalmente interoperables
bajo el concepto de JPC (Java for Process
Control), herramienta que en la actualidad se
encuentra
disponible
en
el
mercado.
Posteriormente, otras empresas como Softing y
Advosol [3] en Europa implementaron otras
herramientas exclusivas para algunas versiones de
sistemas Linux basadas en lenguaje C++.
La segunda opción [4] es mucho más reciente
y ha incursionado vertiginosamente permitiendo el
desarrollo de una gran variedad de productos .NET
en entornos Windows, para ser compatible con
cualquier otro sistema, pero no se tiene ninguna
referencia de desarrollos totalmente interoperables
en diferentes plataformas sin necesidad de crear
versiones
nuevas
o
con
modificaciones
estructurales que afecten el rendimiento de los
dispositivos de campo.
En nuestro caso particular, los Servicios Web
son la tecnología que más se aproxima a lo
requerido: Interoperabilidad multiplataforma para
poder ejecutarlo en cualquier sistema operativo;
ajustándose perfectamente a una de las
especificaciones OPC: OPC XML-DA, que está
dirigida a los procesos industriales y a su
integración con las funcionalidades de los sistemas
SCADA y los protocolos de redes industriales.
3. Metodología
Para un desarrollo adecuado del proyecto y
considerando que se basa fundamentalmente en el
desarrollo de soluciones software se debe contar
con una metodología que favorezca la
construcción del sistema con características
óptimas de calidad.
Dentro de las diferentes opciones, se ha
considerado el Modelo de Construcción de
Soluciones (MCS), desarrollado dentro del grupo
de ambientes de Desarrollo de la Facultad de
Ingeniería Electrónica y Telecomunicaciones
(FIET) de la Universidad del Cauca, y el cual se
basa en el RUP (Rational Unified Process),
proceso que cuenta con fases de planeación,
descripción UML básica y detallada y sistemas de
validación del sistema, permitiendo generar
prototipos básicos que van evolucionando a
medida que se desarrolla el proyecto.
4. Herramientas Utilizadas
Para lograr los objetivos del proyecto se ha
realizado una integración de la arquitectura
propuesta por la Fundación OPC denominada
Arquitectura Unificada y las herramientas
brindadas por Java Sun Microsystems con sus
diferentes soluciones para el manejo de: Servicios
Web (J2EE), eventos y procesos normales en
equipos comunes (J2SE), y aplicaciones para
dispositivos móviles (J2ME).
Debido a que la especificación viene orientada
hacia herramientas de desarrollo de Microsoft y
especialmente a Visual Studio .NET, no se han
seguido estrictamente las especificaciones OPC
sugeridas para entornos industriales, pero se lleva
a cabo la mejor aproximación posible con el
objetivo de no perder la estandarización deseada.
4.1. OPC XML-DA (XML acceso a datos)
XML-DA es la última especificación que la
fundación OPC generó para el servicio de la
industria
y
está
basada
en
algunas
especificaciones anteriores, como OPC-DA. La
razón es permitir operabilidad entre diferentes
lenguajes y sistemas operativos al utilizar XML, un
lenguaje que permite el intercambio de información
estructurada entre aplicaciones. Los principales
objetivos de OPC XML-DA son:
•
•
•
Soportar el acceso a OPC DA versión 2.0 y 3.0
Manejar HTTP y SOAP.
Brindar soporte para Servicios Web síncronos
y asíncronos basados en suscripción.
4.1.1. Métodos asíncronos. Los servicios
soportados por la especificación XML-DA son:
Buscar, Obtener Propiedades, Obtener Estado,
Leer y Escribir.
Buscar, busca jerárquicamente los nombres de
las variables del proceso (TAGs) que se
encuentran en el servidor. Obtener Propiedades,
retorna información asociada a una o mas TAGs.
Obtener Estado, retorna información acerca del
servidor, tal como: versión, modo actual, estado
general, entre otros. Leer, devuelve el valor,
calidad y tiempo de consulta de una TAG
seleccionada con el método Buscar o dando un
nombre específico y Write permite escribir en el
servidor uno o más valores de las TAGs.
4.2. OPC AE
El sistema de control y supervisión debe
disponer de un módulo de gestión de alarmas del
proceso, el cual debe generar un reporte a
usuarios así estos se encuentren remotos,
implementando de esta manera la generación de
mensajes de novedades de alarmas y situaciones
críticas usando servicios de comunicaciones
móviles. Para llevar a cabo estas funcionalidades
se utiliza la especificación OPC AE (Alarmas y
Eventos) propuesta por la Fundación OPC,
haciendo uso de la versión estándar de Java
J2SE, que es empleada especialmente para el
manejo de eventos.
Como se ha detallado anteriormente, todas las
especificaciones de la Fundación OPC van
enfocadas a desarrollos en entornos Windows y
comunicaciones COM. Por esta razón, el
desarrollo de la funcionalidad de un servidor de
alarmas y eventos bajo un paradigma
multiplataforma
solo
puede
implementarse
tomando los conceptos básicos y más relevantes
de la especificación integrándolos a la Arquitectura
Unificada de la Fundación OPC.
En general, para implementar la especificación
se tiene en cuenta un servidor de alarmas y
eventos que posee la capacidad y los mecanismos
para notificar a los clientes OPC cuando ocurre un
determinado evento o condición de alarma, e
igualmente debe proporcionar a los clientes los
mecanismos necesarios para determinar los
eventos y condiciones soportadas en el mismo
servidor y obtener su estado.
Una alarma es una condición anormal y por
consiguiente es un caso especial de una condición
[5]. Esta condición está directamente relacionada
con algún objeto que proporcione información a un
cliente OPC, por ejemplo una variable o TAG.
4.3. AXIS
El kit de herramientas de Axis de Apache es
una implementación de código abierto de SOAP
(Protocolo para acceso de objetos Simples), que
facilita el trabajo a los programadores al momento
de desarrollar una herramienta software basada en
Servicios Web y que tenga por lo tanto un
documento WSDL (Web Service Description
Language). Al utilizar esta herramienta y
manejando un WSDL estándar se puede
implementar un servicio Web de forma automática,
casi instantánea y sin costo adicional.
AXIS utiliza la API JAX-RPC (API de Java para
llamada a procedimiento remoto basada en XML)
[6] que a su vez utiliza un protocolo de mensajería
XML como SOAP, para transmitir una llamada a
procedimiento remoto a través de una red.
4.4. JDBC
A pesar de que la Fundación OPC ha intentado
crear una arquitectura abierta, ha basado todos
sus desarrollos en tecnologías Windows, por lo
tanto, al tratar de migrar a otros entornos como
UNIX con Java, se deben hacer algunos cambios.
En este caso, es imprescindible el manejo de
bases de datos con conectores de diferentes tipos
a los manejados por OPC-HDA, los cuales se
basan en OLE-DB, un controlador orientado a
objetos de tipo COM/DCOM. Normalmente cuando
se quiere hacer una conexión a un motor de Bases
de Datos se utiliza el API JDBC.
JDBC es un estándar para acceder a cualquier
motor de base de datos disponible en el mercado,
ya sea de carácter libre o no. Esta API está
formada por un conjunto de clases e interfaces
desarrolladas en Java para ejecutar sentencias
SQL, permitiendo obtener los datos de una forma
fácil y segura en arquitecturas Cliente/Servidor a
través de Internet o Intranet [7].
4.5.
WAP
inalámbrico)
(Protocolo
de
acceso
Es un estándar para la presentación y envío de
información y la utilización de servicios adicionales
de telefonía sobre dispositivos móviles. A
diferencia de las tecnologías de Internet para PCs,
WAP está pensado para dispositivos que tienen
algunas limitaciones técnicas inherentes a la
tecnología actual, tales como menor capacidad de
procesamiento y memoria, restricciones de
suministro de potencia, despliegues pequeños,
mecanismos de entrada diferentes, entre otras.
Los componentes involucrados en las aplicaciones
WAP son muy similares a los del World Wide Web
(WWW), excepto por la incorporación de una
pasarela utilizada para servir de intermediario
entre el mundo inalámbrico e Internet.
4.6. SMS (Servicio de mensajería corta)
El servicio de mensajería corta es un servicio
inalámbrico aceptado globalmente que habilita la
transmisión de mensajes alfanuméricos entre
suscriptores móviles y sistemas externos (E-mail).
5. Resultados
A continuación se presenta el desempeño e
interoperabilidad de la herramienta desarrollada,
en diversas plataformas, entre las cuales se
incluyen Windows XP y 2000, Linux SUSE 9.0 y
Mandrake 10.1, empleando como motor de Base
de Datos Firebird y Emuladores de dispositivos
móviles Ericsson.
Se utilizaron tres servidores OPC XML-DA: El
primero, ubicado en una red LAN con un servidor
de RsLinx de Rockwell Software, el segundo
ubicado en USA publicado por Advosol [8], y el
último ubicado en Suiza publicado por
Technosoftware [9].
5.1. Arquitectura de referencia
En la figura 1 se puede apreciar que el servidor
de Datos XML-DA tiene un servidor Windows IIS
basado en .NET, el cual utiliza un puente para
comunicarse con objetos COM/DCOM y así poder
obtener y modificar los datos que se encuentran en
el dispositivo de campo.
SERVIDOR
OPC-DA
XML-DA
BD
.NET IIS
PUENTE
INTERNET
SOAP/HTTP
CLIENTE WEB OPC
XML-DA
SERVIDOR OPC A&E
DISPOSITIVO
DE CAMPO
CLIENTE MÓVIL
OPC A&E
Figura 1. Arquitectura de referencia para el servicio
Del lado del cliente se encuentran dos tipos de
usuarios: un dispositivo móvil que puede acceder a
un servidor de Alarmas y Eventos OPC a través de
Internet, por medio de WAP; y un cliente OPC DAXML que accede a los datos a través de Internet,
por medio de SOAP y HTTP, pero a su vez es un
servidor de Alarmas y Eventos OPC, con acceso a
datos históricos mediante JDBC.
5.2. Búsqueda de dispositivos
En una red industrial, cada dispositivo debe
estar en la capacidad de brindar información al
sistema SCADA, convirtiéndose dentro de nuestra
arquitectura en un servidor de datos OPC XMLDA, y por tanto tener asignada una dirección en
Internet o en la red de área local (LAN). De esta
forma, se hace indispensable el establecer un
mecanismo eficiente para determinar los
dispositivos que se encuentran activos en la red.
A pesar de que la definición dada por la
especificación OPC XML-DA para implementar
este servicio se basa en repositorios UDDI
(Integración,
Descubrimiento
y
Descripción
Universal), los cuales actúan como un directorio en
Internet, publicando el servicio, su ubicación
(pagina Web) y cómo implementarlo (WSDL); se
realizó la búsqueda de una forma semi-estática, en
la cual los servidores de datos se encuentran
registrados en una base de datos con sus
respectivas direcciones, y utilizando el método
GetStatus (Obtener Estado) se determina si el
dispositivo se encuentra activo o no.
Los resultados de este servicio a pesar de ser
validos y utilizables, son poco eficientes debido a
que, teniendo en cuenta el poco volumen de tráfico
que se genera, la velocidad de respuesta varía
entre 1 y 15 segundos, dependiendo del tráfico de
la red y se presentan en algunos casos
cancelaciones del servicio debido a los altos
tiempos de espera.
La misma implementación del servicio se
ejecutó con éxito en todas las plataformas
mencionadas. Como se comentó anteriormente se
presentaron tiempos de respuesta variables
dependiendo de la plataforma a validar, siendo
Linux Mandrake 10.1 el sistema que presentó la
mayor limitación en cuanto al tiempo de respuesta.
5.3. Acceso a Datos
Se utilizan los servidores anteriormente
mencionados, realizando las transacciones Read y
Write. Para comprobar el correcto funcionamiento
se ha utilizado el software de programación de
PLC´s Rslogix500 de Rockwell Software como
servidor OPC DA con un puente XML-DA para
acceder a éste.
Utilizando el servidor de prueba de
Technosoftware con la herramienta Lixmo, se
puede observar en la Figura 2, que en la búsqueda
de elementos o TAGs, efectivamente el sistema
desarrollado despliega los grupos y variables
disponibles en el dispositivo al cual nos
conectamos.
Además, se validó en todas las plataformas
propuestas la lectura y escritura de datos en los
diferentes servidores, con muy buena velocidad de
respuesta y con capacidad de actualizar múltiples
datos simultáneamente, siendo mucho más eficaz
que el servicio anteriormente presentado.
modifica para enviarse al RSLinx con el formato:
“[NombreDeProyecto]N7:6”.
De igual forma para utilizar la transacción Read,
se recurrió a la misma función de cambio de
formato para adoptar la notación del RSLinx
mencionada anteriormente.
Estos procedimientos son mostrados en la
Figura 3, en la cual se puede observar el resultado
de una transacción Read en la memoria de
variables de datos existente en un PLC de Allen
Bradley, al cual se ha configurado un tópico OPC
en el servidor OPC DA de su software de
comunicaciones RSLinx de Rockwell Software.
Figura 2. Búsqueda de datos en servidor de prueba de
Technosoftware publicado en Internet.
En la Figura 3, se puede apreciar la respuesta
al método GetProperties (Obtener Propiedades)
del servidor mencionado anteriormente.
Figura 4. Búsqueda y lectura de datos en servidor
Local RSLinx.
5.4. Almacenamiento de Datos
Figura 3. Obtención de propiedades de un TAG en el
servidor de Technosoftware publicado en Internet.
Cuando se realizaron las pruebas de
interoperabilidad de estos servicios en el
dispositivo local que funcionaba con el software de
comunicaciones RSLinx de Rockwell Software se
obtuvo un error de lectura. Este se refería a que no
se encontraban elementos dentro del grupo de
variables, debido a que el servidor OPC DA de
RSLinx implementa de una forma propietaria y por
tanto no estándar la manera de nombrar los
grupos y TAGs del sistema, creando una
incompatibilidad con las demás herramientas que
manejan el estándar XML-DA, para lo cual fue
necesaria la implementación de una función de
cambio de formato en las TAGs a transmitir,
solucionando el problema inicial.
Por ejemplo si se quiere llegar al grupo de
TAGs del registro de enteros, usualmente la
notación para el nombre de la TAG sería:
“NombreDeProyecto.Online.N7.N7:6”, el cual se
Una vez obtenidos los datos de la forma
mostrada
en
la
sección
anterior,
el
almacenamiento en la base de datos fue sencillo y
efectivo. Se encontraron algunos problemas de
compatibilidad al momento de publicar la base de
datos en las plataformas Linux y ser accedidas
desde Windows utilizando RMI, pero se pudo
solucionar utilizando Servicios Web como medio
de acceso y publicación.
5.5. Alarmas
Para validar esta función del sistema, se
tomaron cuatro variables de proceso y se
definieron condiciones de alarma para cada una de
ellas, de manera que cuando éstas se activen,
generen el reporte de alarmas y desplieguen la
información a los usuarios Web y Móvil.
En la Figura 5, se observa que el cliente Web
presenta el reporte de alarmas y eventos,
relacionando la información correspondiente a la
fecha y hora de activación y su estado actual
(activa o inactiva).
6. Conclusiones
•
Con el sistema desarrollado, se pueden
generar todas las aplicaciones actualmente
requeridas por un sistema de control y
supervisión utilizando una plataforma Java y
un servidor XML-DA desarrollado en cualquier
lenguaje.
•
A través de la implementación de un Cliente
Web de la especificación OPC XML-DA en
J2EE, se puede tener acceso ilimitado a los
datos de un dispositivo de campo y ejecutar la
aplicación en cualquier plataforma, ya sea
Linux, UNIX, Windows, o un dispositivo móvil.
•
Utilizando la especificación OPC XML-DA se
pueden integrar todos los servicios necesarios
para el control y supervisión de dispositivos de
campo en un proceso industrial, y usar los
mismos desde cualquier sitio remoto con
acceso a Internet, o dentro de una LAN.
•
Se pueden reducir ostensiblemente los costos
de desarrollo de una herramienta de control y
supervisión al utilizar sistemas operativos de
carácter libre y software de desarrollo de libre
distribución, sin perjudicar su calidad y
rendimiento.
•
Para un sistema de control y supervisión en un
proceso industrial, los tiempos de respuesta de
la herramienta desarrollada en Java son muy
buenos y no generan ningún retardo en el
desempeño del mismo. Se puede decir que
cumplen con la definición de tiempo real bajo
condiciones de red específicas y limitadas.
•
La adquisición de los datos por medio de la
aplicación XML-DA puede generar errores y
terminaciones de la conexión dependiendo del
tráfico en la red.
•
Algunos
procesos,
especialmente
los
relacionados con servicios que manejan poca
información como ver el estado de un servidor,
utilizan muchos recursos para una transacción
simple y no son óptimos para un sistema de
este tipo, debido a que pueden generar
errores y aumentar el tráfico en la red.
•
Para desarrollar un servidor OPC XML-DA
sobre lenguaje Java se necesita más que la
simple especificación. Debe desarrollarse
algún medio o utilizar uno ya desarrollado que
Figura 5. Gestión de alarmas en cliente Web.
El sistema implementa el manejo de las
alarmas y reporte de eventos críticos en los
dispositivos móviles y el despliegue de la
información a través de los emuladores WAP como
se observa en las Figuras 6 y 7.
Figura 6. Acceso remoto por medio de la Aplicación
WAP
Figura 7. Activación de alarmas en cliente Móvil.
permita obtener los datos directamente desde
la memoria o que haga una comunicación con
los objetos COM.
7. Bibliografía
[1] http://www.opcfoundation.org
Foundation.
-
The
OPC
[2] http://www.netmodule.com/e/index.asp - Net
Module
[3] http://www.softing.com/en/index.htm - Softing
AG.
[4] OPC Fundation, OPC XML-DA Specification,
2003.
[5] OPC Fundation, OPC Alarm and Event
Specification, 2002
[6] Borland SW Corporation. Guía
desarrollador de servicios Web. EEUU. 2004
del
[7] Caicedo, O., López, D. Electiva Aplicaciones
Web, Universidad del Cauca. 2004.
[8]http://172.16.140.41/PLC1/OpcXmlDaServer.as
mx - Servidor XML-DA de prueba de Advosol.
[9]http://opcxml.dnsalias.org:8080/XmlDaSampleS
erver/Service.asmx – Servidor Technosoftware.
8. Biografías
Fernando Alejandro Campos.
Ingeniero en Electrónica y
Telecomunicaciones
de
la
Universidad del Cauca 2005.
Actualmente es estudiante de
Master
in
Sciences
de
Administración de sistemas de
información
en
L’Ecole
Nacional
Superior
des
Telecomunicaciones et L’Ecole
nacionale des ponts et Chosses
(Paris Francia)
Investigador del grupo de I+D en Automática
industrial de la Universidad del Cauca y fue
presidente del grupo de investigación en sistemas
empotrados de la Universidad del Cauca en el año
2004. Sus líneas de interés son: Comunicaciones
Industriales, Sistemas de información y Servicios
Web.
Germán Mauricio Coral H.
Estudiante de último semestre de
Ingeniería en Electrónica y
Telecomunicaciones
de
la
Universidad
del
Cauca.
Actualmente
desarrolla
su
proyecto de Grado “Sistema de
Supervisión
y
Control
Multiplataforma”.
Investigador del grupo de I+D en Automática
industrial de la Universidad del Cauca. Sus líneas
de interés son: Sistemas SCADA e Integración
Empresarial.
Oscar
Amaury
Rojas.
Ingeniero en Electrónica y
Telecomunicaciones
y
Especialista en Informática
Industrial de la Universidad
del Cauca en 1996 y 2001
respectivamente.
Actualmente cursa estudios
de maestría de ingeniería
con énfasis en automática
en la Universidad del Cauca.
Profesor
asociado
del
Departamento
de
Electrónica,
Instrumentación
y
Control
e
investigador del grupo de I+D en Automática
industrial de la Universidad del Cauca. Sus líneas
de interés son: Sistemas SCADA e Integración
Empresarial.