Aprendiendo de los desafíos de simulación PLC: Guía práctica

Esta contundente afirmación de una tesis del Sr. Roland Schulz de 2002 resume bastante bien la situación en general.

En resumen: "Intentar y probar ayuda a encontrar errores".

No estoy escribiendo aquí sobre la simulación de plantas de producción completas, sino que desgloso el principio a unidades individuales (componentes), como programas de automatización o proyectos de usuario.

En el pasado, como joven empleado de Phoenix Contact, también tuve que aprender programación y habría estado encantado con una simulación del controlador. Simplemente para descubrir más sobre el funcionamiento y función de los bloques o programas mediante "prueba y error". Desafortunadamente, no existía en ese momento y la simulación PLC que siguió era muy limitada. El código IEC61131-3 se podía simular bien, pero faltaba el soporte de dispositivos especiales o simplemente el diferente comportamiento del código entre sistemas basados en Intel, ARM o Motorola.

Con estos pensamientos en mente y los recuerdos del dolor que tuvimos con la simulación "clásica" de un PLC, nos propusimos encontrar realmente algo con valor añadido sin crear enormes esfuerzos. Esfuerzos por un lado en el desarrollo de una simulación y esfuerzos que podrían surgir más tarde en su uso.

Como usuario, quiero poder enviar mi proyecto a un PLC o a una simulación, preferiblemente con un clic de ratón. No quiero prestar atención a las arquitecturas de procesador, y ciertamente no quiero verse obligado a ocultar o, peor aún, eliminar funciones en mi código que no son compatibles con la simulación.

¿Qué podría ser más obvio que utilizar el firmware real en la simulación, que también se usa en el hardware de control real? Y eso es exactamente lo que sucedió.

Hoy en día existen emulaciones de sistema completas que no solo permiten ejecutar varios sistemas operativos bajo Windows. También permiten la emulación de varias arquitecturas de procesador y sus características.

No es un secreto que nuestros controladores se basan en Linux. Pero es importante para el desarrollo de código que aquí también se utilicen diferentes arquitecturas de procesador.

En la ingeniería, en nuestro caso PLCnext Engineer, el cliente debería poder elegir entre la dirección IP del controlador o la simulación - con un clic de ratón sin preocuparse por más adaptaciones de código o compatibilidad de código binario.

¿Qué surgió de esos pensamientos?

Encontramos la emulación de sistema QEMU y la usamos para simular nuestros controladores. QEMU es una "emulación de máquina de código abierto" y ofrece exactamente lo que buscábamos.

Simplemente ejecutar el firmware en él y QEMU emula el sistema Linux completo de PLCnext Technology, incluyendo la arquitectura de procesador ARM de algunos controladores PLCnext - y nació la simulación PLCnext. Admitidamente, incluimos algunas limitaciones menores. La comunicación PROFINET u otros protocolos de comunicación están deshabilitados. Pero el servidor OPC UA, por ejemplo, no se ve afectado.

Sin embargo, se pudieron preservar todas las características especiales de PLCnext Technology. Así que también puedo enviar mis programas y componentes en C/C++, C# o Matlab Simulink a la simulación. También las APPs, que puedo encontrar para ciertas aplicaciones en la Store, pueden llevarse a la ejecución.

Algunas limitaciones adicionales son obvias: no se puede esperar determinismo de un sistema simulado así. Y dependiendo de la carga de mi sistema Windows, puede haber uno u otro watchdog en la simulación PLCnext. Pero en esos casos siempre puedo dar a la simulación una prioridad más alta en el sistema Windows y los errores de watchdog se resuelven rápidamente.

Ahora finalmente la tengo, una simulación, o tal vez incluso, dependiendo de la definición, una emulación de mi controlador. Pero desafortunadamente tuve que aprender programación sin ella, y ahora ya no programo tanto.