Historiador de Ignition: Información general, configuración e implementación

Conozca la información más importante sobre el historial de datos de Ignition

Índice

1. Visión general.

2. Módulos.

3. Almacenamiento de datos.

4. Recuperación de datos.

5. Arquitecturas.

6. Benchmarking.

7. Mejoramiento.

8. Seguridad.

Última actualización para Ignition 8.1.

Visión general

La funcionalidad del historial de datos de Ignition es un conjunto sólido de características que están integradas en los módulos de Ignition, que brindan adquisición, almacenamiento, recuperación y visualización de datos.

Como ocurre con todo lo demás en Ignition, la funcionalidad del historiador es modular. A menudo, se utilizan varios módulos juntos para proporcionar un sistema completo. A menudo, los usuarios combinan la funcionalidad de historiador de Ignition con la funcionalidad SCADA, HMI, IIoT o MES.

Aunque mucha gente piensa en el módulo Tag Historian de Ignition como el "Ignition Historian", un historiador de datos completo a menudo se describe no solo almacenando datos de etiquetas, sino también almacenando datos basados en eventos y proporcionando visualización. Como tal, este documento cubre los módulos para esas características.

Módulos

Diagrama 1: Una posible configuración de módulos cuando Ignition se utiliza como historiador de datos.

La arquitectura modular de Ignition permite elegir entre usar un solo módulo o usar varios módulos para una instalación determinada. Lo mínimo necesario para utilizar Ignition como historiador de etiquetas es el módulo Historial de etiquetas. Muchas empresas utilizan más módulos, especialmente si se necesita almacenamiento basado en eventos o si se utilizará la comunicación directa del dispositivo. Los módulos que se utilizan en un sistema típico se describen a continuación.

• Módulo Tag Historian

Esto proporciona almacenamiento y recuperación de datos históricos a través del sistema de etiquetas de Ignition. Los cambios de etiquetas entrantes se pueden canalizar al almacenamiento de datos y el historial de etiquetas se puede recuperar a través del módulo.

Almacenamiento

El almacenamiento de datos por el módulo Tag Historian puede ir a varias ubicaciones. El almacenamiento interno está disponible para almacenar pequeñas cantidades de datos dentro del propio Ignition. El almacenamiento basado en SQL es la recomendación normal para la mayoría de los sistemas y canaliza los datos a una base de datos SQL adjunta. Los motores de almacenamiento adicionales están disponibles a través de desarrolladores externos, algunos de los cuales se pueden encontrar en Module Showcase. Independientemente del motor de almacenamiento, el módulo Tag Historian ofrece herramientas para velocidades de almacenamiento de datos, compresión, bandas muertas y otras características.

Recuperación

El módulo Tag Historian se puede utilizar para recuperar el historial y realizar cálculos y agregaciones de datos históricos. Dependiendo del motor de almacenamiento que se utilice, el módulo Tag Historian realizará la recuperación directamente y realizará los agregados apropiados, o en el caso de utilizar motores de almacenamiento de terceros, el módulo Tag Historian pasará la solicitud al motor de almacenamiento.

• Módulo puente SQL

Este módulo proporciona grupos de transacciones, que se utilizan para el registro basado en eventos. Los datos se almacenan en tablas de base de datos SQL y se proporcionan opciones para almacenar códigos de calidad, marcas de tiempo, creación automática de tablas configuradas, velocidades de datos, programación y más.

• Módulos de controlador y OPC UA

Estos módulos proporcionan recopilación de datos. El módulo OPC UA actúa como la base de los controladores de Ignition, que ofrecen comunicación nativa a una gran cantidad de dispositivos. Cabe señalar que Ignition también puede conectarse a servidores OPC de terceros para la recopilación de datos, ya sea a través de la plataforma para conexiones OPC UA o mediante el módulo OPC COM para conexiones OPC DA.

• Transmisión, distribuidor y motor MQTT

Estos módulos IIoT pueden ser una parte integral de la recopilación de datos cuando se utilizan arquitecturas modernas. El motor MQTT se conecta directamente al módulo Tag Historian de Ignition para alimentar los datos. También incluye almacenamiento de eventos a través de DRecords, que colocan datos en tablas de bases de datos que crean registros similares a los grupos de transacciones históricas.

• Módulo de perspectiva / visión

A veces, la visualización es parte de un requisito para los historiadores de datos. Perspective y Vision son sistemas de visualización que proporcionan herramientas de creación de pantallas sencillas y fáciles de usar para crear paneles de control, aplicaciones de escritorio, páginas web e informes en pantalla.

• Módulo de informes

Aunque a menudo no se incluye en un historial de datos, vale la pena mencionar el módulo de informes, ya que permite la generación y el envío automático de informes en PDF directamente desde Ignition.

• Plataforma de encendido

Aunque este no es un módulo, vale la pena señalar la plataforma en sí, ya que proporciona una serie de funciones. Además de proporcionar los subsistemas necesarios, como el sistema de etiquetas, Ignition Platform también proporciona soporte de scripting para reaccionar y responder a los cambios de etiquetas en tiempo real, e incluye un lenguaje de expresión que permite etiquetas que se basan en ecuaciones o cálculos.

Almacenamiento de datos

El almacenamiento de datos de datos basados en eventos a través de SQL Bridge se almacena en bases de datos SQL. SQL Bridge permite a los usuarios definir nombres de tablas y columnas, y elegir qué almacenar y sobre qué activadores. Los grupos de transacciones históricas son una buena opción para la mayoría de los registros basados en eventos.

El almacenamiento de datos de datos basados en etiquetas a través de Tag Historian puede ir a varias ubicaciones. La mayoría de los usuarios se dirigen a una base de datos SQL. Otras posibilidades incluyen un pequeño sistema de almacenamiento interno y motores de almacenamiento de terceros, muchos de los cuales se pueden encontrar en Module Showcase.

Recuperación de datos

• Usar las herramientas de visualización de Ignition

Al usar Perspective o Vision, Ignition proporciona un buen conjunto de herramientas integradas para la recuperación de datos. Para el historial de etiquetas, esto incluye enlaces de historial de etiquetas, un tipo de fuente de datos para el módulo de informes, integración automática con algunos componentes de gráficos y algunas configuraciones de arrastrar y soltar en las herramientas de diseño. Para los datos de eventos que se almacenan en una base de datos SQL, Ignition tiene consultas con nombre que permiten la recuperación, incluida la compatibilidad con las condiciones, las limitaciones de fecha y calidad, y cualquier otra cosa que permita la sintaxis SQL.

• Para usar con herramientas externas

Para los datos de eventos, las herramientas externas pueden consultar la base de datos directamente, haciendo que todo sea accesible para las partes que tienen los permisos de seguridad adecuados.

Para los datos del historial de etiquetas, se recomienda que las herramientas externas consulten datos de las API de Ignition. Esto es útil para que cualquier recuperación de datos pase por la lógica de Ignition que proporciona interpolación, agregación, expansión de particiones y cualquier otra lógica necesaria para la recuperación de datos de etiquetas. La función API para recuperar estos datos es system.tag.queryTagHistory (), y configurar un punto final REST para esa función es simple usando el Módulo WebDev.

También debe tenerse en cuenta que las tablas de base de datos creadas automáticamente por Ignition están documentadas completa y públicamente para aquellos usuarios que deseen consultar directamente las tablas en lugar de utilizar la función queryTagHistory () recomendada.

Arquitecturas

Estos diagramas de arquitectura se basan en Ignition ejecutándose con el módulo Tag Historian dirigido a una base de datos SQL. Tenga en cuenta que las arquitecturas que utilizan un almacenamiento de historial de etiquetas diferente pueden verse significativamente diferentes. (Por ejemplo, el conector Azure ADX gratuito de código abierto escrito por Microsoft tiene un rendimiento muy alto y se almacena en la nube, por lo que no se utiliza ninguna base de datos SQL).

Si utiliza una base de datos SQL para el almacenamiento, estas arquitecturas pueden proporcionar una idea de las posibles configuraciones. Consulte la sección Puntos de referencia a continuación para tener una idea de los posibles rendimientos de las diferentes tecnologías de bases de datos.

• Arquitectura simple de baja resiliencia

Servidor 1: Ignition
Servidor 2: Base de datos SQL

• Arquitectura simple de alto rendimiento
  
  

Servidor 1: Ignition
Servidor 2: Ignition con solo el módulo Tag Historian y la base de datos SQL instalada en el mismo servidor
Ventaja: Comunicación de red de puerta de enlace de alta velocidad entre servidores. También soporta bien las dificultades de comunicación, la latencia y la pérdida de paquetes.

• Arquitectura de bases de datos múltiples de alto rendimiento

Servidor 1: Ignition
Servidores 2 y 3: Ignition con solo el módulo Tag Historian y la base de datos SQL instalada en el mismo servidor
Ventaja: Permite escalar más allá de los límites de rendimiento de una sola base de datos.

• Arquitectura del recopilador de datos

Los PLC u otros dispositivos se comunican con los recolectores de datos en el campo. Esos recopiladores de datos pueden ser Ignition, Ignition Edge o sistemas que hablan MQTT Sparkplug B de forma nativa. Además, algunos dispositivos hablan MQTT Sparkplug B de forma nativa con transferencia de historial y soporte para almacenamiento y reenvío. A menudo, esos dispositivos pueden comunicarse directamente sin un recolector separado.

Los recolectores son opcionales. Dependiendo de la industria, pueden tener sentido desde el punto de vista del ancho de banda, la segmentación de la red y la seguridad.

Benchmarking

Los datos basados en eventos y los datos basados en etiquetas deben tener el hardware y el software adecuados para satisfacer las necesidades del diseño. Sin embargo, un sistema diseñado apropiadamente generalmente tiene miles de veces más datos basados en etiquetas que datos de eventos. Como tal, los puntos de referencia aquí se centran en los datos y el rendimiento del historial de etiquetas.

• Comprensión de los puntos de referencia

Los puntos de referencia se basan en los rendimientos. Por ejemplo:

A una tasa de 10 segundos, con un 10% de etiquetas cambiando

Comprender las tasas y los porcentajes de cambio

Tenga en cuenta la tasa y el porcentaje de cambio de etiqueta enumerados anteriormente. El rendimiento del historial de etiquetas de Ignition se califica mejor en cambios de etiquetas por segundo.

A una tasa de 10 segundos, con un 10% de cambios de etiquetas, 100 etiquetas producen 1 cambio de etiqueta por segundo.

Supongamos que una base de datos puede manejar 10,000 cambios de etiquetas por segundo. Esta tabla describe cuántas etiquetas maneja:

Etiquetas de base de datos de ejemplo

¿Cuántas etiquetas puede manejar una sola base de datos?

Como puede ver en la tabla anterior, eso depende en gran medida de la tasa de almacenamiento y la tasa de cambio de las etiquetas. Los sistemas de encendido están configurados de forma predeterminada para utilizar velocidades de almacenamiento de 10 segundos para las etiquetas. Sin embargo, algunos usuarios quieren tasas de 1 o más rápidas para algunas o todas las etiquetas. Se apoya y fomenta ir a tasas más rápidas según sea necesario. Sin embargo, tenga en cuenta que velocidades más rápidas equivalen a más cambios por segundo en la base de datos.

SSD o HDD?

Inductive Automation recomienda encarecidamente el uso de un SSD tanto para la instalación de Ignition como para el almacenamiento de la base de datos si se esperan rendimientos medios-bajos, medios o altos. Si solo se esperan rendimientos de historial bajos, un disco duro puede ser suficiente. Si elige un HDD, se recomienda probar el rendimiento de la base de datos para asegurarse de que un HDD maneje las velocidades de almacenamiento requeridas.

Historiador interno

El historiador interno es un historiador basado en disco, disponible directamente dentro de Ignition. Esta puede ser una excelente manera de almacenar una pequeña cantidad de datos en ubicaciones remotas o ubicaciones donde no hay una base de datos SQL disponible.

Los datos están configurados para estar limitados de forma predeterminada a 1 semana de datos. Aunque ese límite se puede ampliar, la Automatización inductiva no recomienda almacenar años de datos en el historiador interno, ya que el historiador interno solo está destinado a pequeñas cantidades de historia local. Si calcula el período de tiempo necesario para registrar, sus tasas y su porcentaje de cambio, le recomendamos que mantenga los registros totales en alrededor de 10 millones de filas. Como el historiador interno no tiene algunas de las características avanzadas del almacenamiento de la base de datos SQL, como el particionamiento automático, cualquier cosa planificada para almacenar más de 10 millones de registros debe usar el almacenamiento de la base de datos SQL u otro motor de almacenamiento.

Cambios de etiqueta por segundo

Para proporcionar puntos de referencia que sean significativos, estos puntos de referencia se clasifican en cambios de etiquetas por segundo. Estime su Tasa de almacenamiento y Tasa de cambio, y multiplíquelos para calcular los Cambios de etiqueta por segundo.

Cambios de etiqueta por segundo

Ejemplo: 100,000 etiquetas * 20% de cambio / tasa de almacenamiento de 5 s = 100,000 * .2 / 5 = 4,000

Inductive Automation tiene una hoja de cálculo de calculadora de almacenamiento disponible que se puede proporcionar a pedido para ayudar con la estimación.

• Benchmarks de bases de datos SQL

Sistema de prueba

Notas:

• Estos puntos de referencia son solo estimaciones. Las diferencias de hardware y muchos otros factores pueden tener un impacto significativo en el rendimiento.
• Estas estimaciones se basan en rendimientos de estado estacionario. Tener configurados tamaños razonables de partición de Ignition Tag Historian ayudará a evitar que el rendimiento se degrade en la mayoría de las bases de datos. La escala de tiempo es la excepción en esta lista, ya que no experimenta degradación con el tiempo.
• Oracle no está incluido en esta lista ya que Inductive Automation no tiene una licencia empresarial de Oracle. El ligero Oracle Express fue probado y tuvo un rendimiento similar al de MySQL, pero se espera que una versión completa de Oracle tenga un rendimiento significativamente mejor.

Estos puntos de referencia de escritura inicial se incluyen solo como referencia. La mayoría de las bases de datos tienen un alto rendimiento en el rendimiento inicial y esa velocidad luego disminuye hasta que alcanzan un estado estable. La primera imagen de arriba captura ese estado estable. Si está ejecutando sus propias pruebas y los resultados iniciales muestran un mayor rendimiento, asegúrese de dejar que el sistema funcione durante unas horas o unos días para que las tasas se nivelen.

• Requisitos de espacio de almacenamiento

Los requisitos de almacenamiento sin comprimir ni optimizar en las bases de datos SQL requieren alrededor de 100 bytes por cambio de etiqueta, independientemente de la base de datos elegida.

Con base en ese número, es bastante fácil calcular los requisitos de almacenamiento.

Requisitos de espacio de almacenamiento

Por ejemplo, si tiene 1000 etiquetas con un 10% de cambio y una tasa de 10 segundos, está viendo 10 cambios de etiqueta por segundo. Multiplique eso por 100 bytes y 86,400 segundos en un día, y obtendrá alrededor de 86,4 MB por día.

Tenga en cuenta que muchas bases de datos tienen opciones de compresión, que pueden reducir el almacenamiento total requerido en un 30-50% o más, generalmente a costa de la CPU / rendimiento. La escala de tiempo, específicamente, tiene una opción que pretende reducir el almacenamiento hasta en un 90% en determinadas circunstancias. Si el espacio de almacenamiento es un factor limitante principal, puede valer la pena explorar estas opciones.

• Rendimiento frente a calidad de red

Las pruebas de rendimiento de la calidad de la red se realizaron utilizando Microsoft SQL Server. Se cree que es una expectativa razonable que otras bases de datos sigan características de rendimiento similares en lo que respecta a la latencia de la red.

Escenario 1

Escenario 2

Todos los resultados se clasifican en miles de cambios de etiquetas por segundo.

Como se puede ver en los números, Ignition es mucho más resistente en el escenario 2, donde ni siquiera se puede ver una degradación del rendimiento hasta que haya un porcentaje significativo de paquetes descartados o una latencia de más de 100 ms. Esta prueba se realizó con una gran cantidad de cambios de etiqueta a una velocidad de un segundo.

Mejoramiento

• Optimizaciones generales

Estas optimizaciones pueden aplicarse a todos los sistemas.

Puente SQL

• Configure la poda de datos en tablas que no necesitan almacenar el historial para siempre.
• Asegúrese de que los activadores se utilicen para almacenar eventos correctamente.
• No almacene datos que no sean necesarios. Si se necesita almacenamiento de series de tiempo, considere usar el historial de etiquetas en su lugar y solo registrar eventos a través de Grupos de transacciones.
• Al escribir consultas sobre los datos almacenados por SQL Bridge, observe la cláusula WHERE de las consultas y cree los índices adecuados en las tablas de la base de datos.
• Supervise el rendimiento del sistema, para asegurarse de que no se perdió de agregar un índice y para asegurarse de que el tamaño de la tabla de la base de datos no sea excesivo para el proyecto y el hardware en el que se está ejecutando.

• Establezca bandas muertas razonables para las etiquetas. Las bandas muertas se aseguran de que no se registren datos basura. Si un sensor tiene una precisión de 0.2, no hay razón para registrar un cambio de 0.02, ya que ese cambio es solo ruido y no tiene valor. Establecer bandas muertas razonables puede ahorrar una cantidad significativa de espacio de almacenamiento y rendimiento del ruido de registro.
• Establezca bandas muertas de tiempo ("Tiempo mínimo entre muestras") según tenga sentido, para que las etiquetas no se registren más rápido que las tasas específicas.
• Establezca las tasas de etiquetado de manera adecuada. Solo configure las etiquetas para que se registren a velocidades de 1 segundo si es necesario. Por defecto, a velocidades más lentas a menos que los requisitos indiquen lo contrario.
• Si tiene sentido para su sistema, le recomendamos que desactive la Detección de datos obsoletos. Si el sistema está funcionando más lento de lo que cree que debería ser, consulte la tabla sqlth_sce. Si hay más de unos pocos cientos de filas, es posible que haya sobrecargado el sistema sin darse cuenta. Desactivar la Detección de datos obsoletos es normalmente algo seguro (en las propiedades avanzadas de la conexión de la base de datos), pero primero lea el manual del usuario para asegurarse de que comprende la configuración. Desactivar esa configuración evitará que la tabla sqlth_sce crezca si el sistema experimenta lentitud.
• Si usa MySQL, agregue un parámetro de conexión adicional a la conexión de la base de datos. Esto aumentará el rendimiento de alrededor de 1,000 cambios de etiquetas por segundo a alrededor de 10,000-20,000. rewriteBatchedStatements = true
• Asegúrese de que no se estén ejecutando otras aplicaciones o servicios en los sistemas donde se alojan Ignition y las bases de datos.
• Ajuste las particiones para evitar que superen los 100 ma 1 billón de filas por partición. Mantener los tamaños de partición razonables agiliza las consultas en períodos de tiempo cortos y ayuda a garantizar que los cuadros y gráficos del tablero se representen con relativa rapidez.
• Configure particiones preprocesadas si se esperan consultas durante períodos más largos. Tenga en cuenta que hacerlo requerirá almacenamiento y procesamiento adicionales, lo que afectará marginalmente el rendimiento general de almacenamiento alcanzable.

Altos rendimientos

Estas optimizaciones se aplican si tiene una especificación de sistema o en producción donde espera un alto rendimiento en términos de cambios de etiquetas por segundo.

• Opción 1: Reducir el rendimiento siguiendo las instrucciones anteriores.
• Opción 2: Agregue otra base de datos / esquema al DBMS de la base de datos SQL en el mismo almacenamiento. Varias bases de datos pueden ayudar a dividir la carga y pueden aumentar el rendimiento. Configure algunas etiquetas para ir a una base de datos y otras etiquetas para ir a la otra base de datos.
• Opción 3: Si los rendimientos aún no se pueden lograr, colocar varias bases de datos en el mismo DBMS, pero apuntando a un almacenamiento diferente, también puede aumentar los rendimientos. Algunas bases de datos están muy limitadas por la E / S de la unidad, y dividir las bases de datos en diferentes tipos de almacenamiento puede tener un impacto significativo.
• Opción 4: Señalar a Ignition a varios servidores de bases de datos garantizará un rendimiento independiente para cada servidor, lo que duplicará efectivamente el rendimiento posible que proviene de un solo servidor de base de datos.
• Opción 5: Considere una arquitectura distribuida. Si hay varios sitios y un sistema central, considere mantener los datos del sitio en cada sitio y enviar datos resumidos a la central. No te preocupes; Si está utilizando la red de puerta de enlace, siempre puede acceder a los datos del historial de etiquetas del sitio desde el sistema central, tratando todas las puertas de enlace de Ignition conectadas como un gran sistema distribuido. Los informes centrales, los paneles de control y otros elementos visuales pueden transmitir datos desde los sitios para mostrarlos de forma centralizada, siempre que el sitio esté en línea.
• Opción 6: Si se requieren rendimientos muy altos, en el rango de 500,000 a 1,000,000 de cambios de etiquetas por segundo, por ejemplo, esto puede exceder lo que es práctico con un conjunto de bases de datos SQL. Hay otros motores de almacenamiento disponibles para Tag Historian en Module Showcase y otras áreas que tienen rendimientos extremadamente altos. Puede valer la pena considerar estas opciones cuando se necesitan rendimientos muy altos.

• Compresión de base de datos (30-50%)
• Muchas bases de datos tienen opciones para comprimir datos para tablas.
• Compresión de transmisión completa
• La compresión de unidades para unidades de almacenamiento también puede proporcionar beneficios.
• Normalmente no se usa junto con la compresión de base de datos.
• Si usa Timescale
• Chunking & Compression de Timescale puede proporcionar ahorros aún más significativos. La compresión ocurre después de un período de tiempo configurable. El ahorro de espacio en la unidad ocurre una vez transcurrido ese período y activa la compresión. Los ahorros se promueven hasta en un 90% o más. Inductive Automation no ha ejecutado evaluaciones comparativas, por lo que en este momento se desconocen los ahorros exactos frente a los datos de la tabla de Tag Historian.
• Usar otros motores de almacenamiento
• Algunos motores de almacenamiento tienen ahorros de espacio significativos.
• Ejemplos:
• La entrada de Module Showcase tiene requisitos de almacenamiento más pequeños por registro.
• Azure ADX tiene un soporte de rendimiento muy alto y se supone que tiene un almacenamiento eficiente. Microsoft ha lanzado un módulo de código abierto gratuito como conector, que se puede encontrar en github. El servicio Azure ADX es un servicio de pago de Microsoft.
• Aunque Inductive Automation puede proporcionar orientación a los autores de módulos de vez en cuando, Inductive Automation no admite ni respalda los módulos Module Showcase. Alentamos a los clientes que exploran estos a que se pongan en contacto con los autores del módulo y exploren la documentación del módulo antes de tomar la decisión de utilizar uno de estos módulos.
  
  

Seguridad

• Guía de refuerzo de la seguridad

La automatización inductiva tiene un fuerte enfoque en la seguridad y proporciona orientación sobre cómo proteger las puertas de enlace de encendido individuales. Inductive Automation recomienda consultar las últimas pautas de refuerzo de la seguridad para conocer lo último en la protección de una puerta de enlace de encendido individual, que se puede encontrar aquí: https://inductiveautomation.com/resources/article/ignition-security-hardening-guide

• Cifrado en curso

El cifrado en curso puede ser una consideración importante para cualquier dato histórico. Ignition puede ejecutarse a través de redes seguras y toda la transferencia de datos puede ejecutarse a través de VPN u otros túneles cifrados que admitan el tráfico IP normal. Además, la comunicación de cliente a servidor de Ignition se puede cifrar, la comunicación de puerta de enlace a puerta de enlace se puede cifrar y el tráfico de puerta de enlace a base de datos se puede cifrar para todas las bases de datos principales. Algunos dispositivos en sí mismos no admiten el cifrado ni otras medidas de seguridad, por lo que es importante considerar cómo proteger la comunicación de ese dispositivo. A veces, la solución es colocar un pequeño dispositivo de recopilación de datos junto al hardware inseguro, ejecutando Ignition Edge u otra pieza de software, para mantener la comunicación no cifrada fuera de cualquier red. Otras soluciones incluyen cifrado de VLAN y redes de seguridad para tráfico no cifrado mediante reglas de firewall, IDS y otras medidas de seguridad. Inductive Automation recomienda trabajar con expertos en seguridad si surge alguna pregunta sobre la seguridad de la comunicación del dispositivo.

• Cifrado en reposo

El cifrado en reposo se puede lograr cifrando las unidades donde se almacenarán los datos o cifrando las tablas de la base de datos si se utiliza una base de datos SQL para el almacenamiento de datos. Estas herramientas de cifrado formarán parte de las herramientas de gestión de la base de datos. El cifrado en reposo generalmente no requiere que la unidad en la que se está ejecutando Ignition esté cifrada, ya que Ignition no actúa como el medio de almacenamiento principal. Según el tráfico, el rendimiento y la configuración de Ignition, existe la posibilidad de que los datos almacenados en caché en el sistema Store & Forward se escriban temporalmente en el disco desde Ignition. Si se requiere que estos datos se cifren en reposo, incluso mientras se almacenan temporalmente en el disco, entonces, en ese caso, sería apropiado cifrar la unidad en la que se ejecuta Ignition también.

• Seguridad del cliente

La seguridad del cliente normalmente se logra mediante el cifrado TLS 1.2 / 1.3, que proporciona el mismo nivel de cifrado que un sitio web bancario típico. Se utilizan certificados PKI estándar y los pasos para la configuración se tratan en la documentación de Ignition. Consulte la Guía de refuerzo de seguridad anterior para obtener orientación sobre cómo habilitar TLS en Ignition.

Publicado en español el 25 de Agosto del 2021.

Originalmente publicado el 03 de Junio del 2021.

Fuente original: 

https://inductiveautomation.com/resources/article/ignition-historian