Applicazione delle best practice per la creazione di modelli Simulink di grandi dimensioni

Man mano che i sistemi crescono in termini di dimensioni e complessità, i team di ingegneria si trovano ad affrontare una serie di sfide completamente nuove, non presenti su scale più piccole.

Quasi sempre, un aumento significativo di scala richiede un cambiamento di approccio, non solo di portata ma anche di natura. Questo principio si applica anche a modelli Simulink^® quando si lavora con la progettazione Model-Based Se non si seguono le best practice, nel passaggio da semplici modelli proof-of-concept a modelli su larga scala con centinaia di migliaia di blocchi, iniziano a emergere una serie di problemi, tra cui problemi legati a un'architettura del modello scadente, alla gestione dei dati, alle interfacce, alla gestione dei file e alle prestazioni della simulazione. Gli elementi costitutivi di questi grandi modelli possono essere piccoli e spesso sviluppati da individui, team e persino dipartimenti diversi. Quando si adotta una standardizzazione e si seguono le best practice, questi modelli possono essere facilmente adattati alle esigenze di scala.

Questo articolo descrive una serie di best practice per gestire le sfide più comuni quando si lavora con modelli grandi e complessi in Simulink. Poiché l'argomento in sé è piuttosto ampio, l'obiettivo qui non è fornire una guida dettagliata e prescrittiva, ma piuttosto presentare le basi di ciascuna best practice, insieme ai link ad altre risorse che possono essere esplorate per una comprensione più approfondita di come può essere applicata.

Uso del riferimento del modello per la componentizzazione del modello

Quando lavoriamo con i clienti, non è raro vedere modelli di grandi dimensioni privi di componentistica significativa. I team iniziano con un modello semplice per testare le idee; col tempo vengono aggiunti nuovi elementi o funzionalità e tutto il lavoro viene svolto in un singolo file modello monolitico che presto diventa poco maneggevole.

In Simulink, ci sono diversi modi per componentizzare modelli di grandi dimensioni e l'approccio migliore dipenderà dal caso d'uso specifico in esame. Ad esempio, un team che desidera semplicemente organizzare visivamente un gruppo di blocchi o componenti può optare per un sottosistema virtuale in-model. Per un team diverso che desidera creare utilità ampiamente utilizzate che cambiano raramente, un sottosistema collegato (o libreria) è un'opzione migliore. Se l'obiettivo è sviluppare o simulare un componente come modello autonomo, allora un riferimento modello è l'approccio migliore.

Il riferimento al modello è inoltre la chiave per la componentizzazione dei modelli su larga scala. Uno dei motivi è che il riferimento al modello in Simulink consente ai team di sviluppare componenti in parallelo come modelli indipendenti. Ogni componente è completamente funzionale e simulabile, nonché salvato nel proprio file SLX, in modo che ogni team possa lavorare in modo indipendente senza interferire con il lavoro degli altri team, cosa praticamente impossibile quando l'intero progetto è catturato in un unico file. Altrettanto importante è che questi modelli di riferimento indipendenti possono essere inseriti all'interno di modelli più grandi per una facile integrazione (Figura 1). Questa architettura può ridurre i tempi di compilazione utilizzando istanze memorizzate nella cache dei modelli di riferimento e build incrementali. Permette inoltre l'utilizzo di modalità acceleratore e acceleratore rapido, che sono trattati più dettagliatamente di seguito nella sezione sulle prestazioni.

Aumento della gestione dei dati con i dizionari dati

Riconsideriamo lo stesso scenario che ha portato ai problemi con la componentizzazione: Un team inizia con un modello semplice come prima prova di concetto e poi continua ad elaborarlo nel tempo. Per un modello semplice, molti ingegneri memorizzeranno variabili, parametri e altri dati nel spazio di lavoro di base. Questo approccio funziona bene per workflow informali, rapida messa a punto dei parametri, prototipazione rapida, progetti con un singolo sviluppatore o casi d'uso che richiedono una visibilità universale dei parametri. Tuttavia, man mano che i modelli aumentano in portata e complessità, affidarsi allo spazio di lavoro di base per la gestione dei dati presenta alcuni svantaggi. Ad esempio, poiché l'area di lavoro di base viene cancellata ogni volta che un ingegnere chiude la sessione, è necessario salvarla manualmente o in un codice MATLAB^® codice (.m) o un file MATLAB (.mat).

I dizionari di dati sono più adatti dell'area di lavoro di base per la gestione dei dati su progetti che coinvolgono modelli di grandi dimensioni, sviluppo distribuito o dati con ambito definito. Le ragioni sono diverse (vedere Figura 2). Il primo è la persistenza dei dati. I dati vengono salvati in un formato di file specifico nei file del dizionario dati (.sldd), consentendo ai team di definire, gestire e aggiornare i dati separatamente dal modello e dall'area di lavoro di base. In secondo luogo, i team possono suddividere i dati in più dizionari per migliorarne ulteriormente l'organizzazione. In terzo luogo, i dizionari di dati funzionano bene nei workflow di monitoraggio delle modifiche, in cui i team possono visualizzare quali modifiche sono state apportate, quando e chi le ha apportate, e persino ripristinare versioni precedenti quando necessario.

È importante notare che la scelta tra l'utilizzo dell'area di lavoro di base e dei dizionari dati non è una scelta “tutto o niente”. I due approcci possono coesistere, in modo che un team possa gradualmente migrare nel tempo dall'area di lavoro di base a uno o più dizionari di dati.

Semplificazione delle interfacce con i bus

Quando si collegano i sottosistemi in un modello gerarchico e componentizzato, potrebbe inizialmente sembrare che l'approccio più semplice sia quello di utilizzare una linea di segnale separata per ciascun elemento che viene passato da un componente all'altro. Naturalmente, questo metodo funziona per interfacce semplici, ma può rapidamente dare origine a modelli più complessi, disordinati e difficili da gestire del necessario.

In Simulink, i bus possono semplificare le interfacce e ridurre l'ingombro rappresentando un set di segnali (o elementi) con un'unica linea, proprio come diversi fili raggruppati insieme. Il valore di questo è facile da capire con un semplice esempio. Prendiamo in considerazione un componente di rilevamento guasti per identificare condizioni anomale in un sistema di batterie. Il componente ha 11 input diversi, tra cui tensione massima e minima della cella, temperatura massima e minima della cella, stati del contattore, tensione e corrente del pacco e limiti di corrente. Sebbene sia certamente possibile creare il componente con 11 porte di input individuali, è più chiaro separare gli input in gruppi logici e utilizzare un bus per ciascun gruppo. Ad esempio, poiché i segnali di tensione e temperatura della cella provengono tutti dallo stesso componente e sono tutti correlati, ha senso raggrupparli in un singolo bus a quattro elementi (Figura 3). Si tratta chiaramente di un esempio relativamente banale, ma illustra come i bus possano essere utilizzati per semplificare non solo le interfacce dei componenti ma, più in generale, anche modelli complessi.

Migliore gestione dei file con i progetti

Uno degli effetti collaterali dell'adozione delle best practice finora descritte è l'aumento del numero di file da gestire. Quando l'intera progettazione è contenuta in un unico modello, il set di file che un team deve gestire è relativamente piccolo, ma può aumentare rapidamente quando vengono impiegati attivamente la componentizzazione e i dizionari dati. Senza una strategia di gestione dei file, questa proliferazione di file può diventare problematica.

Quando si lavora in Simulink, i team possono utilizzare progetti per automatizzare le attività di gestione dei file, in modo da avere più tempo da dedicare alla modellazione, alla simulazione e ad altre attività di alto valore. Ad esempio, quando si imposta un progetto, il team specificherà le cartelle nel percorso del progetto. Queste cartelle vengono aggiunte al percorso di ricerca quando il progetto viene aperto (e rimosse quando il progetto viene chiuso), garantendo che tutti gli utenti del progetto abbiano accesso ai file in esse contenuti. Il team può anche specificare file di startup che automatizzano la configurazione dell'ambiente per il progetto e i file di arresto che puliscono l'ambiente annullando, ad esempio, i passaggi di configurazione. Inoltre, i progetti possono essere configurati in modo da aprire all'avvio i file utilizzati di frequente e creare scorciatoie per le attività più comuni.

I progetti possono anche aiutare i team a evitare errori comuni. Ad esempio, con una gerarchia di modelli complessa, non è insolito che due file di modello con lo stesso nome esistano in directory diverse. Quando si utilizza un progetto, un ingegnere visualizzerà un avviso quando vengono rilevati tali file in ombra. Inoltre, agli ingegneri viene richiesto di salvare eventuali modifiche non salvate quando un progetto viene chiuso, aiutando a evitare la perdita di lavoro.

Infine, i progetti aiutano a semplificare il controllo del codice sorgente, con operazioni comuni quali refresh, commit, push, pull, fetch e altre operazioni comuni accessibili direttamente dall'interfaccia utente (Figura 4).

Ottimizzazione delle prestazioni della simulazione

Le best practice che abbiamo trattato finora si sono concentrate principalmente sulla struttura dei modelli di grandi dimensioni e sui dati e file associati. Nelle conversazioni con i clienti che hanno implementato queste best practice, spesso ci viene chiesto come migliorare le prestazioni della simulazione: “Ora che abbiamo un modo migliore per costruire modelli di grandi dimensioni, come possiamo farli simulare più velocemente? ”

Sono disponibili diversi strumenti per migliorare le prestazioni della simulazione. Come primo passo, ti consigliamo di usare Performance Advisor, che esegue una serie di controlli per identificare le impostazioni di configurazione che potrebbero rallentare le simulazioni. Successivamente, per qualsiasi modello che includa codice MATLAB di inizializzazione (in un callback, ad esempio), è una buona idea eseguire l’App Profiler di MATLAB per identificare dove MATLAB impiega la maggior parte del tempo. Simulink Profiler valuta il tempo di esecuzione del modello e identifica i problemi che potrebbero contribuire a scarse prestazioni della simulazione. Infine, per i team che utilizzano un risolutore a passo variabile, consigliamo di eseguire Solver Profiler, che analizza il comportamento del risolutore, identifica potenziali problemi (ad esempio ripristini del solver o intervalli di tempo eccezionalmente piccoli) e fornisce suggerimenti per risolverli. Le indicazioni su ciascuno di questi strumenti, incluso come e quando utilizzarli, sono disponibili nella guida Troubleshoot and Speed Up Simulation Performance (vedi tabella).

I team che hanno componentizzato il loro modello di grandi dimensioni possono accelerare le simulazioni utilizzando la modalità acceleratore o modalità acceleratore rapido, che sostituiscono il codice interpretato normalmente utilizzato nelle simulazioni Simulink con il codice generato. Durante l'inizializzazione del modello, Simulink controlla la cache per individuare eventuali componenti per i quali è già stato generato codice. Questo processo di build incrementale riduce notevolmente i tempi di inizializzazione per modelli di grandi dimensioni con molti componenti, perché solo i componenti che sono cambiati dall'ultima simulazione dovranno essere ricostruiti (e aggiunti alla cache).

Un altro modo per ridurre il tempo di inizializzazione, in particolare quando si simula un modello in modo iterativo, è con il riavvio veloce. Quando un team esegue più simulazioni senza apportare modifiche strutturali al modello, il riavvio rapido può velocizzare il processo eseguendo le simulazioni senza compilare il modello e senza terminare la simulazione ogni volta. Invece, durante la prima simulazione il modello viene compilato e inizializzato e poi viene catturata un'istantanea del punto operativo del modello per ogni simulazione successiva (Figura 5).

In conclusione, mentre i team di ingegneri affrontano le complessità del ridimensionamento dei modelli Simulink, diventa essenziale attenersi alle best practice. In questo articolo sono state delineate strategie essenziali per la componentizzazione del modello, la gestione dei dati e l'ottimizzazione delle prestazioni, sottolineando l'importanza di un approccio strutturato allo sviluppo del modello. Utilizzando strumenti quali Performance Advisor, MATLAB Profiler e Solver Profiler, i team possono migliorare le prestazioni della simulazione e aumentare la produttività. Queste pratiche garantiscono che i modelli su larga scala rimangano gestibili, efficienti e adattabili. Mentre il panorama della progettazione Model-Based continua a evolversi, queste linee guida aiuteranno i team a creare modelli solidi che soddisfino le esigenze di sfide ingegneristiche sempre più complesse. Per ulteriori approfondimenti, si incoraggiano i lettori a utilizzare le risorse aggiuntive e le opportunità di formazione evidenziate nel presente documento.

Il contenuto di questo articolo si basa su un intervento intitolato “Best Practices for Building Large Models from Components to Complex Systems” (vedere “Scopri di più” per questo intervento, insieme ad altri webinar e corsi di formazione), che abbiamo presentato alla MathWorks Automotive Conference. Come abbiamo detto all'inizio, si tratta di un argomento molto vasto che non può essere trattato in modo esaustivo in un singolo articolo o discorso.