كيف نصمّم بنية نظام تتبّع المركبات اللحظي

ما هذا النموذج المرجعي؟

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

دراسة الاحتياجات: ما الذي يجب أن تؤدّيه منصّة الأسطول فعلاً؟

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

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

كيف تتحوّل دراسة الاحتياجات إلى مواصفات قابلة للتنفيذ؟

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

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

ما مكوّنات بنية نظام تتبّع المركبات؟

تفصل البنية التي تلبّي هذه المتطلبات بوضوح بين ثلاث مهام: استقبال البيانات، ومعالجتها، وتقديمها لمن يحتاجها.

ترسل الأجهزة بيانات المواقع عبر MQTT، وهو بروتوكول خفيف للاتصال بين الأجهزة يعمل بنمط النشر والاشتراك، ومصمّم للشبكات محدودة الموارد [1]. وتثبت الأجهزة هويتها للبوّابة عبر mutual TLS، فلا يستطيع جهاز منتحل أن يدسّ مواقع مزيّفة. أما طبقة الاستقبال فعديمة الحالة (stateless) وتتوسّع تلقائياً، فلا تنهار أمام ذروة الصباح حين تبدأ المركبات كلها بالإرسال في وقت واحد. ويفصل بين الاستقبال والمعالجة سجلّ أحداث متين (durable) يمكن إعادة قراءته (replay)، فلا يضيع أي موقع بسبب بطء إحدى الخدمات المستهلكة للأحداث (consumers)، ويمكن لاحقاً إعادة بناء أي مخزن بيانات مشتقّ بإعادة قراءة أحداث السجلّ.

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

ما الذي تغفل عنه فرق التطوير؟

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

نمذجة التهديدات أولاً. نحصر التهديدات قبل أن نبدأ التطوير، في عملية تحدَّد فيها التهديدات المحتملة، كالثغرات البنيوية أو غياب إجراءات الحماية المناسبة، وترتَّب فيها أولويات التدابير المضادّة [2]. وفي منصّة الأسطول يعني ذلك مصادقة الأجهزة، التي تفرضها البوّابة عبر mutual TLS قبل أن تصل أي رسالة إلى سجلّ الأحداث، وتوقيع تحديثات البرامج الثابتة رقمياً، وعزل بيانات كل مستأجر (tenant) عن غيره، ووضع حدّ أقصى لمعدّل الرسائل الواردة.

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

العمل دون اتصال، وقابلية الرصد (observability)، والاستعادة. تفقد الأجهزة الإشارة في الأنفاق والمواقف السفلية، لذا تحتفظ بالمواقع مؤقتاً في ذاكرتها وتعيد إرسالها عند عودة الاتصال، بينما يستوعب سجلّ الأحداث موجة الرسائل المفاجئة. ويحمل كل موقع أثر تتبّع موزّع (trace) عبر مكوّنات النظام، وتعرض لوحات المراقبة تأخّر الاستقبال وتأخّر المستهلكين (consumer lag)، وتُدار عمليات النشر بإصدارات مرقّمة مع إمكانية تراجع آمن. ويتيح سجلّ الأحداث المتين إعادة بناء أي مخزن مشتقّ بإعادة قراءة أحداث السجلّ بعد اكتشاف خلل برمجي.

كيف نرتّب مراحل التطوير؟

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

وبعد ذلك تضيف كل جلسة عرض قدرة حقيقية جديدة: سجلّ الرحلات، ثم الأسيجة الجغرافية، ثم التنبيهات، ثم تطبيق السائق. ويوجّه العميل الأولويات وهو ينظر إلى برمجيات تعمل لا إلى وثيقة، وهكذا يبقى النطاق واقعياً.

كيف نختبر المنصّة ونطلقها ونتعامل مع المفاضلات؟

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

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

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

يندرج هذا المقال ضمن عملنا في تطوير البرمجيات المخصّصة، ويعكس منهجية التخطيط التي تقوم عليها طريقة عملنا.

اقرؤوا أيضاً: الفرق بين BRD و SRS و SDD.

أبرز النقاط

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

المصادر

1. MQTT (en.wikipedia.org)
2. Threat model (en.wikipedia.org)
3. Time series database (en.wikipedia.org)
4. Data protection laws - The Official Portal of the UAE Government (u.ae)