Produktu konektatu bat amaituta egon daiteke inguruko ingeniaritza amaitu baino askoz lehenago. Prototipoa egonkorra da, datuak hodeira iristen dira, aplikazioak balio egokiak erakusten ditu eta gailuen lehen multzoa erabiltzaileen eskuetan dago dagoeneko. Une horretan, backenda oraindik nahikoa sinplea izan daiteke taldeak ia gailu guztiak banan-banan ezagutzeko. Hornidura script batekin kudea daiteke, konfigurazio aldaketak eskuz egin daitezke eta zerbait huts egiten badu, ingeniari batek normalean arazoa zuzenean jarrai dezake.
Orduan, mundu errealean bizitzen hasi behar du. Bigarren hardware berrikuspen bat agertzen da. Bezero batzuek lehenengo berrikuspena erabiltzen dute oraindik. Firmware bertsioak desberdintzen hasten dira. Konfigurazio berri bat behar da bezero edo merkatu desberdin baterako, gailu zaharrek eguneraketak eta laguntza behar dituzten bitartean.
Ezer ez dago nahitaez hautsita. Gailuaren atzean dagoen softwareak bere bizi-ziklo propioa eskuratu du, besterik gabe.
Trantsizio hori erraza da oharkabean pasatzea, prototipoak primeran funtzionatzen jarrai baitezake. Baina produktu fisiko beraren hainbat bertsio elkarrekin egon behar direnean, backenda ez da hardwarearen atzean dagoen azpiegitura soilik. Produktuaren arkitekturaren parte bihurtzen da.
Prototipo konektatu funtzional bat ez da oraindik produktu eskalagarria
Prototipo batek lan garrantzitsua du: sistemak muturretik muturrera funtzionatzen duela frogatzea. Gailuak bere funtzio nagusia betetzen du, firmwareak backend-arekin komunikatzen da, telemetria behar duen lekura iristen da, komandoak itzultzeko bidaia egiten dute eta mugikor edo web interfaze batek funtzionaltasuna erabiltzaileari erakusten dio.
Normalean ez da frogatu sistema berak zenbateraino kudeatzen duen barietatea.
Lehen hogei gailuek firmware bera exekutatu dezakete, hardware bertsio berdinarekin eraikiak izan daitezke eta ingeniari berberek konfiguratu. Fase horretan, eskuzko erregistroa, konfigurazio aldaketak zuzenean edo hasierako gidoi txiki bat guztiz zentzuzkoa izan daiteke. Produktua frogatu aurretik ekoizpen mailako tresnak eraikitzea goizegi izan daiteke.
Eskalak arazoa aldatzen du. Gailuak lineaz kanpo geratzen dira, ordezkatzen dira, firmware desberdinak exekutatzen dituzte eta bezeroen konfigurazio desberdinak behar dituzte. Laguntza-zerbitzuak bereizi egin behar du behar bezala hornitu ez den unitate bat gaizki konfiguratuta dagoen edo eskuraezina den batetik.
Prototipoen zorra askotan horrela hasten da: ez erabaki txar batekin, baizik eta produktua aurrera joan ondoren indarrean jarraitzen duen aldi baterako batekin. Eta trantsizio hori bistaratzera behartzen duen lehenengo gauzetako bat hardwarea bera da. Berrikuspen berri batek ez du zaharra ordezkatzen soilik; harekin batera bizi behar du.
Hardwarearen berrikuspen bakoitzak softwarearen bizi-zikloko arazo bat sortzen du
Hardware berrikuspen berri bat gutxitan iristen da zaharraren ordezko garbi gisa. Praktikan, bi bertsioak eremuan egoten dira, batzuetan urteetan. Gehitu trantsizio-multzo bat, firmware-adar batzuk eta bezeroentzako konfigurazio espezifikoak, eta flota azkar bihurtzen da jatorrizko produktu-ereduak iradokitzen duena baino anitzagoa.
Software geruzak ezin du unitate bakoitza "gailu" abstraktu gisa tratatu. Jakin behar du zer egiteko gai den unitate horrek.
Berrikusitako plaka batek sentsore, komunikazio-modulu edo kontrolatzaile desberdin bat erabil dezake. Azken bertsiorako baliozkoa den komando bat agian ez da aurreko batek onartzen. Kalibrazio-balioak alda daitezke. Konfigurazio-mugak alda daitezke. Belaunaldi baterako egokia den firmware pakete bat ez da segurua beste baterako.
Produktu fisikoen ingeniariek dagoeneko modu honetan lan egiten dute. Ia berdinak diruditen bi osagai ez dira elkarren ordezkoak, haien berrikuspenak, tolerantziak edo zehaztapenak desberdinak badira. Konektatutako produktuek arazo bera sortzen dute softwarearen aldetik: plataformak modu fidagarri bat behar du ulertzeko produktu fisikoaren zein bertsiorekin ari den hizketan eta zer arau aplikatzen zaizkion.
Demagun lehenengo berrikuspenak kalibrazio-prozedura bat erabiltzen duen produktu bat, eta bigarrenak, berriz, sentsore berri bat eta parametro multzo desberdin bat sartzen ditu. Bezeroarentzat, bi unitateak produktu bera izan daitezke oraindik. Plataformarentzat, ezin dira.
Desberdintasun horiek esplizituki adierazten ez badira, aplikazioen logikara kasu berezi gisa filtratu ohi dira. Lan-fluxu batek serie-zenbakien barruti bat egiaztatzen du. Beste batek firmware bertsio bat erabiltzen du hardwarea sortzeko proxy gisa. Hirugarren batek salbuespen bat dauka, laguntzak eremuan modu ezberdinean jokatzen zuen multzo zaharrago bat aurkitu ondoren gehitua. Konponketa hauetako batek ere ez dirudi bereziki arriskutsua bere kabuz, baina elkarrekin etorkizuneko aldaketa guztiak zailagoak egiten dituzte arrazoitzeko.
Hardware zaharra gutxitan desagertzen da aurreikusitako garaiz. Produktu-taldeek, naturalki, berrikuspen berrienean jartzen dute arreta, eta bezeroek, berriz, aurreko bertsioak espero baino denbora gehiagoz gordetzen dituzte. Beraz, plataformak hainbat belaunaldi onartu behar ditu aldi berean, instalatuta dagoen oinarria uneko egoera bakarrean elkartuko dela suposatu beharrean.
Hori gertatzen denean, hardwarearen bilakaera eta softwarearen bizi-zikloaren kudeaketa banaezinak bihurtzen dira. Plataformak ez du jakin behar bakarrik gailu bat non dagoen eta linean dagoen ala ez, baizik eta zer den, zer exekutatu dezakeen, nola konfiguratu behar den eta zein aldaketa diren seguruak aplikatzeko.
Eta galdera horiei edozeini modu fidagarrian erantzun aurretik, gailu bakoitza modu koherentean sartu behar da sisteman.
Hornidura eskuzko ingeniaritzak eskalatzea gelditzen duen tokia da.
Hornidura erraza dirudi flota txikia denean: sortu gailuaren erregistro bat, sartu serie-zenbaki bat, sortu kredentzialak, esleitu unitatea bezero bati, aplikatu konfigurazio bat eta jarraitu. Dozena bat gailurentzat, horietako batzuk eskuz kudeatzea oraindik ere aukera egokia izan daiteke.
Ekoizpen eskalan, ordea, hornidura gailuaren identitatearen, kredentzialen, jabetzaren, konfigurazioaren eta bizi-zikloaren egoeraren elkargunean dago. Hasierako fasean egindako akats batek unitatearen funtzionamendu eta laguntzan eragina izan dezake fabrikatik irten eta denbora asko igaro ondoren.
Baliteke kalkulu-orri batek ez bat etortzea benetan instalatuta dagoenarekin. Ordezko gailu batek bezero-elkarte egokia behar du identitate okerra heredatu gabe. Fabrika berrezarpenek beste bide bat sortzen dute prozesuan zehar. Instalatzaile batek unitate bat kontu okerrari esleitu diezaioke, laguntza utziz lineaz kanpo dagoen, gaizki hornituta dagoen edo konfigurazio okerra duen zehazteko.
Galdera horiei erantzuteko, garatzaile batek datu-base bat ikuskatu edo barne-script bat exekutatu behar duenean, prozesuak produktuarekin eskalatzeari utzi dio.
Bikoiztasuna beste abisu seinale bat da. Produktu aldaera bakoitzak bere onboarding script, konfigurazio tresna edo instalatzaile lan-fluxua bereganatzen hasten da. Desberdintasun horiek txikiak dirudite, baina azpiko erantzukizuna bera da. Hornidura berrerabilgarri den plataforma azpiegitura bihurtu da, gailu jakin bati lotutako konfigurazio zeregin bat baino gehiago.
Eta gutxitan da berrerabilgarri bihurtu behar den gaitasun bakarra.
Plataforma geruza berrerabilgarria den azpiegitura bihurtu beharko litzateke
Hainbat produktu edo hardware berrikuspenek oinarrizko behar berdinak partekatzen dituztenean, software gaitasun batzuk produktu espezifikoak izateari uzten diote. Gailuaren identitatea, hornidura, konektibitatea, telemetria, firmwarearen bidalketa, bizi-zikloaren egoera, flotaren ikusgarritasuna eta diagnostikoak dira adibide onak. Aldaera berri bakoitzerako berreraikitzeak kode gehiago eta mantentzeko bide operatibo gehiago sortzen ditu, produktua bera bereizgarriagoa bihurtu gabe.
Taldeek gutxitan hasten dute bikoiztasun hori sortzen. Produktu bakoitzaren inguruan desberdintasun txikiak pilatzen dira, taldeak ingeniaritza-erantzukizun bera bihurtu denaren hainbat inplementazio mantentzen dituen arte.
Muga garbiago bat produktu geruza plataforma geruzatik bereiztea da. Produktu geruzak gailu jakin bat baliotsu egiten duten portaera, lan-fluxuak, interfazeak, integrazioak eta domeinu logika ditu. Plataforma geruzak hardwarea aldatzen den arren koherentea izan behar duten mekanikak kudeatzen ditu.
Produktu konektatuak lehenengo bertsiotik haratago doazen heinean, gailuen hornidura, gailuen bizi-zikloaren kudeaketa, flotaren kudeaketa eta laguntza-tresnak azpiegitura partekatu bihurtzen dira, proiektu-xehetasun puntualen ordez. Enpresentzako IoT PaaS batek plataforma-geruza berrerabilgarri hori eman dezake hainbat produktu edo produktu-aldaeratan, gailu eta datuen kudeaketa estandarra kudeatuz eraikuntza-bloke berrerabilgarrien bidez, ingeniaritza-taldeek beren ahalegin pertsonalizatua hardwarean, lan-fluxuetan eta erabiltzaile-esperientzian zentratzen duten bitartean.
Oinarri komun batek produktuen arteko benetako desberdintasunetarako tartea utzi behar du oraindik. Gailu berri batek datu-eredu, konfigurazio-fluxu, integrazio edo kontrol-logika desberdin bat behar izan dezake, eta desberdintasun horiek erraz sartzen jarraitu beharko lukete. Helburua, besterik gabe, desberdintasun guztiak beste gailu-erregistro, telemetria-hodi, hornidura-mekanismo edo flota-kudeaketa tresna multzo batera arrastatzea saihestea da.
Plataforma gainkarga bat bezala ager daiteke taldeak lehenengo produktua eraikitzen ari den bitartean, eta aktibo bat bigarren edo hirugarrenerako. Behin funtzionamendu-mekanika arruntak ezarrita daudenean, aldaera berri batek oinarri funtzional bat heredatu dezake, taldeak produktu horren bizitza osorako mantendu beharko duen beste backend batekin iritsi beharrean.
Mantendu ingeniaritza pertsonalizatua produktua benetan desberdina den lekuetan
Plataforma berrerabilgarri batek ez luke produktu konektatuak generikoagoak bihurtu behar. Bere lana bereizketarik sortzen ez duten piezetatik ingeniaritza errepikatua kentzea da.
Ahalegin pertsonalizatua gailuaren portaeran, domeinu espezifikoen logikan, lan-fluxuetan, erabiltzaile-esperientzian, integrazio espezializatuetan eta produktu jakin batek mundu fisikoarekin elkarreragiten duen moduan dago oraindik ere. Hain zuzen ere, ingeniaritza-aukerek produktu bat beste bat baino nabarmen hobea bihur dezaketen arloak dira.
Gutxitan merezi du tratamendu bera inguruko iturgintza operatiboa. Makina beraren oinarrizko bertsio batek eta bertsio industrial batek sentsore, kontrol eta interfaze desberdinak behar izan ditzakete, baina ez lukete modu bereizirik behar gailuak identifikatzeko, firmware bertsioak jarraitzeko edo flota bat kudeatzeko.
Nahiago nuke ingeniariek denbora hori produktuak zelaian nola jokatzen duen hobetzen ikustea, taldeak beste produktu baterako dagoeneko dituen mekanikak berreraikitzen baino. Oinarri partekatu batek ez du ingeniaritza pertsonalizatuaren aukera murrizten; ahalegin hori azpiegiturak kontsumitzea saihesten du.
Benetako proba taldeak bigarren produktua hasten duenean dator.
Plataforma on batek hurrengo produktua lehenengoa baino errazagoa egiten du
Bigarren produktuak lehenengo produktuak bezalako plataforma-lana behar badu ere, oso gutxi berrerabili da benetan.
Aldaera berri batek aldatu ez diren eragiketa-ereduaren atalak heredatu ahal izan beharko lituzke: hornidura-fluxuak, identitatea, bizi-zikloaren mekanika, flota-tresnak, firmware-prozesuak, laguntza-ikusgarritasuna eta integrazio komunak. Ondoren, ingeniaritza-ahalegina desberdintasunetan jartzen da —agian sentsore-pakete berri bat, beste kontrol-fluxu bat edo bezeroentzako integrazio espezifiko bat—, oinarriak berreraiki beharrean.
Hardware belaunaldi berri batek ideia bera presio handiagoaren menpe jartzen du. Bere gaitasunak nabarmen alda daitezke unitate zaharragoak lanean jarraitzen duten bitartean. Plataforma heldu batek biak onar ditzake, taldea behartu gabe bi plataforma-pila bereizi mantentzera bezeroek produktu-familia bakar gisa hautematen dutenarentzat.
Honek ez du backend monolitiko bakarra behar. Produktu ezberdinek arkitektura-muga argiak behar izan ditzakete oraindik. Garrantzitsuena ingeniaritza-erantzukizun beraren bigarren inplementazio bat saihestea da arrazoi justifikaturik gabe.
Orduan bihurtzen da plataforma aktibo bat, metatutako gastu-kosturik gabe. Laguntzak tresna paralelo gutxiago ditu ulertzeko, bertsioek bide koherenteagoak jarraitzen dituzte, eta beste produktu bat gehitzea luzapen kontrolatu bat bihurtzen da, enpresak mugagabe heredatzen duen beste backend baten ordez.
Plataforma produktuaren arkitekturaren parte gisa tratatu
Produktu fisikoak berrikuspenak, zerbitzu-gaitasuna, fabrikazio-gaitasuna eta etorkizuneko aldaketak kontuan hartuta diseinatzen dira. Produktu konektatuek diziplina bera behar dute software aldetik.
Lehenengo backenda aldi baterakoa izan daiteke. Lehenengo hornidura-gidoia edo laguntza-tresna ere bai. Ez dago horretan berez ezer txarrik. Arazoak hasten dira aldi baterako mekanika horiek isilean arkitektura iraunkor bihurtzen direnean, produktua bera eboluzionatzen jarraitzen duen bitartean.
Ordurako, produktu konektatua ez da hardwarea, firmwarea eta aplikazio bat soilik izango. Gailu bakoitza identifikatzen duen, haren gaitasunak ulertzen dituen, konfigurazio egokia aplikatzen duen, eguneraketak onartzen dituen eta taldeei arazoak diagnostikatzen laguntzen dien azpiegituraren menpe dago, halaber.
Geruza hori produktuaren arkitektura gisa tratatzen denean, banaketa argiagoa da: mekanika estandarrak berrerabilgarriak dira, eta lan pertsonalizatua, berriz, produktu edo produktu-familia bat beste batetik bereizten duena aztertzen du.
Plataformarik indartsuena ez da lehenengo produktu konektatua posible egiten duena soilik. Ingeniaritza taldeari bigarren, hirugarren eta laugarren produktuak eraikitzeko aukera ematen diona da, backend berri bat heredatu gabe aldiro.
