سرویس داده IoT از سرویس داده | An IoT Middleware of Data Service جدول مقالات آزادابزار تفکیک و ترجمه متون علمیمقالات اینترنت اشیاء
تماس با ما
 
بدان
 
امروز دوشنبه ، ۱۴۰۰/۰۹/۱۵
 
کلیه مقالات

سرویس داده IoT از سرویس داده

An IoT Middleware of Data Service

سرویس داده IoT از سرویس داده:

خلاصه :

با توسعه اینترنت اشیاء (IoT) ، تعداد دستگاهها و سنسورهای متصل به اینترنت به میزان قابل توجهی افزایش یافته است.

در این میان ، ارزش داده و سرویس داده در بسیاری از زمینه ها اهمیت فزاینده ای پیدا می کند.

اما حجم زیادی از داده ها در اینترنت اشیاء نیز برای قالب بندی متنوع داده ها و پروتکل های مختلف دستگاه های مختلف ، مسائل زیادی را به وجود می آورد.

بنابراین لازم است یک راه حل برای محافظت از ناهمگونی پیدا شود.

در این مقاله ، ما یک میان افزار عمومی را طراحی و پیاده سازی می کنیم که می تواند اکثر دستگاه ها را در IoT به دلیل "استخرهای مجازی" و "آداپتور پروتکل" به یکدیگر وصل کند.

تمام دستگاه ها و سیستم های خارجی برای حذف ناهمگونی قالب داده در "اشخاص مجازی" انتزاع می شوند.

Entity Pool برای ذخیره ، مدیریت و نگهداری از آن اشخاص مجازی استفاده می شود.

Middleware فراخوانی سرویس را برای برنامه فوقانی فراهم می کند و از درک پویا و کشف سرویس داده IOT پشتیبانی می کند ، و مکانیزمی را برای استخراج مقدار کلیدی از داده های گسترده برای فیلتر کردن افزونگی طراحی می کند.

این مقاله نتایج تجربی را برای نشان دادن عملکرد خوب و کاربرد نرم افزارهای میانی ارائه می دهد.

مقدمه :

در چند سال گذشته اینترنت اشیا (IoT) محبوبیت بیشتری پیدا کرد.

بسیاری از برنامه ها مانند خانه هوشمند و شهر هوشمند توسعه یافته اند.

با این حال ، دستگاه های تولید شده توسط تولید کنندگان مختلف به دلیل عدم وجود استانداردهای یکپارچه ناهمگن هستند.

بنابراین ، میان افزار برای اتحاد این دستگاه های ناهمگن ایجاد شده است.

اما برخی از وسایل واسط بدون کاربرد کافی منبع باز نیست.

برخی دیگر خیلی بسته هستند تا سایر وسایل بهتر را در میان افزار خود درگیر کنند.

و دیگران ممکن است برای حل یک مشکل درست ثابت توسعه یافته باشند ، که نمی تواند در زمینه های دیگر گسترش یابد.

در این مقاله ، ما برای حل این معضل ، یک واسطه کلی خدمات داده پیشنهاد می کنیم.

با ایجاد مدل "موجودیت مجازی" برای هر دستگاه متصل به واسطه می تواند برخی از کارکردهای اساسی را برای محافظت از ناهمگونی فراهم کند.

و ما از "مجموعه موجودیت" برای ذخیره ، مدیریت و نگهداری آن اشخاص مجازی استفاده می کنیم.

همچنین ، "استخر نهاد" کلیه خدمات ارائه شده توسط دستگاههایی را برای درخواست فوقانی ارائه می دهد.

از این گذشته ، ما مکانیسمی را برای فیلتر کردن داده های بی فایده و زائد برای بهبود عملکرد آن طراحی کرده ایم.

هنگامی که یک پروتکل جدید به وجود می آید ، کاربران می توانند به راحتی و با ثبت و تولید آداپتور پروتکل ، میان افزار را به روز کنند تا بتوانیم موجودیت مجازی را برای آن ایجاد کنیم.

این فرآیند روی سایر دستگاهها و برنامه فوقانی تأثیر نمی گذارد.

بر اساس میان افزار ، کاربران نیازی به مراقبت از دستگاه های اساسی و پروتکل دسترسی به داده های دستگاه های IoT ندارند ، تنها کاری که باید انجام دهند تمرکز روی کاربردهای منطقی و عملکردهای پردازش داده است.

در قسمت آخر این مقاله ، نتایج آزمایشگاهی برای نشان دادن عملکرد واسطه ارائه شده است.

این مقاله به شرح زیر برگزار می شود.

بخش دوم کارهای مرتبط را مرور می کند.

بخش سوم ، طراحی سیستم و اجرای واسط IoT را ارائه می دهد.

بخش چهارم اطلاعات دقیق در مورد فن آوری های کلیدی را ارائه می دهد.

بخش V میان افزار IoT را با چندین آزمایش ارزیابی می کند.

بخش ششم نتیجه گیری مقاله را ارائه می دهد.

دوم تحقیق مرتبط:

با توجه به محبوبیت اینترنت اشیا ، بسیاری از محققان به مطالعه جنبه هایی از جمله آگاهی از متن ، قابلیت همکاری در بین دستگاه های ناهمگن ، امنیت ، پردازش داده ها و برنامه های کاربردی میانی ، ساختار و استقرار اختصاص می دهند.

اگرچه ممکن است هدف از تحقیق متفاوت باشد ، اما برخی از ایده ها ما را روشن می کنند.

پدرو مایا [1] یک واسطه وب را برای اتصال پزشکان و بیماران پیشنهاد کرد.

این بستر داده های سنسورهای ناهمگن بدن بیمار را یکپارچه می کند تا بتواند وضعیت بیمار را در زمان واقعی کنترل کند.

طبق ادبیات [2] ، یک واسطه به نام REACTION برای حل چندین استاندارد در پرونده های بهداشتی طراحی شده است.

در [3] ، سرویس های میان افزار ابری برای محاسبه تاخیر در انتقال داده ، محاسبات ابری را به واسطه میان افزار ترکیب می کنند.

Lomotey یک واسطه را برای حل قابلیت همکاری IoT بر اساس M2I و M2M ارائه می دهد [4].

یک روش بهینه استقرار میان افزار در [5] مورد مطالعه قرار گرفته است ، که قوی و مقرون به صرفه است.

جی سینگ [6] بر روی پیش زمینه واسطه در زمینه بهداشت تمرکز دارد و یک واسطه به نام SBUS طراحی می کند تا منطق و استراتژی های برنامه را جدا کند.

جون جوان کیم معماری امن اینترنت اشیا را مطالعه کرده است [7].

علاوه بر این ، Mangal Sain [8] در مورد ایده تقسیم میان افزار به دو لایه ، که میان افزارهای سطح پایین و واسطه متوسط ​​سطح بالا هستند ، بحث می کند.

واسط سطح پایین پایین بین گره های حسگر مختلف ، داده های خام و برنامه های آنها وجود دارد.

میان افزار سطح بالا برای تبادل داده بین برنامه های مختلف استفاده می شود.

این یک ایده خوب است که به ما در طراحی واسطه کمک می کند.

ICSI M2M [9] با هدف حل مشکل سیستمهای ناهمگن و محدودیت منابع در زمینه حمل و نقل هوشمند با روش پیکربندی مجدد منابع انجام شده است.

[10] برای جمع آوری داده ها ، مدل سازی و استنباط زمینه های مربوط به داده های سنسور ، به منظور درک داده های سنسور توسط محاسبات آگاه از متن ، حل می کند.

چارچوبی به نام ACCADA [11] ارائه شده است تا سیستم بتواند با محیط متغیر سازگار شود.

Sudipto Guha [12] یک الگوریتم جریان کارآمد را برای حل مشکل انواع مختلف داده با مقدار کمی حافظه توصیف می کند ، که می تواند به بهبود عملکرد سیستم کمک کند.

یک زبان پرس و جو به نام SyncSQL معرفی شده است [13] ، و نویسنده الگوریتم مطابق با پرس و جو با عملکرد بالا را ارائه می دهد.

داگلاس [14] هنگامی که داده های ثابت به پایگاه داده جریان می یابد ، مشکل پرس و جو را حل می کند.

یک روش جدید فشرده سازی داده ها [15] بر اساس سه پارامتر ارائه شده است ، پارامترها عبارتند از نسبت فشرده سازی ، سربار و زمان.

بنابراین با هدف تعادل پارامترها برای دستیابی به یک راه حل بهینه انجام می شود.

برخی تحقیقات که در بالا به آنها اشاره کردیم مبتنی بر معماری متمرکز است.

علاوه بر این ، برخی از واسطه ها قابلیت پردازش داده ندارند.

و بعضی از واسطه ها بدون جهانی بودن ، برای تبلیغ مناسب نیستند.

مهمتر از همه ، ما معتقدیم که پشتیبانی از داده های زمان واقعی بسیار مهم است.

در پس زمینه داده های بزرگ ، به منظور بهبود عملکرد سیستم و کاهش تنگناهای ناشی از پردازش و ذخیره سازی داده ها ، ما از یک معماری میان افزار توزیع شده استفاده می کنیم و در مورد نحوه پشتیبانی از دستگاه های ناهمگن به تفصیل توضیح می دهیم.

ما همچنین لایه اتوبوس پیام را برای فیلتر کردن داده ها و رسیدگی به پیام ها طراحی کرده ایم.

علاوه بر این ، برنامه بالا می تواند با تعامل با لایه سرویس داده ، داده های زمان واقعی را با توجه به نیازهای خود بدست آورد.

III. طراحی سیستم:

در فرآیند طراحی این وسط ، ناهمگونی ، اتصال کم ، مقیاس پذیری ، پایداری و عملی را در نظر گرفته ایم.

دستگاه ها و پروتکل های مختلف فیزیکی باید در نظر گرفته شود.

واسطه می تواند از اضافه کردن پروتکل ها و دستگاه های جدید پشتیبانی کند.

در ضمن ، باید یک سرویس داده مناسب برای برنامه فوقانی از قبیل فیلتر کردن داده ، تبدیل داده ارائه دهد.

اینها ملاحظات اصلی ما در طراحی است.

الف) معماری سطح بالا:

این سیستم از سه لایه ، لایه دستگاه ، لایه فیلتر و پردازش داده ها و لایه سرویس داده تشکیل شده است.

هنگامی که یک دستگاه خارجی جدید می خواهد داده ها را به میان افزار متصل کند و ارسال کند ، باید پروتکل آن در ماژول ثبت پروتکل ثبت شود تا واسطه بتواند آن را تشخیص دهد.

هنگامی که یک دستگاه ثبت شده داده را به میان افزار ارسال می کند ، ابتدا به لایه زیرین میان افزار (لایه دستگاه) ارسال می شود ، و لایه دستگاه پروتکل جریان داده را با اطلاعات کلیدی خود مانند پیشوند آن تشخیص می دهد.

سپس میان افزار در استخر موجودیت جستجو می کند تا ببیند موجودیت مربوطه وجود دارد یا خیر.

در این صورت ، نهاد مجازی توسط آداپتور پروتکل مربوطه ساخته می شود و در استخر قرار می گیرد.

سپس نهاد مجازی جریان داده را تجزیه و تحلیل کرده و نتیجه را به لایه فیلتر و پردازش داده ارسال می کند که با هدف فیلتر کردن داده ها و تبدیل داده های ناهمگن به قالب یکپارچه انجام می شود.

با کار کردن لایه فیلتر و پردازش داده ها ، لایه سرویس داده ها نیازی به مراقبت از داده های بی ارزش و قالب متفاوت داده ها ندارند و این لایه می تواند به طور مستقیم از خدمات ارائه شده توسط نهاد موجودیت تماس بگیرد.

هنگامی که دستور از برنامه بالا به این لایه می آید ، به قالب مربوطه تبدیل می شود که توسط دستگاه هدف قابل درک است.

لایه سرویس داده ها یک رابط یکپارچه برای چندین سیستم فشار را محاسبه می کند.

به این ترتیب ، هر لایه وظیفه کار خود را دارد.

شکل 1 معماری سیستم سطح بالا از واسطه IoT ما را نشان می دهد.

B. ساختار مدولار:

همانطور که در شکل 2 نشان داده شده است ، ماژول اصلی لایه دستگاه شامل یک ماژول مدیریت اتصال ، ماژول ثبت پروتکل ، ماژول آداپتور ، ماژول موتور موجودیت مجازی ، ماژول استخر موجودیت و غیره است.

دستگاه های گسترده ای در اینترنت اشیا وجود دارد.

دستگاه ها و دروازه های ناهمگن تعداد زیادی درخواست اتصال به میان افزار ارسال می کنند.

بنابراین ماژول مدیریت اتصال برای مقابله با آن درخواست ها طراحی شده است.

با توجه به عدم ثبات ممکن است ارتباط قطع شود.

این ماژول یک استخر بافر برای از بین بردن روند دوباره سازگاری و بازسازی فراهم می کند ، که می تواند عملکرد سیستم را بهبود بخشد.

برای محافظت از ناهمگونی دستگاه های زیرین ، ما ماژول آداپتور را طراحی می کنیم تا به صورت پویا یک آداپتور برای هر دستگاه ناهمگن یا دروازه اختصاص دهیم.

این به دستیابی به هدف اقتباس خودکار کمک می کند.

ماژول آداپتور مانند کارخانه ای است که برای یافتن و تولید آداپتورها کار می کند.

از آنجا که دستگاه های فیزیکی تولید کنندگان مختلف پروتکل های مختلفی برای ارتباط داده ها دارند ، پروتکل مشخص شده باید در انبار پروتکل ثبت و ذخیره شود تا بتواند داده های دستگاه های ناهمگن را تجزیه کند و فرمان را به درستی محصور کند.

ماژول ثبت نام پروتکل برای دستیابی به این هدف طراحی شده است.

ماژول موتور موجودیت مجازی یک جزء اصلی واسطه است.

ما برای همه دستگاه ها مدلی را به نام "موجودیت مجازی" ایجاد می کنیم تا همه دستگاه های ناهمگن بتوانند راحت تر با یکدیگر ارتباط برقرار کنند.

و موتور موجودیت مجازی می تواند یک واحد مجازی مربوطه را برای هر دستگاه متصل به میان افزار ایجاد کند.

مدل موجودیت مجازی شامل آداپتور و برخی خصوصیات مهم دیگر برای کمک به تبادل داده و کشف دستگاه است.

داده های بارگذاری شده توسط دستگاه های ناهمگن را تجزیه می کند و آن را در قالب یکپارچه برای لایه بالایی کپی می کند.

به طور مشابه ، دستورالعمل های ارسال شده توسط لایه فوقانی محصور شده و به دستگاه ناهمگن مربوطه ارسال می شوند.

از آنجایی که ما برای هر دستگاه متصل ، یک نهاد مجازی ایجاد می کنیم ، تعداد زیادی موجودیت در سیستم وجود خواهد داشت تا بر عملکرد آن تأثیر بگذارد.

بنابراین ما ماژول استخر موجودیت را برای مدیریت پویا آن اشخاص طراحی می کنیم.

ماژول همه موجودات را ادغام می کند و لیست و منبع و خدمات را برای تماس با لایه بالایی فراهم می کند.

تمام داده های دستگاه های زیرین از طریق مجموعه موجودیت به شکل موجودیت مجازی به لایه فیلتر و پردازش داده ها منتقل می شوند.

این لایه شامل موتور فیلتر و پردازش داده ها ، صف بافر پیام است.

IoT تعداد زیادی دستگاه دارد و هر دستگاه در طی یک مدت زمان تعداد زیادی داده تولید می کند.

بنابراین پردازش داده های زیادی برای سیستم بسیار سخت است.

برای کاهش استرس سیستم ، میان افزار باید داده های موجود در صف بافر پیام را ذخیره کند.

و آن داده های بارگذاری شده معمولاً از ارزش کم و کاربری اضافی برخوردار هستند ، بنابراین موتور فیلتر و پردازش داده ها پیام هایی را از صف استخراج کرده و داده های غیر طبیعی را از بین می برد.

آستانه عادی داده ها در پرونده قانون اخطار تعریف شده است.

همچنین موتور می تواند داده های متوسط ​​، حداکثر و حداقل را برای مدت زمانی محاسبه کند تا خدمات داده ای را برای لایه بالایی ارائه دهد.

داده ها در این مدت با سه مقدار مهم نشان داده می شوند.

به این ترتیب داده ها فیلتر شده و عملکرد سیستم بدون از دست دادن داده های ارزشمند بهبود می یابد.

چهارم فن آوری های کلیدی:

نکات کلیدی میان افزار ما مدل "موجودیت مجازی" ، مکانیسم حل پروتکل ، فیلتر داده ها و اشتراک پیام و فشار است.

بنابراین ما آنها را برای جزئیات بیشتر در این بخش شرح می دهیم.

A. استخر مجازی و شخص حقیقی:

همانطور که در بالا به آن اشاره کردیم ، تمام دستگاههای متصل به میان افزار موجودیت مجازی مربوطه ساخته می شوند.

مجموعه ای از مکانیسم کشف و مدیریت دستگاه به کار گرفته شده است که کلیه اشخاص فیزیکی را در "اشخاص مجازی" مجازی می کند و آنها را در "استخر موجودیت پویا" نگهداری می کند.

استخر موجودیت نقشه برداری از اشخاص مجازی را به دستگاههای فیزیکی حفظ می کند.

و به عنوان کانتینر موجودیت های مجازی ، "مجموعه موجودیت" خدمات داده ای را ارائه می دهد که شامل روش فراخوانی و کشف دستگاه است.

ساختار آنها در شکل 3 نشان داده شده است:

1) نهاد مجازی:

موجودیت مجازی نقشه برداری از موجودیت بدنی در دنیای واقعی است. ما می توانیم یک موجودیت فیزیکی را از طریق نهاد مجازی مربوطه پیدا کنیم.

تعریف رسمی یک نهاد مجازی در فرمول (1) نشان داده شده است:

ve = (entitId، onlineStatus، tag، adaptor) (1) موجودیت مجازی چهار ویژگی اصلی دارد:

شناسه موجودات موجودات را از يكديگر تشخيص مي دهد. "وضعیت آنلاین" به معنای دستیابی به موجودیت توسط بستر میان افزار است. "برچسب" برای کشف خدمات استفاده می شود. "آداپتور" حاوی منابع مربوط به آداپتورهای پروتکل مرتبط است.

- شناسه شخص:

شناسه موجودات موجودات را از یکدیگر مشخص می کند.

رمزگذاری مختصر همانطور که در فرمول (2) نشان داده شده است تعریف می شود:

V irtualEntityId = ExtraIndex + ProtocolId (2) "ExtraIndex" شماره دنباله است که وقتی نهاد مجازی به "استخر موجودیت" اضافه می شود (128 بیتی). "ProtokId" تعداد پروتکل مورد استفاده (32 بیتی) است.

از آنجا که "ExtraIndex" هرگز کاهش نمی یابد (شماره توالی پس از ورود به سیستم مورد استفاده مجدد قرار نخواهد گرفت) ، می توان منحصر به فرد بودن شناسه موجودیت مجازی را تضمین کرد.

#NAME?

با توجه به اینکه بعضی اوقات شبکه ممکن است ناپایدار باشد ، ممکن است وسط وسایل نرم افزاری مرتباً وضعیت دستگاه ها را تغییر داده و منجر به عملکرد کم سیستم شود.

بنابراین ما سازوکاری را طراحی می کنیم تا موجودیت مجازی خودش وضعیت آنلاین را حفظ کند.

#NAME?

آنها توصیف متنی از دستگاه های فیزیکی یا خدمات متصل به میان افزار هستند که می توانند در حین جستجو با کلمه کلیدی مطابقت داشته باشند.

انواع اطلاعات را می توان با برچسب ، مانند نوع داده ، مکان ، اطلاعات خاص کاربر و غیره ذخیره کرد.

ما از Tag (X) برای شناسایی برچسب موجودیت مجازی X استفاده می کنیم.

اگر موجودیت مجازی A و B دارای برچسب های زیر است:

کلمات کلیدی ورودی برای جستجو عبارتند از:

كليد واژه = {Tag2 ، Tag4} ، موجوديت مجازي B به عنوان نتيجه جستجو بازگردانده مي شود.

#NAME?

ما اشخاص مجازی را به چهار دسته تقسیم می کنیم:

سنسورها ، کنترل کننده ها ، دروازه های هوشمند ، سیستم های خارجی / سرویس های ابری ، به ترتیب مربوط به بارگذاری داده ها ، دریافت داده ها ، ارتباط داده ها و پردازش داده ها.

سنسورها جریان داده ای را تولید می کنند که می تواند به دو دسته تقسیم شود:

وضعیت فعلی و "داده های تاریخی"

داده های تاریخی را می توان در بانک اطلاعاتی ذخیره کرد ، در حالی که "حالت فعلی" به طور مستقیم به عنوان یک ویژگی از موجودیت مجازی سنسور در مثال ذخیره می شود.

کنترل کننده ها دستورالعمل کنترل را دریافت می کنند ، مطابق دستورالعمل اقدامات مربوطه را انجام می دهند و نتیجه اجرای را برمی گردانند.

کنترل کننده ها "وضعیت فعلی" (مانند روشن / خاموش در سوئیچ هوشمند) را بدون "داده های تاریخی" دارند.

دروازه هوشمند گره ای از سنسورها و کنترل کننده های وابسته به آن است که در ارسال ، دریافت داده و مدیریت شبکه داخلی نقش ایفا می کند.

سیستمهای خارجی / سرویسهای ابری شامل کلیه سیستمهایی هستند که علاوه بر دستگاههای فیزیکی ممکن است با وسایل ارتباطی در تعامل باشند.

به جز چهار ویژگی اصلی که در بالا به آنها اشاره شد ، هر دسته از ویژگیهای خاص خود مانند حساسیت موجودیت مجازی سنسور برخوردار است.

شکل 4 نمونه ای از پرونده پیکربندی موجودیت مجازی حسگر در "JSON" است ، که دستگاه سنجش را با شناسه "intelledison.1726" نشان می دهد.

این پروتکل از "IntelEdison" استفاده می کند و با نظارت بر دمای اتاق نشیمن ، دارای حساسیت 0/0 می باشد ، این بدان معنی است که فقط در صورت تغییر مقدار از 0.5 بیشتر ، داده ها توسط واسطه پذیرفته می شوند.

این یکی از روش های فیلتر کردن داده های گسترده است.

2) استخر اشخاص:

استخر Entity جایی است که واسطه بین المللی تمام موجودات مجازی را ذخیره و نگهداری می کند.

مدل موجودیت مجازی از ساختار مشابهی برخوردار است و آداپتور مربوطه را در خود جای داده است تا بتواند ناهمگونی دستگاه ها را محافظت کند.

بنابراین ، هنگامی که یک ماژول سطح بالا می خواهد با یک دستگاه تعامل داشته باشد ، تنها نیاز به یافتن مجازی موجودیت خود در استخر موجودیت دارد بدون اینکه به وسیله فیزیکی ، پروتکل و آدرس فعلی یا سایر اطلاعات آن اهمیت دهد.

همچنین "استخر موجودیت" برای کمک به کشف دستگاه ، جدول نقشه برداری از همه اشخاص مجازی و دستگاههای فیزیکی مربوطه را در اختیار دارد.

B. قطعنامه پروتکل:

قبل از ایجاد یک موتور موجود در مجازی ، باید پروتکل مربوطه را قضاوت کنیم و آداپتور را مطابقت دهیم.

بنابراین ماژول اتصال و ماژول پروتکل برای میان افزار IoT مورد نیاز است.

همانطور که در شکل 5 نشان داده شده است ، هنگامی که یک دستگاه خارجی داده ها را به میان افزار ارسال می کند ، ماژول پروتکل باید قضاوت کند که آیا پروتکل در انبار پروتکل وجود دارد یا خیر.

معمولاً با پیشوند جریان داده ، پروتکل را قضاوت می کنیم.

اگر ثبت شده باشد ، موتور موتور مطابق پروتکل بسته های داده را با کمک آداپتور پروتکل مربوطه باز می کند.

سپس جریان داده قابل خواندن به لایه بالایی منتقل می شود.

بسته داده ارسال شده توسط دستگاههای IoT معمولاً دارای قالب مشابه است.

می توان آن را به دو بخش تقسیم کرد:

سر و DataField.

همانطور که در فرمول (5) نشان داده شده است:

فرمول (6) ترکیب سر را نشان می دهد.

سر اطلاعات دارای اطلاعات شناسایی بسته داده در نظر گرفته شده است.

معمولاً سر شامل شناسه پروتکل (protokId) ، طول جریان داده (طول داده) ، اطلاعات دستگاه (deviceId) و غیره می باشد.

در مورد dataField ، این شامل داده های معتبر انتقال است که در لایه بالایی مورد تجزیه و تحلیل قرار می گیرد.

بنابراین ماژول پروتکل می تواند پروتکل را توسط سر جریان داده تشخیص دهد.

برای مطابقت بیشتر پروتکل ، بیشتر پروتکل های مورد استفاده در اینترنت اشیاء را کشف می کنیم و آنها را در ساختار مشابه انتزاعی می کنیم تا بتوانیم به راحتی در انبار پروتکل جستجو کنیم.

ما آن پروتکل ها را به دو دسته اصلی تقسیم می کنیم:

نوع اول قالب انتقال داده را به وضوح ارائه می دهد.

این بدان معناست که معنای خاص هر فیلد در بسته داده کاملاً مشخص است.

دسته دوم کلیه عملکردهای تعامل داده را در "SDK" محصور می کند و رابط های مربوطه را برای تماس با کاربران فراهم می کند.

برای دو شکل مختلف پروتکل ، از دو نوع آداپتور استفاده می کنیم.

برای فرم اول ، عمده ترین تفاوت ها بین بسته های داده ورودی ، تقسیم بندی داده ها و قالب آنهاست.

پس از شناسایی بسته ورودی ، وسط افزار مطابق با نوع اتصال ، طول بسته و مشخصات آن (مانند پیشوند جریان داده) آداپتور مربوطه را پیدا می کند.

برای فرم دوم ، ما از فناوری JNI برای حذف تفاوت زبان برنامه نویسی استفاده می کنیم زیرا واسطه ما به زبان جاوا نوشته شده است اما برخی از "SDK" از زبان C ++ یا C استفاده می کنند.

هر دو آداپتور همان سطح رابط را برای سطح بالاتر پیاده سازی می کنند.

بنابراین می توانیم از یک روش واحد برای پیاده سازی هر آداپتور پروتکل بدون مراقبت از دسته آن استفاده کنیم.

از آنجا که در اینترنت اشیاء دستگاه ها و پروتکل های زیادی وجود دارد ، ما یک پرونده پیکربندی پروتکل را طراحی می کنیم که برای ضبط اطلاعات اصلی آداپتورهای پروتکل استفاده می شود.

بنابراین موتور تطبیق پروتکل می تواند به راحتی و با کمک فایل پیکربندی ، آداپتور هدف را به راحتی پیدا کند.

شکل 6 نمونه ای ساده از پرونده پیکربندی در قالب "JSON" است.

این بدان معنی است که هم اکنون میان افزار دارای دو آداپتور پروتکل با نام های "نانجین وولیان" و "IntelEdison" است.

آنها از نوع دیگری هستند.

NanjinWulian نوعی پروتکل "SDK" است (که در بالا به آن اشاره کردیم) و طول جریان داده آن 19 کیلوبایت با پیشوند "27dd4a" است که می توان پروتکل را تشخیص داد.

آداپتور مربوطه به نام "پروتکل نانجینولیان" نامگذاری شده است.

در میان افزار ، پروتکل دسته اول را به عنوان نوع پیش فرض می گیریم.

ج - فیلتر اطلاعات:

هر دستگاهی در IoT قصد دارد داده ها را در میان افزار خود جمع آوری و بارگذاری کند تا بتوانیم وضعیت را بطور دقیق و به موقع بدست آوریم.

بنابراین میان افزار ما باید قادر به پردازش حجم عظیمی از داده ها باشد.

و درمی یابیم که برخی داده ها برای یک دوره زمانی پایدار هستند.

بنابراین ما یک مکانیزم برای استخراج مقدار کلیدی برای فیلتر کردن داده های تکراری طراحی می کنیم.

ما برای انواع مختلفی از خواص ، آستانه مختلفی را تعیین می کنیم.

معمولاً اولین مورد از لیست داده ها به عنوان اولین مقدار کلیدی گرفته می شوند ، و مورد داده ای که مقدار مطلق اختلاف آن از مقدار آستانه پایین تر است ، به عنوان یک مورد اضافی در نظر گرفته می شود.

داده داده بزرگتر از مقدار آستانه به یک مقدار کلیدی جدید تبدیل می شود.

به منظور ارزیابی عملکرد ، ما از خطای دامنه (AE) و میزان فشرده سازی (CR) استفاده می کنیم تا دقت و محاسبه داده ها را به طور جداگانه اندازه گیری کنیم.

AE اندازه گیری شباهت بین دنباله داده است که در واقع توسط واسطه میانی (به عنوان دنباله واقعی) به دست آمده و دنباله تولید شده پس از فشرده سازی زائد (به عنوان دنباله بازیابی) بدست می آید.

هرچه مقدار AE کوچکتر باشد ، دقت بازیابی بعد از فشرده سازی داده ها نیز بالاتر می رود.

فرض کنید یک دنباله واقعی وجود دارد IList = u1، u2،. . . ، un ، و ui ماده اول IList است.

و دنباله بازیابی RList = v1، v2،. . . vn ، vi مورد اول RList است.

بنابراین AE از آنها می تواند با فرمول (7) محاسبه شود.

CR یک اندازه گیری از فشرده سازی دنباله واقعی و دنباله فشرده شده از بین برنده (به عنوان دنباله فشرده شده نامیده می شود).

هرچه مقدار CR کمتر باشد ، میزان فشرده سازی داده ها بیشتر می شود.

فرض کنید یک دنباله واقعی وجود دارد IList = u1، u2،. . . سازمان ملل متحد ، و ui ماده اول IList است.

و دنباله فشرده شده CList = v1، v2،. . . vm ، vi موردی i1 از CList و m از n بزرگتر نیست.

بنابراین CR را می توان با فرمول (8) محاسبه کرد.

AE و CR یک جفت از شاخص های متناقض هستند که نمی توانیم باعث شود هر دو در یک زمان کمترین ارزش را داشته باشند.

اگر تمام داده های دنباله واقعی کاملاً حفظ شود ، از دنباله واقعی به عنوان دنباله فشرده سازی استفاده می شود ، سپس AE حداقل مقدار 0 را می گیرد و در این زمان CR به حداکثر مقدار 1 می رسد؛ اگر همه مقادیر در دنباله واقعی دور ریخته شوند ، از توالی خالی به عنوان دنباله فشرده سازی استفاده می شود ، سپس CR حداقل مقدار 0 را می گیرد و AE حداکثر مقدار است.

بنابراین آستانه مربوطه را با توجه به وضعیت واقعی تنظیم می کنیم.

به عنوان نمونه از درجه حرارت استفاده كنید ، فقط هنگامی كه دامنه تغییر از بیش از 0/5 درجه باشد بدیهی است كه انسان می تواند حس كند.

علاوه بر این ، به منظور ارائه خدمات بهتر داده ، وسایل میانی می توانند میانگین ، حداکثر و حداقل مقادیر داده را در مدت زمان مشخص محاسبه کنند تا داده ها را برای این دوره زمانی نشان دهند.

به این ترتیب داده ها با لایه بالایی آسان تر قابل تجزیه و تحلیل هستند.

در طی این فرآیند ، متوجه می شویم که داده های IoT با مشخصات جریان داده سازگار است.

بنابراین ما برای کمک به فیلتر کردن داده ها از فناوری جریان داده استفاده می کنیم.

زیرا فن آوری سنتی مدیریت داده ها ، ذخیره داده ها به عنوان یک ساختار ایستا است.

این نمی تواند مشکل مقیاس بزرگ ، محاسبه داده ها و پرس و جو را حل کند.

بنابراین ما موتور "Esper" را به عنوان ابزاری انتخاب می کنیم و از یک پنجره کشویی چهار ثانیه برای پردازش داده ها استفاده می کنیم.

از این طریق می توانیم داده های نامحدود را به اطلاعات محدودی تبدیل کنیم.

شکل 7 ساختار پنجره را نشان می دهد.

این بدان معناست که میان افزار با توجه به زمان رسیدن چهار ثانیه از داده ها را دریافت می کند و داده های پنجره کشویی با گذشت زمان به روز می شوند.

D. اشتراک و فشار پیام:

از آنجا که تعامل داده ها همیشه یک به یک نیست ، اما گاهی اوقات یک به یک ، حتی بسیاری از آنها ، ما یک اشتراک کامل داده ها و مکانیسم فشار را برای پاسخگویی به این نیازهای متقابل داده های پیچیده طراحی کرده ایم.

ما به جای رمزگذاری همه توسط خودمان برای ارائه خدمات ، می خواهیم رابط های سیستم شخص ثالث را محصور کنیم.

زیرا سیستم ثالث ثالث از پایه سخت افزاری و نرم افزاری قوی برخوردار است.

و از قابلیت های فنی برای اطمینان از پایداری خدمات فشار برخوردار است.

بنابراین آنچه ما باید انجام دهیم این است که ناهمگونی رابط های مختلف سیستم فشار را محافظت کنیم.

ما روشهای اشتراک پیام را تقسیم می کنیم و به دو دسته فشار می دهیم.

اولین مورد با رابط "RESTful" با یکدیگر ارتباط برقرار می کنند و دوم برای انتقال داده ها "SDK".

بنابراین ما یک رابط سازگار از سیستم فشار را ضبط می کنیم و انواع مختلفی از خدمات را در پرونده "JSON" تعریف می کنیم.

به این ترتیب ، فقط باید هنگام بروزرسانی سرویس های فشار ، کلاس مربوطه را تغییر یا اضافه کنیم.

و پیام منتقل شده در یک قالب یکنواخت است.

فرمول (9) ساختار یک پیام را نشان می دهد.

از "subToken" برای شناسایی پیام استفاده می شود و سیستم فشار جدول را حفظ می کند.

جدول ، نشانه و آدرس مشترکین را نقشه برداری می کند تا سیستم بتواند پیام را دقیقاً ارسال کند.

authToken حاوی اطلاعات تأیید اعتبار است و برای اطمینان از ایمنی پیام استفاده می شود.

msgData شامل داده های واقعی است.

پرونده پیکربندی سیستم فشار "علی" در شکل 8 نشان داده شده است.

این نام سیستم فشار ، کنترل کننده مربوطه و برخی از اطلاعات مهم اتصال را نشان می دهد.

از "subToken" برای شناسایی پیام استفاده می شود و سیستم فشار جدول را حفظ می کند.

جدول ، نشانه و آدرس مشترکین را نقشه برداری می کند تا سیستم بتواند پیام را دقیقاً ارسال کند.

authToken حاوی اطلاعات تأیید اعتبار است و برای اطمینان از ایمنی پیام استفاده می شود.

msgData شامل داده های واقعی است.

پرونده پیکربندی سیستم فشار "علی" در شکل 8 نشان داده شده است.

این نام سیستم فشار ، کنترل کننده مربوطه و برخی از اطلاعات مهم اتصال را نشان می دهد.

داده ها.

یکی ماژول اتصال است که فرآیند readapt و تولید مجدد را از بین می برد.

مکانیسم غیر مسدود کننده ناهمزمان است.

این آزمایش ثابت می کند که واسطه می تواند با مقادیر زیادی و همزمانی بالای انتقال اطلاعات روبرو شود.

در این میان نرخ بسته گمشده در سطح پایین باقی می ماند.

از این گذشته ، ما یک آزمایش کنتراست را برای کشف تأثیر استفاده از مکانیسم غیر مسدود کننده ناهمزمان به جای همزمان ، طراحی می کنیم.

همانطور که در شکل 10 نشان داده شده است ، تاخیر در ارسال اطلاعات برای صف پیام با استفاده از روش ناهمزمان به طور قابل توجهی بهینه می شود زیرا موضوع هسته به مدت طولانی مسدود می شود که تعامل داده های همزمان به تدریج افزایش یابد.

بنابراین به طور جدی عملکرد را کاهش داده و تأخیر را افزایش می دهد.

همچنین میان افزار عملکرد فیلتر کردن داده ها را فراهم می کند.

بنابراین ما آزمایش می کنیم تا تأثیر آن را آزمایش کنیم.

ما واسطه های خود را برای پروژه ای به نام سیستم هوشمند کنترل دما (ITCS) اعمال می کنیم.

این پروژه با هدف تجزیه و تحلیل داده های تاریخچه کاربر و داده های مکان در زمان واقعی انجام شده است تا بتواند زمان رسیدن کاربر برای تنظیم تهویه مطبوع را پیش بینی کند.

و میان افزار ما قادر به ارائه خدمات داده های زمان واقعی برای پروژه است.

سخت افزار درگیر در این راه حل شامل سنسور دما از شرکت "DFRobot" ، صفحه توسعه اینتل و سوئیچ هوشمند ، دروازه هوشمند شرکت "نانجینگ وولیان" است.

این دستگاه ها از تأمین کننده های مختلف هستند بنابراین برای محافظت از ناهمگونی باید از وسایل میان افزار ما استفاده کنند.

این نرم افزار شامل یک برنامه Android ، یک سیستم پیش بینی و کنترل است که برای پیش بینی زمان پشتیبان و واسطه استفاده می شود.

تمام دستگاه های فیزیکی و سیستم های خارجی دارای "موجودیت مجازی" در میان افزار هستند.

همه آنها در "استخر اشخاص" قرار دارند.

هنگامی که وضعیت واحد مجازی سنسور تجدید می شود (به این معنی است که یک داده جدید درجه حرارت از فیلتر عبور می کند) ، اشتراک پیام و ماژول هل دادن داده ها را به مشترکان سوق می دهد.

مشترکین برنامه اندرویدی و سیستم پیش بینی و کنترل هستند.

برنامه اندرویدی اطلاعات موقعیت مکانی زمان واقعی خود را در سیستم پیش بینی و کنترل بارگذاری می کند.

سیستم پیش بینی و کنترل زمان پشتیبان کاربر را بر اساس موقعیت مکانی واقعی و داده های موقعیت مکانی پیش بینی شده خود پیش بینی می کند ، سپس از این زمان پشتیبانی به همراه دمای داخلی در زمان واقعی استفاده کنید تا مشخص شود که آیا ما نیاز به باز کردن تهویه هوا داریم یا خیر.

در "ITCS" ، واسطه کمک می کند تا ناهمگونی محافظت شود زیرا سخت افزار آن از شرکت های مختلف است.

اگر بخواهیم خواسته های دریافت داده های دما ، کنترل سوئیچ هوشمند و انتقال داده های GPS را برآورده کنیم ، بدون برنامه واسط می توان سه برنامه مختلف را در تلفن همراه نصب کرد.

اما به محض اینکه همه دستگاه ها به میان افزار ما متصل شدند ، تبادل داده ها بر روی سکوی میان افزار انجام می شود ، بنابراین ما فقط باید یک برنامه را در تلفن همراه نصب کنیم.

ما این آزمایش را روی رایانه ای با رم Intel Core i7-4710 و 4 گیگابایت انجام می دهیم.

و ما از یک مجموعه داده GPS از یک مسیر ثابت به عنوان داده های تاریخ استفاده می کنیم.

ما برای ارسال اطلاعات GPS در خودرو از تلفن همراه آندروید استفاده می کنیم.

ما در اولین آزمایش آستانه را به اندازه کافی بزرگ قرار دادیم تا واسطه داده ها را فیلتر نکند.

و آستانه را در بار دوم به مقدار عادی تنظیم کنید.

جدول 1 نتیجه کنتراست را نشان می دهد.

از جدول 1 می توان دریافت که زمان محاسبه با مجموعه داده های اصلی متراکم بسیار افزایش می یابد.

و بعد از فیلتر کردن داده های میان افزار ، می توانید سریعتر انجام دهید.

بنابراین این آزمایش عملکرد و ارزش میان افزار ما را اثبات می کند.

ششم نتیجه گیری و کار آینده:

در این مقاله ، ما طراحی و اجرای نرم افزار میانی را ارائه داده ایم که به ارائه برخی از کارکردهای اساسی و خدمات داده است.

طراحی "استخر مجازی" و "استخر موجودیت" به محافظت از ناهمگونی دستگاه ها و مدیریت میان افزار کمک می کند.

همچنین ، ما یک مکانیزم برای فیلتر کردن داده های بی فایده و اضافی را برای اطمینان از عملکرد و راحتی واسطه های خود طراحی کردیم.

علاوه بر این ، میان افزار ما دارای ساختار سلسله مراتبی است و می تواند بصورت توزیع گسترده مستقر شود.

بنابراین می توان آن را به راحتی و بدون تأثیرگذاری بر وسایل فیزیکی اساسی و برنامه های کاربردی فوقانی ، ارتقا داد.

براساس واسطه های ما ، توسعه دهندگان می توانند بدون توجه به چیزهای دیگر ، روی منطق و عملکرد پروژه خود تمرکز کنند.

این آزمایش عملکرد و کاربردی خوب میان افزار را نشان می دهد.

در پایان ، هدف این میان افزار فراهم کردن بستری برای دستگاههای ناهمگن است تا بتوانند راحت تر با یکدیگر ارتباط برقرار کنند و راهکاری مناسب برای پردازش آن داده های گسترده ارائه دهند.

در مورد کارهای آینده ، ما قصد داریم با استفاده از سرویس میانجی IoT از سرویس داده ، مجموعه کاملی از راه حل را در یک سناریوی IoT تهیه کنیم.

به عنوان مثال ، واسطه در Smart Home اعمال خواهد شد.

پس از موفقیت ، سرویس میانجی IoT می تواند آن را در برخی زمینه های دیگر گسترش دهد.