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

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

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

ما الذي يفعله ناقل CAN في المركبات

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

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

يربط ناقل CAN جميع وحدات ECU بحافلة واحدة مشتركة. فكر في الأمر وكأنه خط مترو أنفاق - تقع جميع المحطات على نفس المسار. يمكن لأي وحدة ECU إرسال رسائل تستقبلها جميع وحدات ECU الأخرى. تقوم كل وحدة ECU بمعالجة الرسائل ذات الصلة بوظيفتها بشكل انتقائي.

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

تحتاج بوابات المركبات إلى النقر على حافلات CAN هذه لقراءة البيانات. خذ SV910 على سبيل المثال - فهو مزود ب 3 منافذ CAN التي يمكنها الاتصال بحافلات CAN متعددة للمركبات في نفس الوقت.

عملية قراءة بيانات CAN

 

 

كيف تقرأ هذه البيانات بالضبط؟ لنستعرض قراءة عدد دورات المحرك في الدقيقة كمثال.

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

يستخدم ناقل CAN إشارات تفاضلية بسلكين: CAN_H و CAN_L. في موصّل OBD، السن 6 هو CAN_H والسن 14 هو CAN_L. تحتوي واجهة CAN الخاصة بالبوابة على أسلاك متناظرة - فقط قم بمطابقتها. ملاحظة مهمة: تحتاج نهايات ناقل CAN إلى مقاومات إنهاء 120 أوم لمنع انعكاس الإشارة. تدمج بعض البوابات مقاومات الإنهاء داخليًا، ويمكن تكوينها من خلال البرنامج.

الخطوة الثانية هي تكوين معدل الباود. يجب أن تتطابق سرعة اتصال ناقل CAN وإلا لن تتلقى أي بيانات. تعمل مجموعة نقل الحركة للمركبات التجارية CAN عادةً بسرعة 250 كيلوبت في الثانية أو 500 كيلوبت في الثانية - عليك التحقق أولاً. راجع دليل خدمة السيارة أو اختبرها باستخدام محلل CAN احترافي.

تكوين واجهة CAN الخاصة بالبوابة على نفس معدل الباود. تدعم البوابات، مثل SV910، معدلات باود متعددة، قابلة للتعديل من خلال ملفات التكوين أو واجهات الإدارة.

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

معرف الرسالة هو مفتاح تحديد ما تحتويه كل رسالة. بالنسبة إلى عدد دورات المحرك في الدقيقة، تحدد معايير مثل GB/T 27930 وSAE J1939 المعرفات. J1939 شائع في المركبات التجارية - يستخدم معرّف RPM للمحرك 0x0CF00400، مع بيانات في البايت 4 و5.

تراقب البوابة ناقل CAN باستمرار، وتلتقط الإطارات بمعرفات محددة، ثم تستخرج قيم RPM من بايتات البيانات. القيمة المستخرجة هي بيانات خام تحتاج إلى التحويل إلى RPM الفعلي باستخدام معادلة. في معيار J1939، تبلغ دقة RPM للمحرك 0.125 دورة في الدقيقة/بت، لذا اضرب القيمة الخام في 0.125 للحصول على RPM الحقيقي.

الخطوة الرابعة هي تغليف البيانات وتحميلها. بعد تحليل قيمة RPM، تقوم البوابة بتجميعها في تنسيق مناسب لتحميلها عبر شبكة 5G إلى السحابة. تتضمن التنسيقات الشائعة JSON و Protobuf ورسائل MQTT.

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

تحدي اختلاف طرازات المركبات المختلفة

 

يبدو الأمر بسيطاً من الناحية النظرية. الواقع هو أن التكيف مع طرازات السيارات المختلفة يسبب أكبر قدر من الصداع.

يحدد المعيار الوطني GB/T 32960 تنسيقات البيانات لمركبات الطاقة الجديدة، ولكنه لا يغطي سوى المركبات الكهربائية. وتتبع المركبات التجارية التقليدية التي تعمل بالوقود في الغالب معيار SAE J1939، ومع ذلك لا تزال التطبيقات المحددة تختلف.

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

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

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

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

ضمان الأداء ودقة البيانات في الوقت الفعلي

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

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

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

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

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

يدعم SV910 بروتوكولات مزامنة الوقت PTP/GPTP، مما يضمن مزامنة ساعة عالية الدقة بين البوابة والأجهزة الأخرى. وهو أمر بالغ الأهمية للسيناريوهات التي تتطلب تنسيقاً متعدد الأجهزة.

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

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

مزايا بنية الجيل الخامس المزدوج 5G المزدوجة

يتميز SV910 ببنية 5G مزدوجة مع وحدتي 5G. لماذا 5G المزدوجة؟

السبب الأول هو التكرار الاحتياطي. قد تمر المركبات التجارية على طرق المسافات الطويلة عبر مناطق ذات إشارة ضعيفة. مع شبكة 5G المفردة، يعني فقدان الإشارة عدم نقل البيانات. يستخدم الجيل الخامس المزدوج 5G بطاقات SIM من شركات اتصالات مختلفة - تشاينا تيليكوم وتشاينا يونيكوم، أو تشاينا موبايل وتشاينا يونيكوم. عندما تتدهور إشارة إحداهما، قم بالتبديل إلى الأخرى.

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

السبب الثاني هو توزيع حركة المرور. عادةً ما تتضمن تطبيقات المركبات تدفقات بيانات متعددة - بيانات ناقل CAN، وفيديو الكاميرا، وبيانات تحديد المواقع، واتصالات V2X. وتتميز أنواع البيانات هذه بخصائص مختلفة ومتطلبات مختلفة للنطاق الترددي/وقت الاستجابة.

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

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

التكامل مع منصات إدارة الأسطول

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

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

يدعم MQTT مستويات مختلفة من جودة الخدمة (QoS). QoS 0 هي مرة واحدة على الأكثر - إطلاق ونسيان، احتمال فقدان. QoS 1 هي مرة واحدة على الأقل - تسليم مضمون ولكن مع احتمال التكرار. QoS 2 مرة واحدة بالضبط - تسليم مضمون دون تكرار. اختر جودة الخدمة المناسبة بناءً على أهمية البيانات.

كما يُستخدم HTTP/HTTPS على نطاق واسع. تقوم البوابات بتجميع البيانات المجمعة بشكل دوري وتحميلها عبر طلبات HTTP POST إلى واجهات برمجة التطبيقات السحابية. هذا النهج بسيط ومباشر مع توافق جيد. الجانب السلبي هو أن نفقات HTTP الزائدة تتجاوز MQTT، وهي أقل ملاءمة لنقل البيانات الصغيرة عالية التردد.

توجد بعض البروتوكولات المتخصصة أيضاً. على سبيل المثال JT/T 808 هو بروتوكول الاتصال القياسي لوزارة النقل لمحطات نظام تحديد المواقع بالأقمار الصناعية لمركبات النقل البري. تستخدم العديد من منصات إدارة أسطول المركبات التجارية هذا المعيار. يتطلب دعم JT/T 808 تنفيذ حزمة البروتوكول الكاملة.

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

تنفيذ وظائف التشخيص

بالإضافة إلى قراءة البيانات في الوقت الفعلي، يمكن لبوابات المركبات إجراء عمليات التشخيص.

تقوم وحدات التحكم الإلكترونية في السيارة بتوليد أكواد تشخيص الأعطال (DTCs). عند حدوث عطل في المحرك، فإنها تنتج رموزاً مثل P0001، P0002. يتم تخزين هذه الرموز في وحدات التحكم الإلكترونية ويمكن قراءتها عبر ناقل CAN.

بروتوكولات التشخيص القياسية هي ISO 14229 (UDS - خدمات التشخيص الموحدة) وSAE J1939-73. تعمل البوابة كعميل تشخيص، حيث ترسل طلبات التشخيص إلى وحدات التحكم الإلكترونية ECU، والتي تقوم بإرجاع رموز الأعطال والمعلومات ذات الصلة.

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

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

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

الدروس المستفادة من المشاريع الحقيقية

بعد العديد من المشاريع، واجهنا الكثير من العقبات.

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

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

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

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

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