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-ն էր, որ իսկապես միավորեց ոլորտը։

1.1 OCPP 1.6J-ի գերիշխանությունը

2015 թվականին թողարկված OCPP 1.6-ը ներկայացրեց JSON-ը 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 և շրջանակային կառուցվածքներ

Այս արձանագրությունների միջև եղած տարբերությունը հասկանալու համար պետք է ուշադրություն դարձնել ցածր մակարդակի հաղորդակցությանը։ Երկու արձանագրություններն էլ օգտագործում են JSON-ը WebSockets-ի միջոցով, սակայն այս հաղորդագրությունների կառուցվածքը և մշակումը զգալիորեն տարբերվում են։

2.1 WebSocket շերտը

Երկու տարբերակներն էլ օգտագործում են WebSocket-ի մշտական ​​միացումներ, որոնք թույլ են տալիս լիարժեք երկկողմանի կապ։ Սա կարևոր է իրական ժամանակի գործողությունների համար, ինչպիսիք են բջջային հավելվածից լիցքավորման սեանսի դադարեցումը կամ ակնթարթային խափանումների մասին ծանուցումներ ստանալը։

2.2 Հաղորդագրության շրջանակի բաժանում

Տիպիկ OCPP հաղորդագրությունը բաղկացած է հաղորդագրության տեսակի ID-ից, եզակի հաղորդագրության ID-ից, գործողության անունից և օգտակար բեռից։

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", { "պատճառ": "PowerUp", "chargingStation": { "վաճառողի անուն": "MidaPower", "մոդել": "Terra-Z", "սերիայի համար": "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-ը ներկայացնում է հիերարխիկ մոդել, որը բաղկացած է հետևյալից՝ԲաղադրիչներևՓոփոխականներԲաղադրիչը կարող է լինել «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 ինտեգրացիա. Plug & Charge և V2G

Էլեկտրական մեքենաների լիցքավորման ապագան միայն էլեկտրոնների շարժման մեջ չէ, այլ տվյալների և էներգիայի ինտելեկտուալ փոխանակման մեջ է: ISO 15118-ը տրանսպորտային միջոց-ցանց (V2G) հաղորդակցության միջազգային ստանդարտն է, և դրա ինտեգրումը OCPP-ի հետ 2.0.1-ի որոշիչ առանձնահատկությունն է:

5.1 Միացնել և լիցքավորել գործընթացի բարդությունը

Միացրու և լիցքավորիր (PnC) համակարգը թույլ է տալիս վարորդին պարզապես միացնել մեքենան և սկսել լիցքավորումը՝ առանց հավելված կամ RFID քարտ օգտագործելու: Սա պահանջում է բարդ հանրային բանալիի ենթակառուցվածք (PKI), որը ներառում է մեքենան, լիցքավորիչը, օպերատորը և հաշվարկային կենտրոնը:

OCPP 1.6J-ում PnC աջակցությունը բացակայում էր հիմնական արձանագրությունում: Մատակարարները ստիպված էին ներդնել հատուկ ընդլայնումներ, ինչը հանգեցրեց մասնատման: OCPP 2.0.1-ը ապահովում է PnC-ի «ջրամատակարարումը»՝ աջակցելով.

• Վկայականի տեղադրումՊայմանագրային վկայականների փոխանցում CSMS-ից EV-ին EVSE-ի միջոցով։
• ՀաստատումՕգտագործելով տրանսպորտային միջոցի վկայականից ստացված e-Mobility ID-ն (eMAID):
• Գաղտնագրված հաղորդակցությունԱպահովել, որ մեքենայի և ցանցի միջև փոխանցվող զգայուն հաշվարկային տվյալները պաշտպանված են։

5.2 Խելացի լիցքավորում և բեռի հավասարակշռում

Մինչդեռ 1.6 Ջ-ն աջակցում էր հիմնական խելացի լիցքավորմանը (ուղարկելովՍահմանել լիցքավորման պրոֆիլը), 2.0.1-ը բարձրացնում է սա։ Այն թույլ է տալիս՝

• Արտաքին ազդանշանի ինտեգրումԻրական ժամանակի արձագանք ցանցի հաճախականության կամ մեծածախ գնի ազդանշաններին։
• Դինամիկ բեռի կառավարումՀարյուրավոր միակցիչներով տարածքում էլեկտրաէներգիայի բաշխման ավելի մանրակրկիտ վերահսկողություն։
• Տրանսպորտային միջոցից ցանց (V2G)2.0.1 տարբերակը ներառում է երկկողմանի էներգիայի հոսքը ապահովելու համար անհրաժեշտ տվյալների դաշտերը, ինչը թույլ է տալիս էլեկտրական մեքենաներին գործել որպես բաշխված էներգիայի ռեսուրսներ (ԲԷՌ) ցանցի համար։

5.3 Օգտատիրոջ UI/UX բարելավումներ

OCPP 2.0.1-ը աջակցում է տեղեկատվության ցուցադրմանը անմիջապես լիցքավորիչի էկրանին կամ մեքենայի վահանակին, ինչպիսիք են՝

• Իրական ժամանակում գնագոյացում տեղական արժույթով։
• Մոտավոր ժամանակը 80% լիցքավորման վիճակի (SoC) հասնելու համար։
• Ավարտից հետո ստացականի վերաբերյալ մանրամասն տեղեկատվություն:

Գլուխ 6. Սարքերի առաջադեմ կառավարում և մոնիթորինգ

CPO-ի համար լիցքավորիչի արժեքը միայն գնման գինը չէ, այլ սեփականության ընդհանուր արժեքը (TCO): Սպասարկումը և անսարքության ժամանակը շահույթի ամենամեծ գործոններն են: OCPP 2.0.1-ը լուծում է այս խնդիրը՝ գերազանց մոնիթորինգի հնարավորությունների միջոցով:

6.1 Իրադարձությունների վրա հիմնված հաշվետվություն

1.6Ջ-ում CSMS-ը սովորաբար ստիպված էր հարցնել լիցքավորիչը կարգավիճակի մասին կամ սպասելԿարգավիճակի մասին ծանուցում2.0.1 տարբերակումՄիջոցառումների մոնիթորինգՀամակարգը թույլ է տալիս CSMS-ին սահմանել շեմեր։ Օրինակ՝ «Ծանուցել ինձ միայն այն դեպքում, եթե ներքին ջերմաստիճանը գերազանցի 70°C-ը» կամ «Հաղորդել, եթե մուտքային լարումը իջնի 200 Վ-ից ցածր»։ Սա նվազեցնում է ցանցային երթևեկությունը և թույլ է տալիս իրականացնել կանխարգելիչ սպասարկում։

6.2 Գործարքների մշակում. Գործարքի իրադարձություն

OCPP 1.6J-ի ամենաշատ քննադատվող կողմերից մեկը գործարքների մշակումն էր։ Ներառված էր մի սեսիաԳործարքի սկիզբևԴադարեցրեք գործարքըհաղորդագրություններ, բայց եթե ցանցի ընդհատում էր տեղի ունենում, CSMS-ը հաճախ դժվարանում էր համաձայնեցնել հաշվարկային տվյալները։

OCPP 2.0.1-ը փոխարինում է դրանք մեկ, հզորԳործարքի իրադարձությունհաղորդագրություն։ Այս հաղորդագրությունը օգտագործվում է գործարքի կյանքի ցիկլի բոլոր փուլերը (սկսված, թարմացված, ավարտված) հաղորդելու համար։ Այն ներառում է եզակիգործարքի IDորը շարունակվում է նույնիսկ լիցքավորիչը վերագործարկվելուց հետո՝ ապահովելով, որ լիցքավորման որևէ տվյալ և, հետևաբար, եկամուտ չկորչի։

6.3 Բարելավված ախտորոշում և խնդիրների լուծում

TheGetLogևԱխտորոշման կարգավիճակի ծանուցում2.0.1 տարբերակում հաղորդագրությունները ավելի կառուցվածքային են։ CPO-ները կարող են պահանջել գրանցամատյանի որոշակի տեսակներ (անվտանգություն, ախտորոշում, օգտագործող) և նշել ժամանակային միջակայքը։ Սա թույլ է տալիս հեռակա աջակցության թիմերին լուծել խնդիրները՝ առանց տեխնիկ ուղարկելու կայք, ինչը զգալիորեն նվազեցնում է շահագործման ծախսերը։

Գլուխ 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 Անձնական տվյալներ (PII) OCPP-ում

Եվրոպայում տվյալների պաշտպանության ընդհանուր կանոնակարգի (GDPR) և Կալիֆոռնիայի CCPA-ի նման օրենքների համատեքստում, տվյալների կետեր, ինչպիսիք են՝idTag(RFID) կամEVCCID(Տրանսպորտային միջոցի նույնականացուցիչ) համարվում են անձնական տվյալներ։

OCPP 2.0.1-ը ապահովում է տվյալների անանունացման ավելի լավ վերահսկողություն։ Օրինակ՝Պատվերով տվյալներդաշտերը թույլ են տալիս օպերատորներին պահպանել մետատվյալները՝ առանց անձնական տվյալների հիմնական արձանագրությունների գրանցամատյաններին ենթարկելու։ Ավելին, բարելավված անվտանգության պրոֆիլները ապահովում են, որ այս տվյալները կոդավորված լինեն ինչպես փոխանցման, այնպես էլ հանգստի ժամանակ։

8.2 Մոռացվելու իրավունք և տվյալների փոխադրելիություն

2.0.1 սարքի մոդելի կառուցվածքային բնույթը CSMS մատակարարների համար հեշտացնում է «տվյալների ջնջման» հարցումների իրականացումը: 1.6J համակարգում օգտատիրոջ ID-ի բոլոր օրինակները տարբեր կոնֆիգուրացիայի բանալիների և գրանցամատյանների միջոցով գտնելը ձեռքով կատարելը մղձավանջ էր: 2.0.1-ում սարքի վիճակի և գործարքների տվյալների միջև հստակ տարանջատումը թույլ է տալիս ունենալ ավելի մաքուր տվյալների բազայի ճարտարապետություն:

8.3 Համապատասխանություն Ինտերնետային իրերի անվտանգության օրենքներին

Շատ տարածաշրջաններ այժմ ընդունում են օրենքներ, որոնք պահանջում են, որ IoT սարքերը ունենան եզակի գաղտնաբառեր և անվտանգ թարմացման մեխանիզմներ: OCPP 2.0.1-ի պարտադիր TLS-ը և ստորագրված ներկառուցված ծրագիրը ոչ միայն «հաճելի» գործառույթներ են, այլև իրավական պահանջներ են Կալիֆոռնիայի և Մեծ Բրիտանիայի նման շուկաներում սարքավորումներ վաճառելու համար:

Գլուխ 9. Գնորդի տեսակետը. TCO, ROI և ռազմավարական միգրացիա

Առևտրային լիցքավորման օպերատորի համար 1.6 Ջ-ին մնալու կամ 2.0.1-ին անցնելու որոշումը ֆինանսական է։

9.1 Կիրառման արժեքը

• OCPP 1.6JԷժան է ներդրման համար, լայնորեն աջակցվում է ցածրարժեք սարքավորումների կողմից, բայց կրում է բարձր թաքնված ծախսեր՝ սպասարկման և անվտանգության ռիսկերի առումով։
• OCPP 2.0.1EVSE-ում պահանջվում է ավելի հզոր պրոցեսորներ և ավելի շատ հիշողություն։ CSMS-ի մշակման ծախսերն ավելի բարձր են արձանագրության բարդության պատճառով։ Այնուամենայնիվ, այն ապահովում է զգալի օպերացիոն ծախսերի խնայողություն՝ հեռակառավարման և ավելի լավ հուսալիության շնորհիվ։

9.2 «Հարթ թարմացման» առասպելը

Հաճախ ասվում է, որ 1.6 Ջ լիցքավորիչները կարելի է թարմացնել մինչև 2.0.1՝ ծրագրային ապահովման միջոցով։ Իրականում սա հազվադեպ է ճիշտ։ 2.0.1 տարբերակի հիշողության և պրոցեսորի պահանջները (հատկապես TLS վկայագրերի մշակման և սարքի մոդելի բարդ JSON վերլուծության համար) հաճախ գերազանցում են ավելի հին 1.6 Ջ կարգավորիչների հնարավորությունները։

9.3 Ստրատեգիական միգրացիայի ուղիներ

CPO-ները պետք է դիտարկեն «հիբրիդային ցանցի» մոտեցումը.

1. Հնացած կայքերՇարունակեք օգտագործել 1.6 Ջ-ը առկա ցածր հզորության AC լիցքավորիչների համար։
2. Նոր Վաշինգտոնի արագ լիցքավորման կայաններԲոլոր նոր բարձր հզորության տեղակայումների համար կիրառել 2.0.1 հանձնարարական՝ PnC և V2G տեխնոլոգիաները աջակցելու համար։
3. Proxy SolutionsՕգտագործեք արձանագրության դարպաս, որը կարող է 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 Անլար լիցքավորման աջակցություն

Ինքնավար տրանսպորտային միջոցների (ԱՎ) ի հայտ գալուն զուգընթաց, ձեռքով միացումը կդառնա հնացած։ OCPP 2.1-ը կներառի ստանդարտացված հաղորդագրություններ ինդուկտիվ (անլար) լիցքավորման, հավասարեցման կառավարման և էներգիայի փոխանցման համար՝ առանց մարդու միջամտության։

10.3 Ինտեգրացիա «Խելացի քաղաքների» հետ

Ապագա տարբերակները, հավանաբար, ավելի խորը ինտեգրում կունենան երթևեկության կառավարման համակարգերի և վերականգնվող էներգիայի կանխատեսումների հետ։ Լիցքավորիչները կկարողանան «մրցույթ» ներկայացնել էներգիայի համար իրական ժամանակի էներգետիկ շուկաներում՝ լիցքավորման ցանցերը վերածելով հսկայական վիրտուալ էլեկտրակայանների (ՎԷԿ):

Տեխնիկական հավելված. Հաղորդագրությունների համեմատությունների խորը վերլուծություն

Վերջնական տեխնիկական խորություն ապահովելու համար մենք այժմ կվերլուծենք երկու տարբերակների միջև հաղորդագրությունների որոշակի հաջորդականություններ և շրջանակների տարբերությունները։

Ա.1 Հաստատման հոսքը

1.6J տարբերակում լիազորումը երկուական «Ընդունված» կամ «Արգելափակված» պատասխան էր։

1.6J Հաստատել պատասխանը.«json [3, "123456", { "idTagInfo": { "կարգավիճակ": "Ընդունված է", "ժամկետի ավարտ": "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.6 Ջ-ում, եթեՍրտի զարկձախողվելու դեպքում կայանը հաճախ պարզապես կրկնում էր փորձերը։ 2.0.1-ում կայանը կարող է օգտագործելԾանուցել իրադարձությունմեխանիզմ՝ հաղորդելու համար, որ իր կապը երկրորդական backend-ի հետ կորել է, միաժամանակ պահպանելով հիմնականի հետ աշխատանքը։

Ա.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. BootNotificationԿայանը ուղարկում է մատակարարը, մոդելը և սերիական համարը։
3. Ստանալ կարգավորումCSMS-ը խնդրում է բոլոր բանալիները ստուգել ընթացիկ վիճակը։
4. Փոփոխել կարգավորումըCSMS-ը թարմացնում է որոշակի բանալիներ (օրինակ՝Սրտի զարկերի ընդմիջում).
5. Կարգավիճակի մասին ծանուցումԿայանը հաղորդում է «Հասանելի է»։

OCPP 2.0.1 Հոսք՝

1. Անվտանգ TLS ձեռքսեղմումՊարտադիր վկայականի փոխանակում։
2. BootNotificationՆերառում էպատճառ(օրինակ՝Ուժի ավելացում).
3. GetBaseReportԲոլոր բանալիները հարցնելու փոխարեն, CSMS-ը խնդրում է «Հիմնական հաշվետվություն», որը տրամադրում է սարքի մոդելի ամբողջական հիերարխիան։
4. Սահմանել փոփոխականներCSMS-ը թարմացնում է փոփոխականները։ Նկատի ունեցեք, որ 2.0.1 տարբերակը թույլ է տալիս ատոմային թարմացումներ՝ մեկ հաղորդագրության մեջ սահմանելով մի քանի փոփոխական և ապահովելով, որ բոլորը հաջողությամբ անցնեն կամ ոչ մեկը չանցնի։
5. Ծանուցել իրադարձությունԿայանը հաղորդում է բաղադրիչների սկզբնական վիճակների մասին։

11.2 Խելացի լիցքավորման բանակցային գործընթաց

Խելացի լիցքավորումն է այն, ինչ 2.0.1-ը իսկապես փայլում է, հատկապես բազմակի լիցքավորման պրոֆիլներ օգտագործելիս։

1.6J-ում CSMS-ը ուղարկում էՍահմանել լիցքավորման պրոֆիլըորը սահմանում է կույտի մակարդակը և ժամանակացույցը։ Եթե կայանը ունի բազմաթիվ միակցիչներ, պրոֆիլի մշակումը հաճախ երկիմաստ է։

2.0.1-ում,Սահմանել լիցքավորման պրոֆիլըհստակորեն կապված է a-ի հետլիցքավորման պրոֆիլՆպատակ.

• Լիցքավորման կայան MaxProfileՍահմանափակում է ամբողջ կայանի մուտքը։
• TXDefaultProfile: Ցանկացած նոր գործարքի լռելյայն արժեքը։
• TXProfile: Հատուկ ընթացիկ գործարքի համար։

Ավելին, 2.0.1-ը աջակցում էGetChargingStackLevelհաղորդագրություն, որը թույլ է տալիս CSMS-ին տեսնել, թե որ պրոֆիլներն են ներկայումս ակտիվ և ինչպես են դրանք առաջնահերթություն տրվում EVSE-ի ներքին ժամանակացույցի կողմից։

11.3 Հեռակառավարման ակտիվացում և կառավարում

Հեռակա հրամաններ, ինչպիսիք ենՀեռակա մեկնարկային գործարք(1.6Ջ)-ները փոխարինվել ենԳործարքի մեկնարկի հարցում(2.0.1): Հիմնական տարբերությունը օգտակար բեռնվածության մեջ է: 2.0.1-ում CSMS-ը կարող է ներառելլիցքավորման պրոֆիլանմիջապես մեկնարկի հարցման մեջ։ Սա նշանակում է, որ մեքենան կարող է անմիջապես սկսել լիցքավորումը ճիշտ հզորության մակարդակով՝ առանց երկրորդ հաղորդագրության սպասելու, նվազեցնելով լատենտությունը և բարելավելով ցանցի կայունությունը։

Գլուխ 12. JSON սխեմաների և դաշտերի համեմատություններ ցածր մակարդակում

Մշակողների և համակարգերի ինտեգրատորների համար սխեմայի փոփոխությունները միգրացիայի ամենաաշխատատար մասն են։

12.1 Թվարկված տեսակներ (Enums)

OCPP 2.0.1-ը զգալիորեն ընդլայնում է ստանդարտացված Enum-ների քանակը՝ նվազեցնելով «պատվերով» կարգավիճակի կոդերի անհրաժեշտությունը, որը խոչընդոտում էր 1.6J իրականացումները։

• Պատճառաբանության թվարկումներ: Պահակ, Պլանավորված վերագործարկում, Հեռակա վերագործարկում, PowerLoss.
• Կարգավիճակի համարակալումներ: Բնակեցված, Պահպանված, Անհասանելի է, Խախտված. 2.0.1 ավելացումներՀասանելի է, Բնակեցված, Պահպանված, Անհասանելի է, Խախտվածբայց ենթակարգավիճակներով՝ ավելի մանրամասն տեղեկությունների համար։

12.2 Տվյալների տեսակներ և միավորներ

OCPP 2.0.1-ը ձևակերպում է ստանդարտ միավորների (SI) օգտագործումը: Մինչդեռ 1.6Ջ-ը երբեմն թողնում էր տասնորդական ճշգրտությունը անորոշ, 2.0.1-ը օգտագործում էտասնորդականհզորության և էներգիայի արժեքների տեսակները՝ ապահովելով տարբեր մատակարարների սարքավորումների միջև հետևողական հաշվառում։

Գլուխ 13. Ուսումնասիրություն. Գլոբալ CPO անցումը 1.6J-ից մինչև 2.0.1

Եկեք դիտարկենք «MegaCharge»-ի հիպոթետիկ սցենարը, որը 10,000 լիցքավորման կետ ունեցող CPO է։

13.1 Փուլ 1. Աուդիտ

MegaCharge-ը հայտնաբերեց, որ իրենց 1.6J լիցքավորիչների 40%-ը չի աջակցում TLS 1.2-ին: Սա նշանակում էր, որ այդ լիցքավորիչները չէին կարող մասնակցել առաջիկա կառավարական պայմանագրերին:

13.2 Փուլ 2. CSMS-ի արդիականացում

Նոր CSMS կառուցելու փոխարեն, MegaCharge-ը ներդրեց «OCPP թարգմանության շերտ»։ Այս շերտը մշակում էր 1.6J միացումներ հին սարքավորումների համար և 2.0.1 միացումներ նոր սարքավորումների համար, բայց իրենց բջջային հավելվածին և հաշվարկային մեխանիզմին տրամադրում էր միասնական API։

13.3 Փուլ 3. Սարքավորումների փոխարինում

Բարձր հաճախելիությամբ կայքերի համար MegaCharge-ը փոխարինեց 1.6Ջ լիցքավորիչները 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.6 Ջ հզորությամբ հին լիցքավորիչների «կախված» գործարքները։
• [ ]Խելացի լիցքավորման շարժիչԱջակցո՞ւմ է այն 2.0.1 տարբերակի առաջադեմ stack-level տրամաբանությանը։
• [ ]ՄասշտաբայնությունԿարո՞ղ է WebSocket-ի մշակիչը միաժամանակ կառավարել 50,000+ մշտական ​​TLS միացումներ։

Գլուխ 15. OCPP ներդրման տարածված խնդիրների լուծում

Նույնիսկ ստանդարտի դեպքում իրականացումները տարբեր են։ Ահա ամենատարածված «խճճվածքները»։

15.1 WebSocket-ի ժամկետների ավարտ

Շատ ցանցային firewall-ներ փակում են չաշխատող TCP կապերը։ ԵթեՍրտի զարկերի ընդմիջումեթե այն չափազանց բարձր է դրված, լիցքավորիչը կարող է անջատված լինել։

• ԼուծումՀամոզվեքՍրտի զարկերի ընդմիջումավելի ցածր է, քան firewall-ի ժամանակի ավարտը (սովորաբար 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. Կիրառման կոդի հատվածներ. «Մանրամասները»

Մշակողներին օգնելու համար մենք տրամադրում ենք կոնցեպտուալ JSON ներկայացումներ բարդ 2.0.1 առաջադրանքների համար։

17.1 Վկայականների ռոտացիայի հոսք

Երբ վկայականի ժամկետը մոտենում է, CSMS-ը պետք է ակտիվացնի դրա ռոտացիան։

1. CSMS-ը ուղարկում էՎկայականը ստորագրված է:«json [2, "CERT-01", "CertificateSigned", { "certificateChain": "-----ՍԿԻԶԲԻ ՎԿԱՅԱԳԻՐ-----\n...\n-----ԱՎԱՐՏԻ ՎԿԱՅԱԳԻՐ-----", "certificateType": "V2G" }]«

2. Կայանը արձագանքում էԸնդունված է:«json [3, "CERT-01", { "կարգավիճակ": "Ընդունված է" }]«

3. Կայանը ուղարկում էԱնվտանգության իրադարձության ծանուցում:«json [2, "EVT-99", "Անվտանգության իրադարձության ծանուցում", { "տեսակ": "Վկայականը պտտվել է", "ժամանակային նշագիծ": "2026-08-09T10:00:00Z" }]«

17.2 Ցանցին հարմարվող լիցքավորման պրոֆիլի սահմանում

Պատկերացրեք, որ ցանցի օպերատորը պետք է կրճատի էլեկտրաէներգիայի մատակարարումը ամբողջ ցանցում։

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 (Լիցքավորման կայանների կառավարման համակարգ): Լիցքավորիչները կառավարող backend ամպային հարթակը։
• EVSE (Էլեկտրական տրանսպորտային միջոցների մատակարարման սարքավորումներ)Ֆիզիկական լիցքավորման կայան։
• Բաց լիցքավորման կետի արձանագրություն (OCPP): Լեզուն, որով նրանք խոսում են։
• OCA (Բաց վճարների դաշինք)Կազմակերպությունը, որը գրում է լեզուն։
• ԻՍՕ 15118Մեքենայի և լիցքավորիչի միջև արձանագրությունը։
• PnC (Միացրեք և լիցքավորեք)ISO 15118-ի և OCPP 2.0.1-ի կողմից ապահովված օգտագործողի փորձը։
• V2G (Տրանսպորտային միջոցից ցանց)Մեքենայից էլեկտրաէներգիայի ուղարկում ցանցին։
• V2X (Տրանսպորտային միջոցից ամեն ինչ)V2G, V2H և V2B համակարգերի ընդհանուր տերմինը։
• TLS (Տրանսպորտային շերտի անվտանգություն): Գաղտնագրում, որը պահպանում է տվյալների անվտանգությունը։
• PKI (Հանրային բանալիի ենթակառուցվածք)Անվտանգության համար օգտագործվող թվային վկայականների համակարգ։
• JSON (JavaScript օբյեկտի նշում): Հաղորդագրությունների ձևաչափը։
• WebSocketՄշտական ​​կապի «խողովակը», որի միջով հոսում են հաղորդագրությունները։
• Սարքի մոդելՀիերարխիկ եղանակով 2.0.1-ը նկարագրում է սարքավորումները։
• ԲաղադրիչՍարքավորման մի մաս (օրինակ՝ միակցիչ):
• ՓոփոխականԿոմպոնենտի հատկություն (օրինակ՝ Կարգավիճակ):
• ԱտրիբուտՓոփոխականի մասին մետատվյալներ (օրինակ՝ արժեք, փոփոխականություն):
• Գործարքի իրադարձություն2.0.1 տարբերակում բոլոր սեսիայի տվյալների միասնական հաղորդագրություն։
• Սրտի զարկՊարբերական «Ես կենդանի եմ» ազդանշանը։
• BootNotification«Բարև, ես այստեղ եմ» ազդանշանը, երբ լիցքավորիչը միանում է։
• Տվյալների փոխանցում«Ընդհանուր» հաղորդագրություն մատակարարի հատուկ ընդլայնումների համար (օգտագործեք զգուշությամբ):

Վերջնական մտքեր. Նավարկություն բազմապրոտոկոլային դարաշրջանում

Որպես գնորդ կամ օպերատոր, ամենակարևոր եզրակացությունն այն է, որ մենք մտնում ենքբազմապրոտոկոլային դարաշրջանՀաջորդ 3-5 տարիների ընթացքում 1.6 Ջ-ն և 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 Ասինխրոնիզմի ընդունում

Մինչ WebSocket-ները բնույթով ասինխրոն են, 2.0.1-ի բարդությունը նշանակում է, որ մեկ հարցում (օրինակ՝GetBaseReport) մշակումը սահմանափակ ռեսուրսներով EVSE-ում կարող է մի քանի վայրկյան տևել: CSMS մշակողները պետք է ներդնեն կայուն ժամանակի ավարտի և վերստին փորձի տրամաբանություն, որը հաշվի է առնում տարբեր սարքավորումների մատակարարների մշակման տարբեր արագությունները:

19.2 Արդյունավետ JSON վերլուծում

JSON վերլուծումը կարող է շատ ժամանակ պահանջել պրոցեսորի համար։ EVSE ներկառուցված ծրագրի համար մշակողները պետք է օգտագործեն հոսքային վերլուծիչներ, այլ ոչ թե ամբողջ բեռը բեռնեն RAM-ի մեջ։ Սա հատկապես կարևոր էԾանուցել իրադարձությունհաղորդագրություններ, որոնք կարող են պարունակել հարյուրավոր փոփոխական թարմացումներ մեկ շրջանակում։

19.3 Պետական ​​մեքենայի կառավարումը

2.0.1 տարբերակում գործարքի վիճակների մեքենան ավելի կոշտ է, քան 1.6J-ում։ Մշակողները պետք է խստորեն հետևեն անցման կանոններին։Գործարքի իրադարձությունՕրինակ, դուք չեք կարող ուղարկելԱվարտված էմիջոցառում առանց նախապես ուղարկելուՍկսվել էմիջոցառում տվյալ կոնկրետի համարգործարքի ID.

Գլուխ 20. Փորձարկում, վավերացում և OCPP համապատասխանության ստուգման գործիք (OCTT)

Փոխգործունակությունը OCPP-ի խոստումն է, բայց այն իրականացվում է միայն խիստ փորձարկումների միջոցով։

20.1 OCA հավաստագրման դերը

Բաց վճարային դաշինքը առաջարկում է հավաստագրման ծրագիր: Գնորդները պետք է փնտրեն «OCPP 2.0.1 հավաստագրված» պիտակը: Այս հավաստագրումը երաշխավորում է, որ ներդրումը հաջողությամբ անցել է ավտոմատացված թեստերի մի շարք, որոնք ներառում են բոլոր պարտադիր պրոֆիլները:

20.2 OCTT-ի օգտագործումը

OCPP համապատասխանության ստուգման գործիքը (OCTT) թեստավորման ոսկե ստանդարտն է։ Այն մոդելավորում է և՛ CSMS-ը, և՛ EVSE-ն։

• EVSE արտադրողների համարՕգտագործեք OCTT-ը՝ ստուգելու համար, որ ձեր կայանը կարգավորում է «երջանիկ ուղու» սցենարները և եզրային դեպքերը (օրինակ՝ ցանցի անջատումները ներկառուցված ծրագրի թարմացման ժամանակ):
• CSMS մատակարարների համարՕգտագործեք OCTT-ը՝ ապահովելու համար, որ ձեր backend-ը կարողանա մշակել հաղորդագրությունների հսկայական բազմազանություն և համապատասխանի 2.0.1 տարբերակի խիստ անվտանգության պահանջներին։

20.3 Դաշտային փորձարկումներ և փոխգործակցության փառատոներ

Ավտոմատացված թեստավորումից զատ, OCA-ն կազմակերպում է «Plugfests», որտեղ մատակարարները ներկայացնում են իրենց սարքավորումներն ու ծրագրային ապահովումը՝ իրական աշխարհի սցենարներում միմյանց հետ փորձարկելու համար: Այստեղ են հայտնաբերվում և լուծվում ամենաաննշան սխալները, ինչպիսիք են վկայագրերի անհամատեղելիությունը կամ JSON ձևաչափման աննշան տարբերությունները:

Գլուխ 21. Խորը համեմատական ​​աղյուսակ. OCPP 2.0.1-ի 60+ գործողությունները

Ամբողջական հղումներ տրամադրելու համար մենք դասակարգում ենք 2.0.1-ի հիմնական հաղորդագրությունները և համեմատում դրանք 1.6Ջ համապատասխան հաղորդագրությունների հետ։

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-ը աշխատում է JSON-over-WebSocket-ի վրա, այլ ոչ թե 1.6J-ի SOAP փոխադրման վրա, հաղորդագրությունների հոսքերը ավելի թեթև են և շատ ավելի հեշտ է վրիպազերծել՝ գործնական առավելություն, որը ձեր 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.