La sfida
Il progetto riguardava il controller centrale di una piattaforma di building automation, dove elettronica, protocolli di campo, logiche locali e servizi remoti dovevano funzionare come parti dello stesso prodotto.
La difficoltà non era sviluppare firmware e software separatamente, ma mantenere coerenti livelli con vincoli molto diversi: microcontrollore real-time, Linux embedded, servizi edge, protocolli, deployment e strumenti di produzione.
Il prodotto doveva inoltre poter essere diagnosticato, aggiornato, programmato e verificato in modo ripetibile lungo il suo ciclo di vita.
Come unico sviluppatore embedded ho seguito questa catena dal firmware STM32 fino agli strumenti di collaudo di produzione, collaborando con backend cloud, frontend, UX/UI e system integration.
Dal microcontrollore al prodotto
Sul microcontrollore rimanevano le funzioni più vicine all’hardware: acquisizione, GPIO, bus, memoria non volatile, watchdog, diagnostica e supervisione del sistema.
Il sistema Linux gestiva invece protocolli, servizi applicativi, persistenza, API, comunicazione real-time e integrazione con i servizi remoti.
Ho lavorato anche sulla piattaforma Linux embedded, personalizzando il sistema operativo e integrando le interfacce hardware e i servizi del prodotto.
Il punto centrale era mantenere interfacce esplicite fra i diversi livelli, in modo che stati, errori e funzioni diagnostiche potessero essere riutilizzati anche durante integrazione e produzione.
Tre decisioni di progetto
Ogni funzione al livello giusto
Il microcontrollore gestiva ciò che richiedeva vicinanza all’hardware e comportamento prevedibile; Linux ospitava le funzioni che richiedevano maggiore capacità di elaborazione e integrazione.
Decisione: separare MCU ed edge Linux per responsabilità, mantenendo un’interfaccia chiara fra i due livelli.
Diagnostica fin dall’architettura
Il firmware esponeva un’interfaccia diagnostica utilizzabile sia dal software Linux sia dagli strumenti automatici di test.
Le stesse funzioni permettevano di identificare il dispositivo, verificare periferiche e comunicazioni, leggere grandezze hardware ed esercitare le interfacce durante sviluppo e collaudo.
Decisione: progettare la diagnostica come parte del prodotto, non come strumento aggiunto a sviluppo concluso.
Progettare anche per il test
La produzione richiedeva molto più di un semplice flashing: alimentazioni, bus, periferiche, firmware, host Linux e funzioni fisiche dovevano poter essere esercitati e verificati insieme.
Per questo testabilità e strumenti di collaudo sono stati sviluppati insieme al prodotto.
Decisione: trattare il collaudo come parte dell’architettura e dell’industrializzazione.
Dal prodotto alla produzione
Ho sviluppato una piattaforma automatica di collaudo che coordinava fixture, interfacce di comunicazione, firmware di test, misure, flashing e software.
Le sequenze erano configurabili come dati, permettendo di modificare verifiche, soglie e flussi senza riscrivere il motore di test.
Fixture dedicate, con firmware sviluppati per il collaudo, permettevano di esercitare e verificare automaticamente hardware e interfacce.
Il processo integrava anche flashing, test di comunicazione, computer vision per verifiche visive, reporting, serializzazione e stampa delle etichette.
La piattaforma riuniva verifiche elettriche, firmware e software in un processo di collaudo di produzione ripetibile e gestito dalla stessa infrastruttura.
Deployment e manutenzione
I servizi edge erano distribuiti come stack multi-architettura con build e pubblicazione automatizzate.
Ho sviluppato inoltre strumenti per provisioning, diagnostica e aggiornamento capaci di interagire sia con Linux sia con il microcontrollore.
L’obiettivo era evitare che configurazione, aggiornamento e manutenzione dipendessero da procedure manuali frammentate o conoscenze implicite.
Il risultato
Il risultato è una piattaforma embedded nella quale firmware, Linux, software edge e strumenti di produzione condividono interfacce e diagnostica progettate lungo lo stesso ciclo di sviluppo.
Il prodotto può essere osservato attraverso i diversi livelli, aggiornato e configurato con strumenti dedicati e programmato e verificato attraverso un processo di collaudo ripetibile.
Gli stessi meccanismi introdotti durante lo sviluppo vengono riutilizzati durante integrazione e produzione, riducendo le zone grigie fra firmware, Linux, software applicativo e fabbrica.
Il valore del progetto sta nell’aver seguito il prodotto attraverso livelli normalmente affidati a competenze separate, dal comportamento del microcontrollore fino alla programmazione e verifica dell’hardware in produzione.
Tecnologie
Firmware & real-time
C · STM32 · FreeRTOS · HAL / LL · ADC · GPIO · I²C · UART · USB CDC · CAN · Watchdog · Non-volatile memory
Protocols & interfaces
CAN · KNX · Modbus · RS-485 · UART · I²C · USB · Ethernet · REST · WebSocket / Socket.IO
Embedded Linux
Embedded Linux · Custom Linux platform · Hardware interface integration · systemd · Provisioning
Edge software
Node.js · TypeScript · NestJS · MongoDB · REST APIs · Real-time events · Device orchestration
Deployment & maintenance
Docker · Docker Compose · CI/CD · Containerized deployment · Multi-architecture builds · Update tooling
Production test
Python · Flask · PySerial · OpenCV · Configurable test sequences · Fixture firmware · Electrical measurements · Automated flashing · Reporting · Serialisation · Label printing
Integration & industrialisation
System architecture · HW/FW/SW integration · Design for Test · Diagnostics · Troubleshooting · Provisioning · Test automation · Production readiness