بسیاری از پروژه‌های تجاری اینترنت اشیا با حسگرها، دروازه‌ها (gateways) و پلتفرم‌های ابری شروع می‌شوند. رابط کاربری بعد از همه این‌ها می‌آید. وقتی هم که نوبت به آن می‌رسد، آسان‌ترین گزینه معمولاً این است که هر متریک و ابزار کنترلی ممکنه را روی یک داشبورد وب قرار دهیم.
این رویکرد شاید برای تیم مهندسی که سیستم را ساخته است کار کند، اما اغلب برای افرادی که هر روز ساختمان را اداره می‌کنند شکست می‌خورد.
یک مدیر تأسیسات، مسئول پذیرش، تکنسین نگهداری و تعمیرات، نگهبان امنیت و مستأجر همگی به اطلاعات یکسانی نیاز ندارند. آن‌ها ممکن است تلفن شرکتی مشابهی نداشته باشند، به اپلیکیشن‌های یکسانی دسترسی نداشته باشند یا حتی متعلق به یک سازمان نباشند؛ با این حال، همه آن‌ها با یک محیط فیزیکی واحد تعامل دارند.
اینجاست که یک داشبورد مشترک اینترنت اشیا مفید می‌شود. یک صفحه نمایش در لابی، اتاق کنترل، محوطه پذیرش، فضای جلسه، یا راهروی خدماتی می‌تواند دید عملیاتی مشترکی به افراد بدهد. با این حال، طراحی آن صفحه نمایش نیازمند رویکردی متفاوت با طراحی یک اپلیکیشن موبایل شخصی است.
شروع با تصمیمات عملیاتی، نه فهرست تجهیزات
نسخه اول بسیاری از داشبوردها آینه‌ای از پایگاه داده تجهیزات است. این داشبوردها برای هر ترموستات، چراغ، حسگر کیفیت هوا، نقطه دسترسی (access point)، دوربین و کنتور یک کاشی (tile) دارند. نتیجه کار از نظر فنی کامل است اما از نظر عملیاتی ضعیف عمل می‌کند.
افراد به ندرت به سراغ رابط کاربری ساختمان می‌روند و بپرسند: «حسگر شماره ۱۸۴ چه گزارشی می‌دهد؟» آن‌ها سؤالاتی از این قبیل می‌پرسند:
- آیا هیچ اتاق اشغال‌شده‌ای نامطلوب است؟
- آیا ورودی ناامن است؟
- کدام فضاهای جلسه هم‌اکنون در دسترس هستند؟
- آیا مصرف انرژی خارج از محدوده انتظار است؟
- پیش از شروع شیفت بعدی به چه چیزی باید رسیدگی شود؟
کار را با فهرست کردن تصمیماتی که هر کاربر باید بگیرد شروع کنید. سپس حداقل داده‌های مورد نیاز برای آن تصمیمات را مشخص کنید. این کار سلسله‌مراتب معمول را معکوس می‌کند: استثناهای عملیاتی در اولویت اول قرار می‌گیرند، زمینه (context) در رتبه دوم قرار می‌گیرد و فهرست کامل تجهیزات برای عیب‌یابی محفوظ می‌ماند.
برای مثال، یک داشبورد تأسیسات نیازی ندارد که ۸۰ عدد خوانش دمای عادی را با وزن بصری یکسانی نشان دهد. این داشبورد باید نشان دهد که دو منطقه اشغال‌شده خارج از محدوده هدف خود هستند، این وضعیت از چه زمانی شروع شده و آیا تجهیزات زیربنایی در حال پاسخگویی هستند یا خیر.
طراحی برای یک محیط مشترک
یک اپلیکیشن شخصی می‌تواند فرض کند که یک فرد احراز هویت‌شده دستگاه را در دست دارد. یک صفحه نمایش مشترک نمی‌تواند چنین فرضی داشته باشد.
افرادی که جلوی آن ایستاده‌اند ممکن است نقش‌ها و دسترسی‌های متفاوتی داشته باشند. این نمایشگر ممکن است برای بازدیدکنندگان نیز قابل دیدن باشد. این موضوع باعث می‌شود طراحی دسترسی بخشی از رابط کاربری باشد، نه صرفاًریالی مربوط به بخش پشتی (backend).
یک مدل مفید، اطلاعات را به سه لایه تقسیم می‌کند:
- زمینه عملیاتی مشترک: اطلاعات ایمنی که به همه کمک می‌کند فضا را درک کنند؛ مانند در دسترس بودن اتاق، وضعیت کلی راحتی، آب‌وهوای محلی، اطلاعیه‌های خدماتی و فعالیت برنامه‌ریزی‌شده بعدی.
- اقدامات مبتنی بر نقش: کنترل‌هایی که پس از شناسایی خود توسط یکی از اعضای پرسنل در دسترس قرار می‌گیرند؛ مانند تغییر نقطه تنظیم منطقه، تأیید یک هشدار، یا قرار دادن تجهیزات در حالت تعمیر و نگهداری.
- عملیات محدودشده: امنیت، کنترل دسترسی، مدیریت دوربین، و دستورات بالقوه مخربی که نیازمند احراز هویت قوی‌تر یا یک ایستگاه کاری جداگانه هستند.
این ساختار نمایشگر مشترک را بدون تبدیل کردن آن به یک کنسول مدیریتی در معرض دید، مفید نگه می‌دارد. همچنین وسوسه حل کردن هر مشکل دسترسی با حذف اطلاعات مفید از روی صفحه را کاهش می‌دهد.
رفتار با زمان‌بندی و آب‌وهوا به عنوان داده‌های عملیاتی
داشبوردهای اینترنت اشیا اغلب به مقادیر زنده حسگرها اولویت می‌دهند و در عین حال با زمان‌بندی‌ها و آب‌وهوا به عنوان عناصر تزئینی برخورد می‌کنند. در ساختمان‌های تجاری، هر دوی این موارد می‌توانند توضیح دهند که چه اتفاقی باید رخ دهد.
دمای اتاق ۲۵ درجه سانتی‌گراد زمانی معنای متفاوتی پیدا می‌کند که اتاق خالی است، زمانی که یک جلسه ده دقیقه دیگر شروع می‌شود و زمانی که یک رویداد بزرگ در جریان است. یک برنامه زمانی مشترک می‌تواند این زمینه را فراهم کند. رزرو جلسات، پنجره‌های نظافت، تحویل بار، کارهای نگهداری و رویدادهای مستأجر می‌توانند به اپراتورها کمک کنند تا یک مشکل واقعی را از یک گذار پیش‌بینی‌شده تشخیص دهند.
آب‌وهوا نیز نقش مشابهی دارد. دمای بیرون، باد، بارش و کیفیت هوا بر تقاضای سیستم تهویه مطبوع (HVAC)، تهویه طبیعی، تولید خورشیدی، آبیاری، عملیات بارگیری و ترافیک بازدیدکنندگان تأثیر می‌گذارند. یک پنل آب‌وهوا زمانی مفید می‌شود که شرایط را به یک تصمیم عملیاتی متصل کند.
به جای نشان دادن فقط یک نماد پیش‌بینی، داشبورد ممکن است نشان دهد که تقاضای سرمایش به‌طور غیرعادی بالا با هشدار گرما همزمان شده است، آبیاری به دلیل انتظار باران می‌تواند به تعویق بیفتد، یا یک کار خدماتی در فضای باز به دلیل وزش باد شدید باید به زمان دیگری موکول شود.
هدف افزودن ویجت‌های بیشتر نیست؛ بلکه توضیح رابطه بین ساختمان، زمان‌بندی آن و شرایط خارجی است.
ساخت سلسله‌مراتب استثنا
هر هشداری مستحق وقفه یکسانی نیست. اگر همه چیز فوری باشد، اپراتورها یاد می‌گیرند که صفحه نمایش را نادیده بگیرند.
یک سلسله‌مراتب استثنا باید حداقل چهار عامل را در نظر بگیرد:
- ایمنی: آیا شرایط می‌تواند بر افراد، امنیت یا تجهیزات حیاتی تأثیر بگذارد؟
- تأثیر عملیاتی: آیا فضایی غیرقابل استفاده شده یا خدماتی مختل شده است؟
- حساسیت زمانی: آیا کسی باید اکنون، در طول شیفت جاری یا بعداً اقدام کند؟
- اطمینان: آیا رویداد با یک خوانش پشتیبانی می‌شود یا با چندین سیگنال مرتبط؟
رابط کاربری باید این تفاوت‌ها را قابل مشاهده کند. یک خطای بحرانی کنترل دسترسی نباید شبیه یک اتاق جلسه نسبتاً گرم به نظر برسد. هشداری که از قبل تخصیص داده شده نباید با یک حادثه تأییدنشده رقابت کند. یک ناهنجاری تکرارشونده حسگر باید شامل تاریخچه کافی باشد تا به تکنسین کمک کند تصمیم بگیرد آیا مشکل واقعی است یا خیر.
این سلسله‌مراتب همچنین از تشدید بهتر (escalation) پشتیبانی می‌کند. نمایشگر مشترک می‌تواند آگاهی ایجاد کند، در حالی که اعلان‌ها و سیستم‌های سفارش کار، مالکیت و پیگیری را مدیریت می‌کنند.
برنامه‌ریزی برای خرابی جزئی
یک ساختمان به این دلیل که یک رابط برنامه کاربردی ابری (Cloud API) در دسترس نیست، از کار نمی‌افتد. داشبورد نیز نباید به یک صفحه نمایش خالی تبدیل شود.
در طول طراحی، مشخص کنید که رابط کاربری هنگام از دست دادن موارد زیر چه کاری انجام خواهد داد:
- اتصال به اینترنت؛
- دسترسی به پلتفرم ابری؛
- یک دروازه (gateway) یا زیرسیستم ساختمانی؛
- داده‌های فعلی آب‌وهوا یا زمان‌بندی؛
- مجوز اجرای یک فرمان.
داده‌های قدیمی باید با آخرین زمان به‌روزرسانی برچسب‌گذاری شوند تا اینکه به عنوان داده‌های فعلی ارائه شوند. کنترل‌های غیرقابل دسترس باید دلیل عدم امکان استفاده از خود را توضیح دهند. اطلاعات محلی در دسترس باید در صورت امکان قابل مشاهده باقی بمانند. اگر دستوری برای تحویل بعدی در صف قرار گیرد، رابط کاربری باید «درخواست‌شده» را از «تکمیل‌شده» متمایز کند.
این جزئیات اعتماد اپراتور را ایجاد می‌کنند. داشبوردی که به طور صادقانه عدم قطعیت را ارتباط می‌دهد، مفیدتر از داشبوردی است که سالم به نظر می‌رسد تا زمانی که کسی متوجه شود داده‌های آن ساعت‌ها پیش از به‌روزرسانی متوقف شده است.
طراحی برای فاصله و تعاملات کوتاه
یک صفحه نمایش مشترک اغلب زمانی دیده می‌شود که شخصی از کنار آن رد می‌شود یا در چند متری آن ایستاده است. جدول‌های متراکم و برچسب‌های کوچکی که روی یک لپ‌تاپ کار می‌کنند، در محیط فیزیکی غیرقابل خواندن می‌شوند.
صفحه اول باید از یک بررسی سریع پشتیبانی کند: حالت کلی، استثناهای مهم، اشغال یا زمان‌بندی فعلی، و تعداد کمی از اقدامات رایج. روندهای تفصیلی، تاریخچه دستگاه و پیکربندی می‌توانند یک سطح عمیق‌تر بنشینند.
روش ورودی نیز اهمیت دارد. یک صفحه لمسی دیواری، صفحه‌ای که با کنترل‌های جهتی کار می‌کند و یک ایستگاه کاری اتاق کنترل به چیدمان‌های متفاوتی نیاز دارند. اهداف لمسی به فضا نیاز دارند. ناوبری جهتی به یک ترتیب تمرکز قابل پیش‌بینی نیاز دارد. یک نمایشگر غیرفعال نباید برای انتقال مهم‌ترین اطلاعات خود نیاز به تعامل داشته باشد.
سؤال درست این نیست که آیا داشبورد روی صفحه نمایش جا می‌شود یا خیر. بلکه این است که آیا یک فرد می‌تواند آن را در زمان و مکانی که در آن واقعاً استفاده خواهد شد، درک کند یا خیر.
عملیاتی کردن داشبورد به عنوان بخشی از ناوگان اینترنت اشیا
هنگامی که صفحات نمایش مشترک در چندین طبقه یا سایت نصب می‌شوند، به نقاط پایانی مدیریت‌شده تبدیل می‌شوند. تیم‌ها به برنامه‌ای برای پیکربندی، به‌روزرسانی‌های نرم‌افزاری، پایش سلامت و بازیابی نیاز دارند.
قابلیت‌های عملیاتی مفید عبارتند از:
- گزارش‌دهی از راه دور سلامت اپلیکیشن و دستگاه؛
- تخصیص طرح‌بندی‌ها بر اساس ساختمان، طبقه یا نقش؛
- استقرار به‌روزرسانی‌ها به صورت مرحله‌ای؛
- بازیابی یک پیکربندی شناخته‌شده پس از تعویض دستگاه؛
- شناسایی نمایشگرهایی که آفلاین هستند یا داده‌های قدیمی نشان می‌دهند؛
- ممیزی اقدامات ممتازی که از رابط‌های مشترک انجام شده است.
یک نمونه اولیه که روی یک تبلت اجرا می‌شود را می‌توان به صورت دستی پیکربندی کرد. استقرار ۲۰۰ صفحه نمایش را نمی‌توان به این شکل مدیریت کرد. عملیات ناوگان باید قبل از اینکه رابط کاربری بخشی از جریان‌های کاری روزانه ساختمان شود، در نظر گرفته شود.
سنجش نتایج، نه فعالیت صفحه نمایش
بازدید صفحات و فشردن دکمه‌ها چیز کمی درباره اینکه آیا یک داشبورد مشترک در حال بهبود عملیات است یا خیر، می‌گویند.
معیارهای بهتر به تصمیماتی گره خورده‌اند که صفحه نمایش برای پشتیبانی از آن‌ها در نظر گرفته شده است. این موارد ممکن است شامل زمان تأیید یک خطا، شکایات مکرر راحتی، بازدیدهای غیرضروری تکنسین، زمان از کار افتادن اتاق جلسه، استثناهای انرژی حل‌شده در طول همان شیفت، یا تعداد سؤالات روتینی که بدون تماس با تیم تأسیسات مدیریت شده‌اند، باشد.
بازخورد کیفی نیز اهمیت دارد. تماشا کنید که هر نقش چگونه از نمایشگر استفاده می‌کند. اگر افراد به طور مکرر یک فهرست تفصیلی دستگاه را برای پاسخ به یک سؤال عملیاتی اساسی باز می‌کنند، آن اطلاعات احتمالاً متعلق به جایگاه بالاتری در سلسله‌مراتب است. اگر یک هشدار همیشه بدون اقدام رد شود، آستانه یا ارائه آن ممکن است اشتباه باشد.
یک صفحه نمایش مشترک یک محصول عملیاتی است
موفق‌ترین داشبوردهای مشترک اینترنت اشیا نه سیستم‌های مدیریت ساختمان مینیاتوری هستند و نه اپلیکیشن‌های موبایل بزرگ‌شده. آن‌ها محصولات عملیاتی متمرکز برای یک مکان و گروه خاص از افراد هستند.
آن‌ها وضعیت دستگاه را با زمینه مورد نیاز برای تفسیر آن ترکیب می‌کنند. آن‌ها اطلاعات مشترک را آشکار می‌کنند در حالی که از کنترل‌های ممتاز محافظت می‌کنند. آن‌ها در طول خرابی جزئی صادق باقی می‌مانند. آن‌ها در فاصله‌ای که نصب شده‌اند قابل خواندن هستند و با رشد استقرار می‌توانند مدیریت شوند.
ساختمان‌های متصل در حال حاضر داده‌های بیشتری نسبت به آنچه بیشتر اپراتورها می‌توانند استفاده کنند تولید می‌کنند. فرصت در این نیست که همه آن‌ها را روی صفحه نمایش دیگری قرار دهیم؛ بلکه در این است که داده‌های درست را به درکی مشترک از آنچه در حال وقوع است، آنچه اهمیت دارد و آنچه کسی باید در ادامه انجام دهد، تبدیل کنیم.
منبع: Beyond Mobile Apps: Designing Shared IoT Dashboards for Commercial Buildings — IoT For All؛ نویسنده: Sergey Eskin
منبع: iotforall