TehnoloÄ£iju attÄ«stÄ«ba programmatÅ«ras un aparatÅ«ras jomÄ, jaunu sakaru protokolu parÄdÄ«Å”anÄs ir novedusi pie lietiskÄ interneta (IoT) paplaÅ”inÄÅ”anÄs. IerÄ«Äu skaits pieaug ar katru dienu, un tÄs Ä£enerÄ milzÄ«gu datu apjomu. TÄpÄc ir nepiecieÅ”ama Ärta sistÄmas arhitektÅ«ra, kas spÄj apstrÄdÄt, uzglabÄt un pÄrsÅ«tÄ«t Å”os datus.
Tagad Å”iem nolÅ«kiem tiek izmantoti mÄkoÅpakalpojumi. TomÄr arvien populÄrÄkÄ miglas skaitļoÅ”anas paradigma (Fog) var papildinÄt mÄkoÅa risinÄjumus, mÄrogojot un optimizÄjot IoT infrastruktÅ«ru.
MÄkoÅi spÄj aptvert lielÄko daļu IoT pieprasÄ«jumu. PiemÄram, nodroÅ”inÄt servisu uzraudzÄ«bu, Ätru jebkura ierÄ«Äu Ä£enerÄtÄ datu apjoma apstrÄdi, kÄ arÄ« to vizualizÄciju. Miglas skaitļoÅ”ana ir efektÄ«vÄka, risinot reÄllaika problÄmas. Tie nodroÅ”ina Ätru atbildi uz pieprasÄ«jumiem un minimÄlu datu apstrÄdes latentumu. Tas ir, migla papildina āmÄkoÅusā un paplaÅ”ina savas iespÄjas.
TomÄr galvenais jautÄjums ir atŔķirÄ«gs: kÄ tam visam vajadzÄtu mijiedarboties IoT kontekstÄ? KÄdi sakaru protokoli bÅ«s visefektÄ«vÄkie, strÄdÄjot kombinÄtÄ IoT-Fog-Cloud sistÄmÄ?
Neskatoties uz Ŕķietamo HTTP dominÄjoÅ”o stÄvokli, IoT, miglas un mÄkoÅu sistÄmÄs tiek izmantots liels skaits citu risinÄjumu. Tas ir tÄpÄc, ka IoT ir jÄapvieno dažÄdu ierÄ«Äu sensoru funkcionalitÄte ar lietotÄju droŔības, saderÄ«bas un citÄm prasÄ«bÄm.
Bet vienkÄrÅ”i nav vienotas idejas par atsauces arhitektÅ«ru un komunikÄcijas standartu. TÄpÄc jauna protokola izveide vai esoÅ”Ä protokola modificÄÅ”ana konkrÄtiem IoT uzdevumiem ir viens no svarÄ«gÄkajiem IT kopienas uzdevumiem.
KÄdi protokoli paÅ”laik tiek izmantoti un ko tie var piedÄvÄt? IzdomÄsim. Bet vispirms apspriedÄ«sim ekosistÄmas principus, kurÄ mijiedarbojas mÄkoÅi, migla un lietu internets.
IoT Miglas-mÄkoÅa (F2C) arhitektÅ«ra
JÅ«s droÅ”i vien esat pamanÄ«juÅ”i, cik daudz pūļu tiek ieguldÄ«ts, lai izpÄtÄ«tu priekÅ”rocÄ«bas un ieguvumus, kas saistÄ«ti ar gudru un koordinÄtu IoT, mÄkoÅu un miglas pÄrvaldÄ«bu. Ja nÄ, tad Å”eit ir trÄ«s standartizÄcijas iniciatÄ«vas: , Šø .
Ja iepriekÅ” tika Åemti vÄrÄ tikai 2 lÄ«meÅi, mÄkoÅi un gala ierÄ«ces, tad piedÄvÄtÄ arhitektÅ«ra ievieÅ” jaunu lÄ«meni - miglas skaitļoÅ”anu. Å ajÄ gadÄ«jumÄ miglas lÄ«meni var iedalÄ«t vairÄkos apakÅ”lÄ«meÅos atkarÄ«bÄ no resursu specifikas vai politiku kopas, kas nosaka dažÄdu ierÄ«Äu izmantoÅ”anu Å”ajos apakÅ”lÄ«meÅos.
KÄ varÄtu izskatÄ«ties Ŕī abstrakcija? Å eit ir tipiska IoT-Fog-Cloud ekosistÄma. IoT ierÄ«ces sÅ«ta datus uz ÄtrÄkiem serveriem un skaitļoÅ”anas ierÄ«cÄm, lai atrisinÄtu problÄmas, kurÄm nepiecieÅ”ams mazs latentums. TajÄ paÅ”Ä sistÄmÄ mÄkoÅi ir atbildÄ«gi par tÄdu problÄmu risinÄÅ”anu, kurÄm nepiecieÅ”ams liels daudzums skaitļoÅ”anas resursu vai datu uzglabÄÅ”anas vietas.
ViedtÄlruÅi, viedpulksteÅi un citi sÄ«krÄ«ki var bÅ«t arÄ« daļa no IoT. Bet Å”Ädas ierÄ«ces, kÄ likums, izmanto lielu izstrÄdÄtÄju patentÄtus sakaru protokolus. Ä¢enerÄtie IoT dati tiek pÄrsÅ«tÄ«ti uz miglas slÄni, izmantojot REST HTTP protokolu, kas nodroÅ”ina elastÄ«bu un savietojamÄ«bu, veidojot RESTful pakalpojumus. Tas ir svarÄ«gi, Åemot vÄrÄ nepiecieÅ”amÄ«bu nodroÅ”inÄt atpakaļsaderÄ«bu ar esoÅ”o skaitļoÅ”anas infrastruktÅ«ru, kas darbojas lokÄlos datoros, serveros vai serveru klasterÄ«. VietÄjie resursi, ko sauc par āmiglas mezgliemā, filtrÄ saÅemtos datus un apstrÄdÄ tos lokÄli vai nosÅ«ta uz mÄkoni turpmÄkiem aprÄÄ·iniem.
MÄkoÅi atbalsta dažÄdus sakaru protokolus, no kuriem visizplatÄ«tÄkie ir AMQP un REST HTTP. TÄ kÄ HTTP ir labi pazÄ«stams un pielÄgots internetam, var rasties jautÄjums: "Vai mums nevajadzÄtu to izmantot darbam ar IoT un miglu?" TomÄr Å”im protokolam ir veiktspÄjas problÄmas. VairÄk par to vÄlÄk.
KopumÄ mums nepiecieÅ”amajai sistÄmai ir piemÄroti 2 sakaru protokolu modeļi. Tie ir pieprasÄ«jums-atbilde un publicÄÅ”ana-abonÄÅ”ana. Pirmais modelis ir plaÅ”Äk pazÄ«stams, Ä«paÅ”i servera-klienta arhitektÅ«rÄ. Klients pieprasa informÄciju no servera, un serveris saÅem pieprasÄ«jumu, apstrÄdÄ to un atgriež atbildes ziÅojumu. Å ajÄ modelÄ« darbojas REST HTTP un CoAP protokoli.
Otrais modelis radÄs no nepiecieÅ”amÄ«bas nodroÅ”inÄt asinhronu, sadalÄ«tu, brÄ«vu savienojumu starp avotiem, kas Ä£enerÄ datus, un Å”o datu saÅÄmÄjiem.
Modelis paredz trÄ«s dalÄ«bniekus: izdevÄjs (datu avots), brokeris (dispeÄers) un abonents (saÅÄmÄjs). Å eit klientam, kas darbojas kÄ abonents, nav jÄpieprasa informÄcija no servera. TÄ vietÄ, lai nosÅ«tÄ«tu pieprasÄ«jumus, tÄ abonÄ noteiktus notikumus sistÄmÄ, izmantojot brokeri, kas ir atbildÄ«gs par visu ienÄkoÅ”o ziÅojumu filtrÄÅ”anu un to marÅ”rutÄÅ”anu starp izdevÄjiem un abonentiem. Un izdevÄjs, kad notiek notikums par noteiktu tÄmu, publicÄ to brokerim, kurÅ” nosÅ«ta datus par pieprasÄ«to tÄmu abonentam.
BÅ«tÄ«bÄ Å”Ä« arhitektÅ«ra ir balstÄ«ta uz notikumiem. Un Å”is mijiedarbÄ«bas modelis ir interesants lietojumprogrammÄm IoT, mÄkonÄ«, miglÄ, jo tas spÄj nodroÅ”inÄt mÄrogojamÄ«bu un vienkÄrÅ”ot dažÄdu ierÄ«Äu savstarpÄjo savienojumu, atbalsta dinamisku daudzu pret daudziem komunikÄciju un asinhrono komunikÄciju. Daži no vispazÄ«stamÄkajiem standartizÄtajiem ziÅojumapmaiÅas protokoliem, kas izmanto publicÄÅ”anas-abonÄÅ”anas modeli, ietver MQTT, AMQP un DDS.
AcÄ«mredzot publikÄcijas-abonÄÅ”anas modelim ir daudz priekÅ”rocÄ«bu:
- IzdevÄjiem un abonentiem nav jÄzina vienam par otra esamÄ«bu;
- Viens abonents var saÅemt informÄciju no daudziem dažÄdiem izdevumiem, un viens izdevÄjs var nosÅ«tÄ«t datus daudziem dažÄdiem abonentiem (princips "daudzi pret daudziem");
- IzdevÄjam un abonentam nav jÄbÅ«t aktÄ«viem vienlaikus, lai sazinÄtos, jo brokeris (strÄdÄ kÄ rindas sistÄma) varÄs saglabÄt ziÅojumu klientiem, kuri Å”obrÄ«d nav pieslÄgti tÄ«klam.
TomÄr pieprasÄ«juma-atbildes modelim ir arÄ« savas stiprÄs puses. GadÄ«jumos, kad servera puses spÄja apstrÄdÄt vairÄkus klientu pieprasÄ«jumus nav problÄma, ir lietderÄ«gi izmantot pÄrbaudÄ«tus, uzticamus risinÄjumus.
Ir arÄ« protokoli, kas atbalsta abus modeļus. PiemÄram, XMPP un HTTP 2.0, kas atbalsta opciju āservera pushā. IETF ir arÄ« izlaidis CoAP. MÄÄ£inot atrisinÄt ziÅojumapmaiÅas problÄmu, ir izveidoti vairÄki citi risinÄjumi, piemÄram, WebSockets protokols vai HTTP protokola izmantoÅ”ana, izmantojot QUIC (Quick UDP Internet Connections).
WebSockets gadÄ«jumÄ, lai gan to izmanto datu pÄrsÅ«tÄ«Å”anai reÄllaikÄ no servera uz tÄ«mekļa klientu un nodroÅ”ina pastÄvÄ«gus savienojumus ar vienlaicÄ«gu divvirzienu saziÅu, tas nav paredzÄts ierÄ«cÄm ar ierobežotiem skaitļoÅ”anas resursiem. QUIC arÄ« ir pelnÄ«jis uzmanÄ«bu, jo jaunais transporta protokols sniedz daudz jaunu iespÄju. TaÄu, tÄ kÄ QUIC vÄl nav standartizÄts, ir pÄragri prognozÄt tÄ iespÄjamo pielietojumu un ietekmi uz IoT risinÄjumiem. TÄpÄc mÄs paturam prÄtÄ WebSockets un QUIC, domÄjot par nÄkotni, taÄu pagaidÄm tos sÄ«kÄk nepÄtÄ«sim.
KurÅ” ir mīļÄkais pasaulÄ: protokolu salÄ«dzinÄÅ”ana
Tagad parunÄsim par protokolu stiprajÄm un vÄjajÄm pusÄm. Raugoties uz priekÅ”u, uzreiz izdarÄ«sim atrunu, ka nav viena izteikta lÄ«dera. Katram protokolam ir dažas priekÅ”rocÄ«bas / trÅ«kumi.
Reakcijas laiks
Viens no svarÄ«gÄkajiem komunikÄcijas protokolu raksturlielumiem, Ä«paÅ”i saistÄ«bÄ ar lietu internetu, ir reakcijas laiks. Bet starp esoÅ”ajiem protokoliem nav skaidra uzvarÄtÄja, kas parÄdÄ«tu minimÄlo latentuma lÄ«meni, strÄdÄjot dažÄdos apstÄkļos. Bet ir vesela virkne pÄtÄ«jumu un protokolu iespÄju salÄ«dzinÄjumu.
TÄ, piemÄram, HTTP un MQTT efektivitÄtes salÄ«dzinÄjumi, strÄdÄjot ar IoT, parÄdÄ«ja, ka atbildes laiks MQTT pieprasÄ«jumiem ir mazÄks nekÄ HTTP. Un tad, kad MQTT un CoAP brauciena turp un atpakaļ laiks (RTT) atklÄja, ka CoAP vidÄjais RTT ir par 20% mazÄks nekÄ MQTT.
Cits ar RTT MQTT un CoAP protokoliem tika veikta divos scenÄrijos: lokÄlais tÄ«kls un IoT tÄ«kls. IzrÄdÄ«jÄs, ka vidÄjais RTT IoT tÄ«klÄ ir 2-3 reizes augstÄks. MQTT ar QoS0 uzrÄdÄ«ja zemÄku rezultÄtu, salÄ«dzinot ar CoAP, un MQTT ar QoS1 uzrÄdÄ«ja augstÄku RTT ACK dÄļ lietojumprogrammas un transporta slÄÅos. DažÄdiem QoS lÄ«meÅiem tÄ«kla latentums bez pÄrslodzes bija milisekundes MQTT un simtiem mikrosekunžu CoAP. TomÄr ir vÄrts atcerÄties, ka, strÄdÄjot mazÄk uzticamos tÄ«klos, MQTT, kas darbojas virs TCP, parÄdÄ«s pavisam citu rezultÄtu.
atbildes laiks AMQP un MQTT protokoliem, palielinot lietderÄ«go slodzi, parÄdÄ«ja, ka ar nelielu slodzi latentuma lÄ«menis ir gandrÄ«z vienÄds. Bet, pÄrsÅ«tot lielu datu apjomu, MQTT parÄda Ä«sÄku reakcijas laiku. vÄl vienÄ CoAP tika salÄ«dzinÄts ar HTTP saziÅas scenÄrijÄ starp maŔīnÄm ar ierÄ«cÄm, kas izvietotas virs transportlÄ«dzekļiem, kas aprÄ«koti ar gÄzes sensoriem, laikapstÄkļu sensoriem, atraÅ”anÄs vietas sensoriem (GPS) un mobilÄ tÄ«kla saskarni (GPRS). Laiks, kas nepiecieÅ”ams CoAP ziÅojuma pÄrsÅ«tÄ«Å”anai mobilajÄ tÄ«klÄ, bija gandrÄ«z trÄ«s reizes Ä«sÄks nekÄ HTTP ziÅojumu izmantoÅ”anas laiks.
Ir veikti pÄtÄ«jumi, kuros salÄ«dzinÄti nevis divi, bet trÄ«s protokoli. PiemÄram, IoT protokolu MQTT, DDS un CoAP veiktspÄja medicÄ«niskÄs lietojumprogrammas scenÄrijÄ, izmantojot tÄ«kla emulatoru. DDS pÄrspÄja MQTT pÄrbaudÄ«tÄ telemetrijas latentuma ziÅÄ dažÄdos sliktos tÄ«kla apstÄkļos. Uz UDP balstÄ«ta CoAP darbojÄs labi lietojumprogrammÄm, kurÄm bija nepiecieÅ”ams Ätrs reakcijas laiks, tomÄr, tÄ kÄ tas ir balstÄ«ts uz UDP, bija ievÄrojams neparedzams pakeÅ”u zudums.
Joslas platums
MQTT un CoAP joslas platuma efektivitÄtes ziÅÄ tika veiktas kÄ kopÄjÄ ziÅojuma pÄrsÅ«tÄ«Å”anas datu apjoma aprÄÄ·ins. PÄrsÅ«tot mazus ziÅojumus, CoAP ir uzrÄdÄ«jis zemÄku caurlaidspÄju nekÄ MQTT. Bet, salÄ«dzinot protokolu efektivitÄti noderÄ«gÄs informÄcijas baitu skaita attiecÄ«bÄ pret kopÄjo pÄrsÅ«tÄ«to baitu skaitu, CoAP izrÄdÄ«jÄs efektÄ«vÄks.
Pie izmantojot MQTT, DDS (ar TCP kÄ transporta protokolu) un CoAP joslas platumu, tika konstatÄts, ka CoAP parasti uzrÄdÄ«ja salÄ«dzinoÅ”i mazÄku joslas platuma patÄriÅu, kas nepalielinÄjÄs, palielinoties tÄ«kla pakeÅ”u zudumam vai palielinot tÄ«kla latentumu, atŔķirÄ«bÄ no MQTT un DDS, kur bija joslas platuma izmantoÅ”anas pieaugums minÄtajos scenÄrijos. Cits scenÄrijs ietvÄra lielu skaitu ierÄ«Äu, kas vienlaikus pÄrraida datus, kas ir raksturÄ«gi IoT vidÄm. RezultÄti parÄdÄ«ja, ka lielÄkai izmantoÅ”anai labÄk izmantot CoAP.
Ar nelielu slodzi CoAP izmantoja vismazÄko joslas platumu, kam sekoja MQTT un REST HTTP. TomÄr, kad lietderÄ«gÄs slodzes lielums palielinÄjÄs, REST HTTP bija vislabÄkie rezultÄti.
EnerÄ£ijas patÄriÅÅ”
EnerÄ£ijas patÄriÅa jautÄjums vienmÄr ir ļoti svarÄ«gs, un jo Ä«paÅ”i IoT sistÄmÄ. Ja KamÄr MQTT un HTTP patÄrÄ elektrÄ«bu, HTTP patÄrÄ daudz vairÄk. Un CoAP ir vairÄk salÄ«dzinot ar MQTT, ļaujot pÄrvaldÄ«t jaudas pÄrvaldÄ«bu. TomÄr vienkÄrÅ”os scenÄrijos MQTT ir piemÄrotÄks informÄcijas apmaiÅai lietu interneta tÄ«klos, it Ä«paÅ”i, ja nav jaudas ierobežojumu.
EksperimentÄ, kurÄ tika salÄ«dzinÄtas AMQP un MQTT iespÄjas mobilajÄ vai nestabilÄ bezvadu tÄ«klÄ, tika atklÄts, ka AMQP piedÄvÄ vairÄk droŔības iespÄju, savukÄrt MQTT ir energoefektÄ«vÄka.
DroŔība
DroŔība ir vÄl viens bÅ«tisks jautÄjums, kas izvirzÄ«ts, pÄtot tÄmu par lietu internetu un miglas/mÄkoÅskaitļoÅ”anu. DroŔības mehÄnisms parasti ir balstÄ«ts uz TLS HTTP, MQTT, AMQP un XMPP vai DTLS CoAP, un atbalsta abus DDS variantus.
TLS un DTLS sÄkas ar saziÅas izveidoÅ”anas procesu starp klienta un servera pusÄm, lai apmainÄ«tos ar atbalstÄ«tajiem Å”ifru komplektiem un atslÄgÄm. Abas puses vienojas par komplektiem, lai nodroÅ”inÄtu, ka turpmÄka saziÅa notiek droÅ”Ä kanÄlÄ. AtŔķirÄ«ba starp abiem ir nelielÄs modifikÄcijÄs, kas ļauj UDP balstÄ«tam DTLS darboties neuzticamÄ savienojumÄ.
Pie VairÄkas dažÄdas TLS un DTLS ievieÅ”anas atklÄja, ka TLS paveica labÄku darbu. Uzbrukumi DTLS bija veiksmÄ«gÄki tÄ kļūdu tolerances dÄļ.
TomÄr lielÄkÄ problÄma ar Å”iem protokoliem ir tÄ, ka tie sÄkotnÄji nebija paredzÄti lietoÅ”anai IoT un nebija paredzÄti darbam miglÄ vai mÄkonÄ«. Izmantojot rokasspiedienu, tie pievieno papildu trafiku ar katru savienojuma izveidi, kas iztukÅ”o skaitļoÅ”anas resursus. VidÄji pieskaitÄmÄs izmaksas ir palielinÄjuÅ”Äs par 6,5% TLS un 11% attiecÄ«bÄ uz DTLS, salÄ«dzinot ar sakariem bez droŔības slÄÅa. Resursiem bagÄtÄs vidÄs, kas parasti atrodas uz lÄ«menÄ«, tÄ nebÅ«s problÄma, taÄu saistÄ«bÄ starp IoT un miglas lÄ«meni tas kļūst par svarÄ«gu ierobežojumu.
Ko izvÄlÄties? Skaidras atbildes nav. MQTT un HTTP, Ŕķiet, ir visdaudzsoloÅ”Äkie protokoli, jo tie tiek uzskatÄ«ti par salÄ«dzinoÅ”i nobrieduÅ”Äkiem un stabilÄkiem IoT risinÄjumiem salÄ«dzinÄjumÄ ar citiem protokoliem.
RisinÄjumi, kuru pamatÄ ir vienots sakaru protokols
Viena protokola risinÄjuma praksei ir daudz trÅ«kumu. PiemÄram, ierobežotai videi piemÄrots protokols var nedarboties domÄnÄ, kuram ir stingras droŔības prasÄ«bas. Paturot to prÄtÄ, mums ir jÄatmet gandrÄ«z visi iespÄjamie viena protokola risinÄjumi IoT ekosistÄmÄ Fog-to-Cloud, izÅemot MQTT un REST HTTP.
REST HTTP kÄ viena protokola risinÄjums
Ir labs piemÄrs tam, kÄ REST HTTP pieprasÄ«jumi un atbildes mijiedarbojas telpÄ IoT-to-Fog: . DzÄ«vnieki ir aprÄ«koti ar valkÄjamiem sensoriem (IoT klients, C), un tos kontrolÄ, izmantojot mÄkoÅdatoÅ”anu, izmantojot viedo lauksaimniecÄ«bas sistÄmu (Fog server, S).
POST metodes galvenÄ ir norÄdÄ«ts modificÄjamais resurss (/farm/animals), kÄ arÄ« HTTP versija un satura veids, kas Å”ajÄ gadÄ«jumÄ ir JSON objekts, kas attÄlo dzÄ«vnieku fermu, kas sistÄmai jÄpÄrvalda (Dulcinea/govs). . Atbilde no servera norÄda, ka pieprasÄ«jums bija veiksmÄ«gs, nosÅ«tot HTTPS statusa kodu 201 (resurss izveidots). GET metodei URI ir jÄnorÄda tikai pieprasÄ«tais resurss (piemÄram, /farm/animals/1), kas no servera atgriež dzÄ«vnieka JSON attÄlojumu ar Å”o ID.
PUT metode tiek izmantota, ja ir jÄatjaunina kÄds konkrÄts resursa ieraksts. Å ajÄ gadÄ«jumÄ resurss norÄda mainÄmÄ parametra URI un paÅ”reizÄjo vÄrtÄ«bu (piemÄram, norÄdot, ka govs paÅ”laik staigÄ, /farm/animals/1? state=walking). Visbeidzot, DELETE metode tiek izmantota lÄ«dzvÄrtÄ«gi GET metodei, bet operÄcijas rezultÄtÄ resurss tiek vienkÄrÅ”i izdzÄsts.
MQTT kÄ viena protokola risinÄjums
Å
emsim to paÅ”u viedo fermu, bet REST HTTP vietÄ izmantojam MQTT protokolu. VietÄjais serveris ar instalÄtu Mosquitto bibliotÄku darbojas kÄ starpnieks. Å ajÄ piemÄrÄ vienkÄrÅ”s dators (saukts par fermas serveri) Raspberry Pi kalpo kÄ MQTT klients, kas ieviests, instalÄjot Paho MQTT bibliotÄku, kas ir pilnÄ«bÄ saderÄ«ga ar Mosquitto brokeri.
Å is klients atbilst IoT abstrakcijas slÄnim, kas attÄlo ierÄ«ci ar sensoru un skaitļoÅ”anas iespÄjÄm. No otras puses, starpnieks atbilst augstÄkam abstrakcijas lÄ«menim, kas pÄrstÄv miglas skaitļoÅ”anas mezglu, kam raksturÄ«ga lielÄka apstrÄdes un uzglabÄÅ”anas jauda.
IerosinÄtajÄ viedÄs fermas scenÄrijÄ Raspberry Pi izveido savienojumu ar akselerometru, GPS un temperatÅ«ras sensoriem un publicÄ datus no Å”iem sensoriem miglas mezglÄ. KÄ jÅ«s droÅ”i vien zinÄt, MQTT tÄmas traktÄ kÄ hierarhiju. Viens MQTT izdevÄjs var publicÄt ziÅojumus par noteiktu tÄmu kopu. MÅ«su gadÄ«jumÄ tie ir trÄ«s. Sensoram, kas mÄra temperatÅ«ru dzÄ«vnieku kÅ«tÄ«, klients izvÄlas tÄmu (dzÄ«vnieku ferma/Ŕķūnis/temperatÅ«ra). Sensoriem, kas mÄra GPS atraÅ”anÄs vietu un dzÄ«vnieku kustÄ«bu, izmantojot akselerometru, klients publicÄs atjauninÄjumus (dzÄ«vnieku ferma/dzÄ«vnieks/GPS) un (dzÄ«vnieku ferma/dzÄ«vnieks/kustÄ«ba).
Å Ä« informÄcija tiks nodota brokerim, kurÅ” to var Ä«slaicÄ«gi saglabÄt vietÄjÄ datu bÄzÄ, ja vÄlÄk parÄdÄs cits ieinteresÄts abonents.
Papildus lokÄlajam serverim, kas darbojas kÄ MQTT brokeris miglÄ un kuram Raspberry Pis, kas darbojas kÄ MQTT klienti, sÅ«ta sensoru datus, mÄkoÅa lÄ«menÄ« var bÅ«t vÄl viens MQTT brokeris. Å ÄdÄ gadÄ«jumÄ vietÄjam brokerim nosÅ«tÄ«to informÄciju var Ä«slaicÄ«gi saglabÄt vietÄjÄ datu bÄzÄ un/vai nosÅ«tÄ«t uz mÄkoni. Miglas MQTT brokeris Å”ajÄ situÄcijÄ tiek izmantots, lai saistÄ«tu visus datus ar mÄkoÅa MQTT brokeri. Izmantojot Å”o arhitektÅ«ru, mobilÄs lietojumprogrammas lietotÄjs var abonÄt abus brokerus.
Ja savienojums ar vienu no brokeriem (piemÄram, mÄkonis) neizdodas, galalietotÄjs saÅems informÄciju no otra (migla). TÄ ir raksturÄ«ga kombinÄtajÄm miglas un mÄkoÅdatoÅ”anas sistÄmÄm. PÄc noklusÄjuma mobilo lietotni var konfigurÄt, lai vispirms izveidotu savienojumu ar miglas MQTT brokeri un, ja tas neizdodas, lai izveidotu savienojumu ar mÄkoÅa MQTT brokeri. Å is risinÄjums ir tikai viens no daudzajiem IoT-F2C sistÄmÄm.
VairÄku protokolu risinÄjumi
Viena protokola risinÄjumi ir populÄri to vienkÄrÅ”Äkas ievieÅ”anas dÄļ. Bet ir skaidrs, ka IoT-F2C sistÄmÄs ir jÄga apvienot dažÄdus protokolus. Ideja ir tÄda, ka dažÄdi protokoli var darboties dažÄdos lÄ«meÅos. Å emiet, piemÄram, trÄ«s abstrakcijas: IoT slÄÅus, miglu un mÄkoÅdatoÅ”anu. IerÄ«ces IoT lÄ«menÄ« parasti tiek uzskatÄ«tas par ierobežotÄm. Å ajÄ pÄrskatÄ uzskatÄ«sim, ka IoT lÄ«meÅi ir visierobežotÄkie, mÄkoÅdatoÅ”anas lÄ«meÅi ir vismazÄk ierobežotie, un miglas skaitļoÅ”ana kÄ "kaut kur pa vidu". PÄc tam izrÄdÄs, ka starp IoT un miglas abstrakcijÄm paÅ”reizÄjie protokolu risinÄjumi ietver MQTT, CoAP un XMPP. No otras puses, starp miglu un mÄkoni AMQP ir viens no galvenajiem izmantotajiem protokoliem, kÄ arÄ« REST HTTP, kas tÄ elastÄ«bas dÄļ tiek izmantots arÄ« starp IoT un miglas slÄÅiem.
GalvenÄ problÄma Å”eit ir protokolu savietojamÄ«ba un ziÅojumu pÄrsÅ«tÄ«Å”anas vienkÄrŔība no viena protokola uz otru. IdeÄlÄ gadÄ«jumÄ nÄkotnÄ lietu interneta sistÄmas arhitektÅ«ra ar mÄkoÅa un miglas resursiem bÅ«s neatkarÄ«ga no izmantotÄ sakaru protokola un nodroÅ”inÄs labu sadarbspÄju starp dažÄdiem protokoliem.
TÄ kÄ paÅ”laik tas tÄ nav, ir lietderÄ«gi apvienot protokolus, kuriem nav bÅ«tisku atŔķirÄ«bu. Å im nolÅ«kam viens potenciÄls risinÄjums ir balstÄ«ts uz divu protokolu kombinÄciju, kas atbilst vienam un tam paÅ”am arhitektÅ«ras stilam ā REST HTTP un CoAP. Cits piedÄvÄtais risinÄjums ir balstÄ«ts uz divu protokolu, kas piedÄvÄ publicÄÅ”anas un abonÄÅ”anas saziÅu, MQTT un AMQP kombinÄciju. Izmantojot lÄ«dzÄ«gas koncepcijas (gan MQTT, gan AMQP izmanto brokerus, CoAP un HTTP izmanto REST), Ŕīs kombinÄcijas ir vieglÄk ievieÅ”amas un prasa mazÄku integrÄcijas piepÅ«li.
AttÄlÄ (a) ir parÄdÄ«ti divi uz pieprasÄ«jumu-atbildi balstÄ«ti modeļi HTTP un CoAP, kÄ arÄ« to iespÄjamÄ izvietoÅ”ana IoT-F2C risinÄjumÄ. TÄ kÄ HTTP ir viens no vispazÄ«stamÄkajiem un pieÅemtajiem protokoliem mÅ«sdienu tÄ«klos, maz ticams, ka to pilnÄ«bÄ aizstÄs citi ziÅojumapmaiÅas protokoli. Starp mezgliem, kas pÄrstÄv jaudÄ«gas ierÄ«ces, kas atrodas starp mÄkoni un miglu, REST HTTP ir gudrs risinÄjums.
No otras puses, ierÄ«cÄm ar ierobežotiem skaitļoÅ”anas resursiem, kas sazinÄs starp miglas un IoT slÄni, efektÄ«vÄk ir izmantot CoAP. Viena no lielajÄm CoAP priekÅ”rocÄ«bÄm patiesÄ«bÄ ir tÄ saderÄ«ba ar HTTP, jo abi protokoli ir balstÄ«ti uz REST principiem.
AttÄlÄ (b) ir parÄdÄ«ti divi publicÄÅ”anas un abonÄÅ”anas saziÅas modeļi vienÄ un tajÄ paÅ”Ä scenÄrijÄ, tostarp MQTT un AMQP. Lai gan hipotÄtiski abus protokolus varÄtu izmantot saziÅai starp mezgliem katrÄ abstrakcijas slÄnÄ«, to atraÅ”anÄs vieta jÄnosaka, pamatojoties uz veiktspÄju. MQTT tika izstrÄdÄts kÄ viegls protokols ierÄ«cÄm ar ierobežotiem skaitļoÅ”anas resursiem, tÄpÄc to var izmantot IoT-Fog saziÅai. AMQP ir vairÄk piemÄrots jaudÄ«gÄkÄm ierÄ«cÄm, kas ideÄli novietotu to starp miglas un mÄkoÅu mezgliem. MQTT vietÄ IoT var izmantot XMPP protokolu, jo tas tiek uzskatÄ«ts par vieglu. Bet Å”Ädos scenÄrijos tas netiek tik plaÅ”i izmantots.
Atzinumi
Maz ticams, ka ar vienu no apspriestajiem protokoliem pietiks, lai aptvertu visas sistÄmas komunikÄcijas, sÄkot no ierÄ«cÄm ar ierobežotiem skaitļoÅ”anas resursiem lÄ«dz mÄkoÅserveriem. PÄtÄ«jumÄ konstatÄts, ka divas daudzsoloÅ”ÄkÄs iespÄjas, ko izstrÄdÄtÄji izmanto visvairÄk, ir MQTT un RESTful HTTP. Å ie divi protokoli ir ne tikai visnobrieduÅ”Äkie un stabilÄkie, bet arÄ« ietver daudzas labi dokumentÄtas un veiksmÄ«gas ievieÅ”anas un tieÅ”saistes resursus.
TÄ stabilitÄtes un vienkÄrÅ”Äs konfigurÄcijas dÄļ MQTT ir protokols, kas laika gaitÄ ir pierÄdÄ«jis savu izcilo veiktspÄju, izmantojot IoT lÄ«menÄ« ar ierobežotÄm ierÄ«cÄm. SistÄmas daļÄs, kur ierobežota saziÅa un akumulatora patÄriÅÅ” nav problÄma, piemÄram, daži miglas domÄni un lielÄkÄ daļa mÄkoÅdatoÅ”anas, RESTful HTTP ir vienkÄrÅ”a izvÄle. JÄÅem vÄrÄ arÄ« CoAP, jo tas arÄ« strauji attÄ«stÄs kÄ IoT ziÅojumapmaiÅas standarts un, visticamÄk, tuvÄkajÄ nÄkotnÄ sasniegs tÄdu stabilitÄtes un brieduma lÄ«meni, kas lÄ«dzinÄs MQTT un HTTP. Bet standarts paÅ”laik attÄ«stÄs, un tas ir saistÄ«ts ar Ä«stermiÅa saderÄ«bas problÄmÄm.
Ko vÄl var lasÄ«t emuÄrÄ?
ā
ā
ā
ā
ā
AbonÄjiet mÅ«su -kanÄls, lai nepalaistu garÄm nÄkamo rakstu! MÄs rakstÄm ne biežÄk kÄ divas reizes nedÄÄ¼Ä un tikai darba kÄrtÄ«bÄ.
Avots: www.habr.com