አይኦቲ፣ ጭጋግ እና ደመና፡ ስለ ቴክኖሎጂ እንነጋገር?

በሶፍትዌር እና በሃርድዌር መስክ የቴክኖሎጂ እድገት ፣ አዳዲስ የግንኙነት ፕሮቶኮሎች መፈጠር የበይነመረብ ነገሮች (አይኦቲ) መስፋፋት ምክንያት ሆኗል ። የመሳሪያዎቹ ቁጥር ከቀን ወደ ቀን እያደገ ሲሆን ከፍተኛ መጠን ያለው መረጃ እያመነጩ ነው። ስለዚህ ይህንን መረጃ ለማስኬድ ፣ ለማከማቸት እና ለማስተላለፍ የሚያስችል ምቹ የስርዓት አርክቴክቸር ያስፈልጋል ።

አሁን የደመና አገልግሎቶች ለእነዚህ ዓላማዎች ጥቅም ላይ ይውላሉ. ይሁን እንጂ ከጊዜ ወደ ጊዜ ታዋቂው የጭጋግ ኮምፒዩቲንግ ፓራዳይም (ፎግ) የአይኦቲ መሠረተ ልማትን በማሳደግ እና በማመቻቸት የደመና መፍትሄዎችን ሊያሟላ ይችላል።

ደመናዎች አብዛኛዎቹን የIoT ጥያቄዎችን መሸፈን ይችላሉ። ለምሳሌ የአገልግሎቶችን ክትትል ለማቅረብ፣ በመሣሪያዎች የሚመነጨውን ማንኛውንም የውሂብ መጠን በፍጥነት ማካሄድ፣ እንዲሁም የእይታ እይታቸውን ለማቅረብ። የእውነተኛ ጊዜ ችግሮችን በሚፈታበት ጊዜ ጭጋግ ማስላት የበለጠ ውጤታማ ነው። ለጥያቄዎች ፈጣን ምላሽ ይሰጣሉ እና በመረጃ ሂደት ውስጥ አነስተኛ መዘግየት። ያም ማለት ጭጋግ "ደመናዎችን" ያሟላል እና አቅሙን ያሰፋዋል.

ሆኖም ፣ ዋናው ጥያቄ የተለየ ነው-ይህ ሁሉ በ IoT አውድ ውስጥ እንዴት መስተጋብር አለበት? በተጣመረ IoT-Fog-Cloud ስርዓት ውስጥ ሲሰሩ የትኞቹ የግንኙነት ፕሮቶኮሎች በጣም ውጤታማ ይሆናሉ?

ምንም እንኳን የኤችቲቲፒ የበላይነት ቢታይም በአዮቲ ፣ ፎግ እና ክላውድ ሲስተም ውስጥ ጥቅም ላይ የሚውሉ ሌሎች በርካታ መፍትሄዎች አሉ። ምክንያቱም IoT የተለያዩ የመሣሪያ ዳሳሾችን ተግባር ከደህንነት፣ ተኳኋኝነት እና ሌሎች የተጠቃሚዎች መስፈርቶች ጋር ማጣመር ስላለበት ነው።

ግን ስለ ማጣቀሻ አርክቴክቸር እና የግንኙነት ደረጃ ምንም አይነት ሀሳብ የለም። ስለዚህ፣ አዲስ ፕሮቶኮል መፍጠር ወይም ነባሩን ለተወሰኑ የአይኦቲ ተግባራት ማሻሻል በ IT ማህበረሰብ ፊት ለፊት ከሚታዩት በጣም አስፈላጊ ተግባራት ውስጥ አንዱ ነው።

በአሁኑ ጊዜ ምን ፕሮቶኮሎች ጥቅም ላይ ይውላሉ እና ምን ሊያቀርቡ ይችላሉ? እስቲ እንገምተው። በመጀመሪያ ግን ደመና፣ ጭጋግ እና የነገሮች ኢንተርኔት የሚገናኙበትን የስነ-ምህዳር መርሆች እንወያይ።

IoT Fog-to-Cloud (F2C) አርክቴክቸር

ከአይኦቲ፣ ደመና እና ጭጋግ ብልጥ እና የተቀናጀ አስተዳደር ጋር የተያያዙ ጥቅሞችን እና ጥቅሞችን ለመፈተሽ ምን ያህል ጥረት እየተደረገ እንዳለ አስተውለህ ይሆናል። ካልሆነ፣ ሶስት ደረጃ የማውጣት ውጥኖች እዚህ አሉ። ክፍት ፎግ ኮንሰርቲየም, ጠርዝ ኮምፒውቲንግ ኮንሰርቲየም и mF2C H2020 የአውሮፓ ህብረት ፕሮጀክት.

ቀደም ሲል 2 ደረጃዎች ብቻ ከግምት ውስጥ ከገቡ ፣ ደመናዎች እና የመጨረሻ መሣሪያዎች ፣ ከዚያ የታቀደው ሥነ ሕንፃ አዲስ ደረጃን ያስተዋውቃል - ጭጋግ ማስላት። በዚህ ሁኔታ ፣ የጭጋግ ደረጃው እንደ ልዩ ሀብቶች ወይም በእነዚህ ንዑስ ክፍሎች ውስጥ የተለያዩ መሳሪያዎችን አጠቃቀም በሚወስኑ የፖሊሲዎች ስብስብ ላይ በመመስረት የጭጋግ ደረጃ ወደ ብዙ ንዑስ ክፍሎች ሊከፋፈል ይችላል።

ይህ ረቂቅ ምን ሊመስል ይችላል? እዚህ የተለመደ IoT-Fog-Cloud ሥነ-ምህዳር አለ። ዝቅተኛ መዘግየት የሚጠይቁ ችግሮችን ለመፍታት የአይኦቲ መሳሪያዎች መረጃን ወደ ፈጣን አገልጋዮች እና የኮምፒዩተር መሳሪያዎች ይልካሉ። በተመሳሳዩ ስርዓት ውስጥ, ደመናዎች ከፍተኛ መጠን ያለው የኮምፒዩተር ሀብቶችን ወይም የውሂብ ማከማቻ ቦታን የሚጠይቁ ችግሮችን የመፍታት ሃላፊነት አለባቸው.

ስማርትፎኖች፣ ስማርት ሰዓቶች እና ሌሎች መግብሮች እንዲሁ የአይኦቲው አካል ሊሆኑ ይችላሉ። ነገር ግን እንደነዚህ ያሉ መሳሪያዎች, እንደ አንድ ደንብ, ከትልቅ ገንቢዎች የባለቤትነት ግንኙነት ፕሮቶኮሎችን ይጠቀማሉ. የመነጨው የአይኦቲ መረጃ በREST HTTP ፕሮቶኮል በኩል ወደ ጭጋግ ንብርብር ይተላለፋል፣ ይህም RESTful አገልግሎቶችን ሲፈጥር ተለዋዋጭነትን እና መስተጋብርን ይሰጣል። ይህ በሃገር ውስጥ ኮምፒውተሮች፣ ሰርቨሮች ወይም የአገልጋይ ክላስተር ላይ ከሚሰሩ የኮምፒዩተር መሠረተ ልማት ጋር ወደ ኋላ ተኳሃኝነትን ከማረጋገጥ አስፈላጊነት አንጻር አስፈላጊ ነው። "የጭጋግ ኖዶች" የሚባሉት የአካባቢ ሀብቶች የተቀበለውን ውሂብ ያጣሩ እና በአካባቢው ያስኬዱት ወይም ለተጨማሪ ስሌት ወደ ደመናው ይላኩት።

ደመናዎች የተለያዩ የግንኙነት ፕሮቶኮሎችን ይደግፋሉ፣ በጣም የተለመዱት AMQP እና REST HTTP ናቸው። ኤችቲቲፒ በደንብ የሚታወቅ እና ለኢንተርኔት የተበጀ በመሆኑ ጥያቄው ሊነሳ ይችላል፡ “ከአይኦቲ እና ጭጋግ ጋር ለመስራት ልንጠቀምበት የለብንም?” ሆኖም ይህ ፕሮቶኮል የአፈጻጸም ችግሮች አሉት። በዚህ ላይ ተጨማሪ።

በአጠቃላይ እኛ የምንፈልገው ስርዓት ተስማሚ የሆኑ 2 የግንኙነት ፕሮቶኮሎች ሞዴሎች አሉ። እነዚህ የጥያቄ-ምላሽ እና ማተም-ደንበኝነት መመዝገብ ናቸው። የመጀመሪያው ሞዴል በተለይ በአገልጋይ-ደንበኛ አርክቴክቸር በሰፊው ይታወቃል። ደንበኛው ከአገልጋዩ መረጃን ይጠይቃል, እና አገልጋዩ ጥያቄውን ይቀበላል, ያስኬዳል እና የምላሽ መልእክት ይመልሳል. የ REST HTTP እና CoAP ፕሮቶኮሎች በዚህ ሞዴል ይሰራሉ።

ሁለተኛው ሞዴል ያልተመሳሰለ, የተከፋፈለ, መረጃን በሚፈጥሩ ምንጮች እና በዚህ መረጃ ተቀባዮች መካከል ያልተመሳሰለ ትስስር ማቅረብ አስፈላጊ ነበር.

ሞዴሉ ሶስት ተሳታፊዎችን ይይዛል-አሳታሚ (የውሂብ ምንጭ), ደላላ (ላኪ) እና ተመዝጋቢ (ተቀባይ). እዚህ፣ እንደ ተመዝጋቢ ሆኖ የሚሰራው ደንበኛ ከአገልጋዩ መረጃ መጠየቅ የለበትም። ጥያቄዎችን ከመላክ ይልቅ፣ ሁሉንም ገቢ መልዕክቶች የማጣራት እና በአታሚዎች እና ተመዝጋቢዎች መካከል የማዘዋወር ሃላፊነት ባለው በደላላ በኩል በስርዓቱ ውስጥ ለተወሰኑ ክስተቶች ይመዘገባል። እና አታሚው፣ አንድን ርዕሰ ጉዳይ በተመለከተ አንድ ክስተት ሲከሰት፣ ለደላላው ያሳትመዋል፣ ይህም በተጠየቀው ርዕስ ላይ መረጃን ለተመዝጋቢው ይልካል።

በመሠረቱ, ይህ አርክቴክቸር በክስተት ላይ የተመሰረተ ነው. እና ይህ የመስተጋብር ሞዴል በአዮቲ ፣ ደመና ፣ ጭጋግ ውስጥ ላሉት አፕሊኬሽኖች ትኩረት የሚስብ ነው ምክንያቱም scalability ለማቅረብ እና በተለያዩ መሳሪያዎች መካከል ያለውን ግንኙነት ቀላል ለማድረግ ፣ ተለዋዋጭ ከብዙ እስከ ብዙ ግንኙነቶች እና ያልተመሳሰሉ ግንኙነቶችን ይደግፋል። የሕትመት ተመዝጋቢ ሞዴልን የሚጠቀሙ አንዳንድ በጣም የታወቁ ደረጃውን የጠበቁ የመልእክት ፕሮቶኮሎች MQTT፣ AMQP እና DDS ያካትታሉ።

በግልጽ ለማየት እንደሚቻለው የህትመት-ተመዝጋቢው ሞዴል ብዙ ጥቅሞች አሉት

• አታሚዎች እና ተመዝጋቢዎች አንዳቸው የሌላውን መኖር ማወቅ አያስፈልጋቸውም;
• አንድ የደንበኝነት ተመዝጋቢ ከብዙ የተለያዩ ህትመቶች መረጃን መቀበል ይችላል, እና አንድ አታሚ ለብዙ የተለያዩ ተመዝጋቢዎች መረጃን መላክ ይችላል (ብዙ-ወደ-ብዙ መርህ);
• አታሚው እና ተመዝጋቢው ለመግባባት በተመሳሳይ ጊዜ ንቁ መሆን የለባቸውም, ምክንያቱም ደላላው (እንደ ወረፋ ስርዓት በመስራት ላይ) በአሁኑ ጊዜ ከአውታረ መረቡ ጋር ያልተገናኙ ደንበኞች መልእክቱን ማከማቸት ይችላል.

ሆኖም፣ የጥያቄ-ምላሽ ሞዴልም ጥንካሬዎች አሉት። የአገልጋዩ ጎን ብዙ የደንበኛ ጥያቄዎችን የማስተናገድ ችሎታ ችግር በማይኖርበት ጊዜ፣ የተረጋገጡ እና አስተማማኝ መፍትሄዎችን መጠቀም ተገቢ ነው።

ሁለቱንም ሞዴሎች የሚደግፉ ፕሮቶኮሎችም አሉ. ለምሳሌ, XMPP እና HTTP 2.0, "የአገልጋይ ግፊት" አማራጭን የሚደግፉ. IETF በተጨማሪም CoAP አውጥቷል። የመልእክት መላላኪያ ችግሩን ለመፍታት በሚደረገው ሙከራ እንደ WebSockets ፕሮቶኮል ወይም የኤችቲቲፒ ፕሮቶኮል በQUIC (ፈጣን የዩዲፒ ኢንተርኔት ግንኙነቶች) አጠቃቀም ያሉ ሌሎች በርካታ መፍትሄዎች ተፈጥረዋል።

በዌብሶኬት ላይ ምንም እንኳን መረጃን ከአገልጋይ ወደ ዌብ ደንበኛ በእውነተኛ ጊዜ ለማስተላለፍ ጥቅም ላይ የሚውል እና በተከታታይ የሁለት አቅጣጫዊ ግንኙነት ግንኙነቶችን የሚያቀርብ ቢሆንም ውስን የኮምፒዩተር ሀብቶች ላላቸው መሳሪያዎች የታሰበ አይደለም። አዲሱ የትራንስፖርት ፕሮቶኮል ብዙ አዳዲስ እድሎችን ስለሚሰጥ QUIC ትኩረት ሊሰጠው ይገባል። ነገር ግን QUIC ገና ደረጃውን የጠበቀ ስላልሆነ፣ ሊተገበር የሚችለውን አተገባበር እና በአይኦቲ መፍትሄዎች ላይ ያለውን ተጽእኖ አስቀድሞ መተንበይ ጊዜው ያለፈበት ነው። ስለዚህ WebSockets እና QUICን በአዕምሮአችን ውስጥ እናስቀምጣለን ወደ ፊት ወደፊት, ግን ለአሁን በበለጠ ዝርዝር አናጠናውም.

በዓለም ላይ በጣም ቆንጆ የሆነው ማን ነው-ፕሮቶኮሎችን ማወዳደር

አሁን ስለ ፕሮቶኮሎች ጥንካሬ እና ድክመቶች እንነጋገር. ወደ ፊት ስንመለከት፣ ግልጽ የሆነ መሪ እንደሌለ ወዲያውኑ እንያዝ። እያንዳንዱ ፕሮቶኮል አንዳንድ ጥቅሞች/ጉዳቶች አሉት።

የምላሽ ጊዜ

የግንኙነት ፕሮቶኮሎች በጣም አስፈላጊ ከሆኑት ባህሪያት አንዱ, በተለይም ከበይነመረብ ነገሮች ጋር በተያያዘ, የምላሽ ጊዜ ነው. ነገር ግን አሁን ባሉት ፕሮቶኮሎች ውስጥ በተለያዩ ሁኔታዎች ውስጥ በሚሰሩበት ጊዜ ዝቅተኛውን የመዘግየት ደረጃን የሚያሳይ ግልጽ አሸናፊ የለም. ነገር ግን አጠቃላይ የምርምር እና የፕሮቶኮል ችሎታዎች ንፅፅር አለ።

ለምሳሌ ያህል, ውጤቶቹ ከአይኦቲ ጋር ሲሰራ የኤችቲቲፒ እና MQTT ውጤታማነት ንፅፅር እንደሚያሳየው ለMQTT ጥያቄዎች የምላሽ ጊዜ ከኤችቲቲፒ ያነሰ ነው። እና መቼ በማጥናት የ MQTT እና CoAP የዙር ጉዞ ጊዜ (RTT) አማካይ RTT ከMQTT 20% ያነሰ መሆኑን አሳይቷል።

ሌላ ሙከራ ከ RTT ጋር ለ MQTT እና CoAP ፕሮቶኮሎች በሁለት ሁኔታዎች ተካሂደዋል-የአካባቢ አውታረመረብ እና አይኦቲ አውታረ መረብ። በ IoT አውታረመረብ ውስጥ አማካይ RTT ከ2-3 እጥፍ ከፍ ያለ መሆኑ ተረጋግጧል። MQTT ከ QoS0 ከ CoAP ጋር ሲነጻጸር ዝቅተኛ ውጤት አሳይቷል, እና MQTT ከ QoS1 ጋር በመተግበሪያው እና በማጓጓዣ ንብርብሮች ላይ በኤሲኬዎች ምክንያት ከፍ ያለ RTT አሳይቷል. ለተለያዩ የQoS ደረጃዎች፣ የአውታረ መረብ መዘግየት ያለ መጨናነቅ ሚሊሰከንዶች ለMQTT፣ እና በመቶዎች የሚቆጠሩ ማይክሮ ሰከንድ ለኮፕ። ሆኖም ግን, አስተማማኝ ባልሆኑ አውታረ መረቦች ላይ በሚሰሩበት ጊዜ, MQTT በ TCP ላይ መሮጥ ፍጹም የተለየ ውጤት እንደሚያሳይ ማስታወስ ጠቃሚ ነው.

ንጽጽር ክፍያን በመጨመር ለ AMQP እና MQTT ፕሮቶኮሎች የምላሽ ጊዜ እንደሚያሳየው በቀላል ጭነት የቆይታ ደረጃው ተመሳሳይ ነው። ነገር ግን ከፍተኛ መጠን ያለው ውሂብ ሲያስተላልፍ MQTT አጠር ያሉ የምላሽ ጊዜዎችን ያሳያል። በአንድ ተጨማሪ ምርምር ጋዝ ዳሳሾች፣ የአየር ሁኔታ ዳሳሾች፣ የቦታ ዳሳሾች (ጂፒኤስ) እና የሞባይል አውታረ መረብ በይነገጽ (GPRS) በተገጠሙ ተሽከርካሪዎች ላይ ከተዘረጉ መሳሪያዎች ጋር ከማሽን ወደ ማሽን የግንኙነት ሁኔታ CoAP ከኤችቲቲፒ ጋር ተነጻጽሯል። በተንቀሳቃሽ ስልክ አውታረመረብ ላይ የኮኤፒ መልእክት ለማስተላለፍ የሚያስፈልገው ጊዜ HTTP መልዕክቶችን ለመጠቀም ከሚያስፈልገው ጊዜ በሦስት እጥፍ ያነሰ ነበር።

ጥናቶች ሁለት ሳይሆኑ ሶስት ፕሮቶኮሎችን በማወዳደር ተካሂደዋል። ለምሳሌ, ንጽጽር የአዮቲ ፕሮቶኮሎች MQTT፣ DDS እና CoAP አፈጻጸም በህክምና አተገባበር ሁኔታ የአውታረ መረብ ኢምፔላተርን በመጠቀም። DDS በተለያዩ ደካማ የአውታረ መረብ ሁኔታዎች በተፈተነ የቴሌሜትሪ መዘግየት MQTT በልጧል። በUDP ላይ የተመሰረተ CoAP ፈጣን ምላሽ ጊዜ ለሚጠይቁ አፕሊኬሽኖች ጥሩ ሰርቷል፣ነገር ግን በUDP ላይ የተመሰረተ በመሆኑ፣ያልተጠበቀ የፓኬት ኪሳራ ነበር።

የመተላለፊያ ይዘት

ንጽጽር MQTT እና CoAP የመተላለፊያ ይዘትን ውጤታማነት በተመለከተ በአንድ መልእክት የሚተላለፈውን አጠቃላይ የውሂብ መጠን በማስላት ተካሂደዋል። CoAP ትናንሽ መልዕክቶችን ሲያስተላልፉ ከMQTT ያነሰ የውጤት መጠን አሳይቷል። ነገር ግን የፕሮቶኮሎችን ቅልጥፍና ከጠቃሚ የመረጃ ባይት ብዛት ጥምርታ እና ከተዛወረው ባይት አጠቃላይ ቁጥር አንጻር ሲታይ፣ CoAP የበለጠ ውጤታማ ሆኖ ተገኝቷል።

በ ትንተና MQTT፣ DDS (ከTCP እንደ ትራንስፖርት ፕሮቶኮል) እና ኮኤፒ ባንድዊድዝ በመጠቀም፣ CoAP በአጠቃላይ ባጠቃላይ ዝቅተኛ የመተላለፊያ ይዘት ፍጆታ እንዳሳየ ተደርሶበታል፣ ይህም በኔትወርክ ፓኬት መጥፋት ወይም በኔትወርክ መዘግየት አለመጨመሩ፣ ከ MQTT እና DDS በተለየ መልኩ በተጠቀሱት ሁኔታዎች ውስጥ የመተላለፊያ ይዘት አጠቃቀም መጨመር. ሌላው ሁኔታ ብዙ ቁጥር ያላቸው መሳሪያዎች በአንድ ጊዜ መረጃን የሚያስተላልፉ ሲሆን ይህም በአይኦቲ አካባቢ የተለመደ ነው። ውጤቶቹ እንደሚያሳዩት ለከፍተኛ አጠቃቀም 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 ላይ የተመሰረተ እና ሁለቱንም የዲዲኤስ ልዩነቶች ይደግፋል።

TLS እና DTLS የሚደገፉ የሲፈር ስብስቦችን እና ቁልፎችን ለመለዋወጥ በደንበኛው እና በአገልጋይ ወገኖች መካከል ግንኙነትን በመፍጠር ሂደት ይጀምራሉ። ደህንነቱ በተጠበቀ ቻናል ላይ ተጨማሪ ግንኙነት መፈጠሩን ለማረጋገጥ ሁለቱም ወገኖች ስብስቦችን ይደራደራሉ። በሁለቱ መካከል ያለው ልዩነት በ UDP ላይ የተመሰረተ DTLS አስተማማኝ ባልሆነ ግንኙነት ላይ እንዲሰራ በሚያስችሉ ትናንሽ ማሻሻያዎች ላይ ነው.

በ የሙከራ ጥቃቶች የተለያዩ የTLS እና DTLS አተገባበር TLS የተሻለ ስራ ሰርቷል። በዲቲኤልኤስ ላይ የተደረጉ ጥቃቶች በስህተቱ መቻቻል ምክንያት የበለጠ ስኬታማ ነበሩ።

ነገር ግን፣ የእነዚህ ፕሮቶኮሎች ትልቁ ችግር በመጀመሪያ በአዮቲ ውስጥ ጥቅም ላይ እንዲውል ያልተነደፉ እና በጭጋግ ወይም ደመና ውስጥ ለመስራት የታሰቡ አለመሆኑ ነው። በመጨባበጥ ከእያንዳንዱ የግንኙነት ተቋም ጋር ተጨማሪ ትራፊክ ይጨምራሉ ፣ ይህም የኮምፒዩተር ሀብቶችን ያጠፋል ። በአማካይ ከደህንነት ሽፋን ውጪ ከሚደረጉ ግንኙነቶች ጋር ሲነፃፀር ለTLS 6,5% እና ለDTLS 11% ከአናት በላይ ጭማሪ አለ። በንብረት የበለፀጉ አካባቢዎች፣በተለምዶ በ ላይ ይገኛሉ ደመናማ ደረጃ, ይህ ችግር አይሆንም, ነገር ግን በአዮቲ እና በጭጋግ ደረጃ መካከል ባለው ግንኙነት, ይህ አስፈላጊ ገደብ ይሆናል.

ምን መምረጥ? ምንም ግልጽ መልስ የለም. MQTT እና HTTP ከሌሎች ፕሮቶኮሎች ጋር ሲነፃፀሩ በንፅፅር የበለጠ የበሰሉ እና የበለጠ የተረጋጋ አይኦቲ መፍትሄዎች ተደርገው ስለሚወሰዱ በጣም ተስፋ ሰጪ ፕሮቶኮሎች ይመስላሉ።

በተዋሃደ የግንኙነት ፕሮቶኮል ላይ የተመሰረቱ መፍትሄዎች

የአንድ-ፕሮቶኮል መፍትሔ ልምምድ ብዙ ጉዳቶች አሉት. ለምሳሌ፣ ከተገደበ አካባቢ ጋር የሚስማማ ፕሮቶኮል ጥብቅ የደህንነት መስፈርቶች ባለው ጎራ ውስጥ ላይሰራ ይችላል። ይህን በአእምሯችን ይዘን፣ ከMQTT እና REST HTTP በስተቀር በIoT ውስጥ ከፎግ-ወደ-ክላውድ ሥነ-ምህዳር ውስጥ ያሉትን ሁሉንም ሊሆኑ የሚችሉ ነጠላ ፕሮቶኮል መፍትሄዎችን መጣል እንቀራለን።

REST HTTP እንደ ነጠላ ፕሮቶኮል መፍትሄ

የREST HTTP ጥያቄዎች እና ምላሾች ከአዮቲ ወደ ጭጋግ ቦታ እንዴት እንደሚገናኙ ጥሩ ምሳሌ አለ፡ ብልጥ እርሻ. እንስሳቱ ተለባሽ ዳሳሾች (አይኦቲ ደንበኛ፣ ሲ) የታጠቁ እና በዳመና ኮምፒውቲንግ በዘመናዊ የእርሻ ስርዓት (ፎግ አገልጋይ፣ ኤስ) ቁጥጥር ይደረግባቸዋል።

የPOST ዘዴው ራስጌ የሚሻሻለውን ሃብት (/እርሻ/እንስሳት) እንዲሁም የኤችቲቲፒ ስሪት እና የይዘት አይነትን ይገልፃል፣ በዚህ ሁኔታ ስርዓቱ የሚያስተዳድረው የእንስሳት እርሻን የሚወክል JSON ነገር ነው (ዱልሲና/ላም) . የአገልጋዩ ምላሽ የ HTTPS ሁኔታ ኮድ 201 በመላክ ጥያቄው የተሳካ እንደነበር ያሳያል (ምንጭ ተፈጠረ)። የGET ዘዴ በዩአርአይ ውስጥ የተጠየቀውን ግብአት ብቻ መግለጽ አለበት (ለምሳሌ፡/እርሻ/እንስሳት/1)፣ ይህም የእንስሳትን JSON ውክልና በዚያ መታወቂያ ከአገልጋዩ ይመልሳል።

የPUT ዘዴ ጥቅም ላይ የሚውለው የተወሰኑ የንብረት መዛግብት መዘመን ሲያስፈልግ ነው። በዚህ አጋጣሚ ሀብቱ ዩአርአይ ለየመለኪያው መቀየር እና አሁን ያለውን ዋጋ ይገልጻል (ለምሳሌ ላም በአሁኑ ጊዜ እየተራመደች መሆኑን ያሳያል፣ /እርሻ/እንስሳት/1? ግዛት=መራመድ)። በመጨረሻም የ DELETE ዘዴ ከ GET ዘዴ ጋር እኩል ጥቅም ላይ ይውላል, ነገር ግን በቀዶ ጥገናው ምክንያት ሀብቱን በቀላሉ ይሰርዛል.

MQTT እንደ ነጠላ ፕሮቶኮል መፍትሄ

ተመሳሳዩን ዘመናዊ እርሻ እንውሰድ፣ ነገር ግን ከREST HTTP ይልቅ የMQTT ፕሮቶኮልን እንጠቀማለን። የወባ ትንኝ ቤተ-መጽሐፍት የተጫነ የሀገር ውስጥ አገልጋይ እንደ ደላላ ይሰራል። በዚህ ምሳሌ፣ ቀላል ኮምፕዩተር (የእርሻ አገልጋይ ተብሎ የሚጠራው) Raspberry Pi እንደ MQTT ደንበኛ ሆኖ ያገለግላል፣ በ Paho MQTT ቤተመፃህፍት መጫኛ በኩል የሚተገበረው፣ ከMosquitto ደላላ ጋር ሙሉ ለሙሉ የሚስማማ።

ይህ ደንበኛ የዳሰሳ እና የማስላት ችሎታ ያለው መሳሪያን ከሚወክል የአይኦቲ ማጠቃለያ ንብርብር ጋር ይዛመዳል። ሸምጋዩ በበኩሉ ከከፍተኛ የአብስትራክሽን ደረጃ ጋር ይዛመዳል፣ ይህም በከፍተኛ የማቀነባበር እና የማጠራቀሚያ አቅም ተለይቶ የሚታወቅ የጭጋግ ማስላት መስቀለኛ መንገድን ይወክላል።

በታቀደው የስማርት እርሻ ሁኔታ ውስጥ፣ Raspberry Pi ከአክስሌሮሜትር፣ ጂፒኤስ እና የሙቀት ዳሳሾች ጋር ይገናኛል እና ከእነዚህ ዳሳሾች ወደ ጭጋግ ኖድ ያትማል። እንደሚያውቁት፣ MQTT ርዕሶችን እንደ ተዋረድ ይመለከታቸዋል። አንድ ነጠላ MQTT አታሚ ለተወሰኑ የርእሶች ስብስብ መልዕክቶችን ማተም ይችላል። በእኛ ሁኔታ ሦስቱ አሉ. በእንስሳት ጎተራ ውስጥ ያለውን የሙቀት መጠን የሚለካ ዳሳሽ ደንበኛው ጭብጥ (የእንስሳት እርባታ/ቤት/ሙቀት) ይመርጣል። የጂፒኤስ አካባቢን እና የእንስሳትን እንቅስቃሴ በፍጥነት መለኪያ ለሚለኩ ዳሳሾች ደንበኛው ወደ (የእንስሳት እርሻ/እንስሳ/ጂፒኤስ) እና (የእንስሳት እርባታ/እንስሳ/እንቅስቃሴ) ማሻሻያዎችን ያትማል።

ይህ መረጃ ለደላላው ይተላለፋል፣ ሌላ ፍላጎት ያለው ተመዝጋቢ በኋላ ላይ ቢመጣ ለጊዜው በአካባቢያዊ የውሂብ ጎታ ውስጥ ሊያከማች ይችላል።

በጭጋግ ውስጥ እንደ MQTT ደላላ ሆኖ ከሚሰራው እና Raspberry Pis እንደ MQTT ደንበኛ ሆኖ ሴንሰር ዳታ የሚልክበት ከሀገር ውስጥ አገልጋይ በተጨማሪ በደመና ደረጃ ሌላ MQTT ደላላ ሊኖር ይችላል። በዚህ አጋጣሚ ለአካባቢው ደላላ የተላለፈው መረጃ ለጊዜው በአካባቢው የውሂብ ጎታ ውስጥ ሊከማች እና/ወይም ወደ ደመናው ሊላክ ይችላል። በዚህ ሁኔታ ውስጥ ያለው ጭጋግ MQTT ደላላ ሁሉንም መረጃዎች ከደመናው MQTT ደላላ ጋር ለማያያዝ ይጠቅማል። በዚህ አርክቴክቸር የሞባይል መተግበሪያ ተጠቃሚ ለሁለቱም ደላላዎች መመዝገብ ይችላል።

ከአንዱ ደላላ (ለምሳሌ ደመና) ጋር ያለው ግንኙነት ካልተሳካ የመጨረሻው ተጠቃሚ ከሌላው (ጭጋግ) መረጃ ይቀበላል። ይህ የተዋሃዱ ጭጋግ እና የደመና ማስላት ስርዓቶች ባህሪይ ነው። በነባሪ የሞባይል አፕሊኬሽኑ መጀመሪያ ከጭጋግ MQTT ደላላ ጋር እንዲገናኝ ሊዋቀር ይችላል፣ ያ ካልተሳካ ደግሞ ከደመናው MQTT ደላላ ጋር ለመገናኘት ሊዋቀር ይችላል። ይህ መፍትሔ በ IoT-F2C ስርዓቶች ውስጥ ከብዙዎች ውስጥ አንዱ ብቻ ነው.

ባለብዙ ፕሮቶኮል መፍትሄዎች

ነጠላ ፕሮቶኮል መፍትሄዎች በቀላል አተገባበር ምክንያት ተወዳጅ ናቸው. ነገር ግን በ IoT-F2C ስርዓቶች ውስጥ የተለያዩ ፕሮቶኮሎችን ማዋሃድ ምክንያታዊ እንደሆነ ግልጽ ነው. ሀሳቡ የተለያዩ ፕሮቶኮሎች በተለያዩ ደረጃዎች ሊሠሩ ይችላሉ. ለምሳሌ ሶስት ማጠቃለያዎችን እንውሰድ፡ የአይኦቲ ንብርብሮች፣ ጭጋግ እና ደመና ማስላት። በ IoT ደረጃ ላይ ያሉ መሳሪያዎች በአጠቃላይ ውስን እንደሆኑ ይቆጠራሉ። ለዚህ አጠቃላይ እይታ፣ የአይኦቲ ደረጃዎችን በጣም የተገደበ፣ በትንሹ የተገደበ፣ እና ጭጋግ ማስላትን እንደ “በመካከል ያለ ቦታ” እንይ። በዚያን ጊዜ በ IoT እና በጭጋግ ማጠቃለያዎች መካከል የወቅቱ የፕሮቶኮል መፍትሄዎች MQTT ፣ CoAP እና XMPP ያካትታሉ። በጭጋግ እና በደመና መካከል ፣ በሌላ በኩል ፣ AMQP ከ REST HTTP ጋር ጥቅም ላይ ከሚውሉት ዋና ፕሮቶኮሎች አንዱ ነው ፣ ይህም በተለዋዋጭነቱ ምክንያት በአዮቲ እና በጭጋግ ንብርብሮች መካከልም ጥቅም ላይ ይውላል።

እዚህ ያለው ዋናው ችግር የፕሮቶኮሎች መስተጋብር እና መልእክቶችን ከአንድ ፕሮቶኮል ወደ ሌላ ለማስተላለፍ ቀላልነት ነው. በሐሳብ ደረጃ፣ ወደፊት፣ የበይነመረብ ነገሮች ሥርዓት ከዳመና እና ጭጋግ ሀብቶች ጋር ያለው አርክቴክቸር ጥቅም ላይ ከሚውለው የግንኙነት ፕሮቶኮል ነፃ ሆኖ በተለያዩ ፕሮቶኮሎች መካከል ጥሩ መስተጋብር እንዲኖር ያስችላል።

ይህ በአሁኑ ጊዜ ስላልሆነ, ጉልህ ልዩነት የሌላቸውን ፕሮቶኮሎች ማዋሃድ ምክንያታዊ ነው. ለዚህም፣ አንድ መፍትሄ ሊሆን የሚችለው ተመሳሳይ የስነ-ህንፃ ዘይቤ በሚከተሉ ሁለት ፕሮቶኮሎች ጥምረት ላይ የተመሠረተ ነው REST HTTP እና CoAP። ሌላው የታቀደው መፍትሔ የህትመት-ደንበኝነት ግንኙነትን MQTT እና AMQP በሚያቀርቡ ሁለት ፕሮቶኮሎች ጥምረት ላይ የተመሰረተ ነው። ተመሳሳይ ፅንሰ-ሀሳቦችን መጠቀም (ሁለቱም MQTT እና AMQP ደላላዎችን ይጠቀማሉ፣ CoAP እና HTTP REST ይጠቀማሉ) እነዚህን ውህዶች ለመተግበር ቀላል ያደርጋቸዋል እና አነስተኛ የውህደት ጥረት ይጠይቃል።

ምስል (ሀ) በጥያቄ-ምላሽ ላይ የተመሰረቱ ሁለት ሞዴሎችን፣ ኤችቲቲፒ እና ኮኤፒን እና በአዮቲ-ኤፍ2ሲ መፍትሄ ውስጥ ሊቀመጡ የሚችሉበትን ሁኔታ ያሳያል። ኤችቲቲፒ በዘመናዊ አውታረ መረቦች ውስጥ በጣም ታዋቂ እና ተቀባይነት ካላቸው ፕሮቶኮሎች አንዱ ስለሆነ፣ ሙሉ በሙሉ በሌሎች የመልእክት መላላኪያ ፕሮቶኮሎች ይተካል ተብሎ አይታሰብም። በደመና እና በጭጋግ መካከል ተቀምጠው ኃይለኛ መሳሪያዎችን ከሚወክሉ አንጓዎች መካከል REST HTTP ብልጥ መፍትሄ ነው።

በሌላ በኩል፣ በ Fog እና IoT ንብርብሮች መካከል ለሚግባቡ ውስን የኮምፒውተር ሃብቶች ላላቸው መሳሪያዎች፣ CoAPን መጠቀም የበለጠ ቀልጣፋ ነው። ሁለቱም ፕሮቶኮሎች በREST መርሆዎች ላይ የተመሰረቱ በመሆናቸው ከCoAP ትልቅ ጠቀሜታዎች አንዱ ከኤችቲቲፒ ጋር ያለው ተኳሃኝነት ነው።

ምስል (ለ) MQTT እና AMQPን ጨምሮ ሁለት የህትመት-ደንበኝነት ተመዝጋቢ የግንኙነት ሞዴሎችን በተመሳሳይ ሁኔታ ያሳያል። ምንም እንኳን ሁለቱም ፕሮቶኮሎች በግምታዊ ሁኔታ በእያንዳንዱ የአብስትራክሽን ንብርብር ውስጥ ባሉ አንጓዎች መካከል ለመገናኛ ጥቅም ላይ ሊውሉ ቢችሉም ፣ ቦታቸው በአፈፃፀም ላይ በመመስረት መወሰን አለበት። MQTT የተነደፈው ውስን የኮምፒዩተር ግብዓቶች ላላቸው መሣሪያዎች እንደ ቀላል ክብደት ፕሮቶኮል ነው፣ ስለዚህ ለአይኦቲ-ፎግ ግንኙነት ሊያገለግል ይችላል። AMQP ለበለጠ ኃይለኛ መሳሪያዎች ይበልጥ ተስማሚ ነው፣ ይህም በጭጋግ እና በደመና ኖዶች መካከል ያስቀምጠዋል። ከMQTT ይልቅ የXMPP ፕሮቶኮል ቀላል ክብደት ስላለው በአዮቲ ውስጥ ጥቅም ላይ ሊውል ይችላል። ነገር ግን በእንደዚህ ዓይነት ሁኔታዎች ውስጥ በሰፊው ጥቅም ላይ አይውልም.

ግኝቶች

ከተወያዩት ፕሮቶኮሎች አንዱ በሲስተሙ ውስጥ ያሉትን ሁሉንም የኮምፒዩተር ሃብቶች ካላቸው መሳሪያዎች አንስቶ እስከ ክላውድ ሰርቨሮች ድረስ ያለውን ግንኙነት ለመሸፈን በቂ ይሆናል ተብሎ አይታሰብም። ጥናቱ እንደሚያሳየው ገንቢዎች በብዛት የሚጠቀሙባቸው ሁለቱ በጣም ተስፋ ሰጪ አማራጮች MQTT እና RESTful HTTP ናቸው። እነዚህ ሁለት ፕሮቶኮሎች በጣም የበሰሉ እና የተረጋጉ ብቻ አይደሉም, ነገር ግን ብዙ በደንብ የተመዘገቡ እና የተሳካላቸው አተገባበር እና የመስመር ላይ ግብዓቶችን ያካትታሉ.

በተረጋጋ እና ቀላል ውቅር ምክንያት MQTT በ IoT ደረጃ ከተወሰኑ መሳሪያዎች ጋር ጥቅም ላይ ሲውል በጊዜ ሂደት የላቀ አፈፃፀሙን ያረጋገጠ ፕሮቶኮል ነው. እንደ አንዳንድ የጭጋግ ጎራዎች እና አብዛኛው የደመና ኮምፒዩቲንግ ያሉ የተገደበ የመገናኛ እና የባትሪ ፍጆታ ችግር በማይኖርበት የስርአቱ ክፍሎች ውስጥ፣ RESTful HTTP ቀላል ምርጫ ነው። CoAP እንዲሁ በፍጥነት እንደ አይኦቲ የመልእክት መላላኪያ ደረጃ እያደገ በመሆኑ እና በቅርብ ጊዜ ውስጥ እንደ MQTT እና HTTP ተመሳሳይ የመረጋጋት እና የብስለት ደረጃ ላይ ሊደርስ ስለሚችል ግምት ውስጥ መግባት አለበት። ነገር ግን መስፈርቱ በአሁኑ ጊዜ እያደገ ነው, ይህም ከአጭር ጊዜ የተኳሃኝነት ጉዳዮች ጋር ነው.

በብሎግ ላይ ሌላ ምን ማንበብ ይችላሉ? Cloud4Y

→ ኮምፒዩተሩ ጣፋጭ ያደርግልዎታል
→ AI የአፍሪካን እንስሳት ለማጥናት ይረዳል
→ ክረምት ሊያልቅ ነው። ያልተለቀቀ ውሂብ የለም ማለት ይቻላል።
→ በደመና መጠባበቂያዎች ላይ ለማስቀመጥ 4 መንገዶች
→ ስለህዝቡ መረጃን በያዘ የተዋሃደ የፌዴራል የመረጃ ምንጭ ላይ

የእኛን ይመዝገቡ ቴሌግራምየሚቀጥለውን ጽሑፍ እንዳያመልጥዎት - ቻናል! በሳምንት ከሁለት ጊዜ ያልበለጠ እና በንግድ ስራ ላይ ብቻ እንጽፋለን.

ምንጭ: hab.com