Historización en la captura de datos

Historización en la captura de datos

| | No Comments

Controlar de manera exacta los procesos de fabricación es uno de los objetivos fundamentales en cualquier responsable de planta, de tal manera que nos permita ser más competitivos y mantener esa competitividad en el largo plazo.

Las soluciones en software de automatización nos permiten disponer de visibilidad del estado de planta en tiempo real, lo que permite ese control sobre el proceso para lograr el resultado óptimo. Sin embargo, el control en tiempo real no es suficiente ni es el único control que permite una producción óptima. Es necesario realizar un exhaustivo análisis de los datos de producción de forma que podamos aprender lo que se hizo bien o mal sobre un ciclo de producción anterior. Saber cómo un cambio en el parámetro de una variable puede afectar al rendimiento de un proceso es una información muy valiosa. Por lo general, son necesarios varios ciclos de producción antes de que uno se considere suficientemente bueno como para ser un modelo para la producción futura.
Para poder analizar un proceso, es necesario registrar la información sobre los parámetros de funcionamiento y los estados en el momento de la producción. Aquí es donde el historizador de planta se convierte en una herramienta útil. Un historizador de planta es un sistema de Bases de Datos diseñada para grabar tantos parámetros de un proceso de fabricación como sea necesario. Por lo general, se crean grandes cantidades de datos durante un ciclo de producción de fabricación, y con frecuencia se producen los cambios de datos a gran velocidad (sobre todo cuando algo sale mal!). Esta información debe ser almacenada, precisa y oportuna.
¿Hay algún sistema de Bases de Datos que haga frente a este desafío? Algunos defensores sugieren que una plataforma de Bases de Datos comercial puede ser utilizada, pero en realidad, este no es el caso.
Por ejemplo, los datos en series temporales, ¿puede SQL Server u Oracle almacenar datos en series temporales? Por supuesto. ¿Hay temas a tener en cuenta antes de intentarlo? Por supuesto. En este documento, Elliott Middleton, Product Manager, Historian & Clients, Invensys Operations Management (http://media.sa.online.pt/downloads/wonderware/white%20paper/WhitePaper_%20RDBMSand%20Historians_%201-10.PDF) revisa algunos mitos acerca de cómo una Base de Datos comercial puede ser utilizada como un historizador de planta y por qué estas ideas no son tan buenas como parecen inicialmente.

Mito 1: El almacenamiento es tan barato que la eficiencia no importa

Usted debe comprender completamente la cantidad de datos que un proceso típico genera. Un historizador modesto de 5.000 tags registrando datos cada segundo genera 157.680.000.000 valores por año. Almacenados de manera eficiente en 8 bytes cada uno, es aproximadamente un terabyte al año. En algunas pruebas, comparando los requisitos de almacenamiento de SQL Server para los datos en series temporales para Wonderware Historian, la diferencia fue de 50:1 y abarcaron todos los índices necesarios (apenas 23 Gigabytes).
Incluso con los precios del almacenamiento a la baja, los 50 terabytes de datos de un año son una cantidad considerable de datos. Además, hay que reconocer que tener suficiente espacio en disco para almacenar tal cantidad de datos es insuficiente, la mayoría de las aplicaciones de historización también requieren que los datos sean protegidos, multiplicando la cantidad de almacenamiento para copias de seguridad o de duplicación de discos. Algunas industrias tienen requisitos establecidos para mantener durante varios años los datos, ampliando aún más la cantidad de almacenamiento necesaria.

Mito 2: Las Bases de Datos Relacionales son lo suficientemente rápidas
Como la relación entre el rendimiento y el precio del hardware ha mejorado, las Bases de Datos relacionales también han mejorado. Sin embargo, las Bases de Datos relacionales están diseñadas para proteger la integridad referencial entre “transacciones” que puedan actualizar los valores de múltiples tablas a la vez, añadiendo una importante sobrecarga. Por ejemplo, en un hardware de gama alta (ejecutado en 96 procesadores) SQL Server 2008 estableció un récord mundial de 2.013 transacciones por segundo. Incluso en hardware de gama alta, no es posible almacenar 5000 valores por segundo y tratar cada valor como una transacción. Por lo tanto, una aplicación front-end de almacenamiento en búfer debe recoger los datos e insertar muchos valores en la Base de Datos en una sola transacción. Bases de Datos sin implementación plena de transacciones, tales como el motor gratuito MyISAM de MySQL, pueden soportar mayores tasas, pero aun así requieren un búfer para lograr la tasa de almacenamiento adecuada para todas las aplicaciones, incluso para un pequeño historizador.
Obviamente, la razón principal para almacenar datos es que puedan ser recuperados fácilmente, por lo que el rendimiento de la recogida de datos es muy importante. En particular, en soluciones de propósito general como una Base de Datos relacional, es posible organizar los datos para que sea eficiente ya sea para almacenar (mayor rendimiento) o eficiente para recuperar (recuperación rápida), pero no ambos. La recuperación eficiente de datos en series temporales en Bases de Datos de propósito general requiere el uso de un “índice agrupado” (clusterd index), como en el motor de almacenamiento de alto rendimiento MyISAM, y actualmente no está disponible.
Por el contrario, los motores de almacenamiento personalizados, se han diseñado específicamente aprovechando las series cronológicas de datos, y el conocimiento de cómo los datos se recogen y consumen, para almacenar de manera eficiente para ambos – esto no sería posible si los datos son generales y heterogéneos.

Mito 3: La gestión de datos en una Base de Datos Relacional es trivial
Las Bases de Datos relacionales están diseñadas para acumular grandes cantidades de datos. Sin embargo, a medida que la cantidad de datos va creciendo, también lo hacen los tiempos de ejecución de consultas, el tamaño de las copias de seguridad y numerosas operaciones rutinarias. Para solventar este problema de rendimiento de las tablas en aumento, los administradores de Bases de Datos deben purgar la Dase de Datos con frecuencia. En cualquier Base de Datos que protege la integridad transaccional, esta operación de purga debe detener los accesos a la Dase de Datos, lo cual es un problema para aplicaciones de historización funcionando 24/7/365. Para que la operación de purga sea tolerable, se requiere reducir al mínimo la cantidad de datos mantenidos en la Dase de Datos.
En el caso de los datos purgados sean requeridos más tarde (por ejemplo, en respuesta a una auditoría), los datos no pueden ser fácilmente restaurados. En general, la práctica recomendada es restaurar una copia de seguridad completa que incluya los datos necesarios en un sistema independiente dedicado a tal fin, o desconectar el sistema de producción y utilizar esos datos. Esto es aún más problemático si los datos requeridos no está disponible en una única copia de seguridad de la Base de Datos. Por ejemplo, si los datos sólo se mantienen durante los últimos 30 días en la Base de Datos en línea y una auditoría requiere 90 días de datos, o bien se deben combinar de forma manual todos los datos en una única Base de Datos, requiriendo tres sistemas, cada uno con una ventana aislada de 30 días, o bien examinar cada copia de seguridad en serie, una detrás de otra.

Los historizadores de verdad, en cambio, están diseñados para manejar el rápido crecimiento de datos y proporcionar medios sencillos de poner los subconjuntos de datos en línea y fuera de línea.
Mito 4: La recuperación de datos de series temporales no es diferente de cualquier otro tipo de datos
Debido a la versatilidad del Lenguaje de Consultas Estructurado (SQL) para consultar los datos, algunos afirman que las Bases de Datos relacionales son tan buenas en la recuperación de datos en series temporales, como lo son para recuperar datos transaccionales. SQL permite una mayor flexibilidad, pero se basa en algunas suposiciones fundamentales que no se aplican a los datos de series temporales:
a) no hay un orden inherente en los registros de datos (de hecho, los datos de series temporales se ordenan por el tiempo),
b) todos los datos se almacenan explícitamente (de hecho, la mayoría de los datos historizados representa muestras de un continuo de los datos reales), todos los datos son de igual importancia.
Estas dos diferencias son significativas. Por ejemplo, si un dispositivo comunica un valor de sellado de una compuerta en el instante “7:59:58.603” y un usuario consulta una Base de Datos relacional para el instante “8:00:00.000,” no se devuelven datos ya que no hay registros almacenados en ese preciso instante de tiempo – la Dase de Datos no reconoce que el tiempo es continuo. Del mismo modo, si una temperatura era de “21,0 ºC” y dos minutos más tarde fue “23,0 ºC,” no tiene capacidad inherente para inferir que a mitad de camino entre estas muestras la temperatura era de unos “22,0 ºC.”
En las aplicaciones de historización, rara vez existen operaciones de estado estacionario. La única forma que una aplicación cliente tiene para encontrar excepciones sería consultar todos los datos de una medición, lo que supondría una gran carga en el sistema global: servidor, red y cliente. Por el contrario, los historizadores por lo general disponen de los medios para filtrar los datos no significativos (basándose en la comparación de registros secuenciales) para reducir el volumen de datos que deben ser entregados a las aplicaciones cliente.

Mito 5: Todos los datos son iguales en importancia y calidad
En la recogida de miles de puntos de todo un proceso, es inevitable que alguna información sea incorrecta. Puede haber problemas con el dispositivo físico que esté fuera de alcance, o simplemente no funcione. Para una Base de Datos estándar, un valor almacenado es precisamente eso, un valor. En un historizador de planta, un punto almacenado no sólo tiene un valor asociado (y, por supuesto, una marca de tiempo), tiene una indicación de la calidad de los datos.
El almacenamiento de un punto de un dispositivo, fuera de su funcionamiento normal, por ejemplo, hará que se almacene una serie de indicadores de calidad junto con el valor, los cuales, cuando se recuperen, podrán ser utilizados para avisar a los operadores o al personal de ingeniería de una posible anomalía. Si en un historizador se utilizan los datos de mala calidad para el cálculo de un valor sumarizado (por ejemplo, calcular la media de la última hora de la temperatura) hará que el valor global resultante tenga un aviso de que la calidad no es buena. La gestión y propagación de la calidad de los valores dentro de un historizador de planta es necesaria para permitir a cualquier informe o análisis realizado con los datos que se marquen como sospechosos, y avisar al consumidor de los datos.

Mito 6: Las únicas opciones son completamente relacional o soluciones totalmente propietarias
Si bien es cierto que la mayoría de las soluciones de historización utiliza una tecnología totalmente propietaria para hacer frente a las limitaciones inherentes de la Base de Datos relacional o aprovecha totalmente una Base de Datos relacional para reducir los costes de ingeniería propia, Wonderware Historian ofrece lo mejor de ambos mundos. Se basa en un esquema relacional sólido para la gestión de todos los datos de configuración relativamente estáticos, pero añade al motor de almacenamiento transaccional nativo y al procesador de consultas de Microsoft SQL Server las extensiones propietarias para hacer frente a sus limitaciones con los datos de series temporales.
Sobre la base de Microsoft SQL Server, se ofrece una solución que es más fácil de asegurar y gestionar que una solución completamente propietaria, pero sin comprometer las capacidades fundamentales que se requieren en un historizador.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *