Progetto del quadro comandi di un automobile. Progetto in linguaggio VHDL Corso di Calcolatori Elettronici M

Progetto del quadro comandi di un automobile Progetto in linguaggio VHDL Corso di Calcolatori Elettronici M Prof. Giovanni Neri Prof. Stefano Mattoccia A cura di: Erica Barone Luca Del Bolgia Filippo Gregori

INDICE SPECIFICHE... 6 Parte 1: gestione delle grandezze meccaniche... 6 Parte 2: gestione delle luci e delle spie relative... 6 Parte 3: gestione della sicurezza e delle spie rimanenti... 6 SOLUZIONE... 8 Parte 1... 8 Timer... 10 Component... 10 Architecture... 10 ContaKmTachimetro... 11 Component... 11 Architecture... 11 Contagiri... 13 Component... 13 Architecture... 14 Testbench... 15 Test Effettuati... 16 Parte 2... 19 Gestione delle frecce e del lampeggiante (modulo VHDL : Frecce.vhd)... 21 Component... 21 Architecture... 21 Testbench... 27 2

Gestione delle luci anteriori(modulo VHDL : Luci_Anteriori.vhd)... 27 Component... 27 Architecture... 28 Testbench... 33 Gestione delle luci posteriori(modulo VHDL : Luci_Posteriori.vhd)... 34 Component... 34 Architecture... 34 Testbench... 36 Parte 3... 37 Gestione della cintura di sicurezza... 37 Component... 37 Architecture... 38 Testbench... 39 Gestione dell indicatore del livello di benzina... 40 Component... 40 Architecture... 41 Testbench... 43 Gestione dell indicatore della temperatura dell acqua... 44 Component... 44 Architecture... 44 Testbench... 45 Gestione delle spie... 46 Component... 46 Architecture... 47 3

Testbench... 47 Quadro Comandi... 49 Component e Architecture... 49 Testbench... 51 4

5

SPECIFICHE Parte 1: gestione delle grandezze meccaniche Questo primo blocco concettuale del nostro sistema deve simulare la misura della velocità e della distanza percorsa dall'automobile. Supponiamo quindi di avere un sistema che genera un impulso ogniqualvolta la ruota ha completato un giro. Moltiplicando la lunghezza della circonferenza della ruota per il numero di impulsi registrati avremo la misura della distanza percorsa. Se poi utilizziamo la misura del tempo effettivo che ci è offerta dall'onda quadra del clock, possiamo facilmente dedurre la velocità del nostro sistema e realizzare un normale tachimetro. Col medesimo funzionamento possiamo realizzare un contagiri per il nostro motore: avremo sempre un segnale che proviene dall'albero motore e segnala quando è terminato un giro. Contando i giri in un determinato periodo di clock avremo una misura abbastanza accurata del numero di giri al minuto del nostro motore. Parte 2: gestione delle luci e delle spie relative Questa parte del nostro sistema si occupa di gestire l'azionamento delle luci di posizione e l'attivazione dei segnali opportuni, luminosi e sonori, per avvertire l'autista che il comando è andato a buon fine. In particolare possiamo individuare una serie di componenti che dovranno essere gestiti in questa parte: luci di posizione, anabbaglianti e abbaglianti: a seguito del comando dell'autista è necessario attivare il comando che attiva l'accensione dei fari. Sarà necessario predisporre il sistema per attivare le spie opportune (verde: anabbaglianti / azzurra: abbaglianti) indicatori di direzione (frecce) e luci di emergenza (lampeggianti): sarà necessario discriminare tra la freccia destra e sinistra attivando le luci in modo intermittente con frequenza opportuna. Alla spia luminosa è collegato un segnale acustico di ticchettio. Ricordiamo anche che bisognerà attivare una spia intermittente verde. Fendinebbia e retronebbia: il comportamento è simile a quello delle luci di posizione considerando il fatto che,nella nostra simulazione,il bottone dei fendinebbia e retronebbia invierà un impulso. Stop: queste luci devono essere attivate quando viene frenata la macchina. Appena il freno viene rilasciato queste luci devono essere spente. Luce posteriore retromarcia: quando siamo in retromarcia dobbiamo attivare questa luce bianca posteriore per avvisare gli altri automobilisti che stiamo andando indietro. Parte 3: gestione della sicurezza e delle spie rimanenti Quest area del progetto vuole coprire tutti i servizi relativi alla gestione della sicurezza dell'autista e dell'automobile. In particolare possiamo suddividere ulteriormente quest area del sistema: Gestione della cintura di sicurezza: se viene rilevato un peso sul sedile e viene superata una certa velocità, viene accesa la relativa spia e deve essere attivato un segnale acustico che ricorda 6

all'autista di allacciare la cintura di sicurezza. Nel momento in cui questa viene allacciata il segnale acustico deve interrompersi. Segnali provenienti dai sensori di benzina e acqua, olio, batteria, airbag e impianto frenante. Il segnale proveniente dal serbatoio deve indicare all'autista qual è il livello di benzina presente nella macchina, attivando una spia opportuna se il livello scende sotto il livello di soglia (se siamo, cioè, in riserva ), oltre ad un segnale acustico nel momento in cui si raggiunge la soglia della riserva. Per quanto riguarda l acqua, deve essere fornita al guidatore una stima della temperatura, con l accensione di una spia se la temperatura è eccessivamente elevata. Per l'olio, l airbag, la batteria e il freno a mano dobbiamo rilevare il segnale proveniente dagli opportuni sensori e attivare le spie che segnalano all'autista il problema. 7

SOLUZIONE Parte 1 In fase di definizione delle specifiche e nella successiva fase di analisi è stata individuata quest area di progetto che può essere sviluppata, così come le altre due, in modo indipendente, senza però perdere di vista la necessaria integrazione finale di tutte e tre le parti. Ricordiamo subito che questa parte del progetto si propone di gestire la misura della velocità della macchina in Km/h, del numero di giri del motore (RPM/min o giri al minuto) e dei chilometri percorsi nel corso di un viaggio. Definiamo in modo più preciso il nostro scenario di operazione: i sensori presenti in più parti della nostra automobile (in questo caso il sensore presente sulla candela del motore e su una delle due ruote anteriori) inviano dei segnali al sistema. Questi segnali devono essere campionati ed elaborati opportunamente dalla nostra rete in modo da offrire all esterno una rappresentazione consona delle grandezze da misurare. I segnali in uscita devono essere rinfrescati con una certa frequenza, che tuttavia non ha la necessità di essere istantanea ma deve rispettare solamente un vincolo legato al tempo di reazione medio di un autista (700 ms). Oltre a questo è necessario mantenere una memoria della misura delle tre grandezze in gioco (velocità, chilometri, numero di giri) durante il funzionamento del sistema, in modo che le misure siano consistenti con la realtà. Per realizzare questo abbiamo deciso di sviluppare tre moduli distinti all interno di questa parte del progetto. Questo per ovvie ragioni di fattorizzazione del codice e maggiore estendibilità e riusabilità dei singoli componenti. Questi concetti, mutuati dal contesto dell ingegneria del software, hanno un interessante applicazione nell ambito del codice VHDL, perché permettono di ricorrere a un utile paradigma di progettazione anche per i sistemi hardware. I tre moduli interni a questa frazione del progetto, che andremo ad analizzare in fino nel corso della relazione sono: Timer; TachimetroContaKM; Contagiri. 8

Figura 1: Visione di alto livello del blocco per la misura delle grandezze meccaniche Figura 2: Dettaglio del componente Mechanic con tutti i sottocomponenti 9

Timer Component Il Timer è il modulo VHDL più semplice di questa porzione del progetto. La sua funzione fondamentale è di mantenere un semplice conteggio dei periodi di clock e di fare scattare in modo opportuno il refresh della rappresentazione delle grandezze meccaniche all esterno. Dando uno sguardo al pin-out di questo componente (fig.3) notiamo che oltre all ingresso di clock troviamo altri due ingressi (OkGiri e OkTachimeter): questi segnali provengono dagli altri due componenti e servono per comunicare al Contatore che il segnale di refresh è stato campionato dagli altri due componenti e che le relative uscite verranno aggiornate. L unico segnale di uscita di Contatore è il segnale Leggi che viene connesso agli opportuni ingressi di TachimetroContaKM e Contagiri e serve per indicare a questi moduli di aggiornare le uscite. Figura 3: Pin-out del componente Timer Architecture Per quanto riguarda lo sviluppo comportamentale di quest unità abbiamo preferito ricorrere ad un unico processo (ConteggioPeriodo) che presenta nella sensitivity list tutti i segnali di ingresso del Timer. In particolare, analizzando il codice VHDL, notiamo che in caso di fronte di salita del clock viene incrementata una variabile interna (periodiclock) che tiene traccia dei periodi di clock trascorsi dall ultimo refresh delle uscite. Una volta che questa variabile raggiunge il valore corrispondente a 500 ms ( secondo), viene attivato il segnale Leggi e il contatore dei periodi di clock viene resettato. Lo stesso processo viene risvegliato anche nel caso in cui sia attivo il segnale Leggi e siano attivi anche i segnali OkTachimeter e OkGiri. Infatti, in questa particolare situazione devo abbassare il segnale Leggi, poiché Contagiri e Tachimeter hanno già aggiornato le uscite e devono attendere lo scatto successivo del Timer per fare un ulteriore refresh. Notiamo una particolarità di questo codice, un accorgimento: l uscita Leggi deve essere abbassata a 0 quando OkTachimeter e OkGiri valgono 1 e lo stesso segnale Leggi deve valere 1. Per avere quest ultima informazione è necessario poter leggere all interno del processo l effettivo valore del segnale Leggi, che però è un uscita. Per ovviare a questa difficoltà abbiamo inserito una variabile interna di tipo STD_LOGIC (LeggiInternal). Il valore di questa variabile viene sempre assegnato al segnale di uscita Leggi prima della sospensione del processo. Questo fa sì che i valori di Leggi e LeggiInternal all uscita del processo siano sempre identici e giustifica la condizione if (LeggiInternal= 1 ). 10

Figura 4: Codice dell'architecture del Timer ContaKmTachimetro Component Il secondo componente realizzato in questa parte del progetto si occupa di effettuare il conteggio dei chilometri percorsi e di misurare la velocità del veicolo. Questa funzione del componente viene rispecchiata dai segnali in uscita: Tachimetro è un segnale composto da 8 bit che serve a misurare la velocità dell automobile in Km/h, mentre ContaKm (10 bit) rappresenta il numero di chilometri percorsi. Un ulteriore segnale in uscita è OkTachimeter, che, come già esposto in precedenza serve a sincronizzare ContaKmTachimetro con il Timer. Per quel che riguarda i segnali di ingresso evidenziamo il segnale ImpRuota, segnale che codifica la fine di un giro completo di una delle due ruote anteriori, e Leggi, segnale proveniente dal componente Timer necessario per aggiornare i segnali di uscita del componente. Figura 5: Pin-out del componente ContaKMTachimetro. Architecture Le due funzioni svolte dal componente (Contachilometri e Tachimetro) sono strettamente interrelate e si è deciso di gestire il tutto ricorrendo ad un unico processo. In particolare l intero algoritmo si basa sul segnale 11

ImpRuota, proveniente dal sensore presente sulla ruota che comunica la fine di un giro completo. Ad ogni giro vengono incrementate due variabili aggiungendovi la lunghezza della ruota: girieffettivi e mpercorsi. mpercorsi serve per tenere traccia dei metri effettivamente percorsi, in modo tale che quando questa variabile raggiungerà il valore 1000 vorrà dire che l automobile ha percorso un intero chilometro e verrà incrementata la variabile intera km percorsi che servirà per aggiornare l uscita ContaKm. girieffettivi serve per misurare i metri percorsi dall auto nell arco di un secondo (ossia tra un segnale di lettura e l altro). In questo caso ci troviamo di fronte ad una problematica di rappresentazione dei dati: per portare una misura da metri al secondo in chilometri all ora basterebbe moltiplicare il valore numerico per 3,6 ( ) ma questo non è permesso dal linguaggio VHDL. Per risolvere questo problema e portare il valore della velocità così misurato in Km/h abbiamo adottato la soluzione seguente: il dato in m/s viene moltiplicato per 3600, in modo tale da avere una stima dei metri percorsi in un ora (m/h). Poi, successivamente questa grandezza viene convertita nel formato STD_VECTOR utilizzando l apposita funzione di conversione (CONV_STD_LOGIC_VECTOR) e una variabile a 17 bit. Per poi riportare il valore in Km/h abbiamo deciso di considerare solamente i 7 bit più significativi del dato ( ). Utilizzando quest accorgimento otteniamo una stima decisamente accettabile della velocità in Km/h, in modo tale che possa essere rappresentata nel quadro comandi di qualunque automobile. Sempre con l obiettivo di comunicare con l esterno abbiamo fatto ricorso al segnale OkTachimeter e, come già col Timer, alla variabile InternalOk che serve per leggere il valore della variabile di uscita all interno del processo. Infine si è deciso di definire la lunghezza della ruota (LUNGRUOTA) come parametro costante, in modo che il codice possa essere riutilizzabile nel caso di automobili con ruote di lunghezza differente. 12

Figura 6: Codice dell'architecture del ContaKMTachimetro Contagiri Component Questo componente s incarica della gestione dell ultima problematica rimasta aperta nell ambito della misurazione delle grandezze meccaniche: il calcolo del numero dei giri al minuto del motore. In particolare, analizzando il pin-out del componente (fig. 7) ritroviamo molti segnali che ne suggeriscono la funzione. ContaGiri è un segnale composto da 13 bit (segnale di tipo STD_VECTOR) con la funzione di rappresentare il numero di giri al minuto del motore. Questo tipo di rappresentazione è, generalmente, quello usato in tutti i veicoli e serve come supporto al cambio. Il segnale OkGiri (così come OkTachimeter nel componente precedente) serve per realizzare la sincronizzazione tra il componente Timer e il componente Contagiri, in modo tale da disciplinare il refresh del valore portato in uscita dal sistema. Per quanto riguarda i segnali in ingresso notiamo l analogia con il componente ContaKMTachimetro, in quanto abbiamo in ingresso un segnale che indica la fine di un giro completo dell albero motore (ImpMotore) e il segnale proveniente dal Timer che spinge il componente ad aggiornare le uscite (Leggi). 13

Figura 7: Pin-out del componente Contagiri Architecture Per quanto riguarda il comportamento di questo componente possiamo ricollegarci al Tachimetro con cui possiamo notare una serie di naturali analogie, in quanto analoga è l operazione di misurazione che deve essere realizzata. Anche qui abbiamo deciso di gestire ogni cosa utilizzando un processo unico che è sensibile ai segnali Leggi e ImpMotore. Quest ultimo segnale rappresenta il fuclro fondamentale dell algoritmo: un fronte di salita di ImpMotore comporta l incremento della variabile contmigliaia che serve appunto a misurare le migliaia di giri in un minuto. A questo proposito abbiamo dovuto affrontare un ulteriore problematica di rappresentazione del dato: il numero di giri così misurato è il numero di giri del motore in un secondo (periodo dopo il quale viene attivato il segnale di lettura dal Timer), ma il nostro obiettivo è ottenere il numero di giri al minuto. Ciò comporta l applicazione della seguente formula per effettuare le conversioni tra valore misurato e valore rappresentato:. Questo tipo di operazione è più semplice rispetto a quella realizzata nel componente ContaKmTachimetro, in quanto non è necessario effettuare alcun tipo di divisione. Innanzi tutto ogni volta che si presenta un fronte di salita di ImpMotore la variabile contmigliaia viene incrementata di 1. Quando arriva il segnale di refresh delle uscite proveniente dal Timer (Leggi) la variabile contmigliaia viene moltiplicata per 120 e convertita nel tipo STD_LOGIC_VECTOR e assegnata all uscita ContaGiri. Questo tipo di meccanismo permette di portare sull uscita ContaGiri il numero di giri effettuati dal motore in un minuto rispettando i vincoli imposti dal linguaggio VHDL. 14

Figura 8: Codice dell'architecture del Contagiri Testbench Analizzando i test effettuati per verificare il funzionamento dell intero componente nel suo complesso possiamo osservare innanzi tutto che si tratta di simulazioni molto semplici caratterizzate, per la natura del componente, da tempi di simulazione piuttosto lunghi. In effetti per verificare il corretto funzionamento del componente è sufficiente andare a realizzare 3 processi periodici (Clock, Giri e GiriRuota) che simulano rispettivamente il clock del sistema, l impulso periodico proveniente dall albero motore e l impulso periodico proveniente da una delle due ruote anteriori. Esplorando più in fino il comportamento di questi tre processi osserviamo che mentre il clock deve presentarsi come un onda quadra caratterizzata da un periodo costante nel tempo, i segnali ImpRuota e ImpMotore presentano un andamento periodico ma impulsivo, in quanto il segnale non rimane alto per un lungo periodo ma solo per un brevissimo istante (preso, nelle nostre simulazioni, pari a 1 ns). Oltre a ciò questi due segnali presentano una frequenza variabile in funzione della velocità della macchina e del numero di giri effettivo del motore. Proprio questi due parametri, la frequenza dei giri del motore e la frequenza di rotazione della ruota anteriore, sono quelli che andremo a modificare nella fase di test per verificare che le uscite rilevate corrispondano a quelle attese (variabili periodogiri e periodoruota). Osserviamo che un valore Y di periodoruota determina un numero di impulsi. Ottenuto il numero di impulsi proveniente dalla ruota per ottenere la velocità in Km/h è sufficiente applicare la formula. In particolare va moltiplicato per 2 perché abbiamo un tempo di campionamento pari a mezzo secondo e in tal modo otteniamo la stima del numero di impulsi in un secondo. Successivamente per ottenere il numero dei metri percorsi in un secondo è sufficiente moltiplicare per la lunghezza della ruota 15

espressa in metri. Infine per convertire la velocità da m/s a Km/h basta moltiplicare per il fattore di conversione pari a 3.6. Quindi con periodoruota pari a circa 72 ms ci aspettiamo una velocità misurata di circa 100 Km/h. Discorso analogo può essere sviluppato per periodogiri, ottenendo la relazione. Alla luce di queste relazioni andiamo ad analizzare i test effettuati sul componente. Test Effettuati Abbiamo già osservato che gli unici due ingressi che andremo a modificare sono periodoruota e periodogiri. Inizialmente poniamo questi due ingressi a 0 per resettare il sistema di testing. Successivamente andiamo ad imporre una serie di valori in ingresso, mantenendoli per n tempo arbitrario, sufficiente però a far modificare le uscite. Figura 9: Codice dei test effettuati Possiamo osservare come nel commento a fianco del codice abbiamo indicato il valore atteso della simulazione. Nel seguito andiamo a mostrare una serie di grafici che rappresentano il risultato della simulazione ottenuto ricorrendo all applicativo ISim. 16

Figura 10: Simulazione nell intervallo 0-4 secondi Aiutandoci con i test esposti sopra notiamo come l ingresso venga cambiato dopo 2 secondi dall inizio della simulazione, ma le uscite riportano il valore solo dopo 500 ms in accordo con i tempi di refresh del nostro sistema. Notiamo che ci aspetteremmo un valore di 1000 giri/minuto e di 70 Km/h ed in effetti, a meno delle approssimazioni dovute alle cifre significative considerate nel valore del periodo, ci avviciniamo di molto al valore stimato. Figura 11: Simulazione nell'intervallo 4-8 secondi Anche in questo caso i test rispecchiano i valori attesi delle uscite. Notiamo che in questo caso abbiamo provato a imporre il valore 0 sugli ingressi e questo, dopo 500 ms viene rilevato sulle uscite che 17

diminuiscono gradualmente fino a raggiungere il valore atteso. Discorso esattamente uguale vale per le simulazioni successive di cui riportiamo i grafici per completezza. Figura 12: Simulazione nell'intervallo 8-12 secondi Figura 13: Simulazione nell'intervallo 12-16 secondi 18

Parte 2 Questa parte del progetto descrive la soluzione riguardante l accensione delle luci esterne all auto; in particolare: Le frecce: i segnali che verranno inviati ai sistemi fisici rappresentanti le frecce,ad esempio le luci arancioni esterne(sia anteriori che posteriori), oppure le spie interne; Le luci anteriori: tutti segnali che verranno inviati ai sistemi fisici anteriori, sia esterni che interni(luci e spie fendinebbia,luci e spie dei fari). Le luci posteriori: tutti i segnali che verranno inviati ai sistemi fisici posteriori, sia esterni che interni(luce freni, luce retromarcia, luci e spie retronebbia). Figura 14: Componente Lights 19

Per rendere il tutto più modulare e analizzabile singolarmente(testbench separati), il sistema è stato suddiviso in tre parti fondamentali: 1- Gestione delle frecce e del lampeggiante(modulo VHDL : Frecce.vhd); 2- Gestione delle luci anteriori(modulo VHDL : Luci_Anteriori.vhd); 3- Gestione delle luci posteriori(modulo VHDL : Luci_Posteriori.vhd). Figura 15: Dettaglio del componente Lights e sottocomponenti 20

Gestione delle frecce e del lampeggiante (modulo VHDL : Frecce.vhd) Component Figura 16: Sottocomponente Frecce Descrizione segnali: - Ingressi: attuatore_destra:segnale che rappresenta la volontà di accendere la freccia destra. attuatore_sinistra:segnale che rappresenta la volontà di accendere la freccia sinistra. attuatore_lampeggiante:segnale che rappresenta la volontà di accendere contemporaneamente entrambe le frecce. clock:clock del sistema. sensore_start:segnale di accensione dell auto(0 auto spenta, 1 auto accesa). - Uscite: freccia_destra: segnale inviato alla luce e alla spia della freccia destra; inoltre attiverà anche il meccanismo fisico che produrrà il ticchettio. freccia_sinistra: segnale inviato alla luce e alla spia della freccia sinistra; inoltre attiverà anche il meccanismo fisico che produrrà il ticchettio. Architecture In questo modulo sono state implementate le varie situazioni che si possono cogliere nei casi in cui: A) Si abbia un segnale alto per la freccia destra ma non per il lampeggiante e per la freccia sinistra. B) Si abbia un segnale alto per la freccia sinistra ma non per il lampeggiante e per la freccia destra. C) Si abbia un valore uguale per i segnali di freccia sinistra e destra, e il valore del lampeggiante sia 0. D) Si abbia un segnale alto per il lampeggiante e una qualsiasi configurazione delle due singole frecce. Inoltre per ogni diversa situazione appena descritta si è dovuto controllare lo stato in cui ci si trovava nel momento di salita del segnale(come vedremo più avanti). 21

A)Segnale alto per la freccia destra Configurazione d ingresso: destra sinistra lampeggiante start clock 1 0 0 X X Con questa configurazione di ingresso il compito del blocco è quello di trasformare il segnale destra, fisso ad uno, in un segnale periodico, che possa essere inviato alle luci e spie delle frecce. Spie frecce: (destra attiva) Tutto questo è condizionato dal valore del segnale start, che se posto a zero(auto spenta) deve porre il segnale inviato alle luci e alle spie a zero. 22

Come è possibile notare dal codice, per l implementazione del caso appena descritto si utilizzano alcune variabili temporanee: freccia_destra_var: descrive lo stato della freccia destra all interno del sistema. freccia_sinistra_var:descrive lo stato della freccia sinistra all interno del sistema. turno: variabile utilizzata per l inizializzazione dello stato ogniqualvolta si passa da una configurazione ad un altra. Questa variabile è molto importante poiché risolve i problemi che scaturivano da sequenze di ingressi diversi da quelli normali(come vedremo meglio nel caso del lampeggiante). count: contatore utilizzato per far scattare la freccia in output; poiché il clock ha una frequenza molto alta nei confronti della velocità con cui si vuole che i segnali delle frecce si modifichino, si utilizza una costante che rappresenta quanti clock si devono contare prima della modifica delle frecce. La costante è definita all inizio del Behavioral: B)Segnale alto per la freccia sinistra Configurazione d ingresso: destra sinistra lampeggiante start clock 0 1 0 X X Spie frecce: (sinistra attiva) 23

Questo caso è analogo al precedente, l unica differenza è la freccia interessata(sinistra invece che destra). Il segnale start in questa configurazione ha lo stesso significato del caso precedente. C)Stessi valori per freccia destra e sinistra Configurazione d ingresso: (tra parentesi l altra possibile configurazione) destra sinistra lampeggiante start clock 1(0) 1(0) 0 X X Questi casi rappresentano: 11-che si abbia un errore in ingresso(si ipotizza che non si possano avere entrambi i segnali ad 1) 00-le frecce debbano essere spente. Entrambe le configurazioni vengono risolte tramite questa sequenza di istruzioni: 24

D)Segnale alto per il lampeggiante Configurazione d ingresso: destra sinistra lampeggiante start clock X X 1 X X Questa configurazione verrà attivata se le frecce devono essere entrambe accese, e deve accadere anche se l auto è spenta. Quindi il segnale start non condizionerà l attivazione delle frecce: Spie frecce: (lampeggiante attivo) È possibile notare che si utilizza, per l assegnazione dei valori alle frecce, il valore di una sola delle due. In questo modo è possibile risolvere problemi dovuti a sequenze di configurazioni di ingresso del tipo: il lampeggiante viene attivato quando una freccia è attiva; possibile alternanza delle due frecce(non si accenderebbero contemporaneamente ma alternate). 25

Questa problematica era già stata risolta con l utilizzo dei turni ; infatti al primo ingresso nel blocco di istruzioni condizionati da lampeggiante=1, il lampeggiante ottiene i diritti per utilizzare e modificare le frecce, e reinizializza lo stato; il count posto a zero(e reinizializzazione) è molto importante poiché si evita di avere un problema di ritardi nell uscite: se non fosse stato azzerato, e all attivazione del lampeggiante un altra freccia avesse già utilizzato il contatore(count<clock_moltiplicator), allora il sistema sarebbe rimasto nello stato precedente fino a count=clock_moltiplicator(ritardo nelle uscite/incoerenza ingresso uscita). Comunque si è pensato di lasciare anche la prima soluzione al problema poiché non appesantisce il sistema. 26

Testbench Il test effettuato per il modulo riguardante le frecce è stato il seguente: Figura 17: Testbench del Sottocomponente Frecce Dal test è stato controllato che il modulo funzionasse correttamente, ed è possibile notare che le frecce prese singolarmente vengono disattivate nel caso che il segnale sensore_start sia pari a zero; invece se il segnale del lampeggiante è attivo, le frecce vengono attivate entrambe anche se il sensore_start è a zero. Gestione delle luci anteriori(modulo VHDL : Luci_Anteriori.vhd) Component Descrizione segnali: Figura 18: Sottocomponente Luci_Anteriori - Ingressi: attuatore _luci_di_posizione: segnale che rappresenta la volontà di accendere le luci di posizione. attuatore _abbaglianti: segnale che rappresenta la volontà di accendere gli abbaglianti. attuatore _anabbaglianti: segnale che rappresenta la volontà di accendere gli anabbaglianti. attuatore _down: segnale che rappresenta la volontà di abbassare l altezza degli anabbaglianti. attuatore _up: segnale che rappresenta la volontà di alzare l altezza degli anabbaglianti. 27

sensore_sportello_aperto:segnale che rappresenta l apertura dello sportello dalla parte del conducente. attuatore_fendinebbia: segnale che rappresenta l attivazione o la disattivazione dei fendinebbia; segnale ad impulsi. attuatore_freccia_destra: segnale che rappresenta la volontà di accendere la freccia destra. attuatore_freccia_sinistra: segnale che rappresenta la volontà di accendere la freccia sinistra. sensore_start: segnale di accensione dell auto(0 auto spenta, 1 auto accesa). - Uscite: altezza_anabbaglianti: segnale utilizzato per impostare l altezza degli anabbaglianti. luci: segnale di controllo per indicare quali luci devono essere attivate. fendinebbia_anteriore_destro: segnale inviato al fendinebbia anteriore destro. fendinebbia_anteriore_sinistro:segnale inviato al fendinebbia anteriore sinistro. luci_cruscotto: segnale inviato alle luci del cruscotto. luci_sonoro: segnale inviato al meccanismo fisico di allarme per luci accese con macchina spenta e sportello aperto. Spia_fendinebbia:segnale inviato alla spia dei fendinebbia. Architecture Il modulo Luci_Anteriori.vhd è stato diviso in tre processi: A) Fari_process: processo che controlla e gestisce l accensione delle luci(fari). B) Altezza_process: processo che controlla e gestisce l altezza degli anabbaglianti. C) Fendinebbia_process: processo che controlla e gestisce l accensione dei fendinebbia. A)Fari_process Il processo gestisce l accensione dei fari, per farlo correttamente esso controlla cinque diversi segnali di ingresso: (sensitivity list) sensore_start, attuatore_luci_di_posizione, attuatore_anabbaglianti, attuatore_abbaglianti, sensore_sportello_aperto. Si ipotizza che nel sistema sia presente un vincolo meccanico : i segnali delle luci_di_posizione, degli anabbaglianti e degli abbaglianti non possano essere attivi contemporaneamente(vincolo più che plausibile). Per prima cosa il processo controlla che l auto sia accesa e che lo sportello della macchina sia chiuso, altrimenti se uno dei sensori dei fari è attivo, si emette un segnale (luci_sonoro) che avverte il conducente(che eventualmente sta scendendo dalla macchina), che i fari sono rimasti accesi. Il controllo del segnale_start viene effettuato solo per questo motivo e non per bloccare l accensione dei fari in caso di 28

auto spenta(come nel caso dei fendinebbia/retronebbia), poiché il conducente potrebbe accendere i fari con l auto ancora spenta(e, come vedremo meglio più avanti, la loro accensione porta all accensione delle luci del cruscotto). Il secondo compito, il compito fondamentale del processo, è il controllo dei tre sensori dei fari: Luci_di_posizione(fari= 01 ) Fari_anabbaglianti(fari= 10 ) Fari_abbaglianti(fari= 11 ) La variabile stato_fari verrà assegnata al segnale di uscita fari alla fine del processo. Se eventualmente si presentasse un errore nei sensori ed il vincolo meccanico non venisse rispettato(meccanicamente impossibile ma elettricamente possibile), la priorità è assegnata in questo ordine: luci_di_posizione > anabbaglianti > abbaglianti > fari_spenti. Quindi se avessimo un caso di attuatore_anabbaglianti= 1 e attuatore_abbaglianti= 1 avremmo stato_fari = 10. L ultimo compito del processo è l accensione delle luci del cruscotto, le quali saranno attivate all accensione dei fari: 29

B)Altezza_process Il processo gestisce l altezza degli anabbaglianti, controllando i segnali di ingresso attuatore_up e attuatore_down. Si ipotizza che nel sistema vi sia un vincolo meccanico che permetta solamente configurazioni down & up 01, 10 e 00 ma non 11. Le istruzioni seguenti rappresentano la soluzione al problema: Si è deciso di utilizzare il case poiché con una cascata di if era sorto un problema di sintesi(errore in fase di sintesi); la sintassi comunque era corretta anche nell altra soluzione, e sarebbe stato possibile fare anche le simulazioni. Inoltre si son definite le istruzioni nel caso when others (che non portano modifiche allo stato del sistema) di modo da eliminare la presenza dei latch(warning in fase di sintesi). 30

C)Fendinebbia_process Il processo controlla e gestisce i fendinebbia. Quando il segnale start non è ad uno(auto spenta), le luci e la spia dei fendinebbia devono essere spente; in questo caso non si mantiene lo stato, cioè nel caso in cui l auto venga spenta(sensore_start= 0 ), lo stato viene resettato (spia_fendinebbia_temp= 0 ). Se l auto è accesa ed abbiamo un fronte di salita del segnale attuatore_fendinebbia, si devono accendere o spegnere i fendinebbia in base allo stato in cui il sistema si trova: Si è aggiunta una ulteriore caratteristica al sistema dei fendinebbia: all attivazione di uno dei segnali delle frecce si attiva il singolo fendinebbia nella direzione indicata dalla freccia. In questo modo si riesce ad illuminare meglio la strada nell incrocio in cui si vuole curvare. 31

Le istruzioni riportate nella pagina seguente descrivono come è stato risolto il problema. Questa caratteristica è presente solamente in alcune auto di nuova generazione; nel caso in cui non dovessimo servircene basterà programmare la costante tipologia_fendinebbia a zero; in questo modo il sistema fendinebbia avrà un comportamento analogo a quello dei retronebbia(vedi più avanti). 32

Testbench Il test effettuato per il modulo riguardante le luci anteriori è stato il seguente: Figura 19: Testbench del sottocomponente Luci_Anteriori Il test dimostra la correttezza del sistema; è possibile notare le varie caratteristiche riguardanti il modulo sovra descritto: - I fari che modificano il proprio valore in base agli ingressi abbaglianti,anabbaglianti e luci di posizione. - L altezza degli anabbaglianti che viene modificata al modificarsi dei segnali up e down(da notare il fatto che viene modificato solamente in presenza di un fronte di ingresso). - Il segnale luci_cruscotto si attiva anche se l auto è spenta. - Il segnale luci_sonoro si attiva con l auto spenta, sportello aperto e luci accese. - I segnali fendinebbia non sono sempre contemporaneamente attivi/disattivi, ma possono attivarsi singolarmente a causa dei segnali di ingresso sensore_freccia_destra e sinistra. 33

Gestione delle luci posteriori(modulo VHDL : Luci_Posteriori.vhd) Component Descrizione segnali: Figura 20: Sottocomponente Luci_Posteriori - Ingressi: attuatore_retronebbia: segnale che rappresenta l attivazione o la disattivazione dei retronebbia; segnale ad impulsi. sensore_freno: segnale che scaturisce da un eventuale frenata fatta dal conducente(pedale del freno sotto una certa soglia). sensore_retromarcia:segnale viene posto ad uno quando il conducente ingrana la retromarcia. sensore_start:segnale di accensione dell auto(0 auto spenta, 1 auto accesa). - Uscite: retronebbia:segnale inviato ai retronebbia(1 accesi,0 spenti),sia alle spie che alle luci. freno_luci: segnale inviato alle luci rappresentanti la frenata. retromarcia_luci: segnale inviato alle luci rappresentanti l ingranaggio della retromarcia. Architecture Spie retronebbia: Il modulo sovra rappresentato ha un unico compito: controllare che i dati in ingresso possano essere propagati verso gli appositi componenti fisici(in questo caso delle luci). Per poter essere propagati il segnale sensore_start deve essere al livello logico uno(auto accesa). Il codice seguente descrive come è stata implementata la soluzione al problema: Segnali freno e retromarcia: 34

Segnale retronebbia: Si sono utilizzati due processi separati per due motivi: 1- Omogeneità con il modulo precedentemente descritto(un processo per i fendinebbia). 2- Si è voluto separare il processo per i retronebbia il quale controlla degli impulsi, da quello che semplicemente propaga il segnale in arrivo dall esterno. 35

Testbench Il test effettuato per il modulo riguardante le luci posteriori è stato il seguente: Figura 21: Testbench del sottocomponente Luci_Posteriori Il test ha mostrato la correttezza del modulo e ha sottolineato il suo compito principale: il segnale start condiziona la propagazione dei segnali che arrivano dai sensori. 36

Parte 3 Il sistema in analisi può essere ulteriormente suddiviso in 4 parti fondamentali: - Gestione della cintura di sicurezza; - Gestione dell indicatore del livello di benzina; - Gestione dell indicatore della temperatura dell acqua; - Gestione delle spie: olio, airbag, batteria e freno a mano; Tale suddivisione è stata effettuata per semplificare la progettazione di questi sistemi che possono essere considerati autonomi, e soprattutto indipendenti tra di loro. Infatti è stato possibile suddividere il problema in 4 distinti moduli, semplificando in tal modo lo studio e l implementazione del progetto, oltre alla fase di testing. Gestione della cintura di sicurezza Component Descrizione dei segnali in ingresso: Figura 21: Pin-out del componente cintura_di_sicurezza - velocita: è un segnale costituito da 8 bit che indicano la velocità istantanea dell automobile; proviene da uno dei moduli descritti e implementati nella parte 1. - sensore_peso: è un segnale che proviene da un sensore situato al di sotto dei sedili di guidatore e passeggero; se acceso (quindi se il segnale è 1 ) significa che rileva un peso sul sedile. 37

- sensore_cintura: è un segnale che indica se la cintura di sicurezza è allacciata o meno. Nel primo caso il segnale è posto a 1, nel secondo a 0. - sensore_start: è un segnale che rappresenta l avviamento dell automobile; se è posto a 1 significa che l automobile ha effettuato l avviamento (ovvero è stata accesa). - clock: clock del sistema, necessario per sincronizzare il segnale acustico. Descrizione dei segnali in uscita: - segnale_acustico_cintura: rappresenta il segnale acustico intermittente che viene attivato nel caso in cui venga rilevato un peso sul sedile del conducente o del passeggero, la corrispondente cintura di sicurezza risulta slacciata e si superano i 10 Km/h di velocità. - spia_cintura: spia luminosa che viene accesa negli stessi casi descritti per il segnale acustico. Architecture Il comportamento che s intende sintetizzare è il seguente: quando viene rilevato un peso sul sedile, si supera una certa velocità, stimata a 10 Km/h, e la cintura di sicurezza non risulta allacciata, allora deve essere immediatamente accesa la spia che segnala al conducente la necessità di allacciare la cintura di sicurezza e deve essere attivato un segnale acustico intermittente. Entrambi questi segnali vengono disattivati nel momento in cui una delle condizioni non è più verificata, ovvero se la cintura di sicurezza viene allacciata, oppure sul sedile non viene rilevato alcun peso, oppure la velocità dell autovettura scende al di sotto dei 10 Km/h. Il comportamento appena descritto si deve avere solamente nel caso in cui l auto sia accesa. Dopo un accurata analisi del sistema, infatti, si è deciso di discriminare solamente l accensione dell automobile, senza specificare se questa è stata anche messa in moto, in quanto all interno dei moduli presenti nell intero progetto l unica distinzione importante è rappresentata proprio dall accensione della vettura. Infatti sul segnale acustico intermittente della cintura di sicurezza, che rappresenta l unico segnale che non si deve attivare alla semplice accensione dell auto, si è posto un vincolo sulla velocità, grazie al quale la distinzione tra auto accesa e spenta del sensore_start risulta sufficiente. Per l implementazione di questo modulo VHDL si è reso necessario un unico processo, chiamato processo_cintura, all intero del quale sono state definite alcune variabili utilizzate per ottenere il corretto funzionamento del sistema. Processo_cintura 38

La sensitivity list del processo include tutti i segnali di ingresso precedentemente descritti, oltre al clock del sistema, necessario per una corretta sincronizzazione del segnale acustico. Per la conversione della velocità da un segnale std_logic a 8 bit ad un intero, più facilmente gestibile, si è utilizzata una funzione di conversione. In questo modo risulterebbe anche più semplice un eventuale modifica della soglia di velocità che si intende utilizzare nella condizione di accensione della spia luminosa e del segnale acustico. Utilizzando questa funzione di conversione la variabile intera kilometri_orari contiene l intero corrispondente alla configurazione degli 8 bit del segnale di ingresso velocita. Le variabili conta_periodi e periodi_segnale_acustico sono utilizzate per scegliere la durata del segnale acustico intermittente. Infine, per ottenere in output il segnale acustico è necessario effettuare l assegnamento del valore della variabile utilizzata all interno del processo al segnale d uscita. Testbench Nel testbench realizzato per verificare il corretto funzionamento del modulo appena descritto si è scelto come periodo di clock il valore di 10 ms e sono state scelte configurazioni di ingresso tali da attivare e disattivare la spia e il segnale acustico intermittente. Il risultato della simulazione è riportato in figura. 39

Figura 22: Test del componente cintura_di_sicurezza Dopo l attivazione del sensore di start, che indica l accensione dell auto, viene immediatamente rilevato un peso sul sedile, ma inizialmente la velocità è pari a 0 Km/h. La spia luminosa ed il segnale acustico non vengono attivati fino al raggiungimento o superamento della velocità impostata come soglia: 10 Km/h. A tal punto la spia si accende immediatamente, mentre il segnale acustico viene attivato in corrispondenza del fronte di salita del clock, e funziona ad intermittenza fino a quando non viene allacciata la cintura. Dall immagine si può notare una leggera discrepanza tra l accensione della spia e del segnale acustico, ma, avendo scelto un periodo di clock pari a 10 ms, tale discrepanza non viene nemmeno rilevata dal conducente. Dopo l allacciamento della cintura di sicurezza sia la spia sia il segnale acustico vengono immediatamente disattivati. Gestione dell indicatore del livello di benzina Component Descrizione dei segnali in ingresso: Figura 23: Pin-out del componente gestore_benzina - sensori_livello_benzina: è un segnale costituito da 7 bit che proviene da 7 sensori posti uno sotto l altro all interno del serbatoio della benzina; ciascun sensore è posto a 1 se in corrispondenza di quel livello è presente della benzina, a 0 in caso contrario. 40

- clock: clock del sistema, necessario per sincronizzare il segnale acustico. - sensore_start: è un segnale che indica se l automobile ha effettuato o meno l avviamento; in caso positivo, il segnale è posto a 1. Descrizione dei segnali in uscita: Figura 24: Rappresentazione grafica dei sensori di livello nel serbatoio - indicatore_benzina: è un segnale costituito da 3 bit, avente quindi 8 possibili configurazioni, che fornisce al guidatore una stima del livello di benzina presente all interno del serbatoio. - segnale_acustico_benzina: rappresenta il segnale acustico che viene attivato per avvisare il guidatore nel momento in cui il livello della benzina raggiunge la soglia della riserva. - spia_benzina: spia luminosa che viene accesa nel caso in cui si raggiunga la soglia indicata come limite superiore della riserva. Architecture Questo modulo VHDL riceve in ingresso i segnali appena descritti e, nel caso in cui l automobile abbia effettuato l avviamento, fornisce al guidatore un indicazione del livello di benzina presente all interno del serbatoio. Quella fornita è in realtà una stima, in quanto si utilizza un indicatore a 8 livelli. Quando la benzina scende, passando dalla configurazione 0000011 alla configurazione 0000001, allora si è raggiunta la soglia della riserva, quindi devono essere attivati la spia corrispondente ed il segnale acustico. Mentre la spia rimane attiva fino a che il livello della benzina non sale oltre la soglia della riserva, al contrario il segnale acustico deve essere disattivato dopo pochi secondi dall accensione. Dopo lo spegnimento dell automobile sia l indicatore del livello della benzina, sia l a spia devono essere disattivati. Per l implementazione del modulo appena descritto sono stati realizzati due distinti processi: processo_benzina e processo_riserva. Il primo si occupa della gestione dell indicatore del livello della benzina e della spia della riserva, attivando nel momento opportuno il processo_riserva, tramite l utilizzo di due variabili condivise. Il secondo processo gestisce, invece, il segnale acustico, sincronizzandosi con il clock e con il processo precedente. Le due variabili condivise tra i due processi ne permettono la sincronizzazione. Per evitare la possibilità di modifica contemporanea di una stessa variabile da parte di due processi distinti, si è scelto di utilizzare due variabili: un processo legge la prima e scrive la seconda, mentre l altro processo esegue le operazioni inverse. Nel dettaglio, il processo_benzina legge la variabile stato e scrive segnale_attivo, mentre il processo_riserva legge la variabile segnale_attivo e scrive stato. 41

Processo_benzina Si noti come la soglia della riserva viene rilevata basandosi sul segnale sensori_livello_benzina: quando il livello raggiunge la configurazione che corrisponde alla riserva passando da 0000011 a 0000001 allora se la variabile stato è stata posta a 0 dal processo_riserva, quindi il segnale acustico è disattivato, viene posta a 1 la variabile segnale_attivo, utilizzata dall altro processo. Se al contrario il bit numero 1 è uguale a 1 significa che il livello della benzina non ha raggiunto la soglia della riserva, quindi la variabile segnale_attivo viene posta a 0. In figura è riportato il codice relativo alla gestione dell indicatore del livello di benzina presente all interno del serbatoio, unitamente all accensione della spia. 42

Processo_riserva La sensitivity list del processo_riserva contiene unicamente il clock, necessario per la sincronizzazione del segnale acustico. A tal fine sono necessarie due variabili: num_periodi per scegliere la durata del segnale acustico, e conta_periodi per interromperlo. In particolare, il segnale acustico viene attivato in corrispondenza del fronte di salita del clock, e solo nel caso in cui segnale_attivo, la variabile condivisa modificata dal processo_benzina, sia uguale a 1. Fino al raggiungimento del numero di periodi prescelto, il segnale acustico rimane attivo, e la variabile condivisa stato viene settata a 1. Infine, se la variabile condivisa segnale_attivo è stata posta a 0 dall altro processo, allora anche stato viene posta a 0, viene azzerato il contatore dei periodi per la prossima attivazione della riserva e viene disattivato il segnale acustico. Testbench Nel testbench implementato per testare il corretto funzionamento del modulo che gestisce l indicatore della benzina si è scelto un clock pari a 10 ms. Dopo aver attivato il sensore_start, si è simulato un riempimento del serbatoio, con progressivo consumo della benzina ad intervalli di 15 ms, fino al raggiungimento dell ultimo livello, che indica che il serbatoio è completamente vuoto. Si noti che in corrispondenza della soglia della riserva si accendono la relativa spia ed il segnale acustico, con una leggera discrepanza non rilevabile dal conducente. Il risultato prodotto dal simulatore è riportato in figura. 43

Figura 25: Test del componente gestore_benzina Gestione dell indicatore della temperatura dell acqua Component Descrizione dei segnali in ingresso: Figura 26: Pin-out del componente gestore_acqua - sensore_start: è un segnale necessario per verificare se l automobile è stata accesa; - sensori_livello_acqua: è un segnale che proviene dal serbatoio dell acqua ed è costituito da 7 bit; ciascun bit corrisponde ad una determinata temperatura, ed è posto a 1 nel caso in cui la temperatura dell acqua sia superiore a tale valore. Descrizione dei segnali in uscita: - spia_acqua: spia luminosa che viene accesa se la temperatura dell acqua ha superato una determinata temperatura scelta come soglia massima. - indicatore_livello_acqua: è un segnale costituito da 3 bit, utilizzato per fornire al guidatore una stima della temperatura dell acqua. Architecture Il comportamento che s intende sintetizzare con questo modulo è simile a quello descritto per la benzina. I sensori_livello_acqua sono posti su un indicatore di temperatura: la temperatura dell acqua viene misurata, e vengono posti a 1 tutti i bit corrispondenti a temperature minori o uguali a quella rilevata. In questo 44

modo si ha la possibilità di fornire al guidatore una rappresentazione della temperatura dell acqua simile e conforme a quella del livello della benzina. Anche l implementazione risulta quindi simile a quella già descritta per la benzina, con la differenza che non si ha nessun segnale acustico, e quindi non risulta necessario suddividere l architettura in due processi, né impostare un clock per la sincronizzazione. Si tratta quindi di un modulo completamente asincrono. Processo_acqua Come si può notare dal codice, l intero processo è vincolato dall avviamento dell automobile; la spia dell acqua viene accesa quando i sensori di temperatura passano da un valore pari a 0011111 al valore impostato come soglia: 0111111. Si noti l assenza di variabili, in quanto semplici condizioni sui segnali di ingresso sono sufficienti a modificare in maniera opportuna i segnali in uscita. Testbench Nella fase di test del modulo appena descritto è stata simulata una semplice variazione della temperatura dell acqua, passando dalla temperatura più bassa a quella più alta ad intervalli di 10 ms, con accensione della spia al raggiungimento del valore impostato come soglia. Il risultato della simulazione è riportato nella figura della pagina successiva. 45

Figura 27: Test del componente gestore_acqua Gestione delle spie Component Figura 28: Pin-out del componente gestore_spie Descrizione dei segnali in ingresso: - sensore_airbag: è un segnale che proviene da un sensore che verifica il corretto funzionamento degli airbag; se è posto a 1 indica un possibile guasto. - sensore_batteria: è un segnale che proviene da un sensore che indica se la batteria è in procinto di scaricarsi. - sensore_freno_a_mano: è un segnale che proviene dal freno a mano; è posto a 1 se la leva del freno a mano è stata alzata. - sensore_olio: è un segnale che proviene dalla coppa dell olio; se è posto a 1 significa che il livello dell olio è eccessivamente basso. 46

- sensore_start: è un segnale che proviene da un sensore che verifica se l automobile ha effettuato o meno l avviamento. Descrizione dei segnali in uscita: - spia_airbag: spia luminosa che deve essere accesa per segnalare al guidatore un possibile guasto a un airbag - spia_batteria: spia luminosa che deve essere accesa se la batteria è in procinto di scaricarsi. - spia_freno_a_mano: spia luminosa che deve essere accesa nel caso in cui la leva del freno a mano risulti alzata. - spia_olio: spia luminosa che viene accesa quando il livello dell olio risulta eccessivamente basso, per informare il guidatore della necessità di cambiare l olio. Architecture Il comportamento che tale modulo deve avere è piuttosto semplice: in base al valore rilevato dal relativo sensore, viene attivata o disattivata la spia corrispondente. Ogni spia è vincolata dall avviamento dell automobile: se l auto non è accesa le spie sono spente. Per l implementazione di questo modulo è stato realizzato un unico processo, chiamato processo_spie. Processo_spie Come si può notare dal codice riportato, non è stato necessario introdurre un segnale di clock, in quanto tutti i segnali in ingresso e in uscita a questo modulo sono asincroni. Testbench Nel testbench realizzato per verificare il corretto funzionamento di questo modulo sono stati effettuati alcuni assegnamenti ai segnali in ingresso, per verificare le risposte del sistema. 47

Figura 29: Test del componente gestore_spie Nel dettaglio, è stato inizialmente posto a 1 il bit che indica l avviamento dell auto. Dopo alcuni ms sono stati settati a 1 i sensori di batteria, di airbag e freno a mano. Dopo aver disattivato quest ultimo, è stato azzerato il bit di start ed attivato nuovamente il freno a mano. Come si nota dalla figura la spia relativa non si accende se l auto è spenta, ma, alla successiva accensione, la spia riporta in uscita il valore rilevato dal sensore mentre l auto era spenta. 48

Quadro Comandi Component e Architecture Si è realizzato infine un unico Component che rappresenta l intero quadro comandi dell automobile, costituito dalla sintesi di tutti i componenti precedentemente descritti. Avendo già analizzato in modo approfondito ciascuna delle singole parti che costituiscono il Quadro comandi, appare superfluo descrivere nel dettaglio i pin di ingresso e uscita che lo caratterizzano, mentre è necessario focalizzare l attenzione sulle modifiche che sono state apportate per garantire il corretto funzionamento del sistema nel suo complesso. Poiché quasi tutti i moduli sono indipendenti tra di loro, le modifiche che sono state apportate al codice sono ridotte: è stato necessario, ad esempio, utilizzare lo stesso nome per i segnali utilizzati in più moduli, come il sensore_start, necessario per verificare se l auto è accesa, e utilizzato sia all interno dei moduli che gestiscono il funzionamento dei fari, sia nei moduli per la gestione della benzina, dell acqua, delle spie e della cintura di sicurezza. La modifica di maggiore rilevanza per garantire il corretto funzionamento del sistema riguarda il segnale che rappresenta la velocità dell automobile. Infatti, questo segnale rappresenta un uscita per il modulo ContaKmTachimetro, mentre è un valore d ingresso per il modulo Cintura_di_sicurezza. Ciò significa che i due moduli in questione sono interconnessi tra loro proprio attraverso il segnale che rappresenta la velocità del veicolo, il quale, pertanto è stato modificato all interno del componente Quadro comandi in un segnale inout. In tal modo è garantito il corretto funzionamento dell intero sistema, come si può notare dai test effettuati. 49

Figura 30: Schema generale di Quadro Comandi 50

Testbench Lo scopo della realizzazione di un unico componente costituito dall assemblaggio dei singoli moduli precedentemente descritti è quello di testare il funzionamento dell intera applicazione realizzata: i risultati ottenuti con i singoli testbench, infatti, non garantiscono il corretto funzionamento del sistema nel suo complesso. In particolare, si è deciso di effettuare una simulazione il più possibile realistica, ipotizzando di avere un automobile, su cui è montato il nostro Quadro comandi, che si sposta dalla Stazione FS di Bologna alla Facoltà di Ingegneria. Figura 31: Mappa del percorso simulato in fase di testing Nel dettaglio, s ipotizza che l automobile parta da ferma; dopo aver acceso e avviato il veicolo, disinserito il freno a mano e acceso i fari anabbaglianti, si comincia ad aumentare la velocità, passando gradualmente da 0 Km/h a 50 Km/h. Quando si raggiungono i 10 Km/h, poiché viene rilevato un peso sul sedile e la cintura non è ancora stata allacciata, si attivano la relativa spia e il segnale acustico. A questo punto viene allacciata la cintura di sicurezza. Viale Pietramellara viene percorso ad una velocità di circa 50 Km/h, fino al raggiungimento dell incrocio con Via Zanardi, dove si rallenta fino a 40 Km/h. La velocità risale poi fino a 50 Km/h, sino ad arrivare a Porta San Felice, dove ci si ferma, ipotizzando che il semaforo sia rosso. A questo punto, dopo una breve attesa, si riparte, raggiungendo gradualmente i 50 Km/h fino a Porta Saragozza, dove si svolta a destra, in Via Saragozza. Per la svolta è necessario inserire l indicatore di direzione destro, frenare e disinserire la freccia, per poi aumentare nuovamente la velocità fino a 50 Km/h. Una volta raggiunto l incrocio con Via Bellinzona è di nuovo necessario frenare, accendere la freccia sinistra, svoltare e disattivare la freccia. Trattandosi di una strada stretta e in salita, questa viene percorsa ad una velocità di 40 Km/h, sino al raggiungimento dell incrocio con Via Belluzzi. Dopo aver attivato l indicatore di direzione 51

sinistro, aver ridotto, frenando, la velocità fino a 20 Km/h circa per la svolta e aver disattivato la freccia, si percorre Via Bellinzona ad una velocità media di 40 Km/h. A tal punto, però, il livello della benzina presente nel serbatoio scende, raggiungendo la soglia della riserva, con conseguente accensione della spia e del breve segnale acustico. Infine, dopo aver diminuito la velocità per l incrocio con Viale del Risorgimento, si è raggiunta la Facoltà di Ingegneria e si frena sino a fermare l auto per il parcheggio. Dopo aver spento il veicolo, attivato il freno a mano e slacciato la cintura, si apre lo sportello: non avendo ancora spento i fari si attiva il relativo segnale acustico. A questo punto il guidatore spegne i fari, scende dall auto e chiude la portiera. Di seguito sono riportate le immagini relative alla simulazione effettuata, suddivise in modo da focalizzare l attenzione su ciascuna delle 3 parti in cui è stata suddivisa l implementazione del progetto. Figura 32: Dettaglio dell'andamento della velocità e del numero di giri al minuto durante il percorso 52

Figura 33: Simulazione delle luci e delle spie relative durante il percorso Figura 34: Simulazione delle spie e dei segnali relativi alla sicurezza 53