Progettazione di un rilevatore di stato di un sensore

su bus CAN, secondo standard aeronautico

Davide Marsili
February 2, 2024

1 Introduzione
Questo elaborato può essere collocato nell’ambito della progettazione di un rilevatore di stato di un
sensore su bus CAN, secondo standard aeronautico. Il sistema, chiaramente collocato su di un velivolo,
dovrà essere sensibile infatti all’azionamento di una leva, lato pilota, la quale comporterà contestual-
mente l’apertura di un paracadute e lo spegnimento dei motori, per ovvie ragioni di stabilità.
Una caratteristica fondamentale della scheda, sarà quella di venir realizzata interamente in elettronica
hardware, per ridurre al minimo il margine di errore nel funzionamento, che non può essere garantito
del tutto, nel caso di utilizzo di dispositivi con software integrato. Per ragioni di sicurezza, inoltre, la
comunicazione del comando, indotto dall’azionamento della leva, avverrà su di un bus CAN, su cui si
interfacciano le altre periferiche del velivolo stesso, seguendo in aggiunta le specifiche dello standard
ARINC 825. L’architettura (vedi Appendice) di base sarà articolata in:
• una parte di gestione dell’alimentazione
• una parte di diagnostica dei segnali sia esterni sia interni alla scheda.
• una sezione, costituita da circuiteria logica di base, con il fine di generare i segnali necessari alla
configurazione.
• due CAN controller, dispositivi che si occupano della gestione della comunicazione CAN, inter-
facciandosi sul bus(due per motivi di ridondanza).
Lo scopo dello studio, successivamente illustrato, è quello di cercare di emulare il comportamento del
sistema, mediante l’utilizzo di codice VHDL, da implementare su di una FPGA, cosı̀ da ricreare un
testbench dell’architettura stessa, per poi andare a verificare, se effettivamente il CAN controller, invia
correttamente il messaggio.

2 Protocollo CAN
Il protocollo CAN (Controller Area Network ), definito dalla BOSCH, nacque, dapprima, per scopi
automotive, al fine di ridurre il cablaggio tra le le varie apparecchiature elettroniche, che cominciavano
ad affollare gli autoveicoli, ma successivamente si estese in altri ambiti (robotica, domotica, industriale,
avionico, medicale).
I motivi del suo uso sono:

• Semplicità nel cablaggio, si parla infatti di comunicazione seriale, su di un doppino, con periferiche
non identificate da indirizzi, essendo un protocollo message oriented.
• Elevata affidabilità nella trasmissione, senza lasciare alcun margine di errore
• Alta immunità ai disturbi

• Confinamento degli errori, con periferiche che gestiscono da sole eventuali problemi hardware,
con la possibilità di autoescludersi.

1
 • Priorità dei messaggi, infatti la contesa del bus CAN, avviene mediante un sensing dello stesso
da parte delle periferiche e viene trasmesso il messaggio con identifier a più alta priorità.
Due sono sono le specifiche del protocollo, ovvero 2.0A e 2.0B, che nonostante qualche piccola vari-
azione, come per esempio a livello di trama dati, mostrano pressoché un comportamento analogo. Si
hanno in generale quattro tipi di trame, ovvero Data frame, Remote Frame, Error Frame, Overload
Frame, tuttavia nel sistema si è interessati all’invio di una singola trama dati[1].

3 CAN controller
Il dispositivo attorno al quale ruota tutto il sistema è l’HI-3110, il quale implementa il CAN 2.0B e
può essere configurato per supportare sia lo standard ARINC 825 sia CANaerospace standards. La
sua configurazione prevede la popolazione dei suoi registri interni, attraverso una interfaccia SPI, e di
conseguenza tale dispositivo assumerà il ruolo di Slave, mentre il Master è rappresentato dalla parte
di circuiteria logica a monte.
Indubbiamente l’impostazione dei registri( ognuno accessibile con operazioni di scrittura mediante uno
specifico Op-Code, da apporre agli 8 bit di ciascun registro, inviati via SPI) in fase di inizializzazione,
andrà ad influire sul comportamento del controller nella comunicazione sul bus, infatti si andrà a
settare, per esempio, bit rate (in funzione della frequenza di oscillazione), fino ad 1 MHz massimo, bit
timing e ad abilitare le uscite (GP1, GP2, INT), sfruttate dalla parte di diagnostica, e che assumeranno
un determinato livello logico, in presenza di determinati eventi ecc.
Sempre durante l’inizializzazione si va a popolare con una operazione di Write la sua Transmit FIFO,
con il data frame da inviare, per poi indurre il passaggio alla modalità di funzionamento normale, dove
il chip può trasmettere e ricevere[2].
Di seguito si riporta, il Pin-out dell’HI-3110 (vedi 1)

Figure 1: Pin-out HI-3110.

4 Progettazione
In primo luogo, si è pensato a come poter produrre il pattern di bit per la programmazione dell’HI-
3110, secondo SPI mode 0, e cosı̀ si sono andati a generare nello specifico tre segnali, ovvero un chip
select, unspi clk, un slave in, con la linea di slave out disattivata.
Più precisamente, ogni ottava di bit di ciascun registro è preceduta da otto bit di Op-Code, inoltre il
segnale di chip select deve tornare ad un valore logico alto, in modo da intervallare le varie operazioni.
Si è impostata una catena di bit su tre file, che dovrà costituire l’uscita della rete logica e per far si
che sequenzialmente viene inviata al controller la giusta tripla di bit, si è posto a monte un contatore,
che, se abilitato, ad ogni ciclo di clock genera un indirizzo che corrisponde ad una specifica tripla.
Le uscite del parallel counter sono gli ingressi delle tre funzioni combinatorie, prodotte attraverso
mappe di Karnaugh, e ovviamente la grandezza del contatore dipende dal numero di bit necessari. Si
è scelto, infine, un counter a dieci bit con l’ultimo usato come discrimine tra due diverse configurazioni
del dispositivo a valle. In 2, si riporta il pattern generato su Vivado.

2
 Figure 2: Porzione di tre pattern di bit generati.

La macchina a stati da implementare è riportata in 3 e in 4 la simulazione su Vivado.

Figure 3: Macchina a stati generale.

Bisogna affermare come i flag esterni dei due CAN controllers, svolgono un ruolo fondamentale
perché, mandati in retroazione al FPGA, permettono di capire se il dispositivo è configurato e se la
trasmissione è completata.

• GP1, legato allo stato della FIFO.

• GP2, legato a cambiamenti nella modalità operativa.
• INT, legato allo stato della trasmissione appena effettuata.

In aggiunta si può riconfigurare il sistema solo con un segnale alto-basso proveniente dalla leva, a
trasmissione del precedente comando completata.

3
 Figure 4: Simulazione in Vivado.

5 Testbench
Per realizzare un test del tutto, innanzitutto, si è andato a simulare, su una basetta millefori, la
circuiteria per la gestione degli ingressi,seguendo il seguente schema elettrico 5.

Figure 5: Simulazione in Vivado.

Dei jumper e un bottone sono stati posti sul pull-up, in modo da ricreare con il loro inserimento
o meno uno switch, vedi 6. Sono stati aggiunti anche dei led per segnalare con la loro accensione
determinati stati. Per quanto concerne il codice quest’ultimo è stato implementato su una FPGA,
inserita all’interno di una sistema precedentemente realizzato in XIBO, su cui sono integrati pure i
CAN controllers. Chiaramente il sistema mette a disposizione un numero considerevole di risorse,
cosicché si è andato ad abilitare solo quelle necessarie per il funzionamento.
L’uscita della board viene visualizzata mediante connettori CAN-to-USB e tramite software,. In 6, si
riporta il set-up.

4
((a)) Top del ciruito, alimentazione 3.3
VDC. ((b)) Bottom del circuito

((c)) Set-up 1, alimentazione 28 VDC ((d)) Set-up2.

Figure 6: Set-up complessivo.

5
6 Conclusioni e sviluppi futuri
In questo tirocinio, si è dapprima studiato il funzionamento del protocollo CAN e dell’HI-3110, per
poi passare all’implementazione dell’architettura con codice VHDL su FPGA. Si è poi realizzato un
piccolo circuito per pilotare gli ingressi su basetta millefori. Tra gli sviluppi futuri si collocano:
• Modifica circuito di ingresso, con l’aggiunta di transistor bipolari, opportunamente polarizzati
per poter passare una corrente sufficiente all’accensione dei led, in quanto le linee di uscita
presentano 51 kOhm in serie.

• Generazione dei segnali abilitanti per le I/O (esempio un segnale di Watchdog), visto che l’FPGA
è inserita in un macro-sistema, con circuiti di gestione per le I/O stesse.
• Validazione del test
• Passaggio ad una progettazione completamente hardware del sistema stesso.

7 Riferimenti
[1] 1991, Robert Bosch Gmbh, Can specification, version 2.0.
[2] Data-sheet, HI-3110, http://www.holtic.com/products/3012-hi-3110-hi-3111-hi-3112-hi-3113.aspx

8 Appendice