Ծրագրային ապահովման և սարքավորումների ոլորտում տեխնոլոգիաների զարգացումը, հաղորդակցության նոր արձանագրությունների ի հայտ գալը հանգեցրել են Իրերի ինտերնետի (IoT) ընդլայնմանը: Սարքավորումների թիվը օրեցօր ավելանում է, և դրանք հսկայական քանակությամբ տվյալներ են արտադրում։ Հետևաբար, անհրաժեշտ է հարմար համակարգի ճարտարապետություն, որն ունակ է մշակել, պահել և փոխանցել այս տվյալները:
Այժմ այդ նպատակների համար օգտագործվում են ամպային ծառայություններ: Այնուամենայնիվ, մառախուղի հաշվարկման ավելի ու ավելի տարածված պարադիգմը (Fog) կարող է լրացնել ամպային լուծումները՝ մասշտաբավորելով և օպտիմալացնելով IoT ենթակառուցվածքը:
Ամպերն ի վիճակի են ծածկելու IoT հարցումների մեծ մասը: Օրինակ՝ մատուցել ծառայությունների մոնիտորինգ, սարքերի կողմից ստեղծված ցանկացած քանակի տվյալների արագ մշակում, ինչպես նաև դրանց վիզուալիզացիա։ Մառախուղի հաշվարկն ավելի արդյունավետ է իրական ժամանակում խնդիրներ լուծելիս: Նրանք արագ արձագանքում են հարցումներին և տվյալների մշակման նվազագույն ուշացում: Այսինքն՝ Մառախուղը լրացնում է «ամպերը» և ընդլայնում իր հնարավորությունները։
Այնուամենայնիվ, հիմնական հարցն այլ է՝ ինչպե՞ս պետք է այս ամենը փոխազդի IoT-ի համատեքստում: Հաղորդակցման ո՞ր արձանագրություններն առավել արդյունավետ կլինեն համակցված IoT-Fog-Cloud համակարգում աշխատելիս:
Չնայած HTTP-ի ակնհայտ գերակայությանը, կան մեծ թվով այլ լուծումներ, որոնք օգտագործվում են IoT, Fog և Cloud համակարգերում: Դա պայմանավորված է նրանով, որ IoT-ը պետք է համատեղի սարքի մի շարք սենսորների ֆունկցիոնալությունը օգտատերերի անվտանգության, համատեղելիության և այլ պահանջների հետ:
Բայց տեղեկատու ճարտարապետության և հաղորդակցության ստանդարտի մասին պարզապես չկա մեկ գաղափար: Հետևաբար, IoT-ի հատուկ առաջադրանքների համար նոր արձանագրություն ստեղծելը կամ գոյություն ունեցողը փոփոխելը ՏՏ համայնքի առջև ծառացած ամենակարևոր խնդիրներից է:
Ի՞նչ արձանագրություններ են ներկայումս օգտագործվում և ի՞նչ կարող են դրանք առաջարկել: Եկեք պարզենք այն: Բայց նախ, եկեք քննարկենք էկոհամակարգի սկզբունքները, որոնցում փոխազդում են ամպերը, մառախուղը և իրերի ինտերնետը:
IoT Fog-to-Cloud (F2C) ճարտարապետություն
Դուք հավանաբար նկատել եք, թե որքան ջանք է գործադրվում IoT-ի, ամպի և մառախուղի խելացի և համակարգված կառավարման հետ կապված առավելություններն ու առավելությունները ուսումնասիրելու համար: Եթե ոչ, ապա ահա ստանդարտացման երեք նախաձեռնություններ. , и .
Եթե նախկինում դիտարկվում էր միայն 2 մակարդակ՝ ամպեր և վերջնական սարքեր, ապա առաջարկվող ճարտարապետությունը ներկայացնում է նոր մակարդակ՝ մառախուղային հաշվարկ: Այս դեպքում մառախուղի մակարդակը կարելի է բաժանել մի քանի ենթամակարդակների՝ կախված ռեսուրսների առանձնահատկություններից կամ քաղաքականության մի շարքից, որոնք որոշում են այս ենթամակարդակներում տարբեր սարքերի օգտագործումը:
Ինչպիսի՞ն կարող է լինել այս աբստրակցիան: Ահա տիպիկ IoT-Fog-Cloud էկոհամակարգը: IoT սարքերը տվյալներ են ուղարկում ավելի արագ սերվերներ և հաշվողական սարքեր՝ լուծելու այն խնդիրները, որոնք պահանջում են ցածր ուշացում: Նույն համակարգում ամպերը պատասխանատու են այնպիսի խնդիրների լուծման համար, որոնք պահանջում են մեծ քանակությամբ հաշվողական ռեսուրսներ կամ տվյալների պահպանման տարածք:
Սմարթֆոնները, խելացի ժամացույցները և այլ գաջեթները նույնպես կարող են լինել IoT-ի մաս: Բայց նման սարքերը, որպես կանոն, օգտագործում են խոշոր ծրագրավորողների սեփական կապի արձանագրություններ: Ստեղծված IoT տվյալները փոխանցվում են մառախուղի շերտ REST HTTP արձանագրության միջոցով, որն ապահովում է ճկունություն և փոխգործունակություն RESTful ծառայություններ ստեղծելիս։ Սա կարևոր է տեղական համակարգիչների, սերվերների կամ սերվերների կլաստերի վրա աշխատող հաշվողական ենթակառուցվածքի հետ հետընթաց համատեղելիության ապահովման անհրաժեշտության լույսի ներքո: Տեղական ռեսուրսները, որոնք կոչվում են «մառախուղի հանգույցներ», զտում են ստացված տվյալները և մշակում դրանք տեղական կամ ուղարկում են ամպ՝ հետագա հաշվարկների համար:
Ամպերն աջակցում են տարբեր հաղորդակցման արձանագրություններին, որոնցից ամենատարածվածն են AMQP-ն և REST HTTP-ը: Քանի որ HTTP-ն լավ հայտնի է և հարմարեցված է ինտերնետի համար, կարող է հարց առաջանալ. «չպետք է այն օգտագործենք IoT-ի և մառախուղի հետ աշխատելու համար»: Այնուամենայնիվ, այս արձանագրությունն ունի կատարողականի հետ կապված խնդիրներ: Այս մասին ավելի ուշ:
Ընդհանուր առմամբ, մեզ անհրաժեշտ համակարգին հարմար հաղորդակցման արձանագրությունների 2 մոդել կա։ Դրանք են՝ հարցում-պատասխան և հրապարակում-բաժանորդագրվել։ Առաջին մոդելն ավելի լայն ճանաչում ունի, հատկապես սերվեր-հաճախորդ ճարտարապետության մեջ: Հաճախորդը սերվերից պահանջում է տեղեկատվություն, իսկ սերվերը ստանում է հարցումը, մշակում այն և վերադարձնում պատասխան հաղորդագրություն: REST HTTP և CoAP արձանագրությունները գործում են այս մոդելի վրա:
Երկրորդ մոդելն առաջացել է տվյալներ ստեղծող աղբյուրների և այդ տվյալների ստացողների միջև ասինխրոն, բաշխված, ազատ միացում ապահովելու անհրաժեշտությունից:
Մոդելը ենթադրում է երեք մասնակից՝ հրատարակիչ (տվյալների աղբյուր), բրոքեր (դիսպետչեր) և բաժանորդ (ստացող): Այստեղ հաճախորդը, որը հանդես է գալիս որպես բաժանորդ, պարտավոր չէ սերվերից տեղեկատվություն պահանջել: Հարցումներ ուղարկելու փոխարեն այն բաժանորդագրվում է համակարգի որոշակի իրադարձությունների բրոքերի միջոցով, որը պատասխանատու է բոլոր մուտքային հաղորդագրությունները զտելու և դրանք հրատարակիչների և բաժանորդների միջև ուղղորդելու համար: Իսկ հրատարակիչը, երբ ինչ-որ թեմայի հետ կապված իրադարձություն է տեղի ունենում, այն հրապարակում է բրոքերին, որն էլ բաժանորդին ուղարկում է պահանջվող թեմայի վերաբերյալ տվյալներ։
Ըստ էության, այս ճարտարապետությունը հիմնված է իրադարձությունների վրա: Եվ այս փոխազդեցության մոդելը հետաքրքիր է IoT-ի, ամպի, մառախուղի հավելվածների համար, քանի որ իր ունակությամբ ապահովում է մասշտաբայնություն և պարզեցնում է փոխկապակցումը տարբեր սարքերի միջև, աջակցում է դինամիկ շատ-շատ հաղորդակցությանը և ասինխրոն հաղորդակցությանը: Ամենահայտնի ստանդարտացված հաղորդագրությունների արձանագրություններից մի քանիսը, որոնք օգտագործում են հրապարակման-բաժանորդագրման մոդելը, ներառում են MQTT, AMQP և DDS:
Ակնհայտ է, որ հրապարակել-բաժանորդագրվել մոդելը շատ առավելություններ ունի.
- Հրատարակիչները և բաժանորդները կարիք չունեն իմանալու միմյանց գոյության մասին.
- Մեկ բաժանորդը կարող է տեղեկատվություն ստանալ բազմաթիվ տարբեր հրապարակումներից, և մեկ հրատարակիչը կարող է տվյալներ ուղարկել բազմաթիվ տարբեր բաժանորդների (շատ-շատերի սկզբունքը);
- Հրատարակիչը և բաժանորդը պարտադիր չէ, որ միաժամանակ ակտիվ լինեն հաղորդակցվելու համար, քանի որ բրոքերը (աշխատելով որպես հերթագրման համակարգ) կկարողանա հաղորդագրություն պահել այն հաճախորդների համար, որոնք ներկայումս միացված չեն ցանցին:
Այնուամենայնիվ, հարցում-պատասխան մոդելն ունի նաև իր ուժեղ կողմերը: Այն դեպքերում, երբ սերվերի կողմից հաճախորդի բազմաթիվ հարցումները լուծելու կարողությունը խնդիր չէ, իմաստ ունի օգտագործել ապացուցված, հուսալի լուծումներ:
Կան նաև արձանագրություններ, որոնք աջակցում են երկու մոդելներին: Օրինակ՝ XMPP և HTTP 2.0, որոնք աջակցում են «server push» տարբերակը։ IETF-ը նաև հրապարակել է CoAP-ը: Հաղորդագրությունների խնդիրը լուծելու համար ստեղծվել են մի քանի այլ լուծումներ, ինչպիսիք են WebSockets արձանագրությունը կամ HTTP արձանագրության օգտագործումը QUIC-ի վրա (Quick UDP Internet Connections):
WebSockets-ի դեպքում, չնայած այն օգտագործվում է իրական ժամանակում տվյալները սերվերից վեբ-հաճախորդ փոխանցելու համար և ապահովում է մշտական կապեր միաժամանակյա երկկողմանի հաղորդակցությամբ, այն նախատեսված չէ սահմանափակ հաշվողական ռեսուրսներով սարքերի համար: QUIC-ը նույնպես արժանի է ուշադրության, քանի որ տրանսպորտային նոր արձանագրությունը շատ նոր հնարավորություններ է տալիս: Բայց քանի որ QUIC-ը դեռ ստանդարտացված չէ, վաղաժամ է կանխատեսել դրա հնարավոր կիրառումը և ազդեցությունը IoT լուծումների վրա: Այսպիսով, մենք նկատի ենք ունենում WebSockets-ը և QUIC-ը` ակնկալելով ապագան, բայց առայժմ այն ավելի մանրամասն չենք ուսումնասիրի:
Ո՞վ է աշխարհում ամենասիրունը՝ համեմատելով արձանագրությունները
Այժմ խոսենք արձանագրությունների ուժեղ և թույլ կողմերի մասին: Առաջ նայելով, եկեք անմիջապես վերապահում անենք, որ հստակ առաջնորդ չկա։ Յուրաքանչյուր արձանագրություն ունի որոշ առավելություններ/թերություններ:
Պատասխան ժամանակ
Հաղորդակցության արձանագրությունների ամենակարևոր բնութագրիչներից մեկը, հատկապես իրերի ինտերնետի հետ կապված, արձագանքման ժամանակն է: Սակայն գոյություն ունեցող արձանագրությունների շարքում չկա հստակ հաղթող, որը ցույց է տալիս ուշացման նվազագույն մակարդակը տարբեր պայմաններում աշխատելիս: Բայց կա մի ամբողջ փունջ հետազոտություն և արձանագրության հնարավորությունների համեմատություններ:
Օրինակ, IoT-ի հետ աշխատելիս HTTP-ի և MQTT-ի արդյունավետության համեմատությունները ցույց են տվել, որ MQTT-ի հարցումների արձագանքման ժամանակն ավելի քիչ է, քան HTTP-ի համար: Եւ երբ MQTT-ի և CoAP-ի շրջադարձային ժամանակը (RTT) ցույց է տվել, որ CoAP-ի միջին RTT-ը 20%-ով պակաս է, քան MQTT-ինը:
Այլ RTT-ով MQTT և CoAP արձանագրությունների համար իրականացվել է երկու սցենարով՝ տեղական ցանց և IoT ցանց: Պարզվեց, որ IoT ցանցում միջին RTT-ը 2-3 անգամ ավելի բարձր է։ QoS0-ով MQTT-ն ավելի ցածր արդյունք ցույց տվեց CoAP-ի համեմատ, իսկ MQTT-ը QoS1-ով ցույց տվեց ավելի բարձր RTT՝ կիրառական և տրանսպորտային շերտերում ACK-ների պատճառով: QoS տարբեր մակարդակների համար ցանցի ուշացումն առանց գերբեռնվածության միլիվայրկյան էր MQTT-ի համար, իսկ հարյուրավոր միկրովայրկյան՝ CoAP-ի համար: Այնուամենայնիվ, հարկ է հիշել, որ ավելի քիչ հուսալի ցանցերի վրա աշխատելիս TCP-ի վերևում աշխատող MQTT-ն ցույց կտա բոլորովին այլ արդյունք:
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-ն ավելի հարմար է Իրերի ինտերնետ ցանցերում տեղեկատվության փոխանակման համար, հատկապես, եթե չկա էներգիայի սահմանափակումներ:
Փորձարկումը, որը համեմատում էր AMQP-ի և MQTT-ի հնարավորությունները շարժական կամ անկայուն անլար ցանցի փորձարկման հարթակի վրա, ցույց տվեց, որ AMQP-ն առաջարկում է ավելի շատ անվտանգության հնարավորություններ, մինչդեռ MQTT-ն ավելի էներգաարդյունավետ է:
Безопасность
Անվտանգությունը ևս մեկ կարևոր խնդիր է, որը բարձրացվում է Իրերի ինտերնետի և մառախուղի/ամպային հաշվարկի թեման ուսումնասիրելիս: Անվտանգության մեխանիզմը սովորաբար հիմնված է TLS-ի վրա HTTP-ում, MQTT-ում, AMQP-ում և XMPP-ում կամ DTLS-ում CoAP-ում և աջակցում է երկու DDS տարբերակներին:
TLS-ը և DTLS-ը սկսվում են հաճախորդի և սերվերի կողմերի միջև հաղորդակցության հաստատման գործընթացից՝ աջակցվող գաղտնագրման հավաքակազմերն ու բանալիները փոխանակելու համար: Երկու կողմերն էլ բանակցում են հավաքածուների շուրջ՝ ապահովելու, որ հետագա հաղորդակցությունն ապահով ալիքով լինի: Երկուսի միջև տարբերությունը կայանում է փոքր փոփոխությունների մեջ, որոնք թույլ են տալիս UDP-ի վրա հիմնված DTLS-ին աշխատել անվստահելի կապի վրա:
Ի TLS-ի և DTLS-ի մի քանի տարբեր իրականացումներ պարզեցին, որ TLS-ն ավելի լավ աշխատանք է կատարել: DTLS-ի վրա հարձակումներն ավելի հաջող էին, քանի որ դրա հանդուրժողականությունը սխալ էր:
Այնուամենայնիվ, այս արձանագրությունների ամենամեծ խնդիրն այն է, որ դրանք ի սկզբանե նախատեսված չէին IoT-ում օգտագործելու համար և նախատեսված չէին աշխատելու մառախուղի կամ ամպի մեջ: Ձեռքսեղմման միջոցով նրանք հավելյալ տրաֆիկ են ավելացնում յուրաքանչյուր կապի հաստատության հետ, ինչը սպառում է հաշվողական ռեսուրսները: Միջին հաշվով, TLS-ի համար կա 6,5% աճ և 11% DTLS-ի համար՝ առանց անվտանգության շերտի հաղորդակցությունների համեմատ: Ռեսուրսներով հարուստ միջավայրերում, որոնք սովորաբար գտնվում են մակարդակով, սա խնդիր չի լինի, բայց IoT-ի և մառախուղի մակարդակի միջև կապի մեջ սա դառնում է կարևոր սահմանափակում:
Ի՞նչ ընտրել: Հստակ պատասխան չկա. MQTT-ը և HTTP-ը, թվում է, ամենախոստումնալից արձանագրություններն են, քանի որ դրանք համարվում են համեմատաբար ավելի հասուն և ավելի կայուն IoT լուծումներ՝ համեմատած այլ արձանագրությունների:
Լուծումներ՝ հիմնված միասնական հաղորդակցության արձանագրության վրա
Մեկ արձանագրային լուծման պրակտիկան ունի բազմաթիվ թերություններ: Օրինակ, արձանագրությունը, որը համապատասխանում է սահմանափակ միջավայրին, կարող է չաշխատել այնպիսի տիրույթում, որն ունի անվտանգության խիստ պահանջներ: Սա նկատի ունենալով, մեզ մնում է հրաժարվել IoT-ի «Մառախուղ-ամպ» էկոհամակարգի գրեթե բոլոր հնարավոր մեկ արձանագրային լուծումներից, բացառությամբ MQTT-ի և REST HTTP-ի:
REST HTTP որպես մեկ արձանագրության լուծում
Կա լավ օրինակ, թե ինչպես են REST HTTP հարցումները և պատասխանները փոխազդում IoT-to-Fog տարածության մեջ. . Կենդանիները հագեցված են կրելի սենսորներով (IoT հաճախորդ, C) և կառավարվում են ամպային հաշվարկի միջոցով խելացի գյուղատնտեսական համակարգի միջոցով (Fog server, S):
POST մեթոդի վերնագիրը սահմանում է ռեսուրսը (/farm/animals) փոփոխելու համար, ինչպես նաև HTTP տարբերակն ու բովանդակության տեսակը, որն այս դեպքում JSON օբյեկտ է, որը ներկայացնում է այն կենդանիների ֆերման, որը համակարգը պետք է կառավարի (Dulcinea/կով) . Սերվերի պատասխանը ցույց է տալիս, որ հարցումը հաջողվել է՝ ուղարկելով HTTPS կարգավիճակի կոդը 201 (ստեղծվել է ռեսուրս): GET մեթոդը պետք է նշի միայն պահանջվող ռեսուրսը URI-ում (օրինակ՝ /farm/animals/1), որը սերվերից վերադարձնում է այդ ID-ով կենդանու JSON ներկայացումը:
PUT մեթոդը օգտագործվում է, երբ որոշակի ռեսուրսների գրառումը պետք է թարմացվի: Այս դեպքում ռեսուրսը նշում է փոփոխվող պարամետրի URI-ը և ընթացիկ արժեքը (օրինակ՝ նշելով, որ կովը ներկայումս քայլում է, /farm/animals/1? state=քայլում է): Վերջապես, DELETE մեթոդը օգտագործվում է GET մեթոդին հավասար, բայց ուղղակի ջնջում է ռեսուրսը գործողության արդյունքում։
MQTT որպես մեկ արձանագրության լուծում
Վերցնենք նույն խելացի ֆերմա, բայց REST HTTP-ի փոխարեն մենք օգտագործում ենք MQTT արձանագրությունը: Տեղական սերվերը, որտեղ տեղադրված է Mosquitto գրադարանը, գործում է որպես բրոքեր: Այս օրինակում պարզ համակարգիչ (որը կոչվում է ֆերմայի սերվեր) Raspberry Pi-ն ծառայում է որպես MQTT հաճախորդ, որն իրականացվում է Paho MQTT գրադարանի տեղադրման միջոցով, որը լիովին համատեղելի է Mosquitto բրոքերի հետ:
Այս հաճախորդը համապատասխանում է IoT աբստրակցիոն շերտին, որը ներկայացնում է զգայական և հաշվողական հնարավորություններով սարք: Մյուս կողմից, միջնորդը համապատասխանում է աբստրակցիայի ավելի բարձր մակարդակի, որը ներկայացնում է մառախուղի հաշվողական հանգույց, որը բնութագրվում է ավելի մեծ մշակման և պահեստավորման հզորությամբ:
Առաջարկվող խելացի ֆերմայի սցենարում Raspberry Pi-ը միանում է արագացուցիչին, GPS-ին և ջերմաստիճանի տվիչներին և հրապարակում տվյալ սենսորներից մառախուղի հանգույց: Ինչպես հավանաբար գիտեք, MQTT-ն թեմաներին վերաբերվում է որպես հիերարխիա: Մեկ MQTT հրատարակիչ կարող է հրապարակել հաղորդագրություններ կոնկրետ թեմաների համար: Մեր դեպքում դրանք երեքն են. Սենսորի համար, որը չափում է ջերմաստիճանը կենդանիների գոմում, հաճախորդը ընտրում է թեմա (կենդանիների ֆերմա/թաղանթ/ջերմաստիճան): Սենսորների համար, որոնք չափում են GPS-ի գտնվելու վայրը և կենդանիների շարժումը արագաչափի միջոցով, հաճախորդը կհրապարակի թարմացումներ (կենդանիների ֆերմա/կենդանիներ/GPS) և (կենդանիների ֆերմա/կենդանիներ/շարժում):
Այս տեղեկատվությունը կփոխանցվի բրոքերին, որը կարող է ժամանակավորապես պահել այն տեղական տվյալների բազայում, եթե ավելի ուշ հայտնվի մեկ այլ շահագրգիռ բաժանորդ:
Բացի տեղական սերվերից, որը մառախուղում գործում է որպես MQTT բրոքեր և որին Raspberry Pis-ը, հանդես գալով որպես MQTT հաճախորդ, ուղարկում է սենսորային տվյալներ, կարող է լինել ևս մեկ այլ MQTT բրոքեր ամպի մակարդակում: Այս դեպքում տեղական բրոքերին փոխանցված տեղեկատվությունը կարող է ժամանակավորապես պահպանվել տեղական տվյալների բազայում և/կամ ուղարկել ամպին: Մառախուղի MQTT բրոքերը այս իրավիճակում օգտագործվում է բոլոր տվյալները ամպային MQTT բրոքերի հետ կապելու համար: Այս ճարտարապետությամբ բջջային հավելվածի օգտվողը կարող է բաժանորդագրվել երկու բրոքերներին:
Եթե բրոքերներից մեկի (օրինակ՝ ամպի) հետ կապը ձախողվի, վերջնական օգտագործողը տեղեկություն կստանա մյուսից (մառախուղ): Սա համակցված մառախուղի և ամպային հաշվողական համակարգերի բնորոշ հատկանիշն է: Լռելյայնորեն, բջջային հավելվածը կարող է կազմաձևվել այնպես, որ նախ միանա մառախուղի MQTT բրոքերին, իսկ եթե դա չհաջողվի, միանա ամպային MQTT բրոքերին: Այս լուծումը միայն մեկն է IoT-F2C համակարգերի շատերից:
Բազմաարձանագրային լուծումներ
Մեկ արձանագրային լուծումները տարածված են իրենց ավելի հեշտ իրականացման շնորհիվ: Բայց պարզ է, որ IoT-F2C համակարգերում իմաստ ունի միավորել տարբեր արձանագրություններ։ Գաղափարն այն է, որ տարբեր արձանագրություններ կարող են գործել տարբեր մակարդակներում: Վերցրեք, օրինակ, երեք աբստրակցիա՝ IoT-ի շերտերը, մառախուղը և ամպային հաշվարկը: IoT մակարդակի սարքերը սովորաբար համարվում են սահմանափակ: Այս ակնարկի համար եկեք դիտարկենք IoT մակարդակները որպես ամենասահմանափակ, ամպը՝ ամենաքիչ կաշկանդվածը, իսկ մառախուղի հաշվարկը՝ «ինչ-որ տեղ մեջտեղում»: Այնուհետև պարզվում է, որ IoT-ի և մառախուղի աբստրակցիաների միջև ընթացիկ պրոտոկոլային լուծումները ներառում են MQTT, CoAP և XMPP: Մառախուղի և ամպի միջև, մյուս կողմից, AMQP-ն օգտագործվող հիմնական արձանագրություններից մեկն է՝ REST HTTP-ի հետ միասին, որն իր ճկունության շնորհիվ օգտագործվում է նաև IoT-ի և մառախուղի շերտերի միջև։
Այստեղ հիմնական խնդիրը արձանագրությունների փոխգործունակությունն է և հաղորդագրությունները մի արձանագրությունից մյուսը փոխանցելու հեշտությունը: Իդեալում, ապագայում ամպի և մառախուղի ռեսուրսներով իրերի ինտերնետ համակարգի ճարտարապետությունը անկախ կլինի օգտագործվող հաղորդակցության արձանագրությունից և կապահովի տարբեր արձանագրությունների միջև լավ փոխգործունակություն:
Քանի որ ներկայումս դա այդպես չէ, իմաստ ունի միավորել արձանագրությունները, որոնք էական տարբերություններ չունեն: Այդ նպատակով մեկ պոտենցիալ լուծում հիմնված է երկու արձանագրությունների համակցության վրա, որոնք հետևում են նույն ճարտարապետական ոճին՝ REST HTTP և CoAP: Մեկ այլ առաջարկվող լուծում հիմնված է երկու արձանագրությունների համակցության վրա, որոնք առաջարկում են հրապարակել-բաժանորդագրվել հաղորդակցություն՝ MQTT և AMQP: Նմանատիպ հասկացությունների օգտագործումը (ինչպես MQTT, այնպես էլ AMQP օգտագործում են բրոքերներ, CoAP-ը և HTTP-ն օգտագործում են REST-ը) հեշտացնում է այս համակցությունները իրականացնելը և պահանջում է ավելի քիչ ինտեգրման ջանք:
Նկար (ա) ցույց է տալիս հարցումների վրա հիմնված երկու մոդելներ՝ HTTP և CoAP, և դրանց հնարավոր տեղադրումը IoT-F2C լուծումում: Քանի որ HTTP-ն ժամանակակից ցանցերում ամենահայտնի և ընդունված արձանագրություններից մեկն է, դժվար թե այն ամբողջությամբ փոխարինվի հաղորդագրությունների փոխանակման այլ արձանագրություններով: Ամպի և մառախուղի միջև գտնվող հզոր սարքերը ներկայացնող հանգույցների շարքում REST HTTP-ը խելացի լուծում է:
Մյուս կողմից, սահմանափակ հաշվողական ռեսուրսներով սարքերի համար, որոնք շփվում են Fog-ի և IoT շերտերի միջև, ավելի արդյունավետ է օգտագործել CoAP-ը: CoAP-ի մեծ առավելություններից մեկն իրականում նրա համատեղելիությունն է HTTP-ի հետ, քանի որ երկու արձանագրություններն էլ հիմնված են REST սկզբունքների վրա:
Գծապատկեր (բ) ցույց է տալիս նույն սցենարով երկու հրատարակել-բաժանորդագրվել հաղորդակցման մոդելներ, ներառյալ MQTT և AMQP: Թեև երկու արձանագրությունները կարող են հիպոթետիկորեն օգտագործվել յուրաքանչյուր աբստրակցիոն շերտի հանգույցների միջև հաղորդակցության համար, դրանց դիրքը պետք է որոշվի կատարողականի հիման վրա: MQTT-ը նախագծվել է որպես թեթև արձանագրություն սահմանափակ հաշվողական ռեսուրսներով սարքերի համար, ուստի այն կարող է օգտագործվել IoT-Fog հաղորդակցության համար: AMQP-ն ավելի հարմար է ավելի հզոր սարքերի համար, որոնք իդեալականորեն այն կդնեն մառախուղի և ամպի հանգույցների միջև: MQTT-ի փոխարեն XMPP արձանագրությունը կարող է օգտագործվել IoT-ում, քանի որ այն համարվում է թեթև: Բայց դա այնքան էլ լայնորեն չի կիրառվում նման սցենարներում։
Արդյունքները
Քիչ հավանական է, որ քննարկված արձանագրություններից մեկը բավարար լինի համակարգում բոլոր հաղորդակցությունները ծածկելու համար՝ սահմանափակ հաշվողական ռեսուրսներով սարքերից մինչև ամպային սերվերներ: Հետազոտությունը ցույց է տվել, որ երկու ամենահեռանկարային տարբերակները, որոնք ծրագրավորողները ամենաշատն են օգտագործում, MQTT և RESTful HTTP են: Այս երկու արձանագրությունները ոչ միայն առավել հասուն և կայուն են, այլ նաև ներառում են բազմաթիվ լավ փաստաթղթավորված և հաջող իրականացումներ և առցանց ռեսուրսներ:
Իր կայունության և պարզ կազմաձևման շնորհիվ MQTT-ն արձանագրություն է, որն ապացուցել է իր բարձր արդյունավետությունը ժամանակի ընթացքում, երբ օգտագործվում է IoT մակարդակում սահմանափակ սարքերով: Համակարգի այն մասերում, որտեղ սահմանափակ հաղորդակցությունը և մարտկոցի սպառումը խնդիր չեն, օրինակ՝ որոշ մառախուղի տիրույթներ և ամպային հաշվարկների մեծ մասը, RESTful HTTP-ն հեշտ ընտրություն է: CoAP-ը նույնպես պետք է հաշվի առնել, քանի որ այն նաև արագորեն զարգանում է որպես IoT հաղորդագրությունների ստանդարտ, և հավանական է, որ մոտ ապագայում այն կհասնի կայունության և հասունության մակարդակի, որը նման է MQTT-ին և HTTP-ին: Սակայն ստանդարտը ներկայումս զարգանում է, ինչը կապված է կարճաժամկետ համատեղելիության խնդիրների հետ:
Էլ ի՞նչ կարող եք կարդալ բլոգում:
→
→
→
→
→
Բաժանորդագրվեք մեր -ալիք, որպեսզի բաց չթողնեք հաջորդ հոդվածը: Մենք գրում ենք ոչ ավելի, քան շաբաթական երկու անգամ և միայն գործով:
Source: www.habr.com