Un pruduttu cunnessu pò parè finitu assai prima chì l'ingegneria intornu à ellu sia cumpleta. U prototipu hè stabile, i dati ghjunghjenu à u cloud, l'applicazione mostra i valori ghjusti, è u primu batch di dispositivi hè digià in manu à l'utilizatori. À quellu puntu, u backend pò esse ancu abbastanza simplice chì a squadra cunnosce guasi ogni dispositivu individualmente. U provisioning pò esse gestitu cù un script, i cambiamenti di cunfigurazione ponu esse fatti manualmente, è se qualcosa falla, un ingegnere pò generalmente traccià u prublema direttamente.
Dopu, deve cumincià à campà in u mondu reale. Apparisce una seconda revisione di l'hardware. Certi clienti utilizanu sempre a prima revisione. E versioni di u firmware cumincianu à diverge. Una nova cunfigurazione hè necessaria per un cliente o un mercatu differente, mentre chì i dispositivi più vechji anu sempre bisognu di aghjurnamenti è supportu.
Nunda hè necessariamente rottu. U software daretu à u dispusitivu hà simpliciamente acquistatu un ciclu di vita propiu.
Quella transizione hè faciule da mancà perchè u prototipu pò cuntinuà à funziunà perfettamente bè. Ma una volta chì parechje versioni di u listessu pruduttu fisicu devenu coesiste in u campu, u backend ùn hè più solu l'infrastruttura daretu à l'hardware. Diventa parte di l'architettura di u pruduttu stessu.
Un prototipu cunnessu funzionale ùn hè ancu un pruduttu scalabile
Un prototipu hà un compitu impurtante: dimustrà chì u sistema funziona da un principiu à l'altru. U dispusitivu svolge a so funzione principale, u firmware cumunica cù u backend, a telemetria ghjunghje induve deve, i cumandamenti facenu u viaghju di ritornu, è una interfaccia mobile o web espone a funziunalità à un utilizatore.
Ciò chì di solitu ùn hà micca dimustratu hè quantu bè u listessu sistema gestisce a varietà.
I primi vinti dispusitivi ponu tutti eseguisce u listessu firmware, esse custruiti cù a listessa revisione hardware è esse cunfigurati da i stessi ingegneri. À quellu stadiu, a registrazione manuale, i cambiamenti diretti di cunfigurazione, o un picculu script d'integrazione ponu esse cumpletamente sensati. Custruisce strumenti di qualità di pruduzzione prima chì u pruduttu si sia pruvatu pò esse prematuru.
A scala cambia u prublema. I dispusitivi stanu fora di linea, sò rimpiazzati, eseguiscenu firmware diversi è richiedenu diverse cunfigurazioni di i clienti. L'assistenza deve distingue un'unità chì ùn hè mai stata furnita currettamente da una chì hè mal cunfigurata o semplicemente irraggiungibile.
U debitu di prototipu spessu principia cusì: micca cù una mala decisione, ma cù una decisione tempuranea chì ferma in piazza dopu chì u pruduttu hè andatu avanti. È una di e prime cose chì forza sta transizione in vista hè l'hardware stessu. Una nova revisione ùn rimpiazza micca solu quella vechja; deve coesiste cun ella.
Ogni revisione di hardware crea un prublema di u ciclu di vita di u software
Una nova revisione di l'hardware raramente ghjunghje cum'è un rimpiazzamentu pulitu per quella vechja. In pratica, e duie versioni restanu in u campu, qualchì volta per anni. Aggiungete un batch di transizione, uni pochi di rami di firmware è cunfigurazioni specifiche per u cliente, è a flotta diventa rapidamente più diversa di ciò chì u mudellu di u pruduttu originale suggerisce.
U stratu di software ùn pò più trattà ogni unità cum'è un "dispositivu" astrattu. Hà bisognu di sapè ciò chì quella unità particulare hè capace di fà.
Una scheda rivista pò aduprà un sensore, un modulu di cumunicazione o un controller differente. Un cumandamentu chì hè validu per l'ultima versione pò ùn esse supportatu da una versione precedente. I valori di calibrazione ponu cambià. I limiti di cunfigurazione ponu cambià. Un pacchettu di firmware adattatu per una generazione pò esse periculosu per un'altra.
L'ingegneri di prudutti fisichi travaglianu digià cusì. Dui cumpunenti chì parenu guasi identichi ùn sò micca intercambiabili se e so revisioni, tolleranze o specificazioni sò diverse. I prudutti cunnessi creanu u listessu prublema da u latu di u software: a piattaforma hà bisognu di un modu affidabile per capisce cù quale versione di u pruduttu fisicu parla è quali regule si applicanu.
Cunsiderate un pruduttu chì a so prima revisione usa una prucedura di calibrazione mentre chì a seconda introduce un novu sensore è un inseme di parametri sfarenti. Per u cliente, e duie unità ponu esse sempre u listessu pruduttu. Per a piattaforma, ùn ponu micca esse.
S'è ste differenze ùn sò micca rapprisentate esplicitamente, tendenu à filtrà in a logica di l'applicazione cum'è casi particulari. Un flussu di travagliu verifica un intervallu di numeri di serie. Un altru usa una versione di firmware cum'è proxy per a generazione di hardware. Un terzu cuntene una eccezione aghjunta dopu chì u supportu hà scupertu un batch più vechju chì si cumportava in modu diversu in u campu. Nisuna di queste correzioni pare particularmente periculosa per sè stessa, ma inseme rendenu ogni cambiamentu futuru più difficiule da ragiunà.
L'hardware più vechju raramente sparisce à tempu. E squadre di produttu si cuncentrenu naturalmente nantu à a revisione più recente, mentre chì i clienti spessu mantenenu e versioni precedenti assai più longu di ciò chì era previstu. A piattaforma deve dunque supportà parechje generazioni à tempu invece di suppone chì a basa installata cunvergerà mai nantu à un unicu statu attuale.
Una volta chì questu accade, l'evoluzione di l'hardware è a gestione di u ciclu di vita di u software diventanu inseparabili. A piattaforma hà bisognu di sapè micca solu induve si trova un dispositivu è s'ellu hè in linea, ma ciò chì hè, ciò chì pò eseguisce, cumu deve esse cunfiguratu è quali cambiamenti sò sicuri da applicà.
È prima chì una di queste dumande possi esse risposta in modu affidabile, ogni dispusitivu deve entre in u sistema in modu coerente.
U provisioning hè induve l'ingegneria manuale ferma a scalabilità
U furnimentu pare simplice quandu a flotta hè chjuca: creà un registru di u dispusitivu, inserisce un numeru di serie, generà credenziali, assignà l'unità à un cliente, applicà una cunfigurazione è cuntinuà. Per una decina di dispusitivi, gestisce una parte di questu manualmente pò esse sempre a scelta ghjusta.
À scala di pruduzzione, però, u provisioning si trova à l'intersezzione di l'identità di u dispusitivu, di e credenziali, di a pruprietà, di a cunfigurazione è di u statu di u ciclu di vita. Un errore fattu durante l'integrazione pò influenzà u modu in cui l'unità hè operata è supportata assai dopu avè lasciatu a fabbrica.
Una foglia di calculu pò ùn currisponde più à ciò chì hè veramente installatu. Un dispositivu di sustituzione hà bisognu di l'associazione di u cliente curretta senza eredità l'identità sbagliata. I reset di fabbrica creanu un altru percorsu attraversu u prucessu. Un installatore pò assignà un'unità à u contu sbagliatu, lascendu à l'assistenza u compitu di determinà s'ella hè offline, furnita in modu incorrectu, o semplicemente porta a cunfigurazione sbagliata.
Una volta chì risponde à queste dumande richiede di rutina à un sviluppatore di ispezionà una basa di dati o di eseguisce un script internu, u prucessu hà cessatu di scalà cù u pruduttu.
A duplicazione hè un altru segnu d'avvertimentu. Ogni variante di pruduttu principia à acquistà u so propiu script d'integrazione, strumentu di cunfigurazione o flussu di travagliu d'installazione. Queste differenze ponu sembrà chjuche, ma a rispunsabilità sottustante hè a listessa. U provisioning hè diventatu una infrastruttura di piattaforma riutilizzabile piuttostu chè un compitu di cunfigurazione attaccatu à un dispositivu particulare.
È raramente l'unica capacità chì hà bisognu di diventà riutilizzabile.
U stratu di piattaforma deve diventà una infrastruttura riutilizzabile
Una volta chì parechji prudutti o revisioni di hardware spartenu i stessi bisogni basi, alcune capacità di u software smettenu di esse specifiche di u pruduttu. L'identità di u dispusitivu, u provisioning, a cunnessione, a telemetria, a consegna di u firmware, u statu di u ciclu di vita, a visibilità di a flotta è a diagnostica sò boni esempi. A ricustruzzione di li per ogni nova variante crea più codice è più percorsi operativi da mantene senza rende u pruduttu stessu più distintivu.
E squadre raramente si mettenu à creà sta duplicazione. Piccule differenze s'accumulanu intornu à ogni pruduttu finu à chì a squadra mantene parechje implementazioni di ciò chì hè diventatu a listessa rispunsabilità d'ingegneria.
Una fruntiera più pulita hè di separà u stratu di u produttu da u stratu di a piattaforma. U stratu di u produttu cuntene u cumpurtamentu, i flussi di travagliu, l'interfacce, l'integrazioni è a logica di duminiu chì rendenu un dispositivu particulare preziosu. U stratu di a piattaforma gestisce a meccanica chì deve esse consistente ancu quandu l'hardware cambia.
À misura chì i prudutti cunnessi vanu oltre a so prima versione, u provisioning di dispositivi, a gestione di u ciclu di vita di i dispositivi, a gestione di a flotta è l'arnesi di supportu diventanu infrastrutture spartute piuttostu chè dettagli di prughjettu unichi. Un PaaS IoT per l'imprese pò furnisce quellu stratu di piattaforma riutilizzabile in parechji prudutti o varianti di prudutti, gestendu a gestione standard di dispositivi è dati attraversu blocchi di custruzzione riutilizzabili mentre e squadre d'ingegneria mantenenu u so sforzu persunalizatu focalizatu nantu à l'hardware, i flussi di travagliu è l'esperienza di l'utente.
Una basa cumuna deve sempre lascià spaziu per e vere differenze di produttu. Un novu dispositivu pò avè bisognu di un mudellu di dati, un flussu di cunfigurazione, una integrazione o una logica di cuntrollu sfarenti, è queste differenze devenu esse faciuli da intruduce. L'obiettivu hè simplicemente di evità chì ogni differenza si trascini longu à un altru registru di dispositivi, una pipeline di telemetria, un mecanismu di provisioning o un inseme di strumenti di gestione di flotta.
A piattaforma pò sembrà una sovraccarica mentre a squadra custruisce u primu pruduttu è cum'è un attivu per u secondu o u terzu. Una volta chì i meccanismi operativi cumuni sò in piazza, una nova variante pò eredita una basa funzionale invece di ghjunghje cù un altru backend chì a squadra duverà mantene per u restu di a vita di quellu pruduttu.
Mantene l'ingegneria persunalizata induve u pruduttu hè in realtà differente
Una piattaforma riutilizzabile ùn deve micca rende i prudutti cunnessi più generici. U so travagliu hè di caccià l'ingegneria ripetuta da e parte chì ùn creanu micca differenziazione.
U sforzu persunalizatu appartene sempre à u cumpurtamentu di u dispusitivu, a logica specifica di u duminiu, i flussi di travagliu, l'esperienza di l'utente, l'integrazioni spezializate è u modu in cui un pruduttu particulare interagisce cù u mondu fisicu. Quessi sò esattamente i duminii induve e scelte ingegneristiche ponu fà chì un pruduttu sia significativamente megliu cà un altru.
Ciò chì raramente merita u listessu trattamentu hè l'impianto idraulicu operativu circundante. Una versione basica è una versione industriale di a stessa macchina ponu avè bisognu di sensori, cuntrolli è interfacce diversi, ma ùn devenu micca richiede modi separati per identificà i dispositivi, seguità e versioni di firmware o gestisce una flotta.
Preferiscu vede l'ingegneri passà quellu tempu à affinà u cumpurtamentu di u pruduttu in u campu chè à ricustruisce a meccanica chì a squadra hà digià in piazza per un altru pruduttu. Una basa cumuna ùn riduce micca u scopu di l'ingegneria persunalizata; prutege quellu sforzu da esse cunsumatu da l'infrastruttura.
A vera prova vene quandu a squadra principia u pruduttu numeru dui.
Una bona piattaforma rende u prossimu pruduttu più faciule chè u primu
Sè u pruduttu numeru dui richiede guasi u listessu travagliu di piattaforma cum'è u pruduttu numeru unu, assai pocu hè statu riutilizatu.
Una nova variante duveria esse capace di eredità e parti di u mudellu operativu chì ùn sò micca cambiate: flussi di provisioning, identità, meccanica di u ciclu di vita, strumenti di flotta, prucessi di firmware, visibilità di supportu è integrazioni cumuni. U sforzu d'ingegneria si concentra tandu nantu à e differenze - forse un novu pacchettu di sensori, un altru flussu di travagliu di cuntrollu, o una integrazione specifica per u cliente - invece di ricustruisce a basa.
Una nova generazione di hardware mette a listessa idea sottu più pressione. E so capacità ponu cambià sustanzialmente mentre l'unità più vechje restanu attive in u campu. Una piattaforma matura pò supportà tramindui senza furzà a squadra à mantene dui stack di piattaforme separati per ciò chì i clienti percepiscenu sempre cum'è una sola famiglia di prudutti.
Nunda di questu richiede un backend monoliticu. Diversi prudutti ponu ancu avè bisognu di limiti architettonichi chjari. Ciò chì importa hè di evità una seconda implementazione di a stessa responsabilità ingegneristica senza una bona ragione.
Hè tandu chì a piattaforma diventa un attivu invece di un sovraccaricu accumulatu. U supportu hà menu strumenti paralleli da capisce, e versioni seguitanu percorsi più coerenti, è l'aghjunghje di un altru pruduttu diventa una estensione cuntrullata invece di un altru backend chì a cumpagnia eredita indefinitamente.
Trattate a piattaforma cum'è parte di l'architettura di u pruduttu
I prudutti fisichi sò cuncipiti cù revisioni, manutenzione, fabricabilità è cambiamenti futuri in mente. I prudutti cunnessi anu bisognu di a listessa disciplina da u latu di u software.
U primu backend pò esse tempurale. Cusì pò esse u primu script di provisioning o strumentu di supportu. Ùn ci hè nunda di male in questu. I prublemi cumincianu quandu quelle meccaniche tempuranee diventanu tranquillamente un'architettura permanente mentre u pruduttu stessu cuntinueghja à evoluzione.
À quellu puntu, u pruduttu cunnessu ùn hè più solu hardware, firmware è una applicazione. Dipende ancu da l'infrastruttura chì identifica ogni dispusitivu, ne capisce e capacità, applica a cunfigurazione curretta, supporta l'aghjurnamenti è aiuta e squadre à diagnosticà i prublemi anni dopu a spedizione.
Una volta chì stu stratu hè trattatu cum'è architettura di u produttu, a divisione diventa più chjara: a meccanica standard ferma riutilizzabile, mentre chì u travagliu persunalizatu si concentra nantu à ciò chì distingue veramente un pruduttu o una famiglia di prudutti da un'altra.
A piattaforma a più forte ùn hè micca solu quella chì rende pussibule u primu pruduttu cunnessu. Hè quella chì permette à a squadra d'ingegneria di custruisce u secondu, u terzu è u quartu senza eredità un novu backend ogni volta.
