Scuola Politecnica e delle Scienze di BaseCorso di Laurea in Ingegneria Informatica

Elaborato finale in Misure per l'Automazione e la Produzione Industriale

Sviluppo di layer applicativo per fault injection in un wheel speed sensor emulator

Anno Accademico 2013-2014

Candidato:

Francesco Di Lillo

matr. N46001380

Vorrei ringraziare Vittorio per avermi seguito nello sviluppo di questo lavoro con estrema disponibilità e pazienza. Dedico questo traguardo a Chiara, Fabio e tutte le persone che mi hanno sostenuto ed incentivato durante questi anni, ma sopratutto ai miei genitori ed amia sorella Marcella per essere stati una guida costante nel mio percorso e per avermi impartito insegnamenti che nessun tipo di università avrebbe potuto trasferirmi.

Indice

Introduzione .......................................................................................................................................... 4Capitolo 1: Struttura dell'emulatore ...................................................................................................... 5

1.1 Protocollo di Comunicazione ..................................................................................................... 71.2 Interfaccia Grafica ...................................................................................................................... 9

Capitolo 2: Firmware .......................................................................................................................... 112.1 ISR TIMER0 ............................................................................................................................ 11

2.1.1 Prescaler e Risoluzione ...................................................................................................... 132.1.2 Maschere di Open e di Short ............................................................................................. 13

Capitolo 3: Ottimizzazioni ................................................................................................................. 163.1 Scelta dei fattori correttivi ........................................................................................................ 16

Capitolo 4: Risultati sperimentali ...................................................................................................... 194.1 KMI22 Philips – VDA .............................................................................................................. 20

4.1.2 Funzionamento in condizioni ideali .................................................................................. 214.1.3 Funzionamento in condizioni di fault ................................................................................ 22

4.2 INFINEON TLE4942 ............................................................................................................... 264.3 AIS1200PS .............................................................................................................................. 29

Conclusioni ......................................................................................................................................... 31Bibliografia ......................................................................................................................................... 32

Introduzione

La necessità di velocizzare la prototipazione dei sistemi di testing ha portato

l'azienda STMicroelectronics a realizzare un emulatore di wheel speed sensor in

grado di poter riprodurre i segnali elettrici dei sensori posti in corrispondenza delle

ruote di automobili e motoveicoli. L'emulazione delle situazioni di fault, in cui il

comportamento dei sensori non coincide con quello atteso, costituisce un sensibile

miglioramento delle prestazioni dell'emulatore. Da questa esigenza è partito il

progetto che ha avuto come obiettivo quello di sviluppare un layer applicativo che

consentisse l'emulazione della fault injection ; il lavoro si è articolato in diverse

parti : l'analisi dell'emulatore precedentemente realizzato (firmware ed interfaccia

grafica), modifica della board su cui è stata implementata la precedente versione

del progetto e fase di debug e caratterizzazione.

Per lo sviluppo del layer applicativo sono stati utilizzati : l'IDE Atmel Studio nella

sua versione 6.1 per la modifica, la compilazione ed il debug del firmware e

LabVIEW (Laboratory Virtual Instrumentation Engineering Workbench) per la

realizzazione dell'apposita VI adibita alla fault injection.

4

Capitolo 1: Struttura dell'emulatore

Per la realizzazione dell'emulatore è stato utilizzato il microcontrollore ad 8 bit

ATMEGA328p, realizzato dalla casa produttrice Atmel, montato su di una board

realizzata dalla STMicroeletronics.

Rispetto all'emulatore pre-esistente, è stata richiesta la possibilità di simulare due

differenti tipologie di guasto : OPEN e SHORT TO GROUND. Per spiegarne il

funzionamento, occorre una breve premessa riguardante i sensori emulati. Tutti i

sensori presenti nell'emulatore codificano le informazioni sotto forma di impulsi di

corrente che possono assumere unicamente tre valori : 7, 14, 28 mA da ciò risultano

anomale le condizioni di OPEN (uscita del sensore pari a 0 mA) e di SHORT

(uscita saturata a 35 mA). Per realizzare la prima tipologia di fault è stato

necessario interrompere il percorso della corrente Is, mostrata nell'Illustrazione 1,

così da emulare una condizione di perdita del segnale, dovuta, ad esempio, ad una

disconnessione del sensore (temporanea o permanente).

A tale scopo, sono stati inseriti in serie al percorso dei mosfet (Q2 – Q5, in

Illustrazione 1) i quali, pilotati opportunamente mediante i pin D10, D11, D12, D13

del micro consentono l'emulazione del fault desiderato interrompendo/ripristinando

il passaggio di corrente in base ad una particolare tempistica definibile dall'utente.

Riguardo al fault SHORT TO GROUND non è stato neccessario apportare

modifiche hardware alla scheda poiché esso si realizza alzando tutti i pin relativi

alle PORTB e PORTD, ciò ha come risultato il portare a VUSB le tensioni V021,

V031, V022, V032, V023, V033, V024 e V034 indicate nell'illustrazione 1. In questo

modo, considerato a titolo di esempio il circuito con R55 e R10 (il risultato ed i

calcoli sono i medesimi in tutte e quattro gli schemi circuitali) si vuole determinare

l'uscita del sensore IS : le resistenze R55 , R10 e R9 sono in parallelo tra loro e la

resistenza equivalente risultante è :

5

Il potenziale del nodo 3 (adiacente all'amplificatore) puo' essere calcolato

utilizzando un partitore di tensione.

Da cui, per il corto circuito virtuale, si è determinato anche il potenziale del nodo 2.

La corrente I2 equivale a :

Utilizzando I2 si determina il potenziale del nodo C da cui poi è possibile giungere a

IS :

Il risultato finale è la saturazione dell'uscita del sensore a 35 mA, valore non

previsto nel normale funzionamento del sensore di wheel-speed.

6

1.1 Protocollo di Comunicazione

Nel progetto pre-esistente, l'utente puo' selezionare il tipo di sensore ed il pattern di

segnale da emulare utilizzando l'interfaccia grafica, la quale, nativamente,

implementa un protocollo di comunicazione seriale tra il computer ed il

7

Illustrazione 1

microcontrollore sulla board. Il protocollo di comunicazione dell'emulatore è stato

quindi modificato per permettere il trasferimento delle informazioni relative al fault

(tipologia, ritardo rispetto ad un trigger definito e durata) di cui effettuare una

simulazione.

Analizzando il protocollo nel dettaglio:

• ACK(Acknowledge): i primi otto bit della stringa contengono un carattere di

controllo utile al microcontrollore per determinare la presenza di errori nel

processo di trasmissione, in particolare, è stato scelto 0xC3 come carattere

esadecimale che rappresenta la corretta trasmissione della stringa,

riconosciuto questo carattere, verrà inviato in risposta 0x3C. Nel caso in cui

venga riconosciuto un carattere esadecimale differente, il microcontrollore

ignorerà la stringa e risponderà con un NACK codificato con 0xFF.

• WAIT : in questo carattere è codificata la durata degli impulsi del segnale.

• #SLICE : indica il numero di impulsi del segnale da simulare.

• TR1, TR0 : sono i due caratteri ausiliari per la descrizione del

comportamento del sensore a basse velocità.

• ADC2, ADC1, ADC0 : sono caratteri utilizzati per descrivere il

comportameno del sensore in caso di perdita della tensione di alimentazione.

• C0 : è un carattere contenente diversi flag di controllo la cui struttura è

sinteticamente indicata di seguito.

L'MSB indica se il sensore che si vuole emulare è di tipo wheel speed oppure

accelerometer , i due bit successivi sono attualmente inutilizzati,il quarto bit

8

Illustrazione 2: Struttura del carattere C0

abilita o disabilita i fault nell'emulazione, con il terzo bit invece si specifica

la tipologia di guasto che si è interessati ad emulare : OPEN che simula

l'interruzione di segnale e SHORT che simula la condizione di sensore in

corto a massa. Il secondo bit abilita l'iterazione dei fault o alternativamente la

modalità single-shot. I bit PSK_DUR e PSK_DL definiscono invece la

risoluzione temporale desiderata dall'utente rispettivamente sulla durata del

guasto e sul ritardo rispetto al trigger.

• C1 : contiene al suo interno la durata del tempo di delay, ovvero

dell'intervallo di tempo, a partire dal trigger, in seguito al quale si desidera

che avvenga la simulazione di guasto.

• C2 : codifica la durata del guasto, parametro che, insieme al precedente, è a

totale discrezione dell'utente.

• C3, C4, .. , C9 : al momento inutilizzati e destinati a scopi futuri.

• SLICES : è contenuta la sequenza degli stati dei pin, definiscono il pattern di

modulazione del sensore.

1.2 Interfaccia Grafica

A partire dalla precedente implementazione dell'emulatore ed utilizzando

l'ambiente LabView è stata aggiunta la funzione di emulazione dei guasti.

Visualizzando il front panel è stata aggiunta sulla destra una sottosezione chiamata

Fault Manager in cui è stato inserito tutto l'occorrente per poter settare

adeguatamente i parametri relativi ai guasti. Partendo dall'alto e muovendosi verso

il basso, vi sono due slider (Fault Delay e Fault Duration) tramite cui vengono

selezionati i tempi di delay del fault rispetto al trigger e la durata effettiva del

guasto, successivamente vi è Faults ON/OFF tramite cui impostare o meno

l'abilitazione della simulazione di guasto: è importante notare che nel caso in cui

Faults ON/OFF non sia impostato su ON, l'emulatore è stato impostato in modo da

9

ignorare tutti i settaggi relativi ai faults, operando in condizioni di assenza di guasti.

Inoltre, tramite uno switch è possibile selezionare la tipologia di fault di interesse

(sia esso short o open) ed agendo su Faults iteration è possibile rendere iterativo il

presentarsi di malfunzionamenti così da poter simulare, ad esempio, situazioni di

guasti intermittenti.

Quindi, una volta selezionata la porta seriale a cui è connessa la board, scelto il

sensore da voler simulare ed impostati i parametri dei guasti, sarà sufficiente

utilizzare il bottone TRANSMIT per inviare i dati al microcontrollore che

provvederà poi ad elaborarli, l'accensione di un LED verde sull'interfaccia

indicherà la corretta riuscita della trasmissione. Non è stato però possibile inserire

la possibilità di simulare i guasti per l'accelerometro per le motivazioni spiegate nel

Capitolo 4 per cui, selezionandolo, la GUI nasconderà automaticamente le

impostazioni relative ai faults.

10

Capitolo 2: Firmware

Il firmware è strutturato secondo una logica di interrupt dove, al verificarsi di un

particolare evento la CPU sospende l'esecuzione del programma corrente per

servire l'interruzione mediante la chiamata della subroutine che esegue il compito

richiesto dall'interrupt., terminato il quale il processore riprende l'esecuzione delle

operazioni che stava precedentemente elaborando. Per la modifica del precedente

firmware sono state utilizzate librerie standard (messe a disposizione da AVR) oltre

che le librerie sviluppate in precedenza a cui sono state applicate alcune

ottimizzazioni per rendere più performante l'emulatore.

Le librerie custom sono state raggruppate in base alle funzionalità che inglobano:

1. UARTFunctions.h: contiene le primitive e le funzioni necessarie per

permettere la comunicazione tra il microcontrollore ed il pc.

2. DynamicStringFunctions.h: contiene la definzione di tipo e le funzioni

necessarie per poter utilizzare il tipo strutturato non predefinito “String”,

composto da una parte statica di lunghezza fissa più una parte dinamica a

lunghezza variabile.

3. TIMERFunctions.h: racchiude tutta la logica per la gestione dei tre timer

disponibili all'interno dell'ATMEGA328p, inglobando in funzioni tutti i

passaggi per settare i valori all'interno dei registri dei timer.

4. ADCFunctions.h: contiene le procedure per il funzionamento del

convertitore Analog-to-Digital

2.1 ISR TIMER0

L'interrupt del TIMER0 viene invocata non appena il contenuto del registro di

conteggio coincide con il valore memorizzato nel registro di arrivo, poiché il timer

in questione ha il compito di contare sia il tempo di delay che il tempo di durata11

effettiva del guasto, l'interruzione presenta un duplice comportamento descritto

dalla seguente illustrazione nell'ipotesi che fault_delay<650μs e quindi il TIMER0

parta con un prescaler di 64:

12

Illustrazione 3: Diagramma di flusso interrupt Timer0

2.1.1 Prescaler e Risoluzione

Mediante l'interfaccia grafica, l'utente potrà selezionare valori di delay e di durata

del fault che vanno, rispettivamente, da 30 a 2600μs per il primo slider e da 10 a

2600μs per il secondo. Risulta di fondamentale importanza notare che, poiché il

TIMER0 possiede unicamente registri ad 8bit, occorre selezionare il prescaler in

maniera adeguata per poter simulare guasti di delay e durata desiderata, inoltre i

due tempi in esame non devono essere necessariamente di uguale estensione e ciò

porta all'inserimento di istruzioni per il cambiamento del prescaler tra il conteggio

del delay e della duration, come è possibile osservare dall'illustrazione 2.

Senza l'impostazione di un prescaler, con il TIMER0 sarebbe possibile contare fino

a:

Un intervallo temporale estremamente piccolo. L'ATMega328p mette a

disposizione la possibilità di impostare il prescaler a valori quali 8, 64, 256, 1024 in

base alle esigenze derivanti dalla particolare applicazione. Utilizzando la relazione

precedentemente applicata:

Utilizzando questi due valori di prescaler, il timer potrà quindi contare l'intervallo

di tempo richiesto, in particolare, nel caso in cui il valore desiderato (sia esso per la

durata o il delay) sia inferiore al 650μs, il prescaler del TIMER0 verrà impostato

durante l'esecuzione del programma a 64, altrimenti a 256.

13

2.1.2 Maschere di Open e di Short

I faults vengono generati andando a definire ed applicare delle particolari bit mask

che condizionano i livelli logici dei pin del microcontrollore producendo, a livello

fisico, gli effetti descritti nel Capitolo 1. Considerato il fault di tipo OPEN, ad esso

è associato un'opportuna maschera (OPEN_mask) che ha come valore predefinito

0x3C che, una volta terminato il tempo di delay, viene modificato in 0x00 per tutta

la durata del fault ottenendo l'effetto desiderato per poi re-impostare la maschera al

valore predefinito. Il valore di partenza è stato calcolato determinando i pin

connessi alle gate dei mosfet presenti nell'Illustrazione 1, si ha infatti che è la porta

B a controllare i pin digitali che vanno da 8 a 13 e, poiché in condizioni di regolare

funzionamento dell'emulatore i pin D10, D11, D12 e D13 devono essere in ogni

caso alti – altrimenti non si avrebbe passaggio di corrente – osservando la struttura

del registro PORTB:

Considerata l'esecuzione di un fault di tipo OPEN nel caso iterativo, si ha un

andamento della maschera di questo tipo:

14

Illustrazione 4: Registro PORTB

Più immediato è il discorso nel caso del fault di tipo SHORT TO GROUND

poiché, in questo caso, l'obiettivo è alzare tutti i pin digitali (da D0 a D13). Per

realizzare questa tipologia di fault si ricorre quindi ad una maschera differente

(SHORT_mask) dal valore predefinito posto a 0x00 che, una volta terminato il

conteggio del tempo di delay, viene passato a 0xFF per tutta la durata del fault, e,

poiché la maschera contribuisce tramite un OR al risultato finale sui registri

PORTB (che pilota i pin D8 a D13) e PORTD (pin da D0 a D7) si ottiene la

saturazione dell'uscita dei sensori a 35 mA.

15

Capitolo 3: Ottimizzazioni

Utilizzare funzioni con un numero eccessivo di controlli e di istruzioni rallentava

più del consentito l'esecuzione dell'emulatore e quindi per eliminare alcune

assegnazioni dalle routine di interrupt dei timer, utilizzando il datasheet

dell'ATMEGA328p, sono stati impostati tutti in CLEAR TIMER ON

COMPARE MATCH (CTC) MODE in cui, al contrario dell'esecuzione in

modalità normale, porta automaticamente a zero il contatore una volta che il valore

di conteggio (contenuto nel registro TCNTx) coincide con il valore contenuto nel

registro OCRxA. Così facendo sono state eliminate tutte le operazioni software di

azzeramento del registro di conteggio dalle interrupt ottenendo un aumento della

velocità complessiva di esecuzione oltre all'alleggerimento delle routine. Il ridotto

tempo di esecuzione della routine di interrupt ha reso necessaria la ricalibrazione

dello scheduler interno.

3.1 Scelta dei fattori correttivi

Effettuando differenti misurazioni con l'oscilloscopio è stato determinato l'errore

medio nel calcolo dei tempi di delay e di durata dei faults sia nel caso di prescaler

impostato a 64 o 256. Sono emersi i seguenti risultati: selezionando un prescaler

pari a 64, il valore misurato del tempo di delay si discostava in media dal valore

ideale di 9μs mentre quello del tempo di durata di appena 3μs, con questi dati sono

stati calcolati i fattori correttivi utilizzando la seguente relazione:

16

Determinando così, al lancio del timer0, la necessità di sottrarre una costante pari a

4 al tempo di delay (nel caso di prescaler impostato a 64) e di sottrarre 1 alla durata

del fault. Le medesime misurazioni sono state effettuate selezionando il prescaler a

256, evidenziando uno scostamento del tempo di delay di 12μs rispetto all'idealità

ed un errore di 9μs nel tempo di durata, applicando la stessa relazione

precedentemente definita sono stati determinati i due fattori correttivi (stavolta

coincidenti): al lancio del timer andrà sottratto 1 ad entrambi i tempi.

Inseriti i fattori di correzione all'interno del codice sono state effettuate nuovamente

le misurazioni oggetto del test evidenziando un notevole miglioramento rispetto

alla situazione iniziale. Alla pagina seguente sono riportate le tabelle contenti le

misurazioni effettuate: nella prima tabella il prescaler a cui era impostato il timer è

pari a 64, nella seconda a 256.

17

Fault Delayideale

Fault Delayeffettivo precorrezione

Fault Delayeffettivo postcorrezione

FaultDurationideale

FaultDurationeffettivo precorrezione

FaultDurationeffettivo postcorrezione

100μs 108μs 100μs 100μs 103μs 101μs

200μs 209μs 200μs 200μs 203μs 200μs

300μs 310μs 299μs 300μs 302μs 300μs

400μs 408μs 399μs 400μs 404μs 400μs

500μs 508μs 497μs 500μs 500μs 500μs

600μs 608μs 597μs 600μs 604μs 600μs

Fault Delayideale

Fault Delayeffettivo precorrezione

Fault Delayeffettivo postcorrezione

FaultDurationideale

FaultDurationeffettivo precorrezione

FaultDurationeffettivo postcorrezione

700μs 708μs 697μs 700μs 704μs 696μs

800μs 808μs 801μs 800μs 804μs 792μs

900μs 905μs 905μs 900μs 908μs 910μs

1000μs 1015μs 1005μs 1000μs 1020μs 1010μs

1100μs 1115μs 1095μs 1100μs 1100μs 1100μs

1200μs 1215μs 1205μs 1200μs 1200μs 1200μs

1300μs 1315μs 1305μs 1300μs 1310μs 1300μs

1400μs 1415μs 1395μs 1400μs 1410μs 1400μs

1500μs 1515μs 1495μs 1500μs 1510μs 1500μs

2000μs 2015μs 1995μs 2000μs 2010μs 2000μs

2600μs 2605μs 2605μs 2600μs 2610μs 2600μs

18

Capitolo 4: Risultati sperimentali

La parte finale del lavoro ha riguardato la caratterizzazione delle performances

dell'emulatore in termini di fault injection.

Il primo canale mostra sull'oscilloscopio la corrente dei sensori, misurata tramite

una sonda di corrente, il secondo canale è mostrato a video collegando una sonda di

tensione al pin D2 ed evidenzia gli impulsi di inizio frame, il terzo canale mostra

gli impulsi relativi alla trasmissione dei dati da parte dei sensori mentre il quarto ed

ultimo canale permette di vedere l'effetto dei fault di tipo OPEN.

Per mostrare l'effetto dei fault sui sensori, occorrerà fornire le informazioni

necessarie alla comprensione del loro funzionamento in condizioni di normali.

19

4.1 KMI22 Philips – VDA

Il KMI22 prodotto dalla Philips è un sensore di wheel speed a tre livelli di corrente

che produce in uscita un segnale di corrente codificato secondo il protocollo

Manchester. In particolare, si avrà un impulso di 28 mA in corrispondenza di ogni

presenza di un dente della ruota e quindi, la distanza tra due impulsi di questo tipo

permetterà di ricavare indirettamente la misura della velocità. Si susseguiranno poi

impulsi di 14 mA, su una base di 7mA, codificanti informazioni di diagnostica e, in

caso di bassa velocità, codificheranno anche il bit di parità. E' importante notare

che la quantità di informazioni inviate è inversamente proporzionale alla velocità.

20

Tutti gli impulsi di dato hanno una durata temporale pari al pulse time (che puo'

assumere valori pari a 20, 25 o 30μs) , mentre l'impulso in corrispondenza dei denti

ha durata pari a due volte il pulse time.

La maggior parte dei test sui fault verrà fatta su questo sensore, in realtà, essendo

tutti i dati relativi alla simulazione di un fault codificati all'interno della stringa del

protocollo sempre allo stesso modo (indipendentemente dal particolare sensore) ,

risulta poco interessante il test esaustivo su ogni sensore.

4.1.2 Funzionamento in condizioni ideali

In seguito sono mostrate tipiche situazioni di funzionamento prive di guasti del

KMI22:

Si puo' notare come, in corrispondenza dell'impulso sul canale 2 codificante la

presenza di un dente della ruota, l'uscita sia un impulso di corrente di 28 mA

21

Illustrazione 5: pulse time = 25μs, velocità = 80 km/h

mentre, all'occorrenza degli impulsi di dato, l'andamento dell'uscita sia un insieme

di impulsi di 14mA alternati ad una base di 7mA.

Si nota quindi che, come descritto nella trattazione precedentemente, aumentando i

km/h il sensore riuscirà ad inviare un numero minore di bit di dato.

4.1.3 Funzionamento in condizioni di fault

Inserendo un fault di tipo OPEN si ha una modifica dell'uscita prodotta dal sensore,

in particolare, per tutta la durata del guasto, la corrente di output deve essere pari a

0.

22

Illustrazione 6: pulse time = 25μs, velocità = 300μs

Nell'Illustrazione 6 è mostrato il caso di un fault con delay pari a 100μs e durata

pari a 80μs, è importante notare che il calcolo del delay non parte dal primo fronte

alto del segnale bensì dall'inizio della frame, ovvero un pulse time (25μs) prima.

Per quanto riguarda la misura della durata del fault, in questa particolare

simulazione, il guasto risulta durare 2μs in più, ma ciò è dovuto alla bassa

risoluzione del timer calcolabile mediante la semplice relazione:

Ricordando che in questo caso il prescaler associato alla duration è pari a 64 poiché

la durata impostata è minore di 650μs.

23

Illustrazione 7: fault delay = 100μs, fault duration = 80μs

Un'ulteriore simulazione è quella realizzabile aumentando la velocità a 270 km/h ed

impostando il delay del fault a 400μs e la durata dei fault a 700μs (utilizzando

quindi un prescaler impostato a 256). Con questi dati, l'uscita sulll'oscilloscopio è:

24

Illustrazione 8: Misura della durata del guasto

Si ha che ad alte velocità gli speed pulse sono molto ravvicinati e dal primo fronte

d'onda vengono calcolati i 400μs di delay.

Riducendo a 100μs il delay e la velocità ed impostando la duration a 50μs,

simulando dei fault di tipo OPEN iterativamente si ottiene il seguente risultato:

In questa situazione non è avvenuto il corretto tracciamento della forma d'onda

mentre è però corretta l'uscita del sensore: la corrente deve essere 0 mA in

corrispondenza dei fault.

I guasti di tipologia SHORT producono la saturazione dell'uscita a 35 mA, di

seguito è riportata una simulazione del loro funzionamento con velocità a 67 km/h,

delay a 30μs e durata a 300μs.

25

4.2 INFINEON TLE4942

26

Illustrazione 9: fault delay = 70μs, fault duration = 300μs

L'INFINEON TLE4942 è un sensore a due livelli di corrente in cui la distanza

temporale tra due fronti di salita degli impulsi fornisce una misura indiretta della

velocità mentre eventuali informazioni sono trasmesse mediante la lunghezza degli

impulsi alti, di durata temporale multipla del pulse time.

Un segnale di warning è codificato con un impulso di durata temporale pari ad un

pulse time, la marcia in avanti è tradotta in un impulso di durata temporale pari a

due pulse time, mentre la marcia indietro con quattro pulse time.

4.2.1 Funzionamento in condizione di fault

Oltre che sul KMI22, le condizioni di fault sono state testate anche sul sensore

Infineon, di seguito sono riportati i risultati di alcune simulazioni.

27

Una simulazione di estremo interesse è quella che prevede la selezione di fault

delay e di fault duration ai minimi valori messi a disposizione dall'emulatore

(rispettivamente 30μs e 10μs) e studiarne i risultati ad esempio in caso di fault di

tipo SHORT. E' importante notare che al di sotto delle due quantità specificate

l'ATMega328p non garantisce una durata ripetibile a causa del tempo di esecuzione

delle routine di interrupt.

28

Illustrazione 10: fault delay = 1500μs, fault duration = 1000μs

Si puo' notare che nonostante le condizioni limite, il funzionamento dell'emulatore

è prossimo all'idealità.

4.3 AIS1200PS

E' necessario trattare a parte l'accelerometro AIS1200PS sviluppato dalla

STMicroeletronics poiché, al contrario degli altri sensori, richiede la produzione di

impulsi della durata di 4μs obbligando quindi ad una riduzione all'essenziale delle

operazioni necessarie alla gestione dell'interruzione del timer2 che ne descrive il

comportamento. Il pattern caratteristico prodotto dal sensore ha un periodo di

500μs dove solo nei primi 104μs si hanno delle transizioni che definiscono il valore

di 13 bit:

• S0 ed S1 sono start bit.

• In D0 – D9 è codificato il valore dell'accelerazione.

• L'ultimo bit è di parità.

Per i restanti 396μs la corrente in uscita rimane costante a 7 mA.

29

Illustrazione 11: fault delay = 30μs, fault duration = 10μs

Tutti i tentativi di inserire la possibilità di fault injection su questo tipo di sensore

hanno portato a ripercussioni negative sul funzionamento in modalità priva di fault:

essendo il timing particolarmente critico per questo sensore infatti, qualsiasi tipo di

emulazione dei fault comportava una complessità computazionale non sostenibile

per il micro. Si è dunque deciso di disabilitare la modalità di emulazione dei fault

per l'accelerometro.

30

Conclusioni

Il lavoro svolto per la costruzione di un modulo di fault-injection da aggiungere

all'emulatore ASD350E pre-esistente, ha portato all'affrontare un gran numero di

problematiche relative allo studio ed alla comprensione di un progetto sviluppato

da terzi oltre alle difficoltà di sviluppo vere e proprie del plug-in,

Dopo aver approfondito la conoscenza sul funzionamento e sulle potenzialità del

microcontrollore montato sulla board utilizzata, al candidato è stato chiesto di

sviluppare la parte firmware del componente utilizzando l'IDE Atmel Studio e la

GUI ricorrendo al software LabView in modo tale da permettere al plug-in di essere

perfettamente compatibile con gli output della versione precedente dell'interfaccia

grafica dell'emulatore.

Nella fase finale di test bench sono emerse le potenzialità del modulo e la validità

delle simulazioni di guasto effettuabili utilizzandolo, sebbene non sia stato

possibile renderlo utilizzabile nel caso dell'accelerometro dove i risultati ottenuti

non hanno corrisposto le aspettative.

Durante lo sviluppo del modulo sono state fornite direttive riguardo a modifiche

dell'emulatore pre-esistente per gli sviluppi futuri di nuove tipologie di sensori e

plug-in.

31

Bibliografia

[1] Roberto Galizia, “Sviluppo ed ottimizzazione firmware e software di un emulatore

di accelerometer e wheel speed sensor per applicazioni airbag ed ESP”, Napoli

2013.

[2] Atmel ATMEGA328p, DATASHEET

[3] Infineon Technologies TLE4942 DATASHEET

[4] Philips KMI22 VDA3level, DATASHEET

[5] STMicroelectronics AIS1200PS PSI5, DATASHEET

32