Арилжааны цэнэглэгч операторуудад зориулсан OCPP 1.6J болон 2.0.1-ийн стратегийн харьцуулалт

Дэлхийн арилжааны цэнэглэгч операторуудын OCPP 1.6J болон 2.0.1-ийн эцсийн стратегийн харьцуулалт: Сүлжээний өргөтгөх чадвар, дэвшилтэт кибер аюулгүй байдал, ISO 15118 интеграцчилал, тогтвортой цахилгаан тээврийн хэрэгслийн өсөлтийн урт хугацааны дэд бүтцийн ирээдүйг баталгаажуулах чадварыг эзэмших.

Товч агуулга

Цахилгаан тээврийн хэрэгслийн (EV) цэнэглэх орчин газар хөдлөлтийн өөрчлөлтөд орж байна. Дэлхий даяар нэвтрүүлэлт хурдасахын хэрээр Цахилгаан тээврийн хэрэгслийн хангамжийн тоног төхөөрөмж (EVSE) болон цэнэглэх станцын удирдлагын систем (CSMS)-ийн харилцан үйлчлэлийг зохицуулдаг үндсэн харилцаа холбооны протоколууд нь Арилжааны цэнэглэх операторуудын (CPO) техникийн стратегийн гол цэг болсон. Нээлттэй цэнэглэх холбоо (OCA)-ийн дэмждэг Нээлттэй цэнэглэх цэгийн протокол (OCPP) нь энгийн мессеж дамжуулах хүрээнээс нарийн төвөгтэй, аюулгүй, өндөр өргөтгөх боломжтой стандарт болж хөгжсөн.

Энэхүү гарын авлагад OCPP 1.6J-ээс OCPP 2.0.1 руу шилжих шилжилтийн талаарх бүрэн техникийн шинжилгээг өгсөн болно. Бид архитектурын ялгаа, аюулгүй байдлын сайжруулалт, төхөөрөмжийн удирдлагын загварууд болон ISO 15118 интеграцийн чухал үүргийг судална. Худалдан авагчид болон операторуудын хувьд энэхүү нийтлэл нь хурдацтай хөгжиж буй зах зээл дээр мэдээлэлтэй худалдан авалт болон шилжилтийн шийдвэр гаргахад гол лавлагаа болж өгдөг.

1-р бүлэг: Цахилгаан тээврийн хэрэгслийн цэнэглэх стандартын хувьсал: Түүхэн нөхцөл байдал

Нээлттэй Цэнэглэх Цэгийн Протокол (OCPP) нь харилцан ажиллах чадварын хэрэгцээнээс үүдэлтэй. Цахилгаан тээврийн хэрэгслийг цэнэглэх эхэн үед техник хангамж үйлдвэрлэгчид болон програм хангамжийн үйлчилгээ үзүүлэгчид өмчийн протоколуудыг ашиглаж, өрсөлдөөн болон инновацийг боомилсон "ханатай цэцэрлэг"-ийг бий болгосон. OCPP 1.2 болон 1.5-ыг нэвтрүүлснээр суурийг тавьсан боловч салбарыг үнэхээр нэгтгэсэн зүйл нь OCPP 1.6 байв.

1.1 OCPP-ийн давамгайлал 1.6J

2015 онд гарсан OCPP 1.6 нь 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 Structures

Эдгээр протоколуудын ялгааг ойлгохын тулд доод түвшний харилцаа холбоог авч үзэх хэрэгтэй. Хоёр протокол хоёулаа WebSockets дээр JSON ашигладаг боловч эдгээр мессежийн бүтэц, боловсруулалт нь мэдэгдэхүйц ялгаатай байдаг.

2.1 WebSocket давхарга

Хоёр хувилбар хоёулаа бүрэн дуплекс харилцаа холбоог зөвшөөрдөг байнгын WebSocket холболтыг ашигладаг. Энэ нь гар утасны аппликейшнаас цэнэглэх сессийг зогсоох эсвэл алдааны мэдэгдлийг шууд хүлээн авах зэрэг бодит цагийн үйл ажиллагаанд чухал ач холбогдолтой.

2.2 Зурвасын хүрээний задаргаа

Ердийн OCPP мессеж нь мессежийн төрлийн ID, өвөрмөц мессежийн ID, үйлдлийн нэр болон ашигтай ачааллаас бүрдэнэ.

OCPP 1.6J Хүрээний Жишээ (Ачаалах Мэдэгдэл)

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

OCPP 2.0.1 Хүрээний Жишээ (Ачаалах Мэдэгдэл)

"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-д ачаалалт нь дахин ачаалах, асаах эсвэл хяналтын нохойн өдөөгчөөс болсон эсэхийг ойлгох боломжийг олгодог бөгөөд энэ нь оношлогооны логикийг илүү сайн болгодог.

Бүлэг 3: Архитектурын парадигмын өөрчлөлт: Төхөөрөмжийн загвар

OCPP 2.0.1 хувилбарын хамгийн чухал техникийн алдаа нь ...-г нэвтрүүлсэн явдал юм.Төхөөрөмжийн загвар.

3.1 1.6J тохиргооны түлхүүрүүдийн хязгаарлалтууд

OCPP 1.6J хувилбарт техник хангамжийн тохиргоог "Тохиргооны түлхүүрүүд"-ийн хавтгай жагсаалтаар удирддаг байсан (жишээ нь,Зүрхний цохилтын интервал, Холболтын хугацаа дууслаа). Цэнэглэгч нь илүү төвөгтэй болохын хэрээр (олон холбогч, нэгдсэн цахилгаан модулиуд, нарийн төвөгтэй хөргөлтийн системүүд) энэхүү хавтгай жагсаалтыг удирдах боломжгүй болсон. Станцын физик шатлалыг тодорхойлох стандартчилагдсан арга байгаагүй.

3.2 2.0.1 Төхөөрөмжийн Загварын Арга

OCPP 2.0.1 нь дараахаас бүрдэх шаталсан загварыг танилцуулж байнаБүрэлдэхүүн хэсгүүдмөнХувьсагчБүрэлдэхүүн хэсэг нь “Хянагч”, “Холбогч”, эсвэл “PowerModule” байж болно. Бүрэлдэхүүн хэсэг бүр нь түүний төлөв байдал эсвэл тохиргоог илэрхийлдэг хувьсагчтай байдаг (жишээ нь,Температур, Хүчдэл, Хамгийн их гүйдэл).

• Бүрэлдэхүүн хэсэгЦэнэглэх станцын физик эсвэл логик хэсэг.
• Хувьсах: Тухайн бүрэлдэхүүн хэсгийн тодорхой шинж чанар.
• Онцлог шинж чанаруудХувьсагчийг тодорхойлсон мета өгөгдөл (нэгж, хүрээ, хандалтын төрөл).

Энэ нь стандартчилагдсан хяналт хийх боломжийг олгодог. Оператор одоо үйлдвэрлэгчийн тусгай өмчийн түлхүүрт найдахын оронд стандартчилагдсан замыг ашиглан тодорхой тэжээлийн модулийн температурыг асууж болно.

Бүлэг 4: Кибер аюулгүй байдал: “Хамгийн сайн хүчин чармайлт”-аас заавал биелүүлэх TLS хүртэл

Цахилгаан тээврийн хэрэгслийг цэнэглэж эхэлсэн эхний үед аюулгүй байдлын асуудал ихэвчлэн хоёрдугаарт тавигддаг байсан. OCPP 1.6J нь аюулгүй байдлын профайлуудыг санал болгодог байсан ч хэрэгжилт нь үйлдвэрлэгчдийн хооронд жигд бус байв.

4.1 1.6J дахь аюулгүй байдлын профайлууд

OCPP 1.6J нь гурван аюулгүй байдлын профайлыг тодорхойлсон:

1. Баталгаатай бусЭнгийн текст HTTP/Вэб Сокетууд.
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 Залгаад цэнэглэх системийн нарийн төвөгтэй байдал

Plug & Charge (PnC) нь жолоочид аппликейшн эсвэл RFID карт ашиглахгүйгээр тээврийн хэрэгслийг залгаад цэнэглэж эхлэх боломжийг олгодог. Энэ нь тээврийн хэрэгсэл, цэнэглэгч, оператор болон клиринг төвийг хамарсан цогц нийтийн түлхүүрийн дэд бүтэц (PKI) шаарддаг.

OCPP 1.6J хувилбарт PnC дэмжлэг үндсэн протоколд байхгүй байсан. Үйлдвэрлэгчид өөрчлөн тохируулсан өргөтгөлүүдийг хэрэгжүүлэх шаардлагатай болсон нь хуваагдмал байдалд хүргэсэн. OCPP 2.0.1 нь дараах зүйлсийг дэмжих замаар PnC-д зориулсан "сантехник"-ийг хангадаг:

• Сертификат суурилуулахCSMS-ээс гэрээний гэрчилгээг EVSE-ээр дамжуулан EV-д дамжуулах.
• ЗөвшөөрөлТээврийн хэрэгслийн гэрчилгээнээс гаргаж авсан цахим хөдөлгөөний үнэмлэх (eMAID)-г ашиглах.
• Шифрлэгдсэн харилцаа холбоо: Машин болон сүлжээний хооронд дамжуулсан мэдрэмтгий төлбөрийн өгөгдлийг хамгаалсан эсэхийг баталгаажуулах.

5.2 Ухаалаг цэнэглэлт ба ачааллын тэнцвэржүүлэлт

1.6J нь үндсэн ухаалаг цэнэглэлтийг дэмждэг байсан (илгээдэг)Цэнэглэх Профайлыг Тохируулах), 2.0.1 хувилбар нь үүнийг сайжруулдаг. Энэ нь дараах боломжийг олгодог:

• Гадаад дохионы интеграци: Сүлжээний давтамж эсвэл бөөний үнийн дохионд бодит цагийн хариу үйлдэл үзүүлэх.
• Динамик ачааллын менежмент: Хэдэн зуун холбогчтой сайт даяар цахилгаан түгээлтийг илүү нарийн хянах.
• Тээврийн хэрэгслээс сүлжээнд (V2G): 2.0.1 нь хоёр чиглэлт эрчим хүчний урсгалыг дэмжихэд шаардлагатай өгөгдлийн талбаруудыг багтаасан бөгөөд энэ нь цахилгаан тээврийн хэрэгслийг сүлжээнд тархсан эрчим хүчний нөөц (DER) болгон ашиглах боломжийг олгодог.

5.3 Хэрэглэгчийн UI/UX сайжруулалтууд

OCPP 2.0.1 нь дараах мэдээллийг цэнэглэгчийн дэлгэц эсвэл тээврийн хэрэгслийн хяналтын самбар дээр шууд харуулахыг дэмждэг:

• Орон нутгийн мөнгөн тэмдэгтээр бодит цагийн үнэ тогтоох.
• 80%-ийн цэнэгийн төлөвт (SoC) хүрэх тооцоолсон хугацаа.
• Хүлээн авсны дараа дэлгэрэнгүй мэдээлэл.

Бүлэг 6: Дэвшилтэт төхөөрөмжийн удирдлага ба хяналт

CPO-ийн хувьд цэнэглэгчийн өртөг нь зөвхөн худалдан авах үнэ биш; энэ нь өмчлөлийн нийт өртөг (TCO) юм. Засвар үйлчилгээ болон зогсолт нь ашгийн хамгийн том эрсдэл юм. OCPP 2.0.1 нь үүнийг дээд зэргийн хяналтын чадавхаар дамжуулан шийдвэрлэдэг.

6.1 Үйл явдалд суурилсан тайлан

1.6J хувилбарт CSMS нь ихэвчлэн цэнэглэгчээс статусыг нь асуух эсвэл хүлээх шаардлагатай болдог байв.Статусын Мэдэгдэл2.0.1 хувилбарт,Үйл явдлын хяналтсистем нь CSMS-д босго хэмжээг тохируулах боломжийг олгодог. Жишээлбэл: “Дотоод температур 70°C-аас хэтэрсэн тохиолдолд л надад мэдэгдээрэй” эсвэл “Оролтын хүчдэл 200В-оос доош унасан тохиолдолд мэдээлнэ үү.” Энэ нь сүлжээний урсгалыг бууруулж, урьдчилан сэргийлэх засвар үйлчилгээ хийх боломжийг олгодог.

6.2 Гүйлгээ хийх: Гүйлгээний үйл явдал

OCPP 1.6J-ийн хамгийн их шүүмжлэлд өртсөн талуудын нэг нь гүйлгээг зохицуулах явдал байв. Үүнд оролцсон сессГүйлгээг эхлүүлэхмөнГүйлгээг зогсоохмессежүүд байсан ч сүлжээнд тасалдал гарсан тохиолдолд CSMS нь төлбөрийн өгөгдлийг тохируулахад ихэвчлэн бэрхшээлтэй байсан.

OCPP 2.0.1 нь эдгээрийг ганц, хүчирхэг хувилбараар сольсон.Гүйлгээний арга хэмжээмессеж. Энэ мессежийг гүйлгээний бүх амьдралын мөчлөгийн үе шатуудыг (Эхэлсэн, Шинэчилсэн, Дууссан) мэдээлэхэд ашигладаг. Энэ нь өвөрмөц мэдээллийг агуулдаггүйлгээний дугаарцэнэглэгч дахин ассан ч энэ нь хэвээр үлдэж, цэнэглэх өгөгдөл алдагдахгүй, улмаар орлого ч алдагдахгүй байхыг баталгаажуулдаг.

6.3 Оношлогоо болон алдааг олж засварлах сайжруулалт

ньGetLogмөнОношлогооСтатусМэдэгдэл2.0.1 хувилбар дахь мессежүүд илүү бүтэцлэгдсэн. CPO-ууд тодорхой логийн төрлүүдийг (Аюулгүй байдал, Оношлогоо, Хэрэглэгч) хүсч, цагийн хязгаарыг зааж өгч болно. Энэ нь алсын дэмжлэгийн багуудад техникчийг сайт руу илгээхгүйгээр асуудлыг шийдвэрлэх боломжийг олгодог бөгөөд энэ нь OPEx-ийг мэдэгдэхүйц бууруулдаг.

Бүлэг 7: Програм хангамжийн шинэчлэлтийн механизмууд: Найдвартай байдал ба буцаан олголтууд

Програм хангамжийн шинэчлэлтүүд нь хөгжиж буй техник хангамжийн амин чухал хэсэг боловч амжилтгүй шинэчлэлт нь цэнэглэгчийг эвдэж болзошгүй.

7.1 1.6J шинэчлэлтийн үйл явц

1.6Ж-д,ШинэчлэхФирмэйрТушаал нь харьцангуй энгийн байсан. Цэнэглэгч нь зургийг татаж аваад суулгахыг оролддог байв. Олон үе шаттай шинэчлэлт эсвэл баталгаажсан буцаан олголтын стандартчилагдсан механизм байгаагүй.

7.2 2.0.1 Олон шатлалт шинэчлэлт

OCPP 2.0.1 нь програм хангамжийн шинэчлэлтийн илүү боловсронгуй амьдралын мөчлөгийг танилцуулж байна:

1. Татаж авахЦэнэглэгч нь зургийг авч, шалгах нийлбэр/гарын үсгийг баталгаажуулдаг.
2. Суурилуулалт: Шинэчлэлтийг хоёрдогч хуваалтад хэрэглэнэ.
3. Баталгаажуулалт: Систем шинэ програм хангамж зөв ачаалагдаж байгаа эсэхийг шалгана.
4. Идэвхжүүлэлт: Үндсэн хуваалт шилжсэн байна.

Хэрэв ямар нэгэн алхам бүтэлгүйтвэл, протокол нь цэнэглэгчийг өмнөх тогтвортой хувилбар руу хэрхэн буцаах, тодорхой алдааны кодыг CSMS-д мэдээлэхийг тодорхойлдог. Энэ түвшний найдвартай байдал нь томоохон хэмжээний арилжааны байршуулалтын хувьд хэлэлцээр хийх боломжгүй юм.

7.3 Гарын үсгийн баталгаажуулалт

Хорлонтой этгээдүүд эвдэрсэн програм хангамжийг байршуулахаас урьдчилан сэргийлэхийн тулд 2.0.1 хувилбар нь дижитал гарын үсэг ашиглахыг шаарддаг. Цэнэглэгч нь үйлдвэрлэгчийн хувийн түлхүүрээр гарын үсэг зураагүй аливаа кодыг ажиллуулахаас татгалзах бөгөөд энэ нь техник хангамжийн түвшний хакердлаас хамгаалах чухал давхаргыг нэмж өгдөг.

Бүлэг 8: Мэдээллийн нууцлал, зохицуулалтын нийцэл болон GDPR

Цахилгаан машин цэнэглэх нь өдөр тутмын хэрэглээ болж байгаа тул үүсгэсэн хувийн мэдээллийн хэмжээ гайхалтай их байна. Нэг удаагийн цэнэглэлт нь хэрэглэгчийн хувийн мэдээлэл, тээврийн хэрэгслийн байршил, аяллын хэв маяг, санхүүгийн мэдээллийг нь холбож чаддаг.

8.1 OCPP дахь хувь хүнийг таних мэдээлэл (PII)

Европ дахь Ерөнхий Мэдээлэл Хамгаалалтын Зохицуулалт (GDPR) болон Калифорнийн CCPA зэрэг ижил төстэй хуулиудын хүрээнд, гэх мэт өгөгдлийн цэгүүдidTag(RFID) эсвэлEVCCID(Тээврийн хэрэгслийн таних тэмдэг)-ийг PII гэж үзнэ.

OCPP 2.0.1 нь өгөгдлийг нууцлах илүү сайн хяналтыг олгодог. Жишээлбэл,Захиалгат өгөгдөлталбарууд нь операторуудад PII-г үндсэн протоколын бүртгэлд ил гаргахгүйгээр мета өгөгдлийг хадгалах боломжийг олгодог. Цаашилбал, сайжруулсан аюулгүй байдлын профайлууд нь энэхүү өгөгдлийг дамжуулах болон амрах үед шифрлэхийг баталгаажуулдаг.

8.2 Мартагдах эрх ба өгөгдөл зөөвөрлөх боломж

2.0.1 Төхөөрөмжийн Загварын бүтэцлэгдсэн шинж чанар нь CSMS үйлчилгээ үзүүлэгчдэд "өгөгдөл устгах" хүсэлтийг хэрэгжүүлэхэд хялбар болгодог. 1.6J системд хэрэглэгчийн ID-ийн бүх тохиолдлыг өөр өөр тохиргооны түлхүүр болон бүртгэлээс олох нь гараар хар дарсан зүүд байсан. 2.0.1 хувилбарт төхөөрөмжийн төлөв болон гүйлгээний өгөгдлийн хоорондох тодорхой тусгаарлалт нь илүү цэвэр мэдээллийн сангийн архитектурыг бий болгох боломжийг олгодог.

8.3 IoT аюулгүй байдлын хуулийг дагаж мөрдөх

Олон бүс нутаг одоо IoT төхөөрөмжүүдийг өвөрмөц нууц үг болон аюулгүй шинэчлэх механизмтай байхыг шаарддаг хууль баталж байна. OCPP 2.0.1-ийн заавал дагаж мөрдөх TLS болон гарын үсэг зурсан програм хангамж нь зөвхөн "байхад тохиромжтой" функцууд биш бөгөөд эдгээр нь Калифорни, Их Британи зэрэг зах зээл дээр техник хангамж борлуулах хууль ёсны шаардлага юм.

9-р бүлэг: Худалдан авагчийн үзэл бодол: TCO, ROI болон Стратегийн шилжилт хөдөлгөөн

Арилжааны цэнэглэгч операторын хувьд 1.6J-г ашиглах эсвэл 2.0.1 руу шилжих шийдвэр нь санхүүгийн хувьд асуудал юм.

9.1 Хэрэгжүүлэх зардал

• OCPP 1.6JХэрэгжүүлэхэд хямд, хямд өртөгтэй техник хангамжаар өргөнөөр дэмжигддэг боловч засвар үйлчилгээ болон аюулгүй байдлын эрсдэлд өндөр далд зардал дагуулдаг.
• OCPP 2.0.1: EVSE-д илүү хүчирхэг процессор болон илүү их санах ой шаарддаг. Протоколын нарийн төвөгтэй байдлаас шалтгаалан CSMS-ийн хөгжүүлэлтийн зардал өндөр байдаг. Гэсэн хэдий ч энэ нь алсын удирдлага болон илүү найдвартай байдлыг сайжруулснаар OPEx-ийн мэдэгдэхүйц хэмнэлтийг санал болгодог.

9.2 “Шулуун шинэчлэлт” гэсэн домог

1.6J цэнэглэгчийг програм хангамжаар дамжуулан 2.0.1 руу шинэчлэх боломжтой гэж ихэвчлэн ярьдаг. Бодит байдал дээр энэ нь ховор тохиолддог. 2.0.1 хувилбарын санах ой болон CPU-ийн шаардлага (ялангуяа TLS гэрчилгээтэй ажиллах болон Төхөөрөмжийн загварын нарийн төвөгтэй JSON задлан шинжлэх) нь хуучин 1.6J хянагчдын чадавхаас давж гардаг.

9.3 Шилжилт хөдөлгөөний стратегийн замууд

CPO-ууд "Эрлийз сүлжээ"-ний аргыг авч үзэх хэрэгтэй:

1. Хуучин сайтууд: Одоо байгаа бага чадлын хувьсах гүйдлийн цэнэглэгчдэд зориулж 1.6J-г үргэлжлүүлэн ажиллуулна уу.
2. Шинэ DC хурдан цэнэглэх сайтуудPnC болон V2G-г дэмжих бүх шинэ өндөр хүчин чадалтай байршуулалтуудад 2.0.1-ийг заавал биелүүлэх.
3. Прокси шийдлүүдCSMS-ийн 1.6J мессежийг 2.0.1-тэй нийцтэй формат руу хөрвүүлэх боломжтой протоколын гарцыг ашиглан нэгдсэн удирдлагын самбар ашиглах боломжтой.

Бүлэг 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": "Хүлээн зөвшөөрөгдсөн", "дуусах огноо": "2026-12-31T23:59:59Z" } }]"

2.0.1 хувилбарт хариулт нь илүү олон нөхцөл байдлыг агуулдаг, тухайлбалidTokenхэрэглэгчийн интерфэйсийн төрөл болон нэмэлт мэдээлэл.

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: Гүнзгий шумбалт: Мессежийн урсгалын шинжилгээ ба дарааллын диаграммууд

Энэ бүлэгт бид 1.6J болон 2.0.1 хувилбаруудын хоорондох үйл ажиллагааны ялгааг харуулахын тулд EVSE болон CSMS-ийн харилцан үйлчлэлийн дарааллыг шинжилнэ.

11.1 Ачаалах болон Тохиргооны дараалал

Цэнэглэгч анх сүлжээнд холбогдохдоо өөрийгөө тодорхойлж, тохиргоогоо синхрончлох ёстой.

OCPP 1.6J Урсгал:

1. WebSocket холболт: 80 эсвэл 443-р боомт дээр байгуулагдсан.
2. Ачаалах МэдэгдэлСтанц нь үйлдвэрлэгч, загвар болон цуваа дугаарыг илгээдэг.
3. Тохиргоог авахCSMS нь одоогийн төлөвийг шалгахын тулд бүх түлхүүрийг хүсдэг.
4. Тохиргоог өөрчлөхCSMS нь тодорхой түлхүүрүүдийг шинэчилдэг (жишээ нь,Зүрхний цохилтын интервал).
5. Статусын Мэдэгдэл: Станцын тайлангууд “Боломжтой”.

OCPP 2.0.1 Урсгал:

1. Аюулгүй TLS гар барихЗаавал гэрчилгээ солих.
2. Ачаалах Мэдэгдэл: Оруулсаншалтгаан(жишээ нь,PowerUp).
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 нь дараахыг дэмждэгЦэнэглэх StackLevel-г авахмессеж нь CSMS-д аль профайлууд одоогоор идэвхтэй байгаа болон EVSE-ийн дотоод хуваарьлагчаар тэдгээрийг хэрхэн эрэмбэлж байгааг харах боломжийг олгоно.

11.3 Алсын удирдлага болон удирдлага

Алсын удирдлага гэх мэтАлсын зайнаас эхлүүлэх гүйлгээ(1.6J)-г сольсонХүсэлтЭхлүүлэхГүйлгээ(2.0.1). Гол ялгаа нь ачааллын хэмжээнд байна. 2.0.1 хувилбарт CSMS нь дараах зүйлсийг агуулж болноцэнэглэхПрофайлэхлүүлэх хүсэлтэд шууд. Энэ нь машин хоёр дахь мессежийг хүлээхгүйгээр зөв чадлын түвшинд шууд цэнэглэж эхлэх боломжтой бөгөөд энэ нь саатлыг бууруулж, сүлжээний тогтвортой байдлыг сайжруулна гэсэн үг юм.

Бүлэг 12: Бага түвшний JSON схем болон талбарын харьцуулалт

Хөгжүүлэгчид болон системийн интеграторуудын хувьд схемийн өөрчлөлт нь шилжилтийн хамгийн их хөдөлмөр шаардсан хэсэг юм.

12.1 Тоолсон төрлүүд (Тооллого)

OCPP 2.0.1 нь стандартчилагдсан Enum-уудын тоог эрс өргөжүүлж, 1.6J хувилбарын хэрэгжилтэд тулгардаг байсан "Захиалгат" төлөвийн кодын хэрэгцээг бууруулсан.

• Шалтгаан Тоолуурууд: Харуул, Хуваарьт Дахин тохируулах, Алсын зайнаас дахин тохируулах, Эрчим хүчний алдагдал.
• Статусын тоололтууд: Эзлэгдсэн, Захиалсан, Боломжгүй, Алдаатай. 2.0.1 хувилбар нэмэгдлээБоломжтой, Эзлэгдсэн, Захиалсан, Боломжгүй, Алдаатайгэхдээ илүү дэлгэрэнгүй мэдээлэл авахын тулд дэд статусуудтай.

12.2 Өгөгдлийн төрөл ба нэгжүүд

OCPP 2.0.1 нь стандарт нэгж (SI)-ийн хэрэглээг албан ёсоор болгосон. 1.6J нь заримдаа аравтын бутархайн нарийвчлалыг тодорхойлоогүй үлдээдэг бол 2.0.1 нь ... ашигладаг.аравтын бутархайэрчим хүч болон эрчим хүчний үнэ цэнийн төрлүүд, энэ нь янз бүрийн үйлдвэрлэгчийн техник хангамжийн хооронд тогтмол төлбөр тооцоог хангах боломжийг олгодог.

Бүлэг 13: Кейс судалгаа: Дэлхийн CPO шилжилт хөдөлгөөн 1.6J-ээс 2.0.1 хүртэл

10,000 цэнэгийн цэг бүхий CPO болох “MegaCharge”-ийн таамаглалын хувилбарыг авч үзье.

13.1 1-р үе шат: Аудит

MegaCharge компани 1.6J загварын автомашиныхаа 40% нь TLS 1.2-г дэмждэггүй болохыг тогтоожээ. Энэ нь эдгээр цэнэглэгч нь засгийн газрын дараагийн гэрээнд хамрагдах эрхгүй гэсэн үг юм.

13.2 2-р үе шат: CSMS-ийн шинэчлэлт

MegaCharge нь шинэ CSMS бүтээхийн оронд “OCPP орчуулгын давхарга”-г хэрэгжүүлсэн. Энэ давхарга нь хуучин техник хангамжийн 1.6J холболтыг, шинэ техник хангамжийн 2.0.1 холболтыг зохицуулдаг байсан ч гар утасны апп болон төлбөр тооцооны системдээ нэгдсэн API-г нэвтрүүлсэн.

13.3 3-р үе шат: Тоног төхөөрөмжийг солих

Их ачаалалтай сайтуудын хувьд MegaCharge нь 1.6J цэнэглэгчийг 2.0.1-тэй нийцтэй DC хурдан цэнэглэгчээр сольсон. Үүний үр дүнд "Эхлүүлж чадсангүй" гэсэн сессүүд 15%-иар буурсан нь голчлон илүү бат бөх байсантай холбоотой юм.Гүйлгээний арга хэмжээ2.0.1 хувилбар дээр боловсруулж байна.

13.4 ROI шинжилгээ

Анхны хөрөнгө оруулалт нь 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-ийн Root CA суулгаагүй үед тохиолддог.

• Шийдэл: АшиглахСуулгах гэрчилгээИтгэмжлэлийн сүлжээ бүрэн дууссан эсэхийг баталгаажуулахын тулд ашиглалтад оруулах үеийн мессеж.

15.3 JSON ачааллын хэмжээ

Зарим 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: Хэрэгжүүлэх кодын хэсгүүд: “Эцсийн” хэсэг

Хөгжүүлэгчдэд туслахын тулд бид нарийн төвөгтэй 2.0.1 даалгавруудын JSON дүрслэлийг өгдөг.

17.1 Гэрчилгээний эргэлтийн урсгал

Сертификатын хугацаа дуусах дөхөж байгаа үед CSMS нь эргэлтийг идэвхжүүлэх ёстой.

1. CSMS илгээдэгГэрчилгээнд гарын үсэг зурсан:"json [2, "CERT-01", "CertificateSigned", { "certificateChain": "-----СЕРТИФИКАТ ЭХЛЭХ-----\n...\n-----СЕРТИФИКАТ ТӨГСГӨЛ-----", "certificateType": "V2G" }]"

2. Станц хариу үйлдэл үзүүлдэгХүлээн зөвшөөрөгдсөн:"json [3, "CERT-01", {"status": "Хүлээн зөвшөөрөгдсөн"}]"

3. Станц илгээдэгАюулгүй байдлын үйл явдлын мэдэгдэл:"json [2, "EVT-99", "SecurityEventNotification", { "төрөл": "Гэрчилгээ Эргэсэн", "цаг хугацааны тэмдэг": "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 задлан шинжлэх нь CPU-г их ачаалдаг байж болно. 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 үйлчилгээ үзүүлэгчдэд зориулсан: Өөрийн backend нь маш олон төрлийн мессеж болон 2.0.1-ийн хатуу аюулгүй байдлын шаардлагыг зохицуулж чадах эсэхийг баталгаажуулахын тулд OCTT ашиглана уу.

20.3 Хээрийн туршилт ба харилцан үйлчлэлийн наадам

Автоматжуулсан туршилтаас гадна OCA нь үйлдвэрлэгчид бодит ертөнцийн нөхцөлд бие биетэйгээ тулгарах туршилт хийхийн тулд техник хангамж болон програм хангамжаа авчирдаг "Plugfests"-ийг зохион байгуулдаг. Энэ нь сертификатын нийцгүй байдал эсвэл JSON форматын бага зэргийн ялгаа зэрэг хамгийн нарийн алдаануудыг илрүүлж, шийдвэрлэдэг газар юм.

Бүлэг 21: Гүнзгий харьцуулсан хүснэгт: OCPP 2.0.1-ийн 60+ үйлдлүүд

Бүрэн лавлагаа өгөхийн тулд бид 2.0.1 хувилбарын үндсэн мессежүүдийг ангилж, тэдгээрийг 1.6J хувилбартай харьцуулсан.

21.1 Хангамж болон тохиргоо

21.2 Гүйлгээ хийх

21.3 Аюулгүй байдал болон програм хангамжийн удирдлага

21.4 Хүснэгт нь таны сүлжээнд юу гэсэн үг вэ

Хүснэгт нэг зүйлийг эргэлзээгүй харуулж байна: OCPP 2.0.1 нь 1.6J-ийн гоо сайхны нэршил биш юм. Шинэ мессежийн гэр бүлүүд - бичсэн хувьсагчууд, үйл явдалд суурилсан гүйлгээ, гэрчилгээний менежмент - нь Plug & Charge, ухаалаг цэнэглэлт, зохицуулалтын тайланд шаардлагатай сантехник юм. Зөвхөн 1.6J-ээр ярьдаг цэнэглэгчийг гарцаар шинэчилж болох боловч зөвхөн 1.6J-ээр ярьдаг CSMS нь зохицуулагчид болон автомашин үйлдвэрлэгчдийн улам бүр шаардаж буй аюулгүй байдлын загварыг хангаж чадахгүй. Тоног төхөөрөмжийг үнэлэхдээ "2.0.1-д бэлэн" гэдэг нь програм хангамж ирэх жил төлөвлөгдөөгүй, өнөөдөр хүргэгдэж байгаа гэсэн үг юм. OCPP 2.0.1 нь 1.6J-ийн SOAP дамжуулалтын оронд JSON-over-WebSocket дээр ажилладаг тул мессежийн урсгал нь илүү хөнгөн бөгөөд дибаг хийхэд илүү хялбар байдаг - энэ нь танай мэдээллийн технологийн баг эхний өдрөөс эхлэн мэдрэх практик давуу тал юм.

Бүлэг 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.