سیستم محاسبات مشارکتی برای پردازش سنگین و تأخیر کم در شبکه‌های حسگر بی‌سیم

مقدمه

با پشتیبانی از پیشرفت‌های سیستم‌های میکرو الکترومکانیکی (MEMS)، فناوری‌های حسگرها پیشرفت چشمگیری داشته و انواع مختلفی از حسگرها ظاهر شده‌اند [1]. با چنین پیشرفتی، شبکه‌های حسگر بی‌سیم (WSN) مورد توجه بسیاری از محققان در زمینه‌های مختلف از جمله اینترنت اشیا (IoT) قرار گرفته‌اند [2،3]. WSN ها شامل گره های حسگر هستند که به یکدیگر متصل هستند و گره های حسگر نقش جمع آوری داده های حس شده و انتقال داده ها به کاربران یا سرورها را بر عهده می گیرند [4،5،6]. به طور کلی، گره‌های حسگر بی‌سیم در مقایسه با گره‌های سیمی منابع ضعیفی دارند، زیرا معمولاً از منابع برق سیمی برای مشکل تحرک اجتناب می‌شود [7]. بنابراین، WSN‌های موجود عمدتاً برای سرویس‌های دارای تحمل تاخیر که به محاسبات کم نیاز دارند، استفاده می‌شوند. به همین دلیل، بسیاری از محققین بر بهبود کارایی مصرف برق شبکه های بی سیم تمرکز کرده اند [8،9]. علاوه بر این، سایر محققان تحقیقاتی را در مورد استفاده از سرورهای ابری برای غلبه بر منابع محدود گره ها مانند قدرت محاسباتی کم، کمبود ذخیره سازی و غیره انجام داده اند [10،11،12،13،14]. این به این دلیل است که وظایف با تحمل تأخیر یا ویژگی تجمع دامنه وسیع با منابع قدرتمند سرورهای ابری به خوبی انجام می‌شوند [15].

← اجاره ابر رایانه   →

اینجا کلیک کنید

با توجه به پیشرفت فن آوری های سخت افزاری و نرم افزاری در سال های اخیر، دستگاه های تلفن همراه امروزی دارای منابع، حسگرها و محرک های بیشتری هستند. علاوه بر دستگاه های تلفن همراه، پیشرفت های قابل توجهی در سیستم عامل های حسگر کوچک و کم هزینه مانند آردوینو و WRTnode وجود دارد [16،17]. با استفاده از این دستگاه‌ها، کاربران قادر به جمع‌آوری داده‌های مختلف حسگر و انجام پردازش‌های مورد نیاز محاسباتی سنگین هستند. بر اساس چنین پیشرفتی، مفهوم محاسبات لبه پیشنهاد شد. محاسبات لبه به شبکه هایی اطلاق می شود که گره های لبه به طور فعال در عملیات محاسباتی شرکت می کنند [18]. مدل‌های محاسبات ابری موجود عمدتاً برای برنامه‌های کاربردی وب سنتی طراحی شده‌اند، بنابراین برای برنامه‌های اینترنتی آینده که بر روی گره‌های مختلف موبایل و حسگر اجرا می‌شوند، مناسب نیستند [19]. علاوه بر این، تأخیر شبکه ناشی از فواصل طولانی بین سرورهای ابری و دستگاه‌ها برای برنامه‌ها یا سرویس‌های حساس به تأخیر که برای انتقال مکرر داده‌های با اندازه بزرگ مانند داده‌های ویدیویی و صوتی مورد نیاز هستند، نامناسب است [16]. برعکس، محاسبات لبه به گره‌های حسگر اجازه می‌دهد تا به درستی از منابع خود برای انجام پردازش استفاده کنند. بنابراین، طیف وسیع تری از برنامه ها را می توان بر روی گره های حسگر با مفهوم محاسبات لبه اجرا کرد.

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

. در محاسبات مشارکتی، گره‌های حسگر منابع خود را مانند قدرت و انرژی محاسباتی به اشتراک می‌گذارند و پردازش را به صورت مشارکتی انجام می‌دهند. گره های حسگر، بر اساس محاسبات مشارکتی، قادر به تخلیه محاسبات پردازش داده های حس شده برای بهبود عملکرد محاسباتی و مصرف انرژی گره های حسگر به طور یکنواخت هستند. بنابراین، گره‌هایی که از محاسبات مشترک استفاده می‌کنند، می‌توانند برنامه‌هایی را انجام دهند که به محاسبات بزرگ نیاز دارند. به خصوص، بیشتر برنامه‌هایی که از داده‌های ویدیویی استفاده می‌کنند، نیازمند پردازش حجم زیادی از محاسبات هستند. بنابراین، می توان عملکرد چنین برنامه هایی را با اعمال مفهوم محاسبات مشارکتی برای برنامه های کاربردی در WSN ها بهبود بخشید. به عنوان مثال، تحقیقی وجود دارد که سیستمی را برای استفاده از پردازش ویدیویی مشارکتی برای بهبود کیفیت نتیجه پردازش پیشنهاد می‌کند [21].

علاوه بر داده‌های ویدیویی، داده‌های صوتی نیز از جمله پرکاربردترین انواع داده در WSN هستند. میکروفون ارزان است و بسیار مورد استفاده قرار می گیرد، بنابراین اکثر دستگاه های تلفن همراه از قبل یک میکروفون داخلی دارند. علاوه بر این، حتی اگر برخی از گره های حسگر میکروفون داخلی ندارند، اکثر آنها قادر به استفاده از میکروفون هستند. این بدان معناست که برنامه‌هایی که از داده‌های صوتی استفاده می‌کنند می‌توانند به راحتی از دستگاه‌های نزدیک به عنوان گره‌های حسگر استفاده کنند. به دلیل این مزایا، بسیاری از محققان علاقه مند به استفاده از داده های صوتی در WSN ها بوده اند و برنامه های کاربردی مختلفی با استفاده از داده های صوتی پیشنهاد شده است [22،23،24،25،26]. برای پردازش یا تجزیه و تحلیل داده های صوتی در چنین برنامه هایی، تبدیل فوریه سریع (FFT) [27] تقریباً همیشه جزء کلیدی است. حتی همبستگی متقابل [28] یا تبدیل موجک [29] اساساً ترکیبی از چندین عملیات FFT یا یک نتیجه جزئی از FFT است. از آنجایی که FFT به منابع محاسباتی زیادی نیاز دارد، عملیات پردازش داده های صوتی به مقدار زیادی محاسبات نیاز دارد. علاوه بر این، بسیاری از برنامه‌ها نیازمند این هستند که عملیات باید در موعد مقرر انجام شود، که اجرای برنامه‌های نسبتاً سنگین را برای یک گره در WSN دشوار می‌کند.

برای غلبه بر محدودیت‌ها، ما یک سیستم محاسباتی مشارکتی، HeaLow را برای پردازش سنگین و تأخیر کم در WSN پیشنهاد می‌کنیم. برای پایان دادن به محاسبات سنگین در مهلت مقرر، HeaLow پردازش و بارگذاری را به درستی با در نظر گرفتن عوامل مختلف انجام می دهد. از آنجایی که پردازش داده های صوتی (پردازش سیگنال صوتی) یکی از پرکاربردترین عملیات برای برنامه های کاربردی در WSN ها است، ما پردازش داده های صوتی را به عنوان وظیفه هدف در این مقاله در نظر می گیریم. با این حال، HeaLow را می توان برای هر برنامه ای که نیاز به محاسبات و پردازش های بزرگ برای تکمیل در یک مهلت محدود دارد استفاده کرد. هدف طراحی HeaLow این است که به گره های حسگر بی سیم ناتوان کمک کند تا محاسبات سنگین را در مهلت مقرر به پایان برسانند. علاوه بر این، اگر منابع کافی در سیستم چند دستگاهی وجود داشته باشد، استفاده از منابع رایگان برای بهبود عملکرد برنامه، هدف ثانویه HeaLow است. از آنجایی که به موقع بودن محاسبات سنگین یک کار چالش برانگیز است، موضوع بهره وری توان در این مقاله در نظر گرفته نشده است.

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

با استفاده از HeaLow، گره‌ها در WSN می‌توانند فرآیندهای محاسباتی سنگین را در حالی که نیاز زمان تکمیل را برآورده می‌کنند، انجام دهند.

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

ما در این مقاله پردازش سیگنال‌های صوتی را که می‌توان برای سرویس‌ها و برنامه‌های کاربردی مختلف در WSN ها استفاده کرد، به عنوان وظیفه هدف در نظر می‌گیریم. بنابراین، چنین سرویس ها و برنامه هایی می توانند به راحتی از HeaLow استفاده کنند.

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

کار مرتبط

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

به طور کلی، گره ها در WSN ها منابع نسبتا محدودی دارند، بنابراین مطالعات زیادی برای غلبه بر محدودیت با استفاده از منابع قدرتمند سرورهای ابری انجام شده است. اولا، ون و همکاران. تمرکز بر اجرای برنامه بهینه انرژی در پلتفرم به کمک ابر خود [30]. برای کاهش مصرف انرژی گره‌های حسگر، آنها استراتژی‌هایی را برای پیکربندی فرکانس ساعت و زمان‌بندی بهینه انتقال داده‌ها تدوین کردند. با توجه به نتایج عددی آنها، مقدار زیادی انرژی را می توان با بارگذاری وظیفه به کلون ابری ذخیره کرد. مشابه ون [30]، سینها و همکاران. از منابع سرورها برای کاهش محدودیت های دستگاه ها استفاده می کردند، اما آنها از چندین سرور با هم بر اساس الگوریتم پارتیشن بندی وظایف خود استفاده می کردند [31]. نتایج ارزیابی آنها نشان می دهد که الگوریتم پارتیشن بندی پیشنهادی بهتر از الگوریتم های موجود عمل می کند. برخلاف ون [30] و سینها [31]، داتاترایا و همکاران. تمرکز بر ذخیره سازی ناکافی گره های حسگر [32]. در سیستم خود، گره‌های حسگر داده‌های حس‌شده را در سرورها ذخیره می‌کنند و سیستم دسترسی به کاربران مجاز را برای بازیابی اطلاعات حسگر ذخیره شده در سرورها فراهم می‌کند. از جمله کار فوق، بسیاری از مطالعات نشان دادند که استفاده از سرورهای ابری روشی مؤثر برای کاهش محدودیت منابع گره‌های حسگر است. با این حال، به گفته چاندرا [16]، استفاده از سرورهای ابری برای برنامه‌ها یا سرویس‌های حساس به تأخیر که برای انتقال مکرر داده‌های با اندازه بزرگ مورد نیاز است، نامناسب است. علاوه بر این، مدل‌های محاسبات ابری موجود عمدتاً برای برنامه‌های کاربردی وب سنتی طراحی شده‌اند، بنابراین این مدل‌ها برای برنامه‌های اینترنتی آینده که بر روی گره‌های مختلف موبایل و حسگر اجرا می‌شوند، از جمله کارهای انجام شده توسط شنگ و همکاران، مناسب نیستند. [19].

← اجاره ابر رایانه   →

اینجا کلیک کنید

در سال‌های اخیر، دستگاه‌های گره‌های حسگر در شبکه‌های بی‌سیم پیشرفت چشمگیری داشته‌اند، بنابراین فرآیندهای مختلفی را می‌توان در گره‌های حسگر بدون سرور ابری انجام داد. بنابراین بسیاری از محققین مانند Varghese et al. بر محاسبات لبه متمرکز شد و مطالعاتی را بر روی بارگذاری وظایف انجام داد که فرآیند مهمی در محاسبات لبه است [33]. اولا، کیونگ و همکاران. روشی را برای پارتیشن بهینه در میان گره‌ها برای به حداقل رساندن زمان جستجوی الگوی مورد علاقه در یک داده بزرگ پیشنهاد کرد [34]. آنها یک ارزیابی شبیه‌سازی انجام دادند و نتیجه شبیه‌سازی نشان می‌دهد که زمان مورد انتظار پردازش با تقسیم‌بندی وظایف بین گره‌ها کاهش می‌یابد. چن و همکاران . یک الگوریتم تخلیه محاسباتی توزیع شده طراحی و مسئله تصمیم گیری تخلیه بارگذاری را فرموله کرد [35]. آنها مطالعات عددی انجام دادند و نتایج مطالعات نشان می‌دهد که الگوریتم آنها عملکرد بارگذاری محاسباتی را بهبود می‌بخشد و بسته به تعداد گره‌ها به خوبی مقیاس می‌شود. مشابه چن [35]، مائو و همکاران. یک الگوریتم تخلیه محاسباتی پویا پیشنهاد کرد که تصمیم تخلیه، فرکانس‌های سیکل CPU و توان انتقال را به طور مشترک تعیین می‌کند [36]. مزیت اصلی این الگوریتم این است که می توان تصمیمات را بدون نیاز به اطلاعات توزیع دیگر اتخاذ کرد. الگوریتم پیشنهادی از طریق شبیه سازی مورد ارزیابی قرار گرفت.

علاوه بر محاسبات لبه، برخی از مطالعات از مفهوم محاسبات مشارکتی برای بهبود عملکرد پردازش و مصرف یکنواخت انرژی گره ها استفاده کردند. شنگ و همکاران یک رویکرد جدید برای به حداقل رساندن مصرف انرژی در پردازش پیشنهاد کرد [19]. آنها راه حل پیشنهادی را از طریق شبیه سازی ارزیابی کردند و نتایج شبیه سازی ها نشان می دهد که مصرف کل انرژی به طور قابل توجهی با توزیع بار کاری بین گره های حسگر کاهش یافته است. با استفاده از محاسبات مشارکتی، این امکان برای گره ها وجود دارد که برنامه هایی را انجام دهند که به محاسبات بزرگ نیاز دارند، مانند برنامه هایی که از داده های تصویری یا صوتی استفاده می کنند. بنابراین، محاسبات مشارکتی می‌تواند راه‌حل مؤثری برای چنین کاربردهایی در WSN باشد. مطالعاتی در مورد استفاده از محاسبات مشارکتی برای بهبود عملکرد پردازش ویدئو در شبکه های بی سیم وجود دارد. اولا، اریکسون و همکاران. راه حلی برای بهینه سازی توزیع وظایف بین گره ها برای به حداقل رساندن زمان مورد نیاز برای تکمیل تجزیه و تحلیل بصری توزیع شده در یک شبکه حسگر بصری پیشنهاد کرد [37]. به طور مشابه، لانگ و همکاران. یک طرح پردازش ویدئویی همکاری برای به حداکثر رساندن کیفیت نتیجه پردازش ویدئو طراحی کردند و آنها مطالعات شبیه سازی را با استفاده از MATLAB انجام دادند [21]. علاوه بر داده‌های ویدیویی، داده‌های صوتی نیز از جمله پرمصرف‌ترین انواع داده‌ها هستند و مطالعات زیادی در مورد استفاده از داده‌های صوتی در WSN‌ها وجود دارد. اولا، مائو و همکاران. برنامه ای را توسعه داده است که از اثر داپلر برای ردیابی حرکت کاربر در زمان واقعی استفاده می کند [38]. به طور مشابه، ژانگ و همکاران. سیستمی برای تشخیص برخوردهای انسان بر اساس پروفایل های داپلر سیگنال های صوتی طراحی کرد [39]. علاوه بر این، وانگ و همکاران. سیستمی را برای درک محیط با استفاده از بازتاب‌های صوتی پیشنهاد کرد [40]. تونگ و همکاران یک تکنیک محلی سازی بدون برد را برای تشخیص اتاق با استفاده از بازتاب سیگنال دیوارها و مبلمان اطراف ایجاد کرد [41]. اخیراً، تلاش‌هایی برای اتخاذ سیگنال‌های مبتنی بر صوتی در میدان هواپیمای بدون سرنشین، که یکی از سریع‌ترین میدان‌های در حال ظهور است، از جمله کار مائو برای محلی‌سازی فضای داخلی [42] صورت گرفته است. موارد ارائه شده گزیده ای از مطالعات اخیر با استفاده از آکوستیک است و موارد بیشتری نیز وجود دارد. هنگام پردازش سیگنال های صوتی، عملیات مختلفی مانند FFT و همبستگی متقابل اساسا انجام می شود. در میان عملیات، FFT بسیار مکرر در مطالعات و برنامه های کاربردی با استفاده از سیگنال های صوتی استفاده می شود. در واقع، از جمله مطالعات فوق، بیشتر این گونه مطالعات و کاربردها شامل فرآیند FFT است و سیگنال های صوتی یکی از منابع اولیه برای به دست آوردن اطلاعات در زمینه های مختلف از جمله WSN ها بوده است که در کار پنگ به خوبی ارائه شده است [43]. از آنجایی که سیگنال های صوتی می توانند اطلاعاتی را ارائه دهند که در غیر این صورت در دسترس نیستند، علاقه فزاینده ای به سیگنال های صوتی وجود دارد. سیگنال‌های صوتی به روش‌های مختلفی در WSN‌ها استفاده می‌شوند: محلی‌سازی، تشخیص تماس انسانی، برچسب‌گذاری مکان، راهنمایی، و غیره. با این حال، بیشتر مطالعات با استفاده از سیگنال‌های صوتی از دستگاه‌های تخصصی یا گوشی‌های هوشمند استفاده می‌کنند. بسیاری از برنامه ها از جمله پردازش سیگنال صوتی نیاز به محاسبات و پردازش های بزرگ دارند تا در یک مهلت محدود تکمیل شوند. الزامات فوق بزرگ‌ترین موانع برای اتخاذ سیستم‌های صوتی پیچیده برای گره‌ها در WSN‌ها هستند که در آن بیشتر گره‌ها فقط قابلیت‌های محدودی دارند.

برای غلبه بر محدودیت فوق، ما سیستم محاسباتی مشارکتی HeaLow را پیشنهاد می‌کنیم که گره‌ها را در WSN‌ها را قادر می‌سازد تا پردازش محاسباتی سنگین را با رعایت ضرب‌الاجل انجام دهند. در مقایسه با کار مرتبط، HeaLow از چندین منظر دارای تازگی و مزیت است. اول، بسیاری از مطالعات مرتبط بر روی پردازش عملیات محاسباتی سنگین اما تحمل تاخیر متمرکز شدند. به عبارت دیگر، چنین مطالعاتی تأکید زیادی بر الزامات تأخیر کم نداشتند، به این معنی که نمی‌توان آن‌ها را برای برنامه‌هایی که نیاز به محاسبات بزرگ و پردازش در یک مهلت محدود دارند، اعمال کرد. HeaLow برای انجام فرآیندهای محاسباتی سنگین و در عین حال برآوردن نیاز زمان تکمیل طراحی شده است، بنابراین HeaLow را می توان برای برنامه های کاربردی متنوع تر در زمینه های مختلف اعمال کرد. ثانیا، از جمله مطالعات فوق، اکثر مطالعات با تمرکز بر محاسبات مشترک و بارگذاری در WSN ها ارزیابی عملکرد را از طریق شبیه سازی بدون پیاده سازی بر روی دستگاه های واقعی و آزمایش هایی با استفاده از دستگاه ها انجام دادند. در مقابل، ما HeaLow را بر روی دستگاه‌های واقعی پیاده‌سازی کردیم و آزمایش‌های متعددی را با استفاده از دستگاه‌ها برای تأیید اثربخشی HeaLow انجام دادیم. علاوه بر این، در این مقاله، ما پردازش سیگنال‌های صوتی را که یکی از پرکاربردترین عملیات در WSN ها است، به عنوان وظیفه هدف در نظر می‌گیریم. بنابراین، بسیاری از سرویس ها و برنامه های کاربردی که نیاز به پردازش سیگنال صوتی دارند، می توانند به راحتی از HeaLow استفاده کنند.

← مرکز محاسبات سنگنن شبیه‌سازان امیرکبیر  →

اینجا کلیک کنید!

طراحی HeaLow و پیاده سازی

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

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

3.1. طراحی کلی

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

نحوه خواندن نماد پیکان و توضیحات در زیر آمده است:

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

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

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

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

3.2. گردش کار HeaLow

در HeaLow، مولد بار کاری ماژولی را نشان می‌دهد که در آن بارهای کاری، یعنی داده‌های ورودی میکروفون، تولید می‌شوند. در بقیه مقاله، حجم کار با مقدار مشخصی ابهام استفاده می‌شود، زیرا می‌خواهیم مفهوم طراحی سیستم ما برای سایر سیستم‌ها مورد استفاده قرار گیرد. با این حال، در این کار، ما فقط آزمایش‌هایی را انجام دادیم که در آن حجم کاری بلوکی از ورودی صوتی خوانده شده از میکروفون است. ما یک تعریف مجزا از حجم کار داریم، که در آن مجموعه ای از داده های ورودی میکروفون برای یک عملیات FFT به عنوان یک بار کاری در نظر گرفته می شود. همانطور که قبلا ذکر شد، اکثر سیستم های مرتبط با صدا از FFT برای پردازش سیگنال استفاده می کنند، به خصوص زمانی که توسط سایر ابزارهای پردازش سیگنال نیز استفاده می شود: همبستگی متقاطع، کانولوشن، همبستگی خودکار و غیره. لازم به ذکر است که ما حجم کاری را به عنوان یک بلوک صدا تعریف کردیم. داده های ورودی زیرا FFT توسط بلوک ها انجام می شود. در مطالعات و سیستم‌های دیگر، این موضوع مستقیماً به یک موضوع کارگری می‌رود. این بر این فرض استوار است که دستگاه دارای منابع محاسباتی کافی است. در HeaLow، thread کارگر دارای یک صف کار است، زیرا نرخ پردازش می تواند کمتر از نرخ ورودی باشد. این باید در برنامه های کاربردی برای WSN ها در نظر گرفته شود. هنگامی که یک نخ کارگر یک صف کار به آن متصل است، صف یا خالی می شود یا پر می شود. اگر صف در طول مشخصی پر شود، بررسی کننده در دسترس بودن درخواست ها را رد می کند و داده ها را به یک صف تخلیه می فرستد. به این ترتیب، صف کار فقط مقداری دارد که نخ کارگر بتواند از عهده آن برآید.

وقتی حجم کاری به صف تخلیه پرتاب می‌شود، باید یا حذف شود یا در جای دیگری تخلیه شود. Dump queue به طور مداوم از مدیر درخواست می کند که دستگاه های دیگر در عضویت در صف موجود باشند، جایی که ماژول پشتیبانی ارتباطی مدیر درخواست را پخش می کند. بررسی‌کننده در دسترس بودن دستگاه دیگری با مقداری که می‌تواند در بالای حجم کاری خود پردازش کند، پاسخ می‌دهد که از طریق ماژول پشتیبانی ارتباطی به دستگاه درخواست‌کننده بازگردانده می‌شود. صف dump سپس تعداد بارهای کاری مجاز را از طریق اتصال همتا به همتا به دستگاه تخلیه می کند. ما از عبارت اتصال همتا به همتا در سطح لایه برنامه استفاده می کنیم. در HeaLow، اتصال همتا به همتا به معنای اتصالی است که از طریق آن یک دستگاه داده ای را بدون عبور از دستگاه سرور به دستگاه دیگری ارسال می کند. به عنوان مثال، دستگاه تخلیه مستقیماً بر اساس آدرس داده شده از سرور به دستگاه مقصد متصل می شود. این امر باعث می شود که سرور مجبور نباشد تمام ترافیک را پردازش کند. یعنی اگر دستگاه ها مانند سیستم ما از طریق Wi-Fi وصل شوند، اگر نیاز باشد از سوکت سرور عبور کند، دستگاه A داده ها را به Wi-Fi AP می فرستد، AP آن را به دستگاه سرور، سرور می فرستد. دستگاه آن را به AP می فرستد و AP آن را به دستگاه مقصد می فرستد. با این حال، اگر دستگاه A مستقیماً به مقصد متصل شود، انتقال فقط دو بار اتفاق می‌افتد. این اتصال زمانی که نتیجه تخلیه بار برگردانده می شود دوباره استفاده می شود. سازمان‌دهنده نتیجه نتایج را مستقیماً از صف کار و کار بارگذاری شده جمع‌آوری می‌کند و نتایج را برای برنامه مرتب می‌کند. برخی از توضیحات گمشده برای جزئیات پیاده سازی در بخش 3.3 همراه با انتخاب های طراحی برای آنها آورده شده است.

3.3. جزئیات پیاده سازی

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

3.3.1. مدیریت بار بافر

با بافر کردن بارهای کاری در سراسر HeaLow، کارایی HeaLow را بهبود بخشیم. به خصوص برای شبکه ها، تحویل بار بافر استفاده از شبکه را به حداکثر می رساند. برای استفاده از بافرها، بررسی‌کننده در دسترس بودن تعداد بارهای کاری را که می‌تواند هنگام درخواست دستگاه‌های دیگر برای تخلیه پردازش کند، برمی‌گرداند. از سوی دیگر، true یا false برای کار خود که هنوز بافر نشده است، برگردانده می شود. در HeaLow، در دسترس بودن حداکثر طول صف تقسیم بر نرخ پردازش را نشان می دهد.

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

3.3.2. مدیریت صف کار

مهمترین جزء یک کارگر در HeaLow صف کار است. همانطور که از نام آن مشخص است، یک حجم کاری در سر صف کار توسط نخ کارگر پردازش می شود. البته حجم کاری که ضرب الاجل خود را پشت سر گذاشته است به طور مداوم از صف حذف می شود و این اتفاق به عنوان یک شکست تلقی می شود. بررسی کننده در دسترس بودن تعیین می کند که آیا یک بار کاری می تواند توسط رشته کارگر پردازش شود یا خیر. مقداری که قابل پردازش نیست به صف دامپ ریخته می شود و بارهای کاری در صف دامپ به دستگاه های دیگر ارسال می شود یا به عنوان خرابی در نظر گرفته می شود. طول صف HeaLow در حوزه زمانی درک می شود، زیرا مهلت یکی از مسائل کلیدی طراحی HeaLow است. thread کارگر زمان پردازش آخرین بار کاری را به صف کار گزارش می‌دهد، جایی که مقدار کار در صف کار بر نرخ پردازش تقسیم می‌شود تا طول صف در حوزه زمانی بدست آید. سپس طول صف با مهلت بار کاری جدید مقایسه می شود. اگر طول صف از مهلت مقرر کمتر نباشد، حجم کار را نمی توان به صف اضافه کرد. توضیح مفصل در مورد فرآیند تصمیم گیری تخلیه بار در بررسی کننده در دسترس بودن در بخش 3.4 آورده شده است.

روش فوق منطقی و سرراست است، اما زمان پردازش یک مسئله عملی به همراه دارد. همانطور که در شکل 2 نشان داده شده است، زمان پردازش اغلب به یک مرتبه بزرگی برای یک دوره کوتاه کاهش می یابد. اگرچه نتوانستیم علت تاخیر را مشخص کنیم، بهترین حدس ما این است که سیستم عامل اندروید فقط برای HeaLow عملیات انجام نمی دهد و این باعث ایجاد رقابت برای منابع موجود شد. این منجر به پدیده ای می شود که ما آن را خطر بافر نامیدیم و یک تکنیک اضافی برای مقابله با این پدیده پیاده سازی کردیم. خطر بافر زمانی اتفاق می‌افتد که زمان پردازش به سرعت کاهش می‌یابد، طول صف درک شده را چند برابر می‌کند، تمام بار کاری ورودی را برای یک دوره زمانی رد می‌کند در حالی که نمی‌توان حجم کاری را در صف کار به پایان رساند. هنگامی که یک خطر بافر رخ می دهد، می توانیم پیش بینی کنیم که سرعت پردازش آن برای یک دوره کوتاه کند باشد. بنابراین، وقتی این اتفاق می‌افتد، دستگاه وارد حالت خطر می‌شود و بخشی از بار کاری ورودی را بدون بررسی در دسترس بودن تخلیه می‌کند تا زمانی که صف خالی شود و از حالت خطر خارج شود. نام این روش را مدیریت حالت خطر گذاشتیم.

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

3.3.3. ماژول ارتباط و پاسخ با تاخیر

دو ماژول مختلف برای ارتباط در HeaLow وجود دارد. ماژول ارتباطی به مدیر متصل است و ماژول اتصال همتا به همتا به جایی متصل نیست. اگر همه پیام ها از طریق مدیری ارسال شوند که برای همه اعضای خود ارتباط برقرار می کند، کارگران نیازی به داشتن اطلاعاتی از سایر اعضا ندارند. به این ترتیب تعداد اتصالات برای متصل نگه داشتن همه دستگاه ها به حداقل می رسد. این به ویژه هنگام ارسال پیام به همه اعضا راحت است، به عنوان مثال هنگام ارسال پیام درخواست تخلیه. با این حال، این تعداد ارسال ها را برای هر تحویل پیام دو برابر می کند، زیرا مدیر باید دوباره پیام را ارسال کند. این معمولاً یک مسئله حیاتی نیست، اما زمانی که اندازه پیام با حجم کاری بارگیری و نتایج بزرگتر می شود، استفاده دوبرابر از شبکه یک گلوگاه جدی شبکه ایجاد می کند. برای جلوگیری از چنین تنگناهایی، پیام‌هایی با اندازه بزرگ که شامل حجم کاری یا نتایج فرآیند هستند مستقیماً به مقصد ارسال می‌شوند. از آنجایی که هر تخلیه با یک درخواست و یک پاسخ شروع می شود، پیام پاسخ شامل اطلاعات آدرس شبکه برای درخواست کننده برای ایجاد یک سوکت از طریق ماژول اتصال همتا به همتا است. این روش به طور موثر استفاده از شبکه را نصف می کند مگر اینکه مدیر به عنوان زیرساخت بی سیم عمل کند.

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

…

نتایج

در مقایسه با گره‌های سنتی در WSN، گره‌های حسگر امروزی منابع قدرتمندتری دارند، بنابراین گره‌ها قادر به انجام عملیات پیچیده‌تر هستند و کاربردهای متنوع‌تری را می‌توان برای WSN‌ها اعمال کرد. در میان برنامه‌ها، بسیاری از برنامه‌ها با داده‌های صوتی سروکار دارند، زیرا داده‌های صوتی جزو پرکاربردترین انواع داده‌ها هستند و گره‌های حسگر می‌توانند به راحتی از میکروفون‌ها استفاده کنند. با این حال، اکثر برنامه‌ها نیاز به محاسبات و پردازش‌های بزرگ دارند تا در یک مهلت کوتاه تکمیل شوند، بنابراین برای یک گره دشوار است که برنامه‌های نسبتاً سنگین را به تنهایی اجرا کند. برای غلبه بر این محدودیت، در این مقاله، ما سیستم محاسباتی مشارکتی، HeaLow را برای پردازش با محاسبات سنگین و تأخیر کم در WSN ها پیشنهاد کردیم. برخلاف مطالعات مرتبط که سیستم‌های خود را فقط از طریق شبیه‌سازی ارزیابی می‌کنند، ما HeaLow را بر روی دستگاه‌های واقعی پیاده‌سازی کردیم. بنابراین، ما آزمایش‌هایی را با استفاده از دستگاه‌های واقعی و همچنین شبیه‌سازی انجام دادیم و نتایج نشان داد که گره‌هایی که از HeaLow در WSN استفاده می‌کنند، قادر به اجرای برنامه‌هایی هستند که به عملیات سنگین با تأخیر کم نیاز دارند. ما در این مقاله پردازش سیگنال‌های صوتی را که می‌توان برای سرویس‌ها و برنامه‌های مختلف در WSN استفاده کرد، در نظر گرفت. بنابراین، چنین سرویس ها و برنامه هایی می توانند به راحتی از HeaLow استفاده کنند. با این حال، از آنجایی که HeaLow برای تخصصی شدن در برنامه های خاص طراحی نشده است، HeaLow را می توان برای هر برنامه ای استفاده کرد.

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

مطالب مرتبط:

پردازش سنگین

← اجاره ابر رایانه   →

اینجا کلیک کنید