In ferbûn produkt kin der klear útsjen lang foardat de technyk deromhinne klear is. It prototype is stabyl, gegevens berikke de wolk, de app lit de juste wearden sjen, en de earste partij apparaten is al yn 'e hannen fan brûkers. Op dat stuit kin de backend noch ienfâldich genôch wêze dat it team hast elk apparaat yndividueel ken. Provisioning kin mei in skript ôfhannele wurde, konfiguraasjewizigingen kinne mei de hân makke wurde, en as der wat mis giet, kin in yngenieur it probleem meastal direkt opspoare.
Dan moat it yn 'e echte wrâld begjinne te libjen. In twadde hardware-revyzje ferskynt. Guon klanten brûke noch altyd de earste revyzje. Firmware-ferzjes begjinne te ferskillen. In nije konfiguraasje is nedich foar in oare klant of merk, wylst âldere apparaten noch updates en stipe nedich binne.
Neat is needsaaklikerwize kapot. De software efter it apparaat hat gewoan in eigen libbenssyklus krigen.
Dy oergong is maklik te missen, om't it prototype perfekt trochgean kin mei wurkjen. Mar as meardere ferzjes fan itselde fysike produkt neist elkoar yn it fjild bestean moatte, is de backend net langer allinich ynfrastruktuer efter de hardware. It wurdt ûnderdiel fan 'e produktarsjitektuer sels.
In wurkjend ferbûn prototype is noch gjin skalberber produkt
In prototype hat in wichtige taak: bewize dat it systeem fan begjin oant ein wurket. It apparaat docht syn kearnfunksje, firmware kommunisearret mei de backend, telemetrie komt oan wêr't it moat, kommando's meitsje de weromreis, en in mobile of webinterface stelt de funksjonaliteit bleat oan in brûker.
Wat it meastentiids net bewiisd hat, is hoe goed itselde systeem mei ferskaat omgiet.
De earste tweintich apparaten kinne allegear deselde firmware útfiere, boud wêze mei deselde hardware-revisje, en konfigurearre wurde troch deselde yngenieurs. Yn dat stadium kin hânmjittige registraasje, direkte konfiguraasjewizigingen, of in lyts onboarding-skript folslein ferstannich wêze. It bouwen fan produksjeklasse-ark foardat it produkt himsels bewiisd hat, kin te betiid wêze.
Skaal feroaret it probleem. Apparaten bliuwe offline, wurde ferfongen, rinne ferskillende firmware en fereaskje ferskillende klantkonfiguraasjes. Stipe moat in ienheid ûnderskiede dy't nea goed ynrjochte is fan ien dy't ferkeard konfigurearre of gewoan net berikber is.
Prototypeskuld begjint faak sa: net mei in minne beslissing, mar mei in tydlike dy't op syn plak bliuwt nei't it produkt fierder gien is. En ien fan 'e earste dingen dy't dy oergong yn sicht twingt is de hardware sels. In nije revisy ferfangt net gewoan de âlde; it moat dermei bestean.
Elke hardware-revisy skept in probleem yn 'e softwarelibbensyklus
In nije hardware-revisy komt selden as in skjinne ferfanging foar de âlde. Yn 'e praktyk bliuwe beide ferzjes yn it fjild, soms jierrenlang. Foegje in oergongsbatch, in pear firmware-tûken en klantspesifike konfiguraasjes ta, en de float wurdt al gau ferskaater as it orizjinele produktmodel suggerearret.
De softwarelaach kin net langer elke ienheid as in abstrakt "apparaat" behannelje. It moat witte wat dy bepaalde ienheid yn steat is om te dwaan.
In revisearre board kin in oare sensor, kommunikaasjemodule of controller brûke. In kommando dat jildich is foar de lêste ferzje wurdt miskien net stipe troch in eardere. Kalibraasjewearden kinne feroarje. Konfiguraasjelimiten kinne ferskowe. In firmwarepakket dat geskikt is foar de iene generaasje kin ûnfeilich wêze foar in oare.
Fysike produktyngenieurs wurkje al op dizze manier. Twa komponinten dy't hast identyk lykje, binne net útwikselber as har revisjes, tolerânsjes of spesifikaasjes ferskille. Ferbûne produkten meitsje itselde probleem oan 'e softwarekant: it platfoarm hat in betroubere manier nedich om te begripen mei hokker ferzje fan it fysike produkt it praat en hokker regels dêrfoar jilde.
Tink oan in produkt wêrfan de earste revisy ien kalibraasjeproseduere brûkt, wylst de twadde in nije sensor en in oare set parameters yntrodusearret. Foar de klant kinne beide ienheden noch itselde produkt wêze. Foar it platfoarm kinne se dat net wêze.
As dy ferskillen net eksplisyt werjûn wurde, hawwe se de neiging om as spesjale gefallen yn 'e applikaasjelogika te lekken. Ien workflow kontrolearret in serienûmerberik. In oare brûkt in firmwareferzje as proxy foar hardwaregeneraasje. In tredde befettet in útsûndering dy't tafoege is neidat stipe ûntduts dat in âldere batch him oars gedroech yn it fjild. Gjin fan dizze reparaasjes sjocht der op himsels bysûnder gefaarlik út, mar tegearre meitsje se elke takomstige feroaring dreger om oer te redenearjen.
Aldere hardware ferdwynt selden op skema. Produktteams rjochtsje har fansels op 'e nijste revisy, wylst klanten eardere ferzjes faak folle langer bewarje as ferwachte. It platfoarm moat dêrom ferskate generaasjes tagelyk stypje ynstee fan oan te nimmen dat de ynstalleare basis ea sil konvergearje nei ien hjoeddeistige steat.
As dat ienris bart, wurde hardware-evolúsje en softwarelibbensyklusbehear ûnskiedber. It platfoarm moat net allinich witte wêr't in apparaat is en oft it online is, mar ek wat it is, wat it útfiere kin, hoe't it konfigurearre wurde moat en hokker feroarings feilich ta te passen binne.
En foardat ien fan dy fragen betrouber beantwurde wurde kin, moat elk apparaat op in konsekwinte manier it systeem yngean.
Provisioning is wêr't manuele technyk ophâldt mei skalearjen
It oanlizzen fan apparatuer liket ienfâldich as de float lyts is: in apparaatrekord oanmeitsje, in serienûmer ynfiere, ynloggegevens generearje, de ienheid oan in klant tawize, in konfiguraasje tapasse en fierder gean. Foar in pear tsientallen apparaten kin it sels ôfhanneljen fan guon hjirfan noch altyd de juste kar wêze.
Op produksjeskaal sit de foarsjenning lykwols op it krúspunt fan apparaatidentiteit, ynloggegevens, eigendom, konfiguraasje en libbenssyklusstatus. In flater dy't makke wurdt by it onboarden kin ynfloed hawwe op hoe't de ienheid betsjinne en stipe wurdt lang nei't it de fabryk ferliet.
In spreadsheet kin net mear oerienkomme mei wat eins ynstalleare is. In ferfangend apparaat hat de juste klantassosjaasje nedich sûnder de ferkearde identiteit te erven. Fabryksresets meitsje in oar paad troch it proses. In ynstallearder kin in ienheid tawize oan it ferkearde akkount, wêrtroch't de stipe oerlitten wurdt om te bepalen oft it offline is, ferkeard ynrjochte is, of gewoan de ferkearde konfiguraasje hat.
Sadree't it beantwurdzjen fan dy fragen routinematich fereasket dat in ûntwikkelder in database ynspektearret of in yntern skript útfiere moat, is it proses opholden mei skalearjen mei it produkt.
Duplikaasje is in oar warskôgingsteken. Elke produktfariant krijt syn eigen onboarding-skript, konfiguraasjetool of ynstallaasjeworkflow. Dy ferskillen lykje miskien lyts, mar de ûnderlizzende ferantwurdlikens is itselde. Provisioning is in werbrûkbere platfoarmynfrastruktuer wurden ynstee fan in ynstellingstaak dy't oan in bepaald apparaat keppele is.
En it is selden de ienige mooglikheid dy't werbrûkber wurde moat.
De platfoarmlaach moat werbrûkbere ynfrastruktuer wurde
Sadree't ferskate produkten of hardware-revisjes deselde basisbehoeften diele, binne guon softwaremooglikheden net mear produktspesifyk. Apparaatidentiteit, foarsjenning, ferbining, telemetrie, firmwarelevering, libbenscyclusstatus, floatsichtberens en diagnostyk binne goede foarbylden. It opnij bouwen fan dizze foar elke nije fariant makket mear koade en mear operasjonele paden om te ûnderhâlden sûnder it produkt sels ûnderskiedender te meitsjen.
Teams sette har selden yn om dizze duplikaasje te meitsjen. Lytse ferskillen sammelje har op om elk produkt hinne oant it team ferskate ymplemintaasjes ûnderhâldt fan wat deselde yngenieursferantwurdlikens wurden is.
In skjinne grins is om de produktlaach te skieden fan 'e platfoarmlaach. De produktlaach befettet it gedrach, de workflows, de ynterfaces, de yntegraasjes en de domeinlogika dy't in bepaald apparaat weardefol meitsje. De platfoarmlaach behannelet meganika dy't konsekwint bliuwe moat, sels as de hardware feroaret.
As ferbûne produkten fierder geane as harren earste release, wurde apparaatfoarsjenning, apparaatlibbensyklusbehear, floatbehear en stipe-ark dielde ynfrastruktuer ynstee fan ienmalige projektdetails. In IoT PaaS foar bedriuwen kin dy werbrûkbere platfoarmlaach leverje oer meardere produkten of produktfarianten, wêrby't standert apparaat- en gegevensbehear ôfhannele wurdt fia werbrûkbere boublokken, wylst yngenieursteams har oanpaste ynspanning rjochtsje op hardware, workflows en brûkersûnderfining.
In mienskiplike basis moat noch romte litte foar echte produktferskillen. In nij apparaat kin in oar datamodel, konfiguraasjestream, yntegraasje of kontrôlelogika nedich hawwe, en dy ferskillen moatte maklik yn te fieren bliuwe. It doel is gewoan om te foarkommen dat elk ferskil in oar apparaatregister, telemetripipeline, foarsjenningsmeganisme of set ark foar floatbehear meisleept.
It platfoarm kin lykje as overhead wylst it team it earste produkt bout en as in asset by it twadde of tredde produkt. Sadree't de mienskiplike operasjonele meganika op syn plak binne, kin in nije fariant in wurkjende basis ervje ynstee fan te kommen mei in oare backend dy't it team foar de rest fan 'e libbensdoer fan dat produkt ûnderhâlde moat.
Hâld oanpaste technyk wêr't it produkt eins oars is
In werbrûkber platfoarm moat ferbûne produkten net generiker meitsje. Syn taak is om werhelle yngenieurswurk te ferwiderjen fan 'e ûnderdielen dy't gjin ûnderskied meitsje.
Oanpaste ynspanning heart noch altyd ta apparaatgedrach, domeinspesifike logika, workflows, brûkersûnderfining, spesjalisearre yntegraasjes, en de manier wêrop in bepaald produkt ynteraksje hat mei de fysike wrâld. Dat binne krekt de gebieten wêr't yngenieurskeuzes it iene produkt betsjuttingsfol better meitsje kinne as it oare.
Wat selden deselde behanneling fertsjinnet, is de omlizzende operasjonele liedingen. In basisferzje en in yndustriële ferzje fan deselde masine kinne ferskillende sensoren, kontrôles en ynterfaces nedich hawwe, mar se moatte gjin aparte manieren fereaskje om apparaten te identifisearjen, firmwareferzjes te folgjen of in float te behearjen.
Ik soe leaver sjen dat yngenieurs dy tiid besteegje oan it ferbetterjen fan hoe't it produkt him yn it fjild gedraacht dan oan it opnij opbouwen fan meganika dy't it team al hat foar in oar produkt. In dielde basis ferminderet de romte foar oanpaste technyk net; it beskermet dy ynspanning tsjin it opslokjen troch ynfrastruktuer.
De echte test komt as it team begjint mei produkt nûmer twa.
In goed platfoarm makket it folgjende produkt makliker as it earste
As produkt nûmer twa hast itselde platfoarmwurk fereasket as produkt nûmer ien, is der eins mar hiel bytsje opnij brûkt.
In nije fariant moat de dielen fan it bestjoeringsmodel ervje kinne dy't net feroare binne: foarsjenningsstreamen, identiteit, libbenscyclusmeganika, floattools, firmwareprosessen, stipesichtberens en mienskiplike yntegraasjes. De yngenieurswurk giet dan nei de ferskillen - miskien in nij sensorpakket, in oare kontrôleworkflow, of in klantspesifike yntegraasje - ynstee fan de basis te rekonstruearjen.
In nije hardwaregeneraasje set itselde idee ûnder mear druk. De mooglikheden dêrfan kinne flink feroarje, wylst âldere ienheden aktyf bliuwe yn it fjild. In folwoeksen platfoarm kin beide stypje sûnder it team te twingen om twa aparte platfoarmstacks te ûnderhâlden foar wat klanten noch altyd as ien produktfamylje sjogge.
Neat fan dit fereasket ien monolityske backend. Ferskillende produkten kinne noch dúdlike arsjitektoanyske grinzen nedich hawwe. Wat wichtich is, is it foarkommen fan in twadde ymplemintaasje fan deselde yngenieursferantwurdlikens sûnder in goede reden.
Dat is wannear't it platfoarm in asset wurdt ynstee fan opboude overhead. Stipe hat minder parallelle ark om te begripen, releases folgje konsekwintere paden, en it tafoegjen fan in oar produkt wurdt in kontroleare útwreiding ynstee fan in oare backend dy't it bedriuw foar ûnbepaalde tiid erft.
Behannelje it platfoarm as ûnderdiel fan 'e produktarsjitektuer
Fysike produkten wurde ûntworpen mei revisjes, tsjinstberens, produsearberens en takomstige feroarings yn gedachten. Ferbûne produkten hawwe deselde dissipline nedich oan 'e softwarekant.
De earste backend kin tydlik wêze. Dat kin ek it earste provisioningskript of stipe-ark. Dêr is neat ynherint mis mei. Problemen begjinne as dy tydlike meganika stilwei in permaninte arsjitektuer wurde, wylst it produkt sels trochgiet mei evoluearjen.
Tsjin dy tiid is it ferbûne produkt net mear allinich hardware, firmware en in app. It hinget ek ôf fan 'e ynfrastruktuer dy't elk apparaat identifisearret, syn mooglikheden begrypt, de juste konfiguraasje tapast, updates stipet en teams helpt by it diagnostisearjen fan problemen jierren nei ferstjoering.
Sadree't dy laach behannele wurdt as produktarsjitektuer, wurdt de ferdieling dúdliker: standertmeganika bliuwt werbrûkber, wylst oanpast wurk giet oer wat eins ien produkt of produktfamylje fan in oar ûnderskiedt.
It sterkste platfoarm is net allinich it platfoarm dat it earste ferbûne produkt mooglik makket. It is it platfoarm dat it yngenieursteam it twadde, tredde en fjirde produkt bouwe lit sûnder elke kear in nije backend te erven.
