Dal progetto al codice attraverso i modelli. A tu per tu con la Senior Software Engineer Anna Lanzaro in un’intervista da leggere fino all’ultimo rigo.

A cura di Emiliano La Cara
[Direttore Area Ingegneria del Software]

L’APPROCCIO MODEL-BASED.

1. Anna, quale lavoro svolgi principalmente in NIER?

Sono un ingegnere informatico, Responsabile di Linea e lavoro in NIER da 5 anni. Durante questo periodo mi sono occupata di supportare i clienti nelle attività che prevedono il processo di sviluppo dei prodotti.

Ho seguito prevalentemente i progetti dedicati al settore ferroviario, basati su approcci di implementazione tradizionali e dove la produzione di documentazione è costante.  Recentemente, invece, le richieste dei nostri clienti si sono rivolte maggiormente sul supporto nella gestione e nello sviluppo di prodotti oppure verso alcune funzionalità che hanno un approccio model-based.

2. Cosa intendi per processi tradizionali e model-based?

Il ciclo di vita dei prodotti nel settore ferroviario, ma più in generale dei sistemi safety-critical (automobilistico, medicale, aerospaziale) è basato su un modello detto a ‘V’.

Il V-Cycle o V-Model viene suddiviso nelle macro-fasi così:

• Le attività di analisi e progettazione sono nel ramo discendente;
• Quelle di sviluppo si trovano nel vertice della ‘V’;
• Quelle di testing e validazione nel ramo ascendente.

Ognuna di queste fasi è caratterizzata da un’attività di verifica che spesso si conclude con la produzione di documenti di testo.

Solitamente, il linguaggio utilizzato tra i team di ingegneri coinvolti nello sviluppo del prodotto è quello naturale. Invece, quando viene scelto l’approccio model-based, ogni fase termina con la descrizione del prodotto affiancata da modelli consistenti e interconnessi, dove il linguaggio non è mai lasciato alla libera interpretazione.

In altre parole, tutti i modelli condividono la stessa base di conoscenza e viene usato lo stesso vocabolario per fornire i diversi punti di vista del sistema.

3. Le due metodologie possono coesistere in uno stesso progetto?

Assolutamente sì. Si può decidere di adottare le metodologie model-based solo per una funzionalità o per un componente particolarmente critico: quello a cui dedicare analisi specifiche, che ti spinge a valutare delle scelte architetturali o implementative e a realizzare delle simulazioni.

Il risultato è un codice eseguibile che può essere integrato nel sistema esistente.

Inoltre, esistono molti tool commerciali che permettono di generare automaticamente la documentazione associata ai modelli sviluppati e che utilizzano template preconfigurati. Una svolta che rende più facile la convivenza tra i due approcci e che snellisce sia le attività di scrittura sia quelle più costose sulla verifica delle specifiche del software.

4. Torniamo ai modelli, ci puoi fare qualche esempio?

La Model-Based System Engineering (MBSE) si basa sullo sviluppo di modelli che permettono di fornire un’astrazione dei componenti hardware e software di un sistema che utilizza i linguaggi formali, come: SySML, Modelica, UML e strumenti di modellazione. Ad esempio:

• Ansys SCADE;
• MATLAB/Simulink;
• MagicDraw;
• Enterprice Architect.

I modelli di progettazione sono in grado di cogliere gli aspetti funzionali e architetturali che consentono al progettista di individuare nuovi requisiti, di verificare quelli esistenti o di rilevare delle criticità. Alcuni esempi di modelli: i diagrammi di sequenza, di attività e macchine a stati.

Una volta che abbiamo definito i modelli di progettazione, si sviluppano quelli di simulazione. Hanno l’obiettivo di fornire un prototipo per l’analisi del comportamento dinamico del sistema o di un suo componente in esecuzione, anche in termini di timing e performance.

I modelli vengono testati, verificati e validati in ogni fase per garantire la corretta trasmissione delle informazioni. L’ultimo step è la generazione automatica del codice sorgente (ad esempio in linguaggio C) a partire dai modelli.

Infine, il codice che viene generato viene integrato con altri componenti oppure eseguito sull’hardware target.

MBSE: DALLE PAROLE AI FATTI.

5. Da quello che ci racconti, il test assume un ruolo fondamentale nella MBSE. Puoi descriverci quali sono le attività di testing, verifica e validazione?

Il testing dei modelli (il cosiddetto MIL, Model-In-The-Loop) permette di verificare il comportamento del sistema o di un suo componente per trovare errori di progettazione ed eventuali margini di miglioramento.

Un passaggio a monte che consente di avere una certa sicurezza sullo sviluppo del software, l’acquisto dell’hardware e soprattutto le giuste garanzie prima di iniziare le attività di testing che spesso sono lunghe e costose.

Successivamente, nel testing denominato SIL (Software-In-The-Loop), il codice sorgente è eseguito e testato in ambiente simulato.

Così si possono individuare eventuali bachi del software durante l’esecuzione e l’opportunità di migliorarne la qualità in anticipo rispetto alla disponibilità dell’hardware del prodotto finale.

L’ultima attività di testing è la software e hardware integration (HIL, Hardware-In-The-Loop), dove il codice sorgente generato automaticamente è testato sull’hardware target.

6. Sembra che l’implementazione dei modelli richieda un certo effort, ma quali sono i vantaggi di introdurre questi modelli nel processo di sviluppo tradizionale?

Gli ingegneri che si occupano di MBSE hanno competenze interdisciplinari e sono in grado di comprendere e realizzare sistemi che, grazie ai rapidi avanzamenti tecnologici, sono sempre più complessi. Attraverso i modelli, è molto intuitivo scomporre il sistema in componenti e individuare sia le interconnessioni che le dipendenze sin dalle prime fasi di progettazione. L’MBSE ti offre l’opportunità di analizzare i comportamenti, identificare eventuali criticità e non conformità rispetto alle specifiche del committente.

Inoltre, la simulazione consente agli ingegneri e al cliente di migliorare il prodotto, valutare le scelte architetturali e le possibili implementazioni durante le varie fasi di progettazione. L’obiettivo è evitare di prendere decisioni sbagliate durante il corso del progetto e che potrebbero costare care sotto tutti i punti di vista. Infine, non va trascurato il vantaggio di avere modelli che possono essere riutilizzati.

7. Anna, ci puoi raccontare di un’esperienza nella MBSE?

Un nostro cliente, leader del settore ferroviario, ci ha commissionato lo sviluppo di un componente software da integrare in quello del DMI a bordo treno. Questo componente, eseguito su un hardware safety-related, costituisce il gateway tra il DMI e i dispositivi di I/O a bordo treno e trasforma i segnali digitali in un formato definito da un protocollo proprietario e viceversa.

Sviluppando il modello del componente attraverso macchine a stati e tabelle di verità è stato possibile analizzare in tempi rapidi il comportamento dinamico del componente . Attraverso la simulazione del modello implementato siamo riusciti ad individuare alcuni problemi dovuti alla parziale o errata specifica dei requisiti ancor prima di integrare il nostro componente con il software del DMI target. Infatti, abbiamo generato automaticamente il codice sorgente pronto per essere integrato con il resto del sistema solo al termine delle attività di simulazione e testing del modello e, come ci auspicavamo (e aspettavamo…), durante l’integrazione con il DMI target ha avuto  successo!

8. Nell’esperienza che ci hai raccontato, quali strumenti di modellazione sono stati utilizzati?

In questo caso particolare è stato utilizzato un tool proprietario che il cliente aveva già utilizzato per lo sviluppo di alcuni componenti software. In generale, i modelli basati su un linguaggio formale possono essere sviluppati con tool commerciali come MATLAB/Simulink, Ansys SCADE, Enterprise Architect. La scelta dello specifico tool dipende dalle esigenze di ciascun cliente, ma tutti si basano su metodologie della MBSE.

Ringraziamo l’ingegnere Anna Lanzaro per il suo tempo e per l’accurata intervista.