ការប្រៀបធៀបជាយុទ្ធសាស្ត្រនៃ OCPP 1.6J ទល់នឹង 2.0.1 សម្រាប់ប្រតិបត្តិករសាកថ្មពាណិជ្ជកម្ម

ការប្រៀបធៀបជាយុទ្ធសាស្ត្រច្បាស់លាស់នៃ OCPP 1.6J ទល់នឹង 2.0.1 សម្រាប់ប្រតិបត្តិករសាកថ្មពាណិជ្ជកម្មសកល៖ ការស្ទាត់ជំនាញលើសមត្ថភាពធ្វើមាត្រដ្ឋានបណ្តាញ សន្តិសុខតាមអ៊ីនធឺណិតកម្រិតខ្ពស់ ការរួមបញ្ចូល ISO 15118 និងហេដ្ឋារចនាសម្ព័ន្ធរយៈពេលវែងដែលធានាអនាគតសម្រាប់កំណើន EV ប្រកបដោយចីរភាព

សេចក្តីសង្ខេបសម្រាប់នាយកប្រតិបត្តិ

ទេសភាព​នៃ​ការសាកថ្ម​យានយន្ត​អគ្គិសនី (EV) កំពុង​ឆ្លងកាត់​ការផ្លាស់ប្ដូរ​ដ៏​ធំ​មួយ។ នៅពេលដែលការទទួលយកជាសកលកើនឡើងលឿន ពិធីការទំនាក់ទំនងមូលដ្ឋានដែលគ្រប់គ្រងអន្តរកម្មរវាងឧបករណ៍ផ្គត់ផ្គង់យានយន្តអគ្គិសនី (EVSE) និងប្រព័ន្ធគ្រប់គ្រងស្ថានីយ៍សាកថ្ម (CSMS) បានក្លាយជាចំណុចកណ្តាលនៃយុទ្ធសាស្ត្របច្ចេកទេសសម្រាប់ប្រតិបត្តិករសាកថ្មពាណិជ្ជកម្ម (CPOs)។ ពិធីការចំណុចសាកថ្មបើកចំហ (OCPP) ដែលថែរក្សាដោយ Open Charge Alliance (OCA) បានវិវត្តពីក្របខ័ណ្ឌផ្ញើសារសាមញ្ញមួយទៅជាស្តង់ដារដ៏ទំនើប មានសុវត្ថិភាព និងអាចធ្វើមាត្រដ្ឋានបានខ្ពស់។

មគ្គុទ្ទេសក៍នេះផ្តល់នូវការវិភាគបច្ចេកទេសយ៉ាងហ្មត់ចត់អំពីការផ្លាស់ប្តូរពី OCPP 1.6J ទៅ OCPP 2.0.1។ យើងស្វែងយល់ពីភាពខុសគ្នានៃស្ថាបត្យកម្ម ការបង្កើនសុវត្ថិភាព គំរូគ្រប់គ្រងឧបករណ៍ និងតួនាទីសំខាន់នៃការរួមបញ្ចូល ISO 15118។ សម្រាប់អ្នកទិញ និងប្រតិបត្តិករ អត្ថបទនេះបម្រើជាឯកសារយោងច្បាស់លាស់សម្រាប់ធ្វើការសម្រេចចិត្តលើការផ្គត់ផ្គង់ និងការធ្វើចំណាកស្រុកដែលមានព័ត៌មានគ្រប់គ្រាន់នៅក្នុងទីផ្សារដែលមានភាពចាស់ទុំយ៉ាងឆាប់រហ័ស។

ជំពូកទី 1: ការវិវត្តនៃស្តង់ដារសាកថ្មរថយន្តអគ្គិសនី៖ បរិបទប្រវត្តិសាស្ត្រ

ពិធីការចំណុចសាកថ្មបើកចំហ (OCPP) បានកើតចេញពីតម្រូវការសម្រាប់អន្តរប្រតិបត្តិការ។ នៅក្នុងថ្ងៃដំបូងនៃការសាកថ្មរថយន្ត EV ក្រុមហ៊ុនផលិតផ្នែករឹង និងអ្នកផ្តល់កម្មវិធីបានប្រើប្រាស់ពិធីការដែលមានកម្មសិទ្ធិ ដោយបង្កើត "សួនច្បារដែលមានជញ្ជាំងព័ទ្ធជុំវិញ" ដែលរារាំងការប្រកួតប្រជែង និងភាពច្នៃប្រឌិត។ ការណែនាំអំពី OCPP 1.2 និង 1.5 បានដាក់មូលដ្ឋានគ្រឹះ ប៉ុន្តែវាគឺជា OCPP 1.6 ដែលពិតជាបានបង្រួបបង្រួមឧស្សាហកម្មនេះ។

១.១ ការត្រួតត្រារបស់ OCPP ១.៦J

OCPP 1.6 ត្រូវបានចេញផ្សាយនៅឆ្នាំ 2015 បានណែនាំការអនុវត្ត JSON over WebSockets (1.6J)។ ការផ្លាស់ប្តូរនេះចេញពីការផ្ញើសារដែលមានមូលដ្ឋានលើ SOAP បានកាត់បន្ថយការចំណាយយ៉ាងច្រើន និងធ្វើឱ្យការអនុវត្តមានភាពសាមញ្ញសម្រាប់អ្នកអភិវឌ្ឍន៍។ វាបានណែនាំមុខងារដូចជាការសាកថ្មឆ្លាតវៃ និងការជូនដំណឹងអំពីស្ថានភាពបន្ថែម ដែលធ្វើឱ្យវាក្លាយជាស្តង់ដារឧស្សាហកម្មអស់រយៈពេលជិតមួយទសវត្សរ៍មកហើយ។

១.២ លោកុប្បត្តិនៃ OCPP ២.០.១

បើទោះបីជាមានភាពជោគជ័យនៃ 1.6J ក៏ដោយ កំណើនរបស់ឧស្សាហកម្មនេះបានបង្ហាញពីដែនកំណត់របស់វា។ បញ្ហាទាក់ទងនឹងសុវត្ថិភាព ភាពស្មុគស្មាញនៃការគ្រប់គ្រងឧបករណ៍ និងកង្វះការគាំទ្រដើមសម្រាប់ការរួមបញ្ចូលបណ្តាញអគ្គិសនីកម្រិតខ្ពស់ (V2G) បាននាំឱ្យមានការអភិវឌ្ឍ OCPP 2.0 ហើយបន្ទាប់មក OCPP 2.0.1 ដែលបានកែលម្អ (ចេញផ្សាយនៅឆ្នាំ 2020)។ OCPP 2.0.1 មិនមែនគ្រាន់តែជាការអាប់ដេតនោះទេ វាគឺជាការរចនាឡើងវិញទាំងស្រុងដែលមានគោលបំណងគាំទ្រដល់បណ្តាញសាកថ្មជំនាន់ក្រោយដែលមានថាមពលខ្ពស់ ឆ្លាតវៃ និងមានសុវត្ថិភាព។

ជំពូកទី 2: គំរូទំនាក់ទំនងមូលដ្ឋាន៖ JSON, WebSockets និងរចនាសម្ព័ន្ធស៊ុម

ដើម្បីយល់ពីភាពខុសគ្នារវាងពិធីការទាំងនេះ មនុស្សម្នាក់ត្រូវតែពិនិត្យមើលការទំនាក់ទំនងកម្រិតទាប។ ពិធីការទាំងពីរប្រើប្រាស់ JSON លើ WebSockets ប៉ុន្តែរចនាសម្ព័ន្ធ និងការគ្រប់គ្រងសារទាំងនេះមានភាពខុសគ្នាគួរឱ្យកត់សម្គាល់។

២.១ ស្រទាប់ WebSocket

កំណែទាំងពីរប្រើប្រាស់ការតភ្ជាប់ WebSocket អចិន្ត្រៃយ៍ ដែលអនុញ្ញាតឱ្យមានការទំនាក់ទំនងទ្វេភាគីពេញលេញ។ នេះមានសារៈសំខាន់សម្រាប់ប្រតិបត្តិការជាក់ស្តែង ដូចជាការបញ្ឈប់វគ្គសាកថ្មពីកម្មវិធីទូរស័ព្ទ ឬការទទួលបានការជូនដំណឹងអំពីកំហុសភ្លាមៗ។

២.២ ការបំបែកស៊ុមសារ

សារ OCPP ធម្មតាមួយមានលេខសម្គាល់ប្រភេទសារ លេខសម្គាល់សារតែមួយគត់ ឈ្មោះសកម្មភាព និងបន្ទុកទិន្នន័យ។

ឧទាហរណ៍ស៊ុម 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 គឺការណែនាំអំពីម៉ូដែលឧបករណ៍.

៣.១ ដែនកំណត់នៃសោកំណត់រចនាសម្ព័ន្ធ 1.6J

នៅក្នុង OCPP 1.6J ការកំណត់រចនាសម្ព័ន្ធផ្នែករឹងត្រូវបានគ្រប់គ្រងតាមរយៈបញ្ជីសំប៉ែតនៃ "សោកំណត់រចនាសម្ព័ន្ធ" (ឧ.ចន្លោះពេលចង្វាក់បេះដូង, អស់ពេលភ្ជាប់នៅពេលដែលឆ្នាំងសាកកាន់តែស្មុគស្មាញ (ឧបករណ៍ភ្ជាប់ច្រើន ម៉ូឌុលថាមពលរួមបញ្ចូលគ្នា ប្រព័ន្ធត្រជាក់ស្មុគស្មាញ) បញ្ជីរាបស្មើនេះក្លាយជាមិនអាចគ្រប់គ្រងបាន។ មិនមានវិធីស្តង់ដារដើម្បីពិពណ៌នាអំពីឋានានុក្រមរូបវន្តរបស់ស្ថានីយ៍ទេ។

៣.២ វិធីសាស្រ្តគំរូឧបករណ៍ ២.០.១

OCPP 2.0.1 ណែនាំគំរូឋានានុក្រមដែលមានសមាសធាតុនិងអថេរសមាសភាគមួយអាចជា “ឧបករណ៍បញ្ជា” “ឧបករណ៍ភ្ជាប់” ឬ “ម៉ូឌុលថាមពល”។ សមាសភាគនីមួយៗមានអថេរដែលតំណាងឱ្យស្ថានភាព ឬការកំណត់រចនាសម្ព័ន្ធរបស់វា (ឧ.សីតុណ្ហភាព, វ៉ុល, ចរន្តអតិបរមា).

• សមាសភាគ: ផ្នែករូបវន្ត ឬឡូជីខលនៃស្ថានីយ៍សាកថ្ម។
• អថេរ៖ គុណលក្ខណៈជាក់លាក់នៃសមាសភាគនោះ។
• លក្ខណៈទិន្នន័យមេតាពិពណ៌នាអំពីអថេរ (ឯកតា ជួរ ប្រភេទចូលប្រើ)។

នេះអនុញ្ញាតឱ្យមានការត្រួតពិនិត្យស្តង់ដារ។ ឥឡូវនេះ ប្រតិបត្តិករអាចសាកសួរសីតុណ្ហភាពនៃម៉ូឌុលថាមពលជាក់លាក់មួយដោយប្រើផ្លូវស្តង់ដារ ជាជាងពឹងផ្អែកលើសោដែលមានកម្មសិទ្ធិជាក់លាក់របស់អ្នកលក់។

ជំពូកទី ៤៖ សន្តិសុខតាមអ៊ីនធឺណិត៖ ពី “កិច្ចខិតខំប្រឹងប្រែងដ៏ល្អបំផុត” ដល់ TLS ចាំបាច់

នៅក្នុងថ្ងៃដំបូងនៃការសាកថ្មរថយន្ត EV សុវត្ថិភាពច្រើនតែជាការគិតគូរនៅពេលក្រោយ។ OCPP 1.6J ផ្តល់ជូននូវទម្រង់សុវត្ថិភាព ប៉ុន្តែការអនុវត្តមិនស៊ីសង្វាក់គ្នានៅទូទាំងអ្នកលក់។

៤.១ ទម្រង់សុវត្ថិភាពក្នុង 1.6J

OCPP 1.6J បានកំណត់ទម្រង់សុវត្ថិភាពចំនួនបី៖

1. មិនមានការធានា៖ HTTP/WebSockets អត្ថបទធម្មតា
2. ការអនុញ្ញាតមូលដ្ឋាន: TLS ជាមួយឈ្មោះអ្នកប្រើប្រាស់/ពាក្យសម្ងាត់។
3. ផ្អែកលើវិញ្ញាបនបត្រ: TLS ជាមួយវិញ្ញាបនបត្រផ្នែកអតិថិជន។

បញ្ហាគឺថា ឆ្នាំងសាកជាច្រើននៅតែស្ថិតនៅលើ Profile 1 ដែលធ្វើឱ្យពួកវាងាយរងគ្រោះដោយការវាយប្រហារដោយ man-in-the-middle (MITM) និងការគ្រប់គ្រងដោយគ្មានការអនុញ្ញាត។

៤.២ ជំហររឹងមាំនៃ ២.០.១

OCPP 2.0.1 តម្រូវ​ឱ្យ​មាន​ការ​ទំនាក់ទំនង​ដែល​មាន​សុវត្ថិភាព។ វា​បញ្ចូល​មុខងារ​សុវត្ថិភាព​កម្រិត​ខ្ពស់​ជា​មូលដ្ឋាន៖

• ការអាប់ដេតកម្មវិធីបង្កប់ដែលមានសុវត្ថិភាព៖ ការចុះហត្ថលេខា និងការផ្ទៀងផ្ទាត់រូបភាពកម្មវិធីបង្កប់ជាកាតព្វកិច្ច។
• ការកត់ត្រាសុវត្ថិភាព៖ កំណត់ហេតុលម្អិតសម្រាប់ព្រឹត្តិការណ៍ពាក់ព័ន្ធនឹងសុវត្ថិភាព (ឧ. ការប៉ុនប៉ងចូលបរាជ័យ ការផុតកំណត់វិញ្ញាបនបត្រ)។
• ការគ្រប់គ្រងវិញ្ញាបនបត្រ: សារស្តង់ដារសម្រាប់វិញ្ញាបនបត្រដែលបានបង្វិល និងបានធ្វើបច្ចុប្បន្នភាព (ដឹកនាំដោយ CSMS ឬដឹកនាំដោយស្ថានីយ៍)។
• TLS 1.2/1.3៖ គាំទ្រ​ស្តង់ដារ​អ៊ិនគ្រីប​ចុងក្រោយ​បំផុត។

សម្រាប់ប្រតិបត្តិករពាណិជ្ជកម្ម វាកាត់បន្ថយហានិភ័យនៃការសម្របសម្រួលបណ្តាញដ៏ធំ និងធានានូវការអនុលោមតាមបទប្បញ្ញត្តិសន្តិសុខតាមអ៊ីនធឺណិតដែលកំពុងលេចចេញសម្រាប់ឧបករណ៍ IoT។

ជំពូកទី 5: ការរួមបញ្ចូល ISO 15118: ឌុយ និងសាក និង V2G

អនាគតនៃការសាកថ្មរថយន្ត EV មិនមែនគ្រាន់តែជាការផ្លាស់ទីអេឡិចត្រុងនោះទេ វាគឺអំពីការផ្លាស់ប្តូរទិន្នន័យ និងថាមពលដ៏ឆ្លាតវៃ។ ISO 15118 គឺជាស្តង់ដារអន្តរជាតិសម្រាប់ការទំនាក់ទំនងរវាងយានយន្ត និងបណ្តាញអគ្គិសនី (V2G) ហើយការរួមបញ្ចូលរបស់វាជាមួយ OCPP គឺជាលក្ខណៈពិសេសនៃ 2.0.1។

៥.១ ភាពស្មុគស្មាញនៃការដោត និងសាកថ្ម

បច្ចេកវិទ្យា​ដោត​និង​សាក (PnC) អនុញ្ញាត​ឱ្យ​អ្នកបើកបរ​ដោត​រថយន្ត​ចូល​ក្នុង​ប្រព័ន្ធ ហើយ​ចាប់ផ្តើម​សាក​ដោយ​មិន​ចាំបាច់​ប្រើ​កម្មវិធី ឬ​កាត RFID។ នេះ​ទាមទារ​ឱ្យ​មាន​ហេដ្ឋារចនាសម្ព័ន្ធ​សោសាធារណៈ (PKI) ដ៏​ស្មុគស្មាញ​មួយ​ដែល​ពាក់ព័ន្ធ​នឹង​រថយន្ត ឆ្នាំងសាក ប្រតិបត្តិករ និង​ការិយាល័យ​ទូទាត់។

នៅក្នុង OCPP 1.6J ការគាំទ្រ PnC មិនមាននៅក្នុងពិធីការមូលដ្ឋានទេ។ អ្នកលក់ត្រូវអនុវត្តផ្នែកបន្ថែមផ្ទាល់ខ្លួន ដែលនាំឱ្យមានការបែកបាក់។ OCPP 2.0.1 ផ្តល់នូវ "បរិក្ខារបរិក្ខារ" សម្រាប់ PnC ដោយការគាំទ្រ៖

• ការដំឡើងវិញ្ញាបនបត្រការប្រគល់វិញ្ញាបនបត្រកិច្ចសន្យាពី CSMS ទៅ EV តាមរយៈ EVSE។
• ការអនុញ្ញាត៖ ដោយប្រើប្រាស់ e-Mobility ID (eMAID) ដែលទទួលបានពីវិញ្ញាបនបត្រយានយន្ត។
• ការទំនាក់ទំនងដែលបានអ៊ិនគ្រីបធានាថាទិន្នន័យវិក្កយបត្រដ៏រសើបដែលបានបញ្ជូនរវាងរថយន្ត និងបណ្តាញអគ្គិសនីត្រូវបានការពារ។

៥.២ ការសាកថ្មឆ្លាតវៃ និងការធ្វើឱ្យមានតុល្យភាពបន្ទុក

ខណៈពេលដែល 1.6J គាំទ្រការសាកថ្មឆ្លាតវៃជាមូលដ្ឋាន (ផ្ញើកំណត់ទម្រង់សាកថ្ម), 2.0.1 លើកកម្ពស់​ចំណុច​នេះ។ វាអនុញ្ញាតឱ្យ៖

• ការរួមបញ្ចូលសញ្ញាខាងក្រៅការឆ្លើយតបភ្លាមៗចំពោះប្រេកង់ក្រឡាចត្រង្គ ឬសញ្ញាតម្លៃលក់ដុំ។
• ការគ្រប់គ្រងបន្ទុកថាមវន្តការគ្រប់គ្រងកាន់តែលម្អិតលើការចែកចាយថាមពលនៅទូទាំងទីតាំងដែលមានឧបករណ៍ភ្ជាប់រាប់រយ។
• ការតភ្ជាប់ពីយានយន្តទៅក្រឡាចត្រង្គ (V2G)2.0.1 រួមបញ្ចូលវាលទិន្នន័យចាំបាច់ដើម្បីគាំទ្រដល់លំហូរថាមពលទ្វេទិស ដែលអនុញ្ញាតឱ្យរថយន្តអគ្គិសនីដើរតួជាធនធានថាមពលចែកចាយ (DERs) សម្រាប់បណ្តាញអគ្គិសនី។

៥.៣ ការបង្កើនប្រសិទ្ធភាព UI/UX របស់អ្នកប្រើប្រាស់

OCPP 2.0.1 គាំទ្រការបង្ហាញព័ត៌មានដោយផ្ទាល់នៅលើអេក្រង់ឆ្នាំងសាក ឬផ្ទាំងគ្រប់គ្រងរបស់យានយន្ត ដូចជា៖

• តម្លៃជាក់ស្តែងជារូបិយប័ណ្ណក្នុងស្រុក។
• ពេលវេលាប៉ាន់ស្មានដើម្បីឈានដល់ស្ថានភាពសាកថ្ម 80% (SoC)។
• ព័ត៌មានលម្អិតអំពីបង្កាន់ដៃនៅពេលបញ្ចប់។

ជំពូកទី 6: ការគ្រប់គ្រង និងការត្រួតពិនិត្យឧបករណ៍កម្រិតខ្ពស់

សម្រាប់ CPO តម្លៃ​ឆ្នាំងសាក​មិនមែន​គ្រាន់តែជា​តម្លៃទិញ​នោះទេ វា​គឺជា​តម្លៃសរុប​នៃ​កម្មសិទ្ធិ (TCO)។ ការថែទាំ និង​ពេលវេលា​រងចាំ គឺជា​កត្តា​ដែល​ធ្វើ​ឲ្យ​ខាតបង់​ប្រាក់ចំណេញ​ដ៏ធំបំផុត។ OCPP 2.0.1 ដោះស្រាយ​បញ្ហា​នេះ​តាមរយៈ​សមត្ថភាព​ត្រួតពិនិត្យ​ដ៏​ល្អ​ប្រសើរ។

៦.១ ការរាយការណ៍ដែលជំរុញដោយព្រឹត្តិការណ៍

នៅក្នុង 1.6J CSMS ជាធម្មតាត្រូវស្ទង់មតិស្ថានភាពឆ្នាំងសាក ឬរង់ចាំការជូនដំណឹងអំពីស្ថានភាពនៅក្នុង 2.0.1,ការត្រួតពិនិត្យព្រឹត្តិការណ៍ប្រព័ន្ធអនុញ្ញាតឱ្យ CSMS កំណត់កម្រិត។ ឧទាហរណ៍៖ “ជូនដំណឹងមកខ្ញុំតែប្រសិនបើសីតុណ្ហភាពខាងក្នុងលើសពី 70°C” ឬ “រាយការណ៍ប្រសិនបើវ៉ុលបញ្ចូលធ្លាក់ចុះក្រោម 200V”។ នេះកាត់បន្ថយចរាចរណ៍បណ្តាញ និងអនុញ្ញាតឱ្យមានការថែទាំជាមុន។

៦.២ ការដោះស្រាយប្រតិបត្តិការ៖ ព្រឹត្តិការណ៍ប្រតិបត្តិការ

ទិដ្ឋភាពមួយក្នុងចំណោមទិដ្ឋភាពដែលត្រូវបានរិះគន់បំផុតនៃ OCPP 1.6J គឺការដោះស្រាយប្រតិបត្តិការរបស់វា។ វគ្គមួយដែលពាក់ព័ន្ធនឹងចាប់ផ្តើមប្រតិបត្តិការនិងបញ្ឈប់ប្រតិបត្តិការសារ ប៉ុន្តែប្រសិនបើមានការរំខានដល់បណ្តាញកើតឡើង CSMS ជារឿយៗពិបាកក្នុងការផ្សះផ្សាទិន្នន័យវិក្កយបត្រ។

OCPP 2.0.1 ជំនួស​ទាំងនេះ​ដោយ​ប្រព័ន្ធ​ប្រតិបត្តិការ​តែមួយ​ដែល​រឹងមាំព្រឹត្តិការណ៍ប្រតិបត្តិការសារ។ សារនេះត្រូវបានប្រើដើម្បីរាយការណ៍ពីដំណាក់កាលវដ្តជីវិតទាំងអស់នៃប្រតិបត្តិការ (បានចាប់ផ្តើម ធ្វើបច្ចុប្បន្នភាព បញ្ចប់)។ វារួមបញ្ចូលតែមួយគត់។លេខសម្គាល់ប្រតិបត្តិការវានៅតែបន្តកើតមាន ទោះបីជាឆ្នាំងសាកចាប់ផ្តើមឡើងវិញក៏ដោយ ដែលធានាថាគ្មានទិន្នន័យសាកថ្មទេ ហើយដូច្នេះគ្មានប្រាក់ចំណូលត្រូវបានបាត់បង់នោះទេ។

៦.៣ ការធ្វើរោគវិនិច្ឆ័យ និងការដោះស្រាយបញ្ហាដែលប្រសើរឡើង

ទីទទួលបានកំណត់ហេតុនិងការជូនដំណឹងអំពីស្ថានភាពរោគវិនិច្ឆ័យសារនៅក្នុង 2.0.1 មានរចនាសម្ព័ន្ធច្រើនជាង។ CPOs អាចស្នើសុំប្រភេទកំណត់ហេតុជាក់លាក់ (សុវត្ថិភាព ការវិនិច្ឆ័យ អ្នកប្រើប្រាស់) និងបញ្ជាក់ជួរពេលវេលា។ នេះអនុញ្ញាតឱ្យក្រុមគាំទ្រពីចម្ងាយដោះស្រាយបញ្ហាដោយមិនចាំបាច់បញ្ជូនអ្នកបច្ចេកទេសទៅកាន់ទីតាំង ដែលកាត់បន្ថយ OpEx យ៉ាងសំខាន់។

ជំពូកទី 7: យន្តការធ្វើបច្ចុប្បន្នភាពកម្មវិធីបង្កប់៖ ភាពជឿជាក់ និងការបម្រុងទុក

ការអាប់ដេតកម្មវិធីបង្កប់គឺជាសរសៃឈាមនៃផ្នែករឹងដែលកំពុងវិវត្ត ប៉ុន្តែការអាប់ដេតបរាជ័យអាចធ្វើឱ្យឆ្នាំងសាកខូចបាន។

៧.១ ដំណើរការធ្វើបច្ចុប្បន្នភាព 1.6J

ក្នុង 1.6J,ធ្វើបច្ចុប្បន្នភាពកម្មវិធីបង្កប់ពាក្យបញ្ជាគឺសាមញ្ញណាស់។ ឆ្នាំងសាកនឹងទាញយករូបភាព ហើយព្យាយាមដំឡើងវា។ មិនមានយន្តការស្តង់ដារសម្រាប់ការអាប់ដេតពហុដំណាក់កាល ឬការត្រឡប់ក្រោយដែលបានផ្ទៀងផ្ទាត់នោះទេ។

៧.២ ការអាប់ដេតពហុជំហាន ២.០.១

OCPP 2.0.1 ណែនាំវដ្តជីវិតដ៏ស្មុគស្មាញជាងមុនសម្រាប់ការអាប់ដេតកម្មវិធីបង្កប់៖

1. ទាញយក៖ ឆ្នាំងសាកទាញយករូបភាព ហើយផ្ទៀងផ្ទាត់ checksum/signature របស់វា។
2. ការដំឡើង៖ ការអាប់ដេតត្រូវបានអនុវត្តចំពោះភាគថាសបន្ទាប់បន្សំ។
3. ការផ្ទៀងផ្ទាត់ប្រព័ន្ធពិនិត្យមើលថាតើកម្មវិធីបង្កប់ថ្មីចាប់ផ្ដើមបានត្រឹមត្រូវឬអត់។
4. ការធ្វើឱ្យសកម្ម៖ ភាគថាសចម្បងត្រូវបានប្តូរ។

ប្រសិនបើជំហានណាមួយបរាជ័យ ពិធីការនឹងកំណត់ពីរបៀបដែលឆ្នាំងសាកគួរតែត្រឡប់ទៅកំណែដែលមានស្ថេរភាពមុន ហើយរាយការណ៍លេខកូដបរាជ័យជាក់លាក់ទៅ CSMS។ កម្រិតនៃភាពជឿជាក់នេះមិនអាចចរចាបានទេសម្រាប់ការដាក់ពង្រាយពាណិជ្ជកម្មទ្រង់ទ្រាយធំ។

៧.៣ ការផ្ទៀងផ្ទាត់ហត្ថលេខា

ដើម្បីទប់ស្កាត់ជនល្មើសពីការផ្ទុកឡើងកម្មវិធីបង្កប់ដែលរងការគំរាមកំហែង 2.0.1 តម្រូវឱ្យប្រើប្រាស់ហត្ថលេខាឌីជីថល។ ឆ្នាំងសាកនឹងបដិសេធមិនប្រតិបត្តិកូដណាមួយដែលមិនបានចុះហត្ថលេខាដោយកូនសោឯកជនរបស់អ្នកផលិតទេ ដោយបន្ថែមស្រទាប់ការពារដ៏សំខាន់ប្រឆាំងនឹងការលួចចូលកម្រិតផ្នែករឹង។

ជំពូកទី 8: ភាពឯកជននៃទិន្នន័យ ការអនុលោមតាមបទប្បញ្ញត្តិ និង GDPR

ដោយសារការសាកថ្មរថយន្ត EV ក្លាយជាឧបករណ៍ប្រើប្រាស់ប្រចាំថ្ងៃ បរិមាណទិន្នន័យផ្ទាល់ខ្លួនដែលបានបង្កើតគឺមានចំនួនច្រើនគួរឱ្យភ្ញាក់ផ្អើល។ វគ្គសាកថ្មតែមួយអាចភ្ជាប់អត្តសញ្ញាណអ្នកប្រើប្រាស់ ទីតាំងយានយន្តរបស់ពួកគេ ទម្លាប់ធ្វើដំណើររបស់ពួកគេ និងព័ត៌មានហិរញ្ញវត្ថុរបស់ពួកគេ។

៨.១ ព័ត៌មាន​ដែល​អាច​កំណត់​អត្តសញ្ញាណ​ផ្ទាល់ខ្លួន (PII) នៅ​ក្នុង OCPP

នៅក្នុងបរិបទនៃបទប្បញ្ញត្តិការពារទិន្នន័យទូទៅ (GDPR) នៅអឺរ៉ុប និងច្បាប់ស្រដៀងគ្នាដូចជា CCPA នៅរដ្ឋកាលីហ្វ័រញ៉ា ចំណុចទិន្នន័យដូចជាស្លាក​លេខសម្គាល់(RFID) ឬអ៊ីវីស៊ីឌី(ឧបករណ៍កំណត់អត្តសញ្ញាណយានយន្ត) ត្រូវបានចាត់ទុកថាជា PII។

OCPP 2.0.1 ផ្តល់នូវការគ្រប់គ្រងកាន់តែប្រសើរសម្រាប់ការធ្វើឱ្យទិន្នន័យអនាមិក។ ឧទាហរណ៍ទិន្នន័យផ្ទាល់ខ្លួនវាលអនុញ្ញាតឱ្យប្រតិបត្តិកររក្សាទុកទិន្នន័យមេតាដោយមិនចាំបាច់បង្ហាញព័ត៌មានផ្ទាល់ខ្លួន (PII) ទៅកាន់កំណត់ហេតុពិធីការស្នូល។ លើសពីនេះ ទម្រង់សុវត្ថិភាពដែលបានធ្វើឱ្យប្រសើរឡើងធានាថាទិន្នន័យនេះត្រូវបានអ៊ិនគ្រីបទាំងក្នុងពេលដឹកជញ្ជូន និងពេលសម្រាក។

៨.២ សិទ្ធិត្រូវបានបំភ្លេចចោល និងលទ្ធភាពផ្ទេរទិន្នន័យ

លក្ខណៈ​ដែល​មាន​រចនាសម្ព័ន្ធ​នៃ​ម៉ូដែល​ឧបករណ៍ 2.0.1 ធ្វើ​ឱ្យ​វា​កាន់តែ​ងាយស្រួល​សម្រាប់​អ្នក​ផ្តល់​សេវា CSMS ក្នុង​ការ​អនុវត្ត​សំណើ "លុប​ទិន្នន័យ"។ នៅ​ក្នុង​ប្រព័ន្ធ 1.6J ការ​ស្វែងរក​ឧទាហរណ៍​ទាំងអស់​នៃ​លេខសម្គាល់​របស់​អ្នក​ប្រើប្រាស់​ឆ្លងកាត់​សោ​កំណត់​រចនាសម្ព័ន្ធ និង​កំណត់ហេតុ​ខុសៗ​គ្នា​គឺជា​សុបិន្ត​អាក្រក់​មួយ​ដោយ​ដៃ។ នៅ​ក្នុង 2.0.1 ការ​បំបែក​យ៉ាង​ច្បាស់លាស់​រវាង​ស្ថានភាព​ឧបករណ៍ និង​ទិន្នន័យ​ប្រតិបត្តិការ​អនុញ្ញាត​ឱ្យ​មាន​ស្ថាបត្យកម្ម​មូលដ្ឋាន​ទិន្នន័យ​កាន់តែ​ស្អាត។

៨.៣ ការអនុលោមតាមច្បាប់សន្តិសុខ IoT

តំបន់ជាច្រើនឥឡូវនេះកំពុងអនុម័តច្បាប់ដែលតម្រូវឱ្យឧបករណ៍ IoT មានពាក្យសម្ងាត់តែមួយគត់ និងយន្តការធ្វើបច្ចុប្បន្នភាពសុវត្ថិភាព។ TLS ចាំបាច់របស់ OCPP 2.0.1 និងកម្មវិធីបង្កប់ដែលបានចុះហត្ថលេខាមិនមែនគ្រាន់តែជាលក្ខណៈពិសេស "ល្អដែលមាន" នោះទេ - វាគឺជាតម្រូវការផ្លូវច្បាប់សម្រាប់ការលក់ផ្នែករឹងនៅក្នុងទីផ្សារដូចជារដ្ឋកាលីហ្វ័រញ៉ា និងចក្រភពអង់គ្លេស។

ជំពូកទី 9: ទស្សនៈរបស់អ្នកទិញ៖ TCO, ROI និងការធ្វើចំណាកស្រុកជាយុទ្ធសាស្ត្រ

សម្រាប់​ប្រតិបត្តិករ​សាក​ថ្ម​ពាណិជ្ជកម្ម ការសម្រេចចិត្ត​ប្រើប្រាស់​ចរន្ត 1.6J ឬ​ប្តូរ​ទៅ 2.0.1 គឺជា​ការសម្រេចចិត្ត​ផ្នែក​ហិរញ្ញវត្ថុ។

៩.១ ថ្លៃដើមនៃការអនុវត្ត

• OCPP 1.6Jមានតម្លៃថោកក្នុងការអនុវត្ត គាំទ្រយ៉ាងទូលំទូលាយដោយផ្នែករឹងដែលមានតម្លៃទាប ប៉ុន្តែមានការចំណាយលាក់កំបាំងខ្ពស់ក្នុងការថែទាំ និងហានិភ័យសុវត្ថិភាព។
• OCPP 2.0.1៖ តម្រូវឱ្យមានប្រព័ន្ធដំណើរការដែលមានថាមពលខ្លាំងជាងមុន និងអង្គចងចាំកាន់តែច្រើននៅក្នុង EVSE។ ថ្លៃដើមអភិវឌ្ឍន៍សម្រាប់ CSMS គឺខ្ពស់ជាងដោយសារតែភាពស្មុគស្មាញនៃពិធីការ។ ទោះជាយ៉ាងណាក៏ដោយ វាផ្តល់នូវការសន្សំសំចៃ OpEx យ៉ាងសំខាន់តាមរយៈការគ្រប់គ្រងពីចម្ងាយ និងភាពជឿជាក់កាន់តែប្រសើរ។

៩.២ ទេវកថា "ការធ្វើឱ្យប្រសើរឡើងដោយរលូន"

គេតែងតែនិយាយថា ឆ្នាំងសាក 1.6J អាចត្រូវបានធ្វើឱ្យប្រសើរឡើងទៅ 2.0.1 តាមរយៈកម្មវិធី។ តាមពិតទៅ នេះកម្រជាការពិតណាស់។ តម្រូវការអង្គចងចាំ និង CPU សម្រាប់ 2.0.1 (ជាពិសេសការដោះស្រាយវិញ្ញាបនបត្រ TLS និងការវិភាគ JSON ស្មុគស្មាញនៃម៉ូដែលឧបករណ៍) ជារឿយៗលើសពីសមត្ថភាពរបស់ឧបករណ៍បញ្ជា 1.6J ចាស់ៗ។

៩.៣ ផ្លូវ​ធ្វើ​ចំណាកស្រុក​ជា​យុទ្ធសាស្ត្រ

នាយកប្រតិបត្តិការ (CPOs) គួរពិចារណាវិធីសាស្រ្ត “បណ្តាញចម្រុះ”៖

1. គេហទំព័រចាស់ៗបន្តដំណើរការ 1.6J សម្រាប់ឆ្នាំងសាក AC ថាមពលទាបដែលមានស្រាប់។
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) ដែលអនុញ្ញាតឱ្យរថយន្តអគ្គិសនីផ្តល់ថាមពលដល់ផ្ទះក្នុងអំឡុងពេលដាច់ចរន្តអគ្គិសនី ឬកាត់បន្ថយតម្រូវការកំពូលសម្រាប់អគារពាណិជ្ជកម្ម។

១០.២ ការគាំទ្រសម្រាប់ការសាកថ្មឥតខ្សែ

នៅពេលដែលយានយន្តស្វ័យប្រវត្តិ (AVs) លេចចេញមក ការដោតដោយដៃនឹងក្លាយទៅជាហួសសម័យ។ OCPP 2.1 នឹងរួមបញ្ចូលសារស្តង់ដារសម្រាប់ការសាកថ្មដោយអាំងឌុចស្យុង (ឥតខ្សែ) ការគ្រប់គ្រងការតម្រឹម និងការផ្ទេរថាមពលដោយគ្មានអន្តរាគមន៍ពីមនុស្ស។

១០.៣ ការរួមបញ្ចូលជាមួយទីក្រុងឆ្លាតវៃ

ការធ្វើ​កំណែទម្រង់​នាពេលអនាគត​ទំនងជា​នឹងឃើញ​ការធ្វើសមាហរណកម្ម​កាន់តែស៊ីជម្រៅ​ជាមួយប្រព័ន្ធគ្រប់គ្រងចរាចរណ៍ និងការព្យាករណ៍ថាមពលកកើតឡើងវិញ។ ឆ្នាំងសាក​នឹងអាច «ដេញថ្លៃ» សម្រាប់ថាមពលនៅក្នុងទីផ្សារថាមពលពេលវេលាជាក់ស្តែង ដោយប្រែក្លាយបណ្តាញសាកថ្មទៅជារោងចក្រថាមពលនិម្មិតដ៏ធំ (VPPs)។

ឧបសម្ព័ន្ធបច្ចេកទេស៖ ស្វែងយល់ស៊ីជម្រៅអំពីការប្រៀបធៀបសារ

ដើម្បីផ្តល់នូវជម្រៅបច្ចេកទេសចុងក្រោយ ឥឡូវនេះយើងនឹងវិភាគលំដាប់សារជាក់លាក់ និងភាពខុសគ្នានៃស៊ុមរវាងកំណែទាំងពីរ។

ក.១ លំហូរនៃការអនុញ្ញាត

នៅក្នុង 1.6J ការអនុញ្ញាតគឺជាការឆ្លើយតបគោលពីរ "ទទួលយក" ឬ "រារាំង"។

1.6J អនុញ្ញាតការឆ្លើយតប៖«json [3, "123456", { "idTagInfo": { "ស្ថានភាព": "បានទទួលយក", "ផុតកំណត់": "2026-12-31T23:59:59Z" } }]«

នៅក្នុង 2.0.1 ការឆ្លើយតបរួមមានបរិបទបន្ថែមទៀត ដូចជាលេខសម្គាល់ប្រភេទ និងព័ត៌មានបន្ថែមសម្រាប់ចំណុចប្រទាក់អ្នកប្រើប្រាស់។

2.0.1 អនុញ្ញាតការឆ្លើយតប៖«json [3, "987654", { "idTokenInfo": { "status": "បានទទួលយក", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "សូមស្វាគមន៍មកវិញ John! សមតុល្យរបស់អ្នកគឺ $45.00" } } }]«

ក.២ ការគ្រប់គ្រងចង្វាក់បេះដូង និងការតភ្ជាប់

OCPP 2.0.1 ធ្វើឱ្យប្រសើរឡើងនូវរបៀបដែលស្ថានីយ៍បញ្ជាក់ថាវា "មានជីវិត"។ ក្នុង 1.6J ប្រសិនបើចង្វាក់បេះដូងប្រសិនបើបរាជ័យ ស្ថានីយ៍ជារឿយៗគ្រាន់តែព្យាយាមម្តងទៀត។ នៅក្នុង 2.0.1 ស្ថានីយ៍អាចប្រើជូនដំណឹងព្រឹត្តិការណ៍យន្តការ​ដើម្បីរាយការណ៍ថាការតភ្ជាប់របស់វាទៅកាន់ backend បន្ទាប់បន្សំត្រូវបានបាត់បង់ ខណៈពេលដែលនៅតែរក្សាចង្វាក់បេះដូងជាមួយ primary។

ក.៣ តារាងទិន្នន័យមេតាលម្អិត

សេចក្តីសន្និដ្ឋាន

ការផ្លាស់ប្តូរពី OCPP 1.6J ទៅ 2.0.1 មិនមែនគ្រាន់តែជាការអាប់ដេតកម្មវិធីនោះទេ វាគឺជាការវិវត្តជាមូលដ្ឋាននៃប្រព័ន្ធអេកូឡូស៊ីចល័តភាពអគ្គិសនី។ សម្រាប់ប្រតិបត្តិករពាណិជ្ជកម្ម 1.6J តំណាងឱ្យអតីតកាលដែលអាចទុកចិត្តបាន ខណៈពេលដែល 2.0.1 តំណាងឱ្យអនាគតដែលអាចធ្វើមាត្រដ្ឋានបាន មានសុវត្ថិភាព និងឆ្លាតវៃ។

ការជ្រើសរើស 2.0.1 នៅថ្ងៃនេះ គឺជាការវិនិយោគលើអាយុកាលប្រើប្រាស់បានយូរ។ វាធានាថា ផ្នែករឹងរបស់អ្នកនឹងឆបគ្នាជាមួយរថយន្តអគ្គិសនីជំនាន់ក្រោយ អនុលោមតាមបទប្បញ្ញត្តិសន្តិសុខតាមអ៊ីនធឺណិតដ៏តឹងរ៉ឹង និងត្រៀមខ្លួនសម្រាប់ឱកាសដ៏ចំណេញនៃ V2G និងការរួមបញ្ចូលបណ្តាញអគ្គិសនីឆ្លាតវៃ។ នៅពេលដែលទីផ្សារមានការបង្រួបបង្រួម ប្រតិបត្តិករដែលមានជង់ពិធីការដ៏រឹងមាំ និងអាចបត់បែនបានបំផុតនឹងក្លាយជាអ្នកដែលនាំមុខគេ។

ជំពូកទី 11: ស្វែងយល់ស៊ីជម្រៅ៖ ការវិភាគលំហូរសារ និងដ្យាក្រាមលំដាប់

នៅក្នុងជំពូកនេះ យើងវិភាគលំដាប់អន្តរកម្មរវាង EVSE និង CSMS ដើម្បីបង្ហាញពីភាពខុសគ្នានៃប្រតិបត្តិការរវាង 1.6J និង 2.0.1។

១១.១ លំដាប់ចាប់ផ្ដើម និងការកំណត់រចនាសម្ព័ន្ធ

នៅពេលដែលឆ្នាំងសាកភ្ជាប់ទៅបណ្តាញជាលើកដំបូង វាត្រូវតែកំណត់អត្តសញ្ញាណខ្លួនវា និងធ្វើសមកាលកម្មការកំណត់រចនាសម្ព័ន្ធរបស់វា។

លំហូរ OCPP 1.6J៖

1. ការតភ្ជាប់ WebSocketបង្កើតឡើងនៅលើច្រក 80 ឬ 443។
2. ការជូនដំណឹងអំពីការចាប់ផ្ដើមស្ថានីយ៍ផ្ញើអ្នកលក់ ម៉ូដែល និងស៊េរី។
3. ទទួលបានការកំណត់រចនាសម្ព័ន្ធCSMS ស្នើសុំ​សោ​ទាំងអស់​ដើម្បី​ពិនិត្យ​ស្ថានភាព​បច្ចុប្បន្ន។
4. ការផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធCSMS ធ្វើបច្ចុប្បន្នភាពសោជាក់លាក់ (ឧ.ចន្លោះពេលចង្វាក់បេះដូង).
5. ការជូនដំណឹងអំពីស្ថានភាព: របាយការណ៍ស្ថានីយ៍ "អាចប្រើបាន"។

លំហូរ OCPP 2.0.1៖

1. ការចាប់ដៃ TLS ប្រកបដោយសុវត្ថិភាព៖ ការផ្លាស់ប្តូរវិញ្ញាបនបត្រជាកាតព្វកិច្ច។
2. ការជូនដំណឹងអំពីការចាប់ផ្ដើម: រួមបញ្ចូលហេតុផល(ឧ.បង្កើនថាមពល).
3. ទទួលបានរបាយការណ៍មូលដ្ឋានជំនួស​ឲ្យ​ការ​ស្នើសុំ​សោ​ទាំងអស់ CSMS ស្នើសុំ "របាយការណ៍​មូលដ្ឋាន" ដែល​ផ្តល់​ឋានានុក្រម​ពេញលេញ​នៃ​ម៉ូដែល​ឧបករណ៍។
4. កំណត់អថេរCSMS ធ្វើបច្ចុប្បន្នភាពអថេរ។ ចំណាំថា 2.0.1 អនុញ្ញាតឱ្យមានការអាប់ដេតអាតូមិច—ការកំណត់អថេរច្រើនក្នុងសារមួយ និងធានាថាអថេរទាំងអស់ទទួលបានជោគជ័យ ឬគ្មានអថេរណាមួយទទួលបានជោគជ័យ។
5. ជូនដំណឹងព្រឹត្តិការណ៍ស្ថានីយរាយការណ៍ពីស្ថានភាពសមាសភាគដំបូង។

១១.២ ការចរចាសាកថ្មឆ្លាតវៃ

ការសាកថ្មឆ្លាតវៃគឺជាកន្លែងដែល 2.0.1 ពិតជាលេចធ្លោ ជាពិសេសនៅពេលដោះស្រាយទម្រង់សាកថ្មច្រើន។

ក្នុង 1.6J CSMS ផ្ញើកំណត់ទម្រង់សាកថ្មដែលកំណត់កម្រិតជង់ និងកាលវិភាគ។ ប្រសិនបើស្ថានីយ៍មានឧបករណ៍ភ្ជាប់ច្រើន ការគ្រប់គ្រងទម្រង់ច្រើនតែមិនច្បាស់លាស់។

នៅក្នុង 2.0.1,កំណត់ទម្រង់សាកថ្មត្រូវបានភ្ជាប់យ៉ាងច្បាស់លាស់ទៅនឹងគោលបំណង​នៃ​ការ​សាក​ថ្ម.

• ទម្រង់ស្ថានីយសាកថ្មអតិបរមា: កំណត់ការទទួលទានរបស់ស្ថានីយ៍ទាំងមូល។
• ទម្រង់ TXDefaultលំនាំដើមសម្រាប់ប្រតិបត្តិការថ្មីណាមួយ។
• ប្រវត្តិរូប TXជាក់លាក់ចំពោះប្រតិបត្តិការដែលកំពុងដំណើរការ។

លើសពីនេះ 2.0.1 គាំទ្រទទួលបានកម្រិតសាកថ្ម Stackសារ ដែលអនុញ្ញាតឱ្យ CSMS មើលថាតើទម្រង់ណាខ្លះដែលកំពុងសកម្មបច្ចុប្បន្ន និងរបៀបដែលពួកវាត្រូវបានផ្តល់អាទិភាពដោយកម្មវិធីកំណត់ពេលផ្ទៃក្នុងរបស់ EVSE។

១១.៣ ការ​បញ្ជា​ និង​ការ​បញ្ជា​ពីចម្ងាយ

ការបញ្ជាពីចម្ងាយដូចជាប្រតិបត្តិការចាប់ផ្តើមពីចម្ងាយ(1.6J) ត្រូវបានជំនួសដោយស្នើសុំចាប់ផ្តើមប្រតិបត្តិការ(២.០.១)។ ភាពខុសគ្នាសំខាន់គឺស្ថិតនៅក្នុង payload។ នៅក្នុង ២.០.១ CSMS អាចរួមបញ្ចូលទម្រង់សាកថ្មដោយផ្ទាល់នៅក្នុងសំណើចាប់ផ្តើម។ នេះមានន័យថា រថយន្តអាចចាប់ផ្តើមសាកថ្មនៅកម្រិតថាមពលត្រឹមត្រូវភ្លាមៗ ដោយមិនចាំបាច់រង់ចាំសារទីពីរ ដែលកាត់បន្ថយភាពយឺតយ៉ាវ និងធ្វើអោយប្រសើរឡើងនូវស្ថេរភាពនៃបណ្តាញ។

ជំពូកទី 12: គ្រោងការណ៍ JSON កម្រិតទាប និងការប្រៀបធៀបវាល

សម្រាប់អ្នកអភិវឌ្ឍន៍ និងអ្នករួមបញ្ចូលប្រព័ន្ធ ការផ្លាស់ប្តូរគ្រោងការណ៍គឺជាផ្នែកដែលប្រើប្រាស់កម្លាំងពលកម្មច្រើនបំផុតនៃការផ្លាស់ប្តូរ។

១២.១ ប្រភេទដែលបានរាប់បញ្ចូល (Enums)

OCPP 2.0.1 ពង្រីកចំនួន Enums ស្តង់ដារយ៉ាងច្រើន ដោយកាត់បន្ថយតម្រូវការសម្រាប់លេខកូដស្ថានភាព "ផ្ទាល់ខ្លួន" ដែលរំខានដល់ការអនុវត្ត 1.6J។

• ហេតុផល Enums: ឆ្មាំយាម, កំណត់ឡើងវិញតាមកាលវិភាគ, កំណត់ឡើងវិញពីចម្ងាយ, ការបាត់បង់ថាមពល.
• លេខសម្គាល់ស្ថានភាព: កាន់កាប់, បានកក់ទុក, មិនអាចប្រើបាន, មានកំហុស2.0.1 បន្ថែមមាន, កាន់កាប់, បានកក់ទុក, មិនអាចប្រើបាន, មានកំហុសប៉ុន្តែជាមួយស្ថានភាពរងសម្រាប់ព័ត៌មានលម្អិតបន្ថែម។

១២.២ ប្រភេទទិន្នន័យ និងឯកតា

OCPP 2.0.1 ធ្វើឱ្យការប្រើប្រាស់ឯកតាស្តង់ដារ (SI) មានលក្ខណៈជាផ្លូវការ។ កន្លែងដែល 1.6J ជួនកាលទុកភាពត្រឹមត្រូវនៃលេខទសភាគមិនបានកំណត់ 2.0.1 ប្រើទសភាគប្រភេទសម្រាប់តម្លៃថាមពល និងថាមពល ដោយធានាបាននូវការគិតថ្លៃស្របគ្នានៅទូទាំងផ្នែករឹងរបស់អ្នកលក់ផ្សេងៗគ្នា។

ជំពូកទី 13: ការសិក្សាករណី៖ ការធ្វើចំណាកស្រុក CPO សកលពី 1.6J ទៅ 2.0.1

ចូរយើងពិនិត្យមើលសេណារីយ៉ូសម្មតិកម្មនៃ “MegaCharge” ដែលជា CPO ដែលមានចំណុចសាកចំនួន 10,000។

១៣.១ ដំណាក់កាលទី ១៖ ការធ្វើសវនកម្ម

MegaCharge បានរកឃើញថា 40% នៃកងនាវារថយន្ត 1.6J របស់ពួកគេមិនគាំទ្រ TLS 1.2 ទេ។ នេះមានន័យថា ឆ្នាំងសាកទាំងនោះមិនមានសិទ្ធិទទួលបានកិច្ចសន្យារបស់រដ្ឋាភិបាលនាពេលខាងមុខទេ។

១៣.២ ដំណាក់កាលទី ២៖ ការធ្វើឱ្យប្រសើរឡើង CSMS

ជំនួស​ឲ្យ​ការ​បង្កើត CSMS ថ្មី MegaCharge បាន​អនុវត្ត “ស្រទាប់​បកប្រែ OCPP”។ ស្រទាប់​នេះ​បាន​ដោះស្រាយ​ការ​តភ្ជាប់ 1.6J សម្រាប់​ផ្នែករឹង​ចាស់ និង 2.0.1 សម្រាប់​ផ្នែករឹង​ថ្មី ប៉ុន្តែ​បាន​បង្ហាញ API បង្រួបបង្រួម​ទៅ​កម្មវិធី​ទូរស័ព្ទ និង​ម៉ាស៊ីន​គិត​ប្រាក់​របស់​ពួកគេ។

១៣.៣ ដំណាក់កាលទី ៣៖ ការជំនួសផ្នែករឹង

សម្រាប់​ទីតាំង​ដែល​មាន​ចរាចរណ៍​ច្រើន MegaCharge បាន​ជំនួស​ឆ្នាំង​សាក 1.6J ជាមួយ​នឹង​ឆ្នាំង​សាក​លឿន DC ដែល​អនុលោម​តាម 2.0.1។ លទ្ធផល​គឺ​ការ​ថយ​ចុះ 15% នៃ​វគ្គ "បរាជ័យ​ក្នុង​ការ​ចាប់ផ្តើម" ដែល​ជា​ចម្បង​ដោយសារ​តែ​ការ​ប្រើប្រាស់​កាន់តែ​រឹងមាំ។ព្រឹត្តិការណ៍ប្រតិបត្តិការការដោះស្រាយនៅក្នុង 2.0.1។

១៣.៤ ការវិភាគ ROI

ការវិនិយោគដំបូងគឺ 2 លានដុល្លារ។ ទោះជាយ៉ាងណាក៏ដោយ ការហៅទូរស័ព្ទថែទាំដែលបានកាត់បន្ថយ (អរគុណចំពោះការធ្វើរោគវិនិច្ឆ័យរបស់ Device Model) បានសន្សំប្រាក់បាន 400,000 ដុល្លារក្នុងមួយឆ្នាំ។ លើសពីនេះ សមត្ថភាពក្នុងការចូលរួមក្នុងទីផ្សារឆ្លើយតបប្រេកង់ V2G បានបង្កើតប្រាក់ចំណូលប្រចាំឆ្នាំបន្ថែមចំនួន 200,000 ដុល្លារ។ រយៈពេលសងត្រលប់វិញគឺប្រហែល 3.3 ឆ្នាំ។

ជំពូកទី 14៖ បញ្ជីត្រួតពិនិត្យចុងក្រោយរបស់អ្នកទិញសម្រាប់ OCPP 2.0.1 ការផ្គត់ផ្គង់

នៅពេលវាយតម្លៃផ្នែករឹង ឬកម្មវិធីថ្មី សូមប្រើបញ្ជីត្រួតពិនិត្យនេះដើម្បីធានាបាននូវការអនុលោមតាមច្បាប់ពិតប្រាកដ៖

១៤.១ តម្រូវការផ្នែករឹង (EVSE)

• [ ]ការគាំទ្រទម្រង់សុវត្ថិភាព 3តើវាគាំទ្រការគ្រប់គ្រងវិញ្ញាបនបត្រផ្នែកអតិថិជនដែរឬទេ?
• [ ]ប្រព័ន្ធដំណើរការ Dual-Coreតើ​មាន​កន្លែង​គ្រប់គ្រាន់​សម្រាប់​ការអ៊ិនគ្រីប TLS និង​ការ​វិភាគ JSON ដែរ​ឬទេ?
• [ ]ធាតុសុវត្ថិភាព (SE)តើក្តារមានឫសគល់ផ្នែករឹងនៃការទុកចិត្តសម្រាប់រក្សាទុកកូនសោដែរឬទេ?
• [ ]ISO 15118-2/20 រួចរាល់ហើយតើឧបករណ៍បញ្ជាអាចដោះស្រាយការទំនាក់ទំនងកម្រិតខ្ពស់ដែលត្រូវការសម្រាប់ PnC បានទេ?
• [ ]សមត្ថភាពបង្ហាញ: តើផ្នែករឹងគាំទ្រការបង្ហាញព័ត៌មានតម្លៃ/ស្ថានភាពតាមរយៈ OCPP ដែរឬទេ?ការផ្ទេរទិន្នន័យឬសារដើម?

១៤.២ តម្រូវការ​កម្មវិធី (CSMS)

• [ ]ការមើលឃើញគំរូឧបករណ៍តើផ្ទាំងគ្រប់គ្រងអាចបង្ហាញទិដ្ឋភាពឋានានុក្រមនៃឆ្នាំងសាកបានទេ?
• [ ]ការរួមបញ្ចូលអាជ្ញាធរវិញ្ញាបនបត្រ (CA)តើ CSMS អាចចេញ និងបង្វិលវិញ្ញាបនបត្រដោយស្វ័យប្រវត្តិបានទេ?
• [ ]ការផ្សះផ្សាប្រតិបត្តិការតើប្រព័ន្ធដោះស្រាយប្រតិបត្តិការ "ព្យួរ" ពីឆ្នាំងសាកចាស់ 1.6J យ៉ាងដូចម្តេច?
• [ ]ម៉ាស៊ីនសាកថ្មឆ្លាតវៃតើវាគាំទ្រតក្កវិជ្ជាកម្រិតជង់កម្រិតខ្ពស់នៃ 2.0.1 ដែរឬទេ?
• [ ]សមត្ថភាពធ្វើមាត្រដ្ឋានតើឧបករណ៍ដោះស្រាយ WebSocket អាចគ្រប់គ្រងការតភ្ជាប់ TLS អចិន្ត្រៃយ៍ជាង 50,000+ ក្នុងពេលដំណាលគ្នាបានទេ?

ជំពូកទី 15: ការដោះស្រាយបញ្ហាទូទៅនៃការអនុវត្ត OCPP

ទោះបីជាមានស្តង់ដារក៏ដោយ ការអនុវត្តក៏មានភាពខុសប្លែកគ្នាដែរ។ ខាងក្រោមនេះគឺជា "កំហុសឆ្គង" ទូទៅបំផុត។

១៥.១ ការអស់ពេលរបស់ WebSocket

ជញ្ជាំងភ្លើងបណ្តាញជាច្រើនបិទការតភ្ជាប់ TCP ដែលអសកម្ម។ ប្រសិនបើចន្លោះពេលចង្វាក់បេះដូងត្រូវបានកំណត់ខ្ពស់ពេក ឆ្នាំងសាកអាចត្រូវបានផ្តាច់។

• ដំណោះស្រាយ៖ ធានាចន្លោះពេលចង្វាក់បេះដូងទាបជាងរយៈពេលអស់ពេលរបស់ជញ្ជាំងភ្លើង (ជាធម្មតា 60-120 វិនាទី)។

១៥.២ បញ្ហាខ្សែសង្វាក់វិញ្ញាបនបត្រ

ការបរាជ័យទូទៅមួយនៅក្នុង 2.0.1 គឺកំហុស "វិញ្ញាបនបត្រមិនគួរឱ្យទុកចិត្ត"។ ជាធម្មតាវាកើតឡើងនៅពេលដែលឆ្នាំងសាកមិនមាន Root CA របស់ CSMS ដែលបានដំឡើង។

• ដំណោះស្រាយ: ប្រើដំឡើងវិញ្ញាបនបត្រសារក្នុងអំឡុងពេលដាក់ឱ្យដំណើរការ ដើម្បីធានាថាខ្សែសង្វាក់ទំនុកចិត្តត្រូវបានបញ្ចប់។

ទំហំ​បន្ទុក JSON ១៥.៣

សារ 2.0.1 មួយចំនួន (ដូចជាទទួលបានរបាយការណ៍មូលដ្ឋាន) អាចមានទំហំធំខ្លាំង។ ប្រសិនបើសតិបណ្ដោះអាសន្នរបស់ឆ្នាំងសាកតូចពេក វានឹងទម្លាក់សារ។

• ដំណោះស្រាយ៖ ពិនិត្យមើលទំហំសារអតិបរមាអថេរនៅក្នុងម៉ូដែលឧបករណ៍ ហើយធានាថា CSMS គោរពដែនកំណត់នេះ។

ជំពូកទី ១៦៖ ទេសភាពបទប្បញ្ញត្តិក្នុងតំបន់ និងអាណត្តិពិធីសារ

ការផ្លាស់ប្តូរទៅ OCPP 2.0.1 មិនត្រឹមតែត្រូវបានជំរុញដោយបច្ចេកវិទ្យាប៉ុណ្ណោះទេ វាកាន់តែក្លាយជាបញ្ហាច្បាប់កាន់តែខ្លាំងឡើង។

១៦.១ សហភាពអឺរ៉ុប (AFIR)

បទប្បញ្ញត្តិហេដ្ឋារចនាសម្ព័ន្ធឥន្ធនៈជំនួស (AFIR) នៅក្នុងសហភាពអឺរ៉ុបតម្រូវឱ្យគោរពតាមតម្លាភាពតម្លៃ និងអន្តរប្រតិបត្តិការ។ ខណៈពេលដែលវាមិនបានដាក់ឈ្មោះ OCPP 2.0.1 យ៉ាងច្បាស់លាស់ តម្រូវការសម្រាប់ "ការចែករំលែកទិន្នន័យជាក់ស្តែង" និង "ការសាកថ្មឆ្លាតវៃ" ធ្វើឱ្យ 2.0.1 ក្លាយជាស្តង់ដារតែមួយគត់ដែលអាចអនុវត្តបានសម្រាប់ហេដ្ឋារចនាសម្ព័ន្ធសាធារណៈថ្មី។

១៦.២ អាមេរិកខាងជើង (NEVI)

នៅសហរដ្ឋអាមេរិក កម្មវិធីរូបមន្តហេដ្ឋារចនាសម្ព័ន្ធយានយន្តអគ្គិសនីជាតិ (NEVI) តម្រូវឱ្យឆ្នាំងសាកត្រូវតែ "អាចធ្វើអន្តរកម្មបាន"។ រដ្ឋដូចជារដ្ឋកាលីហ្វ័រញ៉ាកំពុងរីកចម្រើនទៅមុខទៀត ដោយគណៈកម្មការថាមពលកាលីហ្វ័រញ៉ា (CEC) ជំរុញឱ្យមានការគាំទ្រ ISO 15118 ដែលដូចដែលយើងបានពិភាក្សារួចមកហើយ ត្រូវបានអនុវត្តយ៉ាងល្អបំផុតតាមរយៈ OCPP 2.0.1។

១៦.៣ ប្រទេសចិន និងអាស៊ីប៉ាស៊ីហ្វិក

ខណៈពេលដែលប្រទេសចិនមានស្តង់ដារផ្ទាល់ខ្លួន (GB/T) ក្រុមហ៊ុនផលិតដែលផ្តោតលើការនាំចេញត្រូវបានវិនិយោគយ៉ាងខ្លាំងនៅក្នុង OCPP 2.0.1។ នៅក្នុងទីផ្សារដូចជាប្រទេសអូស្ត្រាលី និងសិង្ហបុរី ការដេញថ្លៃរបស់រដ្ឋាភិបាលសម្រាប់បណ្តាញសាកថ្មសាធារណៈឥឡូវនេះស្ទើរតែទាំងស្រុងកំពុងបញ្ជាក់ OCPP 2.0.1 ជាមួយនឹងទម្រង់សុវត្ថិភាព 3។

ជំពូកទី ១៧៖ កូដ​សង្ខេប​សម្រាប់​ការអនុវត្ត៖ «ចំណុច​សំខាន់ៗ»

ដើម្បីជួយអ្នកអភិវឌ្ឍន៍ យើងផ្តល់ជូននូវការតំណាង JSON គោលគំនិតសម្រាប់កិច្ចការស្មុគស្មាញ 2.0.1។

១៧.១ លំហូរនៃការបង្វិលវិញ្ញាបនបត្រ

នៅពេលដែលវិញ្ញាបនបត្រជិតផុតកំណត់ CSMS ត្រូវតែបង្កឱ្យមានការបង្វិល។

១. CSMS ផ្ញើវិញ្ញាបនបត្របានចុះហត្ថលេខា:«json [2, "CERT-01", "CertificateSigned", { "certificateChain": "-----ចាប់ផ្តើម វិញ្ញាបនបត្រ-----\n...\n-----បញ្ចប់ វិញ្ញាបនបត្រ-----", "certificateType": "V2G" }]«

2. ស្ថានីយ៍ឆ្លើយតបបានទទួលយក:«json [3, "CERT-01", { "ស្ថានភាព": "បានទទួលយក" }]«

៣. ស្ថានីយ៍ផ្ញើការជូនដំណឹងអំពីព្រឹត្តិការណ៍សុវត្ថិភាព:«json [2, "EVT-99", "ការជូនដំណឹងអំពីព្រឹត្តិការណ៍សុវត្ថិភាព", { "ប្រភេទ": "វិញ្ញាបនបត្របង្វិល", "ត្រាពេលវេលា": "2026-08-09T10:00:00Z" }]«

១៧.២ ការកំណត់ទម្រង់សាកថ្មដែលឆ្លើយតបទៅនឹងបណ្តាញអគ្គិសនី

ស្រមៃថាប្រតិបត្តិករបណ្តាញអគ្គិសនីត្រូវកាត់បន្ថយថាមពលនៅទូទាំងបណ្តាញ។

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 (ប្រព័ន្ធគ្រប់គ្រងស្ថានីយ៍សាកថ្ម)៖ វេទិកាពពកខាងក្រោយដែលគ្រប់គ្រងឆ្នាំងសាក។
• EVSE (ឧបករណ៍ផ្គត់ផ្គង់យានយន្តអគ្គិសនី)ស្ថានីយ​សាក​ថ្ម​រូបវន្ត។
• OCPP (ពិធីការចំណុចសាកថ្មបើកចំហ): ភាសាដែលពួកគេនិយាយ។
• OCA (សម្ព័ន្ធភាព​ទទួលបន្ទុក​បើកចំហ): អង្គការដែលសរសេរភាសា។
• អាយអេសអូ ១៥១១៨ពិធីការរវាងរថយន្ត និងឆ្នាំងសាក។
• PnC (ដោត និងសាកថ្ម)បទពិសោធន៍អ្នកប្រើប្រាស់ដែលត្រូវបានបើកដោយ ISO 15118 និង OCPP 2.0.1។
• V2G (យានយន្តទៅក្រឡាចត្រង្គ): បញ្ជូនថាមពលពីរថយន្តត្រឡប់ទៅបណ្តាញអគ្គិសនីវិញ។
• V2X (យានយន្ត​ទៅ​អ្វីៗ​គ្រប់យ៉ាង)ពាក្យ​ទូទៅ​សម្រាប់ V2G, V2H និង V2B។
• TLS (សុវត្ថិភាពស្រទាប់ដឹកជញ្ជូន)៖ ការអ៊ិនគ្រីបដែលរក្សាទិន្នន័យឱ្យមានសុវត្ថិភាព។
• PKI (ហេដ្ឋារចនាសម្ព័ន្ធសោសាធារណៈ)ប្រព័ន្ធ​វិញ្ញាបនបត្រ​ឌីជីថល​ដែល​ប្រើ​សម្រាប់​សុវត្ថិភាព។
• JSON (សញ្ញាណវត្ថុ JavaScript)៖ ទម្រង់នៃសារ។
• WebSocketការតភ្ជាប់អចិន្ត្រៃយ៍គឺជា "បំពង់" ដែលសារហូរកាត់។
• ម៉ូដែលឧបករណ៍វិធីសាស្ត្រឋានានុក្រម 2.0.1 ពិពណ៌នាអំពីផ្នែករឹង។
• សមាសភាគ: បំណែកនៃផ្នែករឹង (ឧ. ឧបករណ៍ភ្ជាប់)។
• អថេរ: លក្ខណសម្បត្តិ​របស់​សមាសភាគ​មួយ (ឧ. ស្ថានភាព)។
• គុណលក្ខណៈទិន្នន័យមេតាអំពីអថេរមួយ (ឧ. តម្លៃ ភាពអាចប្រែប្រួលបាន)។
• ព្រឹត្តិការណ៍ប្រតិបត្តិការសារ​រួម​សម្រាប់​ទិន្នន័យ​វគ្គ​ទាំងអស់​ក្នុង 2.0.1។
• ចង្វាក់បេះដូងសញ្ញា "ខ្ញុំនៅរស់" តាមកាលកំណត់។
• ការជូនដំណឹងអំពីការចាប់ផ្ដើមសញ្ញា “សួស្តី ខ្ញុំមកដល់ហើយ” នៅពេលដែលឆ្នាំងសាកចាប់ផ្តើមដំណើរការ។
• ការផ្ទេរទិន្នន័យ: សារ "catch-all" សម្រាប់ផ្នែកបន្ថែមជាក់លាក់របស់អ្នកលក់ (ប្រើដោយប្រុងប្រយ័ត្ន!)។

គំនិតចុងក្រោយ៖ ការរុករកយុគសម័យពហុពិធីការ

ក្នុងនាមជាអ្នកទិញ ឬប្រតិបត្តិករ ចំណុចសំខាន់បំផុតគឺថា យើងកំពុងចូលទៅក្នុងសម័យកាលពហុពិធីការសម្រាប់រយៈពេល 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 មិនមែនជាការកែច្នៃឡើងវិញទេ វាគឺជាការសរសេរឡើងវិញ។ អ្នកអភិវឌ្ឍន៍ត្រូវតែទទួលយកគំរូផ្លូវចិត្តខុសគ្នា។

១៩.១ ការទទួលយកភាពមិនស៊ីសង្វាក់គ្នា

ខណៈពេលដែល WebSockets មានលក្ខណៈអសមកាលកម្មដោយធម្មជាតិ ភាពស្មុគស្មាញនៃ 2.0.1 មានន័យថាសំណើតែមួយ (ដូចជាទទួលបានរបាយការណ៍មូលដ្ឋាន) អាចចំណាយពេលច្រើនវិនាទីដើម្បីដំណើរការលើ EVSE ដែលមានការរឹតត្បិតធនធាន។ អ្នកអភិវឌ្ឍន៍ CSMS ត្រូវតែអនុវត្តតក្កវិជ្ជា timeout និង retry ដ៏រឹងមាំ ដែលគិតគូរពីល្បឿនដំណើរការខុសៗគ្នារបស់អ្នកលក់ផ្នែករឹងផ្សេងៗគ្នា។

១៩.២ ការវិភាគ JSON ប្រកបដោយប្រសិទ្ធភាព

ការវិភាគ JSON អាចត្រូវការ CPU ច្រើន។ សម្រាប់កម្មវិធីបង្កប់ EVSE អ្នកអភិវឌ្ឍន៍គួរតែប្រើកម្មវិធីវិភាគផ្អែកលើស្ទ្រីមជាជាងការផ្ទុកបន្ទុកទាំងមូលទៅក្នុង RAM។ នេះមានសារៈសំខាន់ជាពិសេសសម្រាប់ជូនដំណឹងព្រឹត្តិការណ៍សារ ដែលអាចមានការអាប់ដេតអថេររាប់រយនៅក្នុងស៊ុមតែមួយ។

១៩.៣ ការដោះស្រាយម៉ាស៊ីនរដ្ឋ

ម៉ាស៊ីនស្ថានភាពសម្រាប់ប្រតិបត្តិការនៅក្នុង 2.0.1 គឺតឹងរ៉ឹងជាងនៅក្នុង 1.6J។ អ្នកអភិវឌ្ឍន៍ត្រូវតែអនុវត្តតាមច្បាប់អន្តរកាលយ៉ាងតឹងរ៉ឹងសម្រាប់ព្រឹត្តិការណ៍ប្រតិបត្តិការឧទាហរណ៍ អ្នកមិនអាចផ្ញើបានបញ្ចប់ព្រឹត្តិការណ៍ដោយមិនចាំបាច់ផ្ញើជាមុនសិនបានចាប់ផ្តើមព្រឹត្តិការណ៍សម្រាប់ជាក់លាក់នោះលេខសម្គាល់ប្រតិបត្តិការ.

ជំពូកទី 20៖ ការធ្វើតេស្ត ការផ្ទៀងផ្ទាត់ និងឧបករណ៍សាកល្បងអនុលោមភាព OCPP (OCTT)

អន្តរប្រតិបត្តិការគឺជាការសន្យារបស់ OCPP ប៉ុន្តែវាត្រូវបានសម្រេចតែតាមរយៈការធ្វើតេស្តយ៉ាងម៉ត់ចត់ប៉ុណ្ណោះ។

២០.១ តួនាទីនៃវិញ្ញាបនបត្រ OCA

សម្ព័ន្ធ​ Open Charge ផ្តល់ជូនកម្មវិធីវិញ្ញាបនបត្រ។ អ្នកទិញគួរតែរកមើលស្លាក "OCPP 2.0.1 Certified"។ វិញ្ញាបនបត្រនេះធានាថាការអនុវត្តបានឆ្លងកាត់ការធ្វើតេស្តស្វ័យប្រវត្តិជាច្រើនដែលគ្របដណ្តប់លើទម្រង់ចាំបាច់ទាំងអស់។

២០.២ ការប្រើប្រាស់ OCTT

ឧបករណ៍សាកល្បងអនុលោមភាព OCPP (OCTT) គឺជាស្តង់ដារមាសសម្រាប់ការធ្វើតេស្ត។ វាក្យសព្ទទាំង CSMS និង EVSE។

• សម្រាប់ក្រុមហ៊ុនផលិត EVSE៖ ប្រើ OCTT ដើម្បីផ្ទៀងផ្ទាត់ថាស្ថានីយ៍របស់អ្នកដោះស្រាយសេណារីយ៉ូ "ផ្លូវរីករាយ" និងករណីគែម (ដូចជាការដាច់បណ្តាញអំឡុងពេលធ្វើបច្ចុប្បន្នភាពកម្មវិធីបង្កប់)។
• សម្រាប់អ្នកផ្តល់សេវា CSMSប្រើប្រាស់ OCTT ដើម្បីធានាថា backend របស់អ្នកអាចដោះស្រាយសារជាច្រើនប្រភេទ និងតម្រូវការសុវត្ថិភាពដ៏តឹងរ៉ឹងរបស់ 2.0.1។

២០.៣ ការធ្វើតេស្តនៅទីវាល និង ការធ្វើអន្តរកម្ម

ក្រៅពីការធ្វើតេស្តដោយស្វ័យប្រវត្តិ OCA រៀបចំ "Plugfests" ជាកន្លែងដែលអ្នកលក់នាំយកផ្នែករឹង និងកម្មវិធីរបស់ពួកគេមកធ្វើតេស្តប្រឆាំងគ្នាទៅវិញទៅមកនៅក្នុងសេណារីយ៉ូពិភពពិត។ នេះជាកន្លែងដែលកំហុសដ៏ស្រទន់បំផុត — ដូចជាភាពមិនឆបគ្នានៃវិញ្ញាបនបត្រ ឬភាពខុសគ្នានៃទម្រង់ JSON តិចតួច — ត្រូវបានចាប់ និងដោះស្រាយ។

ជំពូកទី 21៖ តារាងប្រៀបធៀបស៊ីជម្រៅ៖ សកម្មភាព 60+ របស់ OCPP 2.0.1

ដើម្បីផ្តល់ជាឯកសារយោងពេញលេញ យើងចាត់ថ្នាក់សារចម្បងនៃ 2.0.1 ហើយប្រៀបធៀបពួកវាទៅនឹងសមភាគី 1.6J របស់ពួកគេ។

២១.១ ការផ្តល់ និងការកំណត់រចនាសម្ព័ន្ធ

២១.២ ការដោះស្រាយប្រតិបត្តិការ

២១.៣ សុវត្ថិភាព និងការគ្រប់គ្រងកម្មវិធីបង្កប់

២១.៤ អត្ថន័យនៃតារាងនេះសម្រាប់បណ្តាញរបស់អ្នក

តារាងនេះបង្ហាញពីចំណុចមួយដែលមិនអាចច្រឡំបាន៖ OCPP 2.0.1 មិនមែនជាការប្តូរឈ្មោះទៅជា 1.6J ទេ។ ក្រុមសារថ្មី — អថេរដែលបានវាយបញ្ចូល ប្រតិបត្តិការដែលជំរុញដោយព្រឹត្តិការណ៍ និងការគ្រប់គ្រងវិញ្ញាបនបត្រ — គឺជាបរិក្ខារដែលត្រូវការសម្រាប់ Plug & Charge ការសាកថ្មឆ្លាតវៃ និងការរាយការណ៍បទប្បញ្ញត្តិ។ ឆ្នាំងសាកដែលនិយាយត្រឹមតែ 1.6J អាចត្រូវបានបំពាក់ឡើងវិញជាមួយនឹងច្រកទ្វារ ប៉ុន្តែ CSMS ដែលនិយាយត្រឹមតែ 1.6J មិនអាចផ្តល់នូវគំរូសុវត្ថិភាពដែលនិយតករ និងក្រុមហ៊ុនផលិតរថយន្តត្រូវការកាន់តែខ្លាំងឡើងនោះទេ។ នៅពេលវាយតម្លៃផ្នែករឹង “2.0.1-ready” គួរតែមានន័យថាកម្មវិធីបង្កប់កំពុងដឹកជញ្ជូននៅថ្ងៃនេះ មិនមែនកំណត់ពេលសម្រាប់ឆ្នាំក្រោយទេ។ ហើយដោយសារតែ OCPP 2.0.1 ដំណើរការលើ JSON-over-WebSocket ជាជាងការដឹកជញ្ជូន SOAP នៃ 1.6J លំហូរសារមានទម្ងន់ស្រាលជាង និងងាយស្រួលជាងក្នុងការបំបាត់កំហុស — អត្ថប្រយោជន៍ជាក់ស្តែងដែលក្រុម IT របស់អ្នកនឹងមានអារម្មណ៍ចាប់ពីថ្ងៃដំបូង។

ជំពូកទី 22: សេចក្តីសន្និដ្ឋាន: ការធ្វើការសម្រេចចិត្តធ្វើឱ្យប្រសើរឡើង

សម្រាប់ប្រតិបត្តិករពាណិជ្ជកម្ម ការណែនាំជាក់ស្តែងគឺច្បាស់លាស់៖

• ការដាក់ពង្រាយថ្មីគួរតែកំណត់លំនាំដើមទៅ OCPP 2.0.1។គំរូសុវត្ថិភាព ការគ្រប់គ្រងវិញ្ញាបនបត្រ និងការរួមបញ្ចូល ISO 15118 គឺជាតម្រូវការជាមុនសម្រាប់បរិយាកាសបទប្បញ្ញត្តិឆ្នាំ 2026។
• កងនាវា 1.6J ដែលមានស្រាប់មិនជាប់គាំងទេ។ច្រកផ្លូវ​ដែល​បាន​គ្រប់គ្រង និង​វេទិកា CSMS ពិធីការ​ពីរ ជួយ​បំពេញ​ចន្លោះ​ប្រហោង​នេះ ខណៈ​ដែល​អ្នក​បញ្ចូល​ផ្នែករឹង​ដើម 2.0.1 ជា​ដំណាក់កាល។
• សាកល្បងមុនពេលអ្នកទុកចិត្ត។ប្រើប្រាស់ OCTT, plugfests និង staged rollouts — អន្តរប្រតិបត្តិការត្រូវបានបង្ហាញឱ្យឃើញនៅក្នុងវាល មិនមែនសន្មត់ពីសន្លឹកទិន្នន័យទេ។
• ទាមទារផ្លូវធ្វើចំណាកស្រុកជាលាយលក្ខណ៍អក្សរ។អ្នកលក់ឆ្នាំងសាករបស់អ្នកគួរតែបោះពុម្ពផ្សាយផែនទីបង្ហាញផ្លូវកម្មវិធីបង្កប់ពី 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.