1. ما هو برنامج حماية أمن العملاء (OCPP)، ولماذا يجب على كبار مسؤولي حماية العملاء الاهتمام به؟

بروتوكول OCPP (بروتوكول نقطة الشحن المفتوحة) هو معيار الاتصال بين محطات الشحن ونظام إدارة النظام المركزي (CSMS). يحدد هذا البروتوكول كيفية إبلاغ الشاحن عن حالته للمنصة، وكيفية استقباله للأوامر عن بُعد، وكيفية معالجته لعمليات تفويض الدفع، وكيفية إبلاغه عن الأعطال. باختصار: يحدد ما إذا كانت شبكة الشحن الخاصة بك مفتوحة أم محصورة بمورد واحد.

هناك أمران يجب على كل مدير تنفيذي للمنتجات فهمهما:

أولًا، بروتوكول OCPP معيار مفتوح. تتولى صيانته منظمة Open Charge Alliance (OCA) ولا يتبع لأي مصنّع أجهزة أو منصة برمجية بعينها. يمكن لشاحن متوافق مع OCPP التواصل مع أي نظام إدارة شحن متوافق معه. هذا يعني أنك لست مقيدًا بمورّد محدد على مستوى الأجهزة؛ فإذا أردت تغيير مزوّد المنصة خلال ثلاث سنوات، أو إضافة شواحن من مصنّع آخر إلى الشبكة نفسها، فإن تكلفة الانتقال تكاد تكون معدومة طالما أن كلا الطرفين يدعمان OCPP.

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

2. ما حققه معيار OCPP 1.6 - وأوجه قصوره

يُعدّ بروتوكول OCPP 1.6 (الذي صدر عام 2015، وتم تحديثه إلى 1.6J عام 2017) الإصدار الأكثر انتشارًا عالميًا لبروتوكول الشحن. وقد حقق هذا الإصدار مهمته الأساسية المتمثلة في توحيد إجراءات العمل الأساسية لإدارة جلسات الشحن، والتشغيل/الإيقاف عن بُعد، وإعداد التقارير، وتحديثات البرامج الثابتة.

ومع ذلك، فإن الإصدار 1.6 له ثلاثة قيود هيكلية:

1. لا يوجد نموذج بيانات جهاز موحد. لا يُعرّف معيار OCPP 1.6 نموذج بيانات موحدًا لمتغيرات الشاحن. فكل مُصنِّع يُعرِّف "طاقة الشحن" و"مستشعر درجة الحرارة" و"رمز العطل" بطريقة مختلفة. وعندما يُدير مُشغِّل معتمد شبكة شحن متعددة العلامات التجارية، قد يستخدم نفس المُعامل أسماء حقول ووحدات ونطاقات قيم مختلفة تمامًا بين مختلف علامات الشواحن. وهذا يُصعِّب عملية المراقبة والتشخيص الموحدة.

2. الأمن اختياري وليس إلزاميًا. تُعدّ مواصفات الأمان في بروتوكول OCPP 1.6 إضافات اختيارية. يتوفر في هذا الإصدار تشفير TLS، وإدارة الشهادات، وتحديثات البرامج الثابتة الآمنة، ولكنها ليست إلزامية. تعتمد العديد من التطبيقات العملية على اتصالات WebSocket غير مشفرة أو تستخدم شهادات موقعة ذاتيًا. وبحلول عام 2026، لن يكون هذا مقبولًا لنظام تشغيل يتعامل مع بيانات الدفع ومعلومات خصوصية المستخدم.

3. دعم الشحن الذكي رقيق. تتيح مجموعة ميزات الشحن الذكي في بروتوكول OCPP 1.6 تطبيق ملفات تعريف الشحن (حدود الطاقة، والفترات الزمنية)، لكنها تفتقر إلى الدعم الأصلي لإدارة الأحمال الديناميكية، ودمج الطاقة المتجددة، والشحن ثنائي الاتجاه من المركبة إلى الشبكة (V2G). هذه ليست حالات استخدام مستقبلية في عام 2026، بل هي متطلبات تشغيلية يتم تطبيقها على نطاق واسع.

3. OCPP 2.0.1: التحسينات الرئيسية من منظور مدير المشتريات

إنّ OCPP 2.0.1 (الذي صدر عام 2020، واكتملت أولى اختبارات الاعتماد عام 2023) ليس تحديثًا تدريجيًا لـ OCPP 1.6، بل هو إعادة كتابة معمارية كاملة. فيما يلي أهم خمسة تغييرات تهمّ مديري حماية البيانات.

3.1 التحسين 1: نموذج الجهاز - لغة إدارة موحدة

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

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

3.2 التحسين 2: بنية الأمان - أصبح بروتوكول أمان طبقة النقل (TLS) وإدارة الشهادات إلزاميًا

يرفع بروتوكول OCPP 2.0.1 مستوى إمكانيات الأمان التالية من اختيارية إلى إلزامية:

• تشفير TLS 1.2 (أو أعلى): يجب تشفير جميع الاتصالات بين الشاحن ونظام إدارة الاتصالات. لم يعد مسموحًا باتصالات WebSocket غير المشفرة.

• إدارة شهادات X.509: يحدد الإصدار 2.0.1 إدارة دورة حياة شهادات الشحن بالكامل - التثبيت والتجديد والإلغاء. وهذا يسمح لمسؤولي أمن المعلومات بإنشاء سلاسل ثقة قائمة على الشهادات، مما يمنع هجمات الوسيط والوصول غير المصرح به.

• تحديثات البرامج الثابتة الآمنة: يجب أن تكون حزم البرامج الثابتة موقّعة رقميًا، ويجب على الشاحن التحقق من التوقيع قبل التثبيت. هذا يمنع حقن البرامج الثابتة الخبيثة - وهي ثغرة أمنية معروفة في عمليات نشر الإصدار 1.6.

• سجل الأمان: تسجل أجهزة الشحن جميع الأحداث ذات الصلة بالأمان (فشل المصادقة، وتغييرات التكوين، وعمليات البرامج الثابتة)، ويمكن لنظام إدارة أمن الاتصالات (CSMS) جمع هذه السجلات وتحليلها بنشاط.

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

3.3 التحسين 3: الشحن الذكي - من الحدود الثابتة إلى التنسيق الديناميكي

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

يقدم الإصدار OCPP 2.0.1 ميزات الشحن الذكي الأكثر تطوراً:

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

• تكامل نظام إدارة الطاقة الخارجي: يدعم الإصدار 2.0.1 بشكل أصلي واجهات مع أنظمة إدارة الطاقة الخارجية (EMS)، مما يتيح لمحطات الشحن الاستجابة لإشارات الأسعار أو أوامر إرسال الشبكة.

• التكامل مع معيار ISO 15118: يدعم الاتصال الذكي للشحن مع السيارة - يمكن للسيارة إخبار الشاحن بحالة بطاريتها، ومستوى الشحن المستهدف، ووقت المغادرة المتوقع، ويقوم الشاحن بتحسين منحنى الشحن وفقًا لذلك.

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

3.4 التحسين 4: معالجة المعاملات - فوترة أكثر موثوقية

يُعيد نظام OCPP 2.0.1 تصميم مسار معالجة المعاملات ويُقدّم نموذجًا أكثر دقة لأحداث الفوترة. تشمل التحسينات الرئيسية ما يلي:

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

• دقة تفاصيل عملية الفوترة: الإصدار 1.6 يُصدر الفواتير على مستوى الجلسة. يدعم الإصدار 2.0.1 شرائح فوترة متعددة ضمن الجلسة الواحدة، على سبيل المثال، سعر محدد لأول 30 دقيقة، وسعر آخر بعدها. يتيح ذلك استراتيجيات تسعير أكثر مرونة.

• دعم الضرائب والرسوم الإضافية: يمكن أن تتضمن بيانات المعاملات تفاصيل الضرائب، مما يبسط الامتثال الضريبي متعدد الاختصاصات القضائية.

3.5 التحسين الخامس: عرض الرسائل وتجربة المستخدم

يُوحّد بروتوكول OCPP 2.0.1 تنسيق الرسائل لشاشات عرض الشواحن. يستطيع نظام إدارة خدمة الشحن (CSMS) إرسال رسائل مُهيكلة - معلومات التسعير، وحالة الشحن، وإشعارات الأعطال - ويعرضها الشاحن للمستخدم بتنسيق مُوحّد. بالنسبة لشبكات الشحن العامة، يُحسّن هذا من تجربة المستخدم: فبغض النظر عن نوع الشاحن الذي يستخدمه السائق، تتبع المعلومات المعروضة على الشاشة نفس التنسيق.

4. مسار الترقية: من الإصدار 1.6 إلى الإصدار 2.0.1

إنّ الترقية إلى OCPP 2.0.1 ليست مجرد "تحديث للبرامج الثابتة"، بل هي مشروع يشمل الأجهزة والمنصة والعمليات التشغيلية. فيما يلي مسار الترقية المرحلي.

4.1 المرحلة 1: التقييم (1-2 أسبوع)

الخطوة 1: تدقيق توافق الأجهزة. يتطلب بروتوكول OCPP 2.0.1 حدًا أدنى من متطلبات الأجهزة. قد تفتقر وحدات التحكم القديمة في الشواحن إلى قوة المعالجة أو الذاكرة أو تسريع الأجهزة لبروتوكول TLS اللازم لتشغيل حزمة بروتوكول 2.0.1. تواصل مع الشركة المصنعة للشاحن الخاص بك وتأكد، لكل طراز، مما إذا كان يدعم بروتوكول OCPP 2.0.1، وإلى أي مدى (يدعم الإصدار الكامل أو مجموعة فرعية من الميزات).

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

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

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

4.2 المرحلة الثانية: التخطيط (2-4 أسابيع)

الخطوة الرابعة: اختيار استراتيجية النشر. تتوفر ثلاث استراتيجيات:

• من الصفر: قم بنشر OCPP 2.0.1 مباشرة على المواقع الجديدة. هذا هو المسار الأمثل ويتجنب تكاليف الترحيل المستقبلية.

• التشغيل المتوازي: اختر موقعًا أو موقعين موجودين كموقعين تجريبيين. قم بترقية مجموعة فرعية من أجهزة الشحن إلى الإصدار 2.0.1 مع إبقاء الباقي على الإصدار 1.6. يجب أن يدعم نظام إدارة الشحن كلا الإصدارين من البروتوكول في آن واحد.

• التحديث الشامل: ترقية الشبكة بأكملها دفعة واحدة. مناسب فقط للشبكات الصغيرة (أقل من 20 شاحنًا)، أو حيث تم التحقق بدقة من توافق الأجهزة والمنصة.

الخطوة 5: وضع خطة للتراجع. كل عملية ترحيل تتطلب مسارًا مُثبتًا للتراجع. قبل البدء بعملية الترحيل الجماعي، تحقق من اكتمال عملية الرجوع من الإصدار 2.0.1 إلى الإصدار 1.6 على جهاز اختبار واحد. يجب أن يكون التراجع خطوة مُخطط لها، وليس إجراءً طارئًا.

4.3 المرحلة 3: التنفيذ (تختلف المدة حسب النطاق)

الخطوة 6: التحقق من صحة بيئة الاختبار. أكمل الاختبارات التالية في بيئة معزولة:

• 2.0.1 إنشاء وصيانة الاتصال بين الشاحن ونظام إدارة الاتصالات

• إكمال دورة حياة جلسة الشحن (بدء/إيقاف، فوترة، إعداد تقارير البيانات)

• تركيب شهادات TLS وتجديدها وإدارة انتهاء صلاحيتها

• إعداد التقارير وتحليل سجلات الأمان

• محاكاة الأعطال (فقدان الاتصال، شهادة غير صالحة، فشل التحقق من توقيع البرامج الثابتة)

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

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

4.4 المرحلة الرابعة: التحقق والتحسين (مستمرة)

بعد عملية الترحيل، راقب باستمرار المقاييس التالية مقارنةً بالقيم الأساسية قبل الترحيل:

• معدل نجاح جلسة الشحن

• معدل انقطاع الاتصال ووقت التعافي

• عدد أحداث الأمان وتوزيع أنواعها

• سلامة بيانات المعاملات ودقة الفواتير

• اعتماد الميزات الجديدة وفعاليتها (على سبيل المثال، تقليل ذروة الحمل من خلال الشحن الذكي)

5. الأخطاء الشائعة وكيفية تجنبها

فيما يلي الأخطاء الشائعة التي لوحظت في مشاريع الهجرة الحقيقية.

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

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

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

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

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

6. ملخص الورقة البيضاء الأمنية

تعتمد بنية الأمان الخاصة ببروتوكول OCPP 2.0.1 على المبادئ التالية:

الدفاع المتعدد الطبقات: لا يعتمد الأمن على آلية واحدة. يحمي تشفير TLS طبقة النقل. تحمي إدارة الشهادات الهوية والمصادقة. يحمي توقيع البرامج الثابتة سلامة التعليمات البرمجية. يوفر تسجيل الأمان سجلات التدقيق. لا ينبغي أن يؤدي فشل أي طبقة منفردة إلى انهيار الوضع الأمني العام.

مبدأ أقل الامتيازات: تُمنح أجهزة الشحن الحد الأدنى من الصلاحيات اللازمة لأداء وظيفتها. يدعم نظام إدارة الشهادات والأدوار في الإصدار 2.0.1 التحكم الدقيق في الوصول - فلا ينبغي لنظام مراقبة للقراءة فقط أن يتمتع بصلاحيات تحديث البرامج الثابتة أو تعديل التكوين.

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

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

7. بروتوكولات حماية البيانات عبر الإنترنت مقابل البروتوكولات الخاصة: المخاطر طويلة الأجل التي تواجه كبير مسؤولي حماية البيانات

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

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

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

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

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

8. قائمة إجراءات رئيس قسم حماية البيانات

إذا كنت تقوم حاليًا بتشغيل شبكة OCPP 1.6:

1. اطلب بيانات توافق OCPP 2.0.1 لكل طراز شاحن من مورد الأجهزة الخاص بك (ليس مواد تسويقية - المواصفات الفنية).

2. اطلب قائمة مفصلة بميزات دعم بروتوكول OCPP 2.0.1 من مزود نظام إدارة المحتوى الخاص بك

3. تحديد موقع أو موقعين منخفضَي المخاطر ووضع خطة تجريبية للهجرة

4. تضمين دعم OCPP 2.0.1 في المتطلبات الفنية لجميع عمليات شراء المعدات الجديدة

إذا كنت بصدد شراء معدات جديدة وبناء مواقع جديدة:

1. اشتراط دعم بروتوكول OCPP 2.0.1 (النسخة الكاملة، وليس جزءًا منها) بشكل صريح في وثائق المناقصة

2. إلزام الموردين بتقديم شهادة OCA أو تقارير اختبار مطابقة مكافئة من جهة خارجية

3. اشتراط دعم نظام إدارة المحتوى (CSMS) لكل من بروتوكول OCPP 1.6 و 2.0.1 - وهذا يحافظ على التوافق مع إضافات المعدات المستقبلية التي تعمل ببروتوكول 1.6.

4. تضمين التحقق الوظيفي الكامل لمجموعة رسائل OCPP 2.0.1 في اختبار القبول