စီးပွားဖြစ်အားသွင်းအော်ပရေတာများအတွက် OCPP 1.6J နှင့် 2.0.1 တို့၏ မဟာဗျူဟာမြောက်နှိုင်းယှဉ်ချက်

ကမ္ဘာလုံးဆိုင်ရာ စီးပွားဖြစ် အားသွင်းစက်များအတွက် OCPP 1.6J နှင့် 2.0.1 ၏ အပြီးသတ် မဟာဗျူဟာမြောက် နှိုင်းယှဉ်ချက်- ကွန်ရက် တိုးချဲ့နိုင်မှု၊ အဆင့်မြင့် ဆိုက်ဘာလုံခြုံရေး၊ ISO 15118 ပေါင်းစပ်မှုနှင့် ရေရှည်တည်တံ့သော EV တိုးတက်မှုအတွက် အနာဂတ်အတွက် အာမခံချက်ပေးသည့် အခြေခံအဆောက်အအုံများ

စီမံကိန်း၏အဓိကအချက်အလက်များ

လျှပ်စစ်ယာဉ် (EV) အားသွင်းခြင်း ရှုခင်းသည် ကြီးမားသော အပြောင်းအလဲများကို ကြုံတွေ့နေရသည်။ ကမ္ဘာလုံးဆိုင်ရာ လက်ခံအသုံးပြုမှု မြန်ဆန်လာသည်နှင့်အမျှ Electric Vehicle Supply Equipment (EVSE) နှင့် Charging Station Management Systems (CSMS) အကြား အပြန်အလှန် ဆက်သွယ်မှုအား ထိန်းချုပ်သည့် အခြေခံ ဆက်သွယ်ရေး ပရိုတိုကောများသည် Commercial Charging Operators (CPOs) အတွက် နည်းပညာဆိုင်ရာ မဟာဗျူဟာ၏ အဓိကအချက်အချာ ဖြစ်လာခဲ့သည်။ Open Charge Alliance (OCA) မှ ထိန်းသိမ်းထားသော Open Charge Point Protocol (OCPP) သည် ရိုးရှင်းသော မက်ဆေ့ချ်ပို့ခြင်း မူဘောင်မှ ခေတ်မီပြီး လုံခြုံကာ တိုးချဲ့နိုင်သော စံနှုန်းတစ်ခုအဖြစ်သို့ ပြောင်းလဲလာခဲ့သည်။

ဤလမ်းညွှန်ချက်သည် OCPP 1.6J မှ OCPP 2.0.1 သို့ ကူးပြောင်းခြင်း၏ ပြီးပြည့်စုံသော နည်းပညာဆိုင်ရာ ခွဲခြမ်းစိတ်ဖြာမှုကို ပေးပါသည်။ ဗိသုကာပိုင်းဆိုင်ရာ ကွာခြားချက်များ၊ လုံခြုံရေး မြှင့်တင်မှုများ၊ စက်ပစ္စည်းစီမံခန့်ခွဲမှု ပုံစံများနှင့် ISO 15118 ပေါင်းစည်းမှု၏ အရေးကြီးသော အခန်းကဏ္ဍတို့ကို ကျွန်ုပ်တို့ စူးစမ်းလေ့လာပါသည်။ ဝယ်သူများနှင့် အော်ပရေတာများအတွက်၊ ဤဆောင်းပါးသည် အလျင်အမြန် ရင့်ကျက်လာသော ဈေးကွက်တွင် သတင်းအချက်အလက်အပြည့်အစုံပါဝင်သော ဝယ်ယူမှုနှင့် ရွှေ့ပြောင်းမှုဆိုင်ရာ ဆုံးဖြတ်ချက်များချရန်အတွက် တိကျသော ကိုးကားချက်အဖြစ် ဆောင်ရွက်ပါသည်။

အခန်း ၁: EV အားသွင်းစံနှုန်းများ၏ တိုးတက်ပြောင်းလဲလာပုံ- သမိုင်းဝင်နောက်ခံ

Open Charge Point Protocol (OCPP) သည် အပြန်အလှန်လုပ်ဆောင်နိုင်စွမ်း လိုအပ်ချက်မှ ပေါက်ဖွားလာခြင်း ဖြစ်သည်။ EV အားသွင်းခြင်း၏ အစောပိုင်းကာလများတွင် ဟာ့ဒ်ဝဲထုတ်လုပ်သူများနှင့် ဆော့ဖ်ဝဲပံ့ပိုးပေးသူများသည် ပြိုင်ဆိုင်မှုနှင့် ဆန်းသစ်တီထွင်မှုကို တားဆီးသည့် “နံရံကာရံထားသောဥယျာဉ်များ” ကို ဖန်တီးကာ ပိုင်ဆိုင်မှုဆိုင်ရာ ပရိုတိုကောများကို အသုံးပြုခဲ့ကြသည်။ OCPP 1.2 နှင့် 1.5 တို့ကို မိတ်ဆက်ခြင်းသည် အခြေခံအုတ်မြစ်ချပေးခဲ့သော်လည်း လုပ်ငန်းနယ်ပယ်ကို အမှန်တကယ် စည်းလုံးစေခဲ့သည်မှာ OCPP 1.6 ဖြစ်သည်။

၁.၁ OCPP 1.6J ၏ လွှမ်းမိုးမှု

၂၀၁၅ ခုနှစ်တွင် ထွက်ရှိခဲ့သော OCPP 1.6 သည် JSON over WebSockets (1.6J) အကောင်အထည်ဖော်မှုကို မိတ်ဆက်ခဲ့သည်။ SOAP-based messaging မှ ခွဲထွက်ခြင်းသည် overhead ကို သိသိသာသာ လျှော့ချပေးပြီး developer များအတွက် အကောင်အထည်ဖော်မှုကို ရိုးရှင်းစေသည်။ ၎င်းသည် smart charging နှင့် additional status notifications ကဲ့သို့သော အင်္ဂါရပ်များကို မိတ်ဆက်ခဲ့ပြီး ဆယ်စုနှစ်တစ်ခုနီးပါး စက်မှုလုပ်ငန်းစံနှုန်းတစ်ခု ဖြစ်လာစေခဲ့သည်။

၁.၂ OCPP ၏ ကမ္ဘာဦးကျမ်း ၂.၀.၁

1.6J အောင်မြင်မှုရှိသော်လည်း၊ လုပ်ငန်းတိုးတက်မှုသည် ၎င်း၏ကန့်သတ်ချက်များကို ဖော်ထုတ်ခဲ့သည်။ လုံခြုံရေးဆိုင်ရာပြဿနာများ၊ စက်ပစ္စည်းစီမံခန့်ခွဲမှုရှုပ်ထွေးမှုနှင့် အဆင့်မြင့် grid integration (V2G) အတွက် native support မရှိခြင်းကြောင့် OCPP 2.0 နှင့် နောက်ပိုင်းတွင် ပြန်လည်ပြင်ဆင်ထားသော OCPP 2.0.1 (၂၀၂၀ ခုနှစ်တွင် ထွက်ရှိ) ဖွံ့ဖြိုးတိုးတက်မှုကို ဦးတည်စေခဲ့သည်။ OCPP 2.0.1 သည် အပ်ဒိတ်တစ်ခုမျှသာမဟုတ်ပါ။ ၎င်းသည် မြင့်မားသောပါဝါ၊ စမတ်ကျပြီး လုံခြုံသော အားသွင်းကွန်ရက်များ၏ နောက်မျိုးဆက်ကို ပံ့ပိုးပေးရန် ရည်ရွယ်သည့် လုံးဝပြန်လည်ဒီဇိုင်းထုတ်ထားခြင်း ဖြစ်သည်။

အခန်း ၂: အခြေခံဆက်သွယ်ရေးပုံစံများ- JSON၊ WebSockets နှင့် Frame Structures

ဤ protocol များအကြား ကွာခြားချက်ကို နားလည်ရန်အတွက် low-level communication ကို ကြည့်ရပါမည်။ protocol နှစ်ခုစလုံးသည် WebSockets ထက် JSON ကို အသုံးပြုသော်လည်း ဤ message များ၏ structure နှင့် handling မှာ သိသိသာသာ ကွာခြားပါသည်။

၂.၁ WebSocket အလွှာ

ဗားရှင်းနှစ်ခုစလုံးသည် full-duplex ဆက်သွယ်မှုကို ခွင့်ပြုသည့် persistent WebSocket ချိတ်ဆက်မှုများကို အသုံးပြုသည်။ ၎င်းသည် မိုဘိုင်းအက်ပ်မှ အားသွင်းခြင်း session ကို ရပ်တန့်ခြင်း သို့မဟုတ် ချက်ချင်းချို့ယွင်းချက်သတိပေးချက်များ ရရှိခြင်းကဲ့သို့သော အချိန်နှင့်တပြေးညီ လုပ်ဆောင်ချက်များအတွက် အရေးကြီးပါသည်။

၂.၂ မက်ဆေ့ချ်ဘောင် ခွဲခြမ်းစိတ်ဖြာခြင်း

ပုံမှန် OCPP မက်ဆေ့ချ်တစ်ခုတွင် မက်ဆေ့ချ်အမျိုးအစား ID၊ ထူးခြားသော မက်ဆေ့ချ် ID၊ လုပ်ဆောင်ချက်အမည်နှင့် payload တို့ ပါဝင်သည်။

OCPP 1.6J Frame ဥပမာ (BootNotification)

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

OCPP 2.0.1 Frame ဥပမာ (BootNotification)

"json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`၂.၀.၁ မှာ အသေးစိတ်အချက်အလက်တွေ ပိုများလာတာကို သတိပြုပါ။reason` အကွက်သည် CSMS အား boot လုပ်ခြင်းသည် reboot လုပ်ခြင်း၊ power-up လုပ်ခြင်း သို့မဟုတ် watch-dog trigger ကြောင့်ဖြစ်မဖြစ် နားလည်နိုင်စေပြီး ပိုမိုကောင်းမွန်သော diagnostic logic ကို ဖြစ်စေသည်။

အခန်း ၃: ဗိသုကာပုံစံပြောင်းလဲမှု- စက်ပစ္စည်းမော်ဒယ်

OCPP 2.0.1 မှာ အရေးအကြီးဆုံး နည်းပညာပိုင်းဆိုင်ရာ ပြောင်းလဲမှုကတော့စက်ပစ္စည်း မော်ဒယ်.

၃.၁ 1.6J Configuration Keys များ၏ ကန့်သတ်ချက်များ

OCPP 1.6J တွင်၊ ဟာ့ဒ်ဝဲဖွဲ့စည်းမှုကို “Configuration Keys” ၏ flat list မှတစ်ဆင့် စီမံခန့်ခွဲခဲ့သည် (ဥပမာ-နှလုံးခုန်နှုန်းကြားကာလ, ချိတ်ဆက်မှုအချိန်ကုန်သွားခြင်း). အားသွင်းကိရိယာများသည် ပိုမိုရှုပ်ထွေးလာသည်နှင့်အမျှ (multi-connector၊ integrated power module များ၊ ရှုပ်ထွေးသော cooling system များ) ဤပြားချပ်ချပ်စာရင်းသည် စီမံခန့်ခွဲ၍မရနိုင်ဖြစ်လာသည်။ ဘူတာရုံတစ်ခု၏ ရုပ်ပိုင်းဆိုင်ရာ အဆင့်အတန်းကိုဖော်ပြရန် စံသတ်မှတ်ထားသောနည်းလမ်းမရှိပါ။

၃.၂ ၂.၀.၁ စက်ပစ္စည်းမော်ဒယ်ချဉ်းကပ်မှု

OCPP 2.0.1 သည် အောက်ပါတို့ပါဝင်သော အဆင့်ဆင့်ပုံစံကို မိတ်ဆက်ပေးသည်-အစိတ်အပိုင်းများနှင့်ကိန်းရှင်များ။ အစိတ်အပိုင်းတစ်ခုသည် “Controller,” “Connector,” သို့မဟုတ် “PowerModule” ဖြစ်နိုင်သည်။ အစိတ်အပိုင်းတစ်ခုစီတွင် ၎င်း၏အခြေအနေ သို့မဟုတ် ဖွဲ့စည်းမှုပုံစံကို ကိုယ်စားပြုသော variable များရှိသည် (ဥပမာ-အပူချိန်, ဓာတ်အား, အများဆုံးလက်ရှိ).

• အစိတ်အပိုင်းအားသွင်းစခန်း၏ ရုပ်ပိုင်းဆိုင်ရာ သို့မဟုတ် ယုတ္တိဗေဒဆိုင်ရာ အစိတ်အပိုင်း။
• ပြောင်းလဲနိုင်သော: ထိုအစိတ်အပိုင်း၏ သီးခြား attribute တစ်ခုဖြစ်သည်။
• ဝိသေသလက္ခဏာများ: variable (ယူနစ်၊ အပိုင်းအခြား၊ access အမျိုးအစား) ကို ဖော်ပြသည့် metadata။

ဤသည်မှာ စံသတ်မှတ်ထားသော စောင့်ကြည့်ခြင်းကို ခွင့်ပြုသည်။ အော်ပရေတာတစ်ဦးသည် ယခုအခါ ရောင်းချသူ-သီးသန့် သီးသန့်သော့ချက်များကို မှီခိုမည့်အစား စံသတ်မှတ်ထားသော လမ်းကြောင်းကို အသုံးပြု၍ သတ်မှတ်ထားသော ပါဝါမော်ဂျူး၏ အပူချိန်ကို မေးမြန်းနိုင်ပါပြီ။

အခန်း ၄: ဆိုက်ဘာလုံခြုံရေး- “အကောင်းဆုံးကြိုးပမ်းအားထုတ်မှု” မှ မဖြစ်မနေလိုအပ်သော TLS အထိ

EV အားသွင်းခြင်း၏ အစောပိုင်းကာလများတွင် လုံခြုံရေးကို မကြာခဏ နောက်မှစဉ်းစားလေ့ရှိသည်။ OCPP 1.6J သည် လုံခြုံရေးပရိုဖိုင်များကို ပေးဆောင်သော်လည်း အကောင်အထည်ဖော်မှုသည် ရောင်းချသူများအားလုံးတွင် ကိုက်ညီမှုမရှိပါ။

၄.၁ 1.6J ရှိ လုံခြုံရေးပရိုဖိုင်များ

OCPP 1.6J သည် လုံခြုံရေးပရိုဖိုင်သုံးခုကို သတ်မှတ်ထားသည်-

1. မလုံခြုံပါ: ရိုးရိုးစာသား HTTP/WebSockets။
2. အခြေခံ ခွင့်ပြုချက်: အသုံးပြုသူအမည်/စကားဝှက်ပါသော TLS။
3. လက်မှတ်အခြေပြု: client-side certificates များပါသည့် TLS။

ပြဿနာက အားသွင်းကိရိယာအများအပြားဟာ Profile 1 မှာ ကျန်ရှိနေခဲ့ပြီး man-in-the-middle (MITM) တိုက်ခိုက်မှုတွေနဲ့ ခွင့်ပြုချက်မရှိဘဲ ထိန်းချုပ်မှုတွေကို ခံရနိုင်ခြေရှိစေခဲ့ပါတယ်။

၄.၂ ၂.၀.၁ ၏ ခိုင်မာသော ရပ်တည်ချက်

OCPP 2.0.1 သည် လုံခြုံသော ဆက်သွယ်ရေးကို ပြဋ္ဌာန်းထားသည်။ ၎င်းတွင် အဆင့်မြင့် လုံခြုံရေး အင်္ဂါရပ်များကို မူရင်းအတိုင်း ပေါင်းစပ်ထားသည်-

• လုံခြုံသော Firmware အပ်ဒိတ်များ: firmware image များကို မဖြစ်မနေ လက်မှတ်ထိုးခြင်းနှင့် အတည်ပြုခြင်း။
• လုံခြုံရေး မှတ်တမ်းတင်ခြင်းလုံခြုံရေးနှင့်သက်ဆိုင်သော ဖြစ်ရပ်များအတွက် အသေးစိတ်မှတ်တမ်းများ (ဥပမာ၊ ဝင်ရောက်ရန်ကြိုးပမ်းမှုများ မအောင်မြင်ခြင်း၊ လက်မှတ်သက်တမ်းကုန်ဆုံးခြင်း)။
• လက်မှတ်စီမံခန့်ခွဲမှု: လှည့်ပတ်ပြီး အပ်ဒိတ်လုပ်ထားသော လက်မှတ်များအတွက် စံသတ်မှတ်ထားသော မက်ဆေ့ချ်များ (CSMS-led သို့မဟုတ် Station-led)။
• TLS ၁.၂/၁.၃: နောက်ဆုံးပေါ် ကုဒ်ဝှက်ခြင်းစံနှုန်းများအတွက် ပံ့ပိုးမှု။

စီးပွားဖြစ် အော်ပရေတာများအတွက်၊ ၎င်းသည် ကြီးမားသော ကွန်ရက်ထိခိုက်မှုများ၏ အန္တရာယ်ကို လျှော့ချပေးပြီး IoT စက်ပစ္စည်းများအတွက် ပေါ်ပေါက်လာသော ဆိုက်ဘာလုံခြုံရေး စည်းမျဉ်းများနှင့် ကိုက်ညီမှုကို သေချာစေသည်။

အခန်း ၅: ISO 15118 ပေါင်းစပ်မှု- ပလပ်နှင့် အားသွင်းခြင်းနှင့် V2G

EV အားသွင်းခြင်း၏ အနာဂတ်သည် ရွေ့လျားနေသော အီလက်ထရွန်များအကြောင်းသာမက ဒေတာနှင့် စွမ်းအင်ကို ဉာဏ်ရည်ထက်မြက်စွာ ဖလှယ်ခြင်းနှင့်လည်း ပတ်သက်ပါသည်။ ISO 15118 သည် ယာဉ်မှ ဓာတ်အားလိုင်း (V2G) ဆက်သွယ်ရေးအတွက် နိုင်ငံတကာစံနှုန်းဖြစ်ပြီး OCPP နှင့် ပေါင်းစပ်ခြင်းသည် 2.0.1 ၏ အဓိကအင်္ဂါရပ်ဖြစ်သည်။

၅.၁ ပလပ်နှင့် အားသွင်းခြင်း၏ ရှုပ်ထွေးမှု

Plug & Charge (PnC) သည် ယာဉ်မောင်းအား အက်ပ် သို့မဟုတ် RFID ကတ်ကို အသုံးမပြုဘဲ ကားကို ပလပ်ထိုးပြီး အားသွင်းနိုင်စေပါသည်။ ၎င်းအတွက် ကား၊ အားသွင်းကိရိယာ၊ အော်ပရေတာနှင့် clearinghouse တို့ပါဝင်သည့် ရှုပ်ထွေးသော Public Key Infrastructure (PKI) တစ်ခု လိုအပ်ပါသည်။

OCPP 1.6J မှာ PnC အထောက်အပံ့ဟာ base protocol မှာ မရှိခဲ့ပါဘူး။ Vendors တွေက custom extensions တွေကို အကောင်အထည်ဖော်ရတာကြောင့် fragmentation တွေ ဖြစ်ပေါ်ခဲ့ပါတယ်။ OCPP 2.0.1 မှာ PnC အတွက် “plumbing” ကို ပံ့ပိုးပေးပါတယ်-

• လက်မှတ်ထည့်သွင်းခြင်း: CSMS မှ EV သို့ စာချုပ်လက်မှတ်များကို EVSE မှတစ်ဆင့် ပေးပို့ခြင်း။
• ခွင့်ပြုချက်ယာဉ်၏လက်မှတ်မှရရှိသော e-Mobility ID (eMAID) ကို အသုံးပြုခြင်း။
• ကုဒ်ဝှက်ထားသော ဆက်သွယ်ရေးကားနှင့် ဓာတ်အားလိုင်းကြား ပေးပို့သော အရေးကြီးသော ငွေတောင်းခံလွှာဒေတာကို ကာကွယ်ထားကြောင်း သေချာစေခြင်း။

၅.၂ စမတ်ကျသော အားသွင်းခြင်းနှင့် ဝန်အားချိန်ခွင်လျှာညှိခြင်း

1.6J က အခြေခံ smart charging ကို ပံ့ပိုးပေးပေမယ့် (ပေးပို့တဲ့အားသွင်းပရိုဖိုင်ကို သတ်မှတ်ပါ), 2.0.1 သည် ၎င်းကို မြှင့်တင်ပေးသည်။ ၎င်းသည် အောက်ပါတို့ကို ခွင့်ပြုသည်-

• ပြင်ပအချက်ပြပေါင်းစပ်မှုဇယားကွက်ကြိမ်နှုန်း သို့မဟုတ် လက်ကားဈေးနှုန်း အချက်ပြမှုများကို အချိန်နှင့်တပြေးညီ တုံ့ပြန်ခြင်း။
• ဒိုင်းနမစ် ဝန်အား စီမံခန့်ခွဲမှုချိတ်ဆက်ကိရိယာ ရာပေါင်းများစွာဖြင့် ဆိုက်တစ်ခုတစ်လျှောက် ပါဝါဖြန့်ဖြူးမှုကို ပိုမိုအသေးစိတ်ထိန်းချုပ်နိုင်မှု။
• ယာဉ်မှ ဂရစ်သို့ (V2G)၂.၀.၁ တွင် နှစ်လမ်းသွား စွမ်းအင်စီးဆင်းမှုကို ပံ့ပိုးပေးရန်အတွက် လိုအပ်သောဒေတာအကွက်များ ပါဝင်သောကြောင့် EV များသည် ဓာတ်အားလိုင်းအတွက် ဖြန့်ဝေထားသော စွမ်းအင်အရင်းအမြစ်များ (DERs) အဖြစ် လုပ်ဆောင်နိုင်စေပါသည်။

၅.၃ အသုံးပြုသူ UI/UX မြှင့်တင်မှုများ

OCPP 2.0.1 သည် အားသွင်းကိရိယာ၏ မျက်နှာပြင် သို့မဟုတ် ယာဉ်၏ ဒက်ရှ်ဘုတ်ပေါ်တွင် အောက်ပါကဲ့သို့သော အချက်အလက်များကို တိုက်ရိုက်ပြသခြင်းကို ပံ့ပိုးပေးသည်-

• ဒေသတွင်းငွေကြေးဖြင့် အချိန်နှင့်တပြေးညီ ဈေးနှုန်းသတ်မှတ်ခြင်း။
• 80% state-of-charge (SoC) သို့ရောက်ရှိရန် ခန့်မှန်းခြေအချိန်။
• ပြီးစီးသည့်အခါ လက်ခံရရှိကြောင်း အသေးစိတ်အချက်အလက်များ။

အခန်း ၆: အဆင့်မြင့် စက်ပစ္စည်း စီမံခန့်ခွဲမှုနှင့် စောင့်ကြည့်ခြင်း

CPO တစ်ခုအတွက် အားသွင်းကိရိယာတစ်ခု၏ ကုန်ကျစရိတ်သည် ဝယ်ယူမှုစျေးနှုန်းသာမကဘဲ စုစုပေါင်းပိုင်ဆိုင်မှုကုန်ကျစရိတ် (TCO) လည်းဖြစ်သည်။ ပြုပြင်ထိန်းသိမ်းမှုနှင့် ရပ်တန့်ချိန်သည် အကြီးမားဆုံးအမြတ်အစွန်းများကို ဆုံးရှုံးစေသောအချက်များဖြစ်သည်။ OCPP 2.0.1 သည် သာလွန်ကောင်းမွန်သော စောင့်ကြည့်ရေးစွမ်းရည်များမှတစ်ဆင့် ဤပြဿနာကို ဖြေရှင်းပေးပါသည်။

၆.၁ ဖြစ်ရပ်အခြေပြု အစီရင်ခံခြင်း

1.6J မှာ CSMS ဟာ charger ရဲ့ status ကို မေးမြန်းရလေ့ရှိပါတယ် ဒါမှမဟုတ် စောင့်ဆိုင်းရပါတယ်။အခြေအနေအကြောင်းကြားချက်၂.၀.၁ မှာဖြစ်ရပ်စောင့်ကြည့်ခြင်းစနစ်သည် CSMS အား ကန့်သတ်ချက်များ သတ်မှတ်ခွင့်ပြုသည်။ ဥပမာ- “အတွင်းပိုင်းအပူချိန် 70°C ထက်ကျော်လွန်ပါကသာ ကျွန်ုပ်အား အကြောင်းကြားပါ” သို့မဟုတ် “အဝင်ဗို့အား 200V အောက် ကျဆင်းပါက အစီရင်ခံပါ”။ ၎င်းသည် ကွန်ရက်အသွားအလာကို လျှော့ချပေးပြီး ကြိုတင်ပြုပြင်ထိန်းသိမ်းမှုကို ခွင့်ပြုသည်။

၆.၂ ငွေပေးငွေယူ ကိုင်တွယ်ခြင်း- ငွေပေးငွေယူဖြစ်ရပ်

OCPP 1.6J ရဲ့ အဝေဖန်ခံရဆုံး ရှုထောင့်တစ်ခုကတော့ ငွေပေးငွေယူတွေကို ကိုင်တွယ်ပုံပါပဲ။ ပါဝင်ပတ်သက်တဲ့ အစည်းအဝေးတစ်ခုငွေပေးငွေယူစတင်ခြင်းနှင့်ငွေပေးငွေယူ ရပ်တန့်ခြင်းမက်ဆေ့ချ်များပါရှိသော်လည်း ကွန်ရက်ပြတ်တောက်မှုဖြစ်ပေါ်ပါက CSMS သည် ငွေတောင်းခံလွှာဒေတာကို ညှိနှိုင်းရန် မကြာခဏ ရုန်းကန်ခဲ့ရသည်။

OCPP 2.0.1 သည် ၎င်းတို့ကို တစ်ခုတည်းသော၊ ခိုင်မာသော ကိရိယာဖြင့် အစားထိုးသည်ငွေပေးငွေယူဖြစ်ရပ်မက်ဆေ့ချ်။ ဤမက်ဆေ့ချ်ကို ငွေပေးငွေယူတစ်ခု၏ သက်တမ်းစက်ဝန်းအဆင့်အားလုံးကို (စတင်၊ အပ်ဒိတ်လုပ်၊ ပြီးဆုံး) အစီရင်ခံရန်အသုံးပြုသည်။ ၎င်းတွင် ထူးခြားသောတစ်ခုပါဝင်သည်။ငွေပေးငွေယူ IDအားသွင်းကိရိယာ ပြန်လည်စတင်သည့်တိုင် ၎င်းသည် ဆက်လက်တည်ရှိနေပြီး အားသွင်းဒေတာ မဆုံးရှုံးကြောင်းနှင့် ထို့ကြောင့် ဝင်ငွေ မဆုံးရှုံးကြောင်း သေချာစေသည်။

၆.၃ ရောဂါရှာဖွေရေးနှင့် ပြဿနာရှာဖွေဖြေရှင်းခြင်း ပိုမိုကောင်းမွန်လာခြင်း

ထိုမှတ်တမ်းရယူပါနှင့်ရောဂါရှာဖွေရေးအခြေအနေအကြောင်းကြားစာ၂.၀.၁ ရှိ မက်ဆေ့ချ်များသည် ပိုမိုစနစ်တကျဖြစ်သည်။ CPO များသည် သတ်မှတ်ထားသော မှတ်တမ်းအမျိုးအစားများ (လုံခြုံရေး၊ ရောဂါရှာဖွေခြင်း၊ အသုံးပြုသူ) ကို တောင်းဆိုနိုင်ပြီး အချိန်အပိုင်းအခြားကို သတ်မှတ်နိုင်သည်။ ၎င်းသည် အဝေးထိန်းပံ့ပိုးမှုအဖွဲ့များအား ဆိုက်သို့ နည်းပညာရှင်တစ်ဦးကို မစေလွှတ်ဘဲ ပြဿနာများကို ဖြေရှင်းနိုင်စေပြီး OpEx ကို သိသိသာသာ လျှော့ချပေးသည်။

အခန်း ၇: Firmware အပ်ဒိတ်လုပ်ခြင်း ယန္တရားများ- ယုံကြည်စိတ်ချရမှုနှင့် ပြန်လည်ရုပ်သိမ်းခြင်း

Firmware အပ်ဒိတ်များသည် တိုးတက်ပြောင်းလဲနေသော ဟာ့ဒ်ဝဲ၏ အသက်သွေးကြောဖြစ်သော်လည်း အပ်ဒိတ်မအောင်မြင်ပါက အားသွင်းကိရိယာကို ပိတ်ဆို့စေနိုင်သည်။

၇.၁ 1.6J အပ်ဒိတ်လုပ်ခြင်းလုပ်ငန်းစဉ်

၁.၆ ဂျူးလ်မှာFirmware အပ်ဒိတ်command သည် အတော်လေးရိုးရှင်းပါသည်။ charger သည် image ကို download လုပ်ပြီး install လုပ်ရန်ကြိုးစားလိမ့်မည်။ multi-stage update များ သို့မဟုတ် verified rollback များအတွက် စံသတ်မှတ်ထားသော ယန္တရားမရှိပါ။

၇.၂ ၂.၀.၁ ဘက်စုံအဆင့် အပ်ဒိတ်

OCPP 2.0.1 သည် firmware အပ်ဒိတ်များအတွက် ပိုမိုရှုပ်ထွေးသော သက်တမ်းစက်ဝန်းကို မိတ်ဆက်ပေးသည်-

1. ဒေါင်းလုဒ်လုပ်ပါ: အားသွင်းကိရိယာသည် ရုပ်ပုံကို ရယူပြီး ၎င်း၏ checksum/လက်မှတ်ကို အတည်ပြုသည်။
2. တပ်ဆင်ခြင်း: အပ်ဒိတ်ကို ဒုတိယ partition တစ်ခုသို့ အသုံးချသည်။
3. အတည်ပြုခြင်း: စနစ်သည် firmware အသစ်သည် မှန်ကန်စွာ စတင်ခြင်း ရှိ၊ မရှိ စစ်ဆေးသည်။
4. အသက်သွင်းခြင်း: အဓိက အပိုင်းကို ပြောင်းလဲလိုက်ပါပြီ။

အဆင့်တစ်ခုခု မအောင်မြင်ပါက၊ အားသွင်းကိရိယာသည် ယခင်တည်ငြိမ်သောဗားရှင်းသို့ မည်သို့ပြန်ပြောင်းသင့်ပြီး သတ်မှတ်ထားသော ပျက်ကွက်မှုကုဒ်ကို CSMS သို့ မည်သို့အစီရင်ခံသင့်သည်ကို ပရိုတိုကောက သတ်မှတ်ပေးသည်။ ဤယုံကြည်စိတ်ချရမှုအဆင့်ကို ကြီးမားသော စီးပွားဖြစ်ဖြန့်ကျက်မှုများအတွက် ညှိနှိုင်း၍မရပါ။

၇.၃ လက်မှတ်အတည်ပြုခြင်း

မကောင်းဆိုးဝါးသမားများက ခိုးယူခံရသော firmware ကို upload လုပ်ခြင်းမှ ကာကွယ်ရန်အတွက် 2.0.1 တွင် digital signatures များကို အသုံးပြုရန် ပြဋ္ဌာန်းထားသည်။ charger သည် ထုတ်လုပ်သူ၏ private key ဖြင့် လက်မှတ်မထိုးထားသော မည်သည့် code ကိုမဆို execute လုပ်ရန် ငြင်းဆိုမည်ဖြစ်ပြီး hardware-level hack များမှ အရေးကြီးသော ကာကွယ်မှုအလွှာတစ်ခုကို ထည့်သွင်းပေးမည်ဖြစ်သည်။

အခန်း ၈: ဒေတာလုံခြုံရေး၊ စည်းမျဉ်းစည်းကမ်းလိုက်နာမှုနှင့် GDPR

EV အားသွင်းခြင်းသည် နေ့စဉ်အသုံးဝင်မှုတစ်ခု ဖြစ်လာသည်နှင့်အမျှ ထုတ်ပေးသော ကိုယ်ရေးကိုယ်တာဒေတာပမာဏသည် အံ့မခန်းဖြစ်သည်။ တစ်ကြိမ်အားသွင်းခြင်းသည် အသုံးပြုသူ၏ အထောက်အထား၊ ၎င်းတို့၏ယာဉ်၏တည်နေရာ၊ ၎င်းတို့၏ခရီးသွားပုံစံနှင့် ၎င်းတို့၏ဘဏ္ဍာရေးအချက်အလက်များကို ချိတ်ဆက်နိုင်သည်။

၈.၁ OCPP ရှိ ကိုယ်ရေးကိုယ်တာအချက်အလက်များ (PII)

ဥရောပရှိ အထွေထွေဒေတာကာကွယ်ရေးစည်းမျဉ်း (GDPR) နှင့် ကယ်လီဖိုးနီးယားရှိ CCPA ကဲ့သို့သော အလားတူဥပဒေများနှင့် ဆက်စပ်၍ ဒေတာအချက်များဖြစ်သည့်idTag(RFID) သို့မဟုတ်EVCCID(ယာဉ်အမှတ်အသား) များကို PII အဖြစ် သတ်မှတ်သည်။

OCPP 2.0.1 သည် ဒေတာအမည်ဝှက်ခြင်းအတွက် ပိုမိုကောင်းမွန်သော ထိန်းချုပ်မှုများကို ပေးပါသည်။ ဥပမာအားဖြင့်၊စိတ်ကြိုက်ဒေတာfield များသည် operator များအား PII ကို core protocol log များသို့ မဖော်ပြဘဲ metadata များကို သိမ်းဆည်းနိုင်စေပါသည်။ ထို့အပြင်၊ မြှင့်တင်ထားသော လုံခြုံရေးပရိုဖိုင်များသည် ဤဒေတာကို transit နှင့် rest နှစ်ခုလုံးတွင် encrypt လုပ်ထားကြောင်း သေချာစေသည်။

၈.၂ မေ့ပျောက်ခံရခွင့်နှင့် ဒေတာ ရွှေ့ပြောင်းနိုင်မှု

2.0.1 Device Model ၏ ဖွဲ့စည်းတည်ဆောက်ပုံဆိုင်ရာ သဘောသဘာဝသည် CSMS ဝန်ဆောင်မှုပေးသူများအတွက် “ဒေတာဖျက်ခြင်း” တောင်းဆိုမှုများကို အကောင်အထည်ဖော်ရန် ပိုမိုလွယ်ကူစေသည်။ 1.6J စနစ်တွင်၊ မတူညီသော configuration key များနှင့် log များတစ်လျှောက် အသုံးပြုသူ၏ ID ၏ instance အားလုံးကို ရှာဖွေခြင်းသည် manual အိပ်မက်ဆိုးတစ်ခု ဖြစ်သည်။ 2.0.1 တွင်၊ device state နှင့် transaction data အကြား ရှင်းလင်းသော ခွဲခြားမှုသည် ပိုမိုသန့်ရှင်းသော database architecture ကို ခွင့်ပြုသည်။

၈.၃ IoT လုံခြုံရေးဥပဒေများနှင့် ကိုက်ညီမှု

ဒေသအများအပြားသည် IoT စက်ပစ္စည်းများတွင် ထူးခြားသောစကားဝှက်များနှင့် လုံခြုံသော အပ်ဒိတ်ယန္တရားများ ရှိရန် လိုအပ်သည့် ဥပဒေများကို ယခုအခါ အတည်ပြုနေကြပါသည်။ OCPP 2.0.1 ၏ မဖြစ်မနေ TLS နှင့် လက်မှတ်ရေးထိုးထားသော firmware များသည် “ရှိသင့်သော” အင်္ဂါရပ်များသာမက ကယ်လီဖိုးနီးယားနှင့် UK ကဲ့သို့သော ဈေးကွက်များတွင် ဟာ့ဒ်ဝဲရောင်းချရန်အတွက် တရားဝင်လိုအပ်ချက်များဖြစ်သည်။

အခန်း ၉: ဝယ်သူ၏ ရှုထောင့်- TCO၊ ROI နှင့် မဟာဗျူဟာမြောက် ရွှေ့ပြောင်းမှု

စီးပွားဖြစ် အားသွင်းစက်လုပ်ငန်းရှင်တစ်ဦးအတွက် 1.6J မှာပဲ ဆက်ရှိနေဖို့ ဒါမှမဟုတ် 2.0.1 ကို ရွှေ့ဖို့ ဆုံးဖြတ်ချက်က ငွေကြေးအရ ခက်ခဲပါတယ်။

၉.၁ အကောင်အထည်ဖော်မှု၏ ကုန်ကျစရိတ်

• OCPP ၁.၆ ဂျိုးအကောင်အထည်ဖော်ရန် ဈေးသက်သာပြီး ဈေးနှုန်းသက်သာသော ဟာ့ဒ်ဝဲများဖြင့် ကျယ်ကျယ်ပြန့်ပြန့် ပံ့ပိုးပေးထားသော်လည်း ပြုပြင်ထိန်းသိမ်းမှုနှင့် လုံခြုံရေးအန္တရာယ်များတွင် မြင့်မားသော ဖုံးကွယ်ထားသော ကုန်ကျစရိတ်များ ရှိပါသည်။
• OCPP ၂.၀.၁EVSE မှာ ပိုမိုအားကောင်းတဲ့ ပရိုဆက်ဆာတွေနဲ့ မှတ်ဉာဏ် ပိုမိုလိုအပ်ပါတယ်။ CSMS အတွက် ဖွံ့ဖြိုးတိုးတက်ရေး ကုန်ကျစရိတ်တွေက ပရိုတိုကောရဲ့ ရှုပ်ထွေးမှုကြောင့် ပိုမိုမြင့်မားပါတယ်။ ဒါပေမယ့် အဝေးထိန်း စီမံခန့်ခွဲမှုနဲ့ ယုံကြည်စိတ်ချရမှု ပိုမိုကောင်းမွန်လာတာကြောင့် OpEx ကုန်ကျစရိတ်ကို သိသာထင်ရှားစွာ သက်သာစေပါတယ်။

၉.၂ “ချောမွေ့စွာ အဆင့်မြှင့်တင်ခြင်း” ဒဏ္ဍာရီ

1.6J အားသွင်းကိရိယာများကို ဆော့ဖ်ဝဲမှတစ်ဆင့် 2.0.1 သို့ အဆင့်မြှင့်တင်နိုင်သည်ဟု မကြာခဏပြောကြသည်။ အမှန်တကယ်တွင် ၎င်းသည် ရှားပါးစွာသာ မှန်ကန်ပါသည်။ 2.0.1 အတွက် မှတ်ဉာဏ်နှင့် CPU လိုအပ်ချက်များ (အထူးသဖြင့် TLS လက်မှတ်များကို ကိုင်တွယ်ခြင်းနှင့် Device Model ၏ ရှုပ်ထွေးသော JSON parsing) သည် 1.6J ထိန်းချုပ်ကိရိယာအဟောင်းများ၏ စွမ်းဆောင်ရည်ထက် မကြာခဏ ကျော်လွန်လေ့ရှိသည်။

၉.၃ မဟာဗျူဟာမြောက် ရွှေ့ပြောင်းမှုလမ်းကြောင်းများ

CPO များသည် “Hybrid Network” ချဉ်းကပ်မှုကို ထည့်သွင်းစဉ်းစားသင့်သည်-

1. အမွေအနှစ်ဆိုက်များရှိပြီးသား ပါဝါနည်း AC အားသွင်းကိရိယာများအတွက် 1.6J ကို ဆက်လက်လည်ပတ်ပါ။
2. DC အမြန်အားသွင်းစနစ်အသစ်များPnC နှင့် V2G ကို ပံ့ပိုးပေးရန် မြင့်မားသောပါဝါဖြန့်ကျက်မှုအသစ်အားလုံးအတွက် အမိန့် ၂.၀.၁။
3. ပရိုစီ ဖြေရှင်းချက်များပေါင်းစည်းထားသော စီမံခန့်ခွဲမှု dashboard တစ်ခုတည်းအတွက် ခွင့်ပြုသည့် 1.6J မက်ဆေ့ချ်များကို CSMS အတွက် 2.0.1 နှင့် တွဲဖက်အသုံးပြုနိုင်သော format သို့ ဘာသာပြန်ဆိုနိုင်သည့် protocol gateway တစ်ခုကို အသုံးပြုပါ။

အခန်း ၁၀: အနာဂတ်ကို သက်သေပြခြင်း- OCPP ၂.၁ နှင့် အလိုအလျောက် အားသွင်းခြင်းဆီသို့ ဦးတည်သော လမ်းကြောင်း

၂.၀.၁ သည် လူကြိုက်များလာသည်နှင့်အမျှ Open Charge Alliance သည် OCPP ၂.၁ တွင် လုပ်ဆောင်နေပြီဖြစ်သည်။ ဤအနာဂတ်ဗားရှင်းသည် ပရိုတိုကော၏ လွှမ်းခြုံမှုကို ပိုမိုကျယ်ပြန့်စေမည်ဖြစ်သည်။

၁၀.၁ နှစ်လမ်းသွား အားသွင်းခြင်း (V2X)

2.0.1 သည် အခြေခံ V2G ကို ပံ့ပိုးပေးသော်လည်း 2.1 သည် ယာဉ်မှအိမ်သို့ (V2H) နှင့် ယာဉ်မှအဆောက်အဦသို့ (V2B) အတွက် ဆက်သွယ်ရေးကို ပိုမိုကောင်းမွန်အောင် ပြုလုပ်ပေးမည်ဖြစ်ပြီး လျှပ်စစ်ဓာတ်အားပြတ်တောက်မှုများအတွင်း အိမ်များကို စွမ်းအင်ပေးနိုင်သည် သို့မဟုတ် စီးပွားရေးအဆောက်အအုံများအတွက် အမြင့်ဆုံးဝယ်လိုအားကို လျှော့ချပေးနိုင်မည်ဖြစ်သည်။

၁၀.၂ ကြိုးမဲ့အားသွင်းခြင်းအတွက် ပံ့ပိုးမှု

အလိုအလျောက်မောင်းနှင်နိုင်သော ယာဉ်များ (AV) ပေါ်ပေါက်လာသည်နှင့်အမျှ လက်ဖြင့်ပလပ်ထိုးခြင်းသည် ခေတ်မမီတော့ပါ။ OCPP 2.1 တွင် inductive (ကြိုးမဲ့) အားသွင်းခြင်း၊ လူသားဝင်ရောက်စွက်ဖက်မှုမရှိဘဲ alignment ကို စီမံခန့်ခွဲခြင်းနှင့် စွမ်းအင်လွှဲပြောင်းခြင်းအတွက် စံသတ်မှတ်ထားသော မက်ဆေ့ချ်များ ပါဝင်မည်ဖြစ်သည်။

၁၀.၃ စမတ်မြို့များနှင့် ပေါင်းစည်းခြင်း

အနာဂတ်ဗားရှင်းများတွင် ယာဉ်ကြောစီမံခန့်ခွဲမှုစနစ်များနှင့် ပြန်လည်ပြည့်ဖြိုးမြဲစွမ်းအင်ခန့်မှန်းချက်များနှင့် ပိုမိုနက်ရှိုင်းစွာပေါင်းစပ်မှုကို မြင်တွေ့ရဖွယ်ရှိသည်။ အားသွင်းကိရိယာများသည် အချိန်နှင့်တပြေးညီ စွမ်းအင်ဈေးကွက်များတွင် လျှပ်စစ်ဓာတ်အားအတွက် “တင်ဒါခေါ်ယူ” နိုင်မည်ဖြစ်ပြီး အားသွင်းကွန်ရက်များကို ကြီးမားသော virtual ဓာတ်အားပေးစက်ရုံများ (VPPs) အဖြစ်သို့ ပြောင်းလဲပေးမည်ဖြစ်သည်။

နည်းပညာဆိုင်ရာ နောက်ဆက်တွဲ- မက်ဆေ့ချ်နှိုင်းယှဉ်မှုများကို နက်နက်ရှိုင်းရှိုင်း လေ့လာခြင်း

အဆုံးစွန်သော နည်းပညာဆိုင်ရာ အတိမ်အနက်ကို ပေးစွမ်းနိုင်ရန်အတွက်၊ ယခု ကျွန်ုပ်တို့သည် ဗားရှင်းနှစ်ခုကြားရှိ သီးခြား မက်ဆေ့ချ် အစီအစဉ်များနှင့် frame ကွာခြားချက်များကို ခွဲခြမ်းစိတ်ဖြာပါမည်။

A.1 ခွင့်ပြုချက်လုပ်ငန်းစဉ်

1.6J မှာ ခွင့်ပြုချက်ဟာ “လက်ခံထားသည်” သို့မဟုတ် “ပိတ်ဆို့ထားသည်” ဆိုတဲ့ ဒွိစုံတုံ့ပြန်မှု ဖြစ်ပါတယ်။

၁.၆J ခွင့်ပြုချက်တုံ့ပြန်မှု:"json [3, "123456", { "idTagInfo": { "status": "လက်ခံပြီး", "expiryDate": "2026-12-31T23:59:59Z" } }]"

၂.၀.၁ မှာ တုံ့ပြန်မှုမှာ အောက်ပါအခြေအနေတွေ ပိုမိုပါဝင်ပါတယ်၊ ဥပမာidTokenအသုံးပြုသူ မျက်နှာပြင်အတွက် အမျိုးအစားနှင့် နောက်ထပ်အချက်အလက်များ။

၂.၀.၁ ခွင့်ပြုချက်တုံ့ပြန်မှု-"json [3, "987654", { "idTokenInfo": { "status": "လက်ခံပြီး", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "ပြန်လည်ကြိုဆိုပါတယ် ဂျွန်! ခင်ဗျားရဲ့လက်ကျန်ငွေက $45.00 ပါ" } } }]"

A.၂ နှလုံးခုန်နှုန်းနှင့် ချိတ်ဆက်မှု စီမံခန့်ခွဲမှု

OCPP 2.0.1 သည် ဘူတာရုံသည် "အသက်ရှင်နေသည်" ဟူသော သက်သေပြပုံကို အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ပေးသည်။ 1.6J တွင်၊ aနှလုံးခုန်သံမအောင်မြင်ရင် station က ထပ်ကြိုးစားနေလေ့ရှိပါတယ်။ 2.0.1 မှာ station ကအဖြစ်အပျက်ကို အကြောင်းကြားပါဒုတိယ backend နှင့် ၎င်း၏ ချိတ်ဆက်မှု ပြတ်တောက်သွားကြောင်း အစီရင်ခံရန် ယန္တရား၊ တစ်ချိန်တည်းမှာပင်၊ primary နှင့် heartbeat ကို ထိန်းသိမ်းထားစဉ်။

A.3 အသေးစိတ် မက်တာဒေတာဇယား

နိဂုံးချုပ်

OCPP 1.6J မှ 2.0.1 သို့ ကူးပြောင်းခြင်းသည် ဆော့ဖ်ဝဲလ် အပ်ဒိတ်တစ်ခုမျှသာ မဟုတ်ပါ။ ၎င်းသည် လျှပ်စစ် မိုဘိုင်းလ် ဂေဟစနစ်၏ အခြေခံအဆင့် ဆင့်ကဲဖြစ်စဉ်တစ်ခုဖြစ်သည်။ စီးပွားဖြစ် အော်ပရေတာများအတွက် 1.6J သည် ယုံကြည်စိတ်ချရသော အတိတ်ကို ကိုယ်စားပြုပြီး 2.0.1 သည် တိုးချဲ့နိုင်သော၊ လုံခြုံသော နှင့် ဉာဏ်ရည်ထက်မြက်သော အနာဂတ်ကို ကိုယ်စားပြုသည်။

ဒီနေ့ 2.0.1 ကို ရွေးချယ်ခြင်းဟာ ရေရှည်တည်တံ့မှုအတွက် ရင်းနှီးမြှုပ်နှံမှုတစ်ခုပါပဲ။ ဒါက သင့်ရဲ့ hardware ဟာ နောက်မျိုးဆက် EV တွေနဲ့ တွဲဖက်အသုံးပြုနိုင်မှာဖြစ်ပြီး၊ တင်းကျပ်တဲ့ ဆိုက်ဘာလုံခြုံရေးစည်းမျဉ်းတွေနဲ့ ကိုက်ညီမှာဖြစ်သလို V2G နဲ့ smart grid ပေါင်းစပ်မှုရဲ့ အကျိုးအမြတ်များတဲ့ အခွင့်အလမ်းတွေအတွက် အသင့်ဖြစ်နေမှာဖြစ်ကြောင်း သေချာစေပါတယ်။ ဈေးကွက် ပေါင်းစည်းလာတာနဲ့အမျှ အခိုင်မာဆုံးနဲ့ ပြောင်းလွယ်ပြင်လွယ်အရှိဆုံး protocol stack ရှိတဲ့ operator တွေဟာ ဦးဆောင်သူတွေ ဖြစ်လာပါလိမ့်မယ်။

အခန်း ၁၁: နက်ရှိုင်းစွာ လေ့လာခြင်း- မက်ဆေ့ချ်စီးဆင်းမှု ခွဲခြမ်းစိတ်ဖြာခြင်းနှင့် အစီအစဉ်ဇယားများ

ဤအခန်းတွင်၊ 1.6J နှင့် 2.0.1 အကြား လုပ်ငန်းလည်ပတ်မှု ကွာခြားချက်များကို ပြသရန် EVSE နှင့် CSMS အကြား အပြန်အလှန် ဆက်သွယ်မှု အစီအစဥ်များကို ကျွန်ုပ်တို့ ခွဲခြမ်းစိတ်ဖြာပါသည်။

၁၁.၁ Boot နှင့် Configuration အစီအစဉ်

အားသွင်းကိရိယာတစ်ခုသည် ကွန်ရက်သို့ ပထမဆုံးချိတ်ဆက်သောအခါ၊ ၎င်းသည် ၎င်းကိုယ်တိုင်ကို ခွဲခြားသတ်မှတ်ပြီး ၎င်း၏ဖွဲ့စည်းပုံကို ထပ်တူပြုရမည်။

OCPP 1.6J စီးဆင်းမှု:

1. WebSocket ချိတ်ဆက်မှု: Port 80 သို့မဟုတ် 443 မှတစ်ဆင့် တည်ဆောက်ထားသည်။
2. Boot အကြောင်းကြားချက်: ဘူတာရုံသည် ရောင်းချသူ၊ မော်ဒယ်နှင့် စီရီရယ်ကို ပေးပို့သည်။
3. ပြင်ဆင်မှုရယူပါCSMS သည် လက်ရှိအခြေအနေကို စစ်ဆေးရန် သော့အားလုံးကို တောင်းဆိုသည်။
4. ပြောင်းလဲခြင်းဖွဲ့စည်းပုံCSMS သည် သတ်မှတ်ထားသော သော့များကို အပ်ဒိတ်လုပ်သည် (ဥပမာ-နှလုံးခုန်နှုန်းကြားကာလ).
5. အခြေအနေအကြောင်းကြားချက်: ဘူတာရုံက အစီရင်ခံစာများ “ရရှိနိုင်”။

OCPP ၂.၀.၁ စီးဆင်းမှု-

1. လုံခြုံသော TLS လက်ဆွဲခြင်း: မဖြစ်မနေ လက်မှတ်လဲလှယ်ခြင်း။
2. Boot အကြောင်းကြားချက်: ပါဝင်သည်အကြောင်းပြချက်(ဥပမာ၊ပါဝါအပ်).
3. အခြေခံအစီရင်ခံစာ ရယူပါ: သော့အားလုံးကို တောင်းဆိုမည့်အစား CSMS သည် Device Model ၏ အဆင့်ဆင့်အပြည့်အစုံကို ပေးစွမ်းသည့် “Base Report” ကို တောင်းဆိုသည်။
4. ကိန်းရှင်များ သတ်မှတ်ပါ: CSMS သည် variable များကို အပ်ဒိတ်လုပ်သည်။ 2.0.1 သည် atomic update များကို ခွင့်ပြုကြောင်း သတိပြုပါ—variable များစွာကို မက်ဆေ့ချ်တစ်ခုတည်းတွင် သတ်မှတ်ပြီး အားလုံးအောင်မြင်ကြောင်း သို့မဟုတ် တစ်ခုမျှမအောင်မြင်ကြောင်း သေချာစေသည်။
5. အဖြစ်အပျက်ကို အကြောင်းကြားပါ: ဘူတာသည် ကနဦး အစိတ်အပိုင်း အခြေအနေများကို အစီရင်ခံသည်။

၁၁.၂ စမတ်အားသွင်းခြင်း ညှိနှိုင်းမှု

စမတ်အားသွင်းစနစ်ဟာ 2.0.1 မှာ အထူးသဖြင့် အားသွင်းပရိုဖိုင်များစွာကို ကိုင်တွယ်တဲ့အခါ အမှန်တကယ် ထွန်းတောက်ပါတယ်။

1.6J မှာ CSMS က ပေးပို့ပါတယ်အားသွင်းပရိုဖိုင်ကို သတ်မှတ်ပါ၎င်းသည် stack level နှင့် schedule ကို သတ်မှတ်ပေးသည်။ station တွင် connector များစွာပါရှိပါက profile handling သည် မကြာခဏ မရှင်းလင်းပါ။

၂.၀.၁ မှာ၊အားသွင်းပရိုဖိုင်ကို သတ်မှတ်ပါတစ်ခုနှင့် ရှင်းလင်းစွာ ဆက်စပ်နေသည်အားသွင်းပရိုဖိုင်ရည်ရွယ်ချက်.

• အားသွင်းစခန်းအမြင့်ဆုံးပရိုဖိုင်: ဘူတာရုံတစ်ခုလုံး၏ စုပ်ယူမှုကို ကန့်သတ်ထားသည်။
• TXDefaultProfile: မည်သည့် ငွေပေးငွေယူအသစ်အတွက်မဆို မူရင်း။
• TX ပရိုဖိုင်: လက်ရှိလုပ်ဆောင်နေသော ငွေပေးငွေယူတစ်ခုအတွက် သီးသန့်။

ထို့အပြင်၊ ၂.၀.၁ သည် အောက်ပါတို့ကို ပံ့ပိုးပေးသည်ChargingStackLevel ရယူပါမက်ဆေ့ချ်ကို အသုံးပြု၍ CSMS အား လက်ရှိတွင် မည်သည့်ပရိုဖိုင်များ အသက်ဝင်နေသည်နှင့် EVSE ၏ အတွင်းပိုင်း အချိန်ဇယားဆွဲသူမှ မည်သို့ ဦးစားပေးနေသည်ကို ကြည့်ရှုနိုင်စေပါသည်။

၁၁.၃ အဝေးထိန်းစနစ်ဖြင့် လှုံ့ဆော်ခြင်းနှင့် ထိန်းချုပ်ခြင်း

အဝေးထိန်းအမိန့်များကဲ့သို့သောအဝေးထိန်းစတင်ငွေပေးငွေယူ(၁.၆ ဂျိုး) ကို အစားထိုးလိုက်ပါပြီငွေပေးငွေယူစတင်ရန် တောင်းဆိုခြင်း(၂.၀.၁)။ အဓိကကွာခြားချက်မှာ payload တွင်ဖြစ်သည်။ ၂.၀.၁ တွင် CSMS တွင် ပါဝင်နိုင်သည်အားသွင်းပရိုဖိုင်စတင်ရန်တောင်းဆိုချက်တွင် တိုက်ရိုက်ထည့်သွင်းထားသည်။ ဆိုလိုသည်မှာ ကားသည် ဒုတိယမက်ဆေ့ချ်ကို မစောင့်ဘဲ မှန်ကန်သော ပါဝါအဆင့်တွင် ချက်ချင်းအားသွင်းနိုင်သောကြောင့် နှောင့်နှေးမှုကို လျှော့ချပေးပြီး ဓာတ်အားလိုင်းတည်ငြိမ်မှုကို တိုးတက်ကောင်းမွန်စေသည်။

အခန်း ၁၂: Low-Level JSON Schema နှင့် Field နှိုင်းယှဉ်ချက်များ

developer များနှင့် system integrators များအတွက်၊ schema ပြောင်းလဲမှုများသည် migration ၏ လုပ်အားအသုံးစွဲဆုံးအပိုင်းဖြစ်သည်။

၁၂.၁ စာရင်းပြုစုထားသော အမျိုးအစားများ (Enums)

OCPP 2.0.1 သည် စံသတ်မှတ်ထားသော Enums အရေအတွက်ကို သိသိသာသာ တိုးချဲ့ပေးသောကြောင့် 1.6J အကောင်အထည်ဖော်မှုများတွင် အနှောင့်အယှက်ဖြစ်စေသော “Custom” status code များ လိုအပ်မှုကို လျှော့ချပေးပါသည်။

• အကြောင်းပြချက် Enum များ: ကင်းစောင့်, အချိန်ဇယားဆွဲပြီး ပြန်လည်သတ်မှတ်ခြင်း, အဝေးထိန်းစနစ် ပြန်လည်သတ်မှတ်ခြင်း, ပါဝါဆုံးရှုံးမှု.
• အခြေအနေ Enum များ: သိမ်းပိုက်ထားသည်, ကြိုတင်မှာယူထားသည်, မရနိုင်ပါ, ချို့ယွင်းချက်ရှိ၂.၀.၁ ထည့်သွင်းထားသည်ရရှိနိုင်ပါသည်, သိမ်းပိုက်ထားသည်, ကြိုတင်မှာယူထားသည်, မရနိုင်ပါ, ချို့ယွင်းချက်ရှိဒါပေမယ့် အသေးစိတ်အတွက် sub-status တွေနဲ့အတူ။

၁၂.၂ ဒေတာအမျိုးအစားများနှင့် ယူနစ်များ

OCPP 2.0.1 သည် စံယူနစ်များ (SI) ကို အသုံးပြုခြင်းကို တရားဝင်ဖြစ်စေသည်။ 1.6J သည် တစ်ခါတစ်ရံ ဒဿမတိကျမှုကို မသတ်မှတ်ဘဲ ထားခဲ့သည့်အခါ၊ 2.0.1 သည်ဒဿမပါဝါနှင့် စွမ်းအင်တန်ဖိုးများအတွက် အမျိုးအစားများ၊ ရောင်းချသူအမျိုးမျိုး၏ ဟာ့ဒ်ဝဲများတွင် တသမတ်တည်း ငွေတောင်းခံလွှာပေးပို့ခြင်းကို သေချာစေသည်။

အခန်း ၁၃: ဖြစ်ရပ်လေ့လာမှု- ကမ္ဘာလုံးဆိုင်ရာ စားအုန်းဆီ ၁.၆ ဂျိုးမှ ၂.၀.၁ သို့ ရွှေ့ပြောင်းခြင်း

အားသွင်းအမှတ် ၁၀,၀၀၀ ရှိတဲ့ CPO တစ်ခုဖြစ်တဲ့ “MegaCharge” ရဲ့ ယူဆချက်ဆိုင်ရာ အခြေအနေကို ကြည့်ကြရအောင်။

၁၃.၁ အဆင့် ၁: စာရင်းစစ်ခြင်း

MegaCharge က သူတို့ရဲ့ 1.6J ကားအုပ်စုရဲ့ ၄၀% ဟာ TLS 1.2 ကို မထောက်ပံ့ဘူးဆိုတာ တွေ့ရှိခဲ့ပါတယ်။ ဒါကြောင့် အဲဒီ အားသွင်းကိရိယာတွေဟာ လာမယ့် အစိုးရစာချုပ်တွေအတွက် အရည်အချင်းမပြည့်မီဘူးလို့ ဆိုလိုပါတယ်။

၁၃.၂ အဆင့် ၂: CSMS အဆင့်မြှင့်တင်မှု

CSMS အသစ်တစ်ခုတည်ဆောက်မည့်အစား MegaCharge သည် “OCPP Translation Layer” ကို အကောင်အထည်ဖော်ခဲ့သည်။ ဤအလွှာသည် ဟာ့ဒ်ဝဲအဟောင်းအတွက် 1.6J ချိတ်ဆက်မှုများနှင့် ဟာ့ဒ်ဝဲအသစ်အတွက် 2.0.1 ချိတ်ဆက်မှုများကို ကိုင်တွယ်ခဲ့သော်လည်း ၎င်းတို့၏ မိုဘိုင်းအက်ပ်နှင့် ငွေတောင်းခံအင်ဂျင်သို့ ပေါင်းစည်းထားသော API တစ်ခုကို ဖော်ထုတ်ခဲ့သည်။

၁၃.၃ အဆင့် ၃: ဟာ့ဒ်ဝဲအစားထိုးခြင်း

လူအသွားအလာများသောနေရာများအတွက် MegaCharge သည် 1.6J အားသွင်းကိရိယာများကို 2.0.1 နှင့်ကိုက်ညီသော DC အမြန်အားသွင်းကိရိယာများဖြင့် အစားထိုးခဲ့သည်။ ရလဒ်အနေဖြင့် “စတင်ရန်ပျက်ကွက်ခြင်း” အစည်းအဝေးများတွင် ၁၅% လျော့ကျသွားခဲ့ပြီး အဓိကအားဖြင့် ပိုမိုခိုင်မာသောကြောင့်ဖြစ်သည်။ငွေပေးငွေယူဖြစ်ရပ်၂.၀.၁ တွင် ကိုင်တွယ်ခြင်း။

၁၃.၄ ROI ခွဲခြမ်းစိတ်ဖြာခြင်း

ကနဦးရင်းနှီးမြှုပ်နှံမှုမှာ ဒေါ်လာ ၂ သန်းဖြစ်သည်။ သို့သော်၊ ပြုပြင်ထိန်းသိမ်းမှုခေါ်ဆိုမှုများ လျော့နည်းသွားခြင်း (Device Model ၏ ရောဂါရှာဖွေရေးကြောင့်) သည် တစ်နှစ်လျှင် ဒေါ်လာ ၄၀၀,၀၀၀ ချွေတာနိုင်ခဲ့သည်။ ထို့အပြင်၊ V2G ကြိမ်နှုန်းတုံ့ပြန်မှုဈေးကွက်များတွင် ပါဝင်နိုင်ခြင်းသည် နှစ်စဉ်ဝင်ငွေ ဒေါ်လာ ၂၀၀,၀၀၀ ထပ်မံရရှိခဲ့သည်။ ပြန်ဆပ်ရမည့်ကာလမှာ ၃.၃ နှစ်ခန့်ဖြစ်သည်။

အခန်း ၁၄: OCPP ၂.၀.၁ ဝယ်ယူမှုအတွက် ဝယ်သူ၏ နောက်ဆုံးစစ်ဆေးရမည့်စာရင်း

ဟာ့ဒ်ဝဲ သို့မဟုတ် ဆော့ဖ်ဝဲအသစ်များကို အကဲဖြတ်သည့်အခါ ကိုက်ညီမှုရှိမရှိ သေချာစေရန်အတွက် ဤစစ်ဆေးရမည့်စာရင်းကို အသုံးပြုပါ။

၁၄.၁ ဟာ့ဒ်ဝဲ (EVSE) လိုအပ်ချက်များ

• [ ]လုံခြုံရေးပရိုဖိုင် ၃ ပံ့ပိုးမှုclient-side certificate management ကို support လုပ်ပါသလား။
• [ ]Dual-Core ပရိုဆက်ဆာTLS encryption နဲ့ JSON parsing အတွက် နေရာအလုံအလောက်ရှိပါသလား။
• [ ]လုံခြုံသော အစိတ်အပိုင်း (SE)ကီးတွေကို သိမ်းဆည်းဖို့အတွက် board မှာ hardware root of trust ရှိလား။
• [ ]ISO 15118-2/20 အသင့်ဖြစ်ပါပြီPnC အတွက် လိုအပ်သော မြင့်မားသောအဆင့်ဆက်သွယ်မှုကို ထိန်းချုပ်ကိရိယာက ကိုင်တွယ်နိုင်ပါသလား။
• [ ]မျက်နှာပြင်စွမ်းရည်ဟာ့ဒ်ဝဲက OCPP မှတစ်ဆင့် ဈေးနှုန်း/အခြေအနေ အချက်အလက်များကို ပြသပေးပါသလား။ဒေတာလွှဲပြောင်းခြင်းဒါမှမဟုတ် မူရင်းစာတွေလား။

၁၄.၂ ဆော့ဖ်ဝဲ (CSMS) လိုအပ်ချက်များ

• [ ]စက်ပစ္စည်းမော်ဒယ် မြင်ယောင်ခြင်းဒက်ရှ်ဘုတ်မှာ အားသွင်းကိရိယာရဲ့ အဆင့်ဆင့်မြင်ကွင်းကို ပြသနိုင်ပါသလား။
• [ ]လက်မှတ်အာဏာပိုင် (CA) ပေါင်းစည်းမှုCSMS က အလိုအလျောက် လက်မှတ်တွေ ထုတ်ပေးပြီး အလှည့်ကျ လဲလှယ်နိုင်ပါသလား။
• [ ]ငွေပေးငွေယူ ညှိနှိုင်းခြင်း1.6J legacy chargers တွေကနေ “hanging” transaction တွေကို system က ဘယ်လိုကိုင်တွယ်သလဲ။
• [ ]စမတ်အားသွင်းအင်ဂျင်2.0.1 ရဲ့ advanced stack-level logic ကို support လုပ်ပါသလား။
• [ ]တိုးချဲ့နိုင်မှုWebSocket handler သည် persistent TLS ချိတ်ဆက်မှု ၅၀,၀၀၀+ ကို တစ်ပြိုင်နက်တည်း စီမံခန့်ခွဲနိုင်ပါသလား။

အခန်း ၁၅: OCPP အကောင်အထည်ဖော်မှုပြဿနာများကို ဖြေရှင်းခြင်း

စံနှုန်းတစ်ခုနဲ့တောင်မှ အကောင်အထည်ဖော်မှုတွေ ကွဲပြားပါတယ်။ အဖြစ်အများဆုံး “လွဲချော်မှု” တွေကို ဖော်ပြပေးလိုက်ပါတယ်။

၁၅.၁ WebSocket အချိန်ကုန်ခြင်း

ကွန်ရက် firewall အများအပြားသည် အလုပ်မလုပ်သော TCP ချိတ်ဆက်မှုများကို ပိတ်သည်။ အကယ်၍နှလုံးခုန်နှုန်းကြားကာလမြင့်မားလွန်းပါက အားသွင်းကိရိယာ ဖြုတ်ထားနိုင်သည်။

• ဖြေရှင်းချက်သေချာစေပါနှလုံးခုန်နှုန်းကြားကာလfirewall ရဲ့ timeout (ပုံမှန်အားဖြင့် ၆၀-၁၂၀ စက္ကန့်) ထက် နည်းပါတယ်။

၁၅.၂ လက်မှတ်ကွင်းဆက်ပြဿနာများ

၂.၀.၁ မှာ အဖြစ်များတဲ့ ချို့ယွင်းချက်တစ်ခုကတော့ “ယုံကြည်ရမှုမရှိတဲ့ လက်မှတ်” အမှားပါ။ ဒါက အားသွင်းကိရိယာမှာ CSMS ရဲ့ Root CA မထည့်သွင်းထားတဲ့အခါ ဖြစ်လေ့ရှိပါတယ်။

• ဖြေရှင်းချက်: ကိုသုံးပါအသိအမှတ်ပြုလက်မှတ် ထည့်သွင်းပါယုံကြည်မှုကွင်းဆက် ပြီးစီးကြောင်းသေချာစေရန် commissioning လုပ်နေစဉ်အတွင်း မက်ဆေ့ချ်ပို့ခြင်း။

၁၅.၃ JSON Payload အရွယ်အစား

၂.၀.၁ မက်ဆေ့ချ်အချို့ (ဥပမာအခြေခံအစီရင်ခံစာ ရယူပါ) အလွန်ကြီးမားနိုင်သည်။ အားသွင်းကိရိယာ၏ ဘာဖာသည် အလွန်သေးငယ်ပါက မက်ဆေ့ချ်ကို ချပေးလိမ့်မည်။

• ဖြေရှင်းချက်: စစ်ဆေးပါအများဆုံးမက်ဆေ့ချ်အရွယ်အစားDevice Model တွင် variable ကို ထည့်သွင်းပြီး CSMS သည် ဤကန့်သတ်ချက်ကို လိုက်နာကြောင်း သေချာပါစေ။

အခန်း ၁၆: ဒေသဆိုင်ရာ စည်းမျဉ်းစည်းကမ်းဆိုင်ရာ ရှုခင်းများနှင့် ပရိုတိုကောဆိုင်ရာ အမိန့်များ

OCPP 2.0.1 သို့ ရွေ့လျားခြင်းသည် နည်းပညာကြောင့်သာ မဟုတ်ဘဲ ဥပဒေနှင့် သက်ဆိုင်သည့် ကိစ္စတစ်ခု ဖြစ်လာပါသည်။

၁၆.၁ ဥရောပသမဂ္ဂ (AFIR)

EU ရှိ အခြားရွေးချယ်စရာလောင်စာအခြေခံအဆောက်အအုံစည်းမျဉ်း (AFIR) သည် ဈေးနှုန်းပွင့်လင်းမြင်သာမှုနှင့် အပြန်အလှန်လုပ်ဆောင်နိုင်မှုကို ပြဋ္ဌာန်းထားသည်။ OCPP 2.0.1 ကို ရှင်းလင်းစွာဖော်ပြထားခြင်းမရှိသော်လည်း “အချိန်နှင့်တပြေးညီဒေတာမျှဝေခြင်း” နှင့် “စမတ်အားသွင်းခြင်း” အတွက် လိုအပ်ချက်ကြောင့် 2.0.1 သည် အများပြည်သူသုံးအခြေခံအဆောက်အအုံအသစ်များအတွက် တစ်ခုတည်းသော လက်တွေ့ကျသောစံနှုန်းဖြစ်လာစေသည်။

၁၆.၂ မြောက်အမေရိက (NEVI)

အမေရိကန်ပြည်ထောင်စုတွင် အမျိုးသားလျှပ်စစ်ယာဉ်အခြေခံအဆောက်အအုံ (NEVI) ဖော်မြူလာအစီအစဉ်သည် အားသွင်းကိရိယာများသည် “အပြန်အလှန်လုပ်ဆောင်နိုင်ရမည်” ဟု လိုအပ်သည်။ ကယ်လီဖိုးနီးယားကဲ့သို့သော ပြည်နယ်များသည် ပိုမိုလုပ်ဆောင်နေပြီး ကယ်လီဖိုးနီးယားစွမ်းအင်ကော်မရှင် (CEC) သည် ISO 15118 ပံ့ပိုးမှုအတွက် တွန်းအားပေးနေပြီး ကျွန်ုပ်တို့ဆွေးနွေးခဲ့သည့်အတိုင်း OCPP 2.0.1 မှတစ်ဆင့် အကောင်းဆုံးအကောင်အထည်ဖော်ရန်ဖြစ်သည်။

၁၆.၃ တရုတ်နှင့် အာရှ-ပစိဖိတ်

တရုတ်နိုင်ငံတွင် ၎င်း၏ကိုယ်ပိုင်စံနှုန်းများ (GB/T) ရှိသော်လည်း၊ ပို့ကုန်ကိုအာရုံစိုက်သော ထုတ်လုပ်သူများသည် OCPP 2.0.1 တွင် များစွာရင်းနှီးမြှုပ်နှံထားကြသည်။ ဩစတြေးလျနှင့် စင်ကာပူကဲ့သို့သော ဈေးကွက်များတွင်၊ အများပြည်သူသုံး အားသွင်းကွန်ရက်များအတွက် အစိုးရတင်ဒါများသည် ယခုအခါ Security Profile 3 ပါသည့် OCPP 2.0.1 ကိုသာ သတ်မှတ်ပေးလျက်ရှိသည်။

အခန်း ၁၇: အကောင်အထည်ဖော်မှုကုဒ်အပိုင်းအစများ- “အသေးစိတ်အချက်အလက်များ”

ဆော့ဖ်ဝဲရေးသားသူများကို ကူညီရန်အတွက်၊ ကျွန်ုပ်တို့သည် ရှုပ်ထွေးသော 2.0.1 လုပ်ငန်းများအတွက် သဘောတရားဆိုင်ရာ JSON ကိုယ်စားပြုမှုများကို ပံ့ပိုးပေးပါသည်။

၁၇.၁ လက်မှတ်လည်ပတ်မှုလုပ်ငန်းစဉ်

လက်မှတ်သက်တမ်းကုန်ဆုံးတော့မည့်အချိန်တွင် CSMS သည် လည်ပတ်မှုကို စတင်ရမည်။

၁။ CSMS ပေးပို့သည်လက်မှတ်ရေးပြီး:"json [2, "CERT-01", "CertificateSigned", { "certificateChain": "-----လက်မှတ်စတင်ပါ-----\n...\n-----လက်မှတ်ပြီးဆုံးပါ-----", "certificateType": "V2G" }]"

၂။ ဘူတာရုံက တုံ့ပြန်သည်လက်ခံပြီးပါပြီ:"json [3, "CERT-01", { "status": "လက်ခံပြီး" }]"

၃။ ဘူတာရုံမှ ပေးပို့သည်လုံခြုံရေးဖြစ်ရပ်အကြောင်းကြားစာ:"json [2, "EVT-99", "SecurityEventNotification", { "type": "CertificateRotated", "timestamp": "2026-08-09T10:00:00Z" }]"

၁၇.၂ Grid-Responsive Charging Profile တစ်ခု သတ်မှတ်ခြင်း

ဓာတ်အားလိုင်းအော်ပရေတာသည် ကွန်ရက်တစ်လျှောက်တွင် ဓာတ်အားကို လျှော့ချရန် လိုအပ်သည်ဟု မြင်ယောင်ကြည့်ပါ။

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 } ] } } }]"

အခန်း ၁၈: OCPP ၂.၀.၁ အသုံးအနှုန်းများ၏ ပြည့်စုံသော ဝေါဟာရစာရင်း

အကျိုးတူပါဝင်သူအားလုံးအတွက် ရှင်းလင်းပြတ်သားမှုရှိစေရန်အတွက်၊ ကျွန်ုပ်တို့သည် ချဲ့ထွင်ထားသော ဝေါဟာရစာရင်းကို ပံ့ပိုးပေးပါသည်။

• CSMS (အားသွင်းစခန်းစီမံခန့်ခွဲမှုစနစ်)အားသွင်းကိရိယာများကို ထိန်းချုပ်သည့် backend cloud platform။
• EVSE (လျှပ်စစ်ယာဉ်ထောက်ပံ့ရေးပစ္စည်းကိရိယာ)ရုပ်ပိုင်းဆိုင်ရာ အားသွင်းစခန်း။
• OCPP (ပွင့်လင်းသော အားသွင်းအမှတ် ပရိုတိုကော)သူတို့ပြောတဲ့ ဘာသာစကား။
• OCA (Open Charge Alliance)ဘာသာစကားကို ရေးသားသော အဖွဲ့အစည်း။
• ISO ၁၅၁၁၈ကားနှင့် အားသွင်းကိရိယာကြားရှိ ပရိုတိုကော။
• PnC (ပလပ်ထိုးပြီး အားသွင်းခြင်း)ISO 15118 နှင့် OCPP 2.0.1 မှ ဖွင့်ထားသော အသုံးပြုသူအတွေ့အကြုံ။
• V2G (ယာဉ်မှ ဂရစ်သို့)ကားမှ ဓာတ်အားလိုင်းသို့ ပြန်ပို့ခြင်း။
• V2X (ယာဉ်မှ အရာအားလုံးသို့)V2G၊ V2H နှင့် V2B တို့အတွက် ထီးသုံးအသုံးအနှုန်း။
• TLS (သယ်ယူပို့ဆောင်ရေးအလွှာလုံခြုံရေး)ဒေတာကို လုံခြုံစွာထားရှိပေးသော ကုဒ်ဝှက်ခြင်း။
• PKI (အများပြည်သူ့သော့ အခြေခံအဆောက်အအုံ)လုံခြုံရေးအတွက် အသုံးပြုသော ဒစ်ဂျစ်တယ် လက်မှတ်များ စနစ်။
• JSON (JavaScript Object Notation): မက်ဆေ့ချ်များ၏ ပုံစံ။
• ဝဘ်ဆော့ကက်: မက်ဆေ့ချ်များ စီးဆင်းသည့် အမြဲတမ်းချိတ်ဆက်မှု “ပိုက်”။
• စက်ပစ္စည်း မော်ဒယ်2.0.1 မှာ ဟာ့ဒ်ဝဲကို အဆင့်ဆင့်ဖော်ပြတဲ့ နည်းလမ်း။
• အစိတ်အပိုင်းဟာ့ဒ်ဝဲ၏ အစိတ်အပိုင်းတစ်ခု (ဥပမာ၊ Connector)။
• ပြောင်းလဲနိုင်သောအစိတ်အပိုင်းတစ်ခု၏ ဂုဏ်သတ္တိတစ်ခု (ဥပမာ၊ Status)။
• ဂုဏ်သတ္တိ: variable တစ်ခုနှင့်ပတ်သက်သော metadata (ဥပမာ၊ Value၊ Mutability)။
• ငွေပေးငွေယူဖြစ်ရပ်: 2.0.1 ရှိ session data အားလုံးအတွက် စုစည်းထားသော မက်ဆေ့ချ်။
• နှလုံးခုန်သံ: “ကျွန်တော်/ကျွန်မ အသက်ရှင်နေသေးတယ်” ဆိုတဲ့ ပုံမှန်အချက်ပြမှု။
• Boot အကြောင်းကြားချက်အားသွင်းကိရိယာစတင်လည်ပတ်သည့်အခါ “ဟဲလို၊ ကျွန်တော်/ကျွန်မ ရောက်ပါပြီ” အချက်ပြမှု။
• ဒေတာလွှဲပြောင်းခြင်း: ရောင်းချသူ-သီးသန့် extension များအတွက် "catch-all" မက်ဆေ့ချ် (သတိထားအသုံးပြုပါ!)။

နောက်ဆုံးအတွေးများ- ဘက်စုံပရိုတိုကောခေတ်ကို လမ်းညွှန်ခြင်း

ဝယ်သူ သို့မဟုတ် အော်ပရေတာတစ်ဦးအနေဖြင့် အရေးကြီးဆုံးအချက်မှာ ကျွန်ုပ်တို့သည် လုပ်ငန်းစဉ်တစ်ခုသို့ ဝင်ရောက်နေခြင်းဖြစ်သည်။ပရိုတိုကောလ်များစွာပါဝင်သောခေတ်နောက် ၃ နှစ်မှ ၅ နှစ်အတွင်း 1.6J နှင့် 2.0.1 တို့သည် တစ်ပြိုင်နက်တည်း တည်ရှိနေမည်ဖြစ်သည်။ သို့သော် ချိန်ခွင်လျှာမှာ လျင်မြန်စွာ ပြောင်းလဲနေပါသည်။

OCPP 2.0.1 ကို ယနေ့ ရွေးချယ်ခြင်းဖြင့် သင်သည် protocol တစ်ခုကို ဝယ်ယူရုံသာမက အာမခံကိုလည်း ဝယ်ယူနေခြင်းဖြစ်သည်။ သင့်ကွန်ရက်သည် ကားအသစ်များ၊ ဥပဒေအသစ်များနှင့် ဝင်ငွေစီးဆင်းမှုအသစ်များနှင့် လိုက်လျောညီထွေဖြစ်အောင် လုပ်ဆောင်နိုင်ကြောင်း သေချာစေပါသည်။ 2.0.1 ၏ ရှုပ်ထွေးမှုသည် တိုးတက်မှု၏ တန်ဖိုးဖြစ်သည် - တိုးတက်ကောင်းမွန်သော uptime၊ လျော့နည်းသောအန္တရာယ်နှင့် ပိုမိုကောင်းမွန်သော ဖောက်သည်အတွေ့အကြုံတို့ဖြင့် ၎င်းကိုယ်တိုင် ပေးဆပ်ရမည့် တန်ဖိုးဖြစ်သည်။

စီးပွားဖြစ်အားသွင်းခြင်းသည် သီးသန့်လုပ်ငန်းတစ်ခုမဟုတ်တော့ပါ။ ၎င်းသည် အနာဂတ်သယ်ယူပို့ဆောင်ရေးစနစ်၏ အဓိကကျောရိုးဖြစ်သည်။ ထိုကျောရိုးကို အခိုင်မာဆုံးအုတ်မြစ်ပေါ်တွင် တည်ဆောက်ပါ- OCPP 2.0.1။

အခန်း ၁၉: OCPP ၂.၀.၁ အတွက် တီထွင်ခြင်း: ဆော့ဖ်ဝဲအင်ဂျင်နီယာများအတွက် အကောင်းဆုံးလုပ်ဆောင်မှုများ

1.6J codebase ကနေ 2.0.1 ကို ပြောင်းလဲတာဟာ refactor မဟုတ်ပါဘူး၊ ပြန်လည်ရေးသားခြင်းပဲ ဖြစ်ပါတယ်။ developer တွေဟာ မတူညီတဲ့ mental model တစ်ခုကို လက်ခံကျင့်သုံးရပါမယ်။

၁၉.၁။ တစ်ပြိုင်နက်တည်းမဟုတ်ခြင်းကို လက်ခံခြင်း

WebSockets များသည် မူလက asynchronous ဖြစ်သော်လည်း၊ 2.0.1 ၏ ရှုပ်ထွေးမှုကြောင့် တစ်ခုတည်းသော request (ဥပမာအခြေခံအစီရင်ခံစာ ရယူပါ) သည် resource-constrained EVSE တွင် processor လုပ်ရန် စက္ကန့်အနည်းငယ်ကြာနိုင်သည်။ CSMS developer များသည် hardware vendor အမျိုးမျိုး၏ processing speed အမျိုးမျိုးကို ထည့်သွင်းစဉ်းစားသည့် ခိုင်မာသော timeout နှင့် retry logic ကို အကောင်အထည်ဖော်ရမည်။

၁၉.၂ ထိရောက်သော JSON ခွဲခြမ်းစိတ်ဖြာခြင်း

JSON parsing ဟာ ​​CPU-intensive ဖြစ်နိုင်ပါတယ်။ EVSE firmware အတွက် developer တွေဟာ payload တစ်ခုလုံးကို RAM ထဲကို load လုပ်မယ့်အစား stream-based parsers တွေကို အသုံးပြုသင့်ပါတယ်။ ဒါဟာ အထူးသဖြင့် အရေးကြီးပါတယ်။အဖြစ်အပျက်ကို အကြောင်းကြားပါမက်ဆေ့ချ်များ၊ ၎င်းတွင် frame တစ်ခုတည်းတွင် variable update ရာပေါင်းများစွာ ပါဝင်နိုင်သည်။

၁၉.၃ နိုင်ငံတော်ယန္တရားကို ကိုင်တွယ်ခြင်း

၂.၀.၁ ရှိ ငွေပေးငွေယူအတွက် အခြေအနေစက်သည် ၁.၆J ထက် ပိုမိုတင်းကျပ်သည်။ ဆော့ဖ်ဝဲရေးသားသူများသည် အကူးအပြောင်းစည်းမျဉ်းများကို တင်းကြပ်စွာလိုက်နာရမည်။ငွေပေးငွေယူဖြစ်ရပ်ဥပမာအားဖြင့်၊ သင်သည် ပေးပို့၍မရပါပြီးဆုံးသွားပါပြီအရင်ဆုံး မပို့ဘဲနဲ့ ဖြစ်ရပ်တစ်ခုစတင်ခဲ့သည်အဲဒီတိကျတဲ့ဖြစ်ရပ်အတွက်ငွေပေးငွေယူ ID.

အခန်း ၂၀: စမ်းသပ်ခြင်း၊ အတည်ပြုခြင်းနှင့် OCPP လိုက်နာမှုစမ်းသပ်ကိရိယာ (OCTT)

အပြန်အလှန်လုပ်ဆောင်နိုင်မှုသည် OCPP ၏ ကတိကဝတ်ဖြစ်သော်လည်း ၎င်းကို တင်းကျပ်သော စမ်းသပ်မှုများဖြင့်သာ အကောင်အထည်ဖော်နိုင်သည်။

၂၀.၁ OCA အသိအမှတ်ပြုလက်မှတ်၏ အခန်းကဏ္ဍ

Open Charge Alliance သည် အသိအမှတ်ပြုလက်မှတ်အစီအစဉ်တစ်ခုကို ပေးဆောင်သည်။ ဝယ်ယူသူများသည် “OCPP 2.0.1 Certified” အညွှန်းကို ရှာဖွေသင့်သည်။ ဤအသိအမှတ်ပြုလက်မှတ်သည် မဖြစ်မနေလိုအပ်သော ပရိုဖိုင်အားလုံးကို လွှမ်းခြုံထားသော အလိုအလျောက်စမ်းသပ်မှုအစုံကို အောင်မြင်ကြောင်း သေချာစေသည်။

၂၀.၂ OCTT ကို အသုံးပြုခြင်း

OCPP လိုက်နာမှုစမ်းသပ်ကိရိယာ (OCTT) သည် စမ်းသပ်မှုအတွက် ရွှေစံနှုန်းဖြစ်သည်။ ၎င်းသည် CSMS နှင့် EVSE နှစ်မျိုးလုံးကို တုပပေးသည်။

• EVSE ထုတ်လုပ်သူများအတွက်: သင့်စခန်းသည် “happy path” အခြေအနေများနှင့် edge case များ (firmware update လုပ်နေစဉ် network drop များကဲ့သို့) ကို ကိုင်တွယ်ကြောင်း အတည်ပြုရန် OCTT ကို အသုံးပြုပါ။
• CSMS ဝန်ဆောင်မှုပေးသူများအတွက်: သင့် backend သည် များပြားလှသော မက်ဆေ့ချ်အမျိုးမျိုးနှင့် 2.0.1 ၏ တင်းကျပ်သော လုံခြုံရေးလိုအပ်ချက်များကို ကိုင်တွယ်နိုင်ကြောင်း သေချာစေရန် OCTT ကို အသုံးပြုပါ။

၂၀.၃ ကွင်းဆင်းစမ်းသပ်ခြင်းနှင့် အပြန်အလှန်စမ်းသပ်မှုများ

အလိုအလျောက်စမ်းသပ်ခြင်းအပြင်၊ OCA သည် ရောင်းချသူများသည် ၎င်းတို့၏ ဟာ့ဒ်ဝဲနှင့် ဆော့ဖ်ဝဲကို လက်တွေ့ကမ္ဘာအခြေအနေများတွင် အချင်းချင်းစမ်းသပ်ရန် ယူဆောင်လာသည့် “Plugfests” ကို စီစဉ်သည်။ ဤနေရာတွင် လက်မှတ်မကိုက်ညီမှု သို့မဟုတ် အသေးစား JSON ဖော်မတ်ချမှုကွာခြားချက်များကဲ့သို့သော အသိမ်မွေ့ဆုံး ချို့ယွင်းချက်များကို တွေ့ရှိပြီး ဖြေရှင်းသည်။

အခန်း ၂၁: နက်ရှိုင်းသော နှိုင်းယှဉ်ဇယား- OCPP ၂.၀.၁ ၏ လုပ်ဆောင်ချက် ၆၀+

အပြည့်အစုံကိုးကားနိုင်ရန်အတွက် 2.0.1 ၏ အဓိကမက်ဆေ့ချ်များကို အမျိုးအစားခွဲခြားပြီး ၎င်းတို့၏ 1.6J မိတ်ဖက်များနှင့် နှိုင်းယှဉ်ပါသည်။

၂၁.၁ ပံ့ပိုးပေးခြင်းနှင့် ပြင်ဆင်သတ်မှတ်ခြင်း

၂၁.၂ ငွေပေးငွေယူ ကိုင်တွယ်ခြင်း

၂၁.၃ လုံခြုံရေးနှင့် Firmware စီမံခန့်ခွဲမှု

၂၁.၄ ဇယားက သင့်ကွန်ရက်အတွက် ဘာကိုဆိုလိုသလဲ

ဇယားမှာ မှားယွင်းစရာအချက်တစ်ခုကို ဖော်ပြထားတာကတော့ OCPP 2.0.1 ဟာ 1.6J ရဲ့ အလှကုန်အမည်ပြောင်းတာ မဟုတ်ပါဘူး။ မက်ဆေ့ချ်မိသားစုအသစ် — ရိုက်ထည့်ထားတဲ့ variable တွေ၊ event-driven transaction တွေနဲ့ certificate management — တွေဟာ Plug & Charge၊ smart charging နဲ့ regulatory reporting အတွက် လိုအပ်တဲ့ ပိုက်လိုင်းတွေ ဖြစ်ပါတယ်။ 1.6J သာပြောတဲ့ charger ကို gateway နဲ့ ပြန်လည်တပ်ဆင်နိုင်ပေမယ့် 1.6J သာပြောတဲ့ CSMS ကတော့ လုံခြုံရေးမော်ဒယ် regulator တွေနဲ့ ကားထုတ်လုပ်သူတွေ ပိုပိုပြီးလိုအပ်လာတဲ့ security model ကို မပေးနိုင်ပါဘူး။ hardware ကို အကဲဖြတ်တဲ့အခါ “2.0.1-ready” ဆိုတာ firmware ကို ဒီနေ့ ပို့ဆောင်ပေးမယ်လို့ ဆိုလိုပြီး နောက်နှစ်အတွက် စီစဉ်ထားတာ မဟုတ်ပါဘူး။ OCPP 2.0.1 ဟာ 1.6J ရဲ့ SOAP transport အစား JSON-over-WebSocket မှာ လည်ပတ်တာကြောင့် မက်ဆေ့ချ်စီးဆင်းမှုတွေက ပိုမိုပေါ့ပါးပြီး debug လုပ်ရတာ ပိုမိုလွယ်ကူပါတယ် — သင့်ရဲ့ IT အဖွဲ့ဟာ ပထမဆုံးနေ့ကတည်းက ခံစားရမယ့် လက်တွေ့ကျတဲ့ အားသာချက်တစ်ခုပါပဲ။

အခန်း ၂၂: နိဂုံးချုပ်: အဆင့်မြှင့်တင်မှုဆုံးဖြတ်ချက်ချခြင်း

စီးပွားဖြစ် အော်ပရေတာတစ်ဦးအတွက် လက်တွေ့ကျသော လမ်းညွှန်ချက်မှာ ရှင်းလင်းပါသည်-

• ဖြန့်ကျက်မှုအသစ်များသည် OCPP 2.0.1 သို့ မူရင်းအတိုင်း ဖြစ်သင့်သည်။လုံခြုံရေးမော်ဒယ်၊ လက်မှတ်ကိုင်တွယ်ခြင်းနှင့် ISO 15118 ပေါင်းစပ်ခြင်းသည် ၂၀၂၆ စည်းမျဉ်းစည်းကမ်းပတ်ဝန်းကျင်အတွက် မရှိမဖြစ်လိုအပ်ချက်များဖြစ်သည်။
• ရှိပြီးသား 1.6J ယာဉ်စုများသည် သောင်တင်နေခြင်းမရှိပါ။2.0.1-native hardware ကို အဆင့်လိုက်ထည့်သွင်းနေစဉ်တွင် Managed gateways များနှင့် dual-protocol CSMS platforms များသည် ကွာဟချက်ကို ပေါင်းကူးပေးပါသည်။
• ယုံကြည်ခင်မှာ စမ်းသပ်ကြည့်ပါ။OCTT၊ plugfests နှင့် staged rollouts များကို အသုံးပြုပါ — အပြန်အလှန်လုပ်ဆောင်နိုင်မှုကို datasheet မှ ယူဆထားခြင်းမဟုတ်ဘဲ လက်တွေ့တွင် သက်သေပြနိုင်ပါသည်။
• ရွှေ့ပြောင်းမှုလမ်းကြောင်းကို စာဖြင့်ရေးသားတောင်းဆိုပါ။သင့်ရဲ့ အားသွင်းကိရိယာ ရောင်းချသူက 1.6J မှ 2.0.1 အထိ firmware roadmap ကို မရေမရာကတိတွေနဲ့အတူ ရက်စွဲတွေနဲ့ ထုတ်ပြန်သင့်ပါတယ်။

လုပ်ဆောင်ရန် တိုက်တွန်းချက်- သင်၏ ပရိုတိုကော မဟာဗျူဟာအကြောင်း 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.