مشکل همیشه خرابی دستگاه نیست


فرض کنید چند دستگاه الکترونیکی در یک گلخانه، کارگاه، ساختمان یا سایت صنعتی دارید.


همه چیز به‌ظاهر درست کار می‌کند؛ تا زمانی که یک تماس دریافت می‌کنید:


«دستگاه کار نمی‌کند.»


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


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


در چنین شرایطی معمولاً اولین راه‌حل، فرستادن یک نفر به محل است.


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


آنلاین بودن فقط یک چراغ سبز نیست


در یک سیستم متصل، وضعیت آنلاین یا آفلاین بودن دستگاه یکی از ساده‌ترین اما مهم‌ترین اطلاعات است.


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


این موضوع در پروژه‌هایی که دستگاه‌ها در نقاط مختلف قرار گرفته‌اند اهمیت بیشتری پیدا می‌کند.


برای مثال تصور کنید ده‌ها تجهیز در چند مکان مختلف دارید. بررسی دستی هر دستگاه عملاً زمان‌بر و پرهزینه خواهد بود.


یک داشبورد مرکزی می‌تواند وضعیت تمام آن‌ها را در یک محیط نمایش دهد.


آخرین داده می‌تواند اولین سرنخ باشد


فرض کنید یک دستگاه ناگهان آفلاین شده است.


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


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


ممکن است چند دقیقه قبل از قطع ارتباط:


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

همین اطلاعات می‌تواند به پیدا کردن علت احتمالی مشکل کمک کند.


مانیتورینگ Real-Time فقط برای تماشا نیست


گاهی تصور می‌شود مانیتورینگ لحظه‌ای فقط یعنی چند عدد روی داشبورد مرتب تغییر کنند.


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


برای مثال در یک گلخانه می‌توان دما و رطوبت را لحظه‌ای بررسی کرد.


در یک تابلو برق می‌توان توان مصرفی یا اطلاعات سنسورها را مشاهده کرد.


در یک سیستم آبیاری می‌توان وضعیت پمپ یا مخزن را بررسی کرد.


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


در همه این سناریوها، هدف اصلی یک چیز است:


دانستن وضعیت واقعی دستگاه بدون نیاز به حضور کنار آن.


کنترل از راه دور مرحله بعدی است


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


برای مثال ممکن است لازم باشد:


یک رله خاموش شود
یک پمپ روشن شود
دستگاه ری‌استارت شود
حالت عملکرد تغییر کند
یک خروجی فعال یا غیرفعال شود

اگر دستگاه از چنین Actionهایی پشتیبانی کند، اجرای فرمان از راه دور می‌تواند بسیاری از مراجعات غیرضروری به محل را حذف کند.


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


چرا ساخت یک پنل جدا برای هر پروژه منطقی نیست؟


بسیاری از پروژه‌های IoT با یک سنسور و یک برد شروع می‌شوند.


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


اما با افزایش تعداد دستگاه‌ها، پروژه پیچیده‌تر می‌شود.


نیاز به مدیریت کاربران، دستگاه‌ها، داده‌های تاریخی، ارتباط Real-Time، دسترسی‌ها و Actionهای مختلف ایجاد می‌شود.


در این مرحله بخش زیادی از زمان تیم به جای توسعه خود محصول، صرف ساخت زیرساخت IoT می‌شود.


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


هر دستگاه می‌تواند قابلیت متفاوتی داشته باشد


یک نکته مهم در طراحی پلتفرم IoT این است که همه دستگاه‌ها شبیه هم نیستند.


ممکن است یک دستگاه فقط دما ارسال کند.


دستگاه دیگر چند سنسور، یک رله و موتور داشته باشد.


سیستم دیگری شاید ده‌ها مقدار مختلف تولید کند.


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


دستگاه باید بتواند مشخص کند چه داده‌هایی تولید می‌کند و چه فرمان‌هایی را می‌تواند دریافت کند.


در این حالت یک پلتفرم واحد می‌تواند برای پروژه‌های بسیار متفاوت مورد استفاده قرار گیرد.


MQTT چرا در چنین معماری‌ای کاربردی است؟


در بسیاری از پروژه‌های IoT، ارتباط دستگاه‌ها از طریق MQTT انجام می‌شود.


MQTT یک پروتکل سبک مبتنی بر مدل Publish و Subscribe است که برای انتقال سریع پیام میان دستگاه و سرور بسیار مناسب است.


به جای اینکه دستگاه دائماً از سرور سؤال کند که آیا فرمان جدیدی وجود دارد، می‌تواند روی Topic مشخصی منتظر پیام بماند.


از طرف دیگر اطلاعات سنسورها نیز می‌توانند بلافاصله روی Topicهای مربوط به همان دستگاه منتشر شوند.


این معماری باعث می‌شود دریافت داده و ارسال فرمان به شکل Real-Time و با سربار نسبتاً کم انجام شود.


سوکت قرار است این فاصله را کمتر کند


سوکت با هدف ایجاد بستری برای اتصال و مدیریت دستگاه‌های IoT طراحی شده است.


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


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


دستگاه شما ممکن است دور باشد؛ اطلاعاتش نباید دور باشد


یکی از مهم‌ترین مزایای اینترنت اشیا همین است.


برای دانستن وضعیت یک دستگاه نباید حتماً کنار آن ایستاده باشید.


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


گاهی یک هشدار ساده یا مشاهده چند دقیقه از داده‌های اخیر می‌تواند جلوی ساعت‌ها عیب‌یابی را بگیرد.


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