69 / 84
69
EMBEDDED
57 • settembre • 2015
TEST |
software
statistiche e di copertura del codice, oltre a poter
rilevare in modo rapido e sistematico condizioni
di malfunzionamento particolarmente complesse
che si verificano solo a runtime.
Il riconoscimento delle strutture dati rilevanti
di un sistema operativo e dei suoi meccanismi di
gestione delle risorse (awareness) permette a un
debugger di offrire all’utente funzionalità avan-
zate di controllo del software. Per molti sistemi
operativi embedded, i debugger Lauterbach for-
niscono una sofisticata integrazione con l’OS, in
grado di mostrare le condizioni di utilizzo delle
principali risorse allocate.
Inoltre, molte CPU rendono disponibile anche
il trace di dati d’interesse dell’utente, ad esem-
pio l’informazione sul processo correntemente
in esecuzione in un sistema operativo multipro-
cessing. Utilizzando questi dati, TRACE32 è in
grado di analizzare il flusso di esecuzione di un
programma multitasking, distinguendo il codice
per ogni singolo thread o processo.
Introduzione allo standard AUTOSAR
L’architettura software AUTOSAR è uno stan-
dard aperto per l’ambito automobilistico, svilup-
pato da un consorzio di aziende del settore per
creare un’infrastruttura integrata valida come
punto di riferimento per lo sviluppo di software
per autoveicoli. Pur preservando la competitività
delle aziende partecipanti, ha lo scopo di miglio-
rare l’efficienza e la qualità del software in ambi-
to automobilistico.
Per il progetto delle funzioni di controllo di un
autoveicolo, lo standard AUTOSAR definisce un
modello di progettazione software basato su com-
ponenti. Questi componenti sono l’unità minima
applicativa dotata di funzionalità e quindi l’inte-
ra applicazione può essere vista come composta
da diversi componenti che si interfacciano fra
loro come definito nello standard.
Un progetto AUTOSAR si basa su un’architettu-
ra a livelli in cui i componenti sono collegati a
livello concettuale da un Virtual Function
Bus (VFB), e a livello implementativo da un
Real Time Environment (RTE). In figura
1 è riportato uno schema di riferimento. Il
livello Basic SoftWare (BSW) si occupa di
fornire servizi sia dipendenti dall’hardware
sia indipendenti, in modo da fornire un’a-
strazione verso i livelli superiori. Invece i ser-
vizi di livello applicativo (Application Software
Component) realizzano le effettive funzionalità
del sistema. Poiché i componenti AUTOSAR non
hanno accesso diretto all’hardware sottostante
o al sistema operativo, la loro implementazione
non può essere caratterizzata da entità come i
thread o i processi. Ogni singola funzionalità da
eseguire a runtime viene invece incapsulata in
un cosiddetto runnable, definito come “una se-
quenza di istruzioni che può essere avviata dal
Run Time Environment”.
Analisi di trace con TRACE32
Applicando quanto detto sinora a un sistema
AUTOSAR/OSEK, si può rilevare che TRACE32
Fig. 1 – Architettura AUTOSAR
Fig. 2 – Esempi di analisi statistiche sui task in
TRACE32
Fig. 3 – Esempi di analisi statistiche sulle fun-
zioni in TRACE32