Utilizzo della progettazione Model-Based per sviluppare e testare applicazioni SOA per sistemi operativi di bordo

L’industria automotive è nel pieno di una trasformazione radicale, con il passaggio da sistemi meccanici tradizionali a veicoli definiti dal software (SDV). Questa evoluzione richiede nuovi approcci allo sviluppo software, con l’architettura orientata ai servizi (Service-Oriented Architecture, SOA) che emerge come il paradigma preferito per progettare applicazioni automotive flessibili e scalabili. In ZEEKR abbiamo abbracciato questa transizione adottando un workflow completo basato sulla progettazione Model-Based per lo sviluppo di applicazioni SOA che operano sul nostro sistema operativo di bordo.

Lo sviluppo software automotive tradizionale basato sulla progettazione Model-Based si è concentrato principalmente sulle implementazioni AUTOSAR® Classic Platform, in cui i componenti software (SW-C) interagiscono tramite interfacce standardizzate del Run-Time Environment (RTE). Tuttavia, l’SOA introduce nuovi schemi di comunicazione, come le chiamate client-server e le interazioni basate su messaggi, che richiedono adattamenti significativi alle pratiche di sviluppo consolidate. La sfida non consiste solo nel modellare questi nuovi schemi di comunicazione, ma anche nel gestire la maggiore complessità delle architetture software all’interno di un ambiente non standardizzato AUTOSAR.

Il nostro team in ZEEKR ha affrontato queste sfide adottando un workflow basato sulla progettazione Model-Based per lo sviluppo di applicazioni SOA. Questo articolo descrive tre aree chiave di questo workflow:

• Modellazione del comportamento SOA utilizzando le funzionalità dell'interfaccia client-server di Simulink^®
• Manutenzione di architetture software complesse tramite strumenti personalizzati basati su System Composer™
• Implementazione di verifica e validazione efficaci per le applicazioni SOA

La nostra esperienza dimostra come gli ingegneri possano utilizzare la progettazione Model-Based per accelerare la transizione dai sistemi embedded tradizionali alle moderne architetture software basate su SOA per i veicoli definiti dal software (SDV).

Modellazione di applicazioni orientate ai servizi in Simulink

SOA introduce nuovi modelli di comunicazione che differiscono fondamentalmente da quelli dei sistemi embedded tradizionali. Le applicazioni Classic AUTOSAR comunicano tramite interfacce RTE semplici, che facilitano interazioni strettamente accoppiate e definite staticamente tra i componenti software. Al contrario, gli schemi di comunicazione SOA—come le chiamate a procedure remote (RPC) e le interazioni basate su messaggi—sono più flessibili e sofisticati. Consentono inoltre il disaccoppiamento di hardware e software, oltre a favorire la progettazione gerarchica del software. Per sfruttare appieno questi schemi di comunicazione, seguiamo un workflow di sviluppo basato sulla progettazione Model-Based che include: la modellazione delle applicazioni SOA in Simulink, la generazione di codice C++ con Embedded Coder^®, la creazione del codice di integrazione middleware tramite un generatore di wrapper sviluppato internamente e la fusione sia del codice applicativo sia di integrazione in pacchetti applicativi pronti per il deployment. Questo workflow automatizzato non necessita di alcun codice C++ scritto a mano. Il codice wrapper generato automaticamente funge da ponte tra il codice applicativo, derivato dai nostri modelli Simulink, e il run-time environment—ZEEKR ARK OS.

Un modello SOA tipico nel nostro workflow include service provider e client, entrambi modellati in Simulink (Figura 1). Tale struttura rappresenta i comportamenti fondamentali dell’architettura SOA: servizi invocati in modo disaccoppiato, scambio di messaggi esplicito e netta separazione tra comunicazione e calcolo. Ci consente di esprimere chiaramente i concetti SOA all'interno di Simulink e di preparare tali modelli per il deployment in un ambiente distribuito basato sui servizi.

I nostri scenari di deployment includono sia ambienti di elaborazione centralizzati che distribuiti (Figura 2). Le applicazioni orientate ai servizi, modellate in Simulink, vengono eseguite su un'unità di elaborazione centrale ad alte prestazioni. Nel frattempo, i componenti Classic AUTOSAR, anch'essi sviluppati in Simulink, vengono eseguiti su un microcontrollore, interfacciandosi direttamente con gli attuatori del veicolo. Questo deployment misto riflette la tendenza più ampia verso architetture di dominio centralizzate, in cui i domain controller gestiscono l’elaborazione di alto livello mentre i nodi periferici (edge) si occupano del controllo di basso livello. Con Simulink possiamo supportare entrambi gli aspetti di questa architettura, utilizzando un ambiente di sviluppo unificato per modellare, simulare e generare codice per sistemi automotive eterogenei.

Gestione di architetture software complesse con System Composer

Con l'aumentare della portata e della complessità delle applicazioni orientate ai servizi, la gestione della loro struttura diventa una sfida critica. Con più servizi che interagiscono tra più unità software, non è più sufficiente trattare ogni modello in modo isolato. È invece necessario disporre di una rappresentazione architetturale chiara di come i componenti software si relazionano tra loro, includendo il loro raggruppamento, le modalità di comunicazione e i punti di deployment. Molti strumenti commerciali per l’architettura software automotive, inclusi gli strumenti di authoring AUTOSAR, presumono spesso un ambiente basato su AUTOSAR e non supportano la flessibilità necessaria per distribuire modelli di comunicazione basati su servizi in sistemi operativi personalizzati. Per soddisfare le esigenze del nostro framework SOA e del sistema operativo di bordo, abbiamo sviluppato un ambiente di modellazione architetturale interno. SOA Model Composer—o SOMOC—si basa sulle capacità di Model-Based System Engineering e sugli elementi di progettazione architetturale di System Composer, oltre che sulle funzionalità di programmazione orientata agli oggetti di MATLAB^®. Per semplificare l'utilizzo, abbiamo creato un'interfaccia utente personalizzata con MATLAB e App Designer (Figura 3).

SOMOC supporta un approccio strutturato per definire e gestire le architetture SOA su quattro livelli chiave: architettura di sistema, processo, componente software e definizione dei servizi (Figura 4). Questa organizzazione gerarchica sfrutta le capacità dei reference component di System Composer per stabilire una chiara tracciabilità dai sistemi ad alto livello fino ai singoli servizi.

SOMOC arricchisce i modelli architetturali con profili e stereotipi personalizzati per rappresentare i metadata specifici delle SOA, inclusi identificatori di servizio, namespace e dati di versione. Gli architetti di sistema ZEEKR utilizzano SOMOC per tradurre i requisiti funzionali (importati da file ARXML generati durante la progettazione del sistema) in architetture distribuibili, definendo i confini dei processi, le interfacce dei servizi e i componenti software. A partire da questi modelli architetturali, SOMOC genera automaticamente modelli Simulink “shell” con interfacce coerenti, fornendo agli sviluppatori un punto di partenza affidabile per implementare il comportamento o la logica interna (Figura 5). Questa automazione standardizza il workflow dall’architettura all’implementazione, mantiene le interfacce sincronizzate e offre ai nostri team un punto di riferimento condiviso durante tutto lo sviluppo.

Test multilivello per applicazioni SOA

In ZEEKR, validiamo le nostre applicazioni orientate ai servizi combinando test a livello di modello e a livello di codice. Iniziamo con test unitari e test sui modelli in Simulink utilizzando Simulink Test™, impiegando test harness per isolare singoli componenti e verificare le interazioni tra i servizi (Figura 6). Per ciascun modello, gli ingegneri possono simulare la comunicazione con componenti corrispondenti—ad esempio un provider simulato per un modello consumer—e verificare le risposte attese e il comportamento delle interfacce. Questa validazione nelle fasi iniziali aiuta a individuare errori di logica o incongruenze nelle interfacce prima della generazione del codice.

Dopo aver generato il codice applicativo e integrato con il nostro sistema operativo di bordo, eseguiamo test a run-time utilizzando il nostro Service Verification Toolkit (SVT), un plugin leggero all’interno di Visual Studio Code (Figura 7). SVT consente ai team di importare le definizioni delle interfacce dei servizi dai file ARXML e di testare sia le interfacce dei metodi sia quelle dei topic simulando la comunicazione dei servizi a livello applicativo. Può comportarsi sia da consumer sia da provider—inviando richieste di metodo, gestendo le risposte, pubblicando dati sui topic o sottoscrivendosi ai messaggi. SVT mostra i valori scambiati attraverso le interfacce dei servizi, aiutando gli ingegneri a verificare che l’applicazione distribuita si comporti correttamente in diversi scenari di interazione.

Verso il futuro

Mentre continuiamo a sviluppare nuove applicazioni orientate ai servizi per il deployment a bordo veicolo, stiamo anche perfezionando ed espandendo il nostro workflow basato sulla progettazione Model-Based con MATLAB, Simulink, System Composer ed Embedded Coder. Questo workflow ha già dimostrato il suo valore accelerando lo sviluppo e riducendo al minimo le sfide insite nella scrittura manuale del codice. Grazie alla possibilità di eseguire modellazione dell’architettura, modellazione dei servizi, simulazione, generazione del codice e test di applicazioni orientate ai servizi e basate su AUTOSAR in un unico ambiente, disponiamo di una base software scalabile per supportare lo sviluppo di SDV, man mano che continua a rimodellare il panorama automotive.