השוואה אסטרטגית של OCPP 1.6J לעומת 2.0.1 עבור מפעילי טעינה מסחריים

ההשוואה האסטרטגית הסופית של OCPP 1.6J לעומת 2.0.1 עבור מפעילי טעינה מסחריים גלובליים: שליטה במדרגיות הרשת, אבטחת סייבר מתקדמת, שילוב ISO 15118 והבטחת עתיד תשתית לצמיחה בת קיימא של רכבים חשמליים

סיכום מנהלים

נוף טעינת הרכבים החשמליים (EV) עובר שינוי סייסמי. ככל שהאימוץ העולמי מואץ, פרוטוקולי התקשורת הבסיסיים השולטים באינטראקציה בין ציוד אספקה ​​לרכבים חשמליים (EVSE) ומערכות ניהול תחנות טעינה (CSMS) הפכו למוקד האסטרטגיה הטכנית עבור מפעילי טעינה מסחריים (CPOs). פרוטוקול נקודת הטעינה הפתוחה (OCPP), המתוחזק על ידי ברית הטעינה הפתוחה (OCA), התפתח ממסגרת העברת הודעות פשוטה לתקן מתוחכם, מאובטח וניתן להרחבה.

מדריך זה מספק ניתוח טכני מקיף של המעבר מ-OCPP 1.6J ל-OCPP 2.0.1. אנו בוחנים את ההבדלים הארכיטקטוניים, שיפורי האבטחה, פרדיגמות ניהול התקנים והתפקיד הקריטי של שילוב ISO 15118. עבור קונים ומפעילים, מאמר זה משמש כמקור עזר סופי לקבלת החלטות רכש והעברה מושכלות בשוק המתבגר במהירות.

פרק 1: התפתחות תקני טעינה של רכבים חשמליים: הקשר היסטורי

פרוטוקול נקודת הטעינה הפתוחה (OCPP) נולד מתוך צורך בתפעול הדדי. בימים הראשונים של טעינת רכבים חשמליים, יצרני חומרה וספקי תוכנה השתמשו בפרוטוקולים קנייניים, ויצרו "גנים סגורים" שחנקו תחרות וחדשנות. הצגת OCPP 1.2 ו-1.5 הניחה את היסודות, אך דווקא OCPP 1.6 הוא שאיחד באמת את התעשייה.

1.1 הדומיננטיות של OCPP 1.6J

OCPP 1.6, שיצאה בשנת 2015, הציגה את יישום JSON over WebSockets (1.6J). מעבר זה מהעברת הודעות מבוססת SOAP הפחית משמעותית את התקורה ופישטה את היישום עבור מפתחים. היא הציגה תכונות כמו טעינה חכמה והודעות סטטוס נוספות, מה שהפך אותה לסטנדרט בתעשייה במשך כמעט עשור.

1.2 ראשית OCPP 2.0.1

למרות הצלחתו של 1.6J, צמיחת התעשייה חשפה את מגבלותיה. בעיות אבטחה, מורכבות ניהול מכשירים וחוסר תמיכה מובנית באינטגרציה מתקדמת של רשת החשמל (V2G) הובילו לפיתוח OCPP 2.0, ובהמשך, ל-OCPP 2.0.1 המשופר (שיצא בשנת 2020). OCPP 2.0.1 אינו רק עדכון; זהו עיצוב מחדש מוחלט שמטרתו לתמוך בדור הבא של רשתות טעינה חכמות, עתירות הספק ומאובטחות.

פרק 2: פרדיגמות תקשורת בסיסיות: JSON, WebSockets ומבני Frame

כדי להבין את ההבדל בין פרוטוקולים אלה, יש לבחון את התקשורת ברמה נמוכה. שני הפרוטוקולים משתמשים ב-JSON על פני WebSockets, אך המבנה והטיפול בהודעות אלה שונים באופן משמעותי.

2.1 שכבת WebSocket

שתי הגרסאות משתמשות בחיבורי WebSocket קבועים, המאפשרים תקשורת דו-צדדית מלאה. זה קריטי לפעולות בזמן אמת, כגון עצירת טעינה מאפליקציה סלולרית או קבלת התראות תקלה מיידיות.

2.2 פירוט מסגרות ההודעה

הודעת OCPP טיפוסית מורכבת ממזהה סוג הודעה, מזהה הודעה ייחודי, שם הפעולה ומטען.

דוגמה למסגרת 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" } }]`שימו לב לרמת הפירוט המוגברת ב-2.0.1.השדה `reason` מאפשר ל-CSMS להבין אם האתחול נבע מאתחול מחדש, הפעלה או טריגר של watchdog, מה שמאפשר לוגיקת אבחון טובה יותר.

פרק 3: שינוי פרדיגמה אדריכלי: מודל המכשיר

השינוי הטכני המשמעותי ביותר ב-OCPP 2.0.1 הוא הצגת ה-דגם המכשיר.

3.1 המגבלות של מקשי תצורה 1.6J

ב-OCPP 1.6J, תצורת החומרה נוהלה באמצעות רשימה שטוחה של "מפתחות תצורה" (למשל,מרווח פעימות לב, פסק זמן לחיבורככל שמטענים הפכו מורכבים יותר (רב-מחברים, מודולי כוח משולבים, מערכות קירור מורכבות), רשימה שטוחה זו הפכה לבלתי ניתנת לניהול. לא הייתה דרך סטנדרטית לתאר את ההיררכיה הפיזית של תחנה.

3.2 גישת מודל המכשיר 2.0.1

OCPP 2.0.1 מציג מודל היררכי המורכב מרכיביםומשתניםרכיב יכול להיות "Controller", "Connector" או "PowerModule". לכל רכיב יש משתנים המייצגים את המצב או התצורה שלו (למשל,טֶמפֶּרָטוּרָה, מֶתַח, זרם מקסימלי).

• רְכִיבחלק פיזי או הגיוני של תחנת הטעינה.
• מִשְׁתַנֶה: תכונה ספציפית של אותו רכיב.
• מאפייניםמטא-נתונים המתארים את המשתנה (יחידה, טווח, סוג גישה).

זה מאפשר ניטור סטנדרטי. כעת מפעיל יכול לבצע שאילתה לגבי הטמפרטורה של מודול כוח ספציפי באמצעות נתיב סטנדרטי, במקום להסתמך על מפתחות קנייניים ספציפיים לספק.

פרק 4: אבטחת סייבר: מ"המאמץ הטוב ביותר" ל-TLS חובה

בימים הראשונים של טעינת רכבים חשמליים, אבטחה הייתה לעתים קרובות מחשבה שלאחר מעשה. OCPP 1.6J הציע פרופילי אבטחה, אך היישום היה לא עקבי בין הספקים.

4.1 פרופילי אבטחה ב-1.6J

OCPP 1.6J הגדיר שלושה פרופילי אבטחה:

1. לא מאובטחHTTP/WebSockets בטקסט רגיל.
2. אימות בסיסיTLS עם שם משתמש/סיסמה.
3. מבוסס תעודהTLS עם אישורי צד הלקוח.

הבעיה הייתה שמטענים רבים נותרו בפרופיל 1, מה שהותיר אותם פגיעים להתקפות MITM (אדם באמצע) ולשליטה לא מורשית.

4.2 העמדה המוקשחת של 2.0.1

OCPP 2.0.1 מחייב תקשורת מאובטחת. הוא משלב תכונות אבטחה מתקדמות באופן טבעי:

• עדכוני קושחה מאובטחיםחתימה ואימות חובה של תמונות קושחה.
• רישום אבטחהיומני רישום מפורטים של אירועים רלוונטיים לאבטחה (למשל, ניסיונות התחברות כושלים, פקיעת תוקף של אישור).
• ניהול תעודותהודעות סטנדרטיות עבור אישורים שמסתובבים ומעודכנים (בהובלת CSMS או בהובלת תחנה).
• TLS 1.2/1.3תמיכה בתקני ההצפנה העדכניים ביותר.

עבור מפעילים מסחריים, זה מפחית את הסיכון לפגיעות רשת מסיביות ומבטיח עמידה בתקנות אבטחת סייבר מתפתחות עבור מכשירי IoT.

פרק 5: שילוב ISO 15118: חיבור וטעינה ו-V2G

עתיד טעינת הרכבים החשמליים אינו עוסק רק בהעברת אלקטרונים; מדובר בחילופי נתונים ואנרגיה בצורה חכמה. ISO 15118 הוא התקן הבינלאומי לתקשורת בין רכב לרשת החשמל (V2G), והשילוב שלו עם OCPP הוא המאפיין המגדיר את גרסה 2.0.1.

5.1 מורכבות הטעינה

טעינת רכב (PnC) מאפשרת לנהג פשוט לחבר את הרכב ולהתחיל לטעון מבלי להשתמש באפליקציה או בכרטיס RFID. זה דורש תשתית מפתח ציבורי (PKI) מורכבת הכוללת את הרכב, המטען, המפעיל ומרכז הטעינה.

ב-OCPP 1.6J, תמיכה ב-PnC לא הייתה קיימת בפרוטוקול הבסיסי. ספקים נאלצו ליישם הרחבות מותאמות אישית, מה שהוביל לפיצול. OCPP 2.0.1 מספק את ה"אינסטלציה" עבור PnC על ידי תמיכה ב:

• התקנת תעודההעברת אישורי חוזה ממערכת ה-CSMS לרכב החשמלי דרך מערכת ה-EVSE.
• הַרשָׁאָהשימוש במזהה הניידות האלקטרונית (eMAID) הנגזר מתעודת הרכב.
• תקשורת מוצפנתהבטחת הגנה על נתוני החיוב הרגישים המועברים בין המכונית לרשת החשמל.

5.2 טעינה חכמה ואיזון עומסים

בעוד ש-1.6J תמך בטעינה חכמה בסיסית (שליחתהגדר פרופיל טעינה), 2.0.1 משפרת את הפוטנציאל הזה. זה מאפשר:

• שילוב אותות חיצונייםתגובה בזמן אמת לאותות תדר רשת או מחיר סיטונאי.
• ניהול עומס דינמישליטה מפורטת יותר על חלוקת החשמל באתר עם מאות מחברים.
• רכב לרשת (V2G)גרסה 2.0.1 כוללת את שדות הנתונים הדרושים לתמיכה בזרימת אנרגיה דו-כיוונית, המאפשרת לרכבים חשמליים לשמש כמשאבי אנרגיה מבוזרים (DER) עבור הרשת.

5.3 שיפורי ממשק משתמש/UX

OCPP 2.0.1 תומך בהצגת מידע ישירות על מסך המטען או על לוח המחוונים של הרכב, כגון:

• תמחור בזמן אמת במטבע המקומי.
• זמן משוער להגעה למצב טעינה (SoC) של 80%.
• מידע מפורט על הקבלה לאחר השלמת ההזמנה.

פרק 6: ניהול וניטור מתקדמים של מכשירים

עבור ספק שירותי הבעלות (CPO), עלות המטען אינה רק מחיר הרכישה; זוהי עלות הבעלות הכוללת (TCO). תחזוקה וזמן השבתה הם הגורמים המשפיעים ביותר על הרווח. OCPP 2.0.1 מטפלת בכך באמצעות יכולות ניטור מעולות.

6.1 דיווח מונחה אירועים

ב-1.6J, בדרך כלל ה-CSMS היה צריך לבקש מהמטען לקבלת סטטוס או להמתין להודעה.הודעת סטטוסבגרסה 2.0.1, ה-ניטור אירועיםהמערכת מאפשרת ל-CSMS לקבוע ספים. לדוגמה: "הודע לי רק אם הטמפרטורה הפנימית עולה על 70 מעלות צלזיוס" או "דווח אם מתח הקלט יורד מתחת ל-200 וולט". זה מפחית את תעבורת הרשת ומאפשר תחזוקה יזומה.

6.2 טיפול בעסקאות: אירוע העסקה

אחד ההיבטים שספגו את הביקורת הרבה ביותר ב-OCPP 1.6J היה הטיפול שלו בעסקאות. מושב שכלל...התחל עסקהועצירת עסקההודעות, אך אם התרחשה הפרעה ברשת, מערכת ה-CSMS התקשתה לעתים קרובות ליישב את נתוני החיוב.

OCPP 2.0.1 מחליף את אלה במערכת אחת וחזקהאירוע עסקההודעה. הודעה זו משמשת לדיווח על כל שלבי מחזור החיים של עסקה (התחיל, עודכן, הסתיים). היא כוללת קוד ייחודימזהה עסקהשנמשכת גם אם המטען מופעל מחדש, מה שמבטיח שלא יאבדו נתוני טעינה - ולכן לא יאבדו הכנסות.

6.3 אבחון ופתרון בעיות משופרים

הקבל יומןוהודעת סטטוס אבחוןההודעות בגרסה 2.0.1 הן מובנות יותר. מנהלי תמיכה (CPO) יכולים לבקש סוגי יומני רישום ספציפיים (אבטחה, אבחון, משתמש) ולציין את טווח הזמן. זה מאפשר לצוותי תמיכה מרחוק לפתור בעיות מבלי לשלוח טכנאי לאתר, מה שמפחית משמעותית את עלויות התפעול.

פרק 7: מנגנוני עדכון קושחה: אמינות והחזרות למצב אחר

עדכוני קושחה הם עורק החיים של חומרה מתפתחת, אך עדכון כושל יכול לשבש את המטען.

7.1 תהליך עדכון 1.6J

ב-1.6J, ה-עדכון קושחההפקודה הייתה פשוטה יחסית. המטען היה מוריד את התמונה ומנסה להתקין אותה. לא היה מנגנון סטנדרטי לעדכונים רב-שלביים או החזרות לאחור מאומתות.

7.2 עדכון רב-שלבי 2.0.1

OCPP 2.0.1 מציג מחזור חיים מתוחכם יותר לעדכוני קושחה:

1. הורדההמטען מאחזר את התמונה ומאמת את סכום הבדיקה/חתימה שלה.
2. הַתקָנָההעדכון מוחל על מחיצה משנית.
3. אימותהמערכת בודקת אם הקושחה החדשה מאותחלת כראוי.
4. הַפעָלָההמחיצה הראשית מוחלפת.

אם שלב כלשהו נכשל, הפרוטוקול מגדיר כיצד המטען צריך לחזור לגרסה היציבה הקודמת ולדווח על קוד התקלה הספציפי ל-CSMS. רמת אמינות זו אינה ניתנת למשא ומתן עבור פריסות מסחריות בקנה מידה גדול.

7.3 אימות חתימה

כדי למנוע מגורמים זדוניים להעלות קושחה שנפגעה, גרסה 2.0.1 מחייבת שימוש בחתימות דיגיטליות. המטען יסרב לבצע כל קוד שאינו חתום על ידי המפתח הפרטי של היצרן, ובכך מוסיף שכבת הגנה קריטית מפני פריצות ברמת החומרה.

פרק 8: פרטיות נתונים, תאימות רגולטורית ו-GDPR

ככל שטעינת רכב חשמלי הופכת לשימוש יומיומי, כמות הנתונים האישיים שנוצרת היא מדהימה. טעינה אחת יכולה לקשר בין זהות המשתמש, מיקום הרכב שלו, דפוסי הנסיעה שלו והמידע הפיננסי שלו.

8.1 מידע המאפשר זיהוי אישי (PII) ב-OCPP

בהקשר של תקנת הגנת המידע הכללית (GDPR) באירופה וחוקים דומים כמו CCPA בקליפורניה, נקודות נתונים כגוןתגית מזהה(RFID) או ה-מזהה EVCC(מזהה רכב) נחשבים כמידע אישי מזהה.

OCPP 2.0.1 מספק בקרות טובות יותר לאנונימיזציה של נתונים. לדוגמה, ה-נתונים מותאמים אישיתשדות מאפשרים למפעילים לאחסן מטא-נתונים מבלי לחשוף פרטים אישיים מזהים ליומני הפרוטוקול המרכזיים. יתר על כן, פרופילי האבטחה המשופרים מבטיחים שנתונים אלה מוצפנים הן במעבר והן במנוחה.

8.2 הזכות להישכח וניידות נתונים

האופי המובנה של מודל המכשירים בגרסה 2.0.1 מקל על ספקי CSMS ליישם בקשות "מחיקת נתונים". במערכת 1.6J, מציאת כל המופעים של מזהה המשתמש על פני מפתחות תצורה ויומני רישום שונים הייתה סיוט ידני. בגרסה 2.0.1, ההפרדה הברורה בין נתוני מצב המכשיר לנתוני העסקה מאפשרת ארכיטקטורת מסד נתונים נקייה יותר.

8.3 עמידה בחוקי אבטחת האינטרנט של הדברים

אזורים רבים מחוקקים כעת חוקים המחייבים מכשירי IoT (אינטרנט של הדברים) לכלול סיסמאות ייחודיות ומנגנוני עדכון מאובטחים. ה-TLS המחייב והקושחה החתומה של OCPP 2.0.1 אינם רק תכונות "נחמדות" - הן דרישות חוקיות למכירת חומרה בשווקים כמו קליפורניה ובריטניה.

פרק 9: נקודת המבט של הקונה: עלות כוללת (TCO), החזר השקעה (ROI) והגירה אסטרטגית

עבור מפעיל טעינה מסחרי, ההחלטה להישאר עם 1.6 ג'אול או לעבור ל-2.0.1 היא החלטה כלכלית.

9.1 עלות היישום

• OCPP 1.6Jזול ליישום, נתמך באופן נרחב על ידי חומרה בעלות נמוכה, אך כרוך בעלויות נסתרות גבוהות בסיכוני תחזוקה ואבטחה.
• OCPP 2.0.1דורש מעבדים חזקים יותר ויותר זיכרון ב-EVSE. עלויות הפיתוח עבור CSMS גבוהות יותר עקב מורכבות הפרוטוקול. עם זאת, הוא מציע חיסכון משמעותי בעלויות התפעול באמצעות ניהול מרחוק ואמינות טובה יותר.

9.2 מיתוס "השדרוג החלק"

לעתים קרובות אומרים שניתן לשדרג מטעני 1.6J לגרסה 2.0.1 באמצעות תוכנה. במציאות, זה כמעט ולא נכון. דרישות הזיכרון והמעבד עבור גרסה 2.0.1 (במיוחד טיפול בתעודות TLS וניתוח JSON מורכב של דגם המכשיר) עולות לעתים קרובות על היכולות של בקרי 1.6J ישנים יותר.

9.3 נתיבי הגירה אסטרטגיים

על חברות ביטוח לאומי לשקול גישת "רשת היברידית":

1. אתרים מדור קודםהמשך להפעיל 1.6 ג'אול עבור מטעני AC קיימים בעלי צריכת חשמל נמוכה.
2. אתרי טעינה מהירה חדשים בוושינגטון די.סי.מנדט 2.0.1 עבור כל הפריסות החדשות בעלות הספק גבוה לתמיכה ב-PnC וב-V2G.
3. פתרונות פרוקסיהשתמש בשער פרוטוקול שיכול לתרגם הודעות 1.6J לפורמט תואם 2.0.1 עבור CSMS, מה שמאפשר לוח מחוונים ניהולי מאוחד יחיד.

פרק 10: הבטחת עתיד: OCPP 2.1 והדרך לטעינה אוטונומית

אפילו כאשר גרסה 2.0.1 צוברת תאוצה, ברית ה-Open Charge Alliance כבר עובדת על OCPP 2.1. גרסה עתידית זו תרחיב עוד יותר את טווח ההשפעה של הפרוטוקול.

טעינה דו-כיוונית 10.1 (V2X)

בעוד שגרסה 2.0.1 תומכת ב-V2G בסיסי, גרסה 2.1 תשפר את התקשורת עבור רכב-לבתים (V2H) ורכב-לבניין (V2B), מה שיאפשר לרכבים חשמליים להפעיל בתים במהלך הפסקות חשמל או להפחית את שיא הביקוש לבניינים מסחריים.

10.2 תמיכה בטעינה אלחוטית

עם צמיחתם של כלי רכב אוטונומיים (AV), חיבור ידני יהפוך למיושן. OCPP 2.1 יכלול הודעות סטנדרטיות לטעינה אינדוקטיבית (אלחוטית), ניהול יישור והעברת אנרגיה ללא התערבות אנושית.

10.3 אינטגרציה עם ערים חכמות

גרסאות עתידיות צפויות לכלול אינטגרציה עמוקה יותר עם מערכות ניהול תנועה ותחזיות אנרגיה מתחדשת. עמדות טעינה יוכלו "להגיש הצעות מחיר" על חשמל בשווקי אנרגיה בזמן אמת, ולהפוך רשתות טעינה לתחנות כוח וירטואליות ענקיות (VPP).

נספח טכני: התעמקות בהשוואות הודעות

כדי לספק את העומק הטכני האולטימטיבי, ננתח כעת רצפי הודעות ספציפיים והבדלי מסגרות בין שתי הגרסאות.

א.1 זרימת ההרשאה

בגרסה 1.6J, האישור היה תגובה בינארית "מתקבל" או "חסום".

תגובת אישור 1.6J:"json [3, "123456", { "idTagInfo": { "status": "התקבל", "expiryDate": "2026-12-31T23:59:59Z" } }]"

ב-2.0.1, התגובה כוללת הקשר נוסף, כגוןאסימון מזההסוג ומידע נוסף עבור ממשק המשתמש.

2.0.1 תגובת אישור:"json [3, "987654", { "idTokenInfo": { "status": "התקבל", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "ברוך הבא, ג'ון! היתרה שלך היא $45.00" } } }]"

א.2 ניהול פעימות לב וחיבורים

OCPP 2.0.1 ממטב את האופן שבו התחנה מוכיחה שהיא "חיה". ב-1.6J, אםדוֹפֶקאם נכשל, התחנה הייתה מנסה שוב ושוב. בגרסה 2.0.1, התחנה יכולה להשתמש ב-הודע לאירועמנגנון לדווח שהחיבור שלו לקצה אחורי משני אבד, תוך שמירה על דופק עם הראשי.

א.3 טבלת מטא-נתונים מפורטת

מַסְקָנָה

המעבר מ-OCPP 1.6J ל-2.0.1 אינו רק עדכון תוכנה; זוהי אבולוציה מהותית של המערכת האקולוגית של ניידות חשמלית. עבור מפעילים מסחריים, 1.6J מייצג את העבר האמין, בעוד ש-2.0.1 מייצג את העתיד הניתן להרחבה, מאובטח ואינטליגנטי.

בחירה ב-2.0.1 היום היא השקעה באורך חיים. היא מבטיחה שהחומרה שלכם תהיה תואמת לדור הבא של כלי רכב חשמליים, תואמת לתקנות אבטחת סייבר מחמירות, ומוכנה להזדמנויות הרווחיות של V2G ואינטגרציה של רשת חכמה. ככל שהשוק יתגבש, המפעילים עם ערימות הפרוטוקולים החזקות והגמישות ביותר יהיו אלה שיובילו את הקצב.

פרק 11: צלילה מעמיקה: ניתוח זרימת הודעות ודיאגרמות רצף

בפרק זה, ננתח את רצפי האינטראקציה בין ה-EVSE וה-CSMS כדי להדגים את ההבדלים התפעוליים בין 1.6J ל-2.0.1.

11.1 רצף האתחול והתצורה

כאשר מטען מתחבר לראשונה לרשת, עליו לזהות את עצמו ולסנכרן את התצורה שלו.

זרימה של OCPP 1.6J:

1. חיבור WebSocketהוקם מעל פורט 80 או 443.
2. הודעת אתחולתחנת שולחת ספק, דגם ומספר סידורי.
3. קבל תצורהCSMS מבקש את כל המפתחות כדי לבדוק את המצב הנוכחי.
4. שנהתצורהCSMS מעדכן מפתחות ספציפיים (למשל,מרווח פעימות לב).
5. הודעת סטטוסהתחנה מדווחת "זמין".

זרימה של OCPP 2.0.1:

1. לחיצת יד מאובטחת של TLSהחלפת תעודות חובה.
2. הודעת אתחולכולללְנַמֵק(לְמָשָׁל,פאוור-אפ).
3. GetBaseReportבמקום לבקש את כל המפתחות, ה-CSMS מבקש "דוח בסיס" המספק את ההיררכיה המלאה של מודל המכשיר.
4. הגדרת משתניםCSMS מעדכן משתנים. שימו לב שגרסה 2.0.1 מאפשרת עדכונים אטומיים - הגדרת משתנים מרובים בהודעה אחת והבטחה שכולם יצליחו או שאף אחד לא יצליח.
5. הודע לאירועתחנה מדווחת על מצבי רכיבים ראשוניים.

11.2 משא ומתן על טעינה חכמה

טעינה חכמה היא המקום שבו גרסה 2.0.1 באמת זורחת, במיוחד כאשר מטפלים בפרופילי טעינה מרובים.

ב-1.6J, ה-CSMS שולחהגדר פרופיל טעינהאשר מגדיר רמת מחסנית ולו"ז. אם לתחנה יש מספר מחברים, הטיפול בפרופיל לרוב אינו חד משמעי.

בגרסה 2.0.1, ה-הגדר פרופיל טעינהמקושר במפורש ל-פרופילטעינהמטרה.

• תחנת טעינה מקסימלית: מגביל את צריכת הזרימה של כל התחנה.
• פרופיל ברירת מחדל של TX: ברירת המחדל עבור כל עסקה חדשה.
• פרופיל TXספציפי לעסקה מתמשכת.

יתר על כן, 2.0.1 תומך ב-קבל רמת טעינההודעה, המאפשרת ל-CSMS לראות אילו פרופילים פעילים כעת וכיצד הם מקבלים עדיפות על ידי המתזמן הפנימי של ה-EVSE.

11.3 הפעלה ובקרה מרחוק

פקודות מרחוק כמועסקה התחלה מרחוק(1.6J) הוחלפו על ידיבקשתהתחלתעסקה(2.0.1). ההבדל העיקרי הוא במטען. ב-2.0.1, מערכת ה-CSMS יכולה לכלולפרופיל טעינהישירות בבקשת ההפעלה. משמעות הדבר היא שהמכונית יכולה להתחיל לטעון ברמת ההספק הנכונה באופן מיידי, מבלי להמתין להודעה שנייה, מה שמפחית את זמן ההשהיה ומשפר את יציבות הרשת.

פרק 12: השוואות סכמות ושדות JSON ברמה נמוכה

עבור מפתחים ומשלבי מערכות, שינויי הסכימה הם החלק הדורש הכי הרבה עבודה במעבר.

12.1 סוגים ממוספרים (Enums)

OCPP 2.0.1 מרחיב מאוד את מספר ה-Enums הסטנדרטיים, ומפחית את הצורך בקודי סטטוס "מותאמים אישית" שפקדו את יישומים של 1.6J.

• ספירת סיבות: כֶּלֶב שְׁמִירָה, איפוס מתוזמן, איפוס מרחוק, אובדן חשמל.
• ספירת סטטוס: כָּבוּשׁ, שָׁמוּר, לא זמין, פגום2.0.1 מוסיףזָמִין, כָּבוּשׁ, שָׁמוּר, לא זמין, פגוםאבל עם סטטוסים משניים לפרטים נוספים.

12.2 סוגי נתונים ויחידות

OCPP 2.0.1 מקדם את השימוש ביחידות סטנדרטיות (SI). בעוד ש-1.6J לפעמים הותיר את הדיוק העשרוני לא מוגדר, 2.0.1 משתמשתעֶשׂרוֹנִיסוגי ערכי הספק ואנרגיה, תוך הבטחת חיוב עקבי בין חומרת ספקים שונים.

פרק 13: מקרה בוחן: מעבר גלובלי של CPO מ-1.6J ל-2.0.1

בואו נסתכל על תרחיש היפותטי של "MegaCharge", תחנת כוח CPO עם 10,000 נקודות טעינה.

13.1 שלב 1: הביקורת

מגה-צ'ארג' גילתה ש-40% מצי ה-1.6J שלה לא תומך ב-TLS 1.2. משמעות הדבר היא שמטענים אלה לא היו זכאים לחוזים ממשלתיים עתידיים.

13.2 שלב 2: שדרוג CSMS

במקום לבנות CSMS חדש, MegaCharge יישמה "שכבת תרגום OCPP". שכבה זו טיפלה בחיבורים של 1.6J עבור חומרה ישנה וב-2.0.1 עבור חומרה חדשה, אך חשפה API מאוחד לאפליקציה המובייל ולמנוע החיוב שלהם.

13.3 שלב 3: החלפת חומרה

עבור אתרים בעלי תנועה גבוהה, MegaCharge החליפה מטעני 1.6J במטעני DC מהירים תואמי 2.0.1. התוצאה הייתה הפחתה של 15% בהפעלות "נכשל בהפעלה", בעיקר הודות לחזק יותר.אירוע עסקהטיפול ב-2.0.1.

13.4 ניתוח החזר השקעה

ההשקעה הראשונית הייתה 2 מיליון דולר. עם זאת, צמצום קריאות התחזוקה (הודות לאבחון של דגם המכשיר) חסך 400 אלף דולר בשנה. בנוסף, היכולת להשתתף בשווקי תגובת התדר V2G יצרה 200 אלף דולר נוספים בהכנסות שנתיות. תקופת ההחזר הייתה כ-3.3 שנים.

פרק 14: רשימת הבדיקה האולטימטיבית של הקונה עבור רכש OCPP 2.0.1

בעת הערכת חומרה או תוכנה חדשות, השתמשו בבדיקה זו כדי להבטיח תאימות אמיתית:

14.1 דרישות חומרה (EVSE)

• [ ]תמיכה בפרופיל אבטחה 3האם זה תומך בניהול אישורים בצד הלקוח?
• [ ]מעבד כפול ליבההאם יש מספיק מרווח הפעלה להצפנת TLS וניתוח JSON?
• [ ]אלמנט מאובטח (SE)האם ללוח יש שורש אמון בחומרה לאחסון מפתחות?
• [ ]מוכן לתקן ISO 15118-2/20האם הבקר יכול להתמודד עם התקשורת ברמה גבוהה הנדרשת עבור PnC?
• [ ]יכולת תצוגההאם החומרה תומכת בהצגת מידע על מחיר/סטטוס דרך OCPP?העברת נתוניםאו הודעות מקוריות?

14.2 דרישות תוכנה (CSMS)

• [ ]ויזואליזציה של מודל המכשירהאם לוח המחוונים יכול להציג את התצוגה ההיררכית של המטען?
• [ ]שילוב רשות אישורים (CA)האם מערכת CSMS יכולה להנפיק ולבצע סבב אוטומטי של אישורים?
• [ ]התאמת עסקאותכיצד המערכת מטפלת בעסקאות "תלויות" ממטענים מדור קודם של 1.6J?
• [ ]מנוע טעינה חכםהאם הוא תומך בלוגיקה המתקדמת ברמת הערימה של גרסה 2.0.1?
• [ ]מדרגיותהאם מטפל WebSocket יכול לנהל בו זמנית יותר מ-50,000 חיבורי TLS מתמשכים?

פרק 15: פתרון בעיות נפוצות ביישום OCPP

אפילו עם תקן, היישומים משתנים. הנה ה"תפיסות" הנפוצות ביותר.

15.1 פסקי זמן של WebSocket

חומות אש רבות ברשת סוגרות חיבורי TCP לא פעילים. אםמרווח פעימות לבמוגדר גבוה מדי, ייתכן שהמטען מנותק.

• פִּתָרוֹן: להבטיחמרווח פעימות לבנמוך מזמן הקצוב של חומת האש (בדרך כלל 60-120 שניות).

15.2 בעיות בשרשרת התעודות

תקלה נפוצה בגרסה 2.0.1 היא השגיאה "אישור לא מהימן". זה קורה בדרך כלל כאשר במטען לא מותקן רשות האישור הבסיסית של CSMS.

• פִּתָרוֹןהשתמש ב-התקנת תעודההודעה במהלך ההפעלה כדי להבטיח ששרשרת האמון שלמה.

גודל מטען JSON 15.3

כמה הודעות 2.0.1 (כמוGetBaseReport) יכול להיות גדול מאוד. אם זיכרון המאגר של המטען קטן מדי, ההודעה תבוטל.

• פִּתָרוֹןבדוק אתגודל הודעה מקסימלימשתנה במודל המכשיר ולוודא ש-CSMS מכבד מגבלה זו.

פרק 16: נופים רגולטוריים אזוריים ומנדטים לפרוטוקול

המעבר ל-OCPP 2.0.1 אינו מונע רק על ידי טכנולוגיה; זהו עניין הולך וגובר של חוק.

16.1 האיחוד האירופי (AFIR)

תקנת תשתית הדלקים החלופיים (AFIR) באיחוד האירופי מחייבת שקיפות מחירים ויכולת פעולה הדדית. למרות שהיא אינה מציינת במפורש את OCPP 2.0.1, הדרישה ל"שיתוף נתונים בזמן אמת" ו"טעינה חכמה" הופכת למעשה את 2.0.1 לתקן היחיד בר-קיימא לתשתיות ציבוריות חדשות.

16.2 צפון אמריקה (NEVI)

בארצות הברית, תוכנית התשתית הלאומית לרכב חשמלי (NEVI) דורשת שמטענים יהיו "ניתנים להפעלה הדדית". מדינות כמו קליפורניה הולכות רחוק יותר, כאשר ועדת האנרגיה של קליפורניה (CEC) דוחפת לתמיכה בתקן ISO 15118, אשר כפי שדנו, מיושמת בצורה הטובה ביותר באמצעות OCPP 2.0.1.

16.3 סין ואסיה-פסיפיק

בעוד שלסין יש סטנדרטים משלה (GB/T), היצרנים המתמקדים ביצוא משקיעים רבות ב-OCPP 2.0.1. בשווקים כמו אוסטרליה וסינגפור, מכרזים ממשלתיים לרשתות טעינה ציבוריות מציינים כעת כמעט אך ורק את OCPP 2.0.1 עם פרופיל אבטחה 3.

פרק 17: קטעי קוד של יישום: הפרטים הקטנים

כדי לסייע למפתחים, אנו מספקים ייצוגי JSON מושגיים עבור משימות מורכבות בפורמט 2.0.1.

17.1 תהליך סבב תעודות

כאשר תעודה מתקרבת לפוג, מערכת ה-CSMS חייבת להפעיל רוטציה.

1. CSMS שולחתעודה חתומה:"json [2, "CERT-01", "חתימה על תעודה", { "certificateChain": "-----התחלת תעודה-----\n...\n-----סוף תעודה-----", "סוג תעודה": "V2G" }]"

2. התחנה מגיבהמְקוּבָּל:"json [3, "CERT-01", { "status": "התקבל" }]"

3. שולחים תחנההודעת אירוע אבטחה:"json [2, "EVT-99", "הודעת אירוע אבטחה", { "type": "סיבוב תעודה", "timestamp": "2026-08-09T10:00:00Z" }]"

17.2 הגדרת פרופיל טעינה רספונסיבי לרשת החשמל

דמיינו שמפעיל הרשת צריך לצמצם את אספקת החשמל ברחבי הרשת.

CSMS שולחהגדר פרופיל טעינה:"json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "ChargingStationMaxProfile", "chargingProfileKind": "מוחלט", "chargingSchedule": { "id": 1, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 11000 }, { "startPeriod": 3600, "limit": 22000 } ] } } }]"

פרק 18: מילון מונחים מקיף של OCPP 2.0.1

כדי להבטיח בהירות לכל בעלי העניין, אנו מספקים מילון מונחים מורחב.

• CSMS (מערכת ניהול עמדות טעינה)פלטפורמת הענן האחורית ששולטת במטענים.
• EVSE (ציוד אספקה ​​לרכב חשמלי)עמדת הטעינה הפיזית.
• OCPP (פרוטוקול נקודת טעינה פתוחה): השפה שהם מדברים.
• OCA (ברית טעינה פתוחה): הארגון שכותב את השפה.
• תקן ISO 15118הפרוטוקול בין המכונית למטען.
• PnC (חבר וטען)חוויית המשתמש המופעלת על ידי ISO 15118 ו-OCPP 2.0.1.
• V2G (רכב לרשת): שליחת חשמל מהמכונית חזרה לרשת החשמל.
• V2X (רכב-להכל): המונח הכולל עבור V2G, V2H ו-V2B.
• TLS (אבטחת שכבת תעבורה): ההצפנה ששומרת על בטיחות הנתונים.
• PKI (תשתית מפתח ציבורית)מערכת התעודות הדיגיטליות המשמשת לאבטחה.
• JSON (סימון אובייקטים ב-JavaScript): הפורמט של ההודעות.
• שקע אינטרנט: החיבור המתמיד "צינור" דרכו זורמות ההודעות.
• דגם המכשירהדרך ההיררכית שבה 2.0.1 מתארת ​​חומרה.
• רְכִיב: חלק מהחומרה (למשל, מחבר).
• מִשְׁתַנֶה: מאפיין של רכיב (למשל, סטטוס).
• תְכוּנָהמטא-נתונים אודות משתנה (למשל, ערך, יכולת שינוי).
• אירוע עסקה: ההודעה המאוחדת עבור כל נתוני הסשן בגרסה 2.0.1.
• דוֹפֶק: האות המחזורי "אני חי".
• הודעת אתחול: האות "שלום, אני כאן" מופיע כאשר מטען מופעל.
• העברת נתוניםהודעה כוללת עבור הרחבות ספציפיות לספק (יש להשתמש בזהירות!).

מחשבות אחרונות: ניווט בעידן רב-פרוטוקולים

כקונה או כמפעיל, המסר החשוב ביותר הוא שאנחנו נכנסים לשלבעידן רב-פרוטוקוליםבמשך 3-5 השנים הבאות, 1.6J ו-2.0.1 יתקיימו יחד. עם זאת, האיזון משתנה במהירות.

על ידי בחירה ב-OCPP 2.0.1 היום, אתם לא רק קונים פרוטוקול; אתם קונים ביטוח. אתם מבטיחים שהרשת שלכם תוכל להסתגל למכוניות חדשות, חוקים חדשים וזרמי הכנסה חדשים. המורכבות של 2.0.1 היא מחיר ההתקדמות - מחיר שמשתלם באמצעות זמן פעולה משופר, סיכון מופחת וחוויית לקוח מעולה.

טעינה מסחרית כבר אינה תעשייה נישה; היא עמוד השדרה של מערכת התחבורה העתידית. בנו את עמוד השדרה הזה על הבסיס החזק ביותר האפשרי: OCPP 2.0.1.

פרק 19: פיתוח עבור OCPP 2.0.1: שיטות עבודה מומלצות עבור מהנדסי תוכנה

מעבר מבסיס קוד 1.6J ל-2.0.1 אינו רפקטורינג; זוהי כתיבה מחדש. מפתחים חייבים לאמץ מודל מנטלי שונה.

19.1 אימוץ אסינכרוניות

בעוד ש-WebSockets הם אסינכרוניים מטבעם, המורכבות של 2.0.1 פירושה שבקשה אחת (כגוןGetBaseReport) עשוי להימשך מספר שניות לעיבוד ב-EVSE מוגבל במשאבים. מפתחי CSMS חייבים ליישם לוגיקת פסק זמן וניסיון חוזר חזקה אשר מתחשבת במהירויות העיבוד המשתנות של ספקי חומרה שונים.

19.2 ניתוח יעיל של JSON

ניתוח JSON יכול להיות עתיר מעבד. עבור קושחת EVSE, מפתחים צריכים להשתמש בנתחים מבוססי זרם במקום לטעון את כל המטען ל-RAM. זה חשוב במיוחד עבורהודע לאירועהודעות, שיכולות להכיל מאות עדכונים משתנים במסגרת אחת.

19.3 טיפול במכונת המצבים

מכונת המצבים עבור עסקה בגרסה 2.0.1 נוקשה יותר מאשר בגרסה 1.6J. מפתחים חייבים להקפיד על כללי המעבר עבוראירוע עסקהלדוגמה, אינך יכול לשלוחהסתייםאירוע מבלי לשלוח תחילההתחילאירוע ספציפי זהמזהה עסקה.

פרק 20: בדיקות, אימות וכלי בדיקת תאימות OCPP (OCTT)

יכולת פעולה הדדית היא ההבטחה של OCPP, אך היא מתממשת רק באמצעות בדיקות קפדניות.

20.1 תפקידה של הסמכת OCA

ארגון Open Charge Alliance מציע תוכנית הסמכה. על הקונים לחפש את התווית "OCPP 2.0.1 Certified". הסמכה זו מבטיחה שהיישום עבר סדרה של בדיקות אוטומטיות המכסות את כל הפרופילים המחייבים.

20.2 שימוש ב-OCTT

כלי בדיקת התאימות של OCPP (OCTT) הוא תקן הזהב לבדיקות. הוא מדמה גם CSMS וגם EVSE.

• עבור יצרני EVSEהשתמשו ב-OCTT כדי לוודא שהתחנה שלכם מטפלת בתרחישי "נתיב שמח" ובמקרי קצה (כגון נפילות רשת במהלך עדכון קושחה).
• עבור ספקי CSMSהשתמשו ב-OCTT כדי להבטיח שהשרת האחורי שלכם יוכל להתמודד עם מגוון ההודעות העצום ועם דרישות האבטחה המחמירות של גרסה 2.0.1.

20.3 בדיקות שטח ופסטיבלים של אינטראופ

מעבר לבדיקות אוטומטיות, OCA מארגנת "Plugfests" שבהם ספקים מביאים את החומרה והתוכנה שלהם לבדיקה אחת מול השנייה בתרחישים אמיתיים. זה המקום שבו הבאגים העדינים ביותר - כמו אי תאימות של אישורים או הבדלים קלים בעיצוב JSON - נתפסים ונפתרים.

פרק 21: טבלת השוואה עמוקה: 60+ הפעולות של OCPP 2.0.1

כדי לספק תמונה מלאה, אנו מסווגים את המסרים העיקריים של גרסה 2.0.1 ומשווים אותם למקבילים שלהם בגרסה 1.6J.

21.1 הקצאה ותצורה

21.2 טיפול בעסקאות

21.3 ניהול אבטחה וקושחה

21.4 מה משמעות הטבלה עבור הרשת שלך

הטבלה מבהירה נקודה אחת חד משמעית: OCPP 2.0.1 אינו שינוי שם קוסמטי של 1.6J. משפחות ההודעות החדשות - משתנים מודפסים, עסקאות מונחות אירועים וניהול אישורים - הן הצנרת הנדרשת עבור Plug & Charge, טעינה חכמה ודיווח רגולטורי. מטען שמדבר רק 1.6J יכול להיות מצויד בשער, אך CSMS שמדבר רק 1.6J אינו יכול לספק את מודל האבטחה שרגולטורים ויצרני רכב דורשים יותר ויותר. בעת הערכת חומרה, "מוכן ל-2.0.1" אמור להעיד על כך שהקושחה נשלחת היום, ולא מתוכננת לשנה הבאה. ומכיוון ש-OCPP 2.0.1 פועל על JSON-over-WebSocket ולא על תעבורת SOAP של 1.6J, זרימת ההודעות קלה יותר וקלה בהרבה לאיתור באגים - יתרון מעשי שצוות ה-IT שלך ירגיש מהיום הראשון.

פרק 22: סיכום: קבלת החלטת השדרוג

עבור מפעיל מסחרי, ההנחיות המעשיות ברורות:

• פריסות חדשות צריכות להיות מוגדרות כברירת מחדל ל-OCPP 2.0.1.מודל האבטחה, טיפול באישורים ושילוב ISO 15118 הם תנאים מוקדמים לסביבה הרגולטורית של 2026.
• ציי 1.6J קיימים אינם תקועים.שערים מנוהלים ופלטפורמות CSMS בעלות פרוטוקול כפול מגשרות על הפער בזמן שאתם משלבים בהדרגה חומרה מקורית 2.0.1.
• תבדוק לפני שאתה מאמין.השתמש ב-OCTT, plugfests ופריסה בשלבים - יכולת פעולה הדדית מוכחת בשטח, לא נלקחת בחשבון בגיליון הנתונים.
• דרוש נתיב הגירה בכתב.ספק המטען שלך צריך לפרסם מפת דרכים של קושחה מ-1.6J ל-2.0.1 עם תאריכים, לא הבטחות מעורפלות.

קריאה לפעולה: דברו עם 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.