Recuerdos dolorosos de simulaciones de PLC

Esta declaración voluminosa de una disertación del Sr. Roland Schulz de 2002 lo resume bastante bien en general.

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

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

En el pasado, como joven empleado en Phoenix Contact, también tuve que aprender a programar y me hubiera encantado una simulación del controlador. Simplemente para saber más sobre el funcionamiento y función de los bloques o programas por "prueba y error". Desafortunadamente, no existía en ese momento y la simulación de PLC que siguió fue muy limitada. El código IEC61131-3 se podía simular bien, pero carecía del soporte de dispositivos especiales o simplemente del diferente comportamiento del código entre los sistemas basados ​​en Intel y 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 dispusimos a encontrar realmente algo con valor agregado sin crear grandes esfuerzos. Esfuerzos por un lado en el desarrollo de una simulación y esfuerzos que pudieran surgir posteriormente en el uso de la misma.

Como usuario, quiero poder enviar mi proyecto a un PLC oa una simulación, en el mejor de los casos con un clic del mouse. No quiero prestar atención a las arquitecturas de los procesadores, y ciertamente no quiero verme 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 usar 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 están basados ​​en Linux. Pero es importante para el desarrollo del código que aquí también se utilicen diferentes arquitecturas de procesador.

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

¿Qué salió de esos pensamientos?

Encontramos la emulación del 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 estábamos buscando.

"Solo" ejecute el firmware en él y QEMU emula el sistema Linux completo de PLCnext Technology, incluida la arquitectura del procesador ARM de algunos controladores PLCnext, y nació la simulación PLCnext. Es cierto que 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, todas las características especiales de PLCnext Technology podrían conservarse. Así que también puedo enviar mis programas y componentes C/C++, C# o Matlab Simulink a la simulación. También las aplicaciones, que puedo encontrar para ciertas aplicaciones en la tienda, se pueden llevar a la ejecución.

Algunas limitaciones adicionales son obvias:no se espera determinismo de un sistema simulado de este tipo. Y dependiendo de la carga de mi sistema Windows, puede haber uno u otro perro guardián en la simulación de PLCnext. Pero en tales casos, siempre puedo dar al proceso de simulación una mayor prioridad en el sistema de Windows y luego los errores de vigilancia se resuelven rápidamente.

Y ahora finalmente lo tengo, una simulación, o tal vez incluso dependiendo de la definición, una emulación de mi controlador. Pero desafortunadamente tuve que aprender a programar sin él, y ahora ya no programo tanto.