Lietiskais internets: zilā (zobu) apgriešana malās? - 💡 Fix My Ideas

Lietiskais internets: zilā (zobu) apgriešana malās?

Lietiskais internets: zilā (zobu) apgriešana malās?


Autors: Ethan Holmes, 2019

Neatkarīgi no tā, vai jūs pārraugāt savu mājokli brīvdienu laikā, vai apsildāt savu nedēļas nogales māju pirms došanās ceļojumā - lietiskā interneta lietojumprogramma izmanto interneta protokolus, lai sazinātos starp šeit un tur. Šī iemesla dēļ es pirms trīs gadiem definēju IoT kā „globālu datoru, sensoru un izpildmehānismu tīklu, kas savienots ar interneta protokoliem”.

Tas ir ievērojami vienkāršots, ideāli veidots priekšstats par jauno IoT. Tā ir skaisti skaidras tehnoloģijas ainavas vīzija, kur IP paketes var pārvietoties no temperatūras sensora uz mākoņa datu centru un atpakaļ uz sildītāja kontroli. Bez nevēlamas protokola konversijas, bez sarežģītiem vārtiem, kas ir sarežģīti konfigurēt vai programmēt.

Mūsdienās pilnīgs priekšstats ir gluži pretējs: dažkārt papildinoši, bieži konkurējoši standarti (“jo vairāk, jo vairāk”):

Es bieži brīnos, kā attēls izskatīsies vēl trīs gados vai 10 gados. Ir jautri pievienot vēl vairāk tehnoloģiju attēlam. Mazāk jautrība ir likt derības par konkrētām tehnoloģijām, ieguldot savus draugus un savu dzīves laiku un asinis, sviedri un asaras. Vai arī sniegt ieteikumus klientiem, kas vienkārši varētu izrādīties briesmīgi nepareizi.

Augsts ceļš vai zemais ceļš?

Es esmu ievērojis divus veidus, kā cilvēki reaģē uz šo nenoteiktību. Viens no veidiem ir drebēt un pēc tam uzvilkt savas piedurknes - darīsim visu, kas ir mūsu spēkos, lai tuvotos ideālam; pieņemsim IP protokolus visur - galu galā, IP protokoli vēsturiski ir uzvarējuši pret visiem konkurējošiem protokoliem ”. Otrs veids ir plecusies “tas, kā pasaulē darbojas; konkurence ir laba lieta, un tas, kas ir visai satraukums par interneta protokoliem - šajā jomā ir tik daudz citu pierādītu tehnoloģiju, pieņemsim individuāli izvēlēties pareizo darbu.

Nosauksim to par vienu “augsto ceļu”, salīdzinot ar daudzām “zemo ceļu” perspektīvām. Tas ir aizraujošs karaspēks ar daudziem apsildāmiem strīdiem: „jums ir nepieciešams optimizēts bezvadu protokols sensoru tīklam, kas jau no paša sākuma ir paredzēts, lai patērētu mazu enerģijas patēriņu, pretējā gadījumā jums būs pārāk daudz strāvas padeves, lai tas būtu praktisks - aizmirst par IP protokoliem “Pret” mēs varam darīt IP galvenes saspiešanu un citus trikus, tāpēc mēs netērējam daudz enerģijas bezvadu sensorā no sensoriem uz maršrutētāju - IP ir biļete uz nākotni ”.

Tehniskie strīdi parasti ir vērsti uz dažām arhitektūras īpašībām, kas ir īpaši nozīmīgas lietiskā interneta pēdējās jūdzes vai drīzāk pēdējo pāris metru garumā. Tādā gadījumā IoT "kļūst fiziski": minimāls enerģijas patēriņš akumulatora darbināmam iekārtas sensoram jūsu dārzā, reāllaika determinisms konveijera lentes kontrolei, sistēmas administrēšanas vieglums, kad sysadmins ir tehniskais iesācējs un astoņdesmit gadu vecs vidēji ( viens no mūsu klientiem ražo dzirdes aparātus ...), vienkārša atslēgu pārvaldība mašīnbūves kontrolieriem, kurus uzstādījuši minimāli apmācīti lauka tehniķi utt.

Vai interneta protokoli ir pietiekami labi pat šādos scenārijos? Cik labi ir pietiekami labi? Pat pēc daudzu argumentu un pētniecisku rakstu lasīšanas, man šķiet, ka abām pusēm ir labi argumenti, bet man tas joprojām ir tumšs, kurš būs taisnīgs ilgtermiņā. Reizēm es paši saplīstu, bet citreiz es esmu shrugging. Interneta protokoliem, protams, ir iespaidīgs uzskaite, lai atņemtu patentētus protokolus, piemēram, IBM Token Ring, un iekarojot pat laukus, kas tiem nav acīmredzami piemēroti, piemēram, Ethernet ir veiksmīgi pārveidots, lai garantētu reāllaika uzvedību rūpnieciskiem lietojumiem . (Lai gan ir grūti izvēlēties starp vairāk nekā 20 (!) Priekšlikumiem, kas ir par viltību par reālā laika Ethernet wannabe standartiem ...)

Vai tas ir vienkārši laika jautājums, kamēr interneta protokoli neietver visus pārējos „mantojuma” protokolus, jo šķiet, ka viņu vēsture liecina?

Bluetooth zema enerģija

Pastāv vismaz divi pretparaugi. Sakaru tehnoloģijas, kas ir izdevušās paralēli internetam: USB un Bluetooth. Viņi ir izrādījušies diezgan neaizsargāti pret interneta protokoliem, lai gan ir iespējama IP protokolu tunelēšana. Tātad, varbūt, pēdējie metodi IoT var palikt arī imūni?

2005. gadā klienta CTO man teica par eksotisku bezvadu tehnoloģiju, kas tiek izstrādāta Nokia pētniecības centrā, ko sauc par Wibree. Tas izrādījās ļoti daudzsološi attiecībā uz maza darbības attāluma, mazjaudas scenārijiem mājas automatizācijā, medicīnas lietojumos un citos lietošanas gadījumos. Dažus gadus vēlāk, ļoti gudrā kustībā, Nokia nodeva kontroli pār Wibree Bluetooth īpašo interešu grupai. Pēc tam tehnoloģija tika pārveidota, lai labāk atbilstu esošajam Bluetooth standartam, un 2010. gadā kļuva par oficiālu Bluetooth 4.0 daļu. Tās pašreizējais nosaukums ir Bluetooth zema enerģija (BLE), vai Bluetooth Smart kā tirdzniecības marķējumu.

Viena no BLE iezīmēm, kas padara to gatavu sprādzienbīstamai izaugsmei, neskatoties uz IP protokoliem, ir tās minimālā papildu maksa, salīdzinot ar klasisko Bluetooth risinājumu: tas ir ļoti mazs, lai uzlabotu esošo Bluetooth iespējotu produktu, lai atbalstītu arī BLE. Sākot ar iPhone 4s, Apple ir sākusi atbalstīt BLE visos tās produktos. Ne tikai iekļaujot jaunākas Bluetooth mikroshēmas, bet arī ar API, ko var izmantot, lai izstrādātu BLE-iespējotas lietotnes. Šāda lietojumprogramma kopā ar ierīci, ko tā savieno, dažreiz tiek saukta par “papildinājumu”. Piemēram, lauka tehniķis var izmantot savu viedtālruni, lai izveidotu jaunu sūkni, izmantojot BLE - sūknim nav nepieciešams savs LCD ekrāns šim nolūkam nav pat USB spraudņa. Vajadzības gadījumā lietotne var pat darboties kā pagaidu vārteja no drukas iekārtas uz internetu, piem. tā, lai drukas iekārta varētu ielādēt jaunu programmaparatūru.

Protams, nevajadzētu būt visai biznesam: viens no mūsu pirmajiem braucieniem šajā jaunajā laukā bija elektronisks adventistu vainags, kas bija gatavs 2012. gada Ziemassvētkos. Tas bija interesants uzdevums. Piemēram, Apple sagaida, ka nosūtīsit viņiem vienu no savām ierīcēm, pretējā gadījumā tās neapstiprinās jūsu lietotni lietotņu veikalā. Mēs domājām, vai BMW, ja viņi kādreiz uzbūvēs BLE atbalstu vienā no luksusa automobiļiem, būtu jānosūta arī Apple automašīna?

Pagājušajā gadā Google arī pēdējo reizi pievienoja BLE atbalstu Android API, un šogad Microsoft vajadzētu sekot līdzi Windows Phone. Tas padarīs BLE patiesu pārrobežu platformu tehnoloģiju, sākot no fitnesa ierīcēm, piemēram, kurpju sensoriem vai sirdsdarbības monitoriem, uz gudriem pulksteņiem un visu, kas atrodas tuvumā, ko jūs varētu vēlēties kontrolēt: durvis, televizori, smidzinātāji dārzā utt.

Jaunā Google API bija iespēja arī Android lietotnei Adventes vainagiem 2013. gada Ziemassvētkos. Google BLE ieviešana bija ļoti agra un vēl nav tik nobriedusi kā Apple, kurai vēl ir daži jautājumi. Bet lietas nepārtraukti uzlabojas, un attīstītāji apmainās ar savu pieredzi, piemēram, šeit Facebook grupā, kuru mēs šim nolūkam izveidojām.

Vai tas ir šeit, lai paliktu?

BLE, iespējams, ir viena no jaunajām komunikāciju tehnoloģijām, ko neapdraud interneta juggernaut. Pat tās izsmalcinātajā vecumā jau pats par sevi saprotams: es nesen dzirdēju par konkursu par ēku automatizācijas projektu, kur BLE atbalsts tika piešķirts apgaismes priekšmetiem - zonai, kurā es būtu gaidījis ZigBee. Šķiet, ka arguments „jūs varat to kontrolēt no viedtālruņa vai planšetdatora” pārspēj gandrīz jebkuru pretargumentu, ko jūs varētu atrast pret BLE. Dažreiz tas kļūst nereāls: mēs esam sazinājušies ar startu, kas ir izveidojis savu biznesa ideju, pieņemot, ka ir iespējams savienot simtiem BLE sensoru visā lielajā komerciālajā ēkā tieši uz vienu GSM vārteju. Diemžēl BLE šobrīd patiešām ir pēdējo pāris metru tehnoloģija, tas droši nedarbosies vairākos stāvos un duci sienas…

Uz pakalpojumiem orientēta ierīču arhitektūra

Manā cepurē kā programmatūras arhitekts es uzskatu, ka viens BLE aspekts ir arī intriģējošs un dažkārt arī kairinošs: tas saliek ļoti zemu optimizācijas līmeni ar ļoti augsta līmeņa arhitektūras koncepcijām. Tā ir izstrādāta tā, lai optimizētu zemu enerģijas patēriņu, cenšoties mazināt bitu un baitu skaitu, kas jāpārsūta. Tomēr tā arī definē tā saukto vispārējs atribūtu profils (GATT), kas ietver īpašības (piem., gaisa temperatūra telpā vai vārsta atvērts / slēgts stāvoklis) pakalpojumiemun saistīto pakalpojumu kopas profilus. Profils atbilst lietošanas gadījumam, piem. asinsspiediena mērīšanas profils ir piemērots asinsspiediena mērīšanai. Pakalpojums ir atkārtoti lietojams interfeiss, piem. ierīces informācijas pakalpojums, kas sniedz informāciju, piemēram, ierīces ražotāju un modeļa numuru.

Firmware hell: DLL ellē steroīdi

Pakalpojumi ir galvenais BLE jēdziens. Pakalpojums definē nemainīgu parametru kopumu. Kāpēc nemainīgs? Un kādā veidā tas varētu kļūt nozīmīgs jums? Iemesls tam ir tas, ka lielākā daļa zemo izmaksu ierīču nav paredzētas, lai padarītu programmaparatūras atjauninājumus viegli vai vispār. Tāpēc, tiklīdz jūs sāksiet pārdot šādu ierīci, jums ir problēma, ja vēlaties mainīt pakalpojumu, piem. lai pievienotu tam noderīgu raksturlielumu. Jaunā programmaparatūra nesasniegs visas ierīces, kas atrodas savvaļā. Problēma ir tā, ka, ja atjaunināta viedtālruņa lietotne mēģina piekļūt šai jaunajai pazīmei vecā ierīcē, nekas labs nenotiks. Šāda versiju neatbilstība starp komponentiem ir pazīstama kā “DLL elle” programmatūras pasaulē. Tur vismaz var novērst neatbilstību, pārinstalējot saderīgu failu kopu. Ja jums ir virkne nesaderīgu ierīču, bez jebkāda veida atjaunināt savu programmaparatūru, jūs esat vēl sliktāk "firmware hell".

Tādējādi ideja ir saglabāt pakalpojumu definīciju ServiceA nemainās, kad tiek piegādātas ierīces ar šo pakalpojumu *. Kad vēlāk ir jāmaina pakalpojums, pievienojat jaunu pakalpojuma definīciju PakalpojumsA1, kas ir ServiceA piemēram, tam piemīt papildu raksturojums. Jaunas ierīces izmanto abus pakalpojumus (lēti to darīt, ja abi ir identiski, izņemot papildu raksturlielumus). Ir četri zvaigznāji, kuros pakalpojuma sniedzējs (“perifērijs”) var tikties ar šī pakalpojuma lietotāju (“centrālo”). Pieņemsim, ka centrālais ir jūsu viedtālrunis:

  1. Jūsu viedtālrunis ar lietotni oriģināls pakalpojums atbilst oriģināls ierīce: tā meklē ServiceA uz ierīces, atrod to, un viss ir labi.
  2. Jūsu viedtālrunis ar lietotni oriģināls pakalpojums atbilst pagarināts ierīce: tā meklē ServiceA uz ierīces, atrod to, un viss ir labi. Tā kā lietotne nezina par papildu parametru, ko atbalsta paplašinātā ierīce, tā to nevar izmantot, bet tā ir labi. Tā joprojām var nodrošināt sākotnējo funkcionalitāti.
  3. Jūsu viedtālrunis ar lietotni pagarināts pakalpojums atbilst pagarināts ierīce: tā meklē PakalpojumsA1 uz ierīces, atrod to, un viss ir labi. Lietotne zina un var izmantot papildu raksturlielumus.
  4. Jūsu viedtālrunis ar lietotni pagarināts pakalpojums atbilst oriģināls ierīce: tā meklē PakalpojumsA1 ierīcē, bet ierīce reaģē ar “vai? nekad nav dzirdējis PakalpojumsA1! ”. Tātad lietotne mēģina meklēt vecākus ServiceA, un voilà, tas var graciozi atgriezties pie šī vecākā pakalpojuma. Ne tik atdzist kā ar jaunu ierīci, bet tā darbojas.

Šeit šie četri zvaigznāji ir diagramma:

Ja jūs zināt, ka vecākas ierīces vairs netiek izmantotas vai jūs vairs nevēlaties tās atbalstīt, nākamajai lietotnes versijai ir jāatbild atšķirīgi: ja ierīce neatbalsta PakalpojumsA1, lietojumprogramma atsakās un paziņo lietotājam, ka šī ierīce nav saderīga. Tātad jums nav jāturpina vecā bagāža uz visiem laikiem, tik ilgi, kamēr jūsu lietotāji to pieprasa.

Šis mehānisms ir būtisks nākotnei, kurā visu veidu ierīces un lietotnes tiek savstarpēji savienotas, un šie komponenti var būt jebkuras jaunas, ne tik jaunas vai senas versijas kombinācijā.

Interneta protokoli kodolā, citas tehnoloģijas malās

Izskatās, ka zemu ceļu labirints būs ar mums ilgu laiku, un dažādi piebraucamie ceļi un izkāpšana no augstceļa. Jo īpaši tīkla malās dažas minūtes paliks pie mums. Viens no tiem ir BLE, pat ja tas neatbalsta interneta protokolus, vai uzlabotas funkcijas, piemēram, tīkla maršrutēšana. Es ceru, ka augstā interese par BLE nekļūs par tās lielāko problēmu: ir vairākas grupas, kas strādā pie priekšlikumiem par BLE paplašināšanu vienā vai otrā veidā; BLE mezgli ir daļa no jaunās Bluetooth 4.1 specifikācijas; un jau ir mēģinājums darbināt IPv6 pār BLE ...

Bet kā ar citām „IoT malu tehnoloģijām”, kas var būt noderīgas, bet ne vienlaidus integrētas IP protokola pasaulē? Kad to ieguvumi (piemēram, ir viegli pieejami, ideāli piemēroti darbam utt.) Atsver to trūkumus (piemēram, lai apgūtu jaunu tehnoloģiju, mazāk “tīkla efektu” utt.)? Līdzīgs jautājums rodas augstākā līmenī, lietojumprogrammu slāņa protokoliem: kad mums vajadzētu koncentrēties uz HTTP kā vienotu vienojošu protokolu lietām "Web", un kad mums vajadzētu pāriet uz MQTT, XMPP, AMQP, ZeroMQ un patīk?

Kāds ir jūsu jautājums šajos jautājumos? Es gribētu dzirdēt no jums!

* Ja jūs zināt Microsoft komponentu objekta modeli (COM), jūs atpazīsit šo ideju. Līdzīgi BLE pakalpojumam COM saskarne ir nemainīga metožu kolekcija. Man, viena no inovatīvākajām un svarīgākajām idejām, kas kādreiz nāk no Microsoft, tikai, lai pazaudētu tos, kas vēlāk izstrādāja .NET un nesen atklāja tos, kuri izstrādāja jauno Windows Runtime.



Jums Var Būt Interesē

Jautājiet MAKE: Inženierzinātņu fakultātēm

Jautājiet MAKE: Inženierzinātņu fakultātēm


Laipni lūdzam Brookelynn Morris!

Laipni lūdzam Brookelynn Morris!


Kā-Kā: Kāzu ziedi līgavas pusei

Kā-Kā: Kāzu ziedi līgavas pusei


Grāmatas izvilkums: Intro no Eugenia Bone

Grāmatas izvilkums: Intro no Eugenia Bone