چکیده
از زمان گسترش اینترنت اشیا، شاهد افزایش روز افزون طراحی معماری‌های گوناگون در حوزه اینترنت هستیم. تمام تلاش‌های صورت گرفته در طراحی معماری‌هایی میباشد که اقدام به برقراری ارتباط بین دستگاه ها و سرویس های مختلف IOT میکنند. یکی از مرسوم ترین نمونه از اینترنت اشیا ایجاد یک سیستم یکپارچه حمل و نقال در پاسخ به نیاز ها و شرایط ترافیکی در حال تغییر، مسیریابی و همچنین سازماندهی مجدد فرایند مسیریابی میباشد. در مراقبتهای بهداشتی، اینترنت اشیا برای پیگیری بهبودی بیمار و ارزیابی آن در برابر تعداد‌ی از پارامتر ها ی منحصر به فرد بیمار با استفاده از دستگاه‌های دارای اینترنت اشیا ارزیابی می‌شوند. داده‌های جمع‌آوری شده همچنین می‌توانند برای مقایسه پاسخ های بیمار به درمان در زمینه های مختلف محیطی در مقیاس جهانی مورد استفاده قرار گیرند. از دستگاه های هوشمند اینترنت اشیا نیز میتوان برای نظارت و کنترل مصرف انرژ ی استفاده کرد. در کشاورز ی و تولید مواد غذایی، اینترنت اشیا را می توان برای مدیریت تولید با نظارت و ردیابی متغیرهایی که بر تولید مواد غذایی تأثیر می گذارند مانند آب و هوا، شاخص های سیاسی-اقتصادی، بلایای طبیعی، مصرف، بیماری‌های محصول و حیوانات و غیره استفاده کرد .
کلمات کلیدی: معماری نرم‌افزار در اینترنت اشیا، چارچوب، معماری سرویس‌گرا، معماری میکروسرویس
1. مقدمه
معماری رایج در حوزه اینترنت اشیا، معماری سرویس گرا SOA میباشد که هدف آن ارائه سیستم‌هایی با قابلیت حداقل وابستگی به‌یکدیگر (loosly couple system) جهت استفاده چندباره از سرویس‌های گوناگون اینترنت اشیا میباشد. هدف اصلی به حداقل رساندن وابستگی سیستم‌ها، برطرف کردن و کاهش مشکلات یکپارچگی در لایه میانی سیستم‌ها و سرویس‌های اینترنت اشیا میباشد. یکی از کلیدی ترین مشکلات رایج در بحث یکپارچه‌سازی در اینترنت اشیا، فقدان یک چارچوب هوشمند و آگاه از اتصال برای پشتیبانی از تعامل در سیستم‌های اینترنت اشیا میباشد.
مفهوم integrateability یعنی این اشیا ناهمگن باید بتوانند از طریق اینترنت و پروتکل‌های مختلف اقدام به برقراری ارتباط بپردازند. این اشیا می‌توانند یک مانیتور ارزیابی ضربان قلب باشند که به صورت implant داخل
بدن بیمار قرار داده شده‌اند یا در مزرعه حیوانات به صورت یک سری فرستنده biochip باشد یا ربات امداد و عملیات یا هر شی طبیعی یا مصنوعی که توسط انسان ها ساخته شده‌اند تا با قبول کردن یک IP-Address مشخص از طریق زیرساخت های اینترنتی، اقدام به ارائه یکسری خدمات میکنند.
در شکل 1 یک معماری پایه از سیستم های اینترنت اشیا مشاهده می‌شود
این gateway برای دستگاه‌های مختلف پروتکل و مکانیزمی‌هایی را فراهم می‌کند تا اطلاعات sense شده از محیط را از طریق بستر اینترنت به نمایش گذاشته شود. این ارتباط از طریق پروتکل های ارتباطی مثل WIFI, Ethernet, GSM میباشد. البته این ارتباط در لایه gateway بیشتر از طریق یک پروتکل معروفی به نام GSM (Global System for Mobile Communications) میباشد که مجموعه استانداردی از ارتباطات بین موبایلی با 2G network را فراهم می‌نماید.
واقعی توسط سنسورها و لایه اپلیکیشن را تسهیل می‌کند. لایه میانی پارامتر‌های مختلفی دارد مثل کیفیت سرویس یا Qos(quality of service) که اقدام به ارزیابی کیفیت خدمات عملکرد تلفن، خدمات شبکه کامپیوتری یا ابر و ابزارهای فناوری‌هایی را که توانایی شبکه را برای اجرای عملیات با اولویت بالا تضمین میکنند را اندازه گیری می کند. لایه اپلیکیشن map می‌شود به application هایی که توسط کاربر استفاده می‌شوند جهت ارسال دستور به اشیا در دنیای واقعی از طریق application های موبایلی و همچنین webapp ها و غیره.
اینترنت اشیا در صنایع بزرگ به یک trend مبدل شده است. به عنوان مثال شرکت Samsung در بیانیه خود اعلام کرده بود که تا سال 2017 به تعداد 90% و تا سال 2020، 100% دستگاه های آن دارای خدمات مختلف اینترنت اشیا خواهند شد که این امکان را در گوشی‌ها و تبلت‌های هوشمند خود از طریق اپلیکیشن که قابلیت برقراری ارتباط با سیستم عامل‌های مختلف بود را با نام SmartThings منتشر کرد.
همچنین آقای گارتنر پیشبینی کرده بود که تا سال 2020 بیش از 21 billion دستگاه مجهز به خدمات اینترنت اشیا خواهند شد.
اما یک مشکل وجود دارد، سایز ناهمگن بودن زیاد این دستگاه ها، موجب ایجاد مشکلاتی از قبیل integration و ایجاد ارتباط با توجه به موقعیت جغرافیایی متفاوت و همچنین platform ها و دستگاه های مختلف با یکدیگر شده است. این ها بخشی از مشکلاتی می‌باشند که یک معمار نرم افزار برای طراحی یک معماری و framework برای تعداد زیادی از دستگاه ها در حوزه اینترنت اشیا باید مد نظر خود قرار دهد.
معماری سرویس‌گرا (SOA) یک چارچوب قدرتمند برای پشتیبانی از connectivity، interoperability و همچنین integration در سیستم‌های اینترنت اشیا ارائه می‌دهد، که ستون فقرات frameworks های اینترنت اشیا امروزی را تشکیل می‌دهد. در حالی که اهداف SOA در درجه اول افزایش قابلیت همکاری(interoperability) برنامه های اینترنت اشیا میباشد، استفاده یکپارچه از آن در چارچوب های اخیر اینترنت اشیا مشکل مقیاس پذیری تشدید می‌کند.
به منظور این که framework اینترنت اشیا قابل اعتماد(dependable) و قابل اتکا(reliable) باشند باید حداقل یک سری پارامترها و معیارهای قابل ارزیابی وجود داشته باشند تا دو موضوع integration و همچنین interoperability را در اینترنت اشیا قابل دستیابی کنند. البته برای بحث یکپارچه سازی یکسری تاکتیک وجود دارند که جلوتر به آن‌ها اشاره خواهد شد. مثل orchestration & manage resource و restrict communication paths و همچنین abstract common services.
1.2 معیارهای ارزیابی در چارچوب‌های معماری اینترنت اشیا:
معیار اول: Contract decoupling، از آن جایی که میلیون‌ها دستگاه مجهز به فناوری اینترنت اشیا به صورت سیستم‌ها با سخت و نرم افزار‌های مختلف و همچنین به صورت ناهمگن در سراسر جهان پخش می‌باشند، فریم ورک باید مشکل Contract decoupling را حل کند، یعنی توانایی سرویس مصرف کننده(کاربر) و تولیدکنندگان سرویس بتوانند به صورت مستقل ایجاد و اعمال تغییرات کنند بدون اینکه ارتباط بین آن‌ها قطع شود، فرض کنید یکی از سرویس‌هایی که خدمات می‌دهد فرمت JSON دارد ولی سرویس یکی از کاربران ما نیاز به ورودی XML دارد فریم ورک مربوطه باید بتواند از این مورد خاص به صورت کامل پشتیبانی کند.
معیار دوم: Scalability، همان بحث شرکت سامسونگ که در فاز اول 90% و فاز بعدی 100% دستگاه های خود را مجهز به فناوری اینترنت اشیا کرد و فریم ورک مربوطه باید بتواند این موضوع را مدیریت کند که وقتی جمعیت تعداد کاربران از 1 میلیون نفر به 1 میلیارد رسید، فریم ورک مربوطه به مشکل بر نخورد.
معیار سوم: Ease of testing، فریم ورک مربوطه باید به راحتی debugging و تست شود و ما باید به راحتی بتوانیم defect ها یا fault هایی که قرار است به failure تبدیل شوند را شناسایی کنیم و قابلیت های مهم در حوزه های مختلف تست مانند:
integration testing, component testing, system testing, compatibility testing, installation test, functional and non-functional testing, performance testing, security testing
معیار چهارم: Ease of development، فریم ورک باید قابل توسعه به صورت آسان باشد و شامل مستندات و documentation های مناسب برای افراد فنی و غیر فنی باشد تا هم برنامه نویسان و هم سایر ذینفعان بتوانند بخش‌های درونی فریم ورک را به راحتی درک کنند.
معیار پنجم: Lightweight implementation، فریم ورک باید سبک باشد در زمان development and deployment.
معیار ششم: Service coordination، باید تصمیم گیری انجام شود درمورد نحوه تعامل سیستم‌ها با یکدیگر از طریق orchestrationیا choreography.
:Fault tolerance
فریم ورک مربوطه باید قابل اعتماد و انعطاف پذیر باشد. یک فریم ورک جهت یکپارچه سازی هوشمند باید به طور موثری faultها را مدیریت کند زیرا دستگاه های اینترنت اشیا در نهایت می‌توانند بین حالت‌های آفلاین و آنلاین جابجا شوند یعنی در بعضی مواقع خاموش هستند و مواقعی هم روشن یا باتری تمام میکنند.
و همچنین فریم ورک باید مکانیزم self-healing داشته باشد برای fault های موقتی مثل network faults, وnode level faults. همچنین خطای دسترسی غیرمجاز یا server crash failure یا حتی یک خطای دیگری که میتوان اشاره کرد failure omission که برای وقتی است که سرور مبدا هیچ incoming request را دریافت نمیکند از سرور مقصد.
1. چارچوب اول: Eclipse Smarthome Framework
این Eclipse Smart Home (ESH) درواقع یک فریم ورک connection and integration برای خانه‌های هوشمند مجهز به اینترنت اشیا میباشد. این فریم ورک مستقل از ویژگی های اتصال سخت افزار میباشد و همچنین بر اجرای یک اتصال دهنده به چارچوب تاکید می‌کند که به این connector، binding گفته می‌شود و انتظار می‌رود که حداقل یک بار و تنها یک بار برای یک پروتکل ارتباطی خاص پیاده‌سازی شده است.
این فریم ورک ESH بسیار مشهور و متن باز (open source) میباشد زیرا توسط تکنولوژی openHAB پیاده سازی شده است. این platformبه عنوان مرکز خانه هوشمند شما اجرا می‌شود و توانایی یکپارچه سازی
دستگاه‌های مختلف در خانه هوشمند شما را دارد و توسط فروشگاه‌های بزرگ برای تعداد زیادی از خانه‌های هوشمند نصب شده است. ESH بر 5 ویژگی تاکید می‌کند:
یک: Operating System
کمک می‌کند تا روی سیستم عامل‌های مختلف به راحتی اجرا شوند مثل: Windows, macOS, Linux
دو: The Application Container or Runtime Environment
به طور کامل در جاوا نوشته شده است و از Runtimes (Eclipse Equinox) OSGi استفاده می‌کند.
مفهوم Open Services Gateway Initiative (OSGi)، به عنوان سیستم پویای ماژول برای جاوا شناخته می‌شود که توانایی این چارچوب را برای توسعه برنامه‌های کاربردی ماژولار آسان می‌کند.
از نقطه نظر کد، Eclipse Equinox™پیاده‌سازی مشخصات چارچوب اصلی OSGi میباشد که مجموعه‌ای از package ها که سرویس‌های اختیاری مختلف OSGi و زیرساخت‌های دیگر را برای اجرای سیستم‌های مبتنی بر OSGi پیاده‌سازی میکنند. درواقع کاربرد آن اجرای OSGI در محیط نرم افزار Eclipse میباشد.
سه: Data Management and Messaging
رویکرد SOA در ESHبرای پیاده‌سازی از یک Event Bus استفاده می‌کند که قابلیت دسترسی از محیط بیرون را دارد و از پروتکل های SSEو MQTT استفاده می‌کند. همچنین ساختار ESH دارای مکانیزم‌های ماندگاری برای database storage میباشد.
چهار: Remote Management
فریم ورک ESH طوری طرای شده است که به راحتی میتوان خانه خود را از راه دور نظارت و monitor کرد.
چارچوب دوم: Calvin Framework
یک فریم ورک ترکیبی میباشد که از IOT و Cloud Programming استفاده می‌کند و بیشترین کاربرد آن در صنعت بهداشت و درمان میباشد.
این فریم ورک برای توصیف پروتکل‌های مختلف از یک declarative language به نام CalvinScript استفاده می‌کند.
درdeploability این فریم‌ورک توجه ویژه‌ای به پیاده‌سازی توزیع شده در زمان runtime environmentدارد. این فریم‌ورک توجه ویژه‌ای بهlocality, performance requirements, connectivity وrequirements and resources دارد که به راحتی سربار و اضافه بار در زمان اجرا را کاهش می‌دهد.
در واقع این فریم ورک از cloud computing برای اجرای محاسبات پیچیده در دستگاه‌های مختلف بیمارستانی که توزیع شده هستند استفاده می‌کند و میتواند به صورت همزمان با استفاده از Cloud system اقدام به آپدیت نرم افزاری دستگاه‌های توزیع شده کند که در بخش‌های حساسی مثل مراکز درمانی از اهمیت خاصی برخوردار می‌باشند. یکی از توانایی های این فریم ورک، process هایی که منابع زیادی را مصرف میکنند همانند image processing را محدود میکنند.
چارچوب سوم: SOCRADES framework
SOCRADES یک معماری یکپارچه‌سازی مبتنی بر سرویس است که components های عمومی را برای کمک به مدل سازی فرآیندهای دقیق ارائه می‌دهد. همچنین این فریم ورک از وب سرویس‌های مایکروسافت به نام DPWS برای ارتباط با لایه میانی یا همان middle ware layer (که در بخش2 مطرح شد) استفاده می‌کند.
این فریم ورک بیشتر برای سیستم‌های ناهمگن کاربرد دارد. Enterprise Application componentآن یک رابط کاربری گرافیکی GUI آسان برای استفاده را در اختیار کاربران قرار می‌دهد و در نتیجه مدت زمان deployment را کاهش می‌دهد و مدیریت سیستم را سهل و آسان می‌کند.
چارچوب چهارم: AllJoyn
یک چارچوب open source میباشد. هدف اصلی آن connection و integration صرف نظر از ماژول‌های مختلفی که بایکدیگر در ارتباط هستند و همچنین سیستم عامل‌های مختلف.
این چارچوب برای انتزاع و سادگی بیشتر از یک API استفاده می‌کند برای کشف شبکه بین دستگاه‌ها و همچنین پیچیدگی کشف دستگاه‌های مجاور از طریق ایجاد session مثل(multiple, group, point to point session) بین دستگاه‌ها برای تیجاد ارتباط امن بین آن‌ها فراهم می‌کند.
این چارچوب به صورت کلی شامل سرویس‌ها و interfaceهایی هست که توسط توسعه دهنده‌ها برای یکپارچه کردن برنامه‌ها و دستگاه‌ها به کار می‌رود. این چارچوب بیشتر بر بستر local network اجرا می‌شود ولی قابلیت اجرا بر بستر cloud را نیز دارد و تمام دستگاه‌ها از طریق یک gateway با دنیای اینترنت ارتباط برقرار می‌کند.
چارچوب پنجم: FRASAD(FRAmework for sesor Application Development)
این چارچوب برخلاف مدل‌های قبلی مبتنی بر model driven میباشد پس کد برنامه تولید شده از یک مدل از پیش طراحی شده تولید می‌شود.
این چارچوب در واقع یک افزونه(extension) میباشد که که اقدام به افزودن و یکپارچه کردن 2لایه APLیا همان Application Layer و OALیا همان Operating System Abstraction Layer میباشد که هدف اصلی این 2لایه ایجاد یک سطح انتزاع برای پنهان کردن جزئیات میباشد.
این چارچوب از (MDA) Model Driven Architectureطبعیت می‌کند که به عنوان یک رویکرد طراحی نرم‌افزار کمک می‌کند چارچوب FRASAD یک مرز بین application logic و business logic قائل شود. استفاده از MDA این قابلیت را به چارچوب FRASAD می‌دهد که با تکنولوژی‌های مختلف مانند J2EE و همچنین .NET میتوان پیاده سازی کرد.
چارچوب ششم: AVIOT
یکی دیگر از چارچوب‌ها برای خانه‌های هوشمند و شهر هوشمند میباشد که بر خلاف سایر چارچوب‌ها بحث سه بعدی 3D و بصری سازی در آن مطرح میباشد. یکی دیگر از مزایای این چارچوب که میتوان اشاره کرد، کاربر نهایی یا همان end user میتواند به راحتی و بدون داشتن دانش قبلی از معماری یا ارتباط سیستمی سنسورها اقدام به تغییر پنل کاربری نماید و عملا پنل را برای خود سفارشی سازی کند. زبان پیاده سازی این چارچوب یکی از زبانهای scripty میباشد و همچنین این چارچوب بر بستر وب پیاده سازی شده است.
1.4 شناسایی و طبقه بندی خدمات سرویس ها
معماری میکروسرویس به 2 دسته تقسیم می‌شود: 1. Functional Services 2. Non-Function Service
مفهوم اول Functional Services: به این معنی است که خدمات توسط یک سیستم یا دستگاه خارجی مورد استفاده قرار میگیرند.
مفهوم دوم Services Non-Function: مربوط به عملکرد مورد اعتماد سیستم میباشد مثل مباحث ورود و امنیت: authentication, monitoring, authoring, auditing Logging,.
ارتباط این 2 مفهوم با لایه میانی معماری اینترنت اشیا به صورت زیر میباشد:
2.4 مفهوم Service Atomity
در میکروسرویس‌ها، تأثیر سرویس‌های ریز به توسعه، آزمایش، استقرار و نگهداری نرم افزار کمک می‌کند. ارتباط این سرویس‌های ریزدانه بین دستگاه‌های مختلف توسط پروتکل‌هایی مانند MQTT, AMQP برقرار می‌شود.
این سرویس‌های ریزدانه در عملکرد performance و مدیریت تراکنش‌ها مشکل ایجاد می‌کند. فرض کنید طبق شکل پایین، تراکنش بانکی به سه سرویس A,B,Cنیاز داشته باشد مجموع زمان پردازش هر یک از سرویس‌ها به تریب TA, TB, Tc باشد و هریک 100میلی ثانیه طول بکشد مجموعا 300 میلی ثانیه طول می‌کشد تا برای انجام یک تراکنش سرویس ما اقدام به ارائه سرویس‌ها در زمان کافی به Service consumer کند.
در نتیجه با به کارگیری یک Service Assembler اقدام به پردازش و توزیع سرویس‌ها کرده و مدت زمان مصرفی توسط سرویس ها را کاهش می‌دهد، درنتیجه یک سطح از انتزاع ایجاد می‌کند به عنوان مثال یک سرویس به نام X ارائه می‌دهد و service consumer به راحتی از سرویس Xاستفاده می‌کند.
3.4 مفهوم Interoperability in IoT
در معماری میکروسرویس از API Layer به جای ESBاستفاده می‌شود. یکی از مزایای API Layer ، یک سرویس دانه درشت را می توان به سرویس های دانه ریزتر تقسیم کرد یا بالعکس.
به واسطه API Layer میتواند REST API های مختلفی را ایجاد کرد و از طریق پروتکل‌های مختلف با دستگاه و سیستم و سنسورها ارتباط برقرار کنند
به واسطه این رویکرد میتوان به راحتی بخشی از کاستی های معماری سرویس گرا در availability, performance, scalability را کاهش داد.
این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی میباشد.
منابع:
