פרוטוקולי טעינה של EV: הבנת שכבות התקשורת בתוך פרויקט טעינה

דף הבית / תובנות / טעינת EV

תובנות לגבי טעינת רכב

מדריך תכנון ל-OCPP. הבנת שכבות התקשורת בתוך פרויקט טעינה

SINELINK| מדריך טכני

 

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

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

הבן את שכבות התקשורת

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

לְדוּגמָה,OCPIפועל בין פלטפורמות שירות טעינה. נוכחותו אינה קובעת כיצד מטען בודד מקבל מגבלת חשמל מקומית. תקשורת כלי רכב דורשת גם בדיקות תאימות משלה; התמיכה ב-OCPP אינה קובעת באילו כלי רכב או תכונות תקשורת רכב תומך המטען.

Ethernet, Wi-Fi, תקשורת סלולרית ו-RS485 מתארים קישוריות ולא את ממשק הבקרה המלא. שני מכשירים יכולים לשתף רשת ועדיין להשתמש בפקודות שונות, פורמטים נתונים והרשאות גישה שונות.

בחר OCPP לפי הפונקציות שהפרויקט צריך

פרוטוקול נקודת הטעינה הפתוחה מגדיר תקשורת בין עמדות טעינה ומערכת ניהול עמדת טעינה, או CSMS. הפתח את Charge Allianceמדווח כי OCPP 1.6 נשאר בשימוש נרחב בזמן שהאימוץ עובר לכיוון OCPP 2.x.

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

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

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

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

סקור את היקף ההסמכה ←

הגדר ניהול עומסים דינמי כלולאת בקרה מלאה

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

שקול אתר פשוט עם מגבלת יבוא של 300 קילוואט ומרווח תפעול של 20 קילוואט. כאשר הדרישה ללא-טעינה היא 180 קילוואט, הקצאת הטעינה הזמינה היא 100 קילוואט. אם הביקוש הזה יעלה ל-240 קילוואט, ההקצאה תרד ל-40 קילוואט.

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

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

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

בדוק מה בעצם מאפשר הממשק המקומי

מטען עשוי להציע ממשקים נפרדים לפלטפורמת הניהול שלו ולמערכת ניהול האנרגיה המקומית שלו (EMS).מתארת ​​פניקס קונטקטהסדר באמצעות OCPP לתקשורת עורפית ו- Modbus TCP להקצאת זרם דינמית ממערכת ניהול בניין.

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

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

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

קושחה ראויה לתשומת לב מיוחדת. לְדוּגמָה,הערות השחרור של AHP 2.6.0 של אלפןהציגה בקרת Modbus TCP/IP EMS עבור מוצרים שצוינו ותיעדה חיבור EMS בו-זמני יחיד. אותן הערות מציינות דרישות תוכנה תואמות בתוך רשת טעינה חכמה. לכן יש לרשום תאימות לפי דגם וקושחה, כולל עבור ציוד ממותג אחד.

בחר ארכיטקטורה עם בעלות ברורה על שליטה

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

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

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

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

הערכת ההשפעה על הבנייה ועלות החיים

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

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

להרחבה, קבע אם מטענים חדשים יכולים להצטרף למערכת הבקרה הקיימת בנפרד או רק באמצעות בקר קבוצתי של יצרן אחר. בדוק האם ניתן לשלוט בציוד AC ו-DC מעורב ברמה הנדרשת והאם מכשיר אחד שנכשל משפיע על שאר הקבוצה.

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

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

הפוך תביעות פרוטוקול לדרישות קבלה

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

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

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

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

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

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