Documento de Arquitectura del Sistema de supervisión, mantenimiento y control de planta (WASUP)
De MorfeoWiki
Tabla de contenidos |
Introducción
El presente documento tiene como objetivo la definición de una arquitectura o modelo de referencia objetivo para los sistemas de supervisión, mantenimiento y control de planta de forma que sea lo más genérico posible y aplicable al mayor número posible de procesos de supervisión, mantenimiento y control.
Arquitectura de componentes
A continuación se muestra el esquema general de la arquitectura del Sistema de supervisión mantenimiento y control de planta (WASUP):
Como se puede distinguir en la figura anterior aparecen los siguientes componentes principales:
- Gestor de elementos de planta
- PLCs, OPC Servers y OPC Clients
- Web Server
- Controlador general del sistema
- Receptor de datos
- Filtrado
- SMARTFlow
- Capa de Servicios
- Correlador de eventos
- Distribuidor de eventos
- Gestor de inventario
- EzWeb
Gestor de elementos de planta
Entre las funciones principales del Gestor elementos de planta se encuentran:
- Recibir eventos y capturas de datos a través de sondas, que se traducen a información de un evento estándar del sistema o monitorizan aquellos dispositivos que no tengan mecanismos espontáneos de emisión de eventos.
- Programar medidas periódicas
- Configuración de los elementos medidos
- Acceso a medidas y configuración a través de un servidor web
Una vez que el Gestor de elementos de planta identifica cuáles son las medidas significativas, se envían al Controlador general del sistema mediante un interfaz REST/CORBA, a través del Receptor de datos.
Controlador general del sistema
El Controlador general del sistema se encargará de:
- Recibir a través de un interfaz REST toda la información que proviene del Gestor de elementos de planta a través del Receptor de datos.
- Filtrar dicha información, en base a rangos de valores definidos.
- Almacenar en una base de datos dicha información a través de JDBC. Para la elección del Sistema Gestor de Base de Datos que vamos a utilizar como repositorio central del proyecto Wasup, nos hemos planteado la elección entre los dos SGBD de software libre más utilizados actualmente: MySQL y PostgreSQL. Despues de estudiar las ventajas y desventajas de utilizar uno u otro, siempre teniendo en cuenta las particularidades del proyecto que nos ocupa, hemos decidido optar por PostgreSQL, por las siguientes razones:
- Transacciones y propiedades ACID. En PostgreSQL, incluidas en el núcleo de la BD, de forma nativa. En MySQL se obtienen usando el motor de BD InnoDB, pero los meta-datos se siguen almacenando con el motor MyISAM (más vulnerable a fallos). Además, InnoDB (http://www.innodb.com/) es un producto ajeno con licencia dual, que ha sido adquirido por Oracle (dudas en cuanto a su evolución).
- Foreign Keys y Constraints. PostgreSQL, más acordes al estándar. En MySQL, soportadas con InnoDB, pero con una implementación más 'relajada' (p.ej., las clausulas CHECK son parseadas por todos los motores de BD, pero se ignoran, no tienen efecto)
- Atomicidad de sentencias DDL's. PostgreSQL permite transacciones en casi todos los tipos de sentencias DDL. MySQL realiza commits implícitos después de cada sentencia DDL. Esto es una ventaja a la hora de hacer instalaciones / upgrades de versiones del modelo de datos, ya que permite tratar todo el cambio en el modelo como una transacción atómica.
- Rendimiento. La tradicional superioridad en cuanto a velocidad de MySQL frente a PostgreSQL se ha visto reducida al mínimo en las últimas versiones. En entornos J2EE, PostgreSQL se comporta mejor manejando un elevado número de usuarios y operaciones concurrentes.
- Optimización de subquerys -> PostgreSQL
- Integridad de los datos -> PostgreSQL, garantizada a nivel de servidor por el motor de BD. En MySQL se puede garantizar utilizando el parámetro 'SQL Mode', pero aunque se establezca como politica global, el cliente siempre puede modificar su comportamiento a nivel de conexión modificando dicho parámetro. Ver: http://dev.mysql.com/tech-resources/articles/mysql-data-integrity.html, http://use.perl.org/~Smylers/journal/3424
- Comparativa más detallada (buscable en http://www.google.com/search?q=postgresql+vs.+mysql)
- Generar eventos básicos para el correlador.
- Gestionar todas las alarmas creadas por el correlador a lo largo de todo su ciclo de vida, utilizando el componente SMARTFlow, el núcleo de la plataforma, que constituye un motor de workflow que exporta una seríe de recursos accesibles mediante tecnología REST.
- Exportar una serie de componentes REST, a nivel de back-end, para que sean explotados por la capa de front-end EzWeb.
Correlador de eventos
El Correlador de eventos se encargará mediante un lenguaje basado en reglas de:
- Eliminar eventos redundantes y generar eventos agregados llamando al Controlador general del sistema mediante un interfaz REST, a través del Receptor de datos, determinando la causa raíz.
- Generar alarmas a partir de las medidas y eventos básicos, comunicándoselo al componente SMARTFlow.
Distribuidor de eventos
El Distribuidor de eventos tendrá como función primordial la de exportar información a otros sistemas de forma que el proceso de mantenimiento y control sea lo más integral posible.
Para intercambiar información, obtenida directamente desde la base de datos, entre los distintos sistemas o aplicaciones hará uso de servicios web, utilizando el lenguaje de interfaz pública WSDL, que permite la interoperabilidad independientemente de las propiedades y plataformas sobre las que se instalen.
Gestor de inventario
Entre las funciones principales del Gestor de inventario se encuentran:
- Definir el modelo de información que conforma el inventario, aplicando formalismos para la definición de los modelos físicos (recursos físicos a inventariar, así como sus relaciones de jerarquía y descomposición en componentes simples) y lógicos (información del servicio o proceso que se ofrece sobre los elementos del modelo físico).
- Importar información masiva de inventario, definiendo una interfaz normalizada para este intercambio de información, así como su mapeo en los modelos físicos y lógicos definidos.
Capa de Servicios y EzWeb
Se encargará del canal de acceso a la información por parte del usuario a través de distintos tipos de terminales. Este canal de acceso consistirá en un mashup, definiendo un entorno web operacional avanzado a partir de elementos más sencillos, mediante la utilización de la plataforma EzWeb.
Para ello será necesario definir una serie de componentes REST que realizan las acciones de un recurso usando una representación (generalmente un documento XML) que capture el estado actual de un recurso, identificado unívocamente por una URI, y mediante la cual se puede interectuar utilizando el protocolo HTTP. Estas fuentes de datos estarán ligadas a unos elementos sencillos denominados gadgets; que permitirán la visualización, generación/recepción, filtrado de los datos, así como intercambio de información entre ellos.
