Povezan izdelek je lahko videti dokončan že dolgo preden je inženiring okoli njega končan. Prototip je stabilen, podatki dosežejo oblak, aplikacija prikazuje pravilne vrednosti in prva serija naprav je že v rokah uporabnikov. Na tej točki je lahko zaledni sistem še vedno dovolj preprost, da ekipa pozna skoraj vsako napravo posebej. Dodeljevanje je mogoče upravljati s skriptom, spremembe konfiguracije je mogoče izvesti ročno, in če kaj odpove, lahko inženir običajno neposredno izsledi težavo.
Nato mora začeti živeti v resničnem svetu. Pojavi se druga revizija strojne opreme. Nekatere stranke še vedno uporabljajo prvo revizijo. Različice vdelane programske opreme se začnejo razlikovati. Za drugo stranko ali trg je potrebna nova konfiguracija, medtem ko starejše naprave še vedno potrebujejo posodobitve in podporo.
Nič ni nujno pokvarjeno. Programska oprema, ki stoji za napravo, je preprosto pridobila svoj življenjski cikel.
Ta prehod je enostavno spregledati, saj lahko prototip še naprej deluje brezhibno. Ko pa mora na terenu sočasno obstajati več različic istega fizičnega izdelka, zaledni sistem ni več le infrastruktura za strojno opremo. Postane del same arhitekture izdelka.
Delujoč povezan prototip še ni skalabilen izdelek
Prototip ima pomembno nalogo: dokazati, da sistem deluje od začetka do konca. Naprava opravlja svojo osnovno funkcijo, vdelana programska oprema komunicira z zalednim sistemom, telemetrija prispe tja, kamor bi morala, ukazi se vrnejo, mobilni ali spletni vmesnik pa uporabniku predstavi funkcionalnost.
Običajno ni dokazalo, kako dobro isti sistem obvladuje raznolikost.
Prvih dvajset naprav lahko uporablja isto vdelano programsko opremo, so izdelane z isto revizijo strojne opreme in jih konfigurirajo isti inženirji. Na tej stopnji je lahko ročna registracija, neposredne spremembe konfiguracije ali majhen uvodni skript povsem smiseln. Izdelava orodij za produkcijsko uporabo, preden se izdelek dokaže, je lahko preuranjena.
Obseg spreminja problem. Naprave ostanejo brez povezave, se zamenjajo, uporabljajo drugačno vdelano programsko opremo in zahtevajo drugačne konfiguracije strank. Podpora mora razlikovati med enoto, ki ni bila nikoli pravilno nastavljena, in tisto, ki je napačno konfigurirana ali preprosto nedosegljiva.
Prototipni dolg se pogosto začne tako: ne s slabo odločitvijo, temveč z začasno, ki ostane v veljavi tudi po tem, ko je izdelek že na voljo. In ena prvih stvari, ki ta prehod prisili v ospredje, je sama strojna oprema. Nova revizija ne nadomesti le stare; mora sobivati z njo.
Vsaka revizija strojne opreme ustvari težavo v življenjskem ciklu programske opreme
Nova strojna revizija le redko pride kot čista zamenjava za staro. V praksi obe različici ostaneta na voljo, včasih tudi več let. Dodajte prehodno serijo, nekaj vej vdelane programske opreme in konfiguracije, specifične za stranko, in flota hitro postane bolj raznolika, kot nakazuje prvotni model izdelka.
Programska plast ne more več obravnavati vsake enote kot abstraktne »naprave«. Vedeti mora, kaj ta določena enota zmore.
Revidirana plošča lahko uporablja drugačen senzor, komunikacijski modul ali krmilnik. Ukaz, ki velja za najnovejšo različico, morda ne podpira starejše različice. Kalibracijske vrednosti se lahko spremenijo. Omejitve konfiguracije se lahko premaknejo. Paket vdelane programske opreme, primeren za eno generacijo, je lahko nevaren za drugo.
Inženirji fizičnih izdelkov že delajo na ta način. Dve komponenti, ki sta videti skoraj enaki, nista zamenljivi, če se njune revizije, tolerance ali specifikacije razlikujejo. Povezani izdelki povzročajo isto težavo na strani programske opreme: platforma potrebuje zanesljiv način za razumevanje, s katero različico fizičnega izdelka se pogovarja in katera pravila veljajo zanjo.
Predstavljajte si izdelek, katerega prva revizija uporablja en postopek kalibracije, druga pa uvaja nov senzor in drugačen nabor parametrov. Za stranko sta obe enoti lahko še vedno isti izdelek. Za platformo pa ne moreta biti.
Če te razlike niso eksplicitno predstavljene, se ponavadi prenesejo v logiko aplikacije kot posebni primeri. En potek dela preveri obseg serijskih številk. Drug uporablja različico vdelane programske opreme kot posrednik za generiranje strojne opreme. Tretji vsebuje izjemo, dodano potem, ko je podpora odkrila starejšo serijo, ki se je na terenu obnašala drugače. Noben od teh popravkov sam po sebi ni videti posebej nevaren, vendar skupaj otežujejo razmislek o vsaki prihodnji spremembi.
Starejša strojna oprema le redko izgine po načrtih. Produktne ekipe se seveda osredotočajo na najnovejšo revizijo, medtem ko stranke pogosto hranijo starejše različice veliko dlje, kot je pričakovano. Platforma mora zato podpirati več generacij hkrati, namesto da bi predpostavljala, da se bo nameščena baza kdaj zbližala v enem samem trenutnem stanju.
Ko se to zgodi, postaneta razvoj strojne opreme in upravljanje življenjskega cikla programske opreme neločljiva. Platforma mora vedeti ne le, kje je naprava in ali je na spletu, temveč tudi, kaj je, kaj lahko poganja, kako jo je treba konfigurirati in katere spremembe je varno uporabiti.
In preden je mogoče na katero koli od teh vprašanj zanesljivo odgovoriti, mora vsaka naprava v sistem vstopiti na dosleden način.
Zagotavljanje je kraj, kjer ročno inženirstvo preneha s skaliranjem
Zagotavljanje storitev je videti preprosto, ko je vozni park majhen: ustvarite zapis naprave, vnesite serijsko številko, ustvarite poverilnice, dodelite enoto stranki, uporabite konfiguracijo in nadaljujte. Za nekaj deset naprav je lahko ročno upravljanje dela tega še vedno prava izbira.
V produkcijskem obsegu pa je zagotavljanje na presečišču identitete naprave, poverilnic, lastništva, konfiguracije in stanja življenjskega cikla. Napaka, storjena med uvajanjem, lahko vpliva na delovanje in podporo enote še dolgo po tem, ko zapusti tovarno.
Preglednica se morda ne ujema več z dejansko nameščeno napravo. Nadomestna naprava potrebuje pravilno povezavo s stranko, ne da bi podedovala napačno identiteto. Ponastavitev na tovarniške nastavitve ustvari še eno pot skozi postopek. Monter lahko enoto dodeli napačnemu računu, pri čemer mora podpora ugotoviti, ali je brez povezave, ali je nepravilno nastavljena ali pa ima preprosto napačno konfiguracijo.
Ko odgovor na ta vprašanja rutinsko zahteva, da razvijalec pregleda bazo podatkov ali zažene interni skript, se je postopek nehal prilagajati izdelku.
Podvajanje je še en opozorilni znak. Vsaka različica izdelka začne pridobivati svoj skript za uvajanje, orodje za konfiguracijo ali potek dela namestitvenega programa. Te razlike se morda zdijo majhne, vendar je osnovna odgovornost enaka. Zagotavljanje storitev je postalo infrastruktura platforme za večkratno uporabo in ne le namestitvena naloga, vezana na določeno napravo.
In le redko je edina zmogljivost, ki jo je treba uporabiti za večkratno uporabo.
Platformna plast bi morala postati infrastruktura za večkratno uporabo
Ko ima več izdelkov ali različic strojne opreme enake osnovne potrebe, nekatere programske zmogljivosti niso več specifične za posamezen izdelek. Dobri primeri so identiteta naprave, oskrbovanje, povezljivost, telemetrija, dostava vdelane programske opreme, stanje življenjskega cikla, vidnost voznega parka in diagnostika. Njihova ponovna izgradnja za vsako novo različico ustvari več kode in več operativnih poti za vzdrževanje, ne da bi sam izdelek postal bolj prepoznaven.
Ekipe se redko lotijo tega podvajanja. Majhne razlike se kopičijo okoli vsakega izdelka, dokler ekipa ne vzdržuje več implementacij tistega, kar je postala ista inženirska odgovornost.
Čistejša meja je ločitev plasti izdelka od plasti platforme. Plast izdelka vsebuje vedenje, poteke dela, vmesnike, integracije in logiko domene, zaradi katerih je določena naprava dragocena. Plast platforme obravnava mehaniko, ki mora ostati dosledna tudi ob spremembi strojne opreme.
Ko povezani izdelki presegajo svojo prvo izdajo, postanejo zagotavljanje naprav, upravljanje življenjskega cikla naprav, upravljanje voznega parka in orodja za podporo skupna infrastruktura in ne le enkratne podrobnosti projekta. IoT PaaS za podjetja lahko zagotovi to plast platforme za večkratno uporabo v več izdelkih ali različicah izdelkov, pri čemer upravlja standardne naprave in podatke prek gradnikov za večkratno uporabo, medtem ko inženirske ekipe svoja prizadevanja po meri osredotočajo na strojno opremo, poteke dela in uporabniško izkušnjo.
Skupna osnova mora še vedno pustiti prostor za resnične razlike med izdelki. Nova naprava lahko potrebuje drugačen podatkovni model, konfiguracijski tok, integracijo ali krmilno logiko, te razlike pa bi morale biti enostavne za uvedbo. Cilj je preprosto preprečiti, da bi vsaka razlika vlekla za seboj še en register naprav, telemetrični cevovod, mehanizem za zagotavljanje ali nabor orodij za upravljanje voznega parka.
Platforma se lahko zdi kot dodatna obremenitev, medtem ko ekipa gradi prvi izdelek, in kot prednost pri drugem ali tretjem. Ko so skupni operativni mehanizmi vzpostavljeni, lahko nova različica podeduje delujočo osnovo, namesto da bi prišla z drugim zalednim sistemom, ki ga bo morala ekipa vzdrževati do konca življenjske dobe tega izdelka.
Ohranite inženiring po meri, kjer je izdelek dejansko drugačen
Platforma za večkratno uporabo ne sme narediti povezanih izdelkov bolj generičnih. Njena naloga je odstraniti ponavljajoče se inženiringe iz delov, ki ne ustvarjajo diferenciacije.
Prilagojeni napori še vedno spadajo v obnašanje naprav, logiko, specifično za domeno, delovne procese, uporabniško izkušnjo, specializirane integracije in način interakcije določenega izdelka s fizičnim svetom. To so prav tista področja, kjer lahko inženirske odločitve en izdelek bistveno izboljšajo od drugega.
Redko si zaslužimo enako obravnavo okoliške operativne vodovodne napeljave. Osnovna in industrijska različica istega stroja lahko potrebujeta različne senzorje, krmilnike in vmesnike, vendar ne bi smeli zahtevati ločenih načinov za prepoznavanje naprav, sledenje različicam vdelane programske opreme ali upravljanje voznega parka.
Raje bi videl, da inženirji ta čas porabijo za izpopolnjevanje delovanja izdelka na terenu, kot pa za ponovno izgradnjo mehanizmov, ki jih ima ekipa že vzpostavljene za drug izdelek. Skupna osnova ne zmanjšuje možnosti za inženiring po meri; ščiti ta trud pred tem, da bi ga porabila infrastruktura.
Pravi preizkus pride, ko ekipa začne z drugim izdelkom.
Dobra platforma olajša izdelavo naslednjega izdelka od prvega.
Če izdelek številka dva zahteva skoraj enako delo na platformi kot izdelek številka ena, je bilo dejansko zelo malo ponovno uporabljenega.
Nova različica bi morala biti sposobna podedovati dele operativnega modela, ki se niso spremenili: tokove zagotavljanja, identiteto, mehaniko življenjskega cikla, orodja za vozni park, procese vdelane programske opreme, vidnost podpore in skupne integracije. Inženirski napor se nato osredotoči na razlike – morda nov paket senzorjev, drug potek dela za nadzor ali integracijo, specifično za stranko – namesto na rekonstrukcijo temeljev.
Nova generacija strojne opreme postavlja isto idejo pod večji pritisk. Njene zmogljivosti se lahko bistveno spremenijo, medtem ko starejše enote ostanejo aktivne na terenu. Zrela platforma lahko podpira oboje, ne da bi ekipa morala vzdrževati dva ločena sklada platform za tisto, kar stranke še vedno dojemajo kot eno družino izdelkov.
Nič od tega ne zahteva enega monolitnega zalednega sistema. Različni izdelki lahko še vedno potrebujejo jasne arhitekturne meje. Pomembno je, da se izognemo drugi implementaciji iste inženirske odgovornosti brez dobrega razloga.
Takrat platforma postane prednost in ne nakopičeni režijski stroški. Podpora ima manj vzporednih orodij za razumevanje, izdaje sledijo bolj doslednim potekom, dodajanje še enega izdelka pa postane nadzorovana razširitev namesto še enega zalednega sistema, ki ga podjetje podeduje za nedoločen čas.
Platformo obravnavajte kot del arhitekture izdelka
Fizični izdelki so zasnovani z mislijo na revizije, uporabnost, izdelavo in prihodnje spremembe. Povezani izdelki potrebujejo enako disciplino na strani programske opreme.
Prvi zaledni sistem je lahko začasen. Enako velja za prvi skript za oskrbovanje ali orodje za podporo. S tem ni nič narobe. Težave se začnejo, ko te začasne mehanike tiho postanejo trajna arhitektura, medtem ko se sam izdelek še naprej razvija.
Takrat povezani izdelek ni več le strojna oprema, vdelana programska oprema in aplikacija. Odvisen je tudi od infrastrukture, ki identificira vsako napravo, razume njene zmogljivosti, uporablja pravilno konfiguracijo, podpira posodobitve in pomaga ekipam diagnosticirati težave še leta po odpremi.
Ko se ta plast obravnava kot arhitektura izdelka, postane delitev jasnejša: standardne mehanike ostanejo ponovno uporabne, medtem ko delo po meri dejansko loči en izdelek ali družino izdelkov od drugega.
Najmočnejša platforma ni zgolj tista, ki omogoča prvi povezani izdelek. Je tista, ki inženirski ekipi omogoča izdelavo drugega, tretjega in četrtega, ne da bi vsakič podedovali novo zaledno okolje.
