Architettura dei Sistemi Embedded: Quando il Tuo Prodotto Ha Più PCB

I sistemi embedded sono onnipresenti nel mondo tecnologico di oggi. Che si tratti di un rasoio connesso a Internet o di un'automobile complessa, i dispositivi embedded sono al cuore della maggior parte dei dispositivi elettronici che utilizziamo oggi. Composti da uno o più microprocessori, i sistemi embedded possono semplificare l'elettronica scaricando la complessità da gestire tramite software. Man mano che i dispositivi embedded diventano più grandi e complessi, lo diventano anche le schede a circuito stampato (PCB). Spesso questi dispositivi si sviluppano in più schede e diventano assemblaggi più grandi di quanto originariamente previsto.

In questo articolo esamineremo i compromessi e le considerazioni architettoniche per i sistemi embedded costituiti da più PCB. Copriremo i vantaggi, le considerazioni di progettazione e le sfide associate ai sistemi multi-PCB.

Perché utilizzare più PCB?

Mantenere il proprio dispositivo su un singolo PCB è l'opzione ideale (sia per semplicità che per costo), ma a volte dobbiamo decidere di dividere il nostro progetto in due o più PCB per raggiungere i nostri obiettivi di progettazione. Alcuni motivi per cui vorremmo suddividere il nostro prodotto in più schede includono:

• Modularità: Separare un assemblaggio in più schede significa che è possibile sostituire solo parte del prodotto se necessario. Ad esempio, se un singolo PCB si guasta, può essere sostituito senza influenzare l'intero sistema. Se fatto correttamente, ciò può ridurre i costi e i tempi per i produttori.
• Ottimizzazione dello spazio: Dividendo i componenti su più schede, i progettisti possono ottenere layout più compatti ed efficienti. Pensate a una singola scheda molto lunga e stretta rispetto a poche schede corte e impilate dove l'altezza non importa a causa del packaging.
• Gestione termica: I componenti che generano molto calore possono essere suddivisi su diverse PCB per migliorare la dissipazione termica. Distribuendo uniformemente il calore su tutto l'assemblaggio è possibile migliorare notevolmente l'affidabilità del sistema.
• Scalabilità: Progettare con più PCB consente aggiunte incrementali di funzionalità che possono essere sostituite da una singola scheda anziché da un intero assemblaggio. Pensate a un sensore o una telecamera aggiornati senza sostituire l'intero sistema di calcolo.

Per questi motivi (e altri) consideriamo la progettazione di un assemblaggio composto da più PCB, ma le sfide relative al firmware embedded non sono prive di complessità.

Considerazioni di progettazione embedded per assemblaggi multi-PCB

Ora che abbiamo stabilito il caso per l'uso di più PCB (dove applicabile) è importante comprendere le considerazioni di progettazione quando si architetta il sistema embedded. Sia dal punto di vista hardware che software ci sono sfumature che tendiamo a non valutare con attenzione quando mettiamo tutto su un'unica scheda.

La prima considerazione che dovrebbe venirci in mente è la comunicazione tra schede. Come comunicherà ogni scheda con le altre? Che tipo di potenza di elaborazione (se presente) risiede su ogni scheda? Forse una scheda consiste nel cervello mentre le altre nei sensori? Mentre scegliamo attentamente i nostri protocolli di trasmissione, sia esso I2C, SPI, UART, Ethernet, ecc., dobbiamo anche valutare le linee di trasmissione, l'integrità del segnale e, cosa più importante, il trasferimento del segnale attraverso i connettori tra schede. La peggiore cosa che può accadere a un progettista (e credetemi, ci sono stato) è progettare l'intero sistema e ricevere indietro le vostre PCB dal produttore solo per rendersi conto di aver dimenticato uno o due segnali di clock. Tendiamo anche a dimenticare di mantenere pin di riserva sui nostri connettori tra schede, cercando di sfruttare al massimo ogni conteggio dei pin. Questo è qualcosa che può davvero ritorcersi contro alla fine. Progettare con un progetto multi-scheda in mente, come la funzionalità di Assemblaggio Multi-Scheda in Altium Designer, è un must quando si instradano così tante linee di comunicazione tra PCB.

Dobbiamo anche pensare a come prevediamo di distribuire l'alimentazione, specialmente se monitoreremo i bus di alimentazione con il nostro microprocessore. Vogliamo l'accessibilità al "cervello" per permettergli di monitorare eventuali eventi catastrofici, ma dobbiamo anche considerare il rumore dell'alimentatore switching, la distribuzione dell'alimentazione per carichi pesanti e se i pin dei nostri connettori tra schede sono valutati per quel tipo di potenza.

Infine, anche se non è direttamente correlato al software stesso del sistema embedded, il design meccanico gioca anche un ruolo importante. Pulsanti, schermi touch e altre interfacce fisiche all'utente sono ancora collegati al microprocessore e devono essere presi in considerazione. Il cablaggio può essere instradato in modo tale che il microprocessore possa accedere ai suoi ingressi? Abbiamo considerato l'integrità del segnale dell'uscita digitale ad alta velocità mentre la passiamo da una scheda all'altra? Queste sono cose a cui dobbiamo pensare quando architettiamo il nostro dispositivo embedded.

Sfide e Soluzioni

Una delle sfide più sottovalutate che ho visto ripetersi sia in startup in crescita (e anche in grandi aziende) è stata la piaga degli schemi di versionamento tra software e hardware. Gestire le versioni del software rispetto alle revisioni delle PCB è diventata la battaglia infinita che spesso porta a confusione, ritardi e persino fallimenti del prodotto.

Ad esempio, in una startup con cui ho lavorato, una leggera modifica nella PCB richiedeva un nuovo spin e, quindi, un aggiornamento del firmware (seppur minimo). A causa di un controllo delle versioni scadente, il team di ingegneria ha distribuito il nuovo firmware su versioni più vecchie delle PCB causando brownout inaspettati e una nuvola di fumo periodica. Fortunatamente l'abbiamo scoperto prima della spedizione del prodotto ma è stato un incubo assoluto per giorni interi.

Per evitare queste insidie, è cruciale stabilire uno schema di versionamento solido come una roccia e assicurare una comunicazione chiara tra i team di hardware e software. Anche uno schema di versionamento semplice come un hash Git (o versione semantica) per il firmware, insieme a una tabella di ricerca di base per le revisioni hardware, può essere sufficiente per iniziare. Col passare del tempo, meccanismi più sofisticati come il rilevamento della revisione hardware nel firmware (verificando così la compatibilità) riducono notevolmente anche i disguidi.

Oltre alla versioning del software, è importante anche pensare alla modularità del codice. Con un codice spaghetti, sostituire una scheda sensori con nuovi chip o sensori potrebbe diventare un incubo di refactoring. Modularizzare i driver dei dispositivi e creare strati di astrazione hardware permette di sostituire facilmente componenti per anni a venire. Questo è qualcosa che è diventato molto più popolare man mano che i sistemi embedded sono cresciuti in complessità nel tempo.

Conclusione

Quando pensiamo all'architettura dei sistemi embedded non dobbiamo sempre pensare in piccolo. Le navicelle spaziali e le automobili sono sistemi embedded estremamente complessi ma lo sono anche gli smartphone. Che stiamo progettando un cucchiaio connesso a internet o il prossimo satellite, comprendere i compromessi per l'architettura dei sistemi embedded è estremamente importante quando si progetta per più PCB. Abbiamo esplorato molti concetti in questo articolo ma ci sono ancora molti altri che, senza dubbio, troverai lungo il tuo viaggio.