Come valutare un partner per lo sviluppo di sistemi embedded e IoT

Un imprenditore nel settore hardware, che dispone di un prototipo funzionante e deve rispettare una scadenza di produzione, si pone una domanda fondamentale prima di firmare un contratto di ingegneria: questo team è davvero in grado di trasformare un prodotto connesso, partendo da una breadboard, in un dispositivo certificato e pronto per la commercializzazione? Un responsabile tecnico che sta integrando sensori IoT in una macchina esistente si pone una versione più circoscritta della stessa domanda, incentrata sul fatto che il partner comprenda sia l’hardware fisico sia la piattaforma cloud in cui i dati andranno a finire.

Lo sviluppo di sistemi embedded e IoT si colloca all’incrocio tra diverse discipline ingegneristiche contemporaneamente: progettazione hardware, firmware, connettività wireless, infrastruttura cloud e, spesso, progettazione meccanica. Valutare un partner per questo tipo di lavoro significa verificare che possieda una competenza reale e verificabile su tutto lo stack, non solo un portfolio di loghi. Questa guida illustra in dettaglio cosa comporti effettivamente lo sviluppo di sistemi embedded e IoT, i criteri specifici che distinguono un partner competente da uno rischioso e le domande che vale la pena porre prima di affidare il budget e la roadmap di prodotto a un team esterno. Monarch Innovation collabora con team hardware e di prodotto proprio in questo tipo di ingegneria multidisciplinare, che costituisce il filo conduttore su cui si basa questa guida.

01Cosa comprendono effettivamente i sistemi embedded e lo sviluppo dell'IoT

Lo sviluppo di sistemi embedded consiste nel progettare e scrivere il software che gira direttamente su un componente hardware, controllando il modo in cui un dispositivo rileva, elabora e risponde in tempo reale. Si distingue dallo sviluppo di applicazioni generiche perché deve operare entro limiti prestabiliti in termini di memoria, alimentazione e potenza di elaborazione, e perché eventuali bug possono influire sul comportamento fisico del dispositivo anziché limitarsi a un semplice schermo.

Lo sviluppo dell’IoT estende lo stesso lavoro nel campo dell’embedded verso l’esterno, collegando un dispositivo a una rete in modo che possa inviare dati al cloud, ricevere comandi e interagire con altri sistemi. Un prodotto IoT completo si articola in genere su quattro livelli: l’hardware stesso, il firmware che vi gira sopra, il livello di connettività che gestisce l’invio e la ricezione dei dati dal dispositivo e il cloud o la piattaforma di backend che archivia, elabora e visualizza tali dati.

Un partner che eccelle in un unico ambito non è automaticamente competente in tutti e quattro. Molte aziende specializzate in software embedded sviluppano firmware eccellenti ma affidano la progettazione hardware a terzi, mentre molti fornitori di soluzioni IoT orientati al cloud dispongono di competenze interne limitate in materia di hardware. I servizi di ingegneria di prodotto di Monarch Innovation coprono la progettazione hardware ed elettrica, i sistemi embedded e lo sviluppo IoT come discipline interconnesse piuttosto che come fasi separate, il che rappresenta uno dei primi aspetti da verificare in qualsiasi partner che si intenda valutare.

02Perché le aziende affidano in outsourcing lo sviluppo di sistemi embedded e IoT

Alcune pressioni ricorrenti spingono i team hardware e di prodotto a rivolgersi a un partner esterno specializzato in ingegneria, anziché sviluppare internamente ogni singolo livello.

• Lacune nelle competenze interdisciplinari: un team incentrato sul software che sviluppa un prodotto connesso dispone spesso di competenze di alto livello nel campo del firmware o del cloud, ma non ha esperienza interna nella progettazione hardware o di circuiti stampati (PCB); lo stesso vale, altrettanto comunemente, per i team incentrati sull’hardware.
• Competenze specialistiche a breve termine: un singolo prodotto potrebbe richiedere un protocollo wireless specifico, una particolare famiglia di microcontrollori o un percorso di certificazione con cui il team interno non ha mai avuto a che fare in precedenza e di cui non avrà più bisogno per anni.
• Rapidità nell’ottenere un dispositivo funzionante: assumere e formare internamente un team completo specializzato in sistemi embedded e IoT può richiedere più tempo di quanto consentito dalla roadmap del prodotto, soprattutto quando lo sviluppo dell’hardware e del firmware deve procedere in parallelo.
• Pressioni relative alla certificazione e alla conformità: per far superare a un dispositivo connesso i test FCC, CE o UL è necessario prendere decisioni di progettazione sin dalle prime fasi; affidarsi a un partner che abbia già affrontato tale processo in passato consente di evitare costose riprogettazioni nelle fasi finali del programma.

Il compromesso è che i progetti relativi all’embedded e all’IoT sono più difficili da trasferire rispetto al tipico outsourcing software. Un codice firmware legato a un hardware specifico, o un'architettura cloud costruita secondo le convenzioni di un partner, può risultare costoso da trasferire a un secondo team se il primo non dovesse funzionare. Ecco perché la scelta del partner ha qui un peso maggiore rispetto a lavori di ingegneria meno dipendenti dall'hardware.

03Cosa cercare in un partner per lo sviluppo di sistemi embedded e IoT

Una volta individuati i livelli di cui il vostro prodotto ha bisogno, valutate un potenziale partner sulla base di criteri specifici e verificabili, piuttosto che basandovi su un’impressione generale ricavata da un colloquio di vendita.

Copertura multidisciplinare: chiedete direttamente se gli ingegneri specializzati in hardware, firmware, connettività e cloud lavorino insieme allo stesso progetto o se vengano subappaltati separatamente. Un team che progetta il circuito stampato e scrive il firmware in modo coordinato tende a individuare i problemi di integrazione, come ad esempio un sensore che assorbe più energia di quella per cui la scheda è stata progettata, prima che questi raggiungano la fase di prototipo.

Protocollo e profondità di connettività: verificate che il partner abbia un’esperienza concreta e comprovata con la specifica tecnologia wireless richiesta dal vostro prodotto, che si tratti di Bluetooth Low Energy per un dispositivo indossabile alimentato a batteria, di LoRaWAN o rete cellulare per sensori industriali a lungo raggio, oppure di Wi-Fi e Zigbee per dispositivi per la casa intelligente. Ogni protocollo presenta diversi compromessi in termini di potenza, portata e costo, e un partner dovrebbe essere in grado di spiegare perché uno si adatta meglio al vostro caso d’uso rispetto a un altro, anziché propendere automaticamente per quello che conosce meglio.

Pratiche di sicurezza per i dispositivi connessi: un prodotto connesso è anche un endpoint di rete, e una sicurezza insufficiente del dispositivo può esporre l’intero parco dispositivi ad attacchi. Le linee guida sulla sicurezza informatica dell’IoT del National Institute of Standards and Technology delineano le pratiche di base che i produttori dovrebbero integrare in un dispositivo fin dalla fase di progettazione, tra cui l’identificazione sicura, la protezione dei dati e i meccanismi di aggiornamento. Chiedete a un potenziale partner come gestisce l’avvio sicuro, la comunicazione crittografata e la firma degli aggiornamenti over-the-air, non limitandovi a domandare se “prende sul serio la sicurezza”.

Supporto per la certificazione e la conformità: i dispositivi che trasmettono segnali radio richiedono generalmente la certificazione FCC negli Stati Uniti e la marcatura CE in Europa; per molte categorie di prodotti, a ciò si aggiungono anche i test di sicurezza UL. Un partner con esperienza diretta nei test di pre-conformità può segnalare problemi di progettazione, come un problema di posizionamento dell’antenna o una traccia ad alta velocità non schermata, mesi prima che si verifichi un costoso fallimento della certificazione.

Approvvigionamento dei componenti e consapevolezza dell'obsolescenza: i tempi di consegna dei semiconduttori e la cessazione della produzione di alcuni componenti possono bloccare un programma hardware anche molto tempo dopo il completamento della progettazione. Un partner che prenda in considerazione componenti di seconda fonte e tempi di consegna realistici già in fase di progettazione, e non solo dopo che si è verificata una carenza, riduce notevolmente tale rischio.

Esperienza nell'integrazione con il cloud e il backend: se il prodotto richiede una dashboard, strumenti di analisi o la gestione della flotta, assicurati che il partner abbia una reale esperienza nel collegare dispositivi integrati a una piattaforma cloud, compresa la configurazione dei dispositivi su larga scala e la gestione efficiente della connettività intermittente, anziché limitarsi a sviluppare solo la parte relativa ai dispositivi e considerare il cloud come un problema di qualcun altro.

Modello di organico e ingegneri designati: chiedete specificatamente chi lavorerà al progetto e se tali ingegneri rimarranno assegnati alle fasi relative all’hardware, al firmware e alla connettività. La continuità è più importante nel lavoro embedded che nella maggior parte dei progetti software, poiché un cambio di personale a metà progetto spesso comporta dover reimparare da zero sia i vincoli hardware che l’architettura del firmware. La precedente guida di Monarch Innovation sul confronto tra l’aumento del personale e un team di ingegneri dedicato approfondisce questo aspetto relativo alla gestione del personale per i team che stanno valutando quale modello sia più adatto a un programma hardware in corso.

Tutela della proprietà intellettuale: i prodotti embedded e IoT spesso traggono il loro vero valore competitivo dal firmware e dall’architettura di sistema. Chiedete in modo specifico come il partner gestisce la titolarità del codice sorgente, i controlli di accesso e la riservatezza, e ottenete per iscritto i termini relativi alla cessione della proprietà intellettuale prima dell’inizio dei lavori di progettazione.

Documentazione e procedure di consegna: verificate ciò che ricevete al completamento del progetto: schemi, file di layout dei PCB, codice sorgente del firmware con commenti, rapporti di collaudo e documentazione di certificazione. Un partner che non è in grado di descrivere chiaramente il proprio processo di consegna è un partner dal quale potreste avere difficoltà a separarvi in seguito, anche se il lavoro ingegneristico in sé è di ottima qualità.

04Lista di controllo per la valutazione dei partner nel settore dell'embedded e dell'IoT

05Domande da porre prima di firmare un contratto

Una serie di domande brevi e dirette durante la valutazione permette di individuare la maggior parte dei rischi prima che questi si trasformino in problemi contrattuali.

1. Quali ingegneri, nello specifico, si occuperanno dell’hardware, del firmware e della connettività, e rimarranno assegnati a questi compiti per tutta la durata del programma?
2. Quali protocolli wireless e piattaforme cloud avete effettivamente implementato in produzione, e non solo realizzato come prototipi?
3. Come gestite la sicurezza dei dispositivi, compresi l’avvio sicuro, le comunicazioni crittografate e l’integrità degli aggiornamenti OTA?
4. Qual è la vostra esperienza in materia di certificazioni FCC, CE o UL? Potreste fornirci un esempio di progetto simile?
5. Come si pianifica in base ai tempi di consegna dei componenti e al ricorso a fornitori alternativi durante la fase di progettazione, e non solo dopo che si è verificata una carenza?
6. Di quali codici sorgente, schemi e documentazione saremo proprietari al termine del progetto, e in quale formato?
7. Come si fa a coordinare i team responsabili dell'hardware, del firmware e del cloud se non sono composti dalle stesse persone?
8. Potresti fornirci dei riferimenti relativi a un prodotto che sia effettivamente entrato in produzione e abbia ottenuto la certificazione, e non solo a un prototipo funzionante?

Un partner che risponde a queste domande fornendo dettagli concreti, anziché limitarsi a rassicurazioni generiche, è solitamente la scelta più sicura.

06Errori comuni nell'esternalizzazione dello sviluppo di sistemi embedded e IoT

Quando l’outsourcing nel settore dell’embedded e dell’IoT va a finire male, si riscontrano ripetutamente alcuni schemi ricorrenti. La suddivisione di hardware e firmware tra due fornitori non collegati tra loro è uno dei casi più comuni, poiché i problemi di integrazione emergono in una fase avanzata e nessuno dei due team si assume pienamente la responsabilità della risoluzione. Un altro errore è quello di scegliere un partner basandosi su una demo convincente della piattaforma cloud, trascurando però la sua effettiva esperienza in materia di hardware e certificazioni, in particolare per i prodotti in cui il dispositivo fisico comporta la maggior parte del rischio ingegneristico. Rimandare una discussione approfondita sulla sicurezza fino a quando la progettazione non è terminata tende a costringere a costose rielaborazioni, poiché l’avvio sicuro e la comunicazione crittografata sono molto più difficili da implementare a posteriori che da integrare fin dall’inizio. Sottovalutare i tempi di certificazione è un quarto errore, che si verifica quando un’azienda considera i test FCC o CE una formalità finale anziché un processo che dovrebbe influenzare le decisioni di progettazione già mesi prima. Infine, lasciare indefiniti la titolarità della proprietà intellettuale e il trasferimento della documentazione fino alla fine del progetto crea esattamente il tipo di problema di dipendenza che l’outsourcing avrebbe dovuto evitare.

07Realizzare un prodotto connesso con il partner tecnico giusto

Il successo o il fallimento dello sviluppo di sistemi embedded e IoT dipende dalla solidità del partner che li sostiene, più che nella maggior parte degli altri tipi di outsourcing ingegneristico. Il lavoro abbraccia discipline quali hardware, firmware, connettività e cloud che raramente coesistono sotto lo stesso tetto, e un anello debole in una qualsiasi di esse può bloccare un prodotto anche molto tempo dopo la firma del contratto. Verificare la reale copertura multidisciplinare, l’esperienza in materia di sicurezza e certificazioni, la competenza nell’approvvigionamento dei componenti e la chiarezza dei termini relativi alla proprietà intellettuale e alla documentazione è ciò che distingue un percorso agevole verso la produzione da un programma che si arena in fase di test.

Monarch Innovation supporta i team dedicati all’hardware e ai prodotti in ambiti quali la progettazione meccanica, l’ingegneria hardware ed elettrica, i sistemi embedded e lo sviluppo IoT, fungendo da unico punto di contatto tra discipline che spesso sono suddivise tra fornitori diversi. Se state progettando un prodotto connesso e state valutando se il vostro team sia in grado di gestire internamente l’intero stack, contattate Monarch Innovation per discutere con il nostro team di ingegneri delle vostre esigenze relative a hardware, firmware e connettività.

08Parla con un esperto di sistemi embedded e IoT

Stai sviluppando un prodotto connesso e hai bisogno di competenze in materia di hardware, firmware o integrazione cloud? Contatta Monarch Innovation per discutere con il nostro team di ingegneri delle tue esigenze relative ai sistemi embedded o allo sviluppo IoT.

09Domande frequenti

1. Di cosa si occupa effettivamente un partner per lo sviluppo di sistemi embedded e IoT?

Un partner per lo sviluppo di sistemi embedded e IoT progetta e realizza l'hardware, il firmware, la connettività e, spesso, l'integrazione cloud alla base di un prodotto connesso. Ciò può riguardare un singolo livello, come il firmware per un circuito stampato esistente, oppure l'intero stack, dalla progettazione del PCB fino alle dashboard cloud, a seconda di ciò che il prodotto e il team interno hanno già a disposizione.

2. Come posso valutare un partner per l'outsourcing di sistemi embedded?

Verificate che vi sia un’esperienza concreta e specifica nelle discipline richieste dal vostro prodotto, tra cui hardware, firmware, il protocollo wireless specifico utilizzato e, se del caso, l’integrazione con il cloud. Informatevi sulle pratiche di sicurezza, sulla storia delle certificazioni FCC, CE o UL, sulla strategia di approvvigionamento dei componenti e su quale documentazione e codice sorgente riceverete al completamento del progetto.

3. Perché l'outsourcing nel settore dell'embedded e dell'IoT è più rischioso rispetto al tradizionale outsourcing nel settore del software?

I prodotti embedded e IoT legano strettamente il firmware a un hardware specifico, pertanto è più difficile sostituire un partner inadeguato nel corso di un progetto rispetto alla maggior parte dei lavori di sviluppo software. Anche i requisiti di certificazione, i tempi di consegna dei componenti e i cicli di prototipazione fisica comportano rischi e costi che non sussistono nell’outsourcing basato esclusivamente sul software.

4. Quali standard di sicurezza si applicano allo sviluppo dei dispositivi IoT?

L'Istituto Nazionale di Standard e Tecnologia (NIST) pubblica linee guida fondamentali in materia di sicurezza informatica destinate ai produttori di dispositivi IoT, che trattano aspetti quali l’identificazione sicura dei dispositivi, la protezione dei dati e i meccanismi di aggiornamento sicuri. Un partner di sviluppo competente dovrebbe essere in grado di spiegare in modo concreto in che modo il proprio processo di progettazione tenga conto di tali aspetti, anziché considerare la sicurezza come un elemento secondario.

5. Tutti i prodotti IoT devono avere la certificazione FCC o CE?

La maggior parte dei dispositivi che trasmettono segnali radio necessita della certificazione FCC negli Stati Uniti e della marcatura CE in Europa; inoltre, molte categorie di prodotti richiedono anche i test di sicurezza UL. I requisiti variano a seconda del tipo di dispositivo e del mercato di destinazione, pertanto verificare con anticipo, nelle prime fasi del processo di progettazione, l’esatto percorso di certificazione aiuta a evitare modifiche al progetto in fasi successive.

6. È meglio affidarsi a un unico partner per l'hardware, il firmware e il cloud, oppure a specialisti distinti?

Avere un unico referente che si occupi di tutti e tre i livelli all’interno di un unico team riduce in genere gli errori di integrazione e le accuse reciproche quando qualcosa non funziona come previsto. Specialisti separati possono comunque lavorare bene se l’azienda dispone di una solida leadership tecnica interna in grado di coordinare i passaggi di consegne tra loro, ma l’onere di tale coordinamento dovrebbe essere pianificato in anticipo, piuttosto che emergere a metà progetto.

7. Quali aspetti relativi alla proprietà intellettuale dovrei chiarire prima di scegliere un partner per lo sviluppo di sistemi embedded?

Chiedete direttamente in che modo il partner gestisce la titolarità del codice sorgente, i controlli di accesso durante lo sviluppo e quali condizioni relative alla cessione della proprietà intellettuale sono previste nel contratto. Assicuratevi di ottenere queste condizioni per iscritto prima dell’inizio dei lavori di progettazione, poiché i prodotti embedded e IoT presentano spesso un notevole valore competitivo nel loro firmware e nell’architettura di sistema.