Información previa multiconferencia abril
De MorfeoWiki
Tabla de contenidos |
Información previa multiconferencia mes de abril (29/04/2008 16:00)
Es importante que todos incluyamos aquí los temas de los que queremos hablar
- Horario previsto: 16:00 a 18:00
- Teléfono y PIN: proporcionados por correo
Fechas estimadas de entregas asociados a desarrollos comprometidos
Descripción
- Gestión de Usuarios:
- Usuarios/Perfiles.
- Existirán 3 perfiles: Operador, supervisor y administrador:
- Cada uno de estos perfiles estará definido en una tabla, en la que aparecerá la lista de operaciones que puede realizar:
- Recurso al que accede (URL/método HTTP)
- "Verbo" del recurso que puede utilizar: SELECT, INSERT, UPDATE, DELETE
- Cada uno de estos perfiles estará definido en una tabla, en la que aparecerá la lista de operaciones que puede realizar:
- Cada usuario está asociado a un único perfil
- Existirán 3 perfiles: Operador, supervisor y administrador:
- Usuarios/ámbitos.
- Cada usuario tendrá asociados una lista de "nodos" a los que puede acceder y que definirán el ámbito. No se podrá acceder a información que no esté en el nodo.
- Existirá una propiedad que indicará si el usuario puede acceder a alarmas NO asociadas a ningún nodo.
- Control de acceso en los servicios a los usuarios (se cambiarán los servicios actuales para incluir esta posibilidad)
- Ante cada petición el servicio comprobará que el usuario y la clave son los correctos, así como si tiene permisos para realizar la operación seleccionada y el ámbito al que quiere acceder.
- Para la validación una única vez de un usuario se estudiará una arquitectura (OpenId, OpenAuth) sobre la que se realizará una implementación en EzWeb
- Usuarios/Perfiles.
- Mecanismo de generación de alertas automáticas de supervisión.
- Se permitirá generar alertas tanto de e-mail como de mensaje corto por CAMBIOS DE ESTADO (creación, cierre, asignación...) asociados a:
- Tipos de Alarma
- Severity
- Nodo/Elemento asociado
- Cada alerta podrá estar asociado a una lista de destinatarios/e-mail
- Esta configuración se podrá realizar desde el gadget asociado (5.1 Gadget para envío de mensajes cortos y correos electrónicos)
- Se permitirá generar alertas tanto de e-mail como de mensaje corto por CAMBIOS DE ESTADO (creación, cierre, asignación...) asociados a:
- Se desarrollará una pasarela REST para los gadgets de acceso a los servicios OPC (únicamente sobre los dos servicios SOA necesarios: "read" y "write")
Fechas estimadas desarrollos
- Desarrollo base para los desarrollos posteriores:
- 19 de Mayo
- Gestión de usuarios/perfiles: Modelo de datos
- Gestión de usuarios/ámbitos: Modelo de datos
- Control de acceso en los servicios para garantizar el permiso de los usuarios (incluye cambio en servicios actuales)
- 30 de Mayo
- Propuesta de arquitectura de referencia e implementación de la gestión de usuarios/claves/identidad múltiple (OpenID, OpenAuth)
- 19 de Mayo
- Desarrollo servicios REST base para poder realizar algunos gadgets:
- 30 de Mayo
- Desarrollo de pasarela REST para servicios OPC. Sólo para DOS servicios (read y write)
- 3.1 Gadget de lectura de datos de OPC
- 3.2 Visualizador gráfico de medidas registras en OPC
- 3.3 Gestor de elementos y tipos de medidas de OPC
- 4.7 Visualizador gráfico de medidas almacenadas
- 5.1 Gadget para envío de mensajes cortos y correos electrónicos
- 5.2 Gadget auditor
- Desarrollo de pasarela REST para servicios OPC. Sólo para DOS servicios (read y write)
- 30 de Mayo
- Otros desarrollos
- 12 de Junio
- Proceso de suscripción y notificación de eventos a sistemas con MUSE
- 30 de Junio:
- Gestión de sistemas como un tipo de usuarios
- Mecanismo de generación de avisos/alertas automático ante cambios de estado de alarmas asociados a diferentes tipos de alarma, severidad y nodo/elemento asociado
- Automatización en la creación del tipo de medida
- 30 de Julio:
- 2.3 Árbol topológico de consulta (Gadget y servicios REST)
- 2.4 Bandeja de tipos de medida (Gadget y servicios REST)
- 4.1 Bandeja de alarmas (Gadget y servicios REST)
- 4.2 Creación de alarmas (Gadget y servicios REST)
- 4.3 Cambio de estado de una alarma (Gadget y servicios REST)
- 4.4 Visualizador del historial de estados por el que ha pasado una alarma (Gadget y servicios REST)
- 30 de Agosto:
- 2.5 Gestor de tipos de medida (Gadget y servicios REST)
- 30 de Septiembre:
- 2.1 Gestor de elementos (Gadget y servicios REST)
- 2.2 Gestor de jerarquías (Gadget y servicios REST)
- 30 de Octubre:
- 5.3 Gadget Gestor de Usuarios (Gadget y servicios REST)
- 30 de noviembre:
- 2.6 Información estado elemento (Gadget y servicios REST)
- 2.7 Administración de tablas auxiliares (Gadget y servicios REST)
- 31 de diciembre:
- Proceso de paso a histórico y de borrado de datos antiguos (Gadget y servicios REST)
- 4.5 Visualizador de valores de medidas (Gadget y servicios REST)
- 4.6 Árbol topológico de Supervisión (Gadget y servicios REST)
- 12 de Junio
- Desarrollo del correlador
- 5 de Mayo
- Integración de agentes y pasarelas JMS que permitan extender la interacción del correlador con fuentes y objetivos externos. En esta iteración se implementa la pasarela REST con el receptor de datos
- 19 de Mayo
- Componentización de los ficheros de reglas. Desarrollo de primitivas para la especificación de reglas de correlación
- 4 de Junio
- Integración de la aplicación como un servicio en un contenedor Java EE (Geronimo).
- 16 de Junio
- Gadget visualizador de reglas de correlación
- 30 de Junio
- Gadget visualizador de la ejecución del correlador
- 5 de Mayo
Fechas estimadas documentación
- 30 de Junio:
- D1.3.3: Informe gestión primer semestre 2008.
- 31 de diciembre:
- D1.3.4: Informe gestión segundo semestre 2008.
- D3.1: Formalismos para la descripción normalizada de eventos
- D3.3: Definición de ontologías para análisis de impacto
- D3.4: Panel de alarmas
- D3.5: Árbol/mapa topológico de supervisión
- D5.1: Formalismos para la descripción normalizada de datos de monitorización
- D5.2: Controlador sistema monitorización
- D5.3: Evaluador sistema monitorización
- D6.1: Formalismos para definición e integración de modelos físicos y lógicos
- D6.2: Formalismos para integración multidominio de inventarios
Correo previo de Saray
Hemos pensado que además de las modificaciones en el cliente OPC como son:
- Intentar automatizar la creación de MEASUREMENT_TYPE's, para rellenar automáticamente el mayor numero de campos posibles, a partir de la información recibida desde el gestor de elementos de planta .
- Uso de más tipos de variable
- Posibilidad de entrada manual de los ítems a leer
- Configuración de los tiempos de petición de ítems
Nos interesaría hacer algunos gadgets que no están incluídos. Son gadgets pensados para el mundo industrial y que nos podrían interesar de cara a vender el producto a diferentes empresas relacionadas con el sector. Son los siguientes:
- Un Gadget que muestre un plano general de planta o del proceso a monitorizar, que se pueda pinchar en un elemento determinado y que nos lleve a otro Gadget en el que se pueda ver ese elemento, una tabla de valores asociados a ese elemento (estado, alarmas relacionadas con ese elemento…..) y un par de “botones” que nos permita seleccionar el modo de funcionamiento del elemento, es decir automático o manual. Si es automático, el elemento funcionará según la secuencia programada en el PLC y si es manual será el operario el que decida cuando accionar o parar el elemento.
- Un Gadget que permita implementar reglas sencillas de programación , de manera que pueda enviarlas al correlador y este las valide.
- Un Gadget como el visualizador gráfico de medidas registradas pero históricas también.
- Un Gadget que permita cambiar los rangos de las medidas fuera de los cuales obtendríamos una alarma.
- Un Gadget enfocado a información de partes en el que se puedan obtener valores relacionados con consumos ( no sé si es buen ejemplo, pero por ejemplo, tiempo de funcionamiento de un elemento por el gasto de cada hora, o producción diaria, o cualquier dato relacionado con el proceso que requiera de cálculos entre variables obtenidas de OPC.
Correo previo de Alejandra
Tras reunirnos con MSI se decidieron cuales iban a ser los desarrollos en los que queríamos centrarnos en este primer semestre del año. Estas acciones las hemos dividido en las siguientes secciones:
- PLC
- Gestión de planta
- Gadgets
Programa PLC
Se desarrollarán varias versiones del software de PLC:
- Se preparará a corto plazo un programa PLC que permita probar las nuevas funcionalidades y comprobar el rendimiento con un tráfico grande.
- Se preparará un programa PLC que sea una primera versión del caso de uso.
Gestión de planta Se trabajará en una nueva versión del cliente OPC junto con CTIC. Se identifican una serie de requisitos:
- REQ1.- Uso de más tipos de variable (se habla de incluso probar con estructuras de datos)
- REQ2 - Posibilidad de entrada manual de los ítems a leer
- REQ3 - Configuración de los tiempos de petición de ítems.
- REQ4 - Implementación de una comunicación bidireccional Gadget <->Gestor de planta; de tal forma que se puedan escribir valores OPC y de tal forma que los Gadgets puedan leer valores directamente de OPC sin tener que pasar por la base de datos del controlador general del sistema.
(Esto ya ha sido comentado con CTIC de modo que los requisitos se incorporan a los generales del cliente)
Gadgets
- Se realizará una primera versión de un gadget de generación de gráfica tomando datos de una base de datos. Esto supone cubrir el requisito de mostrar en una gráfica los datos históricos de una medida.
- Se realizará una primera versión de un gadget de generación de gráfica tomando datos directamente desde una pasarela al OPC.
- Se estudiará la viabilidad y las posibles soluciones para crear el gadget de sinópticos: a priori se contemplan dos posibilidades: la de un gadget con zonas activas que interactúa con otro gadget que visualiza las medidas según la zona activa seleccionada y la de un gadget que simplemente sea una pasarela con una aplicación java que implemente la funcionalidad del sinóptico.
- En la lista de gadgets no aparece ningún gadget previsto para escribir valores en PLC. Estudio de su viabilidad.
Agenda prevista REUNION:
- Estado de los diferentes entornos operativos/demostradores (¿Necesidad de apoyo adicional para la instalación completa del servicio?, ¿Dónde se han encontrado los principales problemas?):
- Felguera,
- ESI
- S2
- Adicionalmente a la funcionalidad identificada. ¿Existe algo crucial añadido para que la plataforma se puede usar en pilotos de producción reales?
- Propuesta de reunión presencial en Madrid en el mes de mayo con el objetivo de:
- Resumen del estado del proyecto en esa fecha
- Solucionar in-situ los problemas de integración que se hayan podido producir y/o sugerir dudas
- Presentar los demostradores y casos de uso planteados para final de año
- Validar objetivos finales de año
- Capacidades del correlador para final de año.
- Revisión fechas de disponibilidad
- Otros puntos:
- Pensar en oportunidades de negocio para versión final 2008
- Planificar siguientes demostraciones a empresas, fundaciones, organismos oficiales
