كيف قام أحد مدمجي الأنظمة ببناء تطبيق مستشعر باستخدام IoT Query بدلاً من واجهات برمجة التطبيقات

يقوم مشرف المستودع بالبحث في لوحة تحكم إدارة الأسطول عن قراءات درجة الحرارة التي تتطلب ثلاث نقرات للوصول إليها. البيانات موجودة، لكن الواجهة مصممة للمسؤولين عن التوجيه، وليست لعمليات التخزين البارد. هذا التفاوت بين إمكانيات المنصة واحتياجات العمل شائع. يستغرق بناء التطبيقات المخصصة عادةً عدة أشهر، ولكن توضح دراسة الحالة هذه مسارًا أسرع.

أهم النقاط المستخلصة

• اصنع تطبيقات مراقبة مخصصة بشكل أسرع من خلال الوصول المباشر إلى البيانات عن بُعد (telemetry)، مما يلغي الحاجة إلى الطبقات الوسيطة وخطوط نقل البيانات المعقدة.
• بسِّط تطوير التحليلات من خلال استخدام SQL للاستعلام عن البيانات التاريخية مباشرةً، وتجنب الأعباء والقيود المرافقة للتكاملات المعتمدة على واجهات برمجة التطبيقات (API).
• أنشئ لوحات تحكم مخصصة للأدوار باستخدام استعلامات SQL مرنة تتوافق بشكل وثيق مع سير العمل التشغيلي، مما يعزز سهولة الاستخدام ويساعد في اتخاذ القرارات.
• توسَّع بسلاسة عبر المستودعات والمستخدمين، دون إعادة بناء البنية التحتية أو التعامل مع قيود واجهات برمجة التطبيقات.
• عجِّل الوصول إلى القيمة بالتركيز على التحليلات والرؤى عبر SQL، بدلاً من صيانة الخدمات الخلفية أو عمليات التكامل مع واجهات برمجة التطبيقات.

استكشف IoT Query لاكتشاف الإمكانات الكاملة لبياناتك المتعلقة بالاتصالات عن بُعد (telematics) لتطبيقات التحليلات المخصصة.

الواقع التشغيلي للمراقبة المتخصصة

تتميز منصات الاتصالات عن بُعد (telematics) متعددة الأغراض في المهام التي صُممت لأجلها: تتبع المركبات، تحسين المسارات، وتحليل سلوك السائق. ولكن عندما تحتاج شركة لوجستيات إلى مراقبة البيئات عبر عدة غرف تخزين في المستودع، تصبح الواجهة نفسها عائقًا.

المشرفون في هذه الحالة احتاجوا إلى شيء محدد:

• قراءات درجة الحرارة والرطوبة عبر 12 منطقة تخزين.
• الاتجاهات التاريخية للتحقيق في الحوادث.
• تنبيه في حال خروج الظروف عن النطاقات المقبولة.

تقليديًا، كان حل هذه المشكلة يتطلب أحد مسارين: إما استغلال واجهات برمجة التطبيقات (APIs) والمنصات الحالية بشكل يتجاوز الغرض الأساسي لها، أو بناء حزمة تطبيقية منفصلة تضم خطوط نقل بيانات خاصة وبنية تحتية وإدارة للأدوار. كلا النهجين يزيد من التعقيد بلا داع. الأول يؤدي إلى تكاملات محدودة المرونة للتحليلات. والثاني يبطئ عملية التسليم، نظرًا لقضاء أسابيع وأشهر في تجميع خطوط نقل البيانات وصيانة البنية التحتية والتوفيق بين مصادر البيانات المتعددة بدلاً من تخصيص الوقت لتوليد القيمة.

التحدي: تحقيق التوازن بين الاستقلالية والتكامل

واجه مدمج الأنظمة قائمة متطلبات تبدو بسيطة لكنها تحمل آثارًا معمارية. فقد تم نشر المستشعرات عبر شبكة المستودعات، حيث تُرسل البيانات إلى منصة Navixy. تتدفق بيانات درجة الحرارة والرطوبة وحالة الأبواب ومدة تشغيل المعدات باستمرار.

لكن المشرفين احتاجوا إلى واجهة تظهر فقط ما يهم سير عملهم:

• حالة في الوقت الفعلي بنظرة سريعة.
• استعلامات تاريخية للتحقق من سبب ارتفاع درجة حرارة المُجمِّد في المنطقة 3 يوم الثلاثاء الماضي.
• واجهات مخصصة للعميل لمنحهم الرؤية في مناطق التخزين المخصصة لهم.

كما كان يجب أن يبقى التطبيق مستقلاً، كأداة متخصصة للعمليات في المستودع، مع بقائه متصلاً بالمنصة الأساسية. يجب أن تكون إضافة مستودعات وأجهزة استشعار جديدة ممكنة دون إعادة بناء التطبيق. كما يجب أن تحترم أذونات المستخدم الهيكل التنظيمي الحالي.

وقد تضمنت قابلية التوسع ثلاثة جوانب: المزيد من الغرف في المستودع، المزيد من المستودعات على مستوى الشبكة، والمزيد من المستخدمين ذوي مستويات أذونات مختلفة. لذا كان على البنية المعمارية دعم كل ذلك دون الحاجة إلى تطوير مُخصص عند كل توسع.

القرار المعماري: لماذا تفوق الوصول المباشر للبيانات على نهج واجهات برمجة التطبيقات

كان هناك مساران معماريان يؤديان إلى تطبيق جاهز للعمل. الأول، استخدام واجهة برمجة تطبيقات المنصة، وهو الخيار التقليدي. أما الثاني، الوصول المباشر عبر IoT Query، فقد قدم مجموعة مختلفة من التنازلات.

يناسب نهج واجهة برمجة التطبيقات العديد من التكاملات بشكل جيد. بالنسبة للوحة معلومات الحالة في الوقت الفعلي، فهذه الطريقة توفر النتائج بسرعة. ولكن التحليلات التاريخية تغير المعادلة. فالاستعلام عن ستة أشهر من بيانات درجة الحرارة عبر 12 منطقة من خلال واجهة برمجة التطبيقات يعني التعامل مع تقسيم البيانات (pagination) والحد من المعدل (rate limiting) ومنطق تجميع البيانات في مكون وسيط مخصص. سيضطر المدمج إلى بناء وصيانة قاعدة بيانات محلية وروتينات تزامن وبنية تخزين، وكل هذا قبل كتابة أي سطر برمجي في لوحة المعلومات.

وفر IoT Query بنية مختلفة. فالتطبيق يستعلم مباشرة من طبقة بيانات جاهزة باستخدام SQL القياسي.

"يوفر IoT Query وصولاً جاهزًا للاستخدام إلى بيانات الاتصالات عن بُعد (telemetry) في الوقت الفعلي والبيانات التاريخية دون الحاجة لبناء طبقات التخزين والتجميع"، يوضح Andrew Melnik، نائب رئيس البيانات والحلول في Navixy. "تعمل استعلامات SQL بسرعة أكبر مما قد تسمح به مكالمات واجهة برمجة التطبيقات المتكررة. ونتيجةً لذلك، يمكننا توفير لوحات معلومات في الوقت الفعلي وتحليلات تاريخية من مصدر بيانات واحد، مما يجعل البنية مبسطة. يظل التطبيق مستقلاً ولكنه يتكامل بسهولة مع Navixy. وبشكل خاص لهذا الاستخدام، فإن عبء الصيانة أقل بكثير من بديل واجهة برمجة التطبيقات."

التنفيذ: من الوصول إلى قاعدة البيانات إلى لوحات المعلومات التشغيلية

مع اتخاذ القرار المعماري، تركز التنفيذ على ما يفعله مدمجو الأنظمة بشكل أفضل: بناء تطبيقات تحل مشكلات معينة.

وفرت طبقة البيانات الخام في IoT Query الأساس. هذه المجموعة من البيانات تحتوي على القراءات عن بُعد مع البنية والفهرسة اللازمة لتحليل السلاسل الزمنية. وتشمل قراءات درجات الحرارة والرطوبة وحالات الأبواب وحالة المعدات، وجميعها قابلة للاستعلام باستخدام صيغة SQL القياسية المتوافقة مع أدوات PostgreSQL.

بدا نمط التطوير مألوفًا لأي شخص سبق له بناء تطبيقات تحليلات:

1. الاتصال بمصدر البيانات.
2. كتابة الاستعلامات للمقاييس المحددة المطلوبة.
3. بناء التصورات التي تجيب عن الأسئلة التشغيلية.

بالنسبة للمراقبة في الوقت الفعلي، يستعلم التطبيق عن القراءات الأخيرة ويحدث لوحات المعلومات على فترات زمنية تتناسب مع الظروف البيئية (حيث لا تهم التغيرات على مستوى الدقائق بقدر ما تهم الاتجاهات على مستوى الساعات في التخزين البارد). أما بالنسبة للتحليل التاريخي، فيدعم نفس مصدر البيانات الاستعلامات التي تمتد لأسابيع أو أشهر دون تعقيدات التقسيم (pagination) لواجهات برمجة التطبيقات.

وقد تحققت العزلية بين العملاء من خلال الهيكل التنظيمي القائم. إذ يمكن لكل عميل رؤية مناطق التخزين المخصصة له فقط. ويحترم التطبيق هذه الحدود دون الحاجة إلى منطق مخصص للتحكم في الوصول.

يوفر التطبيق المُسلَّم للمشرفين بالضبط ما يحتاجون إليه:

• حالة البيئة في الوقت الفعلي عبر جميع المناطق الخاضعة للمراقبة.
• مخططات الاتجاهات التاريخية للبحث في الحالات الشاذة.
• تنبيهات قائمة على حدود معينة حين تتجاوز الظروف النطاقات المقبولة.
• واجهات مخصصة لكل عميل مع عزل البيانات الملائم.

يعمل التطبيق كأداة مستقلة ولكنه يُفتح من داخل واجهة Navixy، مما يحافظ على تجربة متكاملة للمستخدمين الذين يتنقلون بين أسطول المركبات وعمليات المستودع.

يتم تمكين هذا التكامل عبر App Connect، أداة المصادقة الخاصة بـNavixy. فهي تنقل مصادقة المستخدم من المنصة إلى التطبيق الخارجي، مما يسمح للمستخدمين بالوصول إلى أداة المراقبة دون استخدام بيانات دخول منفصلة. بالنسبة لمدمجي الأنظمة، يزيل هذا الحاجة إلى بناء أو صيانة بنية المصادقة.

ما الخطوة التالية: من المراقبة إلى التنبؤ

مع توسع التطبيق، يمكن إضافة مؤشرات قياس (KPIs) إضافية لتوسيع لوحة المعلومات إلى ما هو أبعد من درجة الحرارة والرطوبة. يمكن دمج مقاييس مثل وقت تشغيل المعدات واستهلاك الطاقة ومؤشرات الصيانة بسلاسة باستخدام نفس طبقة البيانات.

تشكل التحليلات التنبؤية التحسين التشغيلي التالي. بدلًا من إرسال تنبيه عندما تتجاوز الظروف الحدود المسموح بها، يمكن للنظام التعرف على الأنماط التي تسبق حالات الفشل. ضاغط يتعرض لدورات تشغيل أكثر من المعتاد. مستشعر باب يُظهر فترات فتح غير عادية. كل هذه الإشارات موجودة في البيانات التاريخية وجاهزة للتحليل.

ستتخطى آليات التنبيه حدود التطبيق نفسه، إذ سيجري التكامل مع مسارات العمل التشغيلية لضمان وصول الإشعارات إلى الأشخاص المناسبين عبر قنواتهم الحالية (مثل البريد الإلكتروني والرسائل الفورية)، مع إتاحة تقليل التنبيهات أو إيقافها عند الحاجة.

ستعزز الواجهات المحمولة من إمكانية وصول المشرفين أثناء جولاتهم في المنشأة. فبإمكان الاستعلامات نفسها التي تُشغل لوحات المعلومات المكتبية تزويد الواجهات المحمولة بمعلومات مركزة حول حالة المناطق والتنبيهات الأخيرة.

يكمن جوهر الأمر في أن هذه التوسعات تتطلب أقل قدر من التعديلات المعمارية. إذ تحتوي طبقة البيانات بالفعل على الإشارات اللازمة لتحليلات أكثر تطورًا. ويصبح بناء المزيد من العروض والتحليلات مجرد عمل تطويري، وليس بناءً جديدًا للبنية التحتية.

مبررات نهج التركيز على البيانات أولًا

تُبرز هذه دراسة الحالة مبدأ يمتد تطبيقه إلى ما وراء مراقبة المستودعات: حين يتم التعامل مع البنية التحتية للبيانات مسبقًا، يمكن لمدمجي الأنظمة التركيز على بناء تطبيقات تحل مشكلات حقيقية. تمكِّن طبقة البيانات المُجهزة المطورين من استعلام البيانات المنظمة عن بُعد باستخدام SQL القياسي — دون الحاجة لإدارة الأنظمة التحتية الأساسية.

بالنسبة لمدمجي الأنظمة، يعد هذا مكسبًا معماريًا. فبدعم مدمج لتحليل السلاسل الزمنية والبيئات المتعددة المستأجرين، يمكن تقليل فترة التسليم من أشهر إلى أسابيع.

اتصل بنا لتفعيل IoT Query واستغلال الإمكانات الكاملة لبيانات الاتصالات عن بُعد (telematics) من أجل تطبيقات التحليلات المخصصة.

---

الأسئلة الشائعة

س: ما المكونات الوسيطة المحددة التي يتطلبها نهج يعتمد فقط على واجهة برمجة التطبيقات (API)؟

ج: يتطلب نهج واجهة برمجة التطبيقات (API) التعامل مع تقسيم البيانات (pagination)، وإدارة حدود المعدل (rate limit)، وقاعدة بيانات محلية، وروتينات التزامن، ومنطق التجميع قبل البدء في تطوير لوحة المعلومات.

س: كيف تؤثر حدود المعدل (rate limits) وتقسيم البيانات (pagination) في واجهات برمجة التطبيقات على تحليل البيانات التاريخية على نطاق واسع؟

ج: إن الاستعلامات التاريخية التي تمتد لأشهر من البيانات عبر مناطق متعددة تتطلب معالجة مكثفة لتقسيم البيانات، وتكون مقيدة بحدود المعدل، مما يجعل التحليل التاريخي السريع صعبًا.

س: كيف يتعامل IoT Query مع البيانات غير المتسقة أو المشوشة الصادرة عن أجهزة استشعار مختلفة؟

ج: يوفر IoT Query حاليًا إمكانية الوصول إلى طبقة البيانات الخام، والتي تحتوي على البيانات الكاملة للاتصالات عن بُعد وبيانات الأعمال مع أقل قدر من التحويل. وفقًا لـ وثائق Navixy، فإن طبقة التحويل (Transformation layer) للبيانات المنقحة والمحولة، بالإضافة إلى طبقة الرؤى (Insight layer) للبيانات الجاهزة لأغراض الأعمال، ما تزال قيد التخطيط ولم تتوفر على نطاق واسع حتى الآن. وهذا يعني أن المدمجين يعملون حاليًا بشكل أساسي مع البيانات الخام وينبغي عليهم أخذ التنقية والتوحيد في الحسبان ضمن منطق التحليلات الخاص بهم عند الحاجة.

س: ماذا يحدث عندما تتأخر بيانات الاتصالات عن بُعد أو تكون مفقودة؟

ج: تعتمد توفر البيانات على اتصال الأجهزة وسلوك الإبلاغ. يعرض IoT Query البيانات التي يتلقاها النظام، لذا ينبغي على المدمجين تصميم لوحات المعلومات والمنطق لمعالجة الثغرات والتأخيرات ومجموعات البيانات غير المكتملة.

س: ما هي الحدود العملية أو العوامل الواجب مراعاتها عند استخدام IoT Query للنشر واسع النطاق؟

ج: تعتمد الأداء على تصميم الاستعلام وحجم البيانات والفترات الزمنية. ومع أن IoT Query يلغي الحاجة إلى بنية تخزين مخصصة، ينبغي على المدمجين تقييم كفاءة الاستعلام وأزمنة الاستجابة للبيانات الكبيرة وتواتر تحديث لوحات المعلومات في ظل الأحمال الفعلية.

س: كيف يتكامل IoT Query مع الأنظمة الخارجية أو أدوات ذكاء الأعمال (BI)؟

ج: يدعم IoT Query الوصول القائم على SQL المتوافق مع PostgreSQL، مما يتيح التكامل مع أدوات التحليلات الخارجية والتطبيقات المخصصة التي يمكنها الاتصال بقواعد البيانات العلائقية.

س: كيف يتم التعامل مع التحكم في الوصول وعزل البيانات متعدد المستأجرين؟

ج: يتبع IoT Query البنية التنظيمية للمنصة، مما يضمن أن المستخدمين لا يمكنهم الوصول إلا إلى البيانات المتاحة ضمن حسابهم والأذونات المعينة لهم.