'n Verbonde produk kan klaar lyk lank voordat die ingenieurswese daaromheen voltooi is. Die prototipe is stabiel, data bereik die wolk, die toepassing wys die regte waardes, en die eerste groep toestelle is reeds in gebruikers se hande. Op daardie stadium kan die backend steeds eenvoudig genoeg wees dat die span byna elke toestel individueel ken. Voorsiening kan met 'n skrip hanteer word, konfigurasieveranderinge kan handmatig aangebring word, en as iets misluk, kan 'n ingenieur gewoonlik die probleem direk opspoor.
Dan moet dit in die werklike wêreld begin leef. 'n Tweede hardeware-hersiening verskyn. Sommige kliënte gebruik steeds die eerste hersiening. Firmware-weergawes begin verskil. 'n Nuwe konfigurasie is nodig vir 'n ander kliënt of mark, terwyl ouer toestelle steeds opdaterings en ondersteuning benodig.
Niks is noodwendig stukkend nie. Die sagteware agter die toestel het bloot 'n eie lewensiklus gekry.
Daardie oorgang is maklik om mis te kyk, want die prototipe kan perfek aanhou werk. Maar sodra verskeie weergawes van dieselfde fisiese produk in die veld moet saambestaan, is die agterkant nie meer net infrastruktuur agter die hardeware nie. Dit word deel van die produkargitektuur self.
'n Werkende gekoppelde prototipe is nog nie 'n skaalbare produk nie
'n Prototipe het 'n belangrike taak: bewys dat die stelsel van begin tot einde werk. Die toestel verrig sy kernfunksie, firmware kommunikeer met die backend, telemetrie arriveer waar dit moet, opdragte maak die terugreis, en 'n mobiele of webkoppelvlak stel die funksionaliteit aan 'n gebruiker bloot.
Wat dit gewoonlik nie bewys het nie, is hoe goed dieselfde stelsel verskeidenheid hanteer.
Die eerste twintig toestelle mag dalk almal dieselfde firmware gebruik, volgens dieselfde hardeware-hersiening gebou word en deur dieselfde ingenieurs gekonfigureer word. In daardie stadium kan handmatige registrasie, direkte konfigurasieveranderinge of 'n klein aanboordskrip heeltemal sinvol wees. Die bou van produksiegraad-gereedskap voordat die produk homself bewys het, kan voortydig wees.
Skaal verander die probleem. Toestelle bly vanlyn, word vervang, gebruik verskillende firmware en vereis verskillende kliëntkonfigurasies. Ondersteuning moet 'n eenheid wat nooit korrek voorsien is nie, onderskei van een wat verkeerd gekonfigureer of eenvoudig onbereikbaar is.
Prototipe-skuld begin dikwels so: nie met 'n slegte besluit nie, maar met 'n tydelike een wat in plek bly nadat die produk aanbeweeg het. En een van die eerste dinge wat daardie oorgang in sig dwing, is die hardeware self. 'n Nuwe hersiening vervang nie bloot die oue nie; dit moet daarmee saambestaan.
Elke hardeware-hersiening skep 'n sagteware-lewensiklusprobleem
'n Nuwe hardeware-hersiening kom selde as 'n skoon plaasvervanger vir die oue. In die praktyk bly beide weergawes in die veld, soms vir jare. Voeg 'n oorgangsgroep, 'n paar firmware-takke en kliëntspesifieke konfigurasies by, en die vloot word vinnig meer divers as wat die oorspronklike produkmodel voorstel.
Die sagtewarelaag kan nie meer elke eenheid as 'n abstrakte "toestel" behandel nie. Dit moet weet wat daardie spesifieke eenheid in staat is om te doen.
'n Hersiene bord mag dalk 'n ander sensor, kommunikasiemodule of beheerder gebruik. 'n Opdrag wat geldig is vir die nuutste weergawe, word dalk nie deur 'n vorige een ondersteun nie. Kalibrasiewaardes kan verander. Konfigurasielimiete kan verskuif. 'n Firmwarepakket wat geskik is vir een generasie, mag dalk onveilig wees vir 'n ander.
Fisiese produkingenieurs werk reeds so. Twee komponente wat amper identies lyk, is nie uitruilbaar as hul hersienings, toleransies of spesifikasies verskil nie. Verbonde produkte skep dieselfde probleem aan die sagtewarekant: die platform benodig 'n betroubare manier om te verstaan met watter weergawe van die fisiese produk dit praat en watter reëls daarop van toepassing is.
Dink aan 'n produk waarvan die eerste hersiening een kalibrasieprosedure gebruik terwyl die tweede 'n nuwe sensor en 'n ander stel parameters bekendstel. Vir die kliënt mag beide eenhede steeds dieselfde produk wees. Vir die platform kan hulle nie wees nie.
As daardie verskille nie eksplisiet voorgestel word nie, is hulle geneig om as spesiale gevalle in toepassingslogika in te lek. Een werkvloei kontroleer 'n reeksnommerreeks. 'n Ander gebruik 'n firmware-weergawe as 'n plaasvervanger vir hardeware-generering. 'n Derde bevat 'n uitsondering wat bygevoeg is nadat ondersteuning ontdek het dat 'n ouer bondel anders in die veld optree. Nie een van hierdie regstellings lyk op sigself besonder gevaarlik nie, maar saam maak hulle elke toekomstige verandering moeiliker om oor te redeneer.
Ouer hardeware verdwyn selde volgens skedule. Produkspanne fokus natuurlik op die nuutste hersiening, terwyl kliënte dikwels vroeëre weergawes baie langer as verwag hou. Die platform moet dus verskeie generasies gelyktydig ondersteun eerder as om aan te neem dat die geïnstalleerde basis ooit op 'n enkele huidige toestand sal saamvloei.
Sodra dit gebeur, word hardeware-evolusie en sagteware-lewensiklusbestuur onafskeidbaar. Die platform moet nie net weet waar 'n toestel is en of dit aanlyn is nie, maar ook wat dit is, wat dit kan laat loop, hoe dit gekonfigureer moet word en watter veranderinge veilig is om toe te pas.
En voordat enige van daardie vrae betroubaar beantwoord kan word, moet elke toestel die stelsel op 'n konsekwente manier binnegaan.
Voorsiening is waar handmatige ingenieurswese ophou skaal
Voorsiening lyk eenvoudig wanneer die vloot klein is: skep 'n toestelrekord, voer 'n reeksnommer in, genereer geloofsbriewe, ken die eenheid aan 'n kliënt toe, pas 'n konfigurasie toe en gaan aan. Vir 'n paar dosyn toestelle kan dit steeds die regte keuse wees om sommige hiervan handmatig te hanteer.
Op produksieskaal lê voorsiening egter by die kruispunt van toestelidentiteit, geloofsbriewe, eienaarskap, konfigurasie en lewensiklusstatus. 'n Fout wat tydens aanboordneming gemaak word, kan beïnvloed hoe die eenheid bedryf en ondersteun word lank nadat dit die fabriek verlaat het.
'n Sigblad mag dalk nie meer ooreenstem met wat werklik geïnstalleer is nie. 'n Vervangende toestel benodig die regte kliëntassosiasie sonder om die verkeerde identiteit te erf. Fabrieksherstellings skep 'n ander pad deur die proses. 'n Installeerder kan 'n eenheid aan die verkeerde rekening toewys, wat ondersteuning laat bepaal of dit vanlyn is, verkeerd voorsien is, of bloot die verkeerde konfigurasie het.
Sodra die beantwoording van daardie vrae roetinegewys vereis dat 'n ontwikkelaar 'n databasis inspekteer of 'n interne skrip uitvoer, het die proses opgehou om met die produk te skaal.
Duplisering is nog 'n waarskuwingsteken. Elke produkvariant begin sy eie aanboordskrip, konfigurasiehulpmiddel of installeerderwerkvloei verkry. Daardie verskille mag dalk klein lyk, maar die onderliggende verantwoordelikheid is dieselfde. Voorsiening het herbruikbare platforminfrastruktuur geword eerder as 'n opsteltaak wat aan 'n spesifieke toestel gekoppel is.
En dit is selde die enigste vermoë wat herbruikbaar moet word.
Die platformlaag moet herbruikbare infrastruktuur word
Sodra verskeie produkte of hardeware-hersienings dieselfde basiese behoeftes deel, hou sommige sagtewarevermoëns op om produkspesifiek te wees. Toestelidentiteit, voorsiening, konnektiwiteit, telemetrie, firmware-aflewering, lewensiklusstatus, vlootsigbaarheid en diagnostiek is goeie voorbeelde. Deur hulle vir elke nuwe variant te herbou, skep dit meer kode en meer operasionele paaie om te onderhou sonder om die produk self meer onderskeidend te maak.
Spanne probeer selde hierdie duplisering skep. Klein verskille hoop op rondom elke produk totdat die span verskeie implementerings van wat dieselfde ingenieursverantwoordelikheid geword het, onderhou.
'n Skoonmaker grens is om die produklaag van die platformlaag te skei. Die produklaag bevat die gedrag, werkvloeie, koppelvlakke, integrasies en domeinlogika wat 'n spesifieke toestel waardevol maak. Die platformlaag hanteer meganika wat konsekwent moet bly, selfs al verander die hardeware.
Namate gekoppelde produkte verder as hul eerste vrystelling beweeg, word toestelvoorsiening, toestellewensiklusbestuur, vlootbestuur en ondersteuningsinstrumente gedeelde infrastruktuur eerder as eenmalige projekbesonderhede. 'n IoT PaaS vir ondernemings kan daardie herbruikbare platformlaag oor verskeie produkte of produkvariante verskaf, en standaard toestel- en databestuur deur herbruikbare boublokke hanteer terwyl ingenieurspanne hul persoonlike pogings op hardeware, werkvloei en gebruikerservaring fokus.
'n Gemeenskaplike fondament moet steeds ruimte laat vir werklike produkverskille. 'n Nuwe toestel mag dalk 'n ander datamodel, konfigurasievloei, integrasie of beheerlogika benodig, en daardie verskille moet maklik bly om in te voer. Die doel is eenvoudig om te verhoed dat elke verskil 'n ander toestelregister, telemetriepyplyn, voorsieningsmeganisme of stel vlootbestuursinstrumente meesleep.
Die platform mag dalk soos oorhoofse koste lyk terwyl die span die eerste produk bou en soos 'n bate teen die tweede of derde. Sodra die algemene operasionele meganika in plek is, kan 'n nuwe variant 'n werkende fondament erf in plaas daarvan om met 'n ander backend te kom wat die span vir die res van daardie produk se leeftyd sal moet onderhou.
Hou persoonlike ingenieurswese waar die produk eintlik anders is
’n Herbruikbare platform behoort nie gekoppelde produkte meer generies te maak nie. Die taak daarvan is om herhaalde ingenieurswese te verwyder uit die dele wat nie differensiasie skep nie.
Pasgemaakte pogings behoort steeds in toestelgedrag, domeinspesifieke logika, werkvloeie, gebruikerservaring, gespesialiseerde integrasies en die manier waarop 'n spesifieke produk met die fisiese wêreld omgaan. Dit is presies die areas waar ingenieurskeuses een produk betekenisvol beter as 'n ander kan maak.
Wat selde dieselfde behandeling verdien, is die omliggende operasionele loodgieterswerk. 'n Basiese weergawe en 'n industriële weergawe van dieselfde masjien mag verskillende sensors, kontroles en koppelvlakke benodig, maar hulle behoort nie afsonderlike maniere te vereis om toestelle te identifiseer, firmware-weergawes op te spoor of 'n vloot te bestuur nie.
Ek sou eerder sien dat ingenieurs daardie tyd spandeer om te verfyn hoe die produk in die veld optree as om die meganika wat die span reeds vir 'n ander produk in plek het, te herbou. 'n Gedeelde fondament verminder nie die ruimte vir pasgemaakte ingenieurswese nie; dit beskerm daardie poging teen infrastruktuur.
Die ware toets kom wanneer die span produk nommer twee begin.
'n Goeie platform maak die volgende produk makliker as die eerste een
As produk nommer twee amper dieselfde platformwerk as produk nommer een vereis, is baie min eintlik hergebruik.
'n Nuwe variant behoort die dele van die bedryfsmodel te kan erf wat nie verander het nie: voorsieningsvloei, identiteit, lewensiklusmeganika, vlootgereedskap, firmwareprosesse, ondersteuningssigbaarheid en algemene integrasies. Ingenieurspoging gaan dan in op die verskille – miskien 'n nuwe sensorpakket, 'n ander beheerwerkvloei of 'n kliëntspesifieke integrasie – in plaas daarvan om die fondament te rekonstrueer.
'n Nuwe hardeware-generasie plaas dieselfde idee onder meer druk. Die vermoëns daarvan kan aansienlik verander terwyl ouer eenhede in die veld aktief bly. 'n Volwasse platform kan beide ondersteun sonder om die span te dwing om twee aparte platformstapels te onderhou vir wat kliënte steeds as een produkfamilie beskou.
Niks hiervan vereis een monolitiese backend nie. Verskillende produkte benodig dalk steeds duidelike argitektoniese grense. Wat saak maak, is om 'n tweede implementering van dieselfde ingenieursverantwoordelikheid sonder 'n goeie rede te vermy.
Dit is wanneer die platform 'n bate word eerder as opgehoopte oorhoofse koste. Ondersteuning het minder parallelle gereedskap om te verstaan, vrystellings volg meer konsekwente paaie, en die byvoeging van 'n ander produk word 'n beheerde uitbreiding in plaas van nog 'n backend wat die maatskappy onbepaald erf.
Beskou die platform as deel van die produkargitektuur
Fisiese produkte word ontwerp met hersienings, diensbaarheid, vervaardigbaarheid en toekomstige veranderinge in gedagte. Verbonde produkte benodig dieselfde dissipline aan die sagtewarekant.
Die eerste backend kan tydelik wees. So ook die eerste voorsieningskrip of ondersteuningsinstrument. Daar is niks inherent verkeerd daarmee nie. Probleme begin wanneer daardie tydelike meganika stilweg permanente argitektuur word terwyl die produk self aanhou ontwikkel.
Teen daardie tyd is die gekoppelde produk nie meer net hardeware, firmware en 'n toepassing nie. Dit hang ook af van die infrastruktuur wat elke toestel identifiseer, die vermoëns daarvan verstaan, die regte konfigurasie toepas, opdaterings ondersteun en spanne help om probleme jare na versending te diagnoseer.
Sodra daardie laag as produkargitektuur behandel word, word die verdeling duideliker: standaardmeganika bly herbruikbaar, terwyl pasgemaakte werk fokus op wat eintlik een produk of produkfamilie van 'n ander onderskei.
Die sterkste platform is nie bloot die een wat die eerste gekoppelde produk moontlik maak nie. Dit is die een wat die ingenieurspan toelaat om die tweede, derde en vierde te bou sonder om elke keer 'n nuwe backend te erf.
