La vida se mueve en tiempo real: sus sistemas integrados industriales también deben hacerlo
Por Andreas Karlsson – Product Manager de tecnología Fieldbus y cofundador de RT-Labs
Las redes industriales de Fieldbus (Profibus, EtherCAT, etc.) se utilizan ampliamente en las fábricas para transmitir información entre dispositivos de campo como sensores y actuadores y el controlador lógico programable que supervisa el proceso. Hoy en día, los dispositivos Fieldbus son sistemas integrados que incluyen una unidad de microcontrolador (MCU) que gestiona el flujo de datos bidireccional para el dispositivo. Lo hace mediante la ejecución de un programa que se ejecuta en un sistema operativo (SO). Windows, Linux y Android son sistemas operativos de uso general que se utilizan en dispositivos cotidianos como teléfonos inteligentes y computadoras portátiles. Sin embargo, están diseñados para realizar muchas tareas diferentes en situaciones en las que un ligero retraso es casi imperceptible para el usuario y tiene un impacto limitado en el rendimiento del sistema.
Sin embargo, en entornos industriales, incluso los retrasos más pequeños en la ejecución de un programa utilizado para controlar una máquina o un robot (Figura 1) pueden tener resultados catastróficos, lo que significa que se requiere un sistema operativo diferente: un sistema operativo en tiempo real (RTOS). Además, a medida que se delega más autonomía a los dispositivos «periféricos», estos comienzan a realizar tareas como el aprendizaje automático y emplean inteligencia artificial, esto se vuelve cada vez más importante. Este artículo presenta algunos escenarios que demuestran este requisito antes de analizar las diferencias entre el funcionamiento de un sistema operativo de propósito general y un RTOS. Finalmente, ofrecemos un RTOS que es especialmente adecuado para sistemas integrados que utilizan un enfoque innovador basado en software para implementar protocolos Fieldbus.
Donde la demora es intolerable
Los sistemas operativos en tiempo real se diseñaron para dos clases generales de aplicaciones: respuesta a eventos y control de circuito cerrado. Un ejemplo de una aplicación de control de circuito cerrado es una máquina herramienta de control numérico por computadora (CNC) que recibe entradas en tiempo real de sensores que monitorizan la posición de un cabezal de corte. Estas entradas se utilizan luego para determinar dónde colocar el cabezal a continuación para producir el patrón deseado. En esta aplicación, es necesario que el sistema realice continuamente cálculos de trayectoria mientras actualiza la posición del motor a una velocidad de varios KHz. Cualquier retraso entre la entrada y la salida creará un patrón incorrecto que dará como resultado la producción de un producto defectuoso, el desecho de materias primas y la necesidad de repetir el proceso (con los costes y retrasos asociados).
En las líneas de producción donde los humanos interactúan directamente con la maquinaria robótica, los sistemas de seguridad están diseñados para garantizar que si un operador accidentalmente (o de otra manera) entra en contacto no autorizado con una máquina, esta se detendrá de inmediato. Cualquier demora en apagar el equipo podría provocar lesiones graves al operador o consecuencias aún más trágicas. Estos ejemplos ilustran los efectos potenciales del retraso en los sistemas integrados industriales.
Terminología de RTOS
Los RTOS se clasifican como «duros» o «suaves». Un RTOS que garantiza un tiempo de funcionamiento máximo se denomina ‘duro’, lo cual es un requisito en aplicaciones críticas de seguridad. Un RTOS que realiza operaciones dentro de una ventana de tiempo específica (en varios cientos de milisegundos) se denomina ‘suave’ y puede usarse en aplicaciones menos críticas. El determinismo es la característica utilizada para comparar el rendimiento de RTOS: se dice que una aplicación es determinista si se puede garantizar su sincronización (dentro de un cierto margen de error). Jitter se refiere a la cantidad de error en el tiempo necesario para realizar una operación (medido sobre ejecuciones repetidas de un programa o ciclo).
Un RTOS normalmente se optimiza para tener una baja fluctuación cuando se programa correctamente, lo que significa que una operación requiere casi la misma cantidad de tiempo cada vez que se ejecuta. Los sistemas operativos en tiempo real hacen esto al proporcionar a los programadores un alto grado de control sobre la priorización de tareas y la verificación para garantizar que se cumplan los plazos para las operaciones esenciales.
Por qué un sistema operativo de propósito general no está a la altura del trabajo
El problema con el uso de un sistema operativo de propósito general (como Windows) es que no siempre siguen estrictamente las prioridades preprogramadas. Dado que están optimizados para ejecutar varias aplicaciones y procesos simultáneamente, generalmente funcionan para garantizar que todas las tareas reciban al menos algo de tiempo de procesamiento. Como resultado, las tareas de menor prioridad pueden, en algunos casos, aumentar su prioridad sobre otras tareas de mayor prioridad, lo que garantiza que, si bien cada tarea recibe una cierta cantidad de tiempo de ejecución, el programa en ejecución no siempre se sigue con la precisión que debería. Por el contrario, un RTOS siempre se adhiere a las prioridades preprogramadas. Por ejemplo, si una tarea de alta prioridad utiliza el 100% de los recursos de procesamiento disponibles, las tareas de menor prioridad no se pueden ejecutar hasta que se complete la tarea de mayor prioridad. Por lo tanto, los diseñadores de sistemas en tiempo real deben programar cuidadosamente sus aplicaciones teniendo en cuenta las prioridades. En una aplicación típica en tiempo real, los diseñadores colocan código crítico en el tiempo (por ejemplo, respuesta de evento o código de control) en un área a la que se le ha asignado una prioridad muy alta. El código de menor importancia (como el registro de datos o la comunicación de red) se incluye en un área de menor prioridad. La latencia de interrupción se mide como el tiempo que transcurre entre que un dispositivo genera una interrupción (que marca una operación en espera de ser realizada) y cuando recibe servicio.
Si bien un sistema operativo de uso general puede tardar un tiempo variable en responder a una interrupción determinada, la latencia en un RTOS está limitada en el tiempo, es decir, todas las interrupciones se atenderán dentro de un intervalo de tiempo máximo. Por lo tanto, un RTOS procesa los datos a medida que llegan, sin almacenamiento en búfer ni actualización, lo que permite respuestas más rápidas y precisas en sistemas con entornos de entrada cambiantes. Por lo general, un RTOS con una arquitectura de microkernel (kernel se refiere al núcleo) está diseñado para ser pequeño con funciones separadas que no afectan sus operaciones principales.
¿Qué es RT-Kernel RTOS?
A diferencia de un RTOS tradicional, RT-Kernel es un kernel de diseño monolítico integrado seguro, pequeño, eficiente y fiable creado internamente por los ingenieros de RT-Labs para satisfacer las demandas más complejas en tiempo real. El tamaño del kernel depende del tipo de microprocesador y del conjunto de características, pero un kernel RTOS con funciones completas puede ser tan pequeño como 13 kB (ARM, conjunto de instrucciones Thumb). La huella se puede reducir aún más (hasta un mínimo de 6 kB) si no se requieren todos los servicios del kernel RTOS. Los puertos están disponibles para muchas familias de procesadores, incluidos ARM, PowerPC y Blackfin®. Un puerto consiste en una capa de arquitectura para el procesador y un paquete de soporte de placa (BSP) para periféricos. RT-Kernel es ideal para usar con sistemas integrados en equipos industriales y es adecuado para aplicaciones de control de tren motriz automotriz.
Implementando Fieldbus en Software
RT-Kernel es el complemento ideal para MCU integrados que ejecutan una implementación basada en software de Fieldbus. Este enfoque innovador ha sido desarrollado por RT-Labs y ofrece la máxima flexibilidad al rediseñar equipos industriales para diferentes aplicaciones. Este enfoque significa que simplemente modificando el código que se ejecuta en la MCU, un equipo puede interactuar con los protocolos Fieldbus. Además, cuando se utilizan módulos de hardware para proporcionar la interfaz Fieldbus, esto no es posible sin realizar un rediseño completo de la placa.
Conclusión
Los dispositivos Fieldbus pasan información entre procesos industriales que operan en tiempo real. No tienen tiempo para esperar a que un sistema operativo decida cuándo desea procesar esta información y decidir el curso de acción apropiado, especialmente en circunstancias en las que los retrasos minúsculos pueden tener consecuencias catastróficas. Los sistemas operativos en tiempo real como RT-Kernel garantizan que las operaciones críticas reciban la máxima prioridad y se ejecuten sin demora, lo que garantiza la seguridad y un alto rendimiento en los equipos industriales habilitados para Fieldbus.
