Accelerazione dello sviluppo di trasmissioni elettriche combinando Model-Based Systems Engineering e la progettazione Model-Based

Nel settore dei veicoli elettrici (EV) e della eMobility, i team di ingegneria che si occupano dello sviluppo delle trasmissioni elettriche si trovano ad affrontare sfide comuni. Questi includono non solo una maggiore complessità del prodotto, ma anche la necessità di consegnare prodotti di alta qualità più rapidamente, contenendo i costi e garantendo la conformità ai processi con ASPICE, ISO^® 26262 e altri standard.

Per rispondere a queste sfide, in eMoveUs abbiamo colto un’opportunità unica: unire l’ampia esperienza dei nostri team nella eMobility con la possibilità di partire da zero nella creazione di una nuova azienda. Abbiamo definito un processo di sviluppo snello con una toolchain coerente che affronta gli svantaggi riscontrati negli approcci precedenti.

Dopo un’attenta valutazione delle opzioni disponibili, abbiamo adottato un workflow che combina l’ingegneria dei sistemi basata su modelli (MBSE) e la progettazione Model-Based utilizzando i prodotti MATLAB^® e Simulink^® insieme al software di Application Lifecycle Management (ALM) Polarion™. Il processo di ingegneria di sistema secondo ASPICE può essere visto nella Figura 1. Questo workflow ha già dimostrato vantaggi in diversi ambiti. Ci permette di lavorare su un’unica fonte di verità e di riutilizzare in modo efficiente i deliverable tra discipline e progetti, aumentando coerenza e produttività. Inoltre, consente ai nostri ingegneri di concentrarsi sullo sviluppo delle feature piuttosto che sulla soddisfazione dei processi, instaurando al contempo la tracciabilità dai requisiti alle architetture, ai modelli, al codice e ai test. È importante sottolineare che ci consente anche di applicare il paradigma “shift-left” all’ingegneria dei sistemi, rendendo possibile analizzare il comportamento dinamico del sistema a livello di sistema e, in particolare, identificare gli errori di specifica in una fase iniziale del processo complessivo.

Modellazione dell’architettura di sistema con System Composer

Nei classici processi di sviluppo dei prodotti, gli errori nelle specifiche del sistema vengono spesso identificati per la prima volta quando i prototipi sono disponibili e quando vengono testati rispetto alle specifiche del sistema. Ciò comporta solitamente elevati costi di correzione degli errori e in parte porta a ritardi critici nel progetto. Per evitare questi costi aggiuntivi e imprevedibili dovuti a errori di specifica a livello di sistema, puntiamo a verificare la correttezza della specifica il più presto possibile nel processo. Nel nostro workflow, utilizziamo System Composer™ per definire architetture di sistema simulabili, che ci permettono di anticipare le attività di test e validazione e automatizzarle con pipeline CI, come illustrato anche nella Figura 1.

Manteniamo una corrispondenza diretta tra i componenti di sistema e quelli dell’architettura software in System Composer e Simulink, così da poter analizzare il comportamento dinamico a livello di sistema. In questo modo, i modelli di comportamento a livello di sistema diventano una base di partenza per i software engineer, che possono riutilizzare sia le interfacce sia i modelli di comportamento definiti nell’architettura di sistema per sviluppare i modelli di progettazione dettagliata necessari alla produzione del software in Simulink. Inoltre, i modelli di simulazione e gli ambienti vengono ampiamente riutilizzati tra i diversi dipartimenti, favorendo coerenza e collaborazione. Ad esempio, lo stesso modello di impianto per simulazioni e test in loop chiuso viene utilizzato nei reparti di sistema, hardware e software ed è anche in grado di funzionare direttamente sul nostro sistema HIL Speedgoat^® in tempo reale.Uno schema che descrive le dipendenze è delineato nella Figura 2.

Inoltre, utilizziamo Requirements Toolbox™ e il Polarion Connector for Simulink per collegare i requisiti gestiti in Polarion con gli elementi architetturali definiti nei modelli System Composer. Colleghiamo inoltre gli elementi di progettazione dettagliata all’interno dei modelli Simulink delle implementazioni software utilizzando questo connettore. Questa configurazione permette la tracciabilità bidirezionale tra specifica e implementazione senza sincronizzazione manuale, facilitando la collaborazione tra team multidisciplinari e garantendo coerenza lungo tutto il ciclo di sviluppo.

Modellazione fisica con Simscape

Le simulazioni in loop chiuso a livello di sistema, software o hardware richiedono un modello fisico della trasmissione elettrica del veicolo. Abbiamo creato questo modello in Simscape™ e Simscape Electrical™. Una visione d'insieme è visibile nella Figura 3. Questo modello multidominio comprende componenti modulari per la batteria della trasmissione, il cavo DC, il filtro EMI, l’inverter, il bus AC, i motori elettrici, i modelli di carico e il sistema di raffreddamento. All’interno di questo modello, è possibile integrare modelli a ordine ridotto per gli effetti termici ed elettromagnetici derivanti da strumenti CAE come Ansys Maxwell, mantenendo i tempi di simulazione previsti.

Per permettere ai nostri ingegneri di scegliere il livello di fedeltà per ciascun componente del caso d’uso di simulazione, abbiamo implementato un sistema di gestione delle varianti utilizzando varianti del modello. Ad esempio, con Variant Manager per Simulink, un team può decidere di eseguire simulazioni di base utilizzando un blocco variante che rappresenta la batteria come una semplice sorgente di tensione costante. Successivamente, il team potrebbe passare alle varianti del circuito RC o RL della batteria per esaminare i comportamenti capacitivo a bassa frequenza o induttivo ad alta frequenza, rispettivamente. Allo stesso modo, i nostri ingegneri possono scegliere una variante semplice a sorgente di tensione controllata per l’inverter per velocizzare la simulazione, oppure optare per una variante ad alta fedeltà con un comportamento di commutazione realistico per analizzare gli effetti del PWM. Un esempio di gestione di queste varianti nel Variant Manager è illustrato nella Figura 4.

Simulazione in loop chiuso, generazione del codice e test HIL in tempo reale

Con l’architettura del sistema definita in System Composer e il modello dettagliato dell’impianto pronto, è possibile eseguire simulazioni in loop chiuso a diversi livelli utilizzando modelli di comportamento del sistema, modelli dell’architettura software o modelli di progettazione dettagliati in Simulink, come illustrato in Figura 5.

Ci permette di anticipare le attività di validazione già a livello di sistema, riducendo così al minimo gli errori di specifica nelle funzioni complesse del sistema di trasmissione.

In questo ambiente, possiamo analizzare il comportamento del prodotto a livello di sistema utilizzando MATLAB e il Data Inspector, per visualizzare segnali, metriche di prestazione e relazioni temporali. Un esempio dei risultati della simulazione in loop chiuso della nostra architettura di sistema, volto ad analizzare il comportamento del controllo di corrente di un controller Field-Oriented, è riportato in Figura 6. I test automatizzati possono essere eseguiti in questa configurazione in loop chiuso, sia a livello di sistema sia su componenti architetturali specifici, utilizzando Simulink Test™. Inoltre, i risultati dei test vengono sincronizzati automaticamente con Polarion, permettendo un monitoraggio sempre aggiornato del progetto e la creazione di report basati sulle specifiche dei casi di test.

Questo approccio di sviluppo coerente non si limita ai confini del dominio, ma prosegue ulteriormente. Procedendo attraverso i domini del V-cycle, dalla specifica di sistema a quella software, dall’architettura alla progettazione Model-Based fino all’implementazione, la fase successiva del nostro workflow include la generazione del codice e i test MIL, PIL e HIL. Qui utilizziamo Embedded Coder^® per generare codice dalla nostra architettura software o dai modelli di progettazione dettagliata in Simulink, per poi integrarlo in uno stack AUTOSAR^® e distribuirlo su un microcontroller Infineon^® AURIX™ TC3xx. Il modello dell'impianto già presentato viene quindi distribuito su un FPGA su una macchina target in tempo reale Speedgoat utilizzando HDL Coder™ e Simulink Real-Time™. Questa configurazione è in grado di verificare il corretto comportamento del software del prodotto finale su un HIL.Inoltre, per sfruttare le sinergie e contenere i costi di sviluppo e di strumentazione, la stessa piattaforma HIL viene impiegata per eseguire i test di integrazione e verifica del sistema, prima di procedere ai test finali su banco prova.

Risultati raggiunti e miglioramenti costanti nell’integrazione

Il workflow e l’approccio della toolchain sono stati validati durante lo sviluppo di un inverter da 800 V basato su carburo di silicio, capace di erogare fino a 600 kW di potenza di picco per applicazioni di trazione automotive. La partecipazione al MathWorks Startup Program ci ha aiutato a ridurre il time-to-market per questo prodotto mantenendo bassi i costi, elemento fondamentale per quasi tutte le startup.

Continuiamo a estendere e migliorare il nostro workflow. Ad esempio, stiamo già utilizzando CI con Jenkins^® e Bitbucket^® per eseguire continuamente test di unità software, integrazione e verifica. Stiamo inoltre estendendo questo workflow automatizzato basato su CI alle fasi più avanzate del V-cycle, per consentire la verifica automatizzata delle nostre architetture di sistema.