Il “lato sinistro” della V)

Clicca per la sezione precedente: Fase 2

La Fase 3 è dove il design diventa fisico: progettazione elettronica e meccanica, che di solito avanzano di pari passo. Se avete sentito parlare del V-model in ingegneria (un classico modello di processo di sviluppo), il lato sinistro della “V” è tutto incentrato su design e implementazione – ed è esattamente dove siamo ora. In altre parole, ci stiamo concentrando sulla progettazione dell’hardware che verrà poi verificato e validato sul lato destro della V. (Non preoccupatevi se non conoscete il V-model; l’idea chiave è che il design hardware tende a essere un processo sequenziale da affrontare con cura. Una volta stampato un circuito o stampato un case in plastica, fare modifiche è complicato – leggasi: costoso.)

La Fase 3 può essere scomposta in alcuni sotto-passaggi. Cosa importante, questa è anche la fase in cui lo sviluppo hardware e software inizia a lavorare in parallelo (più sul lato software nella prossima fase). Sul binario hardware, ecco come le cose si svolgono tipicamente:

Schematic capture: il progetto elettronico

Ogni prodotto elettronico comincia come un disegno – non del tipo artistico, ma uno schematico. Lo schematic capture è dove il circuit design elettrico viene tracciato in dettaglio usando strumenti CAD specializzati (come Altium, Eagle o KiCad). Pensate allo schematico come al progetto del vostro circuito: mostra ogni componente (microcontrollore, sensori, condensatori, connettori e altro) e come sono tutti collegati elettricamente dalle net (piste). È come mappare una città di elettronica dove ogni componente è un edificio e le net sono le strade che li collegano.

Questo passo è cruciale perché è molto più facile (ed economico) correggere gli errori su un diagramma che su una scheda fisica. Una volta abbozzato lo schematico, una revisione approfondita è d’obbligo. Tipicamente, l’ingegnere esporta lo schematico in PDF e lo fa circolare per una peer review. Occhi freschi possono cogliere qualcosa che vi è sfuggito – per esempio, “Ops, il pin di alimentazione del sensore di temperatura non è collegato!” o “Quel valore di resistenza sembra sbagliato per il limitatore di corrente del LED.” Intercettare questi problemi ora risparmia molti mal di testa dopo.

In questa fase alcuni team eseguono anche una FMEA (Failure Modes and Effects Analysis) sulle parti critiche del design, come l’alimentazione o i circuiti di sicurezza. La FMEA è fondamentalmente un modo strutturato di chiedersi “In quali modi questo circuito potrebbe guastarsi, e cosa succede se succede?” Per esempio, cosa succede se il sensore di temperatura va in cortocircuito (cioè i suoi due terminali si collegano accidentalmente all’interno)? Farebbe solo leggere al sensore un valore estremo, o potrebbe danneggiare l’intera scheda assorbendo troppa corrente? Ponendo presto queste scomode domande “what-if”, potete aggiungere protezioni o decidere se il rischio è accettabile. Questo tipo di pensiero lungimirante rende il dispositivo più affidabile nel lungo periodo.

Nel frattempo – ed è qui che entra in gioco il lavoro parallelo – il team software/firmware non deve aspettare inattivo che l’hardware sia finito. Sulla base dello schematico, i firmware engineer possono iniziare a creare un HAL (Hardware Abstraction Layer) o almeno uno scheletro di esso. In sostanza, preparano le interfacce software per le periferiche del microcontrollore (timer, interfacce di comunicazione come I2C o SPI per quei sensori, ecc.). Potrebbero persino scrivere unit test o codice di simulazione per questi driver su un PC. Immaginate uno sviluppatore che scrive codice che simula le letture dei sensori solo per testare la logica – in questo modo, il team firmware sta già costruendo le fondamenta. Così, quando arriva la scheda vera, gran parte della struttura del codice è pronta e in attesa di essere provata sull’hardware reale. Questo sforzo parallelo significa che i software engineer non si stanno girando i pollici; stanno gettando le basi che renderanno più facile il bring-up dell’hardware in seguito.

PCB layout: dallo schematico alla scheda fisica

Una volta che il design dello schematico è finalizzato e revisionato, è il momento di trasformare quel progetto elettronico in un circuito stampato reale. Questa è la fase di PCB layout. Usando un altro set di strumenti CAD (spesso la stessa suite usata per gli schematici, come Altium o KiCad, che può passare alla modalità layout), l’ingegnere posiziona il footprint di ogni componente su una scheda virtuale e inizia a instradare le piste di rame che collegano tutto. Se lo schematico è il progetto, il PCB layout è il passo in cui decidete esattamente come quella città di componenti apparirà fisicamente – come decidere dove si trova ogni edificio e come correranno le strade (piste) tra di essi sul territorio reale della scheda.

Il risultato del PCB layout è un insieme di file (i famosi Gerber file) che i produttori usano per fabbricare la scheda. Un altro output utile è un modello 3D (spesso un file STEP) della scheda. Questo modello 3D è particolarmente utile sul lato del design meccanico – potete importarlo nel design del contenitore per verificare che la scheda e tutti i suoi componenti entrino nell’alloggiamento del prodotto senza collisioni (nessuno vuole un connettore USB che sporge dove il case non ha fori!).

Durante il PCB layout, è fondamentale tenere a mente le linee guida di Design for Manufacturing (DFM) e Design for Test (DFT). In termini semplici, DFM significa progettare la scheda in modo che possa essere prodotta in modo affidabile ed economico, e DFT significa progettarla in modo che possa essere testata facilmente in seguito.

Per esempio:

• DFM: Evitate di posizionare componenti troppo vicino al bordo della scheda o così fitti da far faticare le macchine di assemblaggio a saldarli. Assicuratevi che il layout possa essere prodotto senza problemi.
• DFT: Aggiungete test pad o un connettore speciale così da poter collegare attrezzature di test o programmatori alla scheda in produzione. In questo modo, ogni unità che esce dalla linea può essere controllata facilmente (immaginate una comoda presa per programmare il firmware o misurare i segnali su ogni dispositivo).

È molto più facile includere queste misure ora che accorgersi dopo di avere mille unità finite senza un modo semplice di verificare se sono pienamente funzionanti!

Molti team usano una checklist durante il layout per assicurarsi che nulla sia dimenticato – cose come aggiungere i fiducial (piccoli segni che aiutano le macchine di assemblaggio automatizzate ad allineare la scheda), mantenere clearance adeguate tra le parti ad alta tensione, etichettare i connettori importanti, e così via.

Mentre il team hardware è impegnato a instradare piste e a sudare sui dettagli della scheda, lo sforzo software parallelo continua. Il team firmware, conoscendo i modelli esatti di sensori e componenti dallo schematico, può iniziare a scrivere il codice dei driver veri (o almeno dei placeholder) contro i datasheet di quei componenti. Potrebbero usare emulatori di sensori o scrivere codice fittizio che imita ciò che il sensore farebbe. Anche il team cloud/backend, se il vostro prodotto IoT ne ha uno, può portarsi avanti: per esempio, configurando un database cloud di base e gli endpoint API per ricevere dati dal dispositivo. In sostanza, tutti stanno preparando la loro parte del puzzle così che quando arrivano le prime schede fisiche, non sia un avvio a freddo per il resto del team. Quando il design del PCB viene inviato per la fabbricazione, il vostro firmware potrebbe già avere un “hello world” pronto per la scheda e il vostro cloud potrebbe avere un piccolo server di test in attesa di registrare il primo dato del dispositivo. Questo sviluppo concorrente accorcia davvero il ciclo di iterazione in seguito.

Costruzione del prototipo: dare vita all’hardware

Con il PCB layout completato e controllato, è ora il momento di passare dai file digitali agli oggetti fisici. Il primo passo è far fabbricare le schede. Tipicamente, inviate quei Gerber file a un PCB fab (ci sono molti produttori di PCB quick-turn che possono produrre schede in pochi giorni). In parallelo, vorrete assicurarvi che tutti i componenti che vanno sulla scheda (il microcontrollore, i sensori, i chip, ecc.) siano disponibili. Consiglio pratico: Ordinate i componenti critici o a lungo lead time appena siete sicuri del vostro schematico e della selezione dei componenti! Durante le carenze globali di chip, molti team l’hanno imparato a proprie spese – non volete aspettare 12 settimane per un particolare sensore o chip radio mentre le vostre schede restano lì vuote.

Una volta che avete i PCB nudi e tutti i componenti, assemblate alcune unità prototipo. Questo può essere fatto internamente se avete un laboratorio ben attrezzato e una mano ferma per la saldatura, oppure potete usare un servizio di assemblaggio per saldare tutti quei minuscoli componenti. Il risultato è un set (spesso una piccola manciata, da 1 a 5 schede) di dispositivi prototipo.

Ora arriva uno dei momenti più eccitanti (e snervanti) dello sviluppo hardware: il bring-up, che è il termine semplice per la prima volta che accendete la scheda e vedete se funziona. È comune farlo con cautela – per esempio, usando un alimentatore da banco con limite di corrente per evitare di friggere tutto se c’è un cortocircuito da qualche parte. Tutti in laboratorio potrebbero trattenere il fiato mentre girate l’interruttore. La scheda si accende senza lasciar uscire il fumo magico dei componenti bruciati? (Si spera di sì!)

Dopo l’accensione, verificate metodicamente le basi. Tutte le rail di alimentazione sono alle tensioni previste? (Controllate con un multimetro o un oscilloscopio.) Il microcontrollore (MCU) si sveglia ed esegue codice? Un classico primo test è spesso verificare se gira un semplice firmware che fa lampeggiare un LED o invia un messaggio “Hello, world” su una porta seriale. Se vedete quel LED lampeggiare o ricevete quel messaggio sul computer, è una vera milestone – significa che il cuore della vostra scheda è vivo e vegeto.

Poi, testerete la comunicazione con le periferiche chiave: l’MCU riesce a parlare col sensore via I2C o SPI come previsto? I sensori restituiscono dati ragionevoli? È in questa fase che potreste scoprire problemi. Magari un sensore non legge a causa di un errore di cablaggio o di un sottile bug del firmware. Il bring-up è un gioco da detective, in cui hardware engineer e firmware engineer lavorano insieme per risolvere qualsiasi problema. Per esempio, se la lettura della temperatura è sempre zero, il firmware engineer potrebbe fare debug del codice mentre l’hardware engineer verifica le connessioni col multimetro – insieme capiranno se è un problema di inizializzazione software o se magari le linee SDA e SCL del sensore sono state scambiate sul PCB.

Durante il bring-up del prototipo, state anche attenti a eventuali problemi di alimentazione o termici. Qualcosa scalda più del dovuto? (Consiglio pratico: toccare con cautela i chip per sentire il calore o usare una telecamera a infrarossi può intercettare i punti caldi.) La scheda sta assorbendo più corrente del previsto (il che potrebbe indicare che qualcosa è cablato male o che un componente è difettoso)? Questi test assicurano che il vostro prototipo non solo funzioni, ma sia anche sicuro e operi entro i parametri previsti.

Se il vostro dispositivo è destinato a comunicare in wireless o a soddisfare certi standard normativi (come le emissioni FCC per i gadget wireless negli USA), questa fase di prototipo è un buon momento per fare un po’ di pre-compliance testing. Questo potrebbe significare portare il dispositivo in un laboratorio per una scansione preliminare delle emissioni in radiofrequenza per intercettare presto i grandi problemi. Non volete scoprire al test di certificazione finale che la vostra scheda si comporta come un trasmettitore radio accidentale su una frequenza non approvata!

Mentre il team hardware è impegnato col bring-up, il team firmware è ora in piena attività a testare il proprio codice sul dispositivo reale. Tutti quei driver e componenti HAL iniziati prima possono essere caricati sulla scheda vera. È qui che il firmware potrebbe aver bisogno di un po’ di tuning – magari le assunzioni di timing erano un po’ sbagliate, o un interrupt va aggiustato ora che è su silicio reale. Se state usando un RTOS (Real-Time Operating System) sul microcontrollore, è qui che iniziate a regolare priorità o timing dei task, dato che sull’hardware reale potete osservare le prestazioni effettive. Il team cloud potrebbe anche vedere i primi dati reali attraversare il sistema! Per esempio, il prototipo potrebbe effettivamente inviare una lettura di temperatura a un server di test, confermando che l’intero flusso end-to-end (dispositivo -> cloud -> database) funziona almeno su piccola scala.

La Fase 3 spesso comporta alcune iterazioni. È raro azzeccare tutto al primo colpo – ed è completamente normale. Potreste trovare un errore sulla scheda (come una pista sbagliata o un errore di footprint di un componente) che richiede una piccola riparazione chirurgica sui prototipi (ecco i bodge wire e le riparazioni di fortuna!), oppure potrebbe essere abbastanza significativo da giustificare una revisione del PCB per il prossimo giro di prototipi. Ogni iterazione è un’occasione per migliorare: magari riposizionate un connettore difficile da raggiungere, o ritoccate il circuito per ridurre il rumore su una lettura del sensore, ecc. Non scoraggiatevi per le iterazioni necessarie; sono previste nello sviluppo hardware.

Durante tutta questa fase, la stretta collaborazione tra i team hardware e software è vitale. Quando sorge un problema, entrambe le parti devono mettersi il cappello da detective e lavorare insieme. Il sensore non legge perché il firmware è sbagliato, o c’è un ponte di saldatura che manda in corto qualcosa sul PCB? Comunicando risultati e ipotesi, il team può centrare il problema più velocemente. Questa risoluzione collaborativa dei problemi è una delle parti più formative del processo – e spesso rafforza la comprensione del prodotto nel suo insieme da parte del team.

Inoltre, tenete un occhio al futuro: se pianificate di produrre eventualmente questo prodotto su scala, usate questa fase di prototipo per pensare alla produzione e al testing nel lungo periodo. Ricordate DFM e DFT? Ora è il momento di validare quelle decisioni. Per esempio, se avete incluso un header di programmazione, provate a usarlo in un test di produzione simulato: riuscite a collegarvi e programmare la scheda facilmente? Se avete aggiunto test pad, sono accessibili a un bed-of-nails tester? È molto più facile aggiustare il vostro design per la testabilità ora che quando avete una linea di produzione in funzione.

Alla fine della Fase 3, dovreste avere uno o più dispositivi prototipo funzionanti e un solido insieme di lezioni apprese. Avrete dati iniziali sulle prestazioni (quanta energia assorbe davvero il vostro dispositivo? Il sensore funziona in modo accurato in condizioni reali?). Probabilmente avrete anche un elenco di correzioni o miglioramenti per la prossima versione. Cosa più importante, avete costruito la base fisica del vostro prodotto IoT – qualcosa che potete tenere in mano e che funziona davvero.

Quando quel primo prototipo finalmente prende vita e invia dati come previsto, una piccola celebrazione è ben meritata – la maggior parte degli hardware engineer ha sentito un guizzo del “È vivo!” del Dr. Frankenstein in quel momento. Prendetevela. L’hardware è difficile, e avete appena superato una milestone importante sulla strada dall’idea alla realtà.