OCPP 1.6 مقابل OCPP 2.0.1: دليل ترقية بروتوكول شحن EV
OCPP (Open Charge Point Protocol) هو معيار الاتصال العالمي في شحن السيارة الكهربائية مجال. ببساطة ، يعمل مثل "المترجم" بين محطات الشحن وأنظمة إدارة الواجهة الخلفية ، مما يسمح للأجهزة من مختلف العلامات التجارية بالاتصال باستخدام نفس اللغة. تتم إدارة هذا البروتوكول من قبل Open Charge Alliance ، وهي منظمة دولية تتألف من شركات البنية التحتية للمركبات الكهربائية العالمية. القيمة الأساسية لـ OCPP هي أنه معيار مجاني hardware-independent مفتوح. هذا يعني أنه لا يتعين على المشغلين أن يكونوا محبوسين في نظام بيئي لبائع واحد ، ويمكنهم الاختيار بمرونة محطات الشحن ev من علامات تجارية مختلفة أثناء إدارتها باستخدام نفس نظام البرنامج. حاليًا ، الإصدار الأكثر استخدامًا في السوق هو OCPP 1.6 ، بينما يتم الترويج تدريجياً 2.0.1 ، كمعيار الجيل التالي. ستوفر هذه المقالة مقارنة مفصلة بين هذين الإصدارين لمساعدتك في تحديد ما إذا كانت الترقية ضرورية.
منذ صدوره في عام 2015 ، أصبح OCPP 1.6 هو المعيار الفعلي لشبكات الشحن العالمية. لا تزال الغالبية العظمى من محطات الشحن تستخدم هذا الإصدار اليوم ، بما في ذلك متغير 1.6 (ي) المحسن. من السهل شرح اعتماده على نطاق واسع: إنه بسيط من الناحية الهيكلية ، ويعمل بثبات ، وهو كافٍ بشكل أساسي. بالنسبة لشبكات الشحن المبكرة ، استوفى الإصدار 1.6 بالفعل الاحتياجات الأساسية: إرسال حالة الشحن ، ومعالجة سجلات المعاملات ، ودعم جهاز التحكم عن بعد. ومع ذلك ، مع تطور صناعة الشحن بسرعة ، بدأ هذا البروتوكول الذي مضى عليه ما يقرب من عقد من الزمان في إظهار القيود. تشمل المشكلات الرئيسية في OCPP 1.6 ما يلي:
تم تصميم آلية الاتصال للإصدار 1.6 في عصر تهديدات أمان الشبكة البسيطة نسبيًا. في بيئة الشبكة المعقدة اليوم ، تعد طريقة المصادقة الخاصة بها أساسية نسبيًا وتصبح بسهولة هدفًا للهجمات. لشحن الشبكات التي تتعامل مع معلومات الدفع وبيانات المستخدم ، فهذه مخاطرة لا يمكن تجاهلها.
مع توسع نطاق محطة الشحن ، يبدأ الإصدار 1.6 في النضال. لا يدعم ضغط البيانات أو نقل الرسائل دفعة واحدة. حتى أن الإصدارات المبكرة استخدمت بروتوكول SOAP ، وهو ضخم ومطول ، ويستهلك كمية كبيرة من النطاق الترددي. بالنسبة للمحطات الكبيرة التي تحتوي على مئات نقاط الشحن ، تصبح كفاءة نقل البيانات عنق الزجاجة.
تتطلب سيناريوهات الشحن الحديثة طرق بدء متنوعة: تطبيقات الأجهزة المحمولة وبطاقات RFID ورموز QR ومدفوعات NFC وبطاقات الائتمان و "التوصيل والشحن" بشكل مثالي. ومع ذلك ، يدعم الإصدار 1.6 أصلاً بطاقات RFID ورموز التطبيقات فقط ؛ تتطلب الطرق الأخرى أنظمة خارجية ، مما يزيد من التعقيد ونقاط الفشل المحتملة.
يبسط الإصدار 1.6 هيكل محطة الشحن إلى طبقتين: المحطة والموصل. لا يمكن أن يعكس هذا النموذج المسطح البنية المعقدة لمحطات الشحن الحديثة. في الواقع ، قد تحتوي المحطة على وحدات طاقة متعددة ، كل منها يتحكم في مقابس متعددة. يجعل نموذج 1.6 المبسط من الصعب على المشغلين تحديد حالة الموارد بدقة ، وغالبًا ما يعتمدون على البيانات الإضافية التي يوفرها البائع ، والتي تختلف في التنسيق والموثوقية.
آلية معالجة المعاملات غير المتصلة بالإنترنت في الإصدار 1.6 ليست مثالية. يتم إنشاء معرفات المعاملات بواسطة النظام المركزي ، وبمجرد تعطل الشبكة ، تكون المعرفات المحلية عرضة للأخطاء. تفتقر أحداث البدء عن بُعد إلى المعرفات الفريدة ، مما يجعل التتبع اللاحق صعبًا. تتضح هذه المشكلات بشكل خاص في المناطق ذات الإشارات غير المستقرة ، مثل مواقف السيارات تحت الأرض.
عند تعطل محطة الشحن ، غالبًا ما تكون المعلومات التشخيصية التي يوفرها الإصدار 1.6 غير مفصلة بما فيه الكفاية. يجد المشغلون صعوبة في تحديد السبب الجذري بسرعة ، مما يؤدي إلى انخفاض كفاءة الصيانة. بالإضافة إلى ذلك ، إذا احتاج نظام إدارة الواجهة الخلفية إلى الاستبدال ، فإن ترحيل محطات الشحن 1.6 إلى نظام أساسي جديد أمر معقد ويمكن أن يؤدي إلى فقدان البيانات التاريخية.
على الرغم من أن الإصدار 1.6 (j) يدعم الشحن الذكي ، مما يسمح بحدود الطاقة والنوافذ الزمنية ، إلا أن قدراته أساسية نسبيًا. بالنسبة للسيناريوهات التي تتطلب موازنة تحميل معقدة أو تفاعل من مركبة إلى شبكة (V2G) ، فإن الإصدار 1.6 غير كافٍ.
OCPP 2.0.1 هو نسخة منقحة من 2.0 (تم إيقاف الإصدار 2.0 بسبب مشكلات متعددة). إنها بنية جديدة تمامًا ، غير متوافقة مع 1.6 ، مع تغييرات كبيرة في فلسفة التصميم والتشغيل.
تمت إعادة كتابة وثائق الإصدار 2.0.1 ، مع بنية أوضح ، ووظائف نمطية ، ومخططات تفصيلية وأمثلة على الاستخدام. بالنسبة للمطورين ، هذا يعني وقت نشر أقصر وسوء فهم أقل.
هذا هو التغيير المعماري الأكثر أهمية في 2.0.1. يتكون النموذج الجديد من ثلاث طبقات:
المحطة: مرفق الشحن بأكمله
EVSE (معدات تزويد المركبات الكهربائية): وحدة تحكم فعلية تدير توزيع الطاقة
الموصل: قابس الشحن الفعلي
يسمح هذا الهيكل متعدد الطبقات للنظام بتحديد حالة كل وحدة طاقة بدقة. على سبيل المثال ، في حالة فشل EVSE ، يمكن للمشغلين تحديد موقع وحدة التحكم المحددة بدقة دون التأثير على مقابس التشغيل الأخرى في المحطة. هذا المستوى من الإدارة التفصيلية مهم بشكل خاص لمحطات الشحن الكبيرة.
علاوة على ذلك ، يمتد طراز الجهاز 2.0.1 إلى السمات المادية مثل مستشعرات درجة الحرارة وأنظمة التبريد والإضاءة وقدرات العرض ، مما يوفر دعمًا أكثر شمولاً للبيانات للعمليات والصيانة.
يدعم الإصدار 2.0.1 نقل الرسائل دفعة واحدة وضغط البيانات ، والحد بشكل كبير من استخدام عرض النطاق الترددي. في المناطق ذات البنية التحتية للاتصالات المحدودة ، يمكن لهذا التحسين أن يقلل بشكل مباشر من تكاليف التشغيل.
يقدم الإصدار الجديد ملفات تعريف الأمان ، ويدعم المصادقة الأساسية والمصادقة المستندة إلى الشهادة (mTLS). يمكن تحديث معلومات المصادقة عن بُعد ، وتقوم الأحداث الأمنية بإخطار الواجهة الخلفية بنشاط. هذه الوظائف ضرورية للامتثال للوائح حماية البيانات والدفاع ضد الهجمات الإلكترونية.
يمكن للنظام المركزي إعادة تشغيل EVSEs الفردية دون التأثير على المحطة بأكملها. بالنسبة للمعاملات الجارية ، قام النظام بتحسين إدارة الحالة. تعمل هذه الوظائف على تعزيز المرونة التشغيلية بشكل كبير وتقليل الاعتماد على التدخل اليدوي في الموقع.
يدعم الإصدار 1.6 المقاييس المستندة إلى المعاملات فقط ، بينما يدعم 2.0.1 جمع المقاييس non-transaction-level ويقدم نموذج مقاييس جديدًا. يمكن للمشغلين مراقبة صحة المعدات وأنماط استخدام الطاقة والبيانات الهامة الأخرى بمرونة أكبر.
يدعم 2.0.1 أصلاً ميزات الشحن الذكية المتقدمة ، بما في ذلك موازنة الحمل والاستجابة للطلب. الأهم من ذلك ، أنه يوفر الدعم الكامل للتفاعل من مركبة إلى شبكة (V2G) ومعيار ISO 15118.
بالإضافة إلى رموز RFID والتطبيقات التقليدية ، يدعم 2.0.1 أصلاً رموز PIN وبطاقات الائتمان وطرق أخرى ، مما يوفر أساسًا تقنيًا للمحطات غير المأهولة وسيناريوهات التوصيل والشحن.
يعمل الإصدار الجديد على تحسين التشغيل دون اتصال بالإنترنت: فهو يدعم أنواع الرموز المعقدة ، وإدارة قائمة التراخيص المحلية المرنة ، والتوصيل والشحن دون اتصال بالإنترنت ، والإجراءات الموحدة لتخزين البيانات مؤقتًا وتحميلات إعادة الاتصال. تضمن هذه التحسينات التشغيل الموثوق به حتى في ظروف الشبكة غير المستقرة.
هذه واحدة من أكثر ميزات 2.0.1 تطلعية. ISO 15118 هو معيار الاتصال بين المركبات ومحطات الشحن ، ويدعم التوصيل والشحن - يقوم المستخدمون ببساطة بتوصيلهم ، ويقوم النظام تلقائيًا بتعريفهم ويبدأ الشحن ، دون تفاعل البطاقة أو التطبيق.
يتطلب تنفيذ هذه الوظيفة التنسيق بين مصنعي المركبات وبائعي محطات الشحن ومشغلي الشبكات. يوفر 2.0.1 إطارًا تقنيًا كاملاً ، بما في ذلك إدارة الشهادات وأنظمة الهوية المنظمة والمشغلات المتوافقة مع سير عمل ISO 15118.
يسمح 2.0.1 للنظام المركزي بإرسال معلومات التسعير إلى محطات الشحن ، بما في ذلك الأسعار الحالية والتكاليف المقدرة والفواتير النهائية. يمكن للمستخدمين عرض تفاصيل التكلفة مباشرة على شاشة المحطة ، مما يعزز الشفافية.
فهم المواصفات الفنية شيء. رؤية عملياتهم العملية شيء آخر. توضح السيناريوهات الثلاثة التالية الاختلافات بين الإصدارات.
أخذ السيناريو الشائع "التوصيل أولاً ، ثم التفويض":
لا يحتوي الإصدار 1.6 على رسالة واضحة "CablePluggedIn". عادةً ما تستنتج الأنظمة ذلك من خلال تغييرات الحالة في StatusNotification (على سبيل المثال ، Preparing ، SuspendedEV). تكمن المشكلة في أن هذه الحالات تختلف باختلاف البائعين: يشير البعض إلى انتظار تمرير البطاقة ، والبعض الآخر يشير إلى أن السيارة غير جاهزة ، والبعض الآخر يشير إلى اختبار ذاتي داخلي.
يتسبب هذا الغموض في ثلاث مشكلات: السلوك غير المتسق عبر العلامات التجارية التي تؤثر على تجربة المستخدم ، وبدء المعاملات غير المصرح بها المحتملة ، وصعوبة قيام أنظمة الواجهة الخلفية بتقييم الوضع الحقيقي بدقة ، مما يؤثر على القرارات التشغيلية.
يقدم الإصدار 2.0.1 رسائل TransactionEvent وحقول TriggerReason ، مما يشير بوضوح إلى أحداث مثل "CablePluggedIn". إلى جانب دورة حياة المعاملة المحددة جيدًا ، تصبح العملية قابلة للتنبؤ بها ويمكن تتبعها ، مع سلوك ثابت عبر البائعين ، مما يحسن بشكل كبير قابلية التشغيل البيني.
OCPP 1.6: يقتصر توفر الموصل على الحالات البسيطة مثل متصل / غير متصل أو خامل / مشغول. بالنسبة لمحطة بها ثمانية مقابس ، إذا كان اثنان غير متصلين بسبب أخطاء ، فقد لا يعكس 1.6 هذه التفاصيل بدقة.
2.0.1 OCPP: تسمح طبقة EVSE بتحديد المشكلة بدقة - سواء كان ذلك فشل اتصال لوحدة تحكم أو مشكلة في جهاز قابس معين. يمكن للمشغلين التشخيص عن بُعد وحتى إعادة تشغيل وحدة طاقة واحدة دون إرسال فنيين.
OCPP 1.6: يدعم القائمة البيضاء RFID المحلية ولكنه يفتقر إلى معايير القوائم منتهية الصلاحية ، وسلامة البيانات دون اتصال ، ومزامنة ما بعد إعادة الاتصال. يختلف التنفيذ على نطاق واسع ، مما قد يتسبب في فقدان المعاملات أو تكرارها.
2.0.1 OCPP: يحدد سير العمل الكامل دون اتصال بالإنترنت ، بما في ذلك قرارات التفويض المحلية ، والتخزين المؤقت للبيانات ، والتحميلات المجمعة بعد إعادة الاتصال ، وحل التعارض. يوفر هذا دعمًا فنيًا موثوقًا به ، لا سيما في المناطق ذات البنية التحتية المحدودة للشبكة.
على الرغم من المزايا الواضحة 2.0.1 ، فإن تبني الصناعة بطيء. الأسباب الرئيسية تشمل:
التكلفة والتعقيد: تتطلب الترقية إلى 2.0.1 استثمارات كبيرة في تطوير الأجهزة والبرامج. دورات تنفيذ البرامج الثابتة طويلة ، وتكاليف الدعم اللاحقة مرتفعة. بالنسبة للمشغلين ، قد تتضمن ترقية البرامج الثابتة الحالية أو استبدالها عملاً واسع النطاق في الموقع.
اعتبارات الاستقرار: 1.6 وقد ثبت مستقرة على مدى سنوات عديدة. في حين أن 2.0.1 لديها تحسينات كبيرة ، إلا أن تعقيدها أعلى. بالنسبة للمشغلين الذين يعطون الأولوية للعمليات المستقرة ، فإن "العمل بشكل موثوق" غالبًا ما يفوق "المزيد من الميزات".
البدائل الوظيفية: يمكن تنفيذ العديد من ميزات 2.0.1 ، مثل دفع رمز الاستجابة السريعة وعرض الرسوم والجدولة الذكية ، في أنظمة 1.6 عبر التطبيقات الخارجية أو التطوير المخصص. على الرغم من أنها أقل أناقة ، إلا أنها تلبي الاحتياجات الأساسية.
القصور الذاتي للنظام البيئي: يتم بالفعل نشر الملايين من أجهزة 1.6 على مستوى العالم ، مما يشكل نظامًا بيئيًا كبيرًا. تدور الملحقات والأدوات ومهارات الموظفين حول 1.6. تتطلب الهجرة إعادة بناء هذه القدرات.
شبكات الشحن الجديدة: لتخطيط البنية التحتية الجديدة ، يوصى باعتماد 2.0.1 لتجنب تكاليف الترحيل المستقبلية والاستفادة الكاملة من أداء المعيار الجديد وقابليته للتوسع.
التطبيقات المتطورة: بالنسبة لمشاريع التوصيل والشحن و V2G ومشاريع الاستجابة للطلب المعقدة ، يعد 2.0.1 ضروريًا ، حيث لا يمكن لـ 1.6 دعم هذه الوظائف بشكل موثوق.
عمليات واسعة النطاق: يمكن للمشغلين الذين لديهم مئات أجهزة الشحن الاستفادة من تحسينات أداء 2.0.1 ونماذج الأجهزة التفصيلية ، مما يحسن الكفاءة التشغيلية.
الأمان والامتثال: يمكن للمناطق ذات البيانات الصارمة ولوائح الدفع أن تعتمد على آليات أمان 2.0.1 للوفاء بالامتثال بسهولة أكبر.
بالنسبة لمعظم المشغلين الحاليين ، فإن التحول الكامل إلى 2.0.1 ليس في الوقت المناسب بعد. النهج العملي هو:
الحفاظ على أجهزة 1.6 الحالية: استمر في تشغيل نظام 1.6 المستقر واستكمال الوظائف المفقودة بأنظمة خارجية.
حدد 2.0.1 للأجهزة الجديدة: اختر معدات متوافقة مع 2.0.1 للمحطات المبنية حديثًا.
طلب دعم الإصدار المزدوج: عند شراء معدات جديدة ، اطلب من البائعين دعم كل من 1.6 و 2.0.1 ، مع الاحتفاظ بالمرونة للترقيات المستقبلية.
مراقبة اتجاهات الصناعة: تتبع تقدم تنفيذ 2.0.1 البائعين الرئيسيين لتقييم توقيت الترحيل.
تشبه العلاقة بين OCPP 1.6 و 2.0.1 الانتقال من الهواتف المميزة إلى الهواتف الذكية. 1.6 بسيط وموثوق وكافٍ ، ويدعم الموجة الأولى من تطوير شبكة الشحن العالمية. 2.0.1 أكثر قوة وأمانًا ومرونة ، مما يضع الأساس لتجارب الشحن من الجيل التالي.
يعتمد الإصدار الذي تختاره على موقفك: إذا كان نظام 1.6 الحالي يعمل بشكل جيد دون الحاجة إلى ميزات عاجلة ، فيمكنك الانتظار ؛ للمشاريع الجديدة أو متطلبات الميزات المتقدمة ، احتضن 2.0.1 ؛ للسيناريوهات الواقعة بينهما ، اعتمد نهجًا تدريجيًا ، وإعداد أجهزة جديدة للمستقبل.
بغض النظر عن الإصدار ، يساعدك فهم هذه الاختلافات التقنية على اتخاذ قرارات أكثر ذكاءً وبناء شبكة شحن EV أكثر موثوقية وكفاءة.
