START CHARGING

كيفية بدء جلسة شحن باستخدام StartTransaction

مقدمة

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

‍

نناقش هنا كيفية بدء جلسة شحن مع طلب StartTransaction. تبدأ رسالة OCPP هذه الشحن وهي واحدة من أكثر الرسائل شيوعًا في عالم الشحن.

‍

من أجل بدء معاملة شحن بدأها عميل OCPP، نحتاج إلى رسائل OCPP التالية:

إشعار الحالة طلب
التخويل طلب
ابدأ المعاملة طلب

‍

أحداث المكونات الإضافية وإشعار الحالة

لبدء العملية، يجب أن يكون شاحن EV متاحًا للشحن. يقوم الشاحن بذلك عن طريق إرسال إشعار الحالة طلب (إشعار الحالة.req) إلى الواجهة الخلفية لـ OCPP. عندما لا يتم الشحن وتكون نقطة الشحن جاهزة للجلسة التالية، ستظهر رسالة الإشعار «متاح». أيضًا، تتبادل نقطة الشحن ونظام OCPP نبضات القلب، مما يدل على أن الاتصال ثنائي الاتجاه على قيد الحياة.

‍

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

‍

عندما يبدأ سائق EV الشحن، سيقوم بتوصيل قابس الشحن بمدخل السيارة. سيرسل الشاحن رسالة جديدة إشعار الحالة.req رسالة إلى خادم OCPP. تحتوي رسالة الإشعار هذه على معلومات «التحضير»، أو بعبارة أخرى، التحضير للشحن. بدون تحديث الحالة هذا، لن يبدأ الشاحن عملية الشحن.

‍

إذا كانت الواجهة الخلفية لـ OCPP جاهزة، فستستجيب بـ إشعار الحالة.conf رسالة لتأكيد استلام الرسالة وفهمها. لا يحتوي التأكيد على أي معلومات.

‍

أدناه ترى تدفق طلب إعلام الحالة في OCPP:

‍

‍

ال إشعار الحالة.req يتم استخدام الرسالة على نطاق واسع في العديد من السيناريوهات بعد بداية الجلسة. يتضمن المعلومات التالية:

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

‍

‍

في حالة إشعار الحالة.req ConnectorID، إذا كان الشاحن يحتوي على أكثر من منفذ واحد، فسيتم ترقيم ConnectorID، وما إلى ذلك، وهذا أمر مهم، حيث تسمح بعض أجهزة الشحن بالشحن المتزامن. قد يكون الموصل 1 بعد ذلك في حالة «التحضير» بينما لا يزال الموصل 2 في حالة «متاح». في حالة إمكانية شحن قابس واحد فقط في المرة الواحدة، سترسل الموصلات الأخرى طلب StatusNotification يحتوي على الحالة «غير متوفر».

هنا ترى مثالاً على إشعار الحالة.req‍

{
«معرف الموصل»: 1،
«رمز الخطأ»: «لا يوجد خطأ»،
«الحالة»: «التحضير»،
«الطابع الزمني»: «2022-06-12T 09:13:00.515 Z»
}

‍

طلب ترخيص السيارة وبطاقة الهوية

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

‍

للسماح بجلسة الشحن، يرسل الشاحن طلب التفويض (authorize.req) إلى الواجهة الخلفية لـ OCPP. المعلومات الوحيدة التي تحتوي عليها رسالة OCPP هي IDTag. ال IDTag عادةً ما تكون عبارة عن مجموعة من الأرقام والحروف (الرمز المميز)، والتي يجب تسجيلها في شبكة الشحن هذه أو نقطة الشحن هذه.

‍

‍

‍

تستجيب الواجهة الخلفية لـ OCPP بتأكيد التفويض (قم بتفويذ.conf) تحتوي على حالة التخويل «مقبولة». هذا يعني أن النظام المركزي تحقق من IDTag ويسمح للسائق بشحن السيارة. إذا لم يتمكن النظام المركزي من التحقق من الهوية، فإنه يعرض «غير صالح» أو «محظور» أو «منتهي الصلاحية».

‍

ابدأ طلب الشحن وعرض الطاقة

أخيرًا، بعد تغيير الحالة من «متاح» إلى «التحضير» والترخيص الناجح، يبدأ المستخدم جلسة الشحن. لذلك، يرسل الشاحن طلب بدء المعاملة (ابدأ المعاملة. req).

‍

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

‍

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

‍

‍

يتضمن كل من الطلب ورسالة التأكيد معلومات مهمة نريد مناقشتها:

معرف الموصل: معرف قابس الشاحن، عادةً 1، 2، 3، إلخ.
IDTag: نفس الرمز الذي أرسلناه وصرحنا به في authorize.req. سيضمن ذلك الموافقة على الجلسة.
بدء تشغيل العداد: يرسل الشاحن قيمة العداد (الطاقة، بالواط) لبداية جلسة الشحن. يمكن أن تكون هذه القيمة إما صفرية أو أي قيمة إيجابية وستساعد في حساب إجمالي استخدام الطاقة أثناء جلسة الشحن.
معرف الحجز: غير مناسب لهذا السيناريو، ولكن هذا الحقل سيحتوي على معرف الحجز المعروف بالواجهة الخلفية لـ OCPP ويسمح برفض طلب الشحن أو قبوله. غالبًا ما يتم استخدام هذا للشحن العام عندما يمكن للسائقين حجز نقطة شحن مسبقًا.

‍

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

‍

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

‍

‍

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

‍

هنا يمكنك رؤية مثال لـ ابدأ المعاملة. req و ال ابدأ المعاملة. conf:

ابدأ المعاملة. req‍