63 / 84
63
PIL TEST |
SOFTWARE
EMBEDDED
59 • FEBBRAIO • 2016
ogni callback è preventivamente collegata a cer-
ti risultati di simulazione, e viene richiamata
quando si verifica il corrispondente evento. Ogni
chiamata attiva poi nell’ambiente target l’azione
precedentemente assegnatagli. Questo ulterio-
re livello di astrazione permette di collegare a
Simulink un’ampia gamma di piattaforme tar-
get diverse. In questo caso non è importante se
la piattaforma target sia una reale piattaforma
hardware o un ambiente di simulazione. Tutta-
via è necessario che ogni piattaforma target sia
in grado di comunicare con Simulink e sappia in-
teragire mediante callback. I generatori di codice
sono particolarmente adatti a semplificare agli
utenti la generazione di un’interfaccia compati-
bile per le callback necessarie.
Nel caso di PIL l’algoritmo non viene solitamente
eseguito in tempo reale nell’ambiente target, ma
viene eseguito in modo incrementale in ciascun
intervallo di simulazione [9]. In ciascun interval-
lo tutti i parametri necessari devono essere ini-
zializzati, i valori d’ingresso passati all’ambiente
target e i valori di uscita restituiti.
Limiti
La precedente implementazione delle simulazio-
ni PIL con Simulink ha una serie di svantaggi
quando è usata nelle applicazioni effettive:
•
i driver usati per la comunicazione con Simu-
link devono essere personalizzati per corrispon-
dere alla configurazione della specifica piattafor-
ma target;
•
le catene di sviluppo sono progettate solo per
l’utilizzo di codice sorgente generato automatica-
mente;
•
non è previsto alcun supporto per la migrazio-
ne di moduli preesistenti che già contengono co-
dice sorgente;
•
possono sorgere conflitti di allocazione quan-
do sulla piattaforma target per la comunicazione
con Simulink vengono utilizzate interfacce non
separate funzionalmente dal livello applicativo;
•
restringere il numero di blocchi PIL contem-
poraneamente consentiti a livello di modello [10]
limita la scalabilità.
Ulteriore sviluppo dell’interfaccia d’integrazione
Per compensare gli svantaggi delle precedenti
soluzioni nell’eseguire simulazioni PIL, è stata
sviluppata una nuova proposta per un’interfaccia
d’integrazione flessibile, ponendosi l’obiettivo di
sviluppare un approccio universale indipendente
dal processo di generazione di codice utilizzato,
e che potesse essere portato molto facilmente su
nuove piattaforme target.
Per essere sicuri che il nuovo approccio si possa
adottare flessibilmente sia con il codice sorgen-
te generato in modo automatico, sia con quello
scritto a mano, l’interfaccia per le callback della
funzione-S viene creata dinamicamente. È neces-
sario in questo caso analizzare la struttura del
codice sorgente quando si genera l’infrastruttura
PIL. Inoltre nella catena di sviluppo è stato inte-
grato un debugger, come nuovo canale di comuni-
cazione fra Simulink e la piattaforma target. Dal
punto di vista di Simulink il debugger fornisce
un’interfaccia di connessione uniforme per diver-
se piattaforme target. In tal modo gli ambienti di
sviluppo già utilizzati durante la fase di progetto
software possono essere riutilizzati senza solu-
zione di continuità per eseguire simulazioni PIL.
In Fig. 4 è mostrato un diagramma schematico
dell’interfaccia d’integrazione proposta.
Analisi della struttura del codice sorgente
-
L’utente ha la capacità di configurare da solo
l’interfaccia fra Simulink e l’applicazione. A tal
scopo la struttura del codice sorgente viene ana-
lizzata e mostrata in un grafico. Mediante una fi-
nestra di dialogo, l’utente può definire una regola
di mappatura fra le callback della funzione-S e le
Fig. 5 - Analisi del codice sorgente e interfaccia
del modello