Novedades 20150726

Heather MacKenzie, de Hirschmann, se pregunta cómo será la automatización industrial en en futuro (1 y 2). Su visión pasa por la fabricación inteligente, el peso y estructura de las comunicaciones en el nuevo modelo, y los retos y posibilidades que conllevan.
La automatización de los procesos por lotes es más compleja que para los continuos. Greg McMillan hace un recuento de motivos, de entre los que quiero resaltar el primero: se pueden concebir como estar arrancando y parando perpétuamente.
Algo que aprendí en Cosentino fue la ventaja estratégica que proporciona una buena comunicación entre las redes de fábrica y de negocio, los dos niveles superiores del modelo CIM, que tradicionalmente se han mantenido aislados por un mal entendido concepto de seguridad. Edmunds, Voss y Whitehead plantean varios aspectos clave en esta integración: por supuesto la seguridad, pero también la movilidad que ofrece, el acceso remoto, la computación en la nube, el uso del vídeo o la gestión energética.
Hubertus Breuer, de Siemens, nos habla de la importancia de los datos, la más valiosa “materia bruta”. Para ello, presenta varios ejemplos de uso de la información digital: el metro de Riyadh, con trenes sin conductor que operan con intervalos de 90 segundos, los sensores de turbinas de gas o el software PLM, de gestión del ciclo de vida del producto.
InfoPLC ha publicado esta semana dos tutoriales eminentemente prácticos elaborados por José M. Hurtado, que imparte en el ciclo de Automatización y Robótica Industrial del I.E.S. Himilce. El primero, sobre redes Profibus. El segundo, para quien quiera formarse en la programación de Step 7.
Hablando de formación, la empresa chilena Arian ha elaborado unas breves notas técnicas con fines educativos sobre sensores de temperatura y lazos PID. Aviso: en España nos pueden resultar extraños algunos términos (termocuplas por termopares, por ejemplo).
Y para terminar, diez consejos de la NASA para escribir código crítico. Están los clásicos (control de flujo), los esperados (no usar memoria dinámica, ámbitos reducidos) y los llamativos (las funciones deben caber en una cara de papel y contener al menos dos aserciones).

Enviar datos con Arduino vía Ethernet

publicado en: Arduino | 2

Con Arduino tenía una cuenta pendiente. Me ha llegado por fin la placa y he podido hacer unas pruebas. Para iniciarme con un enfoque útil, he pensado desarrollar un programa que envíe los datos a un servidor web. La idea no es original: me la comentó mi compañero Ginés, y hay un puñado de ejemplos en Internet. A pesar de ello, es un ejercicio interesante para comenzar, y quiero orientarlo a un objetivo más general. Por eso, voy a introducir algunos elementos innecesarios en este primer desarrollo, pero que cumplirán una función más adelante. Manos a la obra.
Material con el que parto:

  • Placa Arduino Mega 2560
  • Arduino Ethernet Shield W5100

Más, como es obvio, tensión de 9V, cable USB y Ethernet. También cuento con un PC con PHP instalado y configurado.

Arduino Mega 2560
Arduino Mega 2560

En primer lugar hay que incluir en el código las librerías necesarias e introducir cierta información acerca de la conexión Ethernet:

La dirección MAC es inventada. Podemos elegir los seis bytes que queramos, siempre que no coincidan con los de otra MAC en la red. Además, debería corresponder a una dirección localmente administrada. Estas direcciones se caracterizan por tener activo el segundo bit (que se envía; corresponde con el segundo menos significativo del byte más significativo). Es decir, el primer byte es de la forma 2+4n o 3+4n.
La primera IP que aparece corresponde a la del PC que actua como servidor; y la segunda, la que le asigno al Arduino, que debe estar disponible en la red.
No debo olvidarme de comentar las librerías incluidas. SPI y Ethernet se requieren para las funciones de red y se instalan con el software de Arduino. La primera que se ha colado, en cambio, corresponde a la librería ArduinoJSON, que desarrolla Benoît Blanchon. JSON va a servir para codificar y decodificar información en forma de texto. De momento sólo voy a trabajar con entradas y salidas, y las recogeré en un array de objetos:

Cada objeto del array representa un canal, al que damos un nombre (id), un tipo (de momento sólo entradas digitales, “di”), una dirección y un valor inicial. En principio parece mucho aparato para enviar dos bits, pero espero darle justificación en publicaciones sucesivas. Estas dos entradas quedarían representadas en JSON de la siguiente forma:

Terminemos la función setup, que ha quedado a medias. Falta inicializar la periferia y la interfaz Ethernet:

El ciclo del programa va a ejecutar una tarea sencilla: actualiza los valores de root y los envía al servidor web. Para lo primero sólo hay que repasar el array buscando aquellos elementos que sean de tipo di (entrada digital). Se consulta si la entrada con dicha dirección está activa, y se actualiza su valor:

Queda la segunda parte, que es el envío. Lo voy a hacer con el método GET, por simplicidad. Para ello, basta pedir una URL incluyendo en ella el parámetro que se desea mandar. Por ejemplo, para adjuntar la cadena JSON que hemos mostrado antes sólo tendríamos que pedir la página:

La petición se va a llevar a cabo periódicamente, cada dos segundos si no hay fallos. En primera instancia se realiza la conexión con el servidor y, una vez se esté conectado, se solicita la URL anterior:

Falta una parte, la otra mitad: qué hace el servidor con los datos. De momento, puesto que esto es un ejercicio, le vamos a dar una salida simple almacenándolos en un fichero sin ningún tratamiento previo. El código en PHP es el siguiente:

Listo. A los pocos segundos de descargar el programa a la placa Arduino tenemos un fichero data.txt que va engrosando ininterrumpidamente. Y alimentando cualquiera de las dos entradas, podemos comprobar cómo su valor queda registrado.

Hackeando un Moeller Easy 512

publicado en: Klockner Moeller, Seguridad | 2

Situación: se necesita extraer el programa de un controlador Klockner Moeller Easy 512, pero está protegido por contraseña. La empresa canadiense que lo instaló cerró hace años y no hay otro modo de obtener el software. Personalmente no hubiese intentado hacer lo que a continuación voy a describir, porque leí en el manual que, al tercer intento fallido, el programa se borra (y se vuelve a conceder acceso). Pero no es así: quien me lo trae ha estado probando contraseñas al azar y sigue sin poder iniciar sesión. En cualquier caso, advierto: si alguien repite esto, posiblemente con un PLC con otra configuración, puede perder el programa.
Easy512
Ya en general, la seguridad en automática no ha sido nunca una cualidad destacable. Al contrario, los sistemas de control se han concebido tradicionalmente como cerrados y de acceso exclusivamente físico por personal de confianza. Es un error lamentable. Por todo el mundo hay repartida una cantidad apabullante de instalaciones desprotegidas. No quiero ser alarmista, pero se trata de una asignatura pendiente que no se debería postergar.
Retomemos el Klockner Moeller. El software de programación, EasySoft, lo primero que pide al establecer la conexión es la contraseña. Y ante fallo desconecta y no admite otra acción. Hasta aquí, poco que objetar, no hay que olvidar que hablamos de un PLC de baja gama. Lo que lo hace tan vulnerable es la limitación sobre la contraseña: cuatro caracteres numéricos. Es decir, que en pocos minutos va a caer ante un ataque de fuerza bruta.
Una opción interesante sería suplantar directamente a la aplicación (la comunicación se realiza por el puerto serie) y lanzarle intentos. Pero no disponía de mucho tiempo, así que me decanté por una alternativa que, por otra parte, puede repetirse en otros contextos, razón por la que me he animado a publicarla. Se trata de mandar pulsaciones de teclas directamente al desplegable que solicita la contraseña.
Para ello, me instalé el programa AutoHotkey. No sé si es bueno, es el primero que encontré buscando en Google. Lo que sí puedo decir es que tiene una sintaxis algo retorcida. Los script se crean con cualquier editor de texto, se graban con la extensión .ahk y están listos para ejecutar. Asigné la combinación CTRL+h para iniciar el envío de pulsaciones del teclado, y la tecla ESC para detenerlas. Manda, como he comentado, todas las contraseñas desde 0000 hasta 9999 acompañadas de dos pulsaciones de ENTER (una para el cuadro de diálogo de la contraseña y la segunda para aceptar el mensaje de error). El código es el siguiente:

^h:: ; La ejecución del scrip se inicia con CTRL+h

;=== Se prueban contraseñas desde 0000 hasta 9999
i=0
Loop, 10000
{
   v:=Format("{:04}",i)   ; Se le da formato de cuatro cifras

   Send, %v%{enter}{enter}   ; Se mandan las cuatro cifras seguidas de dos ENTER
   Sleep, 400 ; Pausa
   i++

   ;=== Para salir, pulsar la tecla ESC
   GetKeyState, state, Esc
   if state = D
   Exit
}

Es muy mejorable. Posiblemente se pueda reducir el tiempo de pausa, por ejemplo. Pero sirve con el Moeller. Basta intentar conectarse, pulsar CTRH+h cuando pide la contraseña, y dejarlo correr. Una vez que acierta, la conexión se mantiene. Se pulsa ESC para detener el envío de teclas y ya es posible guardar la copia del programa.

El paradigma olvidado (1). Lenguajes de PLC

publicado en: Controladores, FBD, IL, LD, Lenguajes, PLC, SFC, Siemens, ST | 0

Cuando empecé a programar autómatas, hace quince años, los lenguajes estaban muy limitados en cuanto a operaciones. Un S5-90 de Siemens, por ejemplo, sólo tenía dos operaciones aritméticas: suma y resta. Para multiplicar y dividir había que recurrir a bloques de función. Ni hablar de trigonométricas, búsquedas en tablas o manejo de cadenas. Todo eso vendría después. Recuerdo un Hitachi antiguo que sólo disponía de contactos, bobinas, un tipo de temporizador y un contador. Algunos de estos controladores disponían de más de un tipo de lenguaje de los recogidos en el estándar IEC61131-3:

  • Lista de instrucciones (IL).
  • Diagrama de bloque de funciones (FBD).
  • Ladder o escalera (LD).

En el caso que comentaba del S5 de Siemens, se llamaban AWL, FUP y KOP respectivamente. El primero de ellos sería identificado por cualquier programador como lenguaje ensamblador, ya que está formado por un listado de operaciones básicas de movimiento de registros, operaciones con aculumadores, etc. La programación se hace a nivel de máquina. Un ejemplo podría ser el siguiente:
AWL
Los bloques de funciones se identifican con una programación gráfica, al estilo Lawview, que no abunda en ámbitos distintos de la automática. En todo caso, se puede asimilar a las puertas booleanas que se manejan en electrónica.
FUP
El tercer lenguaje que he mencionado, el ladder, se desarrolló con la mira puesta en eléctricos que se introducían en la programación. Sus componentes principales son pues contactos y bobinas.
KOP
El estándar menciona más lenguajes, que yo no vería sino poco tiemp después:

  • Texto estructurado (ST).
  • Secuencias (SFC).

El texto estructurado es lo más semejante a un típico lenguaje de programación imperativa, tal como C o Basic. A diferencia de la lista de instrucciones, se trabaja a medio nivel, por lo que el desarrollo y mantenimiento es más ágil.

http://web.fe.up.pt/~asousa
Autor: Armando Jorge Sousa

Por último, los bloques de función secuenciales trasladan a los PLC los clásicos diagramas de flujo usados para representar algoritmos. Hay que hacer notar que la programación de acciones y condiciones debe realizarse en otro de los lenguajes expuestos, por lo que el SFC no es en sí completo.
http://szirty.uw.hu
Autor: externet

Esta entrada continúa en El paradigma olvidado (2). Lenguajes de HMI.

1 2 3 4