كيف يعتمد المترو مصادر معلومات المواعيد الحية؟

شبكات المترو تبدو لي كشبكة أعصاب حيّة تعتمد على مزيج من حسّاساتٍ متعددة وبرمجيات ذكية لتحديث مواعيد الوصول في الوقت الحقيقي. في الأنفاق حيث لا يصل GPS بوضوح، يعتمد النظام أساسًا على الإشارات الداخلية: أنظمة التحكم بالقطارات مثل CBTC أو ATP تزود مركز التحكم بمواقع كل قطار تقريبًا اعتمادًا على قياسات العربة (odometry) وحساسات الأكسيل والباليسات الأرضية. هذه الإشارات تمنح توقّعات أولية لوقت الوصول، لكن الأمر لا يقتصر عليها فقط.

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

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

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

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

أحب أن أؤكد أن دقّة المواعيد الحية تختلف: في خطوط حديثة مع CBTC والتزامن العالي تكون دقيقة جدًا، أما في شبكات قديمة فالاعتماد أكبر على التقديرات والجدول، وبالتالي نرى فروق دقيقة إلى عدة دقائق أحيانًا. لكن كمسافر، يطمئنني أن النظام يدمج مصادر متعددة ليقلل المفاجآت قدر الإمكان.

أميل إلى الجانب التقني المختصر: المترو ينقل بيانات مواقع القطارات بأشكال متعددة إلى الأنظمة التي تعرض مواعيد الوصول. البروتوكولات الشائعة التي تُستخدم لنشر هذه البيانات تشمل صيغًا قياسية مثل GTFS‑realtime وواجهات JSON/REST أو بروتوكولات رسائل وقتية (WebSocket/MQTT) لمزامنة التحديثات. البيانات القادمة تكون مزيجًا من قراءات حسّاسات مسار القطار (عربات، باليسات، عدادات محورية) وإشارات نظام التحكم المركزي، تضاف إليها مدخلات تشغيلية يدوياً عند حدوث أعطال.

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

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