وقتی از اینترنت اشیا صحبت می کنیم، معمولا تصویر یک سنسور، برد ESP32 یا وسیله ای متصل به Wi-Fi در ذهن شکل می گیرد. اما اتصال یک دستگاه به اینترنت، به تنهایی یک سامانه IoT ایجاد نمی کند.
دستگاه باید بتواند داده های خود را به مقصد مشخصی ارسال کند، فرمان دریافت کند، هویت آن تایید شود، اطلاعاتش ذخیره شود و بر اساس شرایط مختلف واکنش مناسب انجام گیرد. مجموعه این وظایف در بخشی انجام می شود که آن را سرور IoT می نامیم.
سرور IoT چیست؟
سرور IoT زیرساختی است که میان دستگاه های فیزیکی، داده ها، کاربران و منطق اتوماسیون قرار می گیرد. این سرور پیام دستگاه ها را دریافت می کند، اعتبار آنها را می سنجد، داده ها را پردازش و ذخیره می کند و در صورت نیاز فرمانی را برای دستگاه ارسال می کند.
سرور IoT لزوما یک رایانه یا یک نرم افزار واحد نیست. در یک سامانه حرفه ای ممکن است چند سرویس مستقل وجود داشته باشد:
سرویس شناسایی دستگاه ها
درگاه دریافت داده
Message Broker
پایگاه داده
موتور قوانین و اتوماسیون
صف فرمان ها
داشبورد مدیریت
سامانه ثبت رخداد و خطا
سرویس به روزرسانی دستگاه ها
این اجزا می توانند روی یک سرور کوچک اجرا شوند یا در پروژه های بزرگ میان چند سرور توزیع شوند.
مسیر حرکت داده در یک سامانه IoT
یک معماری ساده اینترنت اشیا معمولا از این مسیر تشکیل می شود:
دستگاه یا سنسور
شبکه ارتباطی
سرور یا Message Broker
لایه پردازش و اتوماسیون
پایگاه داده
داشبورد یا نرم افزار کاربر
برای مثال یک ESP32 دمای محیط را اندازه گیری می کند. داده از طریق Wi-Fi به سرور ارسال می شود. سرور هویت دستگاه را بررسی می کند، مقدار دما را در پایگاه داده ذخیره می کند و قانون تعریف شده را اجرا می کند.
اگر دما بیشتر از حد مجاز باشد، سرور یک فرمان روشن شدن فن ایجاد می کند. دستگاه فرمان را دریافت می کند، فن را روشن می کند و نتیجه اجرای فرمان را دوباره به سرور گزارش می دهد.
در این فرایند، سرور فقط محل ذخیره عدد دما نیست. سرور هماهنگ کننده کل عملیات است.
وظایف اصلی سرور IoT
اولین وظیفه سرور، شناسایی دستگاه است. هر دستگاه باید یک شناسه یکتا داشته باشد تا داده های آن با دستگاه های دیگر اشتباه نشود.
در کنار شناسه، معمولا یک کلید، توکن یا گواهی امنیتی نیز برای دستگاه تعریف می شود. سرور با استفاده از این اطلاعات تشخیص می دهد که پیام واقعا از یک دستگاه مجاز ارسال شده است.
وظیفه دوم، دریافت داده است. این داده می تواند شامل مقدار سنسور، وضعیت باتری، قدرت سیگنال، موقعیت، وضعیت خروجی ها، نسخه نرم افزار یا گزارش خطا باشد.
وظیفه سوم، ذخیره سازی است. بعضی اطلاعات فقط وضعیت فعلی دستگاه را نشان می دهند، در حالی که برخی دیگر باید به صورت تاریخچه نگهداری شوند.
وظیفه چهارم، اجرای قوانین و اتوماسیون است. برای مثال:
اگر دما از ۳۵ درجه بیشتر شد، فن روشن شود.
اگر رطوبت خاک کمتر از مقدار تعیین شده بود، آبیاری آغاز شود.
اگر دستگاه برای پنج دقیقه پیام ارسال نکرد، هشدار قطع ارتباط ثبت شود.
اگر ولتاژ باتری کاهش یافت، اعلان سرویس ارسال شود.
وظیفه پنجم، ارسال فرمان به دستگاه است. فرمان ممکن است بلافاصله ارسال شود یا در صف باقی بماند تا دستگاه دوباره آنلاین شود.
MQTT؛ پروتکل محبوب اینترنت اشیا
MQTT یکی از پرکاربردترین پروتکل ها در پروژه های IoT است. این پروتکل بر اساس مدل Publish و Subscribe کار می کند.
دستگاه داده خود را در یک Topic منتشر می کند. سرویس ها یا دستگاه های دیگری که مشترک آن Topic هستند، پیام را دریافت می کنند.
برای مثال:
یک دستگاه مقدار دما را در Topic مربوط به خود منتشر می کند.
داشبورد مشترک داده های همان Topic است و مقدار جدید را نمایش می دهد.
موتور اتوماسیون نیز پیام را دریافت و قوانین را بررسی می کند.
سرور مرکزی MQTT معمولا Broker نامیده می شود. Broker پیام ها را از منتشرکننده دریافت و به مشترکان مربوط می رساند.
مزیت MQTT، حجم کم پیام، ارتباط دائمی و مناسب بودن برای دستگاه های محدود از نظر حافظه و پردازنده است. با این حال، استفاده از MQTT به تنهایی کافی نیست. مدیریت کاربران، ذخیره داده ها، قوانین اتوماسیون و داشبورد باید در لایه های دیگر پیاده سازی شوند.
HTTP و REST API
در بسیاری از پروژه ها، دستگاه داده را از طریق HTTP یا HTTPS به یک API ارسال می کند.
برای مثال دستگاه یک درخواست POST شامل شناسه، دما، ولتاژ باتری و زمان ثبت داده به سرور می فرستد. سرور درخواست را بررسی می کند و پاسخ موفق یا خطا برمی گرداند.
HTTP برای شروع پروژه ساده تر است و تقریبا روی هر هاستی قابل اجراست. این روش برای دستگاه هایی که هر چند دقیقه یک بار داده ارسال می کنند، انتخاب مناسبی است.
اما اگر ارتباط دائمی، فرمان لحظه ای یا تبادل تعداد زیادی پیام لازم باشد، MQTT یا WebSocket می تواند کارآمدتر باشد.
WebSocket و ارتباط لحظه ای
WebSocket یک ارتباط دوطرفه و مداوم میان کلاینت و سرور ایجاد می کند. این روش بیشتر برای داشبوردهای زنده، نمایش لحظه ای داده ها یا کنترل سریع تجهیزات استفاده می شود.
برای مثال هنگامی که وضعیت یک خروجی در دستگاه تغییر می کند، سرور می تواند بدون بارگذاری مجدد صفحه، مقدار جدید را به داشبورد ارسال کند.
در یک معماری کامل ممکن است دستگاه ها با MQTT ارتباط داشته باشند، APIهای مدیریتی از HTTPS استفاده کنند و داشبورد اطلاعات زنده را از طریق WebSocket دریافت کند.
Message Broker با سرور برنامه چه تفاوتی دارد؟
Broker مسئول دریافت و توزیع پیام است. وظیفه آن این است که پیام منتشر شده در یک Topic را به مشترکان مربوط برساند.
سرور برنامه یا Application Server منطق اصلی سامانه را اجرا می کند. این سرور کاربران و دستگاه ها را مدیریت می کند، اطلاعات را در پایگاه داده می نویسد، قوانین را اجرا می کند و خروجی مناسب تولید می کند.
در پروژه های کوچک ممکن است این دو بخش در یک برنامه ترکیب شوند. در پروژه های بزرگ تر بهتر است Broker، API، موتور اتوماسیون و پایگاه داده از یکدیگر جدا باشند.
صف فرمان ها
یکی از اجزای مهم سرور IoT، Command Queue یا صف فرمان ها است.
فرض کنیم کاربر فرمان روشن شدن یک دستگاه را صادر می کند، اما دستگاه در آن لحظه به اینترنت متصل نیست. اگر سرور فقط یک بار فرمان را ارسال کند، فرمان از بین می رود.
در معماری مبتنی بر صف، فرمان با مشخصات زیر ذخیره می شود:
شناسه فرمان
شناسه دستگاه مقصد
نوع فرمان
اطلاعات مورد نیاز برای اجرا
زمان ایجاد
زمان انقضا
تعداد تلاش ها
وضعیت اجرا
دستگاه پس از اتصال، فرمان های در انتظار خود را دریافت می کند. پس از اجرا نیز یک تایید یا Acknowledgement برای سرور می فرستد.
سرور بر اساس این پاسخ، وضعیت فرمان را از «در انتظار» به «اجرا شده» یا «ناموفق» تغییر می دهد.
وجود شناسه یکتا برای هر فرمان اهمیت زیادی دارد. اگر ارتباط قطع شود و سرور فرمان را دوباره ارسال کند، دستگاه باید بتواند تشخیص دهد که فرمان قبلا اجرا شده است. در غیر این صورت ممکن است یک عملیات چند بار تکرار شود.
ثبت وضعیت فعلی و تاریخچه
داده های IoT را می توان به دو گروه اصلی تقسیم کرد.
گروه اول وضعیت فعلی دستگاه است؛ مانند روشن یا خاموش بودن رله، آخرین دما، میزان باتری و زمان آخرین ارتباط.
گروه دوم تاریخچه داده هاست؛ مانند تغییرات دما در یک ماه یا تعداد دفعات روشن شدن موتور.
برای نمایش سریع داشبورد، بهتر است آخرین وضعیت هر دستگاه به صورت جداگانه نگهداری شود. برای تحلیل روندها نیز داده های تاریخی در جدول یا پایگاه داده مناسب ذخیره شوند.
ذخیره تمام پیام های خام برای همیشه می تواند حجم پایگاه داده را به سرعت افزایش دهد. بنابراین باید از ابتدا درباره مدت نگهداری داده، فشرده سازی، تجمیع و حذف اطلاعات قدیمی تصمیم گیری شود.
مدیریت دستگاه ها
یک سرور IoT حرفه ای باید فهرستی از دستگاه های ثبت شده داشته باشد. اطلاعات هر دستگاه می تواند شامل موارد زیر باشد:
شناسه یکتا
نام و نوع دستگاه
مالک یا کاربر مرتبط
نسخه سخت افزار
نسخه نرم افزار
توکن دسترسی
زمان آخرین ارتباط
آدرس شبکه
وضعیت فعال یا غیرفعال
قابلیت های دستگاه
هر دستگاه باید فقط به اطلاعات و فرمان های مربوط به خود دسترسی داشته باشد. یک سنسور دما نباید بتواند داده های دستگاه دیگر را تغییر دهد یا فرمان های یک سیستم متفاوت را دریافت کند.
امنیت سرور IoT
امنیت در اینترنت اشیا فقط به گذاشتن رمز روی داشبورد محدود نمی شود. هر دستگاه متصل به اینترنت می تواند یک نقطه ورود احتمالی باشد.
ارتباط دستگاه و سرور باید تا حد امکان با TLS و پروتکل های امن مانند HTTPS یا MQTTS انجام شود.
استفاده از یک توکن مشترک برای همه دستگاه ها اشتباه است. اگر توکن یک دستگاه افشا شود، مهاجم نباید بتواند به تمام سامانه دسترسی پیدا کند.
برای هر دستگاه باید اعتبارنامه مستقل تعریف شود. همچنین امکان لغو یا تعویض توکن بدون تغییر سایر دستگاه ها وجود داشته باشد.
سرور باید ورودی ها را اعتبارسنجی کند. دستگاه نباید بتواند داده ای با حجم نامحدود، ساختار نامعتبر یا مقادیر خارج از محدوده ارسال کند.
محدودیت تعداد درخواست، ثبت تلاش های ناموفق، گزارش رخدادهای مشکوک و نگهداری Audit Log نیز از اجزای مهم امنیت هستند.
توکن ها و کلیدهای حساس نباید داخل مخزن عمومی کد قرار گیرند. در محصولاتی که امنیت بالاتری نیاز دارند، استفاده از Secure Element یا روش های امن تر نگهداری کلید در دستگاه توصیه می شود.
به روزرسانی از راه دور
دستگاه های IoT ممکن است سال ها در محل نصب باقی بمانند. اگر برای اصلاح خطا یا آسیب پذیری امنیتی نیاز به دسترسی فیزیکی باشد، نگهداری تعداد زیادی دستگاه بسیار دشوار خواهد شد.
به همین دلیل بسیاری از سامانه های IoT از OTA یا به روزرسانی از راه دور استفاده می کنند.
در این روش، سرور نسخه جدید نرم افزار را معرفی می کند. دستگاه فایل را از یک منبع امن دریافت، صحت و امضای آن را بررسی و سپس به روزرسانی را نصب می کند.
یک فرایند OTA ایمن باید امکان بازگشت به نسخه قبلی را نیز داشته باشد. اگر نسخه جدید اجرا نشد، دستگاه نباید برای همیشه از دسترس خارج شود.
سرور ابری یا سرور اختصاصی؟
سرویس های ابری آماده، راه اندازی اولیه را سریع می کنند. داشبورد، پایگاه داده، مدیریت دستگاه و ابزارهای اتوماسیون ممکن است از قبل آماده باشند.
این سرویس ها برای نمونه سازی و شروع سریع مناسب هستند، اما می توانند محدودیت هایی نیز ایجاد کنند:
وابستگی به یک سرویس دهنده
تغییر تعرفه یا محدودیت حساب
محدودیت تعداد دستگاه و پیام
دشواری انتقال داده ها
عدم دسترسی کامل به منطق داخلی
توقف یا تغییر سرویس
محدودیت در سفارشی سازی
در مقابل، سرور اختصاصی کنترل بیشتری در اختیار توسعه دهنده قرار می دهد. داده ها، منطق اتوماسیون، APIها و مسیر توسعه در اختیار مالک پروژه باقی می مانند.
اما استقلال به معنای حذف مسئولیت نیست. نگهداری سرور، پشتیبان گیری، امنیت، مانیتورینگ، به روزرسانی و رفع اختلال بر عهده تیم پروژه خواهد بود.
انتخاب درست همیشه به معنای انتخاب سرور اختصاصی یا سرویس ابری نیست. در بعضی پروژه ها معماری ترکیبی بهترین نتیجه را دارد. داده های حساس و منطق اصلی می توانند روی زیرساخت اختصاصی باقی بمانند و بعضی خدمات جانبی از سرویس های ابری دریافت شوند.
آیا هاست اشتراکی برای IoT کافی است؟
برای پروژه های ساده که دستگاه هر چند دقیقه یک درخواست HTTPS ارسال می کند، یک هاست مناسب با PHP و پایگاه داده می تواند کافی باشد.
اما اجرای Broker دائمی MQTT، WebSocket، پردازش پس زمینه، صف های حرفه ای و سرویس های همیشگی معمولا به VPS، سرور ابری یا سرویس مدیریت شده نیاز دارد.
هاست اشتراکی اغلب برای اجرای پردازش های دائمی محدودیت دارد. بنابراین انتخاب نوع میزبانی باید بر اساس معماری واقعی انجام شود، نه فقط تعداد دستگاه ها.
یک پروژه با صد دستگاه کم مصرف ممکن است فشار کمی ایجاد کند، اما ده دستگاه با ارسال چندصد پیام در ثانیه می توانند به زیرساخت قوی تری نیاز داشته باشند.
مانیتورینگ و ثبت خطا
سامانه IoT بدون مانیتورینگ، فقط تا زمانی قابل اعتماد است که مشکلی رخ نداده باشد.
سرور باید بتواند موارد زیر را ثبت و گزارش کند:
دستگاه های آفلاین
افزایش خطاهای احراز هویت
تاخیر در پردازش پیام
رشد غیرعادی پایگاه داده
تجمع فرمان ها در صف
مصرف بالای پردازنده و حافظه
پایان فضای ذخیره سازی
قطع ارتباط با Broker
خطاهای تکرارشونده یک دستگاه
وجود داشبورد سلامت سامانه کمک می کند مشکل قبل از آنکه به توقف کامل سرویس تبدیل شود، شناسایی شود.
اشتباهات رایج در طراحی سرور IoT
اولین اشتباه این است که فرض کنیم دستگاه همیشه آنلاین است. قطع اینترنت، ریست، ضعف سیگنال و قطعی برق بخشی طبیعی از دنیای IoT هستند.
اشتباه دوم، استفاده از یک توکن برای تمام دستگاه هاست.
اشتباه سوم، ارسال فرمان بدون شناسه، تاریخ انقضا و تایید اجراست.
اشتباه چهارم، ذخیره اطلاعات بدون Timestamp معتبر است. سرور باید بداند داده چه زمانی اندازه گیری و چه زمانی دریافت شده است.
اشتباه پنجم، قرار دادن مستقیم دستگاه در اینترنت است. معمولا بهتر است دستگاه ارتباط خروجی امنی با سرور برقرار کند و پورت مدیریتی آن در اینترنت عمومی باز نباشد.
اشتباه ششم، نداشتن نسخه برای ساختار پیام است. با تغییر Firmware ممکن است فرمت داده نیز تغییر کند. وجود Schema Version از ناسازگاری دستگاه های قدیمی و جدید جلوگیری می کند.
اشتباه هفتم، وابسته کردن کامل منطق حیاتی به سرور است. عملیات ایمنی مانند قطع موتور در دمای خطرناک باید در خود دستگاه نیز اجرا شود. اگر اینترنت قطع شود، سامانه نباید کنترل حیاتی را از دست بدهد.
نگاه ARDUnia به زیرساخت IoT
هدف ARDUnia IoT مخالفت با سرویس های ابری نیست. هدف، حفظ اختیار در بخش هایی است که برای آینده پروژه اهمیت دارند.
در این معماری، دستگاه باید هویت مشخص داشته باشد، داده ها از مسیر کنترل شده وارد شوند، فرمان ها قابل پیگیری باشند و منطق اتوماسیون به یک سرویس دهنده غیرقابل جایگزین وابسته نباشد.
زیرساخت اختصاصی اجازه می دهد ارتباط میان پروژه های سخت افزاری، ARDUnia AI و موتور اتوماسیون بر اساس نیاز واقعی طراحی شود.
برای مثال یک درخواست متنی می تواند توسط ARDUnia AI تحلیل و به فرمان ساختارمند تبدیل شود. این فرمان پس از بررسی مجوزها در صف قرار می گیرد و دستگاه مقصد آن را دریافت می کند. نتیجه اجرا نیز به صورت یک رویداد ثبت می شود.
در چنین ساختاری، هوش مصنوعی مستقیما و بدون کنترل به تجهیزات فرمان نمی دهد. سرور IoT مانند یک لایه امنیتی و اجرایی میان تصمیم، فرمان و دستگاه قرار می گیرد.
جمع بندی
سرور IoT قلب پنهان یک سامانه اینترنت اشیا است. بردها و سنسورها داده را تولید می کنند، اما این سرور است که به داده معنا می دهد، دستگاه ها را مدیریت می کند، فرمان ها را به مقصد می رساند و اتوماسیون را اجرا می کند.
یک سرور مناسب باید فقط برای شرایط عادی طراحی نشده باشد. قطع ارتباط، تکرار پیام، آفلاین شدن دستگاه، انقضای فرمان، تغییر نسخه نرم افزار و تلاش برای دسترسی غیرمجاز باید از ابتدا در معماری آن دیده شوند.
انتخاب میان سرویس ابری، سرور اختصاصی یا معماری ترکیبی به اندازه پروژه، حساسیت داده ها، توان نگهداری و مسیر توسعه آینده بستگی دارد.
اینترنت اشیا زمانی به یک سامانه واقعی تبدیل می شود که ارتباط میان دستگاه، داده، تصمیم و عمل قابل اعتماد، امن و قابل کنترل باشد.