Sobre CAN, Aplicaciones de Control y Testeo

CAN (Controller Area Network) es un bus de campo publicado por Bosch en 1991.  Se emplea en diversos sectores,  como la automatización o transporte vertical por citar algunos,  pero principalmente en la industria de la automoción.

En relación al modelo OSI, especifica las capas físicas y en enlace.  Es un bus para broadcast  y se pueden enviar mensajes de hasta 8 bytes. Además,  por hardware se evitan colisiones  y por lo tanto, ofrece los mecanismos para poder ser empleado en sistemas de tiempo real.

Sobre tal infraestructura, se definen protocolos superiores como J1939  o CANopen. De forma muy resumida, estos protocolos definen el contenido de los mensajes a intercambiar y su tipo de transmisión (e.g. periodicidad). Permiten desarrollar capas de aplicación y ofrecer a los desarrolladores una abstracción basada en leer/modificar variables y abstraerse de la “infraestructura de mensajería”.  Crean la “ilusión” de que existe un repositorio global de datos a la que todas las aplicaciones pueden acceder.

Centrémonos  ahora en los sistemas de control a los que los protocolos anteriores van dirigidos. A la hora de verificar  un sistema, acuden términos como MIL, SIL, PIL, HIL (model, software, processor,  hardware in the loop). Atendiendo a la primera figura, inmediatamente se puede observar que los nodos conectados al bus pueden ser reemplazados por “simuladores funcionalmente equivalentes”.  Lo único que se espera de éstos es que lean/modifiquen el repositiorio global de variables de la tercera figura de forma análoga la dispositivo real.

Existen diversas herramientas comercialmente disponibles para este último propósito. Ofrecen posibilidades de crear simuladores, acceder al bus de campo pertinente,  testear el sistema de control contra un simulador a nivel lógico o nivel físico, etc …

La simulación hardware-in-the-loop (HIL) es una técnica usada para el desarrollo y comprobación de sistemas embebidos en tiempo real complejos. La simulación HIL constituye una plataforma efectiva porque incluye toda la complejidad de la planta que controla el sistema embebido. Esto lo realiza mediante modelos matemáticos de todos los sistemas dinámicos relacionados con la planta bajo control, formando lo que se denomina como «simulación de la planta». El sistema embebido que se está comprobando interactúa con esta simulación de la planta.

La simulación hardware-in-the-loop debe incluir la simulación eléctrica de sensores y actuadores. Estas simulaciones sirven de interfaz entre el modelo de planta y el sistema integrado bajo prueba. El valor de cada sensor está controlado por el modelo de planta y es leído por el sistema embebido. Del mismo modo, el sistema embebido bajo prueba ejecuta su algoritmo de control por medio de las señales de los actuadores. Igualmente, cambios en las señales de control provocan cambios en los valores de las variables en el modelo de simulación de planta. Por ejemplo, un sistema HIL de simulación para desarrollo de sistema antibloqueo de freno (ABS) puede incluir la representación matemática de los siguientes subsistemas en el modelo de planta:

• Elementos del chasis como la suspensión, ruedas, neumáticos, alabeo, guiñada y cabeceo.
• Características de la vía por la que se desplaza el vehículo.
• Dinámica del circuito hidraúlico de freno.

Además la simulación hardware-in-the-loop debe proveer una interfaz de comunicación con los sistemas de bus de datos. Por ejemplo, en el caso de la automoción se debe proporcionar la correspondiente topología de bus (CAN, LIN, FlexRay, MOST, etc.).

Aunque desde el punto de vista industrial/comercial la adquisición de herramientas de soporte resulte una labor delicada y costosa,  académicamente se puede abordar con relativa facilidad; es sencillo practicar con los buses de campo y afianzar conceptos teóricos, tal y como se aborda en el Master de Sistemas Embebidos de la Universidad de Mondragón. La parte comercial queda relegada a proyectos específicos con empresas y bajo demanda de éstas.

La línea de investigación de Sistemas Distribuidos de Tiempo Real, acaba de empezar una nueva trayectoria en este ámbito por la mano de Ulma Embedded Solutions. Ambos están colaborando en un proyecto ETORGAI, llamado NUSUR, donde se plantea una arquitectura de control de un autobús mediante unas ECU simulada y conectada vía CAN. Se quiere desarrollara una plataforma de testeo que sirva para diferentes Simuladores o herramientas de diseño y desarrollo de ECUs.