Սոֆթյուրյի և հարդեղի ոլորտներում տեխնոլոգիաների զարգացումը, նոր կապի պրոտոկոլների հայտնվելը հանգեցրել են ինտերնետի вещей (IoT) լայնացմանը։ Ակնհայտ է, որ սարքերի թիվը օր օրի աճում է, և դրանք ստեղծում են մեծ քանակությամբ տվյալներ։ Ուստի առաջանում է անհրաժեշտություն հարմար համակարգչային ճարտարապետության, որը կարող է մշակել, պահել և փոխանցել այդ տվյալները։
Ներկայումս այս նպատակների համար օգտագործվում են ամպային ծառայություններ։ Այնուամենայնիվ, ավելի ու ավելի տարածված արահետային հաշվարկի (Fog) աշխարհայացքը կարող է լրացնել ամպային լուծումները՝ ընդլայնելով և օպտիմիզացնելով IoT-ի ենթակառուցվածքը։
«Ամբեր» կարող են փակել IoT-ի շատ պահանջներ։ Օրինակ, ապահովել ծառայությունների մոնիտորինգ, արագ մշակել ցանկացած ծավալո տվյալներ, որոնք ստեղծում են սարքերը, ինչպես նաև նրանց հետազոտումը։ Մշտապես հաշվի առնելով ժամանակակից խնդիրները, Fog հաշվարկը ավելի արդյունավետ է աշխատում իրական ժամանակի խնդիրների լուծման համար։ Այն ապահովում է արագ արձագանք՝ հարցումների նկատմամբ և նվազագույն ուշացում տվյալների մշակման ժամանակ։ Այլ կերպ ասած՝ Fog-ը լրացնում է «ամբեր», ընդլայնելով դրա հնարավորությունները։
Բայց գլխավոր հարցն այլ է. ինչպես պետք է ամեն ինչ փոխգործակցի IoT-ի համատեքստում։ Ո quais կապի պրոտոկոլներ կլինեն ամենաարդյունավետները միասնական IoT-Fog-Cloud համակարգում աշխատելու համար։
Եվ այսպես, զուտ HTTP-ի գերակտիվությունը թվում է, որ IoT, Fog և Cloud համակարգերում օգտագործվում են շատ այլ լուծումներ։ Սա բացատրում է, որ IoT-ը պետք է համադրի տարբեր սարքավորումների ֆունկցիոնալ հնարավորությունները, անվտանգության, համատեղելիության և այլ պահանջների, որոնք առաջադրում են օգտատերերը։
Միայն թե որակի ճարտարապետության և կապի ստանդարտների ընդունելի միտումն առկա չէ։ Ուստի, նոր պրոտոկոլ ստեղծելը կամ գոյություն ունեցողի վերամշակումը IoT-ի կոնկրետ խնդիրների համար հանդիսանում է տեղեկատվական տեխնոլոգիաների համայնքի կարևորագույն խնդիրներից մեկը։
Ո ի՞նչ պրոտոկոլներ կիրառում են հիմա և ինչ է նրանք կարող առաջարկել։ Եկեք հասկանանք։ Բայց նախ քննարկենք էկոհամակարգի սկզբունքները, որտեղ փոխգործում են ամպերը, մշուշը և ինտերնետը։
IoT Fog-to-Cloud (F2C) ճարտարապետություն
Հավանաբար նկատել եք, թե որքան մեծ ջանքեր են ներդրվում IoT-ի, ամպերի և մշուշի պատասխանատու և համակարգված կառավարման առավելությունները ուսումնասիրելու համար։ Աստիճանաբար, եթե չես նկատել, ահա թե ինչպես են այս երեք ստանդարտավորման նախաձեռնությունները. , և .
Եթե նախկինում դիտվում էին միայն 2 մակարդակ՝ ամպեր և վերջնական սարքեր, ապա առաջարկվող ճարտարապետությունը ներկայացնում է նոր մակարդակ՝ մշուշային հաշվարկները։ Հենց այդ ժամանակ, մշուշային մակարդակը կարող է ունենալ մի քանի ենթամակարդակներ, կախված ռեսուրսների բնույթից կամ տարբեր սարքերի օգտագործման համար քաղաքականությունների խմբից, որոնք հստակեցում են այդ ենթամակարդակներում օգտագործվող սարքերի շարժը։
Ինչպես կարող է այս պարբերությունը երևալ: Ահա թե ինչպես է դիտարկվում IoT-Fog-Cloud էկոսистема: IoT սարքը տալիս է տվյալները ավելի ուժեղ սերվերներին և հաշվարկային սարքերին՝ լուծելով ցածր ուշացմամբ պահանջվող խնդիրները: Այդ նույն համակարգում ամպերն պատասխանատու են մեծ հաշվարկային ռեսուրսների կամ տվյալների պահեստավորման ծավալների պահանջվող խնդիրների լուծման համար:
Սմարթֆոնները, խելացի ժամացույցները և այլ միջոցները նույնպես կարող են լինել IoT-ի մասը: Սակայն այդպիսի սարքերը սովորաբար օգտագործում են մեծ մշակողների սեփական հաղորդակցման պրոտոկոլները: Генерированны данные интернета вещей передаются на уровень тумана через протокол REST HTTP, который обеспечивает гибкость и функциональную совместимость при создании RESTful-сервисов. Это важно в свете необходимости обеспечения обратной совместимости с существующей вычислительной инфраструктурой, работающей на локальных компьютерах, серверах или кластере серверов. Լոկալ ռեսուրսները, որոնք կոչվում են
Ամպերը աջակցում են տարբեր հաղորդակցման պրոտոկոլներին, որոնցից ամենատարածվածները AMQP և REST HTTP են: Որպեսզի HTTP- ն հանրահայտ է և ձևավորվում է ինտերնետի գլխավոր զուգապասությամբ, կարող է առաջանալ հարց. «Եւ չէ՞ օգտագործել այն IoT և ֆոգի հետ աշխատանքում»: Իհարկե, այս պրոտոկոլը ունի արտադրողականության խնդիրները: Մ մասին կխոսենք ավելի ուշ:
Ընդհանուր առմամբ, գոյություն ունի 2 հաղորդակցման պրոտոկոլի մոդել, որոնք համապատասխան են մեզ անհրաժեշտ համակարգին: Ասիմետրիկ և հրապարակային-գրանցման մոդելը: Առաջին մոդելը ավելի առաջ է ճանաչված, հատկապես սերվեր-կլիենտի կազմում: Կլիենտը հարցնում է տեղեկատվություն սերվերից, իսկ վերջինս ստանում է հարցումը, մշակելով այն, և վերադարձնում է պատասխանող հաղորդագրությունը: Այս մոդելում աշխատում են REST HTTP և CoAP պրոտոկոլները:
Մյուս մոդելը առաջացել է, քանի որ անհրաժեշտություն է հայտնում ապահովել ասինքրոն, բաշխված, թույլ հաղորդակցում տվյալներ ստեղծող աղբյուրների և այդ տվյալների ստացողերի միջև:
Մոդելը ենթադրում է երեք մասնակցի. հրատարակիչ (տվյալների աղբյուր), շուկան (դիսպետչեր) և գրանցող (ստացող): Այստեղ կլիենտը, ով հանդես է գալիս որպես գրանցող, չի պարտավոր աջակցել տեղեկատվություն սերվերից: Չնայած հարցումների ուղարկմանը, նա ռեգիստրում է որոշակի դեպքերի վրա համակարգի միջոցով՝ շուկայի միջոցով, որը պատասխանատու է բոլոր ներմուծված հաղորդագրությունների ֆիլտրացման և դրանց ուղերձման համար հրատարակիչների և գրանցողների միջև: Իսկ հրատարակիչը, երբ տեղի է ունենում դեպք, որը վերաբերում է որոշակի թեմայի, հրապարակում է այն շուկային, որը ուղարկում է գրանցողին տվյալներ պահանջվող թեմայով:
Իր էության մեջ, այս ճարտարապետությունը հիմնված է իրադարձությունների վրա: Եվ այսպիսի փոխադարձության մոդելը հետաքրքիր է IoT, ամպային և մառաների կիրառությունների համար՝ իր կարողության շնորհիվ ապահովելու ընդլայնողականություն և հեշտացնել կապը տարբեր սարքերի միջև, աջակցելով դինամիկ «բազմաթիվ դիմաց բազմաթիվ» և ասինխրոն կապերին: Առավել հայտնի ստանդարտացված հաղորդակցման արձանագրություններից, որոնք օգտագործում են «հրապարակում-գրանցում» մոդելը, կարելի է նշել MQTT, AMQP և DDS:
Очевидно, что у модели «публикация-подписка» есть масса преимуществ:
- Հրապարակողներին և գրանցիներ պետք չէ իմանալ միմյանց գոյության մասին:
- Մեկ գրանցող կարող է ստանալ տեղեկություններ բազմաթիվ տարբեր հրատարակություններից, իսկ մեկ հրապարակողը կարող է ուղարկել տվյալներ բազմաթիվ տարբեր գրանցողի (մոդել «բազմաթիվ դիմաց բազմաթիվ»);
- Հրապարակողն ու գրանցողն չեն obligado լինել միաժամանակ ակտիվ տվյալներ փոխանակելու համար, քանի որ բրոկեր (ինչպես հերթերի համակարգ) կարող է պահել հաղորդագրություններ այն հաճախորդների համար, որոնք այս պահին չեն միացված ցանցին.
Սակայն «հարց-պատասխան» մոդելը նույնպես ունի իր ուժեղ կողմերը: Այն դեպքերում, երբ սերվերային կողմից միանգամից բազմաթիվ հաճախորդների հարցումների մշակման հնարավորությունները խնդիր չեն, իմաստ ունի օգտագործել արդեն ստուգված վստահոտ լուծումներ:
Կան նաև արձանագրություններ, որոնք մ podpor են երկու մոդելները: Օրինակ, XMPP և HTTP 2.0, որոնք աջակցում են «server push» տարբերակին: IETF-ն նույնպես թողարկել է CoAP: Հաղորդակցման խնդիրը լուծելու փորձերի ընթացքում ստեղծվել են մի քանի այլ լուծումներ, ինչպես WebSockets արձանագրությունը կամ HTTP-ի օգտագործումը QUIC-ի (Quick UDP Internet Connections) միջոցով:
WebSockets-ի պարագայում, չնայած այն օգտագործվում է տվյալների ռեալ ժամանակի փոխանցման համար սերվերից դեպի վեբ-հաճախորդ և ապահովում է շարունակական միացումներ երկկողմ կապով, այն նախատեսված չէ սահմանափակ հաշվարկային ռեսուրսներ ունեցող սարքերի համար: QUIC-ը նույնպես արժանի է ուշադրության, քանի որ նոր փոխադրող արձանագրությունը բազմաթիվ նոր հնարավորություններ է առաջարկում: Բայց քանի որ QUIC-ը դեռ չի ստանդարտացվել, վաղ է կանխատեսել դրա հնարավոր կիրառման և ազդեցության մասին IoT լուծումների նկատմամբ: Հետևաբար WebSockets և QUIC-ն մենք հետ ենք թողնում ապագայի նպատակով, բայց ավելի մանրամասն ուսումնասիրենք դեռ չենք ցանկանում:
Ո kdo է աշխարհում ամեն Sweetie: համեմատում ենք արձանագրությունները
Այժմ քննարկենք արձանագրությունների ուժեղ և թույլ կողմերը: Նախապես նշենք, որ չկա միակ ոչ դրսևորող լիդեր: Որոշ առավելություններ/աղջիկություն կա յուրաքանչյուր արձանագրության:
Ժամանակի արձագանք
Մի քանի կարևոր բնութագրերից մեկը կապի պրոտոկոլների, հատկապես իրերի ինտերնետի համատեքստում, պատասխանման ժամանակն է։ Բայց գոյություն ունեցող պրոտոկոլների մեջ չկա աներկբա հաղթող, որն демонстрирует минимальные задержки տարբեր պայմաններում։ Այնուամենայնիվ, կան բազմաթիվ հետազոտություններ և համեմատականներ պրոտոկոլների հնարավորությունների մասին։
Օրինակ, HTTP և MQTT-ի արդյունավետության համեմատությունը ցույց է տվել, որ MQTT-ի հարցումների պատասխանման ժամանակը ավելի ցածր է, քան HTTP-ի։ Իսկ երբ MQTT-ի և CoAP-ի փոխանցման ժամանակում (RTT) պարզվել է, որ CoAP-ի միջին RTT 20%-ով ցածր է, քան MQTT-ի։
Այլ MQTT և CoAP պրոտոկոլների RTT-ը իրականացվել է երկու սցենարներում՝ տեղական ցանցում և IoT ցանցում։ Հետազոտությունները ցույց են տվել, որ IoT ցանցում միջին RTT-ն 2-3 անգամ բարձր է։ QoS0 ունեցող MQTT-ն ցածր արդյունք է ցուցաբերել, համեմատած CoAP-ի հետ, մինչդեռ QoS1 ունեցող MQTT-ն ցույց է տվել ավելի բարձր RTT, շնորհիվ ACK-ի կիրառման և տրանսպորտային մակարդակներում։ QoS-ի տարբեր մակարդակների համար խնդիրը ցանցում առանց ծանրաբեռնման MQTT-ի ուշացումը կազմել է毫 секунд, իսկ CoAP-ի համար — հարյուրավոր միկրոսեկունդներ։ Բայց պետք է հիշել, որ անհարմար ցանցերում MQTT, որն աշխատում է TCP-ի վրա, ցույց կտա միանգամայն այլ արդյունք։
AMQP և MQTT պրոտոկոլների պատասխանման ժամանակները բեռնաթափման ուսումնասիրությամբ ցույց է տվել, որ փոքր բեռների դեպքում ուշացումը գրեթե նույնն է։ Բայց մեծ ծավալներում տվյալների փոխանցման ժամանակ MQTT-ն ցույց է տվել ավելի ցածր պատասխանման ժամանակ։ Ավելի մեկ CoAP-ն համեմատվել է HTTP-ով մեքենաների միջև հաղորդակցման սցենարում, որոնք տեղակայված են տրանսպորտային միջոցների վրա և պաշտպանված են գազի սենսորներով, եղանակի սենսորներով, դիրքում (GPS) և շարժական ցանցի ինտերֆեյսով (GPRS)։ CoAP հաղորդագրության փոխանցման համար անհրաժեշտ ժամանակը մոբիլային ցանցով գրեթե երեք անգամ ավելի կարճ է, քան HTTP հաղորդագրությունների ժամանակը։
Հետազոտություններ են անցկացվել, որտեղ համեմատվել են ոչ երկու, այլ երեք պրոտոկոլներ։ Օրինակ, IoT պրոտոկոլների MQTT, DDS և CoAP արդյունավետությունը բժշկական կիրառման սցենարում՝ ցանցային էմուլյատորի օգտագործմամբ։ DDS-ն գերազանցել է MQTT-ն՝ հասնելով փորձած հեռախոսամուտում տարբեր վատ ցանցային պայմաններում։ UDP վրա հիմնված CoAP-ն լավ է աշխատել արագ պատասխան պահանջող ծրագրերի համար, սակայն UDP-ի վրա հիմնված լինելու պատճառով կատարվել է զգալի անակնկալ փաթեթների կորուստ։
Չափաբաժինը
MQTT և CoAP-ի արդյունավետության համեմատությունը անցկացնելով ընդհանուր տվյալների քանակի հաշվելով, որոնք փոխանցվում են մեկ հաղորդագրության մեջ։ CoAP-ն ցույց է տվել ավելի ցածր անցանկալիություն, քան MQTT-ն՝ փոքր հաղորդագրություններ փոխանցելիս։ Բայց պրոտոկոլների արդյունավետության համեմատության ժամանակ, օգտակար տեղեկատվական բիտերի քանակի և ընդհանուր փոխանցված բիտերի քանակի միջև հարաբերակցությունը CoAP-ն ավելի արդյունավետ է եղել։
Երբ MQTT, DDS (TCP-с транспортным протоколом) և CoAP-ի Քաղաքային տեռաշենքում դիտարկվել է, որ CoAP, սովորաբար, ցույց է տալիս համեմատաբար ցածր գոտի, որը չի կառաջացնումեղծվել, երբ աճում է ցանցային փաթեթների կորստի կամ վայրենի ներսողության տարածման, անվանական MQTT և DDS, երբ վերոհիշյալ սցենարներում դիտարկվել է մակարդակի օգտագործման աճ։ մեկ այլ սցենարում բաղնիքում ամբողջացնել ապարատներ, հետևաբար տվյալները փոխանցում են համաժամանակ, որն է սովորական դեպք IoT միջավայրերում։ Արդյունքները ցույց են տալիս, որ ավելի բարձրโหลดերի համար լավ օգտագործեք CoAP։
Փոքր բեռներով CoAP-ը օգտագործում էր նվազագույն առնվազնություն, որը հաջորդվում էր MQTT և REST HTTP-ին։ Բայց, երբ օգտակար բեռների չափը մեծանում էր, լավագույն արդյունքները ստացել էին REST HTTP։
Էներգիայի սպառում
Էներգիայի սպարման հարցը միշտ կարևոր նշանակություն ունի, իսկ IoT համակարգում՝ հատկապես։ Եթե էլեկտրաէներգիայի սպառումը MQTT-ի և HTTP-ի միջև, ապա HTTP «աջում է» ավելի շատ։ Իսկ CoAP ավելի MQTT-ի նկատմամբ, թույլ տալով ցանցը կառավարել։ Սակայն պարզ սցենարներում MQTT ավելի լավ է տեղեկատվության փոխանակման համար IoT ցանցերում, հատկապես, եթե ոչ փակող հզորության սահմանափակություն չկա։
փորձ, որի ընթացքում համեմատվել են AMQP-ի և MQTT-ի հնարավորությունները շարժական կամ անհավասար վիրտուալ ցանցում, ցույց է տվել, որ AMQP առաջարկում է ավելի շատ հնարավորություններ հանրայինությունը սիրահետելու, մինչդեռ MQTT-ն ավելի էներգիաէքֆիկ է։
Ապահովություն
Ապահովությունը մեկ այլ կարևոր հարց է, որը ծագում է IoT և մառախուղային/ամպային հաշվարկների թեմայի ուսումնասիրության ժամանակ։ Ապահովության մեխանիզմը սովորաբար հիմնված է TLS-ի վրա HTTP-ում, MQTT-ում, AMQP-ում և XMPP-ում, կամ DTLS-ում CoAP-ում, ինչպես նաև աջակցող երկուսի DDS-ում։
TLS և DTLS սկսվում են շփման գործընթացով հաճախորդային և սերվերի կողմերի միջև, որի նպատակն է փոխանակել աջակցվող ծածկագրերի և բանալիների հավաքածուները։ Երկու կողմերը համաձայվել են հավաքածուները, որպեսզի երաշխավորվի, որ հետագա հաղորդակցությունները տեղի ունենան ապահովված հաղորդման շմարդակներից։ Տարբերությունը նրանց միջև հենց փոքր փոփոխություններում է, որոնք DTLS-ին թույլ են տալիս աշխատել նրանդիտակի միությունից։
Երբ մի քանի տարբեր TLS և DTLS իրականացումների վրա ցույց է տվել, որ TLS-ը ավելի լավ է աշխատում համարում՛։ DTLS-ի վրա հարձակումներն ավելի հաջողվել էին՝ նրա սխալներին նայելով։
Այնուամենայնիվ, այս պրոտոկոլների ամենամեծ խնդիրն այն է, որ դրանք սկզբում նախատեսված չէին ԻոՏ-ում կիրառության համար և չեն ենթադրում աշխատանքի եղանակներում կամ ամպում: Հաստատված փոխանակումով (handshaking) նրանք յուրաքանչյուր կապի հաստատման հետ ավելացնում են լրացուցիչ երթևեկություն, ինչը սպառում է հաշվային ռեսուրսները: Ըստ խմելու տվյալների, TLS-ի համար վերելքը միջին 6.5% է, իսկ DTLS-ի համար՝ 11%, երբ համեմատվում է անվտանգության մակարդակ չընկած կապի հետ: Ռեսուրսներով հարուստ միջավայրերում, որոնք սովորաբար գտնվում են թե մակարդակում, սա խնդիր չէ, բայց IoT-ի և ծուղակի մակարդակի միջև կապի ժամանակ դա կարևոր սահմանափակում է:
Ինչպես ընտրել? Հստակ պատասխան չկա: MQTT-ն և HTTP-ն թվացող ամենահուսադրող պրոտոկոլներն են, քանի որ համեմատաբար ավելի հաշտված և ավելի կայուն լուծումներից են ԻոՏ-ի համար, քան մյուս պրոտոկոլները:
Մեկ საოդակցման պրոտոկոլի հիմնադրույթներ
Մեկ պրոտոկոլի լուծման կիրառման պրակտիկան ունի բազմաթիվ նվազականություններ: Օրինակ, պրոտոկոլը, որը բավարարում է սահմանափակ միջավայրին, կարող է չաշխատել դոմենում, որն ունի խիստ անվտանգային պահանջներ: Այս գիտակցությամբ, մեզ մնում է մերժել գրեթե բոլոր հնարավոր լուծումները, որոնք հիմնված են մեկ պրոտոկոնի վրա IoT-ի Fog-to-Cloud էկոհամակարգում, բացի MQTT-ից և REST HTTP-ից:
REST HTTP որպես մեկ պրոտոկոլի լուծում
Որպես ԻոՏ-էջախաղի փոխադարձության լավ օրինակ կարելի է նշել REST HTTP-ի հարցումների և պատասխանների համագործակցությունը: ։ Կենդանիները զինված են կրելի սենսորներով (IoT-հաճախորդ, C) և կառավարելուց հետո ամպային վերացույցային հենակետով (Fog-սերվեր, S):
POST մեթոդի հերթում մատնանշում է փոփոխման համար միջոցը (\/farm\/animals), ավելին՝ HTTP-ի տարբերակը և պարունակության տեսակ, որը այս դեպքում JSON օբյեկտն է, որն ներկայացնում է կենդանակենդանիների ֆերման, որն պետք է կառավարի համակարգը (Դուլսինեա\/պանիր): Սերվերի պատասխանը գրեթե հաստատում է, որ հարցումը հաջողությամբ իրականացվել է, վերադառնալով HTTPS 201 (resource created) վիճակը: GET մեթոդը պետք է նշանակում միայն խնդրված միջոցը URI-ում (օրինակ, \/farm\/animals\/1), որը վերադառնում է JSON-վերծանում կենդանու տվյալ մշակողի հետ այդ նույն դիրքորոշմամբ:
PUT մեթոդը օգտագործվում է, երբ անհրաժեշտ է թարմացնել որևէ հատուկ ռեսուրսի ծանոթությունը: Այս դեպքում ռեսուրսում նշվում է URI-ը փոփոխման ենթակա պարամետրի և ներկա արժեքի համար (օրինակ, որը նշանակում է, որ կովի ներկայիս վիճակը քայլելն է, \/farm\/animals\/1?state=walking): Եվ վերջապես, DELETE մեթոդը նույն կերպ կիրառվում է GET մեթոդի համար, բայց պարզապես հեռացնում է ռեսուրսը գործողության արդյունքում:
MQTT որպես մեկ պրոտոկոլի լուծում
Նայենք նույն խելացի ֆերման, բայց փոխարենը REST HTTP օգտագործենք MQTT պրոտոկոլը։ Բնակային սերվերը, որը Mosquitto գրադարանը տեղադրված է, հանդիսանում է բրոքեր։ Այս օրինակով պարզ կոմպյուտեր (նշվում է ֆերմայի սերվեր) Raspberry Pi-ն ծառայել է MQTT հաճախորդի, որը իրականացված է MQTT Paho գրադարանի տեղադրման միջոցով, որը լիովին համատեղելի է Mosquitto բրոքերի հետ։
Այս հաճախորդը համապատասխանում է IoT-ի抽象 স্তիզ, որը ներկայացնում է սարքավորում, որն ունի հայտնաբերման ու հաշվարկման հնարավորություններ։ Միջնորդը, մյուս կողմից, համապատասխան է ավելի բարձր抽象 স্তիզ, որը ներկայացնում է մառախուղի հաշվարկային հանգույց, որով բնութագրվում է ավելի մեծ էներգիայի հնարավորություններով տվյալների մշակման ու պահեստավորման方面։
Հոգևոր խելացի ֆերմայի առաջարկվող սցենարում Raspberry Pi-ն միանում է արագաչափին, GPS-ին և ջերմաստիճանի սենսորներին և հրապարակում է այդ սենսորներից ստացված տվյալները մառախողովի հանգույցում։ Ինչպես, համոզված եմ, որ գիտեք, MQTT-ն դիտարկում է թեմաները որպես հիերարխիա։ Մի MQTT արտահամանողը կարող է հաղորդագրություններ հրապարակել որոշակի թեմաների հավաքածուում։ Մեր դեպքում դրանք երեքն են։ Պահպանակի ջերմաստիճանը չափող սենսորի համար հաճախորդը ընտրում է թեման (animalfarm/shed/temperature)։ GPS-ի դիրքը և կենդանիների շարժումը չափող սենսորների համար հաճախորդը հրապարակում է թարմացումներ (animalfarm/animal/GPS) և (animalfarm/animal/movement)।
Այս տեղեկությունը կուղարկվի բրոքերին, որը կարող է ժամանակավորապես պահել այն տեղական տվյալների բազայում մինչ այլ հետաքրքրված բաժանորդ կհայտնվի։
Բնակային սերվերից բացի, որը կատարում է MQTT բրոքերի դերը մառախուղում և որ Raspberry Pi-ն, որը ծառայել է MQTT հաճախորդների, ի՞նչ տեղեկություններ է հաղորդում սենսորներից, մառախողովի մակարդակում կարող է լինել ևս մեկ MQTT բրոքեր։ Այս դեպքում, բնակային բրոքերին փոխանցվող տեղեկությունը կարող է ժամանակավորապես պահպանվել տեղական տվյալների բազայում և/կամ ուղարկվել մառախուղ։ Մառախուղային MQTT բրոքերը այս իրավիճակում օգտագործվում է բոլոր տվյալները կապելու համար մառախուղային MQTT բրոքերին։ Այսպիսի ճարտարապետությամբ, շարժական ծրագիրը կարող է բաժանորդագրվել երկու բրոքերներին։
Եթե մի բրոքերի (օրինակ, մառախուղի) հետ կապը կորցվում է, վերջնական օգտատերը տեղեկությունները կստանա մյուսից (մառախուղից)։ Սա տիպիկ առանձնահատկությունն է մասնակի մառախուղի և մառախողի համակարգերի միջև։ Ավելի զուտ հավելվածը կարող է ըստ իսկության նախնական կապն ապահովել մառախուղի MQTT բրոքերի հետ և մանակապարտի դեպքում՝ կապվել մառախողի MQTT բրոքերի հետ։ Այս լուծումը միայն թվարկվել ամենաբազմաթիվներից մեկ է IoT-F2C համակարգերում։
Բազմածրախոսական լուծումներ
Կրկնակի արձանագրություններով հիմնված լուծումները լայն տարածում են գտել իրենց ավելի հեշտ իրականացանելիության պատճառով: Սակայն ակնհայտ է, որ IoT-F2C համակարգերում բազմաառաջարկված արձանագրությունների համադրությունը իմաստ ունի: Հենց այդ իսկ պատճառով, տարբեր մակարդակներում կարող են գործել տարբեր արձանագրություններ: Օրինակ, կարող ենք վերցնել երեք աբստրակցիաներ. IoT, մշուշային և ամպային համակարգչում։ IoT մակարդակի սարքերը սովորաբար համարվում են սահմանափակ: Այս ակնարկի համար մի՛ դիտարկենք IoT մակարդակները որպես առավել սահմանափակ, ամպային՝ որպես նվազագույն սահմանափակ և մշուշային համակարգիչ՝ որպես «որտեղ որ չափավոր»: Նմանապես, մենք ստանում ենք, որ IoT և մշուշային աբստրակցիաների միջև գործող արձանագրությունների լուծումները ներառում են MQTT, CoAP և XMPP: Մշուշի և ամպի միջև, մյուս կողմից, AMQP-ն մեկն է հիմնական օգտագործվող արձանագրություններից, որը միասին REST HTTP-ի հետ նույնպես օգտագործվում է IoT և մշուշային շերտերի միջև:
Այս դեպքում հիմնական խնդիրը կայանում է արձանագրությունների գործառնական համատեղելիության և հաղորդագրությունների փոխարկման հեշտության հարցում։ Վերջնականում, ապագայում IoT համակարգի արխիտեկտուրան, որը կավարտվի ամպային և մշուշային ռեսուրսներով, պետք է լինի անկախ օգտագործվող կապի արձանագրությունից ու ապահովի տարբեր արձանագրությունների բարենպատակ փոխազդեցություն:
Քանի որ այս պահին դա այդպես չէ, իմաստ ունի համադրել արձանագրությունները, որոնք չունեն էական տարբերություններ։ Այս նպատակով մեկ հնարավոր լուծումը հիմնված է երկու արձանագրությունների համադրության վրա, որոնք հետևում են նույն արխիտեկտուրական ոճին, REST HTTP և CoAP։ Մյուս առաջարկվող լուծումը հիմնված է երկու արձանագրությունների համադրության վրա, որոնք առաջարկում են «հրապարակում-բաժանորդագրություն» մոդել, MQTT և AMQP։ Աճող մոտեցումների (ինչպես MQTT-ն, այնպես էլ AMQP-ն օգտագործում են բրոքերի, CoAP-ը և HTTP-ն օգտագործում են REST) կիրառումը հեշտացնում է այդ համադրությունների իրականացումը և պահանջում է ավելի քիչ ջանքեր ինտեգրման համար:
Նկար (ա) ցույց է տալիս երկու մոդելներ, որոնք հիմնված են հարց-պատասխան ձևաչափի վրա, HTTP և CoAP, և դրանց հնարավոր տեղակայումը IoT-F2C լուծման մեջ: Քանի որ HTTP-ն ներկայիս ցանցերում ամենահայտնի և հարմարեցված արձանագրություններից մեկն է, անպայման չի լինի, որ այն ամբողջությամբ փոխարինվի այլ հաղորդակցական արձանագրություններով: Ամպի և մշուշի միջև գործող ուժեղ սարքերի տուփերի հիմնականում REST HTTP-ն է համեմատաբար ողջամիտ լուծում:
Մյուս կողմից, սահմանափակ հաշվիչ ռեսուրսներով սարքերի համար, որոնք կապվում են մշուշի և IoT մակարդակների միջև, ավելի արդյունավետ կլինի օգտագործել CoAP: CoAP-ի մեծ առավելություններից մեկը իսկապես նրա համատեղելիությունն է HTTP-ի հետ, քանի որ երկուսն էլ արձանագրությունները հիմնված են REST-ի սկզբունքների վրա:
Նկար (բ)-ում ցուցադրված են «հրապարակում-գրանցում» երկու մոդելներ մեկ սցենարում, ներառյալ MQTT և AMQP։ Թեև հիպոթետիկորեն երկու արձանագրությունները կարող են օգտագործվել վայրկյան-ն ձևավորելու միջեւ հաղորդակցության կապ, նրանց դիրքը պետք է որոշվի կատարողականության հիման վրա։ MQTT-ն մշակվել է որպես պարզեցված արձանագիր մասնակցող սարքերի համար, ուստի այն կարող է օգտագործվել IoT-ի և մառախուղի միջև հաղորդակցության համար։ AMQP-ն ավելի բարձր կարողությունների սարքերի համար է ավելի հարմար, որոնք կարող են տեղավորել նրան մառախողովուրդների և ամպերի միջև։ MQTT-ի փոխարեն IoT-ում կարելի է օգտագործել XMPP արձանագիրը, քանի որ այն համարվում է թեթև։ Բայց այն բոլորովին չի օգտագործվում նման սցենարներում։
Արդուկները
Մало вероятно, что одного из рассмотренных протоколов будет достаточно для охвата всей связи в системе, начиная с устройств с ограниченными вычислительными ресурсами и заканчивая облачными серверами. Исследование показало, что два наиболее перспективных варианта, которые чаще используют разработчики, это MQTT и RESTful HTTP. Эти два протокола являются не только наиболее зрелыми и стабильными, но также включают в себя множество хорошо документированных и успешных реализаций и онлайн-ресурсов.
Ուրախությունով իմ անկեղծությունը պաշտպանելու համար, MQTT-ն արձանագիր է, որը ժամանակի ընթացքում ապացուցել է իր գերազանց կատարողականությունը IoT-ի սահմանափակ սարքերի մակարդակում։ Համակարգի այն հատվածներում, որտեղ սահմանափակ հաղորդակցությունը և մարտկոցների սպառումը խնդիր չեն, օրինակ, որոշ մառախողովրդական ոլորտներում և մեծ մասամբ ամպային համակարգերում, RESTful HTTP-ն պարզ ընտրություն է։ CoAP-ն նույնպես պետք է ուշադրության կենտրոնում լինի, քանի որ այն նույնպես արագ զարգանում է որպես IoT հաղորդակցման ստանդարտ, և շատ հնարավոր է, որ մոտ ապագայում այն կհասնի MQTT և HTTP-ի հետ համեմատելի կայունության և հասունության մակարդակին։ Սակայն ստանդարտը ներկայումս զարգանում է, ինչը կապված է կարճաժամկետ համատեղելիության խնդիրներով։
Ի՞նչ այլ օգտակար բաներ կարելի է կարդալ բլոգում
→
→
→
→
→
Համացանցում ավելացնել մեր -թողարկմանը, որպեսզի չխուսափեք նոր հոդվածից։ Գրում ենք ոչ ավելի քան երկու անգամ շաբաթական և միայն անհրաժեշտ հարցերով։
Ընտանիք: habr.com
