ການປຽບທຽບຍຸດທະສາດຂອງ 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 ທີ່ເຮັດໃຫ້ອຸດສາຫະກຳເປັນເອກະພາບຢ່າງແທ້ຈິງ.

1.1 ການຄອບງຳຂອງ OCPP 1.6J

OCPP 1.6 ໄດ້ເປີດຕົວໃນປີ 2015, ເຊິ່ງໄດ້ນຳສະເໜີການປະຕິບັດ 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 ແບບຖາວອນ, ເຊິ່ງອະນຸຍາດໃຫ້ມີການສື່ສານແບບ full-duplex. ນີ້ແມ່ນສິ່ງສຳຄັນສຳລັບການດຳເນີນງານແບບເວລາຈິງ, ເຊັ່ນ: ການຢຸດຊ່ວງການສາກໄຟຈາກແອັບມືຖື ຫຼື ການຮັບການແຈ້ງເຕືອນຂໍ້ບົກພ່ອງທັນທີ.

2.2 ການແຍກເຟຣມຂໍ້ຄວາມ

ຂໍ້ຄວາມ OCPP ທົ່ວໄປປະກອບດ້ວຍ ID ປະເພດຂໍ້ຄວາມ, ID ຂໍ້ຄວາມທີ່ເປັນເອກະລັກ, ຊື່ການກະທຳ, ແລະ payload.

ຕົວຢ່າງເຟຣມ OCPP 1.6J (ການແຈ້ງເຕືອນການເປີດເຄື່ອງ)

"json [2, "123456", "ການແຈ້ງເຕືອນການບູດ", { "chargePointVendor": "MidaPower", "chargePointModel": "Terra-X", "chargePointSerialNumber": "SN001", "firmwareVersion": "v1.2.3" }]"

ຕົວຢ່າງເຟຣມ OCPP 2.0.1 (ການແຈ້ງເຕືອນການເປີດເຄື່ອງ)

"json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`ສັງເກດເຫັນຄວາມລະອຽດທີ່ເພີ່ມຂຶ້ນໃນ 2.0.1.ພາກສະໜາມ reason` ຊ່ວຍໃຫ້ CSMS ເຂົ້າໃຈວ່າການບູດແມ່ນເກີດຈາກການຣີບູດ, ການເປີດເຄື່ອງ, ຫຼື ຕົວກະຕຸ້ນການເຝົ້າລະວັງ, ເຊິ່ງເຮັດໃຫ້ມີເຫດຜົນການວິນິດໄສດີຂຶ້ນ.

ບົດທີ 3: ການປ່ຽນແປງແບບຢ່າງທາງສະຖາປັດຕະຍະກຳ: ຮູບແບບອຸປະກອນ

ການປ່ຽນແປງທາງດ້ານເຕັກນິກທີ່ສຳຄັນທີ່ສຸດໃນ OCPP 2.0.1 ແມ່ນການນຳສະເໜີຮຸ່ນອຸປະກອນ.

3.1 ຂໍ້ຈຳກັດຂອງຄີການຕັ້ງຄ່າ 1.6J

ໃນ OCPP 1.6J, ການຕັ້ງຄ່າຮາດແວໄດ້ຖືກຈັດການຜ່ານລາຍຊື່ຮາບພຽງຂອງ "ລະຫັດການຕັ້ງຄ່າ" (ຕົວຢ່າງ,ຊ່ວງເວລາການເຕັ້ນຂອງຫົວໃຈ, ໝົດເວລາການເຊື່ອມຕໍ່). ຍ້ອນວ່າເຄື່ອງສາກໄຟມີຄວາມຊັບຊ້ອນຫຼາຍຂຶ້ນ (ຫຼາຍຕົວເຊື່ອມຕໍ່, ໂມດູນພະລັງງານປະສົມປະສານ, ລະບົບເຮັດຄວາມເຢັນທີ່ສັບສົນ), ບັນຊີລາຍຊື່ຮາບພຽງນີ້ຈຶ່ງກາຍເປັນສິ່ງທີ່ບໍ່ສາມາດຈັດການໄດ້. ບໍ່ມີວິທີການມາດຕະຖານໃນການອະທິບາຍລຳດັບຊັ້ນທາງກາຍະພາບຂອງສະຖານີ.

3.2 ວິທີການຮູບແບບອຸປະກອນ 2.0.1

OCPP 2.0.1 ແນະນຳຮູບແບບລຳດັບຊັ້ນທີ່ປະກອບດ້ວຍສ່ວນປະກອບຕ່າງໆແລະຕົວແປອົງປະກອບອາດຈະເປັນ "ຕົວຄວບຄຸມ," "ຕົວເຊື່ອມຕໍ່," ຫຼື "ໂມດູນພະລັງງານ." ແຕ່ລະອົງປະກອບມີຕົວແປທີ່ສະແດງເຖິງສະຖານະ ຫຼື ການຕັ້ງຄ່າຂອງມັນ (ຕົວຢ່າງ,ອຸນຫະພູມ, ແຮງດັນ, ກະແສສູງສຸດ).

• ອົງປະກອບ: ສ່ວນທາງກາຍະພາບ ຫຼື ທາງດ້ານເຫດຜົນຂອງສະຖານີສາກໄຟ.
• ຕົວແປຄຸນລັກສະນະສະເພາະຂອງອົງປະກອບນັ້ນ.
• ລັກສະນະ: ຂໍ້ມູນເມຕາທີ່ອະທິບາຍຕົວແປ (ຫົວໜ່ວຍ, ຂອບເຂດ, ປະເພດການເຂົ້າເຖິງ).

ສິ່ງນີ້ອະນຸຍາດໃຫ້ມີການຕິດຕາມກວດກາມາດຕະຖານ. ປະຈຸບັນຜູ້ປະຕິບັດງານສາມາດສອບຖາມອຸນຫະພູມຂອງໂມດູນພະລັງງານສະເພາະໂດຍໃຊ້ເສັ້ນທາງມາດຕະຖານ, ແທນທີ່ຈະອີງໃສ່ກະແຈທີ່ເປັນເຈົ້າຂອງສະເພາະຂອງຜູ້ຂາຍ.

ບົດທີ 4: ຄວາມປອດໄພທາງໄຊເບີ: ຈາກ “ຄວາມພະຍາຍາມທີ່ດີທີ່ສຸດ” ໄປສູ່ TLS ທີ່ບັງຄັບ

ໃນຊ່ວງຕົ້ນໆຂອງການສາກໄຟລົດ EV, ຄວາມປອດໄພມັກຈະເປັນສິ່ງທີ່ຄິດເຖິງພາຍຫຼັງ. OCPP 1.6J ສະເໜີໂປຣໄຟລ໌ຄວາມປອດໄພ, ແຕ່ການຈັດຕັ້ງປະຕິບັດບໍ່ສອດຄ່ອງກັນໃນທົ່ວຜູ້ຂາຍ.

4.1 ໂປຣໄຟລ໌ຄວາມປອດໄພໃນ 1.6J

OCPP 1.6J ໄດ້ກຳນົດໂປຣໄຟລ໌ຄວາມປອດໄພສາມຢ່າງຄື:

1. ບໍ່ປອດໄພHTTP/WebSockets ຂໍ້ຄວາມທຳມະດາ.
2. ການອະນຸຍາດພື້ນຖານ: TLS ພ້ອມດ້ວຍຊື່ຜູ້ໃຊ້/ລະຫັດຜ່ານ.
3. ອີງໃສ່ໃບຢັ້ງຢືນ: TLS ທີ່ມີໃບຢັ້ງຢືນຝັ່ງລູກຄ້າ.

ບັນຫາແມ່ນວ່າເຄື່ອງສາກໄຟຫຼາຍອັນຍັງຄົງຢູ່ໃນໂປຣໄຟລ໌ 1, ເຊິ່ງເຮັດໃຫ້ພວກມັນມີຄວາມສ່ຽງຕໍ່ການໂຈມຕີແບບ man-in-the-middle (MITM) ແລະການຄວບຄຸມທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ.

4.2 ທ່າທີທີ່ແຂງກະດ້າງຂອງ 2.0.1

OCPP 2.0.1 ກຳນົດໃຫ້ມີການສື່ສານທີ່ປອດໄພ. ມັນລວມເອົາຄຸນສົມບັດຄວາມປອດໄພຂັ້ນສູງເຂົ້າກັນ:

• ການອັບເດດເຟີມແວຣ໌ທີ່ປອດໄພ: ການເຊັນ ແລະ ການກວດສອບຮູບພາບເຟີມແວທີ່ຈຳເປັນ.
• ການບັນທຶກຄວາມປອດໄພບັນທຶກລະອຽດສຳລັບເຫດການທີ່ກ່ຽວຂ້ອງກັບຄວາມປອດໄພ (ເຊັ່ນ: ຄວາມພະຍາຍາມເຂົ້າສູ່ລະບົບທີ່ລົ້ມເຫຼວ, ໃບຢັ້ງຢືນໝົດອາຍຸ).
• ການຄຸ້ມຄອງໃບຢັ້ງຢືນ: ຂໍ້ຄວາມມາດຕະຖານສຳລັບໃບຢັ້ງຢືນທີ່ໝູນວຽນ ແລະ ອັບເດດແລ້ວ (CSMS-led ຫຼື Station-led).
• TLS 1.2/1.3: ຮອງຮັບມາດຕະຖານການເຂົ້າລະຫັດລ່າສຸດ.

ສຳລັບຜູ້ປະກອບການທາງການຄ້າ, ສິ່ງນີ້ຊ່ວຍຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງການປະນີປະນອມເຄືອຂ່າຍຂະໜາດໃຫຍ່ ແລະ ຮັບປະກັນການປະຕິບັດຕາມລະບຽບການຄວາມປອດໄພທາງໄຊເບີທີ່ເກີດຂຶ້ນໃໝ່ສຳລັບອຸປະກອນ IoT.

ບົດທີ 5: ການເຊື່ອມໂຍງ ISO 15118: ປລັກ ແລະ ການສາກໄຟ ແລະ V2G

ອະນາຄົດຂອງການສາກໄຟລົດໄຟຟ້າບໍ່ພຽງແຕ່ກ່ຽວກັບການເຄື່ອນຍ້າຍຂອງເອເລັກຕຣອນເທົ່ານັ້ນ; ແຕ່ມັນກ່ຽວກັບການແລກປ່ຽນຂໍ້ມູນ ແລະ ພະລັງງານທີ່ສະຫຼາດ. ISO 15118 ແມ່ນມາດຕະຖານສາກົນສຳລັບການສື່ສານລະຫວ່າງຍານພາຫະນະກັບຕາຂ່າຍໄຟຟ້າ (V2G), ແລະ ການເຊື່ອມໂຍງກັບ OCPP ແມ່ນລັກສະນະທີ່ກຳນົດຂອງ 2.0.1.

5.1 ຄວາມຊັບຊ້ອນຂອງການສຽບ ແລະ ການສາກໄຟ

ການເຊື່ອມຕໍ່ແບບສຽບ ແລະ ສາກໄຟ (PnC) ຊ່ວຍໃຫ້ຜູ້ຂັບຂີ່ສາມາດສຽບລົດ ແລະ ເລີ່ມການສາກໄຟໄດ້ໂດຍບໍ່ຕ້ອງໃຊ້ແອັບ ຫຼື ບັດ RFID. ສິ່ງນີ້ຮຽກຮ້ອງໃຫ້ມີໂຄງສ້າງພື້ນຖານກະແຈສາທາລະນະ (PKI) ທີ່ສັບສົນທີ່ກ່ຽວຂ້ອງກັບລົດ, ເຄື່ອງສາກໄຟ, ຜູ້ປະກອບການ ແລະ ສູນບໍລິການ.

ໃນ OCPP 1.6J, ການຮອງຮັບ PnC ບໍ່ມີການມີຢູ່ໃນໂປໂຕຄອນພື້ນຖານ. ຜູ້ຂາຍຕ້ອງໄດ້ປະຕິບັດສ່ວນຂະຫຍາຍທີ່ກຳນົດເອງ, ເຊິ່ງນຳໄປສູ່ການແຕກແຍກ. OCPP 2.0.1 ໃຫ້ "ລະບົບປະປາ" ສຳລັບ PnC ໂດຍການຮອງຮັບ:

• ການຕິດຕັ້ງໃບຢັ້ງຢືນການສົ່ງໃບຢັ້ງຢືນສັນຍາຈາກ CSMS ໄປຫາ EV ຜ່ານ EVSE.
• ການອະນຸຍາດ: ການໃຊ້ e-Mobility ID (eMAID) ທີ່ມາຈາກໃບຢັ້ງຢືນຂອງຍານພາຫະນະ.
• ການສື່ສານທີ່ຖືກເຂົ້າລະຫັດຮັບປະກັນວ່າຂໍ້ມູນການຮຽກເກັບເງິນທີ່ລະອຽດອ່ອນທີ່ສົ່ງຕໍ່ລະຫວ່າງລົດ ແລະ ຕາຂ່າຍໄຟຟ້າໄດ້ຮັບການປົກປ້ອງ.

5.2 ການສາກໄຟອັດສະລິຍະ ແລະ ການດຸ່ນດ່ຽງການໂຫຼດ

ໃນຂະນະທີ່ 1.6J ຮອງຮັບການສາກໄຟອັດສະລິຍະຂັ້ນພື້ນຖານ (ສົ່ງຕັ້ງຄ່າໂປຣໄຟລ໌ການສາກໄຟ), 2.0.1 ຍົກລະດັບສິ່ງນີ້. ມັນອະນຸຍາດໃຫ້:

• ການເຊື່ອມໂຍງສັນຍານພາຍນອກການຕອບສະໜອງຕາມເວລາຈິງຕໍ່ຄວາມຖີ່ຂອງຕາຂ່າຍໄຟຟ້າ ຫຼື ສັນຍານລາຄາຂາຍສົ່ງ.
• ການຈັດການການໂຫຼດແບບໄດນາມິກການຄວບຄຸມການແຈກຢາຍພະລັງງານທີ່ລະອຽດກວ່າໃນທົ່ວສະຖານທີ່ທີ່ມີຕົວເຊື່ອມຕໍ່ຫຼາຍຮ້ອຍຕົວ.
• ການເຊື່ອມຕໍ່ລະຫວ່າງຍານພາຫະນະກັບຕາຂ່າຍໄຟຟ້າ (V2G)2.0.1 ປະກອບມີພາກສະໜາມຂໍ້ມູນທີ່ຈຳເປັນເພື່ອສະໜັບສະໜູນການໄຫຼວຽນຂອງພະລັງງານສອງທິດທາງ, ຊ່ວຍໃຫ້ລົດໄຟຟ້າສາມາດເຮັດໜ້າທີ່ເປັນຊັບພະຍາກອນພະລັງງານແບບແຈກຢາຍ (DERs) ສຳລັບຕາຂ່າຍໄຟຟ້າ.

5.3 ການປັບປຸງ UI/UX ຂອງຜູ້ໃຊ້

OCPP 2.0.1 ຮອງຮັບການສະແດງຂໍ້ມູນໂດຍກົງຢູ່ໜ້າຈໍຂອງເຄື່ອງສາກໄຟ ຫຼື ແຜງໜ້າປັດຂອງລົດ ເຊັ່ນ:

• ລາຄາໃນເວລາຈິງໃນສະກຸນເງິນທ້ອງຖິ່ນ.
• ເວລາທີ່ຄາດຄະເນວ່າຈະຮອດສະພາບປະຈຸໄຟຟ້າ 80% (SoC).
• ຂໍ້ມູນໃບຮັບເງິນລະອຽດເມື່ອສຳເລັດ.

ບົດທີ 6: ການຄຸ້ມຄອງ ແລະ ການຕິດຕາມກວດກາອຸປະກອນຂັ້ນສູງ

ສຳລັບ CPO, ຄ່າໃຊ້ຈ່າຍຂອງເຄື່ອງສາກໄຟບໍ່ພຽງແຕ່ເປັນລາຄາຊື້ເທົ່ານັ້ນ; ແຕ່ມັນແມ່ນຕົ້ນທຶນທັງໝົດຂອງການເປັນເຈົ້າຂອງ (TCO). ການບຳລຸງຮັກສາ ແລະ ການຢຸດເຮັດວຽກແມ່ນຕົວກຳໄລທີ່ໃຫຍ່ທີ່ສຸດ. OCPP 2.0.1 ແກ້ໄຂບັນຫານີ້ຜ່ານຄວາມສາມາດໃນການຕິດຕາມກວດກາທີ່ດີກວ່າ.

6.1 ການລາຍງານທີ່ຂັບເຄື່ອນດ້ວຍເຫດການ

ໃນ 1.6J, CSMS ໂດຍປົກກະຕິແລ້ວຈະຕ້ອງກວດສອບສະຖານະຂອງເຄື່ອງສາກໄຟ ຫຼື ລໍຖ້າການແຈ້ງເຕືອນສະຖານະໃນ 2.0.1,ການຕິດຕາມເຫດການລະບົບອະນຸຍາດໃຫ້ CSMS ຕັ້ງຄ່າຂອບເຂດ. ຕົວຢ່າງ: “ແຈ້ງໃຫ້ຂ້ອຍຊາບເທົ່ານັ້ນຖ້າອຸນຫະພູມພາຍໃນເກີນ 70°C” ຫຼື “ລາຍງານຖ້າແຮງດັນຂາເຂົ້າຫຼຸດລົງຕໍ່າກວ່າ 200V.” ສິ່ງນີ້ຊ່ວຍຫຼຸດຜ່ອນການຈະລາຈອນເຄືອຂ່າຍ ແລະ ອະນຸຍາດໃຫ້ມີການບຳລຸງຮັກສາຢ່າງຕັ້ງໜ້າ.

6.2 ການຈັດການທຸລະກຳ: ເຫດການທຸລະກຳ

ໜຶ່ງໃນລັກສະນະທີ່ຖືກວິພາກວິຈານຫຼາຍທີ່ສຸດຂອງ OCPP 1.6J ແມ່ນການຈັດການທຸລະກຳ. ກອງປະຊຸມທີ່ກ່ຽວຂ້ອງເລີ່ມຕົ້ນທຸລະກຳແລະຢຸດການເຮັດທຸລະກຳຂໍ້ຄວາມຕ່າງໆ, ແຕ່ຖ້າເກີດການຂັດຂວາງຂອງເຄືອຂ່າຍ, CSMS ມັກຈະມີຄວາມຫຍຸ້ງຍາກໃນການປະສານສົມທົບຂໍ້ມູນການຮຽກເກັບເງິນ.

OCPP 2.0.1 ປ່ຽນແທນສິ່ງເຫຼົ່ານີ້ດ້ວຍອັນດຽວທີ່ແຂງແຮງເຫດການທຸລະກຳຂໍ້ຄວາມ. ຂໍ້ຄວາມນີ້ຖືກນໍາໃຊ້ເພື່ອລາຍງານທຸກຂັ້ນຕອນວົງຈອນຊີວິດຂອງທຸລະກໍາ (ເລີ່ມຕົ້ນ, ອັບເດດ, ສິ້ນສຸດ). ມັນປະກອບມີເປັນເອກະລັກລະຫັດທຸລະກຳສິ່ງນີ້ຍັງຄົງຢູ່ເຖິງແມ່ນວ່າເຄື່ອງສາກໄຟຈະຣີສະຕາດຄືນໃໝ່, ເຊິ່ງຮັບປະກັນວ່າບໍ່ມີຂໍ້ມູນການສາກໄຟ - ແລະດັ່ງນັ້ນຈຶ່ງບໍ່ມີລາຍຮັບ - ຈະສູນເສຍໄປ.

6.3 ການປັບປຸງການວິນິດໄສ ແລະ ການແກ້ໄຂບັນຫາ

ເທບັນທຶກການຮັບແລະການແຈ້ງເຕືອນສະຖານະການວິນິດໄສຂໍ້ຄວາມໃນ 2.0.1 ມີໂຄງສ້າງຫຼາຍກວ່າ. CPOs ສາມາດຮ້ອງຂໍປະເພດບັນທຶກສະເພາະ (ຄວາມປອດໄພ, ການວິນິດໄສ, ຜູ້ໃຊ້) ແລະ ລະບຸໄລຍະເວລາ. ສິ່ງນີ້ຊ່ວຍໃຫ້ທີມງານສະໜັບສະໜູນທາງໄກສາມາດແກ້ໄຂບັນຫາຕ່າງໆໂດຍບໍ່ຕ້ອງສົ່ງຊ່າງເຕັກນິກໄປຫາສະຖານທີ່, ເຊິ່ງຊ່ວຍຫຼຸດຜ່ອນ OpEx ໄດ້ຢ່າງຫຼວງຫຼາຍ.

ບົດທີ 7: ກົນໄກການອັບເດດເຟີມແວຣ໌: ຄວາມໜ້າເຊື່ອຖື ແລະ ການຍ້ອນກັບ

ການອັບເດດເຟີມແວຣ໌ແມ່ນຊີວິດຊີວາຂອງຮາດແວຣ໌ທີ່ພັດທະນາຢູ່ເລື້ອຍໆ, ແຕ່ການອັບເດດທີ່ລົ້ມເຫຼວສາມາດເຮັດໃຫ້ເຄື່ອງສາກໄຟຕິດໄດ້.

7.1 ຂະບວນການອັບເດດ 1.6J

ໃນ 1.6J,ອັບເດດເຟີມແວຄຳສັ່ງແມ່ນງ່າຍດາຍ. ເຄື່ອງສາກໄຟຈະດາວໂຫຼດຮູບພາບ ແລະ ພະຍາຍາມຕິດຕັ້ງມັນ. ບໍ່ມີກົນໄກມາດຕະຖານສຳລັບການອັບເດດຫຼາຍຂັ້ນຕອນ ຫຼື ການຍ້ອນກັບທີ່ຖືກຢືນຢັນ.

7.2 ການອັບເດດຫຼາຍຂັ້ນຕອນ 2.0.1

OCPP 2.0.1 ນຳສະເໜີວົງຈອນຊີວິດທີ່ຊັບຊ້ອນກວ່າສຳລັບການອັບເດດເຟີມແວ:

1. ດາວໂຫຼດເຄື່ອງສາກໄຟຈະດຶງເອົາຮູບພາບ ແລະ ກວດສອບ checksum/ລາຍເຊັນຂອງມັນ.
2. ການຕິດຕັ້ງການອັບເດດຖືກນຳໃຊ້ກັບພາທິຊັນສຳຮອງ.
3. ການຢືນຢັນລະບົບຈະກວດສອບວ່າເຟີມແວໃໝ່ບູດຢ່າງຖືກຕ້ອງຫຼືບໍ່.
4. ການເປີດໃຊ້ງານ: ການແບ່ງປັນຫຼັກຖືກສະຫຼັບ.

ຖ້າຂັ້ນຕອນໃດໜຶ່ງລົ້ມເຫຼວ, ໂປໂຕຄອນຈະກຳນົດວິທີທີ່ເຄື່ອງສາກໄຟຄວນກັບຄືນໄປໃຊ້ລຸ້ນທີ່ໝັ້ນຄົງກ່ອນໜ້ານີ້ ແລະ ລາຍງານລະຫັດຄວາມລົ້ມເຫຼວສະເພາະໃຫ້ກັບ CSMS. ລະດັບຄວາມໜ້າເຊື່ອຖືນີ້ແມ່ນບໍ່ສາມາດເຈລະຈາໄດ້ສຳລັບການນຳໃຊ້ທາງການຄ້າຂະໜາດໃຫຍ່.

7.3 ການຢັ້ງຢືນລາຍເຊັນ

ເພື່ອປ້ອງກັນບໍ່ໃຫ້ຜູ້ກະທຳຜິດອັບໂຫລດເຟີມແວທີ່ຖືກໂຈມຕີ, 2.0.1 ກຳນົດໃຫ້ໃຊ້ລາຍເຊັນດິຈິຕອນ. ເຄື່ອງສາກໄຟຈະປະຕິເສດທີ່ຈະປະຕິບັດລະຫັດໃດໆທີ່ບໍ່ໄດ້ເຊັນໂດຍລະຫັດສ່ວນຕົວຂອງຜູ້ຜະລິດ, ເຊິ່ງເປັນການເພີ່ມຊັ້ນປ້ອງກັນທີ່ສຳຄັນຕໍ່ການແຮັກລະດັບຮາດແວ.

ບົດທີ 8: ຄວາມເປັນສ່ວນຕົວຂອງຂໍ້ມູນ, ການປະຕິບັດຕາມກົດລະບຽບ, ແລະ GDPR

ຍ້ອນວ່າການສາກໄຟລົດ EV ກາຍເປັນສິ່ງຈຳເປັນປະຈຳວັນ, ປະລິມານຂໍ້ມູນສ່ວນຕົວທີ່ສ້າງຂຶ້ນຈຶ່ງມີຢ່າງຫຼວງຫຼາຍ. ການສາກໄຟຄັ້ງດຽວສາມາດເຊື່ອມໂຍງຕົວຕົນຂອງຜູ້ໃຊ້, ສະຖານທີ່ຂອງຍານພາຫະນະ, ຮູບແບບການເດີນທາງ ແລະ ຂໍ້ມູນທາງການເງິນຂອງເຂົາເຈົ້າ.

8.1 ຂໍ້ມູນສ່ວນຕົວທີ່ສາມາດລະບຸຕົວຕົນໄດ້ (PII) ໃນ OCPP

ໃນສະພາບການຂອງກົດລະບຽບວ່າດ້ວຍການປົກປ້ອງຂໍ້ມູນທົ່ວໄປ (GDPR) ໃນເອີຣົບ ແລະ ກົດໝາຍທີ່ຄ້າຍຄືກັນເຊັ່ນ CCPA ໃນລັດຄາລິຟໍເນຍ, ຈຸດຂໍ້ມູນເຊັ່ນidTag(RFID) ຫຼືEVCCID(ຕົວລະບຸຍານພາຫະນະ) ຖືກຖືວ່າເປັນຂໍ້ມູນສ່ວນຕົວ (PII).

OCPP 2.0.1 ໃຫ້ການຄວບຄຸມທີ່ດີກວ່າສຳລັບການປິດບັງຂໍ້ມູນ. ຕົວຢ່າງ,ຂໍ້ມູນກຳນົດເອງພາກສະຫນາມອະນຸຍາດໃຫ້ຜູ້ປະຕິບັດການເກັບຮັກສາ metadata ໂດຍບໍ່ຕ້ອງເປີດເຜີຍ PII ໃຫ້ກັບບັນທຶກໂປໂຕຄອນຫຼັກ. ນອກຈາກນັ້ນ, ໂປຣໄຟລ໌ຄວາມປອດໄພທີ່ດີຂຶ້ນຮັບປະກັນວ່າຂໍ້ມູນນີ້ຖືກເຂົ້າລະຫັດທັງໃນລະຫວ່າງການຂົນສົ່ງ ແລະ ໃນເວລາທີ່ບໍ່ໄດ້ໃຊ້ງານ.

8.2 ສິດທີ່ຈະຖືກລືມ ແລະ ການໂອນຍ້າຍຂໍ້ມູນ

ລັກສະນະໂຄງສ້າງຂອງຮູບແບບອຸປະກອນ 2.0.1 ເຮັດໃຫ້ຜູ້ໃຫ້ບໍລິການ CSMS ສາມາດຈັດຕັ້ງປະຕິບັດການຮ້ອງຂໍ "ລຶບຂໍ້ມູນ" ໄດ້ງ່າຍຂຶ້ນ. ໃນລະບົບ 1.6J, ການຊອກຫາຕົວຢ່າງທັງໝົດຂອງ ID ຂອງຜູ້ໃຊ້ໃນທົ່ວລະຫັດການຕັ້ງຄ່າ ແລະ ບັນທຶກທີ່ແຕກຕ່າງກັນແມ່ນຝັນຮ້າຍທີ່ເຮັດດ້ວຍຕົນເອງ. ໃນ 2.0.1, ການແຍກທີ່ຊັດເຈນລະຫວ່າງສະຖານະອຸປະກອນ ແລະ ຂໍ້ມູນການເຮັດທຸລະກຳຊ່ວຍໃຫ້ສະຖາປັດຕະຍະກຳຖານຂໍ້ມູນສະອາດຂຶ້ນ.

8.3 ການປະຕິບັດຕາມກົດໝາຍວ່າດ້ວຍຄວາມປອດໄພຂອງ IoT

ຫຼາຍພາກພື້ນໃນປະຈຸບັນກຳລັງອອກກົດໝາຍທີ່ຮຽກຮ້ອງໃຫ້ອຸປະກອນ IoT ມີລະຫັດຜ່ານທີ່ເປັນເອກະລັກ ແລະ ກົນໄກການອັບເດດທີ່ປອດໄພ. TLS ທີ່ບັງຄັບຂອງ OCPP 2.0.1 ແລະ ເຟີມແວທີ່ລົງນາມແລ້ວບໍ່ພຽງແຕ່ເປັນຄຸນສົມບັດທີ່ "ດີທີ່ຈະມີ" ເທົ່ານັ້ນ - ແຕ່ພວກມັນຍັງເປັນຂໍ້ກຳນົດທາງກົດໝາຍສຳລັບການຂາຍຮາດແວໃນຕະຫຼາດເຊັ່ນ: ລັດຄາລິຟໍເນຍ ແລະ ສະຫະລາຊະອານາຈັກ.

ບົດທີ 9: ທັດສະນະຂອງຜູ້ຊື້: TCO, ROI, ແລະ ການເຄື່ອນຍ້າຍຍຸດທະສາດ

ສຳລັບຜູ້ໃຫ້ບໍລິການສາກໄຟທາງການຄ້າ, ການຕັດສິນໃຈທີ່ຈະຍຶດໝັ້ນກັບ 1.6J ຫຼື ຍ້າຍໄປ 2.0.1 ແມ່ນເປັນການຕັດສິນໃຈທາງດ້ານການເງິນ.

9.1 ຄ່າໃຊ້ຈ່າຍໃນການຈັດຕັ້ງປະຕິບັດ

• OCPP 1.6Jລາຄາຖືກໃນການຈັດຕັ້ງປະຕິບັດ, ໄດ້ຮັບການສະໜັບສະໜູນຢ່າງກວ້າງຂວາງຈາກຮາດແວລາຄາຖືກ, ແຕ່ມີຄ່າໃຊ້ຈ່າຍທີ່ເຊື່ອງໄວ້ສູງໃນການບຳລຸງຮັກສາ ແລະ ຄວາມສ່ຽງດ້ານຄວາມປອດໄພ.
• OCPP 2.0.1ຕ້ອງການໂປເຊດເຊີທີ່ມີປະສິດທິພາບຫຼາຍຂຶ້ນ ແລະ ໜ່ວຍຄວາມຈຳຫຼາຍຂຶ້ນໃນ EVSE. ຄ່າໃຊ້ຈ່າຍໃນການພັດທະນາສຳລັບ CSMS ແມ່ນສູງກວ່າເນື່ອງຈາກຄວາມສັບສົນຂອງໂປໂຕຄອນ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ມັນສະເໜີການປະຫຍັດ OpEx ທີ່ສຳຄັນຜ່ານການຄຸ້ມຄອງທາງໄກ ແລະ ຄວາມໜ້າເຊື່ອຖືທີ່ດີຂຶ້ນ.

9.2 ຄວາມເຂົ້າໃຈຜິດກ່ຽວກັບ “ການຍົກລະດັບທີ່ລຽບງ່າຍ”

ມັກຈະມີຄົນເວົ້າວ່າເຄື່ອງສາກໄຟ 1.6J ສາມາດອັບເກຣດເປັນ 2.0.1 ຜ່ານຊອບແວໄດ້. ໃນຄວາມເປັນຈິງແລ້ວ, ສິ່ງນີ້ບໍ່ຄ່ອຍເປັນຄວາມຈິງ. ຄວາມຕ້ອງການໜ່ວຍຄວາມຈຳ ແລະ CPU ສຳລັບ 2.0.1 (ໂດຍສະເພາະການຈັດການໃບຢັ້ງຢືນ TLS ແລະການວິເຄາະ JSON ທີ່ສັບສົນຂອງຮູບແບບອຸປະກອນ) ມັກຈະເກີນຄວາມສາມາດຂອງຕົວຄວບຄຸມ 1.6J ລຸ້ນເກົ່າ.

9.3 ເສັ້ນທາງການເຄື່ອນຍ້າຍຍຸດທະສາດ

CPOs ຄວນພິຈາລະນາວິທີການ “ເຄືອຂ່າຍປະສົມ”:

1. ເວັບໄຊເກົ່າສືບຕໍ່ໃຊ້ 1.6J ສຳລັບເຄື່ອງສາກໄຟ AC ພະລັງງານຕ່ຳທີ່ມີຢູ່ແລ້ວ.
2. ສະຖານທີ່ສາກໄຟ DC ໄວໃໝ່ຄຳສັ່ງ 2.0.1 ສຳລັບການນຳໃຊ້ພະລັງງານສູງໃໝ່ທັງໝົດເພື່ອຮອງຮັບ PnC ແລະ V2G.
3. ໂຊລູຊັ່ນຂອງ Proxyໃຊ້ປະຕູໂປຣໂຕຄອນທີ່ສາມາດແປຂໍ້ຄວາມ 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 ຮອງຮັບການສາກໄຟແບບໄຮ້ສາຍ

ເມື່ອຍານພາຫະນະອັດຕະໂນມັດ (AVs) ເກີດຂຶ້ນ, ການສຽບປລັກດ້ວຍຕົນເອງຈະລ້າສະໄໝ. OCPP 2.1 ຈະປະກອບມີຂໍ້ຄວາມມາດຕະຖານສຳລັບການສາກໄຟແບບ inductive (ໄຮ້ສາຍ), ການຈັດການການຈັດລຽນ ແລະ ການຖ່າຍໂອນພະລັງງານໂດຍບໍ່ມີການແຊກແຊງຂອງມະນຸດ.

10.3 ການເຊື່ອມໂຍງກັບເມືອງອັດສະລິຍະ

ຮຸ່ນຕ່າງໆໃນອະນາຄົດອາດຈະເຫັນການເຊື່ອມໂຍງທີ່ເລິກເຊິ່ງກວ່າກັບລະບົບການຄຸ້ມຄອງການຈະລາຈອນ ແລະ ການຄາດຄະເນພະລັງງານທົດແທນ. ເຄື່ອງສາກໄຟຈະສາມາດ "ປະມູນ" ສຳລັບພະລັງງານໃນຕະຫຼາດພະລັງງານແບບເວລາຈິງ, ປ່ຽນເຄືອຂ່າຍສາກໄຟໃຫ້ກາຍເປັນໂຮງງານໄຟຟ້າສະເໝືອນຂະໜາດໃຫຍ່ (VPPs).

ພາກຜະນວກດ້ານເຕັກນິກ: ເຈາະເລິກເຖິງການປຽບທຽບຂໍ້ຄວາມ

ເພື່ອໃຫ້ຄວາມເລິກທາງດ້ານເຕັກນິກສູງສຸດ, ຕອນນີ້ພວກເຮົາຈະວິເຄາະລໍາດັບຂໍ້ຄວາມສະເພາະ ແລະ ຄວາມແຕກຕ່າງຂອງເຟຣມລະຫວ່າງສອງເວີຊັນ.

ກ.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": "ຍິນດີຕ້ອນຮັບກັບມາ, John! ຍອດເງິນຂອງເຈົ້າແມ່ນ $45.00" } } }]"

ກ.2 ການຄຸ້ມຄອງການເຕັ້ນຂອງຫົວໃຈ ແລະ ການເຊື່ອມຕໍ່

OCPP 2.0.1 ປັບປຸງວິທີທີ່ສະຖານີພິສູດວ່າມັນ "ມີຊີວິດຢູ່". ໃນ 1.6J, ຖ້າຈັງຫວະຂອງຫົວໃຈຖ້າລົ້ມເຫລວ, ສະຖານີມັກຈະພະຍາຍາມໃໝ່ຢູ່ເລື້ອຍໆ. ໃນ 2.0.1, ສະຖານີສາມາດໃຊ້ແຈ້ງເຕືອນເຫດການກົນໄກເພື່ອລາຍງານວ່າການເຊື່ອມຕໍ່ກັບ backend ສຳຮອງໄດ້ສູນເສຍໄປ, ໃນຂະນະທີ່ຍັງຮັກສາການເຕັ້ນຂອງຫົວໃຈກັບ backend ຫຼັກໄດ້.

A.3 ຕາຕະລາງ Metadata ລະອຽດ

ສະຫຼຸບ

ການຫັນປ່ຽນຈາກ OCPP 1.6J ໄປເປັນ 2.0.1 ບໍ່ພຽງແຕ່ເປັນການອັບເດດຊອບແວເທົ່ານັ້ນ; ມັນຍັງເປັນວິວັດທະນາການພື້ນຖານຂອງລະບົບນິເວດການເຄື່ອນທີ່ດ້ວຍໄຟຟ້າ. ສຳລັບຜູ້ປະກອບການທາງການຄ້າ, 1.6J ເປັນຕົວແທນຂອງອະດີດທີ່ໜ້າເຊື່ອຖື, ໃນຂະນະທີ່ 2.0.1 ເປັນຕົວແທນຂອງອະນາຄົດທີ່ສາມາດຂະຫຍາຍໄດ້, ປອດໄພ ແລະ ສະຫຼາດ.

ການເລືອກ 2.0.1 ໃນມື້ນີ້ແມ່ນການລົງທຶນໃນອາຍຸການໃຊ້ງານທີ່ຍາວນານ. ມັນຮັບປະກັນວ່າຮາດແວຂອງທ່ານຈະເຂົ້າກັນໄດ້ກັບລົດໄຟຟ້າລຸ້ນຕໍ່ໄປ, ສອດຄ່ອງກັບລະບຽບການຄວາມປອດໄພທາງໄຊເບີທີ່ເຂັ້ມງວດ, ແລະພ້ອມແລ້ວສຳລັບໂອກາດທີ່ມີກຳໄລຈາກ V2G ແລະການເຊື່ອມໂຍງຕາຂ່າຍໄຟຟ້າອັດສະລິຍະ. ໃນຂະນະທີ່ຕະຫຼາດລວມຕົວກັນ, ຜູ້ປະກອບການທີ່ມີໂປໂຕຄອນ stacks ທີ່ແຂງແຮງ ແລະ ມີຄວາມຍືດຫຍຸ່ນທີ່ສຸດຈະເປັນຜູ້ທີ່ນຳພາການຮັບຜິດຊອບ.

ບົດທີ 11: ການເຈາະເລິກ: ການວິເຄາະການໄຫຼຂອງຂໍ້ຄວາມ ແລະ ແຜນວາດລຳດັບ

ໃນບົດນີ້, ພວກເຮົາວິເຄາະລໍາດັບການພົວພັນລະຫວ່າງ EVSE ແລະ CSMS ເພື່ອສະແດງໃຫ້ເຫັນເຖິງຄວາມແຕກຕ່າງດ້ານການດໍາເນີນງານລະຫວ່າງ 1.6J ແລະ 2.0.1.

11.1 ລຳດັບການບູດ ແລະ ການຕັ້ງຄ່າ

ເມື່ອເຄື່ອງສາກໄຟເຊື່ອມຕໍ່ກັບເຄືອຂ່າຍເປັນຄັ້ງທຳອິດ, ມັນຕ້ອງລະບຸຕົວມັນເອງ ແລະ ປະສານການຕັ້ງຄ່າຂອງມັນ.

ກະແສ OCPP 1.6J:

1. ການເຊື່ອມຕໍ່ WebSocketສ້າງຕັ້ງຂຶ້ນຜ່ານພອດ 80 ຫຼື 443.
2. ການແຈ້ງເຕືອນການເປີດເຄື່ອງສະຖານີສົ່ງຜູ້ຂາຍ, ຮຸ່ນ ແລະ serial.
3. ໄດ້ຮັບການຕັ້ງຄ່າ: CSMS ຮຽກຮ້ອງໃຫ້ກະແຈທັງໝົດກວດສອບສະຖານະປັດຈຸບັນ.
4. ການປ່ຽນແປງການຕັ້ງຄ່າCSMS ອັບເດດຄີສະເພາະ (ຕົວຢ່າງ,ຊ່ວງເວລາການເຕັ້ນຂອງຫົວໃຈ).
5. ການແຈ້ງເຕືອນສະຖານະລາຍງານຂອງສະຖານີ “ມີໃຫ້ບໍລິການ.”

ຂັ້ນຕອນ OCPP 2.0.1:

1. ການຈັບມື TLS ທີ່ປອດໄພການແລກປ່ຽນໃບຢັ້ງຢືນບັງຄັບ.
2. ການແຈ້ງເຕືອນການເປີດເຄື່ອງ: ລວມມີເຫດຜົນ(ຕົວຢ່າງ,ພາວເວີອັບ).
3. ຮັບລາຍງານຖານແທນທີ່ຈະຮ້ອງຂໍກະແຈທັງໝົດ, CSMS ຮ້ອງຂໍ "ບົດລາຍງານພື້ນຖານ" ເຊິ່ງສະໜອງລຳດັບຊັ້ນເຕັມຂອງຮູບແບບອຸປະກອນ.
4. ກຳນົດຕົວແປCSMS ອັບເດດຕົວແປ. ໃຫ້ສັງເກດວ່າ 2.0.1 ອະນຸຍາດໃຫ້ມີການອັບເດດແບບອະຕອມ - ການຕັ້ງຄ່າຕົວແປຫຼາຍຕົວໃນຂໍ້ຄວາມດຽວ ແລະ ຮັບປະກັນວ່າທັງໝົດສຳເລັດ ຫຼື ບໍ່ມີຕົວແປໃດເຮັດໄດ້.
5. ແຈ້ງເຕືອນເຫດການສະຖານີລາຍງານສະຖານະອົງປະກອບເບື້ອງຕົ້ນ.

11.2 ການເຈລະຈາກ່ຽວກັບການສາກໄຟອັດສະລິຍະ

ການສາກໄຟອັດສະລິຍະແມ່ນບ່ອນທີ່ 2.0.1 ມີຄວາມໂດດເດັ່ນຢ່າງແທ້ຈິງ, ໂດຍສະເພາະເມື່ອຈັດການກັບໂປຣໄຟລ໌ການສາກໄຟຫຼາຍອັນ.

ໃນ 1.6J, CSMS ສົ່ງຕັ້ງຄ່າໂປຣໄຟລ໌ການສາກໄຟເຊິ່ງກຳນົດລະດັບການຊ້ອນກັນ ແລະ ຕາຕະລາງເວລາ. ຖ້າສະຖານີມີຕົວເຊື່ອມຕໍ່ຫຼາຍຕົວ, ການຈັດການໂປຣໄຟລ໌ມັກຈະບໍ່ຊັດເຈນ.

ໃນ 2.0.1,ຕັ້ງຄ່າໂປຣໄຟລ໌ການສາກໄຟແມ່ນເຊື່ອມໂຍງຢ່າງຊັດເຈນກັບໂປຣໄຟລ໌ການສາກໄຟຈຸດປະສົງ.

• ໂປຣໄຟລ໌ສະຖານີສາກໄຟສູງສຸດຈຳກັດການຮັບອາກາດຂອງສະຖານີທັງໝົດ.
• ໂປຣໄຟລ໌ຄ່າເລີ່ມຕົ້ນ TXຄ່າເລີ່ມຕົ້ນສຳລັບທຸລະກຳໃໝ່ໃດໆ.
• ໂປຣໄຟລ໌ TXສະເພາະສຳລັບທຸລະກຳທີ່ກຳລັງດຳເນີນຢູ່.

ນອກຈາກນັ້ນ, 2.0.1 ຮອງຮັບໄດ້ຮັບລະດັບການສາກໄຟ Stackຂໍ້ຄວາມ, ອະນຸຍາດໃຫ້ CSMS ເຫັນວ່າໂປຣໄຟລ໌ໃດທີ່ເປີດໃຊ້ງານຢູ່ໃນປະຈຸບັນ ແລະ ວິທີທີ່ພວກມັນຖືກຈັດລຳດັບຄວາມສຳຄັນໂດຍຕົວກຳນົດເວລາພາຍໃນຂອງ EVSE.

11.3 ການກະຕຸ້ນ ແລະ ການຄວບຄຸມຈາກໄລຍະໄກ

ຄຳສັ່ງຈາກໄລຍະໄກເຊັ່ນທຸລະກຳເລີ່ມຕົ້ນທາງໄກ(1.6J) ໄດ້ຖືກທົດແທນດ້ວຍການຮ້ອງຂໍເລີ່ມຕົ້ນທຸລະກຳ(2.0.1). ຄວາມແຕກຕ່າງທີ່ສຳຄັນແມ່ນຢູ່ໃນ payload. ໃນ 2.0.1, CSMS ສາມາດປະກອບມີໂປຣໄຟລ໌ການສາກໄຟໂດຍກົງໃນການຮ້ອງຂໍເລີ່ມຕົ້ນ. ນີ້ໝາຍຄວາມວ່າລົດສາມາດເລີ່ມການສາກໄຟໃນລະດັບພະລັງງານທີ່ຖືກຕ້ອງໄດ້ທັນທີ, ໂດຍບໍ່ຕ້ອງລໍຖ້າຂໍ້ຄວາມທີສອງ, ຫຼຸດຜ່ອນຄວາມຊັກຊ້າ ແລະ ປັບປຸງຄວາມໝັ້ນຄົງຂອງຕາຂ່າຍໄຟຟ້າ.

ບົດທີ 12: ໂຄງຮ່າງ JSON ລະດັບຕ່ຳ ແລະ ການປຽບທຽບພາກສະໜາມ

ສຳລັບນັກພັດທະນາ ແລະ ຜູ້ລວມລະບົບ, ການປ່ຽນແປງໂຄງຮ່າງແມ່ນສ່ວນທີ່ໃຊ້ແຮງງານຫຼາຍທີ່ສຸດຂອງການເຄື່ອນຍ້າຍ.

12.1 ປະເພດທີ່ລະບຸໄວ້ (Enums)

OCPP 2.0.1 ຂະຫຍາຍຈຳນວນ Enums ມາດຕະຖານຢ່າງຫຼວງຫຼາຍ, ຫຼຸດຜ່ອນຄວາມຕ້ອງການລະຫັດສະຖານະ "ກຳນົດເອງ" ທີ່ເຮັດໃຫ້ການຈັດຕັ້ງປະຕິບັດ 1.6J ມີບັນຫາ.

• ເຫດຜົນ Enums: ໝາເຝົ້າບ້ານ, ຕັ້ງຄ່າໃໝ່ຕາມກຳນົດເວລາ, ຣີໂໝດຣີເຊັດ, ການສູນເສຍພະລັງງານ.
• ສະຖານະ Enums: ຖືກຄອບຄອງ, ສະຫງວນໄວ້ແລ້ວ, ບໍ່ສາມາດໃຊ້ໄດ້, ມີຂໍ້ບົກຜ່ອງ. 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 ໄດ້ຄົ້ນພົບວ່າ 40% ຂອງລົດ 1.6J ຂອງພວກເຂົາບໍ່ຮອງຮັບ TLS 1.2. ນີ້ໝາຍຄວາມວ່າເຄື່ອງສາກໄຟເຫຼົ່ານັ້ນບໍ່ມີສິດໄດ້ຮັບສັນຍາຂອງລັດຖະບານທີ່ຈະມາເຖິງ.

13.2 ໄລຍະທີ 2: ການຍົກລະດັບ CSMS

ແທນທີ່ຈະສ້າງ CSMS ໃໝ່, MegaCharge ໄດ້ຈັດຕັ້ງປະຕິບັດ “ຊັ້ນການແປພາສາ OCPP.” ຊັ້ນນີ້ຈັດການການເຊື່ອມຕໍ່ 1.6J ສຳລັບຮາດແວເກົ່າ ແລະ 2.0.1 ສຳລັບຮາດແວໃໝ່, ແຕ່ໄດ້ເປີດເຜີຍ API ແບບລວມສູນໃຫ້ກັບແອັບມືຖື ແລະ ເຄື່ອງຈັກການຮຽກເກັບເງິນຂອງເຂົາເຈົ້າ.

13.3 ໄລຍະທີ 3: ການປ່ຽນແທນຮາດແວ

ສຳລັບສະຖານທີ່ທີ່ມີການຈະລາຈອນສູງ, MegaCharge ໄດ້ປ່ຽນແທນເຄື່ອງສາກໄຟ 1.6J ດ້ວຍເຄື່ອງສາກໄຟໄວ DC ທີ່ສອດຄ່ອງກັບມາດຕະຖານ 2.0.1. ຜົນໄດ້ຮັບແມ່ນການຫຼຸດລົງ 15% ໃນຊ່ວງເວລາ "ເລີ່ມຕົ້ນບໍ່ສຳເລັດ", ສ່ວນໃຫຍ່ແມ່ນຍ້ອນຄວາມແຂງແຮງຫຼາຍຂຶ້ນເຫດການທຸລະກຳການຈັດການໃນ 2.0.1.

13.4 ການວິເຄາະຜົນຕອບແທນຈາກການລົງທຶນ

ການລົງທຶນເບື້ອງຕົ້ນແມ່ນ 2 ລ້ານໂດລາ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ການຫຼຸດຜ່ອນການໂທບຳລຸງຮັກສາ (ຍ້ອນການວິນິດໄສຂອງ Device Model) ໄດ້ຊ່ວຍປະຢັດເງິນໄດ້ 400,000 ໂດລາຕໍ່ປີ. ນອກຈາກນັ້ນ, ຄວາມສາມາດໃນການເຂົ້າຮ່ວມໃນຕະຫຼາດການຕອບສະໜອງຄວາມຖີ່ V2G ໄດ້ສ້າງລາຍຮັບເພີ່ມເຕີມ 200,000 ໂດລາຕໍ່ປີ. ໄລຍະເວລາຄືນທຶນແມ່ນປະມານ 3.3 ປີ.

ບົດທີ 14: ບັນຊີກວດສອບສຸດທ້າຍຂອງຜູ້ຊື້ສຳລັບການຈັດຊື້ OCPP 2.0.1

ເມື່ອປະເມີນຮາດແວ ຫຼື ຊອບແວໃໝ່, ໃຫ້ໃຊ້ລາຍການກວດສອບນີ້ເພື່ອຮັບປະກັນການປະຕິບັດຕາມຢ່າງແທ້ຈິງ:

14.1 ຂໍ້ກຳນົດກ່ຽວກັບຮາດແວ (EVSE)

• [ ]ການສະໜັບສະໜູນໂປຣໄຟລ໌ຄວາມປອດໄພ 3ມັນຮອງຮັບການຈັດການໃບຢັ້ງຢືນຝັ່ງລູກຄ້າບໍ?
• [ ]ໂປເຊດເຊີຄູ່ຄໍ: ມີພື້ນທີ່ພຽງພໍສຳລັບການເຂົ້າລະຫັດ TLS ແລະການວິເຄາະ JSON ບໍ?
• [ ]ອົງປະກອບທີ່ປອດໄພ (SE)ກະດານມີຮາກຖານຮາດແວຂອງຄວາມໄວ້ວາງໃຈສຳລັບການເກັບຮັກສາກະແຈບໍ?
• [ ]ພ້ອມແລ້ວສຳລັບ ISO 15118-2/20ຕົວຄວບຄຸມສາມາດຈັດການການສື່ສານລະດັບສູງທີ່ຕ້ອງການສຳລັບ PnC ໄດ້ບໍ?
• [ ]ຄວາມສາມາດໃນການສະແດງຜົນຮາດແວຮອງຮັບການສະແດງຂໍ້ມູນລາຄາ/ສະຖານະຜ່ານ OCPP ຫຼືບໍ່ການໂອນຍ້າຍຂໍ້ມູນຫຼືຂໍ້ຄວາມພື້ນເມືອງ?

14.2 ຂໍ້ກຳນົດຂອງຊອບແວ (CSMS)

• [ ]ການສະແດງພາບຮູບແບບອຸປະກອນແຜງຄວບຄຸມສາມາດສະແດງມຸມມອງລຳດັບຊັ້ນຂອງເຄື່ອງສາກໄຟໄດ້ບໍ?
• [ ]ການເຊື່ອມໂຍງໜ່ວຍງານອອກໃບຢັ້ງຢືນ (CA)CSMS ສາມາດອອກໃບຢັ້ງຢືນ ແລະ ໝູນວຽນໂດຍອັດຕະໂນມັດໄດ້ບໍ?
• [ ]ການປະນີປະນອມທຸລະກຳລະບົບຈັດການກັບທຸລະກຳ "ຄ້າງຢູ່" ຈາກເຄື່ອງສາກໄຟລຸ້ນເກົ່າ 1.6J ແນວໃດ?
• [ ]ເຄື່ອງຈັກສາກໄຟອັດສະລິຍະມັນຮອງຮັບເຫດຜົນລະດັບ stack ຂັ້ນສູງຂອງ 2.0.1 ບໍ?
• [ ]ຄວາມສາມາດໃນການຂະຫຍາຍຕົວຈັດການ WebSocket ສາມາດຈັດການການເຊື່ອມຕໍ່ TLS ທີ່ຄົງທີ່ຫຼາຍກວ່າ 50,000 ອັນພ້ອມໆກັນໄດ້ບໍ?

ບົດທີ 15: ການແກ້ໄຂບັນຫາທົ່ວໄປໃນການຈັດຕັ້ງປະຕິບັດ OCPP

ເຖິງແມ່ນວ່າຈະມີມາດຕະຖານ, ການຈັດຕັ້ງປະຕິບັດກໍ່ແຕກຕ່າງກັນໄປ. ນີ້ແມ່ນ "ຄວາມຜິດພາດທົ່ວໄປທີ່ສຸດ".

15.1 ການໝົດເວລາຂອງ WebSocket

ໄຟວໍລ໌ເຄືອຂ່າຍຫຼາຍອັນຈະປິດການເຊື່ອມຕໍ່ TCP ທີ່ບໍ່ໄດ້ໃຊ້ງານ. ຖ້າຊ່ວງເວລາການເຕັ້ນຂອງຫົວໃຈຖ້າຕັ້ງໄວ້ສູງເກີນໄປ, ເຄື່ອງສາກອາດຈະຖືກຕັດການເຊື່ອມຕໍ່.

• ວິທີແກ້ໄຂ: ຮັບປະກັນຊ່ວງເວລາການເຕັ້ນຂອງຫົວໃຈຕ່ຳກວ່າເວລາໝົດເວລາຂອງໄຟວໍ (ໂດຍປົກກະຕິແມ່ນ 60-120 ວິນາທີ).

15.2 ບັນຫາລະບົບຕ່ອງໂສ້ໃບຢັ້ງຢືນ

ຄວາມລົ້ມເຫຼວທີ່ພົບເລື້ອຍໃນ 2.0.1 ແມ່ນຄວາມຜິດພາດ "ໃບຢັ້ງຢືນທີ່ບໍ່ໜ້າເຊື່ອຖື". ສິ່ງນີ້ມັກຈະເກີດຂຶ້ນເມື່ອເຄື່ອງສາກໄຟບໍ່ມີ Root CA ຂອງ CSMS ຕິດຕັ້ງຢູ່.

• ວິທີແກ້ໄຂ: ໃຊ້ຕິດຕັ້ງໃບຢັ້ງຢືນຂໍ້ຄວາມໃນລະຫວ່າງການມອບໝາຍເພື່ອຮັບປະກັນວ່າລະບົບຕ່ອງໂສ້ຄວາມໄວ້ວາງໃຈແມ່ນສຳເລັດ.

15.3 ຂະໜາດຂອງເພຍໂຫຼດ JSON

ບາງຂໍ້ຄວາມ 2.0.1 (ເຊັ່ນຮັບລາຍງານຖານ) ສາມາດມີຂະໜາດໃຫຍ່ຫຼາຍ. ຖ້າບັຟເຟີຂອງເຄື່ອງສາກໄຟນ້ອຍເກີນໄປ, ມັນຈະວາງຂໍ້ຄວາມລົງ.

• ວິທີແກ້ໄຂ: ກວດສອບຂະໜາດຂໍ້ຄວາມສູງສຸດຕົວແປໃນຮູບແບບອຸປະກອນ ແລະ ຮັບປະກັນວ່າ 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", "ການແຈ້ງເຕືອນເຫດການຄວາມປອດໄພ", { "ປະເພດ": "CertificateRotated", "timestamp": "2026-08-09T10:00:00Z" }]"

17.2 ການຕັ້ງຄ່າໂປຣໄຟລ໌ການສາກໄຟທີ່ຕອບສະໜອງຕໍ່ຕາຂ່າຍໄຟຟ້າ

ລອງນຶກພາບເບິ່ງວ່າຜູ້ປະກອບການຕາຂ່າຍໄຟຟ້າຕ້ອງການຫຼຸດຜ່ອນການໃຊ້ໄຟຟ້າໃນທົ່ວເຄືອຂ່າຍ.

CSMS ສົ່ງຕັ້ງຄ່າໂປຣໄຟລ໌ການສາກໄຟ:"json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "ChargingStationMaxProfile", "chargingProfileKind": "Absolute", "chargingSchedule": { "id": 1, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 11000 }, { "startPeriod": 3600, "limit": 22000 } ] } }]"

ບົດທີ 18: ປະມວນຄຳສັບທີ່ຄົບຖ້ວນຂອງ OCPP 2.0.1 ຄຳສັບ

ເພື່ອຮັບປະກັນຄວາມຊັດເຈນສຳລັບຜູ້ມີສ່ວນຮ່ວມທັງໝົດ, ພວກເຮົາສະໜອງປະມວນຄຳສັບທີ່ຂະຫຍາຍອອກ.

• CSMS (ລະບົບການຄຸ້ມຄອງສະຖານີສາກໄຟ)ແພລດຟອມຄລາວດ້ານຫຼັງທີ່ຄວບຄຸມເຄື່ອງສາກໄຟ.
• EVSE (ອຸປະກອນສະໜອງຍານພາຫະນະໄຟຟ້າ)ສະຖານີສາກໄຟທາງກາຍະພາບ.
• OCPP (ໂປໂຕຄອນຈຸດສາກໄຟເປີດ)ພາສາທີ່ເຂົາເຈົ້າເວົ້າ.
• OCA (ພັນທະມິດການສາກໄຟແບບເປີດ): ອົງກອນທີ່ຂຽນພາສາ.
• ISO 15118ໂປໂຕຄອນລະຫວ່າງລົດ ແລະ ເຄື່ອງສາກໄຟ.
• 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 ບໍ່ແມ່ນການປັບປຸງໂຄງສ້າງ; ມັນແມ່ນການຂຽນຄືນໃໝ່. ນັກພັດທະນາຕ້ອງຮັບຮອງເອົາຮູບແບບທາງຈິດໃຈທີ່ແຕກຕ່າງ.

19.1 ການຮັບເອົາຄວາມບໍ່ສອດຄ່ອງກັນ

ໃນຂະນະທີ່ WebSockets ແມ່ນ asynchronous ໂດຍທຳມະຊາດ, ຄວາມຊັບຊ້ອນຂອງ 2.0.1 ໝາຍຄວາມວ່າການຮ້ອງຂໍດຽວ (ເຊັ່ນຮັບລາຍງານຖານ) ອາດໃຊ້ເວລາຫຼາຍວິນາທີເພື່ອປະມວນຜົນໃນ EVSE ທີ່ມີຊັບພະຍາກອນຈຳກັດ. ນັກພັດທະນາ CSMS ຕ້ອງໃຊ້ເຫດຜົນການໝົດເວລາ ແລະ ລອງໃໝ່ທີ່ຄຳນຶງເຖິງຄວາມໄວໃນການປະມວນຜົນທີ່ແຕກຕ່າງກັນຂອງຜູ້ຂາຍຮາດແວທີ່ແຕກຕ່າງກັນ.

19.2 ການວິເຄາະ JSON ທີ່ມີປະສິດທິພາບ

ການວິເຄາະ JSON ສາມາດໃຊ້ CPU ຫຼາຍ. ສຳລັບເຟີມແວ EVSE, ນັກພັດທະນາຄວນໃຊ້ຕົວວິເຄາະແບບສະຕຣີມແທນທີ່ຈະໂຫຼດ payload ທັງໝົດເຂົ້າໃນ RAM. ສິ່ງນີ້ມີຄວາມສຳຄັນໂດຍສະເພາະສຳລັບແຈ້ງເຕືອນເຫດການຂໍ້ຄວາມຕ່າງໆ, ເຊິ່ງສາມາດມີການອັບເດດຕົວແປຫຼາຍຮ້ອຍອັນໃນເຟຣມດຽວ.

19.3 ການຈັດການເຄື່ອງຈັກສະຖານະ

ເຄື່ອງຈັກສະຖານະສຳລັບທຸລະກຳໃນ 2.0.1 ແມ່ນເຂັ້ມງວດກວ່າໃນ 1.6J. ນັກພັດທະນາຕ້ອງປະຕິບັດຕາມກົດລະບຽບການຫັນປ່ຽນຢ່າງເຂັ້ມງວດສຳລັບເຫດການທຸລະກຳຕົວຢ່າງ, ທ່ານບໍ່ສາມາດສົ່ງສິ້ນສຸດແລ້ວເຫດການໂດຍບໍ່ໄດ້ສົ່ງກ່ອນເລີ່ມຕົ້ນແລ້ວເຫດການສະເພາະສຳລັບເຫດການນັ້ນລະຫັດທຸລະກຳ.

ບົດທີ 20: ການທົດສອບ, ການຢັ້ງຢືນ, ແລະເຄື່ອງມືທົດສອບການປະຕິບັດຕາມ OCPP (OCTT)

ການເຮັດວຽກຮ່ວມກັນແມ່ນຄຳສັນຍາຂອງ OCPP, ແຕ່ມັນຈະຖືກຮັບຮູ້ຜ່ານການທົດສອບຢ່າງເຂັ້ມງວດເທົ່ານັ້ນ.

20.1 ບົດບາດຂອງການຮັບຮອງ OCA

Open Charge Alliance ສະເໜີໂຄງການຮັບຮອງ. ຜູ້ຊື້ຄວນຊອກຫາປ້າຍ “OCPP 2.0.1 Certified”. ການຮັບຮອງນີ້ຮັບປະກັນວ່າການຈັດຕັ້ງປະຕິບັດໄດ້ຜ່ານຊຸດການທົດສອບອັດຕະໂນມັດທີ່ກວມເອົາໂປຣໄຟລ໌ບັງຄັບທັງໝົດ.

20.2 ການນຳໃຊ້ OCTT

ເຄື່ອງມືທົດສອບຄວາມສອດຄ່ອງຂອງ OCPP (OCTT) ແມ່ນມາດຕະຖານຄຳສຳລັບການທົດສອບ. ມັນຈຳລອງທັງ CSMS ແລະ EVSE.

• ສຳລັບຜູ້ຜະລິດ EVSEໃຊ້ OCTT ເພື່ອກວດສອບວ່າສະຖານີຂອງທ່ານຈັດການກັບສະຖານະການ "ເສັ້ນທາງທີ່ມີຄວາມສຸກ" ແລະກໍລະນີຂອບ (ເຊັ່ນ: ເຄືອຂ່າຍຫຼຸດລົງໃນລະຫວ່າງການອັບເດດເຟີມແວ).
• ສຳລັບຜູ້ໃຫ້ບໍລິການ CSMSໃຊ້ OCTT ເພື່ອຮັບປະກັນວ່າ backend ຂອງທ່ານສາມາດຈັດການກັບຂໍ້ຄວາມທີ່ຫຼາກຫຼາຍ ແລະ ຂໍ້ກຳນົດຄວາມປອດໄພທີ່ເຂັ້ມງວດຂອງ 2.0.1.

20.3 ການທົດສອບພາກສະໜາມ ແລະ ການທົດລອງແບບ Interop-Fests

ນອກເໜືອໄປຈາກການທົດສອບແບບອັດຕະໂນມັດແລ້ວ, OCA ຍັງຈັດງານ “Plugfests” ບ່ອນທີ່ຜູ້ຂາຍນຳເອົາຮາດແວ ແລະ ຊອບແວຂອງເຂົາເຈົ້າມາທົດສອບເຊິ່ງກັນແລະກັນໃນສະຖານະການຕົວຈິງ. ນີ້ແມ່ນບ່ອນທີ່ພົບຂໍ້ບົກຜ່ອງທີ່ລະອຽດອ່ອນທີ່ສຸດ - ເຊັ່ນ: ຄວາມບໍ່ເຂົ້າກັນໄດ້ຂອງໃບຢັ້ງຢືນ ຫຼື ຄວາມແຕກຕ່າງເລັກນ້ອຍໃນການຈັດຮູບແບບ JSON - ຖືກຈັບ ແລະ ແກ້ໄຂ.

ບົດທີ 21: ຕາຕະລາງປຽບທຽບຢ່າງເລິກເຊິ່ງ: ການກະທຳ 60+ ຢ່າງຂອງ OCPP 2.0.1

ເພື່ອໃຫ້ເອກະສານອ້າງອີງຄົບຖ້ວນ, ພວກເຮົາຈັດປະເພດຂໍ້ຄວາມຫຼັກຂອງ 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-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 — ການເຮັດວຽກຮ່ວມກັນໄດ້ຮັບການພິສູດແລ້ວໃນພາກສະໜາມ, ບໍ່ໄດ້ສົມມຸດຈາກແຜ່ນຂໍ້ມູນ.
• ຮຽກຮ້ອງໃຫ້ມີເສັ້ນທາງການເຄື່ອນຍ້າຍເປັນລາຍລັກອັກສອນ.ຜູ້ຂາຍອຸປະກອນສາກໄຟຂອງທ່ານຄວນເຜີຍແຜ່ແຜນທີ່ເຟີມແວຈາກ 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.