تشغيل شبكة شحن للسيارات الكهربائية لا يعني تركيب الأجهزة في المواقع فحسب، بل إدارتها ببرنامج موثوق. يجب مراقبة أجهزة الشحن من علامات تجارية مختلفة من لوحة واحدة، واكتشاف الأعطال عن بُعد، وتحديث التعرفات والعروض فورًا، وأن يتمكن السائق من إيجاد المحطة وبدء الشحن والدفع من التطبيق دون عوائق. لذلك يحتاج مشغلو شبكات الشحن إلى نظام إدارة نقاط الشحن (CPMS) يدير الأجهزة مركزيًا ويقدم للسائق تطبيقًا ووسيلة دفع. تطوّر 360 Soft من إسطنبول الخادم الخلفي الذي يتحدث مع الأجهزة عبر بروتوكول OCPP، وتطبيق السائق، ولوحة المشغل معًا.
تخاطب هذه الصفحة المشغلين والمستثمرين في السعودية والإمارات وقطر وسائر دول الخليج، حيث تتوسع شبكات الشحن في المدن والطرق السريعة ومراكز التسوق والفنادق والمجمعات السكنية. ستجد هنا وحدات البرنامج، والتقنيات المستخدمة، والإطار التنظيمي، ونماذج التسليم والفرق، والمدد المعتادة، ومؤشرات SLA، ومنطق التسعير، ومقارنة المنصة الجاهزة بالتطوير المخصص، ومعايير الاختيار.
ما هو نظام إدارة نقاط الشحن (CPMS) ومن يستخدمه؟
نظام CPMS (Charge Point Management System) برنامج مركزي يدير نقاط الشحن عبر الإنترنت. تتصل الأجهزة بالنظام عبر بروتوكول OCPP (Open Charge Point Protocol)، فيبدأ النظام جلسات الشحن ويوقفها، ويسجل الاستهلاك، ويراقب حالة الجهاز، ويوزع تحديثات البرامج الثابتة، ويغذي الفوترة والدفع. وعلى جانب السائق يوجد تطبيق جوال وواجهة ويب، وعلى جانب المشغل لوحة إدارة وتقارير.
- مشغلو شبكات الشحن المرخصون: مع نمو الشبكة تزداد الحاجة إلى إدارة أجهزة متعددة العلامات ومرونة التعرفة والتقارير، وتصبح قيود الترخيص والتخصيص في المنصات الجاهزة عنق زجاجة.
- مراكز التسوق والفنادق والمجمعات السكنية ومحطات الوقود: تحتاج تعرفات خاصة لعملائها، وتكاملًا مع المواقف، وقواعد استخدام للسكان.
- شركات اللوجستيات والتأجير التي تدير شحن الأساطيل: تحتاج شحنًا في المستودعات واستهلاكًا لكل سائق وتوزيعًا للتكاليف بالتكامل مع برنامج متابعة سيارات الشركة والوقود.
- مصنّعو الأجهزة والموزعون: يريدون تقديم منصة إدارة بعلامتهم مع الأجهزة المباعة.
- شركات الطاقة ومستثمرو الطاقة الشمسية: يريدون إدارة الشحن مع الإنتاج المتجدد والتخزين معًا.
المشكلات الشائعة: انقطاع اتصال بعض الطرازات بشكل متكرر، واكتشاف العطل فقط بعد شكوى السائق، وتحديث التعرفات يدويًا في كل جهاز، وتعذر تطبيق اتفاقيات التجوال تقنيًا، وصعوبة مطابقة أخطاء الدفع، وإعداد التقارير التنظيمية يدويًا.
الوحدات والنطاق
| الوحدة | المحتوى | ملاحظات |
|---|---|---|
| اتصال الأجهزة (OCPP) | اتصال عبر OCPP 1.6J و2.0.1، بدء وإيقاف عن بُعد، تهيئة، تحديث البرامج الثابتة، سجلات التشخيص | خطة اختبار لكل طراز لدعم العلامات المتعددة |
| التعرفة والتسعير | رسوم حسب الكيلوواط ساعة والمدة ومدة الوقوف والجلسة؛ تعرفات زمنية؛ عروض وقسائم واشتراكات | تُنشر التعرفات مركزيًا وفورًا |
| تطبيق السائق | خريطة، توفر، حجز، بدء عبر QR أو RFID، متابعة حية، دفع، سجل وفواتير | iOS وAndroid والويب، بالعربية والإنجليزية |
| الدفع والفوترة | دفع بالبطاقة، محفظة، تفويض مسبق، فوترة آلية ومطابقة | تكامل مع مؤسسات دفع مرخصة |
| حسابات الشركات | حسابات الأساطيل والمجمعات ومراكز التسوق والفنادق، مجموعات مستخدمين، تعرفات خاصة، تقارير مراكز التكلفة | فوترة مجمّعة |
| لوحة المشغل | حالة الأجهزة الحية، تنبيهات، إدارة الجلسات، شاشات دعم العملاء | صلاحيات حسب الأدوار |
| الأعطال والصيانة | اكتشاف آلي للأعطال، أوامر عمل، تعيين الفرق الميدانية، سجل الصيانة | قابل للتكامل مع برامج الخدمة الميدانية |
| إدارة الطاقة | موازنة الأحمال، تحديد القدرة، ملفات شحن ذكية | حسب سعة الربط بالشبكة |
| التجوال (Roaming) | الاستخدام المتبادل والمطابقة مع الشبكات الأخرى عبر OCPI | مرتبط باتفاقيات الشراكة |
| التقارير | الطاقة والإيرادات والاستخدام وإتاحة الأجهزة والتقارير التنظيمية | تصدير وتكامل مع BI |
الحزمة التقنية
يُفضَّل في الخادم الخلفي معمارية قائمة على الأحداث قادرة على إدارة اتصالات WebSocket الدائمة لبروتوكول OCPP على نطاق واسع، وتُستخدم لهذا Node.js أو Go أو Java كثيرًا. تُستخدم قاعدة بيانات علائقية لبيانات الجلسات مع تخزين مناسب للسلاسل الزمنية، وتضمن طوابير الرسائل معالجة أحداث الأجهزة دون فقدان. يُطوَّر التطبيق بتقنيات أصلية أو متعددة المنصات ضمن خدمات تطوير التطبيقات، ويمكن تعزيز الفريق بـمطوري Node.js.
الإطار التنظيمي والمعايير
خدمة الشحن نشاط منظَّم، وتتحدث القواعد مع نضج القطاع. يعمل فريقنا في تركيا حيث تخضع شبكات الشحن لترخيص هيئة تنظيم سوق الطاقة (EPDK)، ونصمم البرنامج ليغطي جانب البيانات والتقارير في هذه الالتزامات. وفي السعودية والإمارات وقطر تنطبق متطلبات الجهات المختصة بالطاقة والكهرباء والبلديات في كل بلد؛ لذلك تُؤكَّد الالتزامات الحالية مع مستشارك القانوني في مرحلة الاستكشاف. العناوين التالية تمثل الإطار العام:
- الترخيص والتقارير: التزامات مشغل الشبكة ومشغل المحطة، وعرض الأسعار للمستخدم، ومشاركة معلومات إتاحة نقاط الشحن، ورفع البيانات المطلوبة للجهة التنظيمية.
- شفافية الأسعار وحقوق المستهلك: يجب أن يرى السائق الرسوم بوضوح قبل بدء الشحن، وأن يحصل على كشف مفصل وفاتورة بعد الجلسة.
- خدمات الدفع: تُنفَّذ عمليات البطاقات والمحافظ عبر مؤسسات دفع ونقود إلكترونية مرخصة؛ لا تُخزَّن بيانات البطاقات في CPMS، ويبقى معظم نطاق PCI DSS لدى مؤسسة الدفع.
- القياس: تُراعى دقة بيانات العدادات وقواعد المترولوجيا عند اختيار الأجهزة، ويحفظ البرنامج قيم القياس دون تعديل.
- حماية البيانات: هوية السائق ولوحة السيارة والموقع وعادات الشحن بيانات شخصية تخضع لنظام PDPL السعودي أو القانون الإماراتي لحماية البيانات حسب البلد، ولقانون KVKK التركي حيث نعمل، وGDPR عند الخدمة في أوروبا.
- المعايير التقنية: OCPP 1.6J و2.0.1 من Open Charge Alliance، وOCPI للتجوال، وISO 15118 للتواصل بين السيارة والشاحن (Plug and Charge)، وIEC 61851 على جانب الجهاز. وتُفضَّل ملفات الأمان في OCPP 2.0.1 (TLS وشهادات العميل) في التركيبات الجديدة.
نماذج التسليم والفرق
| النموذج | النطاق | متى يناسب |
|---|---|---|
| مشروع بنطاق ثابت | تسليم MVP أو منصة كاملة بوحدات محددة | مشغلون بمتطلبات واضحة يستهدفون الإصدار الأول |
| فريق مخصص | فريق منتج: دعم مالك المنتج، خلفية، جوال، اختبار، DevOps | تطوير مستمر وخارطة طريق مع نمو الشبكة |
| تعزيز الفريق | إضافة مطوري OCPP أو خلفية أو جوال إلى فريقك | فرق داخلية تنقصها كفاءات محددة |
| خدمة مُدارة | مراقبة النظام والتحديثات وإدارة الحوادث وفق SLA | بعد إطلاق المنصة |
العمل عن بُعد هو النموذج الأكثر شيوعًا للتطوير والتشغيل، مع العمل في الموقع لورش الاستكشاف والاختبارات الميدانية واختبارات القبول، أو نمط هجين. يتراوح الفريق من شخص واحد إلى أكثر من 200، مع مناوبات على مدار الساعة طوال الأسبوع عند الحاجة، وعملية استبدال للكوادر، وبدء معتاد خلال أسبوع إلى أسبوعين. يعمل المطورون ضمن توظيف 360 Soft وإدارتها بعقد خدمات بين شركتين (B2B).
مراحل المشروع والمدد المعتادة
| المرحلة | المحتوى | المدة المعتادة |
|---|---|---|
| الاستكشاف وتحليل المتطلبات | نموذج العمل، هيكل التعرفة، مخزون الأجهزة، الدفع والفوترة، التقارير، التكاملات | 2–3 أسابيع |
| المعمارية وتصميم تجربة المستخدم | معمارية النظام، نموذج البيانات، واجهات التطبيق واللوحة، تصميم الأمان | 2–4 أسابيع |
| تطوير MVP | اتصال OCPP، تعرفة أساسية، تطبيق السائق، الدفع، لوحة المشغل، تقارير أساسية | 3–5 أشهر |
| اختبارات تكامل الأجهزة | اختبارات مخبرية وميدانية لكل طراز ومعالجة عدم التوافق | بالتوازي مع MVP |
| التجربة والإطلاق | استخدام حقيقي بعدد محدود من المحطات ثم انتقال تدريجي | 4–6 أسابيع |
| الميزات المتقدمة | التجوال، موازنة الأحمال، حسابات الشركات، الاشتراكات، Plug and Charge | حسب خارطة الطريق |
جدول SLA ومؤشرات الأداء
تنعكس جودة البرنامج مباشرة على تجربة السائق والإيرادات. تُتابع المؤشرات التالية في عقد التشغيل والصيانة، وتُحدَّد القيم المستهدفة معًا حسب حجم الشبكة وساعات التغطية.
| المؤشر | التعريف | لماذا يهم |
|---|---|---|
| إتاحة المنصة | نسبة الوقت الذي تعمل فيه خدمات CPMS والتطبيق والدفع | الانقطاع قد يوقف الشحن في الشبكة كلها |
| نسبة الأجهزة المتصلة | نسبة الأجهزة المتصلة والمتواصلة مع النظام | اكتشاف مبكر لمشكلات الاتصال |
| نجاح بدء الشحن | نسبة أوامر البدء الناجحة | المؤشر الرئيسي لرضا السائق |
| زمن الاستجابة للأوامر | الوقت بين البدء من التطبيق وبدء الجهاز بالشحن | تجربة المستخدم |
| زمن حل الحوادث | من اكتشاف الحادث الحرج حتى حله | يحد من فقدان الإيرادات |
| فرق مطابقة الدفع | الفرق بين سجلات الجلسات وسجلات مؤسسة الدفع | الدقة المالية |
| زمن اكتشاف العطل | مدة اكتشاف النظام لعطل الجهاز | التدخل قبل شكوى السائق |
نماذج التسعير والعوامل المؤثرة
لا نذكر أسعارًا في هذه الصفحة؛ فالتكلفة تتغير حسب نطاق الوحدات وتنوع الأجهزة والتكاملات وتوقعات التشغيل، ويُعد عرض مكتوب بعد الاستكشاف.
| النموذج | كيف يعمل | متى يناسب |
|---|---|---|
| سعر ثابت | قيمة مشروع لنطاق محدد | MVP بمتطلبات واضحة أو وحدة محددة |
| شخص/شهر | رسوم شهرية حسب الدور لفريق مخصص | منصة تُطوَّر باستمرار |
| بالساعة | ساعات التطوير والدعم الفعلية | تطويرات صغيرة واستشارات ودعم تكامل الأجهزة |
| حسب الاستخدام | رسوم شهرية لكل جهاز أو نقطة شحن متصلة في خدمة التشغيل | عندما يكون التشغيل والصيانة لدى المزوّد |
| العامل | الشرح |
|---|---|
| عدد علامات الأجهزة وطرازاتها | كل طراز يتطلب اختبار توافق مستقل |
| تعقيد التعرفة | تعرفات زمنية واشتراكات وتعرفات شركات |
| عدد المنصات | iOS وAndroid والويب والتطبيقات بعلامة خاصة |
| التكاملات | الدفع والمحاسبة وERP والمواقف والأساطيل والتجوال |
| الحجم والتكرار | عدد الأجهزة المتصلة وهدف الإتاحة |
| نطاق التشغيل | مراقبة في ساعات العمل أو على مدار الساعة |
منصة جاهزة أم مستقل أم تطوير مخصص؟
| المعيار | منصة SaaS جاهزة | تطوير مع مستقل | تطوير مخصص مع 360 Soft |
|---|---|---|---|
| سرعة البدء | الأسرع | غير واضحة | بضعة أشهر لإصدار MVP |
| التخصيص | بقدر ما تسمح المنصة | عالٍ لكنه محفوف بالمخاطر | مرونة كاملة حسب نموذج عملك |
| التكلفة طويلة المدى | ترخيص لكل جهاز أو جلسة يزيد مع نمو الشبكة | الصيانة غير واضحة | استثمار تطوير دون ارتباط بترخيص |
| ملكية البيانات والشيفرة | لدى المزوّد | حسب العقد | تُنقل إليك بالعقد |
| الاستمرارية | عالية | مرتبطة بشخص | بالفريق والتوثيق |
إذا كانت شبكتك صغيرة ونموذج عملك قياسيًا فقد يكون البدء بمنصة جاهزة منطقيًا. ومع نمو الشبكة وتنوع التعرفات ونماذج الشركات والتكاملات يصبح التطوير المخصص أجدى، ويُقيَّم القرار معًا في مرحلة الاستكشاف.
سيناريو توضيحي: شبكة شحن لسلسلة محطات وقود
سيناريو توضيحي، ولا يصف مشروع عميل حقيقي: سلسلة محطات وقود تركّب شواحن سريعة من علامتين مختلفتين وتبدأ بمنصة جاهزة، لكن برنامج الولاء وعروض المتجر داخل المحطة وتعرفات عملاء الأساطيل لا يمكن تطبيقها على المنصة. النهج المعتاد: اختبار توافق الأجهزة مع OCPP، وتطوير CPMS مخصص مع وحدات الولاء وحسابات الشركات وتطبيق السائق، ونقل المحطات تدريجيًا إلى النظام الجديد، ثم مواصلة التشغيل بعقد صيانة مع SLA. وتتغير المدة والنتائج حسب النطاق وتنوع الأجهزة. للاطلاع على إدارة المحطات راجع برنامج إدارة محطات الوقود.
المخاطر وسبل الحد منها
| الخطر | العَرَض | الإجراء |
|---|---|---|
| عدم توافق الأجهزة | تفسير بعض الطرازات لرسائل OCPP بشكل مختلف | خطة اختبار لكل طراز، ملفات تعريف للأجهزة، تواصل تقني مع المصنّع |
| انقطاع الاتصال | مشكلات الشبكة الخلوية أو أخطاء البرامج الثابتة | مزامنة الجلسات غير المتصلة، إعادة اتصال آلية، تنبيهات |
| أخطاء الدفع | فرق بين التفويض المسبق والاستهلاك الفعلي | منطق التفويض والإقفال، مطابقة يومية |
| الثغرات الأمنية | أوامر عن بُعد غير مصرح بها أو تسرب بيانات | ملفات أمان OCPP، إدارة الشهادات، اختبار اختراق، صلاحيات حسب الأدوار |
| مشكلات التوسع | بطء مع زيادة الأجهزة المتصلة | معمارية قابلة للتوسع أفقيًا، اختبارات حمل |
| الارتهان للمزوّد | بقاء الشيفرة والتوثيق لدى المزوّد | تسليم الشيفرة وتعريفات البنية والتوثيق لك |
الأمن وحماية البيانات والعقد والملكية الفكرية
- نوقّع اتفاقية عدم إفصاح متبادلة (NDA) في البداية، وتُعرَّف استراتيجية التعرفة واتفاقيات الأجهزة كمعلومات سرية ضمن عقد خدمات B2B.
- تُدمج قواعد الإشعار والموافقة والحفظ والإتلاف في التصميم وفق قانون حماية البيانات المعمول به في بلدك (PDPL السعودي أو القانون الإماراتي)، وKVKK، وGDPR عند الحاجة، ويُعالج الموقع بإذن المستخدم فقط.
- يُشفَّر اتصال OCPP عبر TLS، وتتم مصادقة الأجهزة بالشهادات، وتُحمى اللوحة بالتحقق الثنائي.
- لا تُخزَّن بيانات البطاقات في النظام، وتُنفَّذ المدفوعات عبر مؤسسات مرخصة.
- تُنقل الملكية الفكرية للشيفرة وتعريفات البنية والتوثيق إليك كما يحدد العقد، مع قائمة بتراخيص المكونات مفتوحة المصدر.
قائمة تحقق لاختيار المزوّد
- هل يملك خبرة اختبار OCPP 1.6J و2.0.1 على أجهزة حقيقية؟
- هل يقترح خطة اختبار ومصفوفة توافق لكل جهاز؟
- هل يشرح إدارة الجلسات غير المتصلة وانقطاع الاتصال؟
- هل يصمم مسار الدفع مع مؤسسات مرخصة ومنطق المطابقة؟
- هل يراعي متطلبات التقارير وشفافية الأسعار في بلدك؟
- هل يترك مكانًا في المعمارية للتجوال (OCPI) وموازنة الأحمال؟
- هل تُسلَّم الشيفرة والتوثيق لك؟
- هل يقدم SLA للتشغيل والصيانة بعد الإطلاق؟
- هل لديه خطة لاختبارات الأمان وإدارة الشهادات؟
- هل يقترح انتقالًا تدريجيًا مع خطة للتراجع؟
ويمكن التخطيط معًا لـعمليات DevOps والسحابة وصيانة البرمجيات ودعمها (AMS) بعد الإطلاق.
الأسئلة الشائعة
مع أي علامات أجهزة شحن يعمل البرنامج؟
يعمل مع الأجهزة التي تدعم OCPP، ويُجرى اختبار لكل طراز قبل التكامل وتُعد مصفوفة توافق.
هل يمكن طلب تطبيق الجوال فقط؟
نعم. إذا كان لديك CPMS فيمكن تطوير تطبيق للسائق يعمل عبر واجهاته البرمجية.
هل البنية التحتية للدفع مشمولة؟
نعم. يُبنى الدفع بالتكامل مع مؤسسات دفع مرخصة، ولا تُخزَّن بيانات البطاقات في النظام.
هل نستخدم OCPP 1.6J أم 2.0.1؟
معظم الأجهزة الميدانية ما زالت تدعم 1.6J، ويُفضَّل 2.0.1 في التركيبات الجديدة لمزايا الأمان وإدارة الأجهزة، وتُصمَّم المنصة لدعم الإصدارين معًا.
هل يمكن الانتقال من منصة جاهزة؟
نعم. تُوجَّه الأجهزة تدريجيًا إلى النظام الجديد، ويمكن نقل حسابات المستخدمين والبيانات التاريخية مع خطة تراجع.
هل يدعم التجوال (Roaming)؟
يمكن دعم الاستخدام المتبادل والمطابقة مع الشبكات الأخرى عبر OCPI، ويعتمد التطبيق على اتفاقيات الشراكة لديك.
هل يلبي متطلبات التقارير التنظيمية؟
يُصمَّم النظام لجمع البيانات اللازمة للتقارير التنظيمية وتصديرها، وتُؤكَّد الالتزامات الحالية في بلدك معك في مرحلة الاستكشاف.
هل يمكن تطبيق موازنة الأحمال؟
نعم. يمكن تقاسم القدرة داخل المحطة وتطبيق ملفات الشحن الذكي حسب سعة الربط بالشبكة.
متى يجهز إصدار MVP؟
يستغرق عادة بضعة أشهر شاملة الاستكشاف والتصميم، وتتغير المدة حسب تنوع الأجهزة وهيكل التعرفة والتكاملات.
لمن تعود ملكية الشيفرة المصدرية؟
تُنقل إليك الشيفرة وتعريفات البنية والتوثيق كما يحدد العقد.
هل تقدمون الدعم بعد الإطلاق؟
نعم. نقدم عقد تشغيل وصيانة مع SLA يشمل المراقبة وإدارة الحوادث والتحديثات والتطويرات.
صفحات ذات صلة
- تطوير التطبيقات في تركيا
- برنامج صيانة وأعطال محطات الطاقة
- إسناد قطاع الطاقة والبنية التحتية
- إسناد قطاع السيارات
- توظيف مطورين من تركيا
- حلولنا
- 360 Soft بالعربية
لنتحدث عن مشروعك
هل تريد مناقشة برنامج شبكة الشحن لديك ومخزون أجهزتك ونموذج التعرفة؟ تواصل معنا عبر الهاتف +90 850 335 10 87، أو البريد الإلكتروني info@360-soft.com، أو واتساب، أو من خلال صفحة التواصل. نشارك معك نطاق العمل والجدول الزمني وعرضًا مكتوبًا. 360 Soft Marketing Yazılım ve Danışmanlık Ltd. Şti.، Nidakule Ataşehir Batı، Barbaros Mah. Begonya Sk. No:1 D:2، 34746 أتاشهير/إسطنبول.
النسخة التركية من هذه الصفحة: Türkçe.
