كيف تتعامل مع قراءات الوقود الخاطئة دون أن تفقد أعصابك

    كيف تتعامل مع قراءات الوقود الخاطئة دون أن تفقد أعصابك

    تقرير الوقود شيء روتيني. يخبرك بكمية الوقود التي استهلكتها المركبة وما إذا حدث شيء غير معتاد أثناء الرحلة. هكذا تسير الأمور عادةً. والآن تخيّل أن تفتح تقريرًا يقول إن حافلة تزوّدت بالوقود 12 مرة، وسجّلت 5 عمليات سحب للوقود، واستهلكت 0.35 لتر فقط لقطع 85 كم. من أين ستبدأ؟

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

    تقرير وقود لا يستقيم

    تلقّى أسطول من 26 حافلة تقرير وقود أثار أسئلة أكثر مما قدّم إجابات. يُفترض أن إحدى الحافلات قطعت 85 كم باستخدام 0.35 لتر من الوقود، مع 12 عملية تعبئة و5 عمليات سحب للوقود خلال اليوم. هذا عدد كبير من العمليات في يوم واحد (ولم تحدث أيٌّ منها فعلًا).

    fuel-report-excerpt.webp

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

    رغم غرابة النتيجة، كانت الحسابات صحيحة. كمية الوقود في بداية اليوم، مضافًا إليها عمليات التعبئة، ومطروحًا منها عمليات السحب والوقود المتبقي في النهاية، أعطت 62.2 + 95.13 − 106.98 − 50 = 0.35 لتر. كانت المعادلة سليمة. إذن، من الواضح أن المشكلة كانت في القراءات.

    الحل الواضح لم يكن كافيًا لإعادة قراءات الوقود إلى طبيعتها

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

    ما كشفته 34,000 رسالة

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

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

    1. أثناء التوقف، لا بيانات جديدة

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

    2. الدقائق الأولى بعد تشغيل المحرك غير موثوقة

    مباشرةً بعد تشغيل المحرك، بينما تبدأ أنظمة المركبة بالعمل، لا تعكس قراءات الوقود الأولى الواقع دائمًا. كانت تشير غالبًا إلى وجود ما بين 0 و6 لترات في الخزان، مهما كانت الكمية الموجودة فيه فعلًا. عادةً ما كانت القراءات تستقر خلال ثوانٍ. لكن في نحو حالة واحدة من كل خمس مرات تشغيل، استغرق الأمر وقتًا أطول، وتجاوزت أبطأ حالة 7 دقائق بقليل.

    3. تشغيل قصير يترك انخفاضًا طويلًا

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

    15:44:31  الإشعال متوقف   الوقود 24.9 L
    15:44:34  الإشعال مفعّل   الوقود  0.0 L   المحرك 740 rpm
    15:45:16  الإشعال مفعّل   الوقود  5.4 L   المحرك 744 rpm
    15:45:17  الإشعال متوقف   الوقود  5.4 L
              276 رسالة إضافية خلال 47 دقيقة، جميعها بقيمة 5.4 L
    16:32:33  الإشعال متوقف   الوقود  5.4 L
    16:32:34  الإشعال مفعّل   الوقود 21.6 L
    16:35:56  الإشعال مفعّل   الوقود 25.3 L   السير بسرعة 45 km/h
    

    حافلة واحدة، و43 ثانية من تشغيل المحرك، ثم 47 دقيقة بدا خلالها الخزان شبه فارغ. هذه رسائل جهاز التتبع الخام، كما أرسلها تمامًا.

    في التقرير، تبدو فترة التوقف هذه وكأن نحو 20 لترًا سُحبت من الخزان، ثم أُضيفت إليه نحو 20 لترًا بعد 47 دقيقة.

    حتى عمليات التعبئة الحقيقية ظهرت بصورة مشوّهة. في إحدى الحافلات، حدثت التعبئة بين عدة مرات تشغيل قصيرة للمحرك. وظهرت تعبئة واحدة بنحو 30 لترًا على الرسم البياني كانخفاض إلى ما يقارب الصفر، تلاه ارتفاع إلى 62 لترًا.

    إذن، لماذا لم ينجح الحل البسيط؟

    معظم إعدادات الوقود تنظر إلى الأرقام فقط. ومع هذه البيانات، يفشل كل منها بطريقته.

    النهج ما يحدث مع هذه البيانات
    تنعيم القراءات أو حساب متوسطها يختلط التشويش بالقيم الحقيقية. استمرار قراءة 5.4 L لمدة 47 دقيقة يخفض المتوسط، فيصبح الانخفاض الوهمي أقل حدة، لكنه يظل موجودًا.
    تجاهل القراءات الأقل من حد معين يُخفى أيضًا الخزان الذي يكون شبه فارغ فعلًا. أما التشويش فوق الحد، مثل القراءات بين 15 و18 لترًا التي وجدناها، فيستمر في المرور.
    رفع عتبة التنبيهات تقل التنبيهات، لكن الرسم البياني للوقود وتقرير الاستهلاك يظلان غير صحيحين.
    تطبيق قواعد تراعي السياق يتحقق IoT Logic مما قد يتحقق منه الشخص نفسه. هل المحرك يعمل؟ منذ متى بدأ تشغيله؟ هل تستمر القيمة الجديدة؟ يُستبعد التشويش، وتُحفظ عمليات التعبئة والسحب الحقيقية.

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

    أربعة أسئلة لكل قراءة

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

    يفحص تدفقنا كل قراءة وقود عبر أربعة أسئلة كحد أقصى، بالترتيب.

    fuel-reading-decision-16x9.webp

    يحتفظ التدفق بآخر مستوى موثوق حتى تجتاز قراءةٌ ما الفحوصات.

    في أبطأ حالة تشغيل ضمن البيانات المسجلة، استغرقت قراءات الوقود أكثر قليلًا من 7 دقائق لتستقر، لذلك حددنا فترة الإحماء بـ7.5 دقائق. أثناء القيادة العادية، لم يتغير المستوى بأكثر من 3.5 لترات بين رسالتين، وهو ما وافق أيضًا العتبة التي طلبها العميل. واخترنا 5 دقائق لأن أي قراءة مشوّشة في البيانات المسجلة لم تبقَ مستقرة لهذه المدة مع استمرار تشغيل المحرك، بينما استقرت المستويات بعد عمليات التعبئة والسحب الحقيقية.

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

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

    فترة بعد الظهر، قبل المعالجة وبعدها

    fuel-before-after-16x9.webp

    بيانات جهاز التتبع المسجلة خلال فترة بعد الظهر، بعد إعادة تمريرها عبر التدفق. يظهر الخط الرمادي فقط حيث تختلف القراءات الأصلية عن القراءات المصححة.

    الوقت قراءة جهاز التتبع القيمة التي تستقبلها المنصة ما حدث
    15:44:31 24.9 L 24.9 L الحافلة متوقفة
    15:44:34 0.0 L 24.9 L يبدأ تشغيل المحرك، وتكون القراءة الأولى تشويشًا
    15:45:17 5.4 L 24.9 L يُطفأ المحرك بعد 43 ثانية. يحتفظ جهاز التتبع بآخر قراءة
    16:32:34 21.6 L 24.9 L تشغيل جديد بعد 47 دقيقة. تبدأ فترة الإحماء
    16:40:44 26.2 L 26.2 L انتهت فترة الإحماء، وأصبحت القراءات موثوقة من جديد
    16:47:23 62.5 L 26.3 L تعبئة وقود بعد تشغيل جديد مباشرةً، لذلك ينتظر التدفق
    17:00:10 62.3 L 62.3 L استمر المستوى الجديد لمدة 5 دقائق مع تشغيل المحرك، فتم قبوله

    كيف تأكدنا من نجاحه

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

    أعدنا أيضًا تمرير جميع البيانات المسجلة عبر القواعد نفسها، نحو 34,000 رسالة من ثلاث حافلات خلال ثلاثة أيام في أغسطس 2026، وحسبنا التغيرات المفاجئة التي تجاوزت 3.5 لترات بين كل رسالة والتي تليها. في حافلتين، كان التدفق يحدد ما إذا كان المحرك يعمل اعتمادًا على عدد دوراته.

    fuel-jumps-before-after.webp

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

    الفكرة نفسها تصلح لما هو أبعد من الوقود

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

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

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

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

    مشاركة المقال