Últimas tendencias en Controladores de Automatización Programables
PACS
Últimas tendencias en Controladores de Automatización Programables El control industrial, con la adopción de los Controladores de Automatización Programables como corazón y cerebro de la máquina, tomo la decisión de concentrar toda la inteligencia en un solo equipo. Se intenta, como premisa de diseño, unificar la toma de decisiones en el PAC y que pueda gestionar todas las tecnologías necesarias para la máquina.
El control industrial, con la adopción de los Controladores de Automatización Programables como corazón y cerebro de la máquina, tomo la decisión de concentrar toda la inteligencia en un solo equipo. Se intenta, como premisa de diseño, unificar la toma de decisiones en el PAC y que pueda gestionar todas las tecnologías necesarias para la máquina. La gestión y diagnóstico de la red Ethernet, la visión artificial o el control de impresión de etiquetas; son ejemplos de tecnologías que se han ido sumando a las capacidades de los Controladores de Automatización Programables en el esfuerzo de simplificar las máquinas. Ethernet como bus de campo. Protocolo PRP
El pilar que está sustentando la incorporación de las máquinas a IIOT es, sin lugar a dudas, el uso de la Ethernet como bus único y exclusivo para todas las necesidades de la máquina. Un bus único Ethernet, que nos permite el tránsito de forma inteligente por la misma instalación de protocolos muy diferentes y con diversas necesidades, es el soporte necesario para desarrollar las prestaciones más punteras del IIOT. Una máquina cuyo control está basado en el protocolo Ethernet/ip, 100% compatible con los estándares Ethernet IEEE 802.x, permite sin ningún esfuerzo añadir servicios tan dispares como el control de servomotores, la gestión de la topología de un posible anillo de switches o el envío del ya tradicional correo electrónico.
Los primeros servicios que se añadieron en los PAC respecto la red Ethernet fueron ligados a la necesidad de diagnosticar la red (que puede llegar a estar formada por varias decenas de switches).
Un PAC conoce el estado de la red que usa. De forma, que aparte de diagnosticarla puede modificar su topología. Por ejemplo anulando puertos en los swiches (ya clásico ejemplo del uso conjunto de PACS Logix con switches Stratix)
O puede conocer el punto de ruptura de un anillo creado con protocolo DLR de forma que tarda milisegundos en re-direccionar el tráfico y evidentemente avisar del lugar exacto de la rotura a mantenimiento. Device Level Ring (DLR): Es un protocolo que suministra los mecanismos para detector, gestionar y recuperarse de fallos en una red basada en anillo.
Cuando se diseña la red Ethernet de una máquina, se han de tener varios (por no decir muchos) parámetros en cuenta. Uno de los parámetros que tiene mucho peso, es la resiliencia de la red. Resiliencia: Capacidad de un material, mecanismo o sistema para recuperar su estado inicial cuando ha cesado la perturbación a la que había estado sometido.
Dicho de otra forma. Cuando aparezca un agente perturbador de mi red (por ejemplo un cable que se rompe de forma imprevista) ¿Cuánto tiempo puedo permanecer sin comunicaciones efectivas entre los elementos de la máquina?
Está pregunta siempre es un poco tramposa, ya que todos tenemos la idea “lo mínimo posible” pero siendo estrictos el tiempo de reacción necesario para una planta de bombeo es muy diferente al de una máquina
envasadora o al de una línea de impresión de papel.
Teniendo en cuenta que los principales protocolos estándar que funcionan en la capa 2 del modelo OSI que nos permitan tener una alta disponibilidad (alta resiliencia) son: Spanning Tree Protocol, REP Ring, Device Level Ring, Parallel Redundancy Protocol, Flex Links y Etherchannel. ¿Cuál de ellos debemos usar?
Si la respuesta, a la pregunta, es de varios centenares de segundos, puedo montar una red con switches y protocolo STP. Si la respuesta es de decenas de milisegundos, mejor que ponga switches con algún protocolo concreto de gestión de anillos tipo REP Ring o Flex Links o Etherchannel. Si ya la respuesta es de 1 o 2 milisegundos tenemos que montar switches y/o equipos con protocolo de anillo Device Level Ring.
¿Pero y si la respuesta es de 0 milisegundos?
En este caso, una de las mejores soluciones consiste en instalar una red doble con el protocolo -Parallel Redundancy Protocol- (PRP). Parallel Redundancy Protocol (PRP): Es un protocolo standard de red Ethernet capaz de garantizar una conmutación perfecta en caso
de fallo de cualquier componente de la red.
Esta infraestructura de red se basa en crear con switches dos redes, LAN (A y B) en paralelo, que no tienen por qué tener la misma estructura pero si han de estar absolutamente aisladas entre ellas. De esta forma, un fallo en una de ellas no afecta al tráfico en la otra red.
Los equipos conectados a este tipo de infraestructura de comunicación se clasifican en tres categorías: DAM, equipos con doble conector Ethernet que se conectan directamente a las dos redes sin intermediarios. SAN equipos con conector simple únicamente conectados a una de las dos redes (y por tanto sin aprovechar la doble red). Y VDAM, equipos con conector simple conectado a un –Redbox- que hace de intermediario para poder acceder a la dos redes.
Cualquier equipo de control se puede conectar como VDAM o como SAM, pero evidentemente perdemos prestaciones en la resiliencia y en la disponibilidad.
Lo ideal es que el propio equipo disponga de doble conector con protocolo PRP nativo en su Firmware, como es el caso de los controladores Controllogix, de las E/S Flex5000 y las ES 1756.
En la siguiente imagen podemos ver de forma esquemática como tanto un controlador Controllogix como E/S remotas de la familia 1756 se conectan directamente a las dos redes A y B sin intermediarios gracias a la implementación por Firmware del protocolo PRP. En la misma imagen también se observa como equipos sin esta capacidad se conectan como estación SAN o a través de un Switch industrial que se ha configurado como Redbox.
Veamos en la siguiente tabla los diferentes protocolos existentes en los diferentes equipos que conforman una red Ethernet Industrial.
Protección avanzada de la Propiedad Intelectual
La Propiedad Intelectual del código, que se pone dentro de un PAC, ha sido durante mucho tiempo una preocupación menor en los fabricantes de máquinas. Si bien es cierto que durante años se han usado métodos como las contraseñas para su protección, hay que tener en cuenta que la gestión de contraseñas requiere de un esfuerzo considerable en el lado “humano”. ¿Cuántas veces hemos visto las credenciales de un determinado usuario apuntados en un papel junto al frontal de un HMI?. Las contraseñas son fácilmente “encontradas” con técnicas básicas de sniffer en la red, por no mencionar las malas praxis de enviarlas a los compañeros por correo electrónico sin encriptar, apuntarlas en papel o simplemente usar el mismo código en diferentes sistemas de seguridad. Si nos enfrentamos a piratas profesionales con suficiente preparación y recursos, las contraseñas son una protección insuficiente.
Pero imaginemos que usamos un sistema de contraseñas robusto para proteger nuestros códigos más valiosos y que pudiésemos eliminar las malas praxis asociadas al factor humano. ¿Podemos garantizar la transmisión segura de datos entre nuestro PC (sin virus) usado para programar y el PAC?
La garantía de transmisiones seguras entre equipos puede ser implementada mediante la tecnología Ipsec que se usa comúnmente para crear Virtual Private Networks (VPN). Ipsec suministra las siguientes características de seguridad:
Autentificación de los puntos finales (Cliente y Servidor)
Autentificación e integridad de los datos (mediante mensajes de comprobación de integridad)
Confidencialidad de los datos (mediante encriptación)
Por tanto usando contraseñas robustas más tecnología Ipsec, ¿Estamos seguros de no entregar nuestro código a personas ajenas a nuestra empresa? La respuesta es: Depende de quien realice el túnel.
Lo comúnmente usado por muchos fabricantes de maquinaria es instalar un dispositivo servidor de túneles VPN (usualmente llamado Router VPN) colocado entre la red de la máquina y la red pública a la que está conectada la máquina (usualmente red del cliente final). Por tanto, aunque el túnel VPN garantice autentificación, integridad y confidencialidad entre nuestro PC y el dispositivo que hace el túnel, no podemos asegurar que la red de la máquina haya sido atacada y que por consiguiente la información que le llega al PAC no ha sido “vista” por un equipo colocado entre el “Router VPN” y el PAC. Es la versión industrial del Man In The Middle.
Pero afortunadamente la solución es muy simple, debemos hacer que sea el propio PAC el que haga la función de servidor VPN para impedir (no dejar espacios) para el ataque conocido como el Man In the Middle ni opciones a los sniffers.
De esta forma, al ser el propio PAC el que genera el servidor VPN y siendo nuestro PC de confianza el cliente de la VPN podemos garantizar que la transmisión es realmente segura.
Ya hemos garantizado la transmisión, pero en un entorno de trabajo cada vez más deslocalizado donde diferentes grupos de desarrollo trabajan en diferentes sedes y donde cada vez más se trabaja con subcontratas (difíciles de supervisar, con PC’S fuera de nuestro dominio, sin garantías de antivirus actualizados…) ¿Cómo podemos plantear el intercambio de códigos (o parte de ellos) de forma segura?
La solución fácil viene nuevamente de aplicar tecnologías de encriptado. En este caso no hablamos de túneles seguros con encriptación para y únicamente la transmisión, sino de tener partes del código del PAC encriptado que se pueden intercambiar entre los usuarios sin tener necesidad de des-encriptarlos para su uso.
La responsabilidad de evitar fugas de código se centraliza en la figura del “Librarian”, persona que encripta el código y que genera los certificados de seguridad asociados. Estos certificados necesitan del soporte de un chip criptográfico que suele ir integrado en una memoria USB o tarjeta SD.
De esta forma, el código puede circular por e-mails, de PC en PC o incluso de PAC a PAC con garantía que solo el Librarian es capaz de generar el certificado correspondiente (certificados de uso, visión, Edición, Copia, Proteger o exportar sin encriptación) a la persona concreta que lo necesite por el tiempo que el Librarian considere necesario.
En este escenario, la persona que hace de Librarian encripta, los usuarios autorizados usan el código y el PAC des-encripta y ejecuta el código obteniéndose una protección total!
Llegados a este punto, donde es el propio PAC que des-encripta el código justo antes de calcularse, ¿Por qué no vincular el uso de estos códigos a la presencia de un certificado de seguridad concreto?
Esto es lo que realizan las nuevas familias de controladores de última generación con los códigos protegidos a ejecución. Por un lado, el librarían encripta partes del código para que otros usuarios puedan insertarlo en sus programas (Propiedad Intelectual garantizada por la encriptación). Estos códigos son descargados a los PAC y son los propios controladores los que leyendo la tarjeta SD con chip criptográfico y comparando los certificados presentes en misma SD, determina si un código es ejecutable o no y si ha de ejecutarlo de una cierta forma o de otra forma.
Es la combinación perfecta para OEMS o integradores que quieren asegurarse al 100% de que su propiedad intelectual (en forma de código de PAC) solo se ejecuta en los PAC que tengan presenten un certificado de seguridad concreto. En caso de que su código sea usado de forma no autorizada (sin certificado de seguridad), el propio código reacciona con variaciones en su ejecución que puede llevar a la máquina a producir más despacio, pararse o simplemente informar de la perdida de los certificados. La reacción del código, ante la pérdida del certificado de seguridad, la decide el programador antes hacer la encriptación. Otro valor añadido obtenido mediante la protección a
ejecución de los códigos en un sistema basado en certificados, es que lo certificados se pueden obtener (los entrega el librarian) por una red no segura y además pueden ser certificados temporales que limitan el uso del código.
PAC Bróker de Alarmas Industriales
Cuando desarrollamos una aplicación para un PAC, que controlará una máquina/proceso, debemos tener en cuenta y planificar muy detalladamente el comportamiento del sistema ante las alarmas. Un buen planteamiento de las alarmas y de como el PAC ha de reaccionar ante ellas, distingue muchas veces entre un buen programa de un mal programa. No hay nada más frustrante para un operador, que tener una máquina parada sin saber qué acciones tomar, porque la interface de usuario no indica correctamente la situación real.
El planteamiento clásico respecto a las alarmas es el de cliente/ servidor. El servidor es el PAC que contiene las variables y que contesta a las peticiones de los clientes HMI (Human Machine Interface) sobre el valor de estas variables. Normalmente hay un HMI que está consultando de forma continua centenares o miles de variables en el PAC, con una frecuencia predeterminada, para decidir bajo una lógica implementada en el HMI cuando mostrar o no una alarma (y sus estados posibles estados como: activa, no activa, reconocida, no reconocida, silenciada, etc… ) y marcar estos estados con una fecha/ hora recogida de su reloj interno. Por otro lado, tenemos el PAC que ha de evaluar las mismas variables para garantizar la integridad de la máquina/proceso. Human Machine Interface (HMI): La interfaz de usuario es el medio con que el usuario puede comunicarse con una máquina, equipo, computadora o dispositivo, y comprende todos los puntos de contacto entre el usuario y el equipo.
La aproximación clásica de cliente/servidor aplicada a las alarmas tiene varias desventajas:
Se requiere programación en el PAC y en el software del HMI. Las variables se deben duplicar en el software HMI y mapeadas al PAC correspondiente (lo cual da origen a múltiples errores).
Añadir o modificar una alarma requiere de reprogramar dos sistemas diferentes (PAC y HMI).
Estados de alarma de muy corta duración (algunos milisegundos) se han de capturar en el PAC.
Las alarmas son detectadas por duplicado, primero en el PAC y luego en el software del HMI.
La consulta continua por parte del HMI incrementa la carga de la red.
La determinación del momento de disparo de la alarma depende de la hora del equipo donde este el HMI ejecutándose y por tanto añade la demora dependiente de la frecuencia de las comunicaciones.
La discriminación de tiempo entre dos alarmas depende del ciclo de consulta.
Si existen varios HMI en diferentes equipos, no hay sincronización en la hora de la alarma y dificulta sincronizar los reconocimientos de las alarmas ya que residen en diferentes lugares.
Y por último, si cae el ordenador que ejecuta el HMI o hay una discontinuidad en la comunicación, las alarmas se pierden…
Este elevado número de desventajas y la creciente simbiosis con el IIOT ha creado la base para evolucionar el modelo clásico cliente/servidor al modelo publicación/suscripción
El modelo publicación/subscripción, se basa en que la información se ha de publicar cuando es relevante y tiene que ser enviada a los suscriptores que están esperando las actualizaciones. Para coordinar estas funciones, suele ser común el uso de “brókers” que son los encargados de mantener los temas que los publicadores ofrecen y de controlar que subscriptores hay para cada tema.
¿Pero cómo encaja un modelo publicación/subscripción en la gestión de alarmas de una máquina/proceso?
La idea básica es que los equipos HMI (ya sean pantallas dedicadas, SCADAS, Bases de Datos, etc..) que necesitan conocer las alarmas se subscriben a los temas (dígase alarmas o grupos de alarmas) que los PAC publican.
La visión que tiene Rockwell Automation de este modelo se basa en la implementación del publicador y del bróker en el mismo equipo PAC (CPU Logix). Al tener integrado en una pieza industrial tanto al publicador como al bróker, permite que existan varias subscripciones enlazadas con el PAC y que trabajen todas ellas coordinadas. El reconocimiento de alarmas, silenciado, entre otros, está gestionado por el PAC (publicador y bróker) y, por tanto, se mantiene la congruencia de los datos que muestran los dife-
rentes HMI’S de la instalación. Otra ventaja de tener el bróker integrado en PAC es que en caso de discontinuidad en las comunicaciones (o de parte de las comunicaciones), el bróker mantiene la información a la espera de ser entregada a los suscriptores aunque hayan estado fuera de servicio temporalmente.
Podemos poner como ejemplo, una máquina sencilla con dos paneles de operador. Las alarmas que muestran son exactamente iguales incluso si un panel se ha desconectado por temas de mantenimiento. Por supuesto, las alarmas que han sido reconocidas en un panel, aparecen como tales en los dos paneles ya que el bróker distribuye la información a todos los subscriptores incluso si han dejado de comunicar temporalmente.
En instalaciones más complejas, tendremos la necesidad de hacer llegar estas alarmas a múltiples softwares que se pueden estar ejecutando en varios ordenadores, dígase múltiples clientes de un SCADA para ver y operar las alarmas, historiadores para guardar las alarmas en base de datos, representaciones graficas donde relacionar valores analógicos históricos con las alarmas, entre otros. Como vemos, este creciente número de subscriptores (y por tanto de memoria necesaria en el bróker) puede hacer que el PAC pierda rendimiento en sus otras comunicaciones Ethernet.
Para controlar esta situación dónde un número creciente de subscriptores (que pueden llegar a ser de cientos de clientes del SCADA) quieren acceder a la información, se adopta el mecanismo de añadir un bróker en forma de software que gestione todos estos otros subscriptores. Este segundo bróker puede ayudar a segregar redes en caso necesario y también se puede instalar de forma redundante en dos ordenadores para aumentar su disponibilidad.
En el caso de Rockwell Automation, este segundo bróker se llama Factorytalk Alarms&events. Este software que necesita del soporte de un ordenador y que (muy importante) soporta de forma nativa una configuración redundante, hace de bróker de los suscriptores Factorytalk View SE (SCADA distribuido), Factorytalk Historian (Historizador), Ftlinx Gateway (Servidor OPC UA), etc.
Con este modelo de comunicación obtenemos los siguientes beneficios:
La detección de las alarmas solo se programa una vez en el PAC.
Las condiciones de las alarma se detectan más rápidamente.
Alarmas en tiempo real se ejecutan en el PAC.
Los textos asociados a las alarmas solo se programan una vez en el PAC.
Los textos asociados a las alarmas pueden realizarse en los diferentes idiomas que se requieran.
Se elimina la duplicación de variables en los diferentes HMI’S (Paneles o SCADAS)
Se reduce la carga de la red al no existir un flujo de miles de variables que supervisar.
Los estados de las alarmas se gestionan en el PAC
La fecha/hora se añade en el PAC siendo más precisa la discriminación entre alarmas.
La desconexión temporal de un subscriptor no afecta a los otros subscriptores al disponer el bróker de una memoria-buffer independiente por cada subscriptor.
Por todas estas razones, esta metodología de funcionamiento se está abriendo paso entre los PAC’S de más alto nivel.
CONCLUSIONES Los PACS son el celebro de las máquinas más modernas y no dejan de mejorar sus prestaciones en aspectos cada vez vinculados a la filosofía del IIOT. La capacidad que tienen para conectarse a redes Ethernet ya sean participando en la estructura de anillo o de una arquitectura compleja PRP, tener la capacidad de trabajar con códigos encriptados que garanticen la propiedad intelectual o el poder trabajar en modelos de comunicación publicación/subscripción los convierten en el compañero perfecto para implementar el IIOT en las fábricas.
REFERENCIAS CISCO –ROCKWELL AUTOMATION (Mayo 2014). “Deploying the Resilient Ethernet Protocol (REP) in a Converged Plantwide Ethernet System (CPWE) Design Guide” CISCO –ROCKWELL AUTOMATION (Febrero 2018). “Deploying a Resilient Converged Plantwide Ethernet Architecture” ROCKWELL AUTOMATION (Agosto 2018). “Ethernet/ip Parallel Redundancy Protocol” ROCKWELL AUTOMATION (Noviembre 2015). “Ethernet/ip Secure Communication” Daniel Benítez Ingeniero Comercial de Arquitecturas Integradas Rockwell Automation Iberia