شرح وحدات OCPI 2.2.1: المواقع والجلسات وسجلات CDR والتعرفات وغيرها

OCPI (Open Charge Point Interface) هو البروتوكول الذي تتبادل به شبكات الشحن ومزودو خدمات التنقل المواقع والجلسات والأسعار وسجلات الفوترة، والإصدار 2.2.1 هو الأكثر تطبيقًا في أوروبا اليوم. وإذا كنت تربط نظام CSMS بشريك تجوال أو منصة، فستقضي معظم وقتك داخل وحداته.

يشرح هذا الدليل كل وحدة، ومن يرسل البيانات ومن يستقبلها، وأين تتعثر عمليات التكامل عادة. وللصورة العامة ابدأ بمقالنا ما هو OCPI والفرق بينه وبين OCPP.

كيف ينتظم OCPI 2.2.1؟

OCPI بروتوكول REST/JSON، يعرض فيه كل طرف نقاط اتصال HTTPS ويستدعي نقاط الطرف الآخر. وتُجمع الوحدات حسب الغرض، وتُنفذ كل وحدة كزوج من الواجهات: المرسل يملك البيانات، والمستقبل يخزنها أو يتصرف بناءً عليها. فالمشغّل مثلًا مرسل في وحدة Locations ومستقبل في وحدة Tokens.

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

وحدات الإعداد

Versions

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

Credentials والتسجيل

تنشئ وحدة Credentials الاتصال الآمن، إذ يتسلم الطرف A رمزًا (يسمى غالبًا Token A) عبر قناة منفصلة، ثم يستدعي نقطة Versions لدى الطرف B ويرسل بيانات اعتماده مع رمز جديد Token B، فيرد الطرف B برمز Token C الذي يستخدمه A في كل الاستدعاءات التالية. ويسرد كائن Credentials أيضًا أدوار كل طرف مثل CPO أو EMSP أو HUB مع رمز الدولة ومعرّف الطرف.

نظرة سريعة على الوحدات الوظيفية

Locations

تتبع وحدة Locations تسلسلًا من ثلاثة مستويات: الموقع يضم نقاط EVSE، وكل نقطة تضم موصلات. وتحمل نقاط EVSE الحالة التي يراها السائقون في التطبيقات مثل AVAILABLE أو CHARGING أو OUTOFORDER، ويجب أن يكون لكل منها معرّف EVSE بصيغة صحيحة. أما الموصلات فتصف المعيار والشكل ونوع التيار والجهد والأمبير والتعرفات المطبقة.

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

Sessions

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

CDRs

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

Tariffs

تصف وحدة Tariffs مكونات السعر مثل ENERGY وTIME وPARKING_TIME وFLAT، مع قيود حسب ساعة اليوم ويوم الأسبوع والحد الأدنى أو الأقصى للطاقة ونطاقات القدرة. هذه البنية قوية لكن إساءة استخدامها سهلة، فانشر تعرفات تعطي بالضبط ما ستفوتره، وإلا اعترض الشركاء على السجلات. وللتصميم التجاري راجع نماذج التعرفة.

Tokens

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

Commands

تتيح وحدة Commands لمزود الخدمة أن يطلب من المشغّل START_SESSION أو STOP_SESSION أو RESERVE_NOW أو CANCEL_RESERVATION أو UNLOCK_CONNECTOR. والأوامر غير متزامنة: يؤكد المشغّل أولًا قبول الأمر، ثم يرسل النتيجة الفعلية إلى عنوان استجابة عندما يرد الشاحن. ويترجم النظام هذه الأوامر داخليًا إلى رسائل OCPP مثل RemoteStartTransaction.

ChargingProfiles

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

HubClientInfo

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

الدفع والسحب والتقسيم إلى صفحات

تدعم معظم الوحدات الدفع (يستدعي المرسل المستقبل عند كل تغيير) والسحب (يجلب المستقبل القوائم دوريًا). ويستخدم السحب المعاملات date_from وdate_to وoffset وlimit، وتعود معلومات الصفحات في الترويسات Link وX-Total-Count وX-Limit. استخدم الدفع للتحديثات اللحظية، والسحب كشبكة أمان لالتقاط الرسائل الفائتة.

رموز حالة OCPI

أخطاء التكامل الشائعة

• ترميز الرمز: يتوقع OCPI 2.2 أن يكون الرمز مرمّزًا بـ Base64 في ترويسة Authorization، وأي اختلاف يسبب أخطاء 401 صامتة.
• المناطق الزمنية: كل الطوابع الزمنية بتوقيت UTC، وساعات العمل المحلية مكانها حقل المنطقة الزمنية في الموقع.
• معرّفات الأطراف: يجب أن يتطابق رمز الدولة ومعرّف الطرف في كل كائن، وإلا رفضه الشركاء.
• عدم تطابق التعرفة: مبلغ CDR الذي لا يمكن إعادة حسابه من التعرفة المنشورة يؤدي إلى نزاعات.
• غياب إعادة المحاولة: يجب إعادة الدفع الفاشل، ويجب أن يسد السحب الدوري الفجوات.

الأسئلة الشائعة

يدعم Üreticy التجوال عبر OCPI إلى جانب OCPP 1.6J و2.0.1 و2.1، مع سجلات رسائل كاملة لكل شريك. استكشف المنصة أو تحدث مع فريقنا.