[ad_1]
Negli ultimi giorni, il numero di centraline elettroniche (ECU) nelle auto continua ad aumentare, allo stesso tempo c’è la necessità di ridurre la corrente di riposo per migliorare l’efficienza della batteria. Nelle auto a gas questo è diventato obbligatorio.
Stupisci il mondo dell’ingegneria con il tuo design unico: Guida per la presentazione di idee di progettazione
Limitazioni al controllo della corrente dello stato di sonno
Al giorno d’oggi, più ECU vengono combinate e alimentate da un singolo fusibile/E-fuse per risparmiare sui costi di progettazione, ma questo presenta lo svantaggio di controllare le ECU in modo indipendente. Se desideriamo un controllo ON/OFF indipendente, il costo di progettazione aumenterà in modo significativo.
Per superare il problema dei costi, ogni ECU è dotata di un I/O aggiuntivo chiamato “ACCENSIONE” dall’ECU principale. Dopo aver ricevuto l’ingresso ACCENSIONE, le ECU slave si risveglieranno dallo stato di sospensione. Questa architettura tradizionale ha i suoi limiti, ad esempio necessita di un’interfaccia di comunicazione aggiuntiva come LIN, CAN o Ethernet per comunicare modalità di alimentazione come sospensione, attività e altre informazioni sullo stato. Ciò aumenta ulteriormente il costo del sistema.
L’ACCENSIONE è un segnale unidirezionale che verrà asserito dalla ECU principale, per la ECU slave questo sarà solo un ingresso. Per rilevare questo ingresso di ACCENSIONE, il microcontrollore nell’ECU slave deve essere abilitato come sorgente di riattivazione. Anche se l’ECU è in uno stato di basso consumo, consuma una certa energia per mantenere il microcontroller in stato di sospensione e il controller DC-DC.
In molte architetture di veicoli l’interfaccia CAN o LIN viene utilizzata sia per la comunicazione che per scopi di Wake (wake over CAN) dove non è necessario un ingresso di accensione. Tuttavia, ciò consuma più energia di sonno rispetto alla condizione precedente.
Figura 1 L’architettura tradizionale del veicolo in cui più ECU sono combinate e alimentate da un unico fusibile per risparmiare sui costi di progettazione. Ciò causa limitazioni al controllo della corrente nello stato di sospensione.
La soluzione proposta
Nell’architettura proposta, l’IGNITION I/O sarà sostituito con l’Hardware Wake I/O (HW_WAKE). Uno schema a blocchi di base dell’architettura proposta con Hardware Wake I/O è mostrato in figura 2.
figura 2 L’architettura proposta utilizza Hardware Wake I/O (HW_WAKE).
Il circuito interno di un I/O di riattivazione hardware è mostrato in Figura 3.
Figura 3 Il circuito bidirezionale Hardware Wake con due transistor per il controllo dell’uscita, un partitore resistivo per leggere lo stesso I/O e diodi per la protezione inversa.
È costituito da due transistor Q1 doppio pacchetto (uno NPN e uno PNP) per il controllo della funzionalità di uscita e un semplice partitore resistivo (R2, R3 & R4) per ricevere o leggere lo stesso I/O. Inoltre, ci sono diodi (D1, D2) per la protezione inversa.
Si tratta di un I/O bidirezionale, in cui possiamo ricevere segnali come riattivazione, ripristino e sospensione, nonché inviare segnali come feedback e stato di errore. I livelli di tensione degli I/O HW_WAKE seguono la tensione della batteria, con una corrente controllata di 13,5 mA nel disegno proposto. L’utente può decidere la propria corrente modificando il resistore R1.
Questo circuito è dotato di protezione da cortocircuito e non richiede alcun ricetrasmettitore sofisticato o di protocollo. Il segnale HW_WAKE può essere collegato a un numero “n” di ECU. Per evitare la contaminazione degli I/O, l’utente può leggere lo stato degli I/O “HW_WAKE_RX_TO_MCU” prima di affermare “HW_WAKE_TX_FROM_MCU_GPIO”.
Vantaggi del segnale HW_WAKE
Poiché HW_WAKE è un I/O bidirezionale, qualsiasi ECU può fungere da master, ciò è utile nei casi in cui sono necessarie più sorgenti di riattivazione (ad esempio, se una ECU si riattiva e invia segnali di riattivazione a tutte le altre). Lo stato predefinito dell’I/O HW_WAKE è aperto (0 V), verrà affermato (VBAT) solo quando richiesto. Sia le informazioni di controllo che quelle di stato vengono trasmesse su questa interfaccia a filo singolo mediante campionamento, inviando segnali basati sulla temporizzazione.
Utilizzando l’I/O HW_WAKE, possiamo evitare di utilizzare il supporto del protocollo LIN o CAN, risparmiando molti costi di progettazione e implementazione. L’utente può implementare i propri tempi per tutti i segnali. Possiamo spegnere completamente l’ECU durante uno stato di sospensione, in questo modo possiamo ottenere una potenza ultra-bassa di quasi 0 mA. Ciò può essere ottenuto collegando anche “HW_WAKE_RX_TO_MCU” al pin di abilitazione del convertitore DC-DC, abilitando l’alimentazione. Ciò abiliterà anche il microcontrollore, una volta che il microcontrollore è attivo, manterrà l’abilitazione per il convertitore DC-DC.
Quando viene ricevuto un segnale di sospensione/spegnimento, il microcontrollore disabiliterà l’abilitazione dell’alimentazione. Ciò disattiva completamente l’alimentazione (come se si autodistruggesse) ottenendo una dissipazione di potenza estremamente bassa (0 mA).
Esempi di tempistiche
Le informazioni sullo stato e sul controllo e gli esempi di temporizzazione possono essere visualizzati in Figura 4.
Figura 4 Esempi di temporizzazione di controllo e stato per WAKE_IN, ACK, ERROR e POWER DOWN/SLEEP.
- WAKE_IN: Questo segnale viene attivato dall’ECU principale semplicemente affermando HW_WAKE. Tutte le altre ECU si sveglieranno in base a questo segnale. Il tipico tempo alto del segnale è 100 ms (tempo basso N/A).
- RICONOSCI: Le ECU slave inviano un segnale di riconoscimento al master semplicemente affermando HW_WAKE. Il tempo alto tipico del segnale è 20 ms (tempo basso N/A).
- ERRORE: Le ECU slave inviano un segnale di pattern alto-basso-alto-basso-alto, per comunicare lo stato di errore. Il tempo alto tipico del segnale è 20 ms mentre il tempo basso tipico è 10 ms.
- SPEGNIMENTO/SONNO: Il segnale di spegnimento o sospensione verrà comunicato dal master a tutte le ECU slave affermando HW_WAKE per 200 ms.
Rajesh Subramanyam (membro senior, IEEE) ha conseguito la laurea in ingegneria elettrica ed elettronica presso l’Anna University, Chennai, India. Attualmente lavora come ingegnere progettista hardware senior presso un’azienda di veicoli elettrici in California, negli Stati Uniti, con una competenza fondamentale nella progettazione hardware di controller di infotainment automobilistico. Rajesh è anche membro del comitato di revisione editoriale della rivista internazionale SAE.
Selvakumar Sonai (membro senior, IEEE) ha conseguito il master in microelettronica presso BITS Pilani, India. Attualmente lavora come ingegnere progettista hardware senior presso un’azienda di veicoli elettrici in California, negli Stati Uniti, con una competenza fondamentale nella progettazione hardware di controller di infotainment automobilistico. Sonai è membro di IEEE Transactions on Circuits and Systems nonché del comitato di revisione editoriale della rivista interna SAE.
Logesh Sekar (membro senior, IEEE) ha conseguito la laurea in ingegneria elettrica ed elettronica presso l’Anna University, Chennai, India. Attualmente lavora come ingegnere progettista hardware senior presso un’azienda di veicoli elettrici in California, USA con competenze chiave nell’hardware dei controller di infotainment automobilistico progetto. Sekar è anche membro del comitato di revisione editoriale della rivista internazionale SAE.
Contenuto relativo
[ad_2]
Source link