Uso de diseño basado en modelos para desarrollar y probar aplicaciones de SOA para sistemas operativos de vehículos

La industria de la automoción está experimentando una profunda transformación a medida que los vehículos evolucionan desde sistemas mecánicos tradicionales a vehículos definidos por software (SDV). Este cambio exige nuevos enfoques para el desarrollo de software, y la arquitectura orientada a servicios (SOA) surge como el paradigma preferido para diseñar aplicaciones de automoción flexibles y escalables. En ZEEKR, hemos adoptado esta transición estableciendo un flujo de trabajo integral basado en diseño basado en modelos para desarrollar aplicaciones de SOA que se ejecutan en el sistema operativo del vehículo.

El desarrollo de software de automoción tradicional que utiliza diseño basado en modelos se ha centrado principalmente en implementaciones de la plataforma AUTOSAR^® Classic, donde los componentes de software (SW-C) interactúan a través de interfaces de entorno en tiempo de ejecución (RTE) estandarizadas. Sin embargo, SOA introduce nuevos patrones de comunicación, como llamadas cliente-servidor e interacciones basadas en mensajes, que requieren ajustes significativos en las prácticas de desarrollo establecidas. El desafío no sólo radica en modelar estos nuevos patrones de comunicación, sino también en gestionar la creciente complejidad de las arquitecturas de software dentro de un entorno no estandarizado por AUTOSAR.

Nuestro grupo en ZEEKR ha abordado estos desafíos con un flujo de trabajo basado en diseño basado en modelos para el desarrollo de aplicaciones de SOA. Este artículo describe tres áreas clave de este flujo de trabajo:

• Modelado del comportamiento de SOA utilizando las capacidades de la interfaz cliente-servidor de Simulink^®
• Mantenimiento de arquitecturas de software complejas mediante herramientas personalizadas basadas en System Composer™
• Implementación de verificación y validación efectivas para aplicaciones de SOA

Nuestra experiencia demuestra que los ingenieros pueden utilizar diseño basado en modelos para acelerar la transición de los sistemas integrados tradicionales a las arquitecturas de software modernas basadas en SOA para SDV.

Modelado de aplicaciones orientadas a servicios en Simulink

SOA introduce nuevos patrones de comunicación que difieren fundamentalmente de los sistemas integrados tradicionales. Las aplicaciones de AUTOSAR Classic se comunican a través de interfaces RTE simples, que facilitan interacciones estrechamente acopladas y definidas estáticamente entre los componentes del software. Por el contrario, los patrones de comunicación de SOA (como las llamadas a procedimientos remotos y las interacciones basadas en mensajes) son más flexibles y sofisticados. También permiten la disociación del hardware y el software, así como el diseño jerárquico de software. Para aprovechar al máximo estos patrones, seguimos un flujo de trabajo de desarrollo basado en diseño basado en modelos que incluye el modelado de las aplicaciones de SOA en Simulink y la generación de código C++ con Embedded Coder^®, creando código de integración de middleware con un generador de envoltura que construimos, y fusionando el código de aplicación y el de integración en paquetes de aplicaciones implementables. Este flujo de trabajo automatizado no necesita código C++ escrito a mano. El código envolvente generado automáticamente une el código de aplicación que generamos a partir de nuestros modelos de Simulink con el entorno de ejecución ZEEKR ARK OS.

Un modelo de SOA típico en nuestro flujo de trabajo incluye proveedores de servicios y clientes, ambos modelados en Simulink (Figura 1). Esta estructura captura el comportamiento esencial de SOA: invocación de servicios desacoplados, intercambio de mensajes explícitos y separación clara entre comunicación y computación. Nos permite expresar conceptos SOA claramente dentro de Simulink y preparar esos modelos para su implementación en un entorno distribuido basado en servicios.

Nuestros escenarios de implementación abarcan entornos informáticos tanto centrales como distribuidos (Figura 2). Las aplicaciones orientadas a servicios, modeladas en Simulink, se ejecutan en una unidad informática central de alto rendimiento. Mientras tanto, los componentes de AUTOSAR Classic, también desarrollados en Simulink, se ejecutan en un microcontrolador, interactuando directamente con los actuadores del vehículo. Esta implementación mixta refleja la tendencia más amplia hacia arquitecturas de dominio centralizadas, donde los controladores de dominio gestionan el procesamiento de alto nivel mientras que los nodos de borde manejan el control de bajo nivel. Con Simulink, podemos respaldar ambos aspectos de esta arquitectura, utilizando un entorno de desarrollo unificado para modelar, simular y generar código para sistemas de automoción heterogéneos.

Gestión de arquitecturas de software complejas con System Composer

A medida que las aplicaciones orientadas a servicios crecen en alcance y complejidad, gestionar su estructura se convierte en un desafío crítico. Con múltiples servicios que interactúan en múltiples unidades de software, ya no es suficiente tratar cada modelo de forma aislada. En cambio, necesitamos una representación arquitectónica clara de cómo se relacionan los componentes de software entre sí, cómo están agrupados, cómo se comunican y dónde se implementan. Muchas herramientas de arquitectura de software de automoción disponibles comercialmente, incluidas las herramientas de creación de AUTOSAR, a menudo suponen un entorno basado en AUTOSAR y no admiten la flexibilidad de implementar modelos de comunicación basados en servicios para sistemas operativos personalizados. Para satisfacer las necesidades de nuestro marco de SOA y del sistema operativo del vehículo, creamos nuestro propio entorno de modelado de arquitectura. SOA Model Composer (o SOMOC) se basa en las capacidades de ingeniería de sistemas basada ​​en modelos y los elementos de diseño arquitectónico de System Composer, así como en las capacidades de programación orientada a objetos de MATLAB^®. Para facilitar su uso, creamos una interfaz de usuario personalizada con MATLAB y App Designer (Figura 3).

SOMOC apoya un enfoque estructurado para definir y gestionar SOA en cuatro niveles clave: arquitectura del sistema, proceso, componente de software y definición de servicio (Figura 4). Esta organización jerárquica utiliza las capacidades de los componentes de referencia de System Composer para establecer una trazabilidad clara desde los sistemas de alto nivel hasta los servicios individuales.

SOMOC amplía los modelos de arquitectura con perfiles y estereotipos personalizados que capturan metadatos específicos de SOA, como identificadores de servicio, espacios de nombres e información de versión. Los arquitectos de sistemas ZEEKR utilizan SOMOC para traducir requisitos funcionales (importados de archivos ARXML generados durante el diseño del sistema) en arquitecturas implementables mediante la definición de límites de procesos, interfaces de servicio y componentes de software. A partir de estos modelos de arquitectura, SOMOC genera automáticamente modelos shell de Simulink con interfaces consistentes, lo que proporciona a los desarrolladores un punto de partida confiable para implementar el comportamiento o la lógica interna (Figura 5). Esta automatización estandariza el flujo de trabajo desde la arquitectura hasta la implementación, mantiene las interfaces sincronizadas y brinda a nuestros equipos un punto de referencia compartido durante todo el desarrollo.

Pruebas multinivel para aplicaciones de SOA

En ZEEKR, validamos nuestras aplicaciones orientadas a servicios mediante una combinación de pruebas en nivel de modelo y en nivel de código. Comenzamos con pruebas unitarias y de modelos en Simulink con Simulink Test™, utilizando arneses de prueba para aislar componentes individuales y verificar interacciones de servicio (Figura 6). Para cada modelo, los ingenieros pueden simular la comunicación con componentes homólogos (como un proveedor simulado para un modelo de consumidor) y verificar las respuestas esperadas y el comportamiento de la interfaz. Esta validación en etapa temprana ayuda a identificar errores lógicos o desajustes de interfaz antes de que se genere el código.

Después de generar el código de la aplicación e integrarlo con nuestro sistema operativo en el vehículo, realizamos pruebas en tiempo de ejecución utilizando Service Verification Toolkit (SVT), un complemento liviano dentro de Visual Studio Code (Figura 7). SVT permite a los equipos importar definiciones de interfaz de servicio desde archivos ARXML y luego probar interfaces de métodos y temas simulando la comunicación del servicio en nivel de aplicación. Puede actuar como consumidor o proveedor: enviando solicitudes de métodos, manejando respuestas, publicando datos de temas o suscribiéndose a mensajes. SVT muestra los valores intercambiados en las interfaces de servicio, lo que ayuda a los ingenieros a confirmar que la aplicación implementada se comporta correctamente en diferentes escenarios de interacción.

Pensando en el futuro

A medida que continuamos desarrollando nuevas aplicaciones orientadas a servicios para nuestra implementación en vehículos, también estamos refinando y ampliando nuestro flujo de trabajo basado en diseño basado en modelos con MATLAB, Simulink, System Composer y Embedded Coder. Este flujo de trabajo ya ha demostrado su valor al acelerar el desarrollo y minimizar los desafíos inherentes a la escritura manual de código. Con la capacidad de realizar modelado de arquitectura, modelado de servicios, simulación, generación de código y pruebas de aplicaciones orientadas a servicios y basadas en AUTOSAR en un solo entorno, tenemos una base de software escalable para respaldar el desarrollo de SDV a medida que continúa avanzando el sector de automoción.