Archivo de la categoría: Automatización

Robots, pero no .txt…

Posted on por
Anuncios

Cuando nos referimos a los entornos industriales generalmente lo hacemos con la vista puesta en PLCs, HMIs, sistemas SCADA, sensores, actuadores, etc. Si embargo, hay otros que también están presentes y que a veces pasan desapercibidos. Los robots.

Éstos son capaces no sólo de llevar a cabo tareas repetitivas de forma rápida y precisa , sino reemplazar la labor de una persona, tanto por capacidad como por ahorro en tiempo y dinero. Un tema este que desde hace tiempo está siendo objeto de debates ya que muchos puestos de trabajo podrían peligrar si no se regulariza su uso a corto plazo. Esto cobra más fuerza si tenemos en cuenta los avances tecnológicos que han derivado en lo que conocemos como «Robótica Colaborativa». Brazos robotizados capaces, no sólo de imitar la labor de operadores tradicionales, sino la de trabajar junto a ellos garantizándose, por supuesto, medidas de seguridad necesarias para prevenir cualquier daño.

Este vídeo habla por si mismo:

Sin embargo en el día de hoy no me voy a centrar en este tipo de robots sino en otros de mayor tamaño presentes en sectores como la industria manufacturera, logística o más concretamente, la automoción. De un tiempo a esta parte se viene hablando que, al igual que otros dispositivos, los robots pueden ser blanco de ataques con unas u otras consecuencias dependiendo de las vulnerabilidades y debilidades que puedan presentar.

En el día de hoy haremos un repaso por sus componentes principales para entender mejor qué partes podrían verse afectadas llegado el caso.

Como decía, de forma genérica, un robot de estas características está compuesto por:

1.- Brazo robótico

Es el componente más visible. A él le asociamos la palabra «Robot» y al que podríamos definir como un manipulador multipropósito reprogramable capaz de mover piezas, materiales y herramientas en diversas trayectorias. Controlado automáticamente, podrá estar compuesto por 3 o más ejes que permiten llevar a cabo los distintos movimientos con el fin de realizar una o varias tareas concretas. En sus extremos podrán disponer de herramientas intercambiables como pinzas, agarres, sensores o cualquier otro tipo según necesidades.

2.- Controlador:

Es dispositivo que gobierna al robot. En él podemos identificar dos subsistemas denominados «módulos» que se encargarán de actuar sobre distintas áreas del mismo. Dependiendo de fabricantes y modelos, esto puede cambiar en cuanto a formatos o arquitecturas, pero en general podremos encontrarnos con:

  • Módulos de Potencia

Encargado de regular la alimentación eléctrica que necesitan tanto el resto de módulos como los servos que mueven los ejes y hacen desplazar al robot por las trayectorias y puntos definidos. Contará con un interruptor principal y otros accionamientos, que estarán en comunicación con los sistemas de seguridad y maniobra para, en caso necesario, suspender el suministro.

  • Módulo de Control

Contará con el computador principal que gobernará el sistema. En él podremos localizar distintos elementos como el mecanismo de paro de emergencia, selector de modo de operación (Manual/Automático), conexiones con otros módulos, leds de estado, etc. También será capaz de gestionar las seguridad en lo que a «Safety» se refiere, recibiendo las señales de sensores o mecanismos que permitirá el paro del robot en caso de error o accidente. Dispondrá de interfaces de entrada y salida de tal manera que los técnicos o ingenieros puedan llevar a cabo la carga de la configuración y parametrización así como otros elementos tipo PLCs, HMIs, vinculados a procesos.

3.- Consola Hombre-Máquina:

Es una unidad conectada al módulo de control con el que se podrá operar el robot. Se trata de pequeñas consolas dotadas con una pantalla, teclado, joystick y accionador de emergencia con el fin de manipular y ajustar parámetros en el brazo robótico de forma manual. Por esta razón, y con el fin de evitar accidentes contra personas,  cuentan con sistemas que obligan, por ejemplo,  a tener presionados simultáneamente dos pulsadores para poder manipularlo. Están dotados de sistemas operativos embebidos, como Windows CE .NET en el caso del fabricante  ABB para su componente Flexpendant. Esto permite la programación «online» a diferencia como veremos más adelante de otra «offline».

Consola de Robot

4.- Programación:

Como resulta evidente al robot hay que parametrizarlo y configurarlo para que realice los movimientos y tareas para los que ha sido pensado. Si bien desde la consola manual pueden llevarse a cabo ciertas tareas, a ésta se le reservan más a la precisión o corrección. El resto de labores se editarán en software destinado a tal efecto como puede ser KUKA.WorkVisual del fabricante KUKA, o RobotStudio en ABB.

Desde este software se llevará a cabo lo relativo a la parametrización de los programas que se ejecuten en el robot, movimientos, coordenadas, estados, etc. para luego desde ahí volcarlo al Controlador por alguna de sus interfaces. Estas tareas podrán hacerse, como hemos visto, tanto de forma «online» y «offline» para que cada programador u operador emplee según necesidades.

Sin embargo, los robots no están solos. Éstos se integran con otros dispositivos como son los autómatas. Los casos de uso a los que me he enfrentado hasta la fecha, han sido en los que un PLC ve a un robot como un «esclavo». Es decir, el autómata ordenará al controlador del robot la ejecución de tal o cual programa según sea necesario. Finalizado, retroinformará para proseguir con las tareas tanto de forma autónoma como de forma conjunta con otros. Obviamente esto no es sencillo ya que entran en juego multitud de señales y medidas, como pueden ser las enviadas por los sensores; detectores de posición; finalización de trabajo antes de comenzar movimientos en otros robots; petición de acceso a una determinada área; respetar tiempos de espera, etc. Pero sobre todo, la implementación de medidas «Safety» y evitar así los temidos accidentes. Según sea el modelo de autómata empleado, éstos podrán incluir estas funcionalidades en sus CPUs o sino depender de otros dedicados a tal efecto. Aparte de estos mecanismos como pulsadores de emergencia, sensórica, barreras de protección, o perímetros restringidos, el propio robot permite que en modo de operación manual puedan establecerse límites y supervisión  en cuanto a velocidad y movimientos. Finalmente para que todo esta interacción sea posible es necesario el uso de buses de campo que permitan la comunicación entre los distintos elementos.

Con la entrada de hoy se pretende arrojar un poco más de información sobre qué elementos componen estos sistemas y la manera en que se comportan. Especialmente cuando no hace demasiado tiempo la firma TrendMicro ha publicado un informe sobre los posibles ataques a los que pueden estar expuestos los robots y las consecuencias que pueden tener, tanto para el proceso como a las personas.

En cualquier caso, espero que en la entrada del día de hoy pueda servir para entender  de forma sencilla algo más sobre estos equipos.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta

MRP, Media Redundancy Protocol

Posted on por
Anuncios

Como avanzaba en la entrada “Redundancia en entornos ICS/SCADA” hoy comenzaremos a hablar de aquellos mecanismos que dotan a nuestras redes industriales de una resiliencia mayor. La tendencia de los protocolos empleados en este tipo de entornos es evolucionar hacia tecnología Ethernet en lugar de la tradicional serie. Sin embargo, su propia naturaleza, no permite la creación de bucles en la red ya que el tráfico “Broadcast” podría no sólo ralentizar las comunicaciones, sino bloquearlas. Ante la necesidad de entornos que requieren alta disponibilidad, hemos configurar protocolos que “rompan” esos bucles dejando un solo camino posible para la comunicación entre equipos. En caso de producirse un fallo, dicho protocolo será capaz de detectarlo y desencadenar las medidas necesarias para que todo el tráfico comience a ir por una vía alternativa. En entornos IT, el más conocido es Spanning Tree Protocol (STP) así como sus respectivas versiones RSTP, MSTP o PVSTP. Sin embargo, los tiempos que maneja para poder restaurar las comunicaciones son muy altos para los requerimientos de los sistemas de control y automatización, siendo necesario emplear otros que iremos viendo en esta y entradas sucesivas.

El primero de ellos es MRP (Media Redundancy Protocol). Este protocolo está descrito en el estándar IEC 62439-2, el cual es ampliamente utilizado en redes industriales para entornos de alta disponibilidad. MRP opera en Capa 2 y es específico para redes en anillo con hasta 50 equipos, garantizando un comportamiento determinístico en caso necesidad de cambio de un estado a otro. Para ello, define una serie de tiempos máximos para recuperar las comunicaciones según sea la configuración elegida. Éstos pueden ser 500 ms, 200 ms, 30 ms y 10 ms. Como hemos dicho estos son valores máximos, por lo que los tiempos reales oscilan entre la mitad y un cuarto de los mismos. Esto es, si configuramos nuestros equipos con un valor de 200 ms, el tiempo aproximado del cambio entre una ruta a otra de los paquetes podrá rondar entre 50 y 60 ms, aproximadamente.

Como vemos en la imagen anterior, MRP necesita que cada nodo disponga de dos enlaces en el anillo. Dentro de la topología, uno de ellos será elegido MRM (Media Redundancy Manager), el cual   monitoriza y controla,  reaccionando en caso de fallo. Esto lo consigue enviando tramas de control desde cada uno de los puertos, recibiéndolas en el otro extremo.  A pesar de que uno de ellos permanezca “Bloqueado”.

El resto de elementos del anillo reciben el nombre de MRC (Media Redundancy Client). Cada MRC retransmite las tramas de control enviadas por el MRM de un puerto a otro de tal manera que éste pueda detectar el fallo y activar el puerto en “Bloqueado”.

MRP define 3 tipos de tramas de control:

  1. Para monitorizar el estado de anillo. MRM envía regularmente tramas de prueba en ambos puertos que le conectan al anillo.
  2. Cuando el MRM detecta un fallo o recuperación de los enlaces, envía tramas de cambio de topología (“TopoChange”) en ambos puertos de lanillo.
  3. Cuando un MRC detecta un fallo o recuperación en un puerto, local envía tramas de cambio de enlace (“LinkChange”) al MRM. Éstas se consideran como un subtipo de otras denominadas “Linkdown y “Linkup”.

En un funcionamiento normal, “Anillo Cerrado”, el MRM bloqueará todo el tráfico a excepción de estas tramas, por lo que a efectos prácticos el anillo se comporta como si fuera un único enlace. Esto es, no existe ningún bucle.

Cuando el MRM deja de recibir dichas tramas en el otro extremo, interpreta que el enlace se ha roto en algún punto,  “Anillo Abierto”, por lo que ese puerto que estaba en “Bloqueado”, ahora comienza a enviar tramas de forma normal.

A esto hay que sumar que los MRC son capaces de informar de cambios de estado en alguno de los enlaces. Si esto se produjese, el MRC envía una trama de control al MRM informando de ello. Si éste la recibe antes de detectar que se ha producido un cambio en el anillo, toma la información contenida en ella para activar el enlace “Bloqueado” y así recuperar la conectividad en el menor tiempo posible. De ahí que, aunque se fijen tiempos máximos, siempre cabe la posibilidad de que el anillo pueda seguir enviando tráfico por debajo de estos umbrales.

Tanto el MRM como el MRC definen una serie de “estados” para sus puertos dentro de la topología.

  1. Disabled, los puertos descartan todas las tramas recibidas.
  1. Blocked, los puertos descartan todas las tramas excepto las tramas de control MRP y algunas otras de protocolos como LLDP.
  1. Forwarding, los puertos reenvían todas las tramas recibidas.
  1. Not Connected, el enlace está físicamente caído o desconectado.

En otro orden, en el caso concreto de PROFINET, MRP puede ser implementado sobre los dispositivos finales sin necesidad de equipos adicionales gracias a la definición de una aplicación concreta como es PROFINET/MRP.

Por último conviene citar las funcionalidades que cada fabricante otorga a sus productos dependiendo de modelos y licenciamiento. Algunos de ellos pueden ser; posibilidad de integración con software de gestión como Siemens Total Integrated Automation (TIA); definición de varios anillos MRP por una misma VLAN; interperabilidad con Spanning Tree Protocol; etc.

No debemos olvidar tampoco de las limitaciones y recomendaciones que cada uno hace a la hora de configurar los equipos. Por ejemplo, Cisco nos habla de que los puertos MRP no pueden ser configurados como puertos SPAN, Private VLAN o Tunnel y, si además la implementación es sobre Profinet, como Trunk; ser configurado en puertos Etherchannel; etc.

Lo dicho, hablar de resiliencia no es sólo hablar de la securización, es tener además la capacidad de recuperarse del elemento que provoca una determinada perturbación. Hoy en día con la cantidad de amenazas que acechan a los Sistemas de Control  Industrial resulta necesario no sólo desplegar medidas técnicas sino además definir arquitecturas que hagan frente a cambios o anomalías inesperadas. Los accidentes ocurren, una fibra óptica rota; un SFP, defectuoso; una configuración accidental de un puerto, o cualquier otra razón,  bien puede desencadenar una alteración en las comunicaciones y por tanto un impacto en el proceso. Esto no quita que debamos hablar de otros riesgos como el “Sabotaje”, “Inyección de tráfico”, “Intrusión”, y que obligen implementar otras medidas como el “Hardening de Sistemas”, “Monitorización”, “Control de Accesos”, entre otras paliando así estas amenazas.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Hasta pronto!