კომერციული დამუხტვის ოპერატორებისთვის 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": { "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/WebSockets.
2. ძირითადი ავტორიზაცია: TLS მომხმარებლის სახელით/პაროლით.
3. სერტიფიკატზე დაფუძნებულიTLS კლიენტის მხარის სერთიფიკატებით.

პრობლემა ის იყო, რომ ბევრი დამტენი რჩებოდა პირველ პროფილზე, რაც მათ დაუცველს ხდიდა შუამავალი ადამიანის (MITM) შეტევებისა და არაავტორიზებული კონტროლის მიმართ.

4.2 2.0.1-ის გამაგრებული პოზიცია

OCPP 2.0.1 უსაფრთხო კომუნიკაციას ითვალისწინებს. ის ინტეგრირებულია მოწინავე უსაფრთხოების ფუნქციებთან:

• უსაფრთხო პროგრამული უზრუნველყოფის განახლებები: firmware-ის სურათების სავალდებულო ხელმოწერა და ვერიფიკაცია.
• უსაფრთხოების ჟურნალირებაუსაფრთხოებასთან დაკავშირებული მოვლენების დეტალური ჟურნალები (მაგ., წარუმატებელი შესვლის მცდელობები, სერტიფიკატის ვადის გასვლა).
• სერტიფიკატების მართვასტანდარტიზებული შეტყობინებები როტირებული და განახლებული სერტიფიკატებისთვის (CSMS-ის ან სადგურის მიერ ხელმძღვანელობით).
• TLS 1.2/1.3: უახლესი დაშიფვრის სტანდარტების მხარდაჭერა.

კომერციული ოპერატორებისთვის ეს ამცირებს ქსელის მასიური კომპრომეტირების რისკს და უზრუნველყოფს ინტერნეტ ნივთების ნივთების მოწყობილობებისთვის ახალი კიბერუსაფრთხოების რეგულაციების დაცვას.

თავი 5: ISO 15118 ინტეგრაცია: Plug & Charge და 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-ს მეშვეობით.
• ავტორიზაციაავტომობილის სერტიფიკატიდან მიღებული e-Mobility ID-ის (eMAID) გამოყენება.
• დაშიფრული კომუნიკაციამანქანასა და ქსელს შორის გადაცემული მგრძნობიარე ბილინგის მონაცემების დაცვის უზრუნველყოფა.

5.2 ჭკვიანი დატენვა და დატვირთვის დაბალანსება

მიუხედავად იმისა, რომ 1.6J მხარს უჭერდა ძირითად ჭკვიან დატენვას (გაგზავნადატენვის პროფილის დაყენება), 2.0.1 ამას აძლიერებს. ის საშუალებას იძლევა:

• გარე სიგნალის ინტეგრაციაქსელის სიხშირის ან საბითუმო ფასის სიგნალებზე რეალურ დროში რეაგირება.
• დინამიური დატვირთვის მართვაასობით კონექტორის გამოყენებით, ობიექტზე დენის განაწილების უფრო დეტალური კონტროლი.
• სატრანსპორტო საშუალება-ქსელი (V2G): 2.0.1 მოიცავს აუცილებელ მონაცემთა ველებს ორმხრივი ენერგიის ნაკადის მხარდასაჭერად, რაც ელექტრომობილებს საშუალებას აძლევს იმოქმედონ ქსელის განაწილებული ენერგიის რესურსების (DER) როლში.

5.3 მომხმარებლის ინტერფეისის/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 ცვლის მათ ერთი, ძლიერიტრანზაქციის მოვლენაშეტყობინება. ეს შეტყობინება გამოიყენება ტრანზაქციის ყველა სასიცოცხლო ციკლის ეტაპის (დაწყებული, განახლებული, დასრულებული) შესატყობინებლად. ის მოიცავს უნიკალურტრანზაქციის IDეს პრობლემა დამტენის გადატვირთვის შემთხვევაშიც კი შენარჩუნდება, რაც უზრუნველყოფს, რომ დამტენის მონაცემები და შესაბამისად, შემოსავალი არ დაიკარგება.

6.3 გაუმჯობესებული დიაგნოსტიკა და პრობლემების მოგვარება

ისGetLogდადიაგნოსტიკის სტატუსის შეტყობინება2.0.1 ვერსიაში შეტყობინებები უფრო სტრუქტურირებულია. CPO-ებს შეუძლიათ მოითხოვონ კონკრეტული ჟურნალის ტიპები (უსაფრთხოება, დიაგნოსტიკა, მომხმარებელი) და მიუთითონ დროის დიაპაზონი. ეს საშუალებას აძლევს დისტანციურ დახმარების გუნდებს მოაგვარონ პრობლემები ტექნიკოსის ადგილზე გაგზავნის გარეშე, რაც მნიშვნელოვნად ამცირებს ოპერაციულ ხარჯებს.

თავი 7: პროგრამული უზრუნველყოფის განახლების მექანიზმები: საიმედოობა და გაუქმება

პროგრამული უზრუნველყოფის განახლებები განვითარებადი აპარატურის სასიცოცხლო მნიშვნელობისაა, მაგრამ წარუმატებელმა განახლებამ შეიძლება დამტენი გააფუჭოს.

7.1 1.6J განახლების პროცესი

1.6 ჯ-ში,პროგრამული უზრუნველყოფის განახლებაბრძანება შედარებით მარტივი იყო. დამტენი ჩამოტვირთავდა სურათს და ცდილობდა მის ინსტალაციას. არ არსებობდა მრავალსაფეხურიანი განახლებების ან დადასტურებული გაუქმებების სტანდარტიზებული მექანიზმი.

7.2 2.0.1 მრავალსაფეხურიანი განახლება

OCPP 2.0.1 წარმოგიდგენთ უფრო დახვეწილ სასიცოცხლო ციკლს firmware-ის განახლებისთვის:

1. ჩამოტვირთვადამტენი იღებს გამოსახულებას და ადასტურებს მის საკონტროლო ჯამს/ხელმოწერას.
2. ინსტალაციაგანახლება გამოიყენება მეორად დანაყოფზე.
3. ვერიფიკაციასისტემა ამოწმებს, სწორად იტვირთება თუ არა ახალი firmware.
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 და ხელმოწერილი firmware არა მხოლოდ „სასიამოვნო“ ფუნქციებია - ისინი იურიდიული მოთხოვნებია აპარატურის გაყიდვისთვის ისეთ ბაზრებზე, როგორიცაა კალიფორნია და დიდი ბრიტანეთი.

თავი 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 ჯ-ის გამოყენება არსებული დაბალი სიმძლავრის ცვლადი დენის დამტენებისთვის.
2. ახალი DC სწრაფი დამუხტვის ადგილებიმანდატი 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": { "სტატუსი": "მიღებულია", "ვადის გასვლის თარიღი": "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" } } }]„

A.2 გულისცემისა და კავშირის მართვა

OCPP 2.0.1 ოპტიმიზაციას უკეთებს იმას, თუ როგორ ადასტურებს სადგური თავის „ცოცხალს“. 1.6 ჯ-ში, თუგულისცემაწარუმატებლობის შემთხვევაში, სადგური ხშირად უბრალოდ ხელახლა ცდილობდა. 2.0.1-ში სადგურს შეუძლია გამოიყენოსშეტყობინებამექანიზმი, რომელიც ატყობინებს, რომ მისი კავშირი მეორად სერვერთან დაიკარგა, ამავდროულად ინარჩუნებს რიტმს პირველადთან.

A.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 ვერსიაში,დატენვის პროფილის დაყენებააშკარად არის დაკავშირებული ა.დატენვის პროფილი დანიშნულება.

• დამუხტვის სადგური MaxProfile: ზღუდავს მთელი სადგურის მიერ წყლის მიღებას.
• TXDefaultProfile: ნებისმიერი ახალი ტრანზაქციის ნაგულისხმევი მნიშვნელობა.
• TXპროფილი: სპეციფიკურია მიმდინარე ტრანზაქციისთვის.

გარდა ამისა, 2.0.1 მხარს უჭერსGetChargingStackLevelშეტყობინება, რომელიც CSMS-ს საშუალებას აძლევს ნახოს, რომელი პროფილებია ამჟამად აქტიური და როგორ ანიჭებს მათ პრიორიტეტს EVSE-ს შიდა დამგეგმავი.

11.3 დისტანციური გააქტიურება და კონტროლი

დისტანციური ბრძანებები, როგორიცაადისტანციური დაწყების ტრანზაქცია(1.6J) შეიცვალატრანზაქციის დაწყების მოთხოვნა(2.0.1). ძირითადი განსხვავება დატვირთვაშია. 2.0.1-ში CSMS-ს შეუძლია მოიცავდესდამუხტვის პროფილიპირდაპირ ჩართვის მოთხოვნაში. ეს ნიშნავს, რომ მანქანას შეუძლია დაუყოვნებლივ დაიწყოს დატენვა სწორი სიმძლავრის დონით, მეორე შეტყობინების მოლოდინის გარეშე, რაც ამცირებს შეყოვნებას და აუმჯობესებს ქსელის სტაბილურობას.

თავი 12: დაბალი დონის JSON სქემები და ველის შედარებები

დეველოპერებისა და სისტემების ინტეგრატორებისთვის, სქემის ცვლილებები მიგრაციის ყველაზე შრომატევადი ნაწილია.

12.1 ჩამოთვლილი ტიპები (Enums)

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-მდე

მოდით განვიხილოთ „MegaCharge“-ის ჰიპოთეტური სცენარი, რომელიც წარმოადგენს CPO-ს 10,000 დამუხტვის წერტილით.

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.6J დამტენები 2.0.1-თან თავსებადი DC სწრაფი დამტენებით ჩაანაცვლა. შედეგად, „ჩართვა ვერ მოხერხდა“ სესიების რაოდენობა 15%-ით შემცირდა, ძირითადად უფრო მძლავრი დამტენების გამო.ტრანზაქციის მოვლენადამუშავება 2.0.1 ვერსიაში.

13.4 ინვესტიციის ანაზღაურების ანალიზი

საწყისი ინვესტიცია 2 მილიონი აშშ დოლარი იყო. თუმცა, ტექნიკური მომსახურების შემცირებულმა ხარჯებმა (მოწყობილობის მოდელის დიაგნოსტიკის წყალობით) წელიწადში 400 ათასი აშშ დოლარი დაზოგა. გარდა ამისა, V2G სიხშირული რეაგირების ბაზრებზე მონაწილეობის შესაძლებლობამ წლიური შემოსავალი დამატებით 200 ათასი აშშ დოლარი გამოიმუშავა. ანაზღაურების პერიოდი დაახლოებით 3.3 წელი იყო.

თავი 14: მყიდველის საბოლოო საკონტროლო სია OCPP 2.0.1 შესყიდვებისთვის

ახალი აპარატურის ან პროგრამული უზრუნველყოფის შეფასებისას, გამოიყენეთ ეს საკონტროლო სია, რათა უზრუნველყოთ ნამდვილი შესაბამისობა:

14.1 აპარატურის (EVSE) მოთხოვნები

• [ ]უსაფრთხოების პროფილი 3 მხარდაჭერამხარს უჭერს თუ არა ის კლიენტის მხარეს სერტიფიკატების მართვას?
• [ ]ორბირთვიანი პროცესორისაკმარისი სივრცეა TLS დაშიფვრისა და JSON დამუშავებისთვის?
• [ ]უსაფრთხო ელემენტი (SE)აქვს თუ არა დაფას გასაღებების შესანახად აპარატურული ნდობის root?
• [ ]ISO 15118-2/20 მზადააშეუძლია თუ არა კონტროლერს PnC-სთვის საჭირო მაღალი დონის კომუნიკაციის მართვა?
• [ ]ჩვენების შესაძლებლობააპარატურა მხარს უჭერს ფასის/სტატუსის ინფორმაციის OCPP-ის მეშვეობით ჩვენებას?მონაცემთა გადაცემაან მშობლიური შეტყობინებები?

14.2 პროგრამული უზრუნველყოფის (CSMS) მოთხოვნები

• [ ]მოწყობილობის მოდელის ვიზუალიზაციაშეიძლება თუ არა დაფაზე დამტენის იერარქიული ხედის ჩვენება?
• [ ]სერტიფიკატის ორგანოს (CA) ინტეგრაციაშეუძლია თუ არა CSMS-ს ავტომატურად გასცეს და მოახდინოს სერტიფიკატების როტაცია?
• [ ]ტრანზაქციის შერიგებაროგორ უმკლავდება სისტემა 1.6 ჯოულიანი ძველი დამტენებიდან „ჩამოკიდებულ“ ტრანზაქციებს?
• [ ]ჭკვიანი დამუხტვის ძრავამხარს უჭერს თუ არა ის 2.0.1 ვერსიის გაფართოებულ სტეკის დონის ლოგიკას?
• [ ]მასშტაბირებაშეუძლია 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": "აბსოლუტური", "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.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 ასინქრონულობის მიღება

მიუხედავად იმისა, რომ WebSockets თავისი ბუნებით ასინქრონულია, 2.0.1-ის სირთულე ნიშნავს, რომ ერთი მოთხოვნა (მაგალითადGetBaseReport) დამუშავებას შესაძლოა რამდენიმე წამი დასჭირდეს რესურსებით შეზღუდულ EVSE-ზე. CSMS დეველოპერებმა უნდა დანერგონ სტაბილური ტაიმ-აუტისა და ხელახალი ცდის ლოგიკა, რომელიც ითვალისწინებს სხვადასხვა აპარატურის მომწოდებლის დამუშავების სხვადასხვა სიჩქარეს.

19.2 ეფექტური JSON დამუშავება

JSON-ის დამუშავება შეიძლება პროცესორზე ინტენსიური იყოს. EVSE ფირმვერისთვის, დეველოპერებმა უნდა გამოიყენონ ნაკადზე დაფუძნებული ანალიზატორები, მთელი დატვირთვის ოპერატიულ მეხსიერებაში ჩატვირთვის ნაცვლად. ეს განსაკუთრებით მნიშვნელოვანიაშეტყობინებაშეტყობინებები, რომლებიც შეიძლება შეიცავდეს ასობით ცვლად განახლებას ერთ ჩარჩოში.

19.3 სახელმწიფო მანქანის მართვა

2.0.1 ვერსიაში ტრანზაქციის მდგომარეობის მანქანა უფრო ხისტია, ვიდრე 1.6J ვერსიაში. დეველოპერებმა მკაცრად უნდა დაიცვან გადასვლის წესები.ტრანზაქციის მოვლენამაგალითად, თქვენ არ შეგიძლიათ გაგზავნოთდასრულდაღონისძიება წინასწარი გაგზავნის გარეშედაიწყოღონისძიება კონკრეტულისთვისტრანზაქციის ID.

თავი 20: ტესტირება, ვალიდაცია და OCPP-ის შესაბამისობის ტესტირების ინსტრუმენტი (OCTT)

OCPP-ის დაპირებაა თავსებადობა, მაგრამ ის მხოლოდ მკაცრი ტესტირების გზით ხორციელდება.

20.1 OCA სერტიფიცირების როლი

Open Charge Alliance სერტიფიცირების პროგრამას სთავაზობს. მყიდველებმა უნდა მოძებნონ „OCPP 2.0.1 სერტიფიცირებული“ იარლიყი. ეს სერტიფიცირება უზრუნველყოფს, რომ იმპლემენტაციამ გაიარა ავტომატიზირებული ტესტების ნაკრები, რომელიც მოიცავს ყველა სავალდებულო პროფილს.

20.2 OCTT-ის გამოყენება

OCPP-ის შესაბამისობის ტესტირების ინსტრუმენტი (OCTT) ტესტირების ოქროს სტანდარტს წარმოადგენს. ის ახდენს როგორც CSMS-ის, ასევე EVSE-ს სიმულირებას.

• EVSE მწარმოებლებისთვისგამოიყენეთ OCTT იმის დასადასტურებლად, რომ თქვენი სადგური ამუშავებს „ბედნიერი გზის“ სცენარებს და ზღვრულ შემთხვევებს (მაგალითად, ქსელის გათიშვას პროგრამული უზრუნველყოფის განახლების დროს).
• CSMS პროვაიდერებისთვისგამოიყენეთ OCTT იმის უზრუნველსაყოფად, რომ თქვენს ბექენდს შეუძლია შეტყობინებების უზარმაზარი რაოდენობის დამუშავება და 2.0.1 ვერსიის მკაცრი უსაფრთხოების მოთხოვნების დაცვა.

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-ზე საუბრობს, შეიძლება აღჭურვილი იყოს კარიბჭით, მაგრამ CSMS, რომელიც მხოლოდ 1.6J-ზე საუბრობს, ვერ უზრუნველყოფს უსაფრთხოების მოდელს, რომელსაც მარეგულირებლები და ავტომწარმოებლები სულ უფრო მეტად მოითხოვენ. აპარატურის შეფასებისას, „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.