Wonderware Historian frente a bases de datos relacionadas

Descripción General
Hoy en día, los fabricantes de todos los sectores deben ser más competitivos, y entender exactamente cómo ajustar y
controlar sus procesos de fabricación de una manera óptima para mantener su competitividad. El software de
automatización de hoy es sofisticado y le da a los operarios la visibilidad del estado de planta en tiempo real, lo que les
permite hacer cambios y ajustar los parámetros del proceso para lograr el resultado óptimo, independientemente del
producto final. En la planta se puede hacer pan, gasolina o productos farmacéuticos, y sin el control constante y la
retroalimentación de sus sistemas de proceso, los operadores rara vez pueden producir unos resultados óptimos. Sin
embargo, el control en tiempo real no es el único control que permite una producción óptima. El análisis de las estadísticas
de producción anteriores permite a los ingenieros aprender lo que se hizo bien o mal sobre un ciclo de producción anterior.
Saber cómo un cambio en el parámetro 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 - a menudo se denomina "lote de oro" o “golden batch”.
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.
El simple hecho de que la Bolsa de Nueva York y otras aplicaciones de alto rendimiento utilicen una base de datos
relacional, no quiere decir que sean la Base de Datos correcta para todo. 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, revisaremos 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.
Wonderware Spain
www.wonderware.es
Página 1 de 4
General
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.
Wonderware Spain
www.wonderware.es
Página 2 de 4
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.
Wonderware Spain
www.wonderware.es
Página 3 de 4
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.
Resumen
Este documento discute varias razones por las cuales un historizador de proceso es superior a la tarea de adquisición y
recuperación de información de planta en comparación con un sistema de Bases de Datos relacional. Sin embargo, esto no
quiere decir que el software comercial no tiene lugar en un entorno industrial. Hoy en día, la información de proceso es a
menudo necesaria fuera del entorno de planta y dentro del área de negocio de una empresa. No hay mejor manera de
ofrecer esta interfaz entre los datos de planta y los sistemas empresariales que una interfaz comercialmente aceptada y
estándar.
Como se señala en el último mito, el Wonderware Historian integra un producto comercial (Microsoft SQL Server), con una
interfaz abierta, estándar de consulta (SQL) para proporcionar acceso abierto a la planta de los datos históricos. Esta
interfaz es fácil de entender por el departamento de IT para la presentación de informes o la integración en el sistema ERP
de la empresa.
Wonderware Historian ofrece toda la capacidad señalada en este documento y mucho más. Verificado y utilizado en más
de 25.000 instalaciones en todo el mundo, Wonderware Historian permite acceder a la información de igual manera a los
operarios de planta y a los usuarios de oficina, ofreciendo la información correcta a la persona correcta; y deja de gestión
de las Bases de Datos a quien corresponde, al departamento de IT de la empresa y no al taller.
Wonderware Spain
www.wonderware.es
Página 4 de 4