Los estándares en IIoT Parte 2 de 4

Los estándares de desbloqueo de sistemas abiertos ofrecen la interoperabilidad prometida por OPAF y NAMUR

Por el Grupo FieldComm

La conocida metáfora del "bloque de construcción" puede estar ligeramente sobre utilizada por ahora, pero nunca ha sido tan cierta como ilustrar cómo los protocolos y tecnologías de Field-Comm Group forman la base de los dos últimos esfuerzos de apertura e interoperabilidad en las industrias de procesos. . Esto se debe a que el uso de FDI, FOUNDATION Fieldbus, WirelessHART y HART puede proporcionar información mucho más buscada y con frecuencia varada desde dispositivos de campo a sistemas en toda la empresa, que es el objetivo final de la apertura y la interoperabilidad.

CONOCE A OPAF Y NAMUR

El Open Process Automation Forum (OPAF, www.open-group.org/open-process-automation) está desarrollando un enfoque revolucionario de la apertura. Su objetivo es desarrollar una especificación abierta e interoperable de "estándares de estándares". En los dos años desde su lanzamiento, OPAF ha crecido a 116 miembros, incluidos usuarios finales, integradores de sistemas, proveedores y organizaciones de apoyo. El año pasado, el Grupo de Trabajo de Negocios de OPAF redactó su "Guía de Negocios de OPA" de 36 páginas (https: // publications.opengroup.org/g182) que describe una propuesta de valor y casos de negocios para la automatización de procesos abiertos (OPA).

Durante el mismo período, el Grupo de trabajo técnico de OPAF desarrolló el Modelo de referencia técnica (TRM) de OPAF, Parte 1: arquitectura técnica que define interfaces entre dispositivos, pero no dicta qué hay en esos productos o interferencias con su propiedad intelectual. El TRM cubre DCS regulares y soporte

MONITOREO ABIERTO Y OPTIMIZACIÓN CON NOA

La arquitectura abierta NAMUR (NOA) proporciona supervisión y optimización de Industrie 4.0 mediante el uso de una infraestructura de TI confiable en áreas de planta ubicadas centralmente, que no afectan los procesos determinantes y los controles deterministas o las interfaces propietarias. Fuente: NAMUR

PLC, HMI, E / S y redes basadas en Ethernet, así como controles avanzados y sistemas de ejecución de fabricación (MES). Se espera que TRM ofrezca apertura e interoperabilidad en tres áreas: Centro de datos OT local con computación avanzada en tiempo real (RTAC) y marco de control distribuido (DCF); OPA Connectivity Framework (OCF), que es un bus de servicio universal en tiempo real como Ethernet que utiliza un protocolo de comunicación estándar OPA como OPC UA; y los nodos de control distribuido (DCN) que son E / S configurables para el procesamiento de entrada / salida, control regulatorio, resolución de lógica y alojamiento de aplicaciones. Si tiene éxito, la arquitectura de OPAF dará como resultado sistemas de control radicalmente diferentes.

El segundo gran esfuerzo de apertura, NAMUR Open Architecture (NOA, www.namur.net) está programado para ser lanzado como un estándar IEC en 2021-22. NOA aborda la apertura como una evolución, es decir, sin afectar lo que ya funciona. NOA está tratando de mantener los beneficios de los sistemas existentes al combinar las aplicaciones de monitoreo y optimización (M + O) de NOA junto con los niveles de campo, automatización básica, MES y ERP existentes.

Estas aplicaciones cubren funciones de M + O como despacho, gestión de alarmas, control avanzado de procesos (APC) e industria de dispositivos 4.0, y funciones esenciales de M + O como analítica avanzada, historiador, HMI central, simulación de red de producción, centro de confiabilidad y la programación

Los estándares en IIoT Parte I de 4

Con la intención de divulgar el conocimiento que hay hasta la fecha en estándares  de Redes en la Industria, es necesario darle claridad en estos momentos en que la IIoT está entrando a las fabricas en México. Hay mucho escrito pero este libro blanco ha sido lo mejor que he encontrado.  Por esa razón transcribo parte del el elaborado por ControlGlobal.com y que será de mucha utilidad para nuestros seguidores de la Gerencia de Mantenimiento y de la Gerencia de IT. pues da claridad.

Por Ian Verhappen

La arquitectura de referencia empresarial de Purdue incorporada en el estándar ISA-95 / IEC 62264, en la que se basa la mayoría de las arquitecturas de sistemas de control y los estándares subsiguientes, incluidos los inalámbricos, la seguridad cibernética, la seguridad, etc., se originó en 1989.

A pesar de estar en uso por casi 30 años, mucha gente todavía cree que se basa en capas físicas, cuando en realidad define las funciones que se deben realizar en cada nivel de la arquitectura.

En el momento en que se desarrolló el modelo, y en la mayoría de los casos en la actualidad, todavía es cierto que la forma sigue a la función, y las diversas piezas de hardware tienden a estar estrechamente relacionadas con su función asignada. La zona de ciberseguridad IEC 62443 / ISA-99 y el concepto de conducto también tienden a fomentar el mantenimiento y la separación de cada una de las capas basadas en funciones.

Con los cambios en el procesamiento y la capacidad de cómputo que hemos visto en los diferentes niveles de la empresa, particularmente en el nivel 1, y la introducción de sistemas basados en la nube, entiendo que ISA-95, como parte de su revisión regular del documento, está revisando el modelo de arquitectura, con especial énfasis en el Nivel 1 y el Nivel 0.

Otro organismo de estándares de ISA, ISA-112 SCADA Systems (www.isa.org/isa112), también necesitaba un modelo de arquitectura en el que basar su trabajo. Aquí se muestra la versión actual de este modelo, que agrega más granularidad al modelo ISA-95.

Al crear este modelo, ISA-112 eligió deliberadamente usar letras para mostrar las diferentes capas, en parte para evitar confusiones. con el modelo de Purdue (que se muestra como referencia en el lateral), pero también para ayudar al cometa a relacionar el equipo físico con las funciones que el equipo necesita actuar.

En este modelo del comité de estándares de Sistemas ISADA ISA-112, las letras se usan para etiquetar capas para evitar posibles conflictos con ISA-95 y otros modelos similares. Los enrutadores y los cortafuegos entre capas no se muestran, ni otros servidores, aplicaciones y estaciones de trabajo específicos del sistema. Las aplicaciones externas (nube) alojadas de nuevo se podrían configurar para conectarse a dispositivos en cualquier nivel con los cortafuegos, túneles y enrutamiento adecuados. * Tenga en cuenta que aunque esto muestra un nivel de Purdue 5, el verdadero modelo de Purdue solo tiene niveles de 0 a 4 porque no anticipó aplicaciones externas.

En general, las capas A a D tenderán a estar en el sitio remoto, que puede ser cualquier cosa, desde un solo punto y RTU hasta un compresor remoto o estación de bombeo completa con su propio sistema de control "mini" con conexiones SCADA inalámbricas a almohadillas de pozos asociados, válvulas de aislamiento o instalaciones de almacenamiento remoto, lo que hace que el "sitio n" sea un Sistema SCADA pequeño, o al menos un sitio de concentración de datos por sí solo.

De manera similar, los niveles F y G identifican los componentes típicos de SCADA que residen en el (los) servidor (es) central (es) de SCADA, típicamente en el centro de control principal. Alarms e Historian se han identificado como dos bases de datos típicas que residen en este nivel, aunque como se indica en el cuadro de "base de datos" a la derecha, no son las únicas; son solo los que el comité considera que requieren una atención especial, ya que, desde la perspectiva de SCADA, tendrán algunas características únicas. Restricciones y elementos a considerar al desarrollar un sistema.

Por último, las líneas rojas a ambos lados del nivel J tienen la intención de mostrar una clara demarcación entre los sistemas OT (sistemas relacionados con SCADA), TI y redes públicas o externas como un recordatorio para prestar especial atención a los requisitos cibernéticos al cruzar entre diferentes capas y sistemas

La virtualización de sistemas por Open Process Automation Forum (OPAF), y posiblemente IIoT, está cambiando las arquitecturas del sistema de control una vez más, con el mayor impacto en la parte superior (inexistente Nivel 5 en la parte superior del modelo) y nuevamente en el Nivel 1, con el control regulador básico acercándose al proceso en sí. Debido a que la mayor parte de la funcionalidad de estos modelos residirá en el software en lugar de la representación basada en el hardware, se puede afirmar que el modelo de referencia basado en la función será aún más importante, ya que el hardware físico podría potencialmente aplastarse en menos capas que residen en la nube. Un par de máquinas virtuales para el hardware sobre la (s) capa (s) del sensor.