Ang pag-unlad ng mga teknolohiya sa larangan ng software at hardware, ang paglitaw ng mga bagong protocol ng komunikasyon ay humantong sa pagpapalawak ng Internet of Things (IoT). Ang bilang ng mga aparato ay lumalaki araw-araw at sila ay bumubuo ng isang malaking halaga ng data. Samakatuwid, mayroong pangangailangan para sa isang maginhawang arkitektura ng system na may kakayahang pagproseso, pag-iimbak at pagpapadala ng data na ito.
Ngayon ang mga serbisyo ng ulap ay ginagamit para sa mga layuning ito. Gayunpaman, ang lalong sikat na fog computing paradigm (Fog) ay maaaring umakma sa mga solusyon sa ulap sa pamamagitan ng pag-scale at pag-optimize ng imprastraktura ng IoT.
Ang mga ulap ay may kakayahang saklawin ang karamihan sa mga kahilingan sa IoT. Halimbawa, upang magbigay ng pagsubaybay sa mga serbisyo, mabilis na pagproseso ng anumang dami ng data na nabuo ng mga device, pati na rin ang kanilang visualization. Ang fog computing ay mas epektibo kapag nilulutas ang mga real-time na problema. Nagbibigay ang mga ito ng mabilis na pagtugon sa mga kahilingan at kaunting latency sa pagproseso ng data. Iyon ay, ang Fog ay umaakma sa "ulap" at nagpapalawak ng mga kakayahan nito.
Gayunpaman, iba ang pangunahing tanong: paano dapat makipag-ugnayan ang lahat ng ito sa konteksto ng IoT? Anong mga protocol ng komunikasyon ang magiging pinakaepektibo kapag nagtatrabaho sa isang pinagsamang IoT-Fog-Cloud system?
Sa kabila ng maliwanag na pangingibabaw ng HTTP, mayroong isang malaking bilang ng iba pang mga solusyon na ginagamit sa IoT, Fog at Cloud system. Ito ay dahil dapat pagsamahin ng IoT ang functionality ng iba't ibang sensor ng device sa seguridad, compatibility, at iba pang mga kinakailangan ng mga user.
Ngunit walang iisang ideya tungkol sa arkitektura ng sanggunian at pamantayan ng komunikasyon. Samakatuwid, ang paggawa ng bagong protocol o pagbabago ng umiiral na para sa mga partikular na gawain ng IoT ay isa sa pinakamahalagang gawain na kinakaharap ng komunidad ng IT.
Anong mga protocol ang kasalukuyang ginagamit at ano ang maiaalok ng mga ito? Alamin natin ito. Ngunit una, talakayin natin ang mga prinsipyo ng ecosystem kung saan nakikipag-ugnayan ang mga ulap, fog at ang Internet ng mga bagay.
IoT Fog-to-Cloud (F2C) Architecture
Marahil ay napansin mo kung gaano karaming pagsisikap ang ginagawa sa pagtuklas sa mga pakinabang at benepisyong nauugnay sa matalino at magkakaugnay na pamamahala ng IoT, cloud at fog. Kung hindi, narito ang tatlong hakbangin sa standardisasyon:
Kung dati ay 2 level lang ang isinasaalang-alang, clouds at end device, ang iminungkahing arkitektura ay nagpapakilala ng bagong level - fog computing. Sa kasong ito, ang antas ng fog ay maaaring hatiin sa ilang mga sublevel, depende sa mga detalye ng mga mapagkukunan o isang hanay ng mga patakaran na tumutukoy sa paggamit ng iba't ibang mga device sa mga sublevel na ito.
Ano kaya ang hitsura ng abstraction na ito? Narito ang isang tipikal na IoT-Fog-Cloud ecosystem. Ang mga IoT device ay nagpapadala ng data sa mas mabilis na mga server at computing device upang malutas ang mga problema na nangangailangan ng mababang latency. Sa parehong sistema, ang mga ulap ay may pananagutan sa paglutas ng mga problema na nangangailangan ng malaking halaga ng mga mapagkukunan sa pag-compute o espasyo sa imbakan ng data.
Ang mga smartphone, matalinong relo at iba pang gadget ay maaari ding maging bahagi ng IoT. Ngunit ang mga naturang device, bilang panuntunan, ay gumagamit ng mga proprietary na protocol ng komunikasyon mula sa malalaking developer. Ang nabuong data ng IoT ay inililipat sa fog layer sa pamamagitan ng REST HTTP protocol, na nagbibigay ng flexibility at interoperability kapag gumagawa ng mga RESTful na serbisyo. Mahalaga ito dahil sa pangangailangang tiyakin ang pabalik na pagkakatugma sa umiiral na imprastraktura ng computing na tumatakbo sa mga lokal na computer, server o isang cluster ng server. Ang mga lokal na mapagkukunan, na tinatawag na "fog nodes," ay sinasala ang natanggap na data at iproseso ito nang lokal o ipadala ito sa cloud para sa karagdagang mga kalkulasyon.
Sinusuportahan ng mga ulap ang iba't ibang mga protocol ng komunikasyon, ang pinakakaraniwan ay ang AMQP at REST HTTP. Dahil ang HTTP ay kilala at iniakma para sa Internet, ang tanong ay maaaring lumitaw: "hindi ba natin ito dapat gamitin upang gumana sa IoT at fog?" Gayunpaman, ang protocol na ito ay may mga isyu sa pagganap. Higit pa tungkol dito mamaya.
Sa pangkalahatan, mayroong 2 modelo ng mga protocol ng komunikasyon na angkop para sa system na kailangan namin. Ito ay kahilingan-tugon at mag-publish-subscribe. Ang unang modelo ay mas kilala, lalo na sa arkitektura ng server-client. Ang kliyente ay humihiling ng impormasyon mula sa server, at natatanggap ng server ang kahilingan, pinoproseso ito at nagbabalik ng isang mensahe ng tugon. Gumagana ang REST HTTP at CoAP protocol sa modelong ito.
Ang pangalawang modelo ay nagmula sa pangangailangang magbigay ng asynchronous, distributed, loose coupling sa pagitan ng mga source na bumubuo ng data at ng mga tatanggap ng data na ito.
Ipinapalagay ng modelo ang tatlong kalahok: isang publisher (data source), isang broker (dispatcher) at isang subscriber (receiver). Dito, ang kliyente na kumikilos bilang isang subscriber ay hindi kailangang humiling ng impormasyon mula sa server. Sa halip na magpadala ng mga kahilingan, nagsu-subscribe ito sa ilang partikular na kaganapan sa system sa pamamagitan ng isang broker, na responsable sa pag-filter ng lahat ng papasok na mensahe at pagruruta sa mga ito sa pagitan ng mga publisher at subscriber. At ang publisher, kapag naganap ang isang kaganapan tungkol sa isang partikular na paksa, ini-publish ito sa broker, na nagpapadala ng data sa hiniling na paksa sa subscriber.
Sa pangkalahatan, ang arkitektura na ito ay batay sa kaganapan. At ang modelo ng pakikipag-ugnayan na ito ay kawili-wili para sa mga application sa IoT, cloud, fog dahil sa kakayahang magbigay ng scalability at pasimplehin ang interconnection sa pagitan ng iba't ibang device, suportahan ang dynamic na marami-sa-maraming komunikasyon at asynchronous na komunikasyon. Ang ilan sa mga pinakakilalang standardized messaging protocol na gumagamit ng publish-subscribe na modelo ay kinabibilangan ng MQTT, AMQP, at DDS.
Malinaw, ang modelo ng pag-publish-subscribe ay may maraming mga pakinabang:
- Hindi kailangang malaman ng mga publisher at subscriber ang tungkol sa pagkakaroon ng isa't isa;
- Ang isang subscriber ay maaaring makatanggap ng impormasyon mula sa maraming iba't ibang publikasyon, at ang isang publisher ay maaaring magpadala ng data sa maraming iba't ibang mga subscriber (many-to-many na prinsipyo);
- Ang publisher at subscriber ay hindi kailangang maging aktibo sa parehong oras upang makipag-usap, dahil ang broker (nagtatrabaho bilang isang queuing system) ay makakapag-imbak ng mensahe para sa mga kliyente na kasalukuyang hindi nakakonekta sa network.
Gayunpaman, ang modelo ng kahilingan-tugon ay mayroon ding mga lakas nito. Sa mga kaso kung saan ang kakayahan ng panig ng server na pangasiwaan ang maraming kahilingan ng kliyente ay hindi isang isyu, makatuwirang gumamit ng mga napatunayan, maaasahang solusyon.
Mayroon ding mga protocol na sumusuporta sa parehong mga modelo. Halimbawa, ang XMPP at HTTP 2.0, na sumusuporta sa opsyong "server push". Ang IETF ay naglabas din ng isang CoAP. Sa pagtatangkang lutasin ang problema sa pagmemensahe, maraming iba pang solusyon ang nagawa, gaya ng WebSockets protocol o ang paggamit ng HTTP protocol sa QUIC (Quick UDP Internet Connections).
Sa kaso ng WebSockets, bagama't ginagamit ito upang maglipat ng data sa real time mula sa isang server patungo sa isang web client at nagbibigay ng patuloy na mga koneksyon na may sabay-sabay na bidirectional na komunikasyon, hindi ito inilaan para sa mga device na may limitadong mga mapagkukunan ng computing. Ang QUIC ay nararapat ding pansinin, dahil ang bagong transport protocol ay nagbibigay ng maraming bagong pagkakataon. Ngunit dahil hindi pa na-standardize ang QUIC, napaaga pa upang mahulaan ang posibleng aplikasyon at epekto nito sa mga solusyon sa IoT. Kaya't isinasaisip namin ang WebSockets at QUIC nang may mata sa hinaharap, ngunit hindi namin ito pag-aaralan nang mas detalyado sa ngayon.
Sino ang pinaka-cute sa mundo: paghahambing ng mga protocol
Ngayon pag-usapan natin ang mga kalakasan at kahinaan ng mga protocol. Pagtingin sa unahan, gumawa tayo agad ng reserbasyon na walang malinaw na pinuno. Ang bawat protocol ay may ilang mga pakinabang / disadvantages.
Oras ng pagtugon
Ang isa sa pinakamahalagang katangian ng mga protocol ng komunikasyon, lalo na may kaugnayan sa Internet of Things, ay ang oras ng pagtugon. Ngunit kabilang sa mga umiiral na protocol, walang malinaw na nagwagi na nagpapakita ng pinakamababang antas ng latency kapag nagtatrabaho sa ilalim ng iba't ibang mga kondisyon. Ngunit mayroong isang buong bungkos ng pananaliksik at paghahambing ng mga kakayahan sa protocol.
Halimbawa,
Iba
Ang mga pag-aaral ay isinagawa na inihambing hindi dalawa, ngunit tatlong mga protocol. Halimbawa,
Throughput
Sa
Sa ilalim ng magaan na pag-load, ginamit ng CoAP ang pinakamababang bandwidth, na sinusundan ng MQTT at REST HTTP. Gayunpaman, nang tumaas ang laki ng mga payload, ang REST HTTP ay nagkaroon ng pinakamahusay na mga resulta.
Power Consumption
Ang isyu ng pagkonsumo ng enerhiya ay palaging napakahalaga, at lalo na sa isang IoT system. Kung
katiwasayan
Ang seguridad ay isa pang kritikal na isyu na ibinangon kapag pinag-aaralan ang paksa ng Internet of Things at fog/cloud computing. Ang mekanismo ng seguridad ay karaniwang nakabatay sa TLS sa HTTP, MQTT, AMQP at XMPP, o DTLS sa CoAP, at sumusuporta sa parehong mga variant ng DDS.
Nagsisimula ang TLS at DTLS sa proseso ng pagtatatag ng komunikasyon sa pagitan ng panig ng kliyente at server upang makipagpalitan ng mga sinusuportahang cipher suite at key. Ang parehong partido ay nakikipag-ayos sa mga hanay upang matiyak na ang karagdagang komunikasyon ay magaganap sa isang secure na channel. Ang pagkakaiba sa pagitan ng dalawa ay nasa maliliit na pagbabago na nagpapahintulot sa UDP-based na DTLS na gumana sa isang hindi mapagkakatiwalaang koneksyon.
Sa
Gayunpaman, ang pinakamalaking problema sa mga protocol na ito ay hindi orihinal na idinisenyo ang mga ito para sa paggamit sa IoT at hindi nilayon na gumana sa fog o ulap. Sa pamamagitan ng pakikipagkamay, nagdaragdag sila ng karagdagang trapiko sa bawat pagtatatag ng koneksyon, na nakakaubos ng mga mapagkukunan ng computing. Sa karaniwan, mayroong pagtaas ng 6,5% para sa TLS at 11% para sa DTLS sa overhead kumpara sa mga komunikasyong walang layer ng seguridad. Sa mga kapaligirang mayaman sa mapagkukunan, na karaniwang matatagpuan sa
Ano ang pipiliin? Walang malinaw na sagot. Ang MQTT at HTTP ay tila ang pinaka-promising na mga protocol dahil ang mga ito ay itinuturing na medyo mas mature at mas matatag na mga solusyon sa IoT kumpara sa iba pang mga protocol.
Mga solusyon batay sa isang pinag-isang protocol ng komunikasyon
Ang pagsasagawa ng isang solong-protocol na solusyon ay may maraming disadvantages. Halimbawa, ang isang protocol na nababagay sa isang pinaghihigpitang kapaligiran ay maaaring hindi gumana sa isang domain na may mahigpit na mga kinakailangan sa seguridad. Sa pag-iisip na ito, hinahayaan kaming itapon ang halos lahat ng posibleng single-protocol solution sa Fog-to-Cloud ecosystem sa IoT, maliban sa MQTT at REST HTTP.
REST HTTP bilang isang solong-protocol na solusyon
Mayroong magandang halimbawa kung paano nakikipag-ugnayan ang mga kahilingan at tugon ng REST HTTP sa espasyo ng IoT-to-Fog:
Tinutukoy ng header ng pamamaraang POST ang mapagkukunang babaguhin (/farm/animals) gayundin ang bersyon ng HTTP at uri ng content, na sa kasong ito ay JSON object na kumakatawan sa animal farm na pamamahalaan ng system (Dulcinea/cow) . Ang tugon mula sa server ay nagpapahiwatig na ang kahilingan ay matagumpay sa pamamagitan ng pagpapadala ng HTTPS status code 201 (ginawa ang mapagkukunan). Ang GET method ay dapat na tukuyin lamang ang hiniling na mapagkukunan sa URI (halimbawa, /farm/animals/1), na nagbabalik ng JSON na representasyon ng hayop na may ID na iyon mula sa server.
Ginagamit ang PUT method kapag kailangang i-update ang ilang partikular na resource record. Sa kasong ito, tinutukoy ng mapagkukunan ang URI para sa parameter na babaguhin at ang kasalukuyang halaga (halimbawa, nagsasaad na kasalukuyang naglalakad ang baka, /farm/animals/1? state=walking). Sa wakas, ang DELETE na paraan ay ginagamit nang pantay sa GET na paraan, ngunit tinatanggal lang ang mapagkukunan bilang resulta ng operasyon.
MQTT bilang isang solong-protocol na solusyon
Dalhin natin ang parehong matalinong bukid, ngunit sa halip na REST HTTP ginagamit namin ang protocol ng MQTT. Ang isang lokal na server na may naka-install na Mosquitto library ay kumikilos bilang isang broker. Sa halimbawang ito, ang isang simpleng computer (tinukoy bilang server ng sakahan) Raspberry Pi ay nagsisilbing MQTT client, na ipinatupad sa pamamagitan ng pag-install ng Paho MQTT library, na ganap na tugma sa Mosquitto broker.
Ang client na ito ay tumutugma sa isang IoT abstraction layer na kumakatawan sa isang device na may sensing at computing na kakayahan. Ang tagapamagitan, sa kabilang banda, ay tumutugma sa isang mas mataas na antas ng abstraction, na kumakatawan sa isang fog computing node na nailalarawan sa pamamagitan ng mas malaking kapasidad sa pagproseso at imbakan.
Sa iminungkahing smart farm scenario, ang Raspberry Pi ay kumokonekta sa accelerometer, GPS, at mga sensor ng temperatura at nag-publish ng data mula sa mga sensor na ito sa isang fog node. Tulad ng malamang na alam mo, tinatrato ng MQTT ang mga paksa bilang isang hierarchy. Ang isang publisher ng MQTT ay maaaring mag-publish ng mga mensahe sa isang partikular na hanay ng mga paksa. Sa aming kaso, tatlo sila. Para sa sensor na sumusukat sa temperatura sa isang kamalig ng hayop, pipili ang kliyente ng tema (animalfarm/shed/temperatura). Para sa mga sensor na sumusukat sa lokasyon ng GPS at paggalaw ng hayop sa pamamagitan ng accelerometer, mag-publish ang kliyente ng mga update sa (animalfarm/animal/GPS) at (animalfarm/animal/movement).
Ang impormasyong ito ay ipapasa sa broker, na maaaring pansamantalang mag-imbak nito sa isang lokal na database kung sakaling dumating ang isa pang interesadong subscriber sa ibang pagkakataon.
Bilang karagdagan sa lokal na server, na gumaganap bilang isang MQTT broker sa fog at kung saan ang Raspberry Pis, na kumikilos bilang mga kliyente ng MQTT, ay nagpapadala ng data ng sensor, maaaring mayroong isa pang MQTT broker sa antas ng ulap. Sa kasong ito, ang impormasyong ipinadala sa lokal na broker ay maaaring pansamantalang maimbak sa isang lokal na database at/o ipadala sa cloud. Ang fog MQTT broker sa sitwasyong ito ay ginagamit upang iugnay ang lahat ng data sa cloud MQTT broker. Sa ganitong arkitektura, ang isang gumagamit ng mobile application ay maaaring mag-subscribe sa parehong mga broker.
Kung mabigo ang koneksyon sa isa sa mga broker (halimbawa, cloud), ang end user ay makakatanggap ng impormasyon mula sa isa (fog). Isa itong katangian ng pinagsamang fog at cloud computing system. Bilang default, maaaring i-configure ang mobile app upang kumonekta sa MQTT broker muna, at kung mabigo iyon, upang kumonekta sa cloud MQTT broker. Ang solusyon na ito ay isa lamang sa marami sa IoT-F2C system.
Mga solusyon sa multi-protocol
Ang mga solong solusyon sa protocol ay sikat dahil sa kanilang mas madaling pagpapatupad. Ngunit malinaw na sa mga sistema ng IoT-F2C ay makatuwiran na pagsamahin ang iba't ibang mga protocol. Ang ideya ay ang iba't ibang mga protocol ay maaaring gumana sa iba't ibang antas. Kunin, halimbawa, ang tatlong abstraction: ang mga layer ng IoT, fog at cloud computing. Ang mga device sa antas ng IoT ay karaniwang itinuturing na limitado. Para sa pangkalahatang-ideya na ito, isaalang-alang natin ang mga tier ng IoT bilang ang pinaka-nalilimitahan, ang cloud ang pinakamaliit na napipigilan, at ang fog computing bilang "sa isang lugar sa gitna." Lumalabas na sa pagitan ng IoT at fog abstraction, ang mga kasalukuyang solusyon sa protocol ay kinabibilangan ng MQTT, CoAP at XMPP. Sa pagitan ng fog at cloud, sa kabilang banda, ang AMQP ay isa sa mga pangunahing protocol na ginagamit, kasama ang REST HTTP, na dahil sa flexibility nito ay ginagamit din sa pagitan ng IoT at fog layers.
Ang pangunahing problema dito ay ang interoperability ng mga protocol at ang kadalian ng paglilipat ng mga mensahe mula sa isang protocol patungo sa isa pa. Sa isip, sa hinaharap, ang arkitektura ng isang Internet of Things system na may cloud at fog resources ay magiging independyente sa protocol ng komunikasyon na ginamit at titiyakin ang mahusay na interoperability sa pagitan ng iba't ibang protocol.
Dahil hindi ito kasalukuyang nangyayari, makatuwirang pagsamahin ang mga protocol na walang makabuluhang pagkakaiba. Sa layuning ito, ang isang potensyal na solusyon ay batay sa isang kumbinasyon ng dalawang protocol na sumusunod sa parehong istilo ng arkitektura, REST HTTP at CoAP. Ang isa pang iminungkahing solusyon ay batay sa isang kumbinasyon ng dalawang protocol na nag-aalok ng komunikasyon sa pag-publish-subscribe, MQTT at AMQP. Ang paggamit ng mga katulad na konsepto (kapwa MQTT at AMQP ay gumagamit ng mga broker, ang CoAP at HTTP ay gumagamit ng REST) ββay ginagawang mas madaling ipatupad ang mga kumbinasyong ito at nangangailangan ng mas kaunting pagsisikap sa pagsasama.
Ang Figure (a) ay nagpapakita ng dalawang modelong batay sa kahilingan-tugon, HTTP at CoAP, at ang kanilang posibleng paglalagay sa isang IoT-F2C na solusyon. Dahil ang HTTP ay isa sa pinakakilala at pinagtibay na mga protocol sa mga modernong network, malamang na hindi ito ganap na mapapalitan ng iba pang mga protocol sa pagmemensahe. Kabilang sa mga node na kumakatawan sa mga makapangyarihang device na nasa pagitan ng ulap at fog, ang REST HTTP ay isang matalinong solusyon.
Sa kabilang banda, para sa mga device na may limitadong mapagkukunan ng computing na nakikipag-ugnayan sa pagitan ng mga layer ng Fog at IoT, mas mahusay na gumamit ng CoAP. Isa sa malaking bentahe ng CoAP ay ang pagiging tugma nito sa HTTP, dahil ang parehong mga protocol ay nakabatay sa mga prinsipyo ng REST.
Ipinapakita ng Figure (b) ang dalawang modelo ng komunikasyon sa pag-publish-subscribe sa parehong senaryo, kabilang ang MQTT at AMQP. Bagama't ang parehong mga protocol ay maaaring hypothetically gamitin para sa komunikasyon sa pagitan ng mga node sa bawat abstraction layer, ang kanilang posisyon ay dapat matukoy batay sa pagganap. Idinisenyo ang MQTT bilang isang magaan na protocol para sa mga device na may limitadong mapagkukunan ng computing, kaya magagamit ito para sa komunikasyon ng IoT-Fog. Ang AMQP ay mas angkop para sa mas makapangyarihang mga device, na perpektong iposisyon ito sa pagitan ng fog at cloud node. Sa halip na MQTT, ang XMPP protocol ay maaaring gamitin sa IoT dahil ito ay itinuturing na magaan. Ngunit hindi ito gaanong ginagamit sa mga ganitong sitwasyon.
Natuklasan
Malamang na ang isa sa mga protocol na tinalakay ay magiging sapat upang masakop ang lahat ng mga komunikasyon sa isang system, mula sa mga device na may limitadong mga mapagkukunan sa pag-compute hanggang sa mga cloud server. Nalaman ng pag-aaral na ang dalawang pinaka-maaasahan na opsyon na karamihang ginagamit ng mga developer ay ang MQTT at RESTful HTTP. Ang dalawang protocol na ito ay hindi lamang ang pinaka-mature at stable, ngunit kasama rin ang maraming mahusay na dokumentado at matagumpay na pagpapatupad at online na mapagkukunan.
Dahil sa katatagan at simpleng configuration nito, ang MQTT ay isang protocol na napatunayan ang mahusay na performance nito sa paglipas ng panahon kapag ginamit sa antas ng IoT na may limitadong mga device. Sa mga bahagi ng system kung saan ang limitadong komunikasyon at pagkonsumo ng baterya ay hindi isang isyu, tulad ng ilang fog domain at karamihan sa cloud computing, ang RESTful HTTP ay isang madaling pagpipilian. Dapat ding isaalang-alang ang CoAP dahil mabilis din itong umuunlad bilang pamantayan sa pagmemensahe ng IoT at malamang na maabot nito ang antas ng katatagan at maturity katulad ng MQTT at HTTP sa malapit na hinaharap. Ngunit ang pamantayan ay kasalukuyang umuunlad, na may mga panandaliang isyu sa compatibility.
Ano pa ang mababasa mo sa blog?
β
β
β
β
β
Mag-subscribe sa aming
Pinagmulan: www.habr.com