مقایسه استراتژیک OCPP 1.6J در مقابل 2.0.1 برای اپراتورهای شارژ تجاری

مقایسه استراتژیک قطعی OCPP 1.6J در مقابل 2.0.1 برای اپراتورهای شارژ تجاری جهانی: تسلط بر مقیاس‌پذیری شبکه، امنیت سایبری پیشرفته، ادغام ISO 15118 و آینده‌نگری بلندمدت زیرساخت برای رشد پایدار خودروهای برقی

خلاصه اجرایی

چشم‌انداز شارژ خودروهای الکتریکی (EV) در حال تغییر و تحولی اساسی است. با افزایش پذیرش جهانی، پروتکل‌های ارتباطی اساسی که تعامل بین تجهیزات تأمین خودروهای الکتریکی (EVSE) و سیستم‌های مدیریت ایستگاه شارژ (CSMS) را کنترل می‌کنند، به نقطه کانونی استراتژی فنی برای اپراتورهای شارژ تجاری (CPO) تبدیل شده‌اند. پروتکل نقطه شارژ باز (OCPP)، که توسط اتحاد شارژ باز (OCA) نگهداری می‌شود، از یک چارچوب پیام‌رسانی ساده به یک استاندارد پیچیده، امن و بسیار مقیاس‌پذیر تبدیل شده است.

این راهنما، تحلیل فنی جامعی از گذار از OCPP 1.6J به OCPP 2.0.1 ارائه می‌دهد. ما تفاوت‌های معماری، بهبودهای امنیتی، الگوهای مدیریت دستگاه و نقش حیاتی ادغام ISO 15118 را بررسی می‌کنیم. برای خریداران و اپراتورها، این مقاله به عنوان مرجع قطعی برای تصمیم‌گیری‌های آگاهانه در زمینه خرید و مهاجرت در بازاری که به سرعت در حال رشد است، عمل می‌کند.

فصل 1: سیر تکامل استانداردهای شارژ خودروهای برقی: یک بستر تاریخی

پروتکل نقطه شارژ باز (OCPP) از نیاز به قابلیت همکاری متولد شد. در روزهای اولیه شارژ خودروهای برقی، تولیدکنندگان سخت‌افزار و ارائه‌دهندگان نرم‌افزار از پروتکل‌های اختصاصی استفاده می‌کردند و «باغ‌های محصور» ایجاد می‌کردند که رقابت و نوآوری را خفه می‌کرد. معرفی OCPP 1.2 و 1.5 زمینه را فراهم کرد، اما OCPP 1.6 بود که واقعاً صنعت را متحد کرد.

۱.۱ تسلط OCPP ۱.۶J

OCPP 1.6 که در سال ۲۰۱۵ منتشر شد، پیاده‌سازی JSON over WebSockets (1.6J) را معرفی کرد. این تغییر از پیام‌رسانی مبتنی بر SOAP به طور قابل توجهی سربار را کاهش داد و پیاده‌سازی را برای توسعه‌دهندگان ساده کرد. این نسخه ویژگی‌هایی مانند شارژ هوشمند و اعلان‌های وضعیت اضافی را معرفی کرد و آن را به استاندارد صنعتی برای تقریباً یک دهه تبدیل کرد.

۱.۲ پیدایش OCPP ۲.۰.۱

علیرغم موفقیت نسخه ۱.۶J، رشد این صنعت محدودیت‌های آن را آشکار کرد. مشکلات امنیتی، پیچیدگی مدیریت دستگاه و عدم پشتیبانی بومی از یکپارچه‌سازی پیشرفته شبکه (V2G) منجر به توسعه OCPP 2.0 و متعاقباً نسخه اصلاح‌شده OCPP 2.0.1 (منتشر شده در سال ۲۰۲۰) شد. OCPP 2.0.1 فقط یک به‌روزرسانی نیست؛ بلکه یک طراحی مجدد کامل با هدف پشتیبانی از نسل بعدی شبکه‌های شارژ پرقدرت، هوشمند و ایمن است.

فصل 2: ​​الگوهای ارتباطی زیربنایی: JSON، WebSockets و ساختارهای فریم

برای درک تفاوت بین این پروتکل‌ها، باید به ارتباطات سطح پایین نگاه کرد. هر دو پروتکل از JSON روی WebSockets استفاده می‌کنند، اما ساختار و نحوه‌ی مدیریت این پیام‌ها تفاوت قابل توجهی دارد.

۲.۱ لایه وب‌سوکت

هر دو نسخه از اتصالات WebSocket پایدار استفاده می‌کنند که امکان ارتباط دوطرفه کامل را فراهم می‌کند. این امر برای عملیات بلادرنگ، مانند متوقف کردن جلسه شارژ از یک برنامه تلفن همراه یا دریافت هشدارهای خطای فوری، بسیار مهم است.

۲.۲ تجزیه فریم پیام

یک پیام OCPP معمولی شامل یک شناسه نوع پیام، یک شناسه پیام منحصر به فرد، نام اقدام و بار داده (payload) است.

مثال فریم OCPP 1.6J (BootNotification)

«json [2, "123456", "BootNotification", { "chargePointVendor": "MidaPower", "chargePointModel": "Terra-X", "chargePointSerialNumber": "SN001", "firmwareVersion": "v1.2.3" }]«

مثال فریم OCPP 2.0.1 (BootNotification)

«json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`به افزایش جزئیات در نسخه ۲.۰.۱ توجه کنید.فیلد reason` به CSMS اجازه می‌دهد تا بفهمد که آیا بوت شدن به دلیل راه‌اندازی مجدد، روشن شدن سیستم یا فعال شدن watch-dog بوده است و منطق تشخیصی بهتری را فراهم می‌کند.

فصل 3: تغییر الگوی معماری: مدل دستگاه

مهم‌ترین تغییر فنی در OCPP 2.0.1، معرفی ... است.مدل دستگاه.

۳.۱ محدودیت‌های کلیدهای پیکربندی ۱.۶J

در OCPP 1.6J، پیکربندی سخت‌افزار از طریق یک لیست مسطح از «کلیدهای پیکربندی» (مثلاًفاصله ضربان قلب, زمان اتصال). با پیچیده‌تر شدن شارژرها (چند کانکتور، ماژول‌های برق یکپارچه، سیستم‌های خنک‌کننده پیچیده)، این فهرست مسطح غیرقابل مدیریت شد. هیچ روش استانداردی برای توصیف سلسله مراتب فیزیکی یک ایستگاه وجود نداشت.

۳.۲ رویکرد مدل دستگاه ۲.۰.۱

OCPP 2.0.1 یک مدل سلسله مراتبی متشکل از موارد زیر را معرفی می‌کند:قطعاتومتغیرهایک جزء می‌تواند «کنترل‌کننده»، «اتصال‌دهنده» یا «ماژول برق» باشد. هر جزء متغیرهایی دارد که حالت یا پیکربندی آن را نشان می‌دهند (مثلاًدما, ولتاژ, حداکثر جریان).

• کامپوننت: یک بخش فیزیکی یا منطقی از ایستگاه شارژ.
• متغیر: یک ویژگی خاص از آن مؤلفه.
• ویژگی‌ها: فراداده‌ای که متغیر (واحد، محدوده، نوع دسترسی) را توصیف می‌کند.

این امر امکان نظارت استاندارد را فراهم می‌کند. اکنون یک اپراتور می‌تواند به جای تکیه بر کلیدهای اختصاصی فروشنده، دمای یک ماژول برق خاص را با استفاده از یک مسیر استاندارد جستجو کند.

فصل ۴: امنیت سایبری: از «بهترین تلاش» تا TLS اجباری

در روزهای اولیه شارژ خودروهای برقی، امنیت اغلب یک موضوع فرعی بود. OCPP 1.6J پروفایل‌های امنیتی ارائه می‌داد، اما پیاده‌سازی آن در بین فروشندگان مختلف، متناقض بود.

۴.۱ پروفایل‌های امنیتی در ۱.۶J

OCPP 1.6J سه پروفایل امنیتی تعریف کرده است:

1. ناامنHTTP/WebSockets متن ساده.
2. مجوز پایه: TLS با نام کاربری/رمز عبور.
3. مبتنی بر گواهی: TLS با گواهی‌های سمت کلاینت.

مشکل این بود که بسیاری از شارژرها در پروفایل ۱ باقی می‌ماندند و همین امر آنها را در برابر حملات مرد میانی (MITM) و کنترل غیرمجاز آسیب‌پذیر می‌کرد.

۴.۲ موضع سرسختانه‌ی نسخه ۲.۰.۱

OCPP 2.0.1 ارتباطات امن را الزامی می‌کند. این نسخه ویژگی‌های امنیتی پیشرفته را به صورت بومی ادغام می‌کند:

• به‌روزرسانی‌های امن میان‌افزارامضا و تأیید اجباری تصاویر میان‌افزار.
• ثبت وقایع امنیتی: گزارش‌های دقیق برای رویدادهای مرتبط با امنیت (مثلاً تلاش‌های ناموفق برای ورود به سیستم، انقضای گواهی).
• مدیریت گواهینامهپیام‌های استاندارد برای گواهی‌های چرخشی و به‌روزرسانی‌شده (CSMS-led یا Station-led).
• TLS نسخه ۱.۲/۱.۳: پشتیبانی از آخرین استانداردهای رمزگذاری.

برای اپراتورهای تجاری، این امر خطر نفوذ گسترده به شبکه را کاهش می‌دهد و انطباق با مقررات نوظهور امنیت سایبری برای دستگاه‌های اینترنت اشیا را تضمین می‌کند.

فصل 5: یکپارچه‌سازی ISO 15118: اتصال و شارژ و V2G

آینده شارژ خودروهای برقی فقط به جابجایی الکترون‌ها مربوط نمی‌شود؛ بلکه به تبادل هوشمند داده‌ها و انرژی مربوط می‌شود. ISO 15118 استاندارد بین‌المللی برای ارتباط خودرو با شبکه (V2G) است و ادغام آن با OCPP ویژگی تعیین‌کننده نسخه ۲.۰.۱ است.

۵.۱ پیچیدگی اتصال و شارژ

قابلیت اتصال و شارژ (PnC) به راننده اجازه می‌دهد تا به سادگی وسیله نقلیه را به برق وصل کرده و بدون استفاده از برنامه یا کارت RFID، شارژ را شروع کند. این امر مستلزم یک زیرساخت کلید عمومی (PKI) پیچیده است که شامل وسیله نقلیه، شارژر، اپراتور و مرکز تسویه حساب می‌شود.

در OCPP 1.6J، پشتیبانی از PnC در پروتکل پایه وجود نداشت. فروشندگان مجبور بودند افزونه‌های سفارشی را پیاده‌سازی کنند که منجر به چندپارگی می‌شد. OCPP 2.0.1 با پشتیبانی از موارد زیر، «لوله‌کشی» PnC را فراهم می‌کند:

• نصب گواهینامهانتقال گواهی‌های قرارداد از CSMS به EV از طریق EVSE.
• مجوز: با استفاده از شناسه e-Mobility (eMAID) که از گواهی خودرو استخراج شده است.
• ارتباط رمزگذاری شدهاطمینان از محافظت از داده‌های حساس صورتحساب که بین خودرو و شبکه برق رد و بدل می‌شود.

۵.۲ شارژ هوشمند و متعادل‌سازی بار

در حالی که ۱.۶J از شارژ هوشمند اولیه (ارسال یک) پشتیبانی می‌کردتنظیمشارژپروفایل) ، ۲.۰.۱ این را ارتقا می‌دهد. این امکان را فراهم می‌کند:

• ادغام سیگنال خارجی: پاسخ بلادرنگ به فرکانس شبکه یا سیگنال‌های قیمت عمده‌فروشی.
• مدیریت بار پویاکنترل دقیق‌تر بر توزیع برق در یک سایت با صدها کانکتور.
• خودرو به شبکه (V2G): نسخه ۲.۰.۱ شامل فیلدهای داده لازم برای پشتیبانی از جریان انرژی دو طرفه است که به خودروهای برقی اجازه می‌دهد به عنوان منابع انرژی توزیع‌شده (DER) برای شبکه عمل کنند.

۵.۳ بهبود رابط کاربری/تجربه کاربری

OCPP 2.0.1 از نمایش اطلاعات مستقیماً روی صفحه نمایش شارژر یا داشبورد خودرو پشتیبانی می‌کند، مانند:

• قیمت‌گذاری لحظه‌ای به ارز محلی.
• زمان تخمینی برای رسیدن به ۸۰٪ حالت شارژ (SoC).
• اطلاعات دقیق رسید پس از تکمیل.

فصل 6: مدیریت و نظارت پیشرفته دستگاه

برای یک CPO، هزینه یک شارژر فقط قیمت خرید آن نیست؛ بلکه هزینه کل مالکیت (TCO) نیز هست. نگهداری و زمان از کارافتادگی بزرگترین عوامل کاهش سود هستند. OCPP 2.0.1 از طریق قابلیت‌های نظارتی برتر، این مشکل را برطرف می‌کند.

۶.۱ گزارش‌دهی مبتنی بر رویداد

در ۱.۶ ژول، CSMS معمولاً مجبور بود وضعیت شارژر را بررسی کند یا منتظر بمانداعلان وضعیتدر نسخه ۲.۰.۱،نظارت بر رویداداین سیستم به CSMS اجازه می‌دهد تا آستانه‌هایی را تعیین کند. برای مثال: «فقط در صورتی که دمای داخلی از ۷۰ درجه سانتیگراد بیشتر شد به من اطلاع بده» یا «اگر ولتاژ ورودی به زیر ۲۰۰ ولت رسید، گزارش بده». این کار ترافیک شبکه را کاهش می‌دهد و امکان نگهداری پیشگیرانه را فراهم می‌کند.

۶.۲ مدیریت تراکنش: رویداد تراکنش

یکی از جنبه‌های OCPP 1.6J که بیشترین انتقاد را به خود جلب کرد، نحوه‌ی مدیریت تراکنش‌ها در آن بود. جلسه‌ای که شاملشروع تراکنشوتوقف تراکنشپیام‌ها، اما اگر اختلالی در شبکه رخ می‌داد، CSMS اغلب برای تطبیق داده‌های صورتحساب با مشکل مواجه می‌شد.

OCPP 2.0.1 این موارد را با یک پروتکل واحد و قوی جایگزین می‌کند.رویداد تراکنشپیام. این پیام برای گزارش تمام مراحل چرخه حیات یک تراکنش (شروع، به‌روزرسانی، پایان) استفاده می‌شود. این پیام شامل یک پیام منحصر به فرد است.شناسه تراکنشاین امر حتی در صورت راه‌اندازی مجدد شارژر نیز ادامه می‌یابد و تضمین می‌کند که هیچ داده‌ای در حال شارژ - و در نتیجه هیچ درآمدی - از بین نمی‌رود.

۶.۳ بهبود تشخیص و عیب‌یابی

دریافت لاگواعلان وضعیت عیب‌یابیپیام‌ها در نسخه ۲.۰.۱ ساختاریافته‌تر هستند. CPOها می‌توانند انواع خاصی از گزارش‌ها (امنیتی، تشخیصی، کاربری) را درخواست کرده و محدوده زمانی را مشخص کنند. این امر به تیم‌های پشتیبانی از راه دور اجازه می‌دهد تا مشکلات را بدون اعزام تکنسین به محل حل کنند و به طور قابل توجهی هزینه عملیاتی را کاهش دهند.

فصل 7: مکانیسم‌های به‌روزرسانی میان‌افزار: قابلیت اطمینان و بازگشت به حالت اولیه

به‌روزرسانی‌های میان‌افزار، نیروی حیاتی سخت‌افزارهای در حال تکامل هستند، اما یک به‌روزرسانی ناموفق می‌تواند شارژر را از کار بیندازد.

۷.۱ فرآیند به‌روزرسانی ۱.۶J

در ۱.۶ ژول،به‌روزرسانی میان‌افزاردستور نسبتاً ساده بود. شارژر، ایمیج را دانلود و سعی در نصب آن می‌کرد. هیچ مکانیزم استانداردی برای به‌روزرسانی‌های چند مرحله‌ای یا رول‌بک‌های تأیید شده وجود نداشت.

۷.۲ به‌روزرسانی چند مرحله‌ای ۲.۰.۱

OCPP 2.0.1 چرخه حیات پیچیده‌تری را برای به‌روزرسانی‌های میان‌افزار معرفی می‌کند:

1. دانلودشارژر تصویر را دریافت کرده و چک‌سام/امضای آن را تأیید می‌کند.
2. نصب: به‌روزرسانی روی یک پارتیشن ثانویه اعمال می‌شود.
3. تأیید: سیستم بررسی می‌کند که آیا میان‌افزار جدید به درستی بوت می‌شود یا خیر.
4. فعال‌سازی: پارتیشن اصلی (primary) تغییر می‌کند.

اگر هر مرحله با شکست مواجه شود، پروتکل نحوه بازگشت شارژر به نسخه پایدار قبلی و گزارش کد خرابی خاص به CSMS را تعریف می‌کند. این سطح از قابلیت اطمینان برای استقرارهای تجاری در مقیاس بزرگ غیرقابل مذاکره است.

۷.۳ تأیید امضا

برای جلوگیری از آپلود میان‌افزار آلوده توسط افراد مخرب، نسخه ۲.۰.۱ استفاده از امضاهای دیجیتال را الزامی می‌کند. شارژر از اجرای هر کدی که توسط کلید خصوصی سازنده امضا نشده باشد، خودداری می‌کند و یک لایه حفاظتی حیاتی در برابر هک‌های سطح سخت‌افزاری اضافه می‌کند.

فصل ۸: حریم خصوصی داده‌ها، انطباق با مقررات و GDPR

با تبدیل شدن شارژ خودروهای برقی به یک ابزار روزمره، میزان داده‌های شخصی تولید شده سرسام‌آور است. یک جلسه شارژ می‌تواند هویت کاربر، موقعیت مکانی وسیله نقلیه او، الگوهای سفر او و اطلاعات مالی او را به هم مرتبط کند.

۸.۱ اطلاعات شخصی قابل شناسایی (PII) در OCPP

در چارچوب مقررات عمومی حفاظت از داده‌ها (GDPR) در اروپا و قوانین مشابه مانند CCPA در کالیفرنیا، نقاط داده‌ای مانندشناسه برچسب(RFID) یاای‌وای‌سی‌دی(شناسه خودرو) به عنوان PII در نظر گرفته می‌شوند.

OCPP 2.0.1 کنترل‌های بهتری برای ناشناس‌سازی داده‌ها ارائه می‌دهد. برای مثال،داده‌های سفارشیفیلدها به اپراتورها اجازه می‌دهند تا فراداده‌ها را بدون افشای اطلاعات شخصی (PII) در گزارش‌های پروتکل اصلی ذخیره کنند. علاوه بر این، پروفایل‌های امنیتی پیشرفته تضمین می‌کنند که این داده‌ها هم در حین انتقال و هم در حالت سکون رمزگذاری می‌شوند.

۸.۲ حق فراموش شدن و قابلیت انتقال داده‌ها

ماهیت ساختاریافته‌ی مدل دستگاه ۲.۰.۱، پیاده‌سازی درخواست‌های «حذف داده‌ها» را برای ارائه‌دهندگان CSMS آسان‌تر می‌کند. در یک سیستم ۱.۶J، یافتن تمام نمونه‌های شناسه‌ی کاربر در کلیدهای پیکربندی و گزارش‌های ناهمگون، یک کابوس دستی بود. در ۲.۰.۱، جداسازی واضح بین وضعیت دستگاه و داده‌های تراکنش، امکان معماری پایگاه داده‌ی تمیزتری را فراهم می‌کند.

۸.۳ انطباق با قوانین امنیتی اینترنت اشیا

بسیاری از مناطق اکنون در حال تصویب قوانینی هستند که دستگاه‌های اینترنت اشیا را ملزم به داشتن رمزهای عبور منحصر به فرد و مکانیسم‌های به‌روزرسانی ایمن می‌کند. TLS اجباری و میان‌افزار امضا شده در OCPP 2.0.1 فقط ویژگی‌های «خوب» نیستند - بلکه الزامات قانونی برای فروش سخت‌افزار در بازارهایی مانند کالیفرنیا و بریتانیا هستند.

فصل 9: دیدگاه خریدار: TCO، ROI و مهاجرت استراتژیک

برای یک اپراتور شارژ تجاری، تصمیم به پایبندی به ۱.۶J یا حرکت به سمت ۲.۰.۱ یک تصمیم مالی است.

۹.۱ هزینه اجرا

• او سی پی پی ۱.۶ ژول: پیاده‌سازی ارزان، پشتیبانی گسترده از سخت‌افزار کم‌هزینه، اما هزینه‌های پنهان بالایی در نگهداری و خطرات امنیتی دارد.
• او سی پی پی ۲.۰.۱: به پردازنده‌های قدرتمندتر و حافظه بیشتری در EVSE نیاز دارد. هزینه‌های توسعه برای CSMS به دلیل پیچیدگی پروتکل بالاتر است. با این حال، از طریق مدیریت از راه دور و قابلیت اطمینان بهتر، صرفه‌جویی قابل توجهی در هزینه‌های عملیاتی ارائه می‌دهد.

۹.۲ افسانه «ارتقاء روان»

اغلب گفته می‌شود که شارژرهای ۱.۶J را می‌توان از طریق نرم‌افزار به ۲.۰.۱ ارتقا داد. در واقع، این به ندرت درست است. حافظه و پردازنده مورد نیاز برای ۲.۰.۱ (به خصوص مدیریت گواهی‌های TLS و تجزیه پیچیده JSON مدل دستگاه) اغلب از قابلیت‌های کنترلرهای قدیمی‌تر ۱.۶J فراتر می‌رود.

۹.۳ مسیرهای مهاجرت استراتژیک

مدیران ارشد تولید (CPO) باید رویکرد «شبکه ترکیبی» را در نظر بگیرند:

1. سایت‌های قدیمی: برای شارژرهای AC کم مصرف موجود، به جریان ۱.۶ ژول ادامه دهید.
2. سایت‌های جدید شارژ سریع DC: الزام نسخه ۲.۰.۱ برای تمام استقرارهای جدید با توان بالا جهت پشتیبانی از PnC و V2G.
3. راهکارهای پروکسی: از یک دروازه پروتکل استفاده کنید که بتواند پیام‌های ۱.۶J را به فرمتی سازگار با ۲.۰.۱ برای CSMS ترجمه کند و امکان ایجاد یک داشبورد مدیریتی یکپارچه را فراهم کند.

فصل 10: آینده‌نگری: OCPP 2.1 و مسیر شارژ خودکار

حتی با وجود اینکه نسخه ۲.۰.۱ مورد توجه قرار گرفته است، اتحادیه Open Charge در حال حاضر روی OCPP 2.1 کار می‌کند. این نسخه آینده، دامنه دسترسی پروتکل را بیشتر گسترش خواهد داد.

۱۰.۱ شارژ دوطرفه (V2X)

در حالی که نسخه ۲.۰.۱ از V2G پایه پشتیبانی می‌کند، نسخه ۲.۱ ارتباطات خودرو به خانه (V2H) و خودرو به ساختمان (V2B) را بهبود می‌بخشد و به خودروهای برقی اجازه می‌دهد در زمان خاموشی برق خانه‌ها را تأمین کنند یا تقاضای اوج مصرف برای ساختمان‌های تجاری را کاهش دهند.

۱۰.۲ پشتیبانی از شارژ بی‌سیم

با ظهور وسایل نقلیه خودران (AV)، اتصال دستی منسوخ خواهد شد. OCPP 2.1 شامل پیام‌های استاندارد برای شارژ القایی (بی‌سیم)، مدیریت هم‌ترازی و انتقال انرژی بدون دخالت انسان خواهد بود.

۱۰.۳ ادغام با شهرهای هوشمند

احتمالاً در نسخه‌های آینده شاهد ادغام عمیق‌تر با سیستم‌های مدیریت ترافیک و پیش‌بینی‌های انرژی تجدیدپذیر خواهیم بود. شارژرها قادر خواهند بود در بازارهای انرژی به صورت آنی برای برق «پیشنهاد» بدهند و شبکه‌های شارژ را به نیروگاه‌های مجازی عظیم (VPP) تبدیل کنند.

پیوست فنی: بررسی عمیق مقایسه پیام‌ها

برای ارائه نهایت عمق فنی، اکنون توالی‌های پیام خاص و تفاوت‌های فریم بین دو نسخه را تجزیه و تحلیل خواهیم کرد.

الف.1 جریان مجوزدهی

در نسخه ۱.۶J، مجوزدهی به صورت پاسخ دودویی «پذیرفته‌شده» یا «مسدود شده» بود.

۱.۶J پاسخ تأیید:«json [3, "123456", { "idTagInfo": { "status": "Accepted", "expiryDate": "2026-12-31T23:59:59Z" } }]«

در نسخه ۲.۰.۱، پاسخ شامل زمینه بیشتری است، مانندشناسه توکننوع و اطلاعات اضافی برای رابط کاربری.

۲.۰.۱ پاسخ مجوز:«json [3, "987654", { "idTokenInfo": { "status": "Accepted", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "جان، خوش برگشتی! موجودی شما ۴۵.۰۰ دلار است" } } }]«

الف.۲ مدیریت ضربان قلب و اتصال

OCPP 2.0.1 نحوه اثبات «زنده بودن» ایستگاه را بهینه می‌کند. در 1.6J، اگرضربان قلباگر شکست می‌خورد، ایستگاه اغلب دوباره تلاش می‌کرد. در نسخه ۲.۰.۱، ایستگاه می‌تواند ازرویداد اطلاع‌رسانیمکانیزمی برای گزارش قطع اتصال آن به یک backend ثانویه، در حالی که همچنان ضربان قلب را با اولیه حفظ می‌کند.

الف.3 جدول فراداده تفصیلی

نتیجه‌گیری

گذار از OCPP 1.6J به 2.0.1 صرفاً یک به‌روزرسانی نرم‌افزاری نیست؛ بلکه یک تکامل اساسی در اکوسیستم حمل‌ونقل الکتریکی است. برای اپراتورهای تجاری، 1.6J نشان‌دهنده گذشته‌ای قابل اعتماد است، در حالی که 2.0.1 نشان‌دهنده آینده‌ای مقیاس‌پذیر، امن و هوشمند است.

انتخاب نسخه ۲.۰.۱ در حال حاضر، سرمایه‌گذاری روی طول عمر آن است. این امر تضمین می‌کند که سخت‌افزار شما با نسل بعدی خودروهای برقی سازگار خواهد بود، با مقررات سختگیرانه‌تر امنیت سایبری مطابقت دارد و برای فرصت‌های سودآور ادغام V2G و شبکه هوشمند آماده است. با تثبیت بازار، اپراتورهایی که قوی‌ترین و انعطاف‌پذیرترین پشته‌های پروتکل را دارند، پیشرو خواهند بود.

فصل 11: بررسی عمیق: تحلیل جریان پیام و نمودارهای توالی

در این فصل، توالی‌های تعامل بین EVSE و CSMS را تجزیه و تحلیل می‌کنیم تا تفاوت‌های عملیاتی بین 1.6J و 2.0.1 را نشان دهیم.

۱۱.۱ توالی بوت و پیکربندی

وقتی یک شارژر برای اولین بار به شبکه متصل می‌شود، باید خود را شناسایی کرده و پیکربندی خود را همگام‌سازی کند.

جریان OCPP 1.6J:

1. اتصال وب سوکت: روی پورت ۸۰ یا ۴۴۳ برقرار شده است.
2. بوت نوتیفیکیشن: ایستگاه، فروشنده، مدل و سریال را ارسال می‌کند.
3. دریافت پیکربندی: CSMS برای بررسی وضعیت فعلی، از تمام کلیدها درخواست می‌کند.
4. تغییر پیکربندی: CSMS کلیدهای خاص را به‌روزرسانی می‌کند (مثلاً،فاصله ضربان قلب).
5. اعلان وضعیت: گزارش ایستگاه «موجود» است.

جریان OCPP 2.0.1:

1. دست‌دهی امن TLS: تعویض اجباری گواهینامه.
2. بوت نوتیفیکیشنشامل می‌شوددلیل(مثلاً،پاورآپ).
3. GetBaseReportبه جای درخواست تمام کلیدها، CSMS یک «گزارش پایه» درخواست می‌کند که سلسله مراتب کامل مدل دستگاه را ارائه می‌دهد.
4. متغیرهای تنظیمی: CSMS متغیرها را به‌روزرسانی می‌کند. توجه داشته باشید که نسخه ۲.۰.۱ امکان به‌روزرسانی‌های اتمی را فراهم می‌کند - تنظیم چندین متغیر در یک پیام و اطمینان از موفقیت همه یا عدم موفقیت هیچ‌کدام.
5. رویداد اطلاع‌رسانیایستگاه، حالت‌های اولیه اجزا را گزارش می‌دهد.

۱۱.۲ مذاکره هوشمند برای دریافت هزینه

شارژ هوشمند جایی است که نسخه ۲.۰.۱ واقعاً می‌درخشد، به‌خصوص هنگام مدیریت چندین پروفایل شارژ.

در ۱.۶ ژول، CSMS یکتنظیمشارژپروفایلکه سطح پشته و زمان‌بندی را تعریف می‌کند. اگر یک ایستگاه چندین کانکتور داشته باشد، مدیریت پروفایل اغلب مبهم است.

در نسخه ۲.۰.۱،تنظیمشارژپروفایلبه طور صریح به یک پیوند داده شده استشارژمشخصاتهدف.

• مشخصات ChargingStationMax: ورودی کل ایستگاه را محدود می‌کند.
• نمایه پیش‌فرض TX: پیش‌فرض برای هر تراکنش جدید.
• پروفایل TX: مختص یک تراکنش در حال انجام.

علاوه بر این، نسخه ۲.۰.۱ از موارد زیر پشتیبانی می‌کند:GetChargingStackLevelاین پیام به CSMS اجازه می‌دهد تا ببیند کدام پروفایل‌ها در حال حاضر فعال هستند و چگونه توسط برنامه‌ریز داخلی EVSE اولویت‌بندی می‌شوند.

۱۱.۳ راه اندازی و کنترل از راه دور

دستورات از راه دور مانندشروع مجدد تراکنش(1.6J) جایگزین شده اند بادرخواستشروع تراکنش(2.0.1). تفاوت کلیدی در بار مفید (payload) است. در 2.0.1، CSMS می‌تواند شامل موارد زیر باشد:شارژمشخصاتمستقیماً در درخواست شروع. این بدان معناست که خودرو می‌تواند بلافاصله و بدون انتظار برای پیام دوم، شارژ را در سطح توان صحیح شروع کند، که این امر باعث کاهش تأخیر و بهبود پایداری شبکه می‌شود.

فصل 12: مقایسه‌های طرحواره و فیلد JSON سطح پایین

برای توسعه‌دهندگان و یکپارچه‌سازان سیستم، تغییرات طرحواره، پرزحمت‌ترین بخش مهاجرت است.

۱۲.۱ انواع شمارشی (Enums)

OCPP 2.0.1 تعداد Enumهای استاندارد را به میزان قابل توجهی افزایش می‌دهد و نیاز به کدهای وضعیت «سفارشی» را که پیاده‌سازی‌های 1.6J را با مشکل مواجه می‌کرد، کاهش می‌دهد.

• Enum های دلیل: دیده‌بان, تنظیم مجدد زمان‌بندی‌شده, تنظیم مجدد از راه دور, افت توان.
• Enum های وضعیت: اشغال شده, رزرو شده, موجود نیست, خطا داده شده۲.۰.۱ اضافه می‌شودموجود است, اشغال شده, رزرو شده, موجود نیست, خطا داده شدهاما با زیرمقیاس‌هایی برای جزئیات بیشتر.

۱۲.۲ انواع داده‌ها و واحدها

OCPP 2.0.1 استفاده از واحدهای استاندارد (SI) را رسمیت می‌بخشد. در حالی که 1.6J گاهی اوقات دقت اعشاری را تعریف نمی‌کند، 2.0.1 ازاعشاریانواع مقادیر برق و انرژی، تضمین صدور صورتحساب یکسان در بین سخت‌افزارهای فروشندگان مختلف.

فصل ۱۳: مطالعه موردی: مهاجرت جهانی CPO از ۱.۶J به ۲.۰.۱

بیایید به یک سناریوی فرضی از «مگاشارژ»، یک CPO با ۱۰،۰۰۰ نقطه شارژ، نگاهی بیندازیم.

۱۳.۱ مرحله ۱: حسابرسی

مگاشارژ متوجه شد که ۴۰ درصد از ناوگان ۱.۶J آنها از TLS 1.2 پشتیبانی نمی‌کنند. این بدان معناست که این شارژرها واجد شرایط قراردادهای دولتی آینده نیستند.

۱۳.۲ مرحله ۲: ارتقاء CSMS

مگاچارج به جای ساخت یک CSMS جدید، یک «لایه ترجمه OCPP» پیاده‌سازی کرد. این لایه اتصالات ۱.۶J را برای سخت‌افزار قدیمی و ۲.۰.۱ را برای سخت‌افزار جدید مدیریت می‌کرد، اما یک API یکپارچه را در اختیار برنامه موبایل و موتور صدور صورتحساب آنها قرار می‌داد.

۱۳.۳ مرحله ۳: تعویض سخت‌افزار

برای سایت‌های پرترافیک، مگاشارژ شارژرهای ۱.۶J را با شارژرهای سریع DC سازگار با ۲.۰.۱ جایگزین کرد. نتیجه، کاهش ۱۵ درصدی در جلسات «عدم موفقیت در شروع» بود، که عمدتاً به دلیل قوی‌تر بودن [سیستم] بود.رویداد تراکنشمدیریت در نسخه ۲.۰.۱.

۱۳.۴ تحلیل بازگشت سرمایه

سرمایه‌گذاری اولیه ۲ میلیون دلار بود. با این حال، کاهش تماس‌های تعمیر و نگهداری (به لطف تشخیص مدل دستگاه) سالانه ۴۰۰ هزار دلار صرفه‌جویی ایجاد کرد. علاوه بر این، امکان شرکت در بازارهای پاسخ فرکانسی V2G، سالانه ۲۰۰ هزار دلار درآمد اضافی ایجاد کرد. دوره بازگشت سرمایه تقریباً ۳.۳ سال بود.

فصل 14: چک لیست نهایی خریدار برای تدارکات OCPP 2.0.1

هنگام ارزیابی سخت‌افزار یا نرم‌افزار جدید، از این چک‌لیست برای اطمینان از انطباق کامل با الزامات استفاده کنید:

۱۴.۱ الزامات سخت‌افزاری (EVSE)

• [ ]پشتیبانی از پروفایل امنیتی ۳آیا از مدیریت گواهی سمت کلاینت پشتیبانی می‌کند؟
• [ ]پردازنده دو هسته‌ایآیا فضای کافی برای رمزگذاری TLS و تجزیه JSON وجود دارد؟
• [ ]عنصر امن (SE)آیا برد دارای ریشه سخت‌افزاری قابل اعتماد برای ذخیره کلیدها است؟
• [ ]آماده برای ISO 15118-2/20آیا کنترلر می‌تواند ارتباطات سطح بالای مورد نیاز برای PnC را مدیریت کند؟
• [ ]قابلیت نمایشآیا سخت‌افزار از نمایش اطلاعات قیمت/وضعیت از طریق OCPP پشتیبانی می‌کند؟انتقال دادهیا پیام‌های بومی؟

۱۴.۲ الزامات نرم‌افزار (CSMS)

• [ ]تجسم مدل دستگاهآیا داشبورد می‌تواند نمای سلسله مراتبی شارژر را نشان دهد؟
• [ ]ادغام مرجع صدور گواهی (CA)آیا CSMS می‌تواند به طور خودکار گواهی‌ها را صادر و تغییر دهد؟
• [ ]تطبیق تراکنشسیستم چگونه تراکنش‌های «معلق» از شارژرهای قدیمی ۱.۶J را مدیریت می‌کند؟
• [ ]موتور شارژ هوشمندآیا از منطق پیشرفته سطح پشته نسخه ۲.۰.۱ پشتیبانی می‌کند؟
• [ ]مقیاس‌پذیریآیا کنترل‌کننده‌ی WebSocket می‌تواند بیش از ۵۰،۰۰۰ اتصال TLS پایدار را به‌طور همزمان مدیریت کند؟

فصل 15: عیب‌یابی مشکلات رایج پیاده‌سازی OCPP

حتی با وجود یک استاندارد، پیاده‌سازی‌ها متفاوت هستند. در اینجا رایج‌ترین «اشتباهات» آورده شده است.

۱۵.۱ وقفه‌های وب‌ساکت

بسیاری از فایروال‌های شبکه، اتصالات TCP بیکار را می‌بندند. اگرفاصله ضربان قلباگر روی مقدار خیلی بالا تنظیم شده باشد، ممکن است شارژر قطع شود.

• راه حل: اطمینان حاصل کنیدفاصله ضربان قلبکمتر از زمان انقضای فایروال (معمولاً ۶۰ تا ۱۲۰ ثانیه) باشد.

۱۵.۲ مشکلات زنجیره گواهی

یکی از خطاهای رایج در نسخه ۲.۰.۱، خطای «گواهی غیرقابل اعتماد» است. این خطا معمولاً زمانی رخ می‌دهد که شارژر، گواهی ریشه CSMS را نصب نکرده باشد.

• راه حل: استفاده ازنصب گواهیپیام در حین راه‌اندازی برای اطمینان از تکمیل زنجیره اعتماد.

۱۵.۳ اندازه بار داده JSON

برخی از پیام‌های ۲.۰.۱ (مانندGetBaseReport) می‌تواند بسیار بزرگ باشد. اگر بافر شارژر خیلی کوچک باشد، پیام را رها می‌کند.

• راه حل: بررسی کنیدحداکثر اندازه پیاممتغیر را در مدل دستگاه تنظیم کنید و مطمئن شوید که CSMS این محدودیت را رعایت می‌کند.

فصل 16: چشم‌اندازهای نظارتی منطقه‌ای و الزامات پروتکل

حرکت به سمت OCPP 2.0.1 فقط ناشی از فناوری نیست؛ بلکه به طور فزاینده‌ای به یک موضوع قانونی تبدیل شده است.

۱۶.۱ اتحادیه اروپا (AFIR)

مقررات زیرساخت سوخت‌های جایگزین (AFIR) در اتحادیه اروپا، شفافیت قیمت و قابلیت همکاری را الزامی می‌کند. اگرچه این مقررات صراحتاً از OCPP 2.0.1 نام نمی‌برد، اما الزام «اشتراک‌گذاری داده‌ها در زمان واقعی» و «شارژ هوشمند» عملاً 2.0.1 را به تنها استاندارد قابل اجرا برای زیرساخت‌های عمومی جدید تبدیل می‌کند.

۱۶.۲ آمریکای شمالی (NEVI)

در ایالات متحده، برنامه فرمول ملی زیرساخت خودروهای الکتریکی (NEVI) الزام می‌کند که شارژرها «قابلیت تعامل» داشته باشند. ایالت‌هایی مانند کالیفرنیا پا را فراتر گذاشته‌اند و کمیسیون انرژی کالیفرنیا (CEC) برای پشتیبانی از ISO 15118 تلاش می‌کند، که همانطور که بحث کردیم، بهترین راه پیاده‌سازی آن از طریق OCPP 2.0.1 است.

۱۶.۳ چین و آسیا-اقیانوسیه

در حالی که چین استانداردهای خاص خود (GB/T) را دارد، تولیدکنندگان متمرکز بر صادرات، سرمایه‌گذاری‌های سنگینی روی OCPP 2.0.1 انجام می‌دهند. در بازارهایی مانند استرالیا و سنگاپور، مناقصه‌های دولتی برای شبکه‌های شارژ عمومی اکنون تقریباً منحصراً OCPP 2.0.1 را با مشخصات امنیتی 3 مشخص می‌کنند.

فصل 17: قطعه کدهای پیاده‌سازی: جزئیات دقیق

برای کمک به توسعه‌دهندگان، ما نمایش‌های مفهومی JSON را برای وظایف پیچیده نسخه ۲.۰.۱ ارائه می‌دهیم.

۱۷.۱ جریان چرخش گواهینامه

وقتی یک گواهی نزدیک به انقضا است، CSMS باید چرخش را آغاز کند.

۱. CSMS ارسال می‌کندگواهی امضا شده:«json [2, "CERT-01", "CertificateSigned", { "certificateChain": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----", "certificateType": "V2G" }]«

۲. ایستگاه پاسخ می‌دهدپذیرفته شده:«json [3, "CERT-01", { "status": "پذیرفته شده" }]«

۳. ایستگاه ارسال می‌کنداعلان رویداد امنیتی:«json [2, "EVT-99", "SecurityEventNotification", { "type": "CertificateRotated", "timestamp": "2026-08-09T10:00:00Z" }]«

۱۷.۲ تنظیم یک پروفایل شارژ پاسخگو به شبکه

تصور کنید که اپراتور شبکه برق نیاز به کاهش مصرف برق در سراسر شبکه دارد.

CSMS ارسال می‌کندتنظیمشارژپروفایل:«json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "ChargingStationMaxProfile", "chargingProfileKind": "Absolute", "chargingSchedule": { "id": 1, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 11000 }, { "startPeriod": 3600, "limit": 22000 } ] } } }]«

فصل 18: واژه‌نامه جامع اصطلاحات OCPP 2.0.1

برای اطمینان از وضوح برای همه ذینفعان، ما یک واژه‌نامه جامع ارائه می‌دهیم.

• سیستم مدیریت ایستگاه شارژ (CSMS): پلتفرم ابری بک‌اند که شارژرها را کنترل می‌کند.
• تجهیزات تامین خودروهای برقی (EVSE): ایستگاه شارژ فیزیکی.
• OCPP (پروتکل نقطه شارژ باز): زبانی که آنها صحبت می کنند.
• OCA (اتحاد شارژ باز): سازمانی که زبان را می‌نویسد.
• ایزو ۱۵۱۱۸: پروتکل بین ماشین و شارژر.
• PnC (اتصال و شارژ)تجربه کاربری که توسط ISO 15118 و OCPP 2.0.1 فراهم شده است.
• V2G (خودرو به شبکه): ارسال برق از ماشین به شبکه.
• V2X (ارتباط خودرو با همه چیز)اصطلاح جامع برای V2G، V2H و V2B.
• TLS (امنیت لایه انتقال): رمزگذاری که داده‌ها را ایمن نگه می‌دارد.
• زیرساخت کلید عمومی (PKI): سیستم گواهی‌های دیجیتال مورد استفاده برای امنیت.
• JSON (نمادگذاری شیء جاوا اسکریپت): قالب پیام‌ها.
• وب‌سوکتاتصال پایدار، پیام‌ها را از طریق «لوله» عبور می‌دهد.
• مدل دستگاهروش سلسله مراتبی ۲.۰.۱ برای توصیف سخت‌افزار.
• کامپوننت: یک قطعه سخت‌افزاری (مثلاً کانکتور).
• متغیر: ویژگی یک کامپوننت (مثلاً وضعیت).
• ویژگی: فراداده درباره یک متغیر (مثلاً مقدار، تغییرپذیری).
• رویداد تراکنش: پیام یکپارچه برای تمام داده‌های جلسه در نسخه ۲.۰.۱.
• ضربان قلب: سیگنال تناوبی «من زنده‌ام».
• بوت نوتیفیکیشنسیگنال «سلام، من اینجام» هنگام روشن شدن شارژر.
• انتقال داده: یک پیام «کلیدی» برای افزونه‌های مخصوص فروشنده (با احتیاط استفاده شود!).

سخن پایانی: پیمایش در عصر چند پروتکلی

به عنوان یک خریدار یا اپراتور، مهمترین نکته این است که ما وارد یک ... می‌شویم.دوران چند پروتکلی... برای ۳ تا ۵ سال آینده، ۱.۶J و ۲.۰.۱ در کنار هم وجود خواهند داشت. با این حال، این تعادل به سرعت در حال تغییر است.

با انتخاب OCPP 2.0.1 امروز، شما فقط یک پروتکل نمی‌خرید؛ شما در حال خرید بیمه هستید. شما تضمین می‌کنید که شبکه شما می‌تواند با خودروهای جدید، قوانین جدید و جریان‌های درآمدی جدید سازگار شود. پیچیدگی 2.0.1 بهای پیشرفت است - بهایی که از طریق بهبود زمان آماده به کار، کاهش ریسک و تجربه برتر مشتری، هزینه خود را می‌پردازد.

شارژ تجاری دیگر یک صنعت خاص نیست؛ بلکه ستون فقرات سیستم حمل و نقل آینده است. این ستون فقرات را بر قوی‌ترین پایه ممکن بنا کنید: OCPP 2.0.1.

فصل 19: توسعه برای OCPP 2.0.1: بهترین شیوه‌ها برای مهندسان نرم‌افزار

انتقال از کدبیس ۱.۶J به ۲.۰.۱ یک بازسازی نیست؛ بلکه یک بازنویسی است. توسعه‌دهندگان باید مدل ذهنی متفاوتی را اتخاذ کنند.

۱۹.۱ پذیرش ناهمزمانی

در حالی که WebSockets ذاتاً ناهمزمان است، پیچیدگی نسخه ۲.۰.۱ به این معنی است که یک درخواست واحد (مانندGetBaseReport) ممکن است پردازش آن در یک EVSE با محدودیت منابع چند ثانیه طول بکشد. توسعه‌دهندگان CSMS باید منطق زمان‌بندی و تلاش مجدد قوی را پیاده‌سازی کنند که سرعت پردازش متفاوت فروشندگان سخت‌افزارهای مختلف را در نظر بگیرد.

۱۹.۲ تجزیه کارآمد JSON

تجزیه JSON می‌تواند به شدت از CPU استفاده کند. برای سیستم عامل EVSE، توسعه‌دهندگان باید به جای بارگذاری کل بار داده در RAM، از تجزیه‌کننده‌های مبتنی بر جریان استفاده کنند. این امر به ویژه برای ... مهم است.رویداد اطلاع‌رسانیپیام‌هایی که می‌توانند شامل صدها به‌روزرسانی متغیر در یک فریم واحد باشند.

۱۹.۳ مدیریت ماشین وضعیت

ماشین وضعیت برای یک تراکنش در نسخه ۲.۰.۱ نسبت به نسخه ۱.۶J سخت‌گیرانه‌تر است. توسعه‌دهندگان باید به شدت از قوانین انتقال پیروی کنند.رویداد تراکنشبرای مثال، شما نمی‌توانید یکپایان یافترویداد بدون اینکه ابتدا ارسال شده باشدشروع شدهرویدادی برای آن مورد خاصشناسه تراکنش.

فصل 20: تست، اعتبارسنجی و ابزار تست انطباق OCPP (OCTT)

قابلیت همکاری، وعده OCPP است، اما این امر تنها از طریق آزمایش دقیق محقق می‌شود.

۲۰.۱ نقش گواهینامه OCA

اتحادیه Open Charge یک برنامه صدور گواهینامه ارائه می‌دهد. خریداران باید به دنبال برچسب «OCPP 2.0.1 Certified» باشند. این گواهینامه تضمین می‌کند که پیاده‌سازی، مجموعه‌ای از آزمایش‌های خودکار را که شامل تمام پروفایل‌های اجباری است، با موفقیت پشت سر گذاشته است.

۲۰.۲ استفاده از OCTT

ابزار تست انطباق OCPP (OCTT) استاندارد طلایی برای تست است. این ابزار هم CSMS و هم EVSE را شبیه‌سازی می‌کند.

• برای تولیدکنندگان خودروهای برقی: از OCTT برای تأیید اینکه ایستگاه شما سناریوهای «مسیر شاد» و موارد خاص (مانند قطعی شبکه در حین به‌روزرسانی میان‌افزار) را مدیریت می‌کند، استفاده کنید.
• برای ارائه دهندگان CSMSاز OCTT استفاده کنید تا مطمئن شوید که backend شما می‌تواند طیف گسترده‌ای از پیام‌ها و الزامات امنیتی سختگیرانه‌ی نسخه ۲.۰.۱ را مدیریت کند.

۲۰.۳ آزمایش میدانی و جشنواره‌های تعامل

فراتر از تست خودکار، OCA «جشنواره‌های افزونه» را سازماندهی می‌کند که در آن فروشندگان، سخت‌افزار و نرم‌افزار خود را برای آزمایش در سناریوهای دنیای واقعی در مقابل یکدیگر می‌آورند. اینجاست که ظریف‌ترین اشکالات - مانند ناسازگاری گواهی یا تفاوت‌های جزئی در قالب‌بندی JSON - شناسایی و برطرف می‌شوند.

فصل 21: جدول مقایسه‌ای عمیق: بیش از 60 اقدام OCPP 2.0.1

برای ارائه یک مرجع کامل، پیام‌های اصلی نسخه ۲.۰.۱ را دسته‌بندی کرده و آنها را با همتایانشان در نسخه ۱.۶J مقایسه می‌کنیم.

۲۱.۱ تأمین و پیکربندی

۲۱.۲ مدیریت تراکنش‌ها

۲۱.۳ مدیریت امنیت و میان‌افزار

۲۱.۴ اهمیت جدول برای شبکه شما

جدول یک نکته را غیرقابل انکار می‌کند: OCPP 2.0.1 یک تغییر نام ظاهری برای 1.6J نیست. خانواده‌های پیام جدید - متغیرهای تایپ‌شده، تراکنش‌های رویدادمحور و مدیریت گواهی - لوله‌کشی مورد نیاز برای Plug & Charge، شارژ هوشمند و گزارش‌دهی نظارتی هستند. شارژری که فقط با 1.6J کار می‌کند را می‌توان با یک دروازه (gateway) ارتقا داد، اما CSMS که فقط با 1.6J کار می‌کند، نمی‌تواند مدل امنیتی مورد نیاز تنظیم‌کنندگان و خودروسازان را ارائه دهد. هنگام ارزیابی سخت‌افزار، «آماده برای 2.0.1» باید به این معنی باشد که سیستم عامل امروز عرضه می‌شود، نه برای سال آینده. و از آنجا که OCPP 2.0.1 به جای انتقال SOAP 1.6J، بر روی JSON-over-WebSocket اجرا می‌شود، جریان‌های پیام سبک‌تر و اشکال‌زدایی آن بسیار آسان‌تر است - یک مزیت عملی که تیم فناوری اطلاعات شما از روز اول احساس خواهد کرد.

فصل ۲۲: نتیجه‌گیری: تصمیم‌گیری در مورد ارتقا

برای یک اپراتور تجاری، راهنمایی عملی واضح است:

• استقرارهای جدید باید به طور پیش‌فرض روی OCPP 2.0.1 باشند.مدل امنیتی، مدیریت گواهینامه‌ها و ادغام ISO 15118 پیش‌نیازهای محیط نظارتی ۲۰۲۶ هستند.
• ناوگان‌های موجود ۱.۶J بلااستفاده نیستند.در حالی که شما در حال استفاده از سخت‌افزار بومی ۲.۰.۱ هستید، دروازه‌های مدیریت‌شده و پلتفرم‌های CSMS دو پروتکله، این شکاف را پر می‌کنند.
• قبل از اعتماد کردن، آزمایش کنید.از OCTT، plugfests و عرضه‌های مرحله‌ای استفاده کنید - قابلیت همکاری در عمل اثبات شده است، نه اینکه از روی برگه اطلاعات فرض شود.
• درخواست کتبی برای مسیر مهاجرت.فروشنده شارژر شما باید یک نقشه راه برای فریمور از نسخه ۱.۶J به ۲.۰.۱ به همراه تاریخ انتشار منتشر کند، نه وعده‌های مبهم.

فراخوان اقدام: با MIDA Power در مورد استراتژی پروتکل خود صحبت کنید

MIDA Power ships OCPP 1.6J and 2.0.1 on every charger, with field-upgradeable firmware and a cloud platform that manages mixed-protocol fleets in a single dashboard. Contact sales@midapower.com for our protocol migration guide, OCTT test reports, and a free compatibility review of your existing network.