การเปรียบเทียบเชิงกลยุทธ์ระหว่าง OCPP 1.6J กับ 2.0.1 สำหรับผู้ประกอบการสถานีชาร์จเชิงพาณิชย์

การเปรียบเทียบเชิงกลยุทธ์ที่ชัดเจนระหว่าง OCPP 1.6J กับ 2.0.1 สำหรับผู้ให้บริการสถานีชาร์จเชิงพาณิชย์ทั่วโลก: การควบคุมความสามารถในการขยายเครือข่าย การรักษาความปลอดภัยทางไซเบอร์ขั้นสูง การบูรณาการ ISO 15118 และการวางแผนโครงสร้างพื้นฐานระยะยาวเพื่อรองรับการเติบโตของรถยนต์ไฟฟ้าอย่างยั่งยืน

บทสรุปสำหรับผู้บริหาร

ภูมิทัศน์การชาร์จรถยนต์ไฟฟ้า (EV) กำลังเปลี่ยนแปลงไปอย่างมาก เนื่องจากการใช้งานทั่วโลกเพิ่มขึ้นอย่างรวดเร็ว โปรโตคอลการสื่อสารพื้นฐานที่ควบคุมการทำงานร่วมกันระหว่างอุปกรณ์จ่ายไฟสำหรับรถยนต์ไฟฟ้า (EVSE) และระบบจัดการสถานีชาร์จ (CSMS) จึงกลายเป็นจุดสนใจของกลยุทธ์ทางเทคนิคสำหรับผู้ประกอบการสถานีชาร์จเชิงพาณิชย์ (CPO) โปรโตคอล Open Charge Point Protocol (OCPP) ซึ่งดูแลโดย Open Charge Alliance (OCA) ได้พัฒนาจากกรอบการส่งข้อความแบบง่ายๆ ไปสู่มาตรฐานที่ซับซ้อน ปลอดภัย และปรับขนาดได้สูง

คู่มือนี้ให้การวิเคราะห์ทางเทคนิคอย่างละเอียดถี่ถ้วนเกี่ยวกับการเปลี่ยนผ่านจาก OCPP 1.6J ไปสู่ ​​OCPP 2.0.1 เราจะสำรวจความแตกต่างทางสถาปัตยกรรม การปรับปรุงด้านความปลอดภัย รูปแบบการจัดการอุปกรณ์ และบทบาทสำคัญของการบูรณาการ ISO 15118 สำหรับผู้ซื้อและผู้ใช้งาน บทความนี้ทำหน้าที่เป็นแหล่งอ้างอิงที่ครบถ้วนสำหรับการตัดสินใจจัดซื้อและย้ายระบบอย่างชาญฉลาดในตลาดที่เติบโตอย่างรวดเร็ว

บทที่ 1: วิวัฒนาการของมาตรฐานการชาร์จรถยนต์ไฟฟ้า: บริบททางประวัติศาสตร์

โปรโตคอล Open Charge Point (OCPP) เกิดขึ้นจากความต้องการความสามารถในการทำงานร่วมกัน ในช่วงแรกๆ ของการชาร์จรถยนต์ไฟฟ้า ผู้ผลิตฮาร์ดแวร์และผู้ให้บริการซอฟต์แวร์ต่างใช้โปรโตคอลที่เป็นกรรมสิทธิ์ของตนเอง ทำให้เกิด "ระบบปิด" ที่ขัดขวางการแข่งขันและนวัตกรรม การเปิดตัว OCPP 1.2 และ 1.5 ได้วางรากฐานไว้ แต่ OCPP 1.6 ต่างหากที่ทำให้เกิดความเป็นเอกภาพในอุตสาหกรรมอย่างแท้จริง

1.1 การครอบงำของ OCPP 1.6J

OCPP 1.6 ซึ่งเปิดตัวในปี 2015 ได้นำเสนอการใช้งาน JSON ผ่าน WebSockets (1.6J) การเปลี่ยนจากการส่งข้อความแบบ SOAP มาใช้ JSON ผ่าน WebSockets ช่วยลดภาระงานและทำให้การพัฒนาสำหรับนักพัฒนาทำได้ง่ายขึ้นอย่างมาก นอกจากนี้ยังเพิ่มคุณสมบัติใหม่ๆ เช่น การคิดค่าบริการแบบอัจฉริยะและการแจ้งเตือนสถานะเพิ่มเติม ทำให้ OCPP 1.6J กลายเป็นมาตรฐานอุตสาหกรรมมาเกือบสิบปี

1.2 จุดเริ่มต้นของ OCPP 2.0.1

แม้ว่า OCPP 1.6J จะประสบความสำเร็จ แต่การเติบโตของอุตสาหกรรมก็เผยให้เห็นข้อจำกัดของมัน ปัญหาด้านความปลอดภัย ความซับซ้อนในการจัดการอุปกรณ์ และการขาดการสนับสนุนโดยตรงสำหรับการบูรณาการโครงข่ายไฟฟ้าขั้นสูง (V2G) นำไปสู่การพัฒนา OCPP 2.0 และต่อมาคือ OCPP 2.0.1 ที่ได้รับการปรับปรุง (เปิดตัวในปี 2020) OCPP 2.0.1 ไม่ใช่แค่การอัปเดต แต่เป็นการออกแบบใหม่ทั้งหมดโดยมีเป้าหมายเพื่อรองรับเครือข่ายการชาร์จพลังงานสูงอัจฉริยะและปลอดภัยในอนาคต

บทที่ 2: รูปแบบการสื่อสารพื้นฐาน: JSON, WebSockets และโครงสร้างเฟรม

เพื่อให้เข้าใจความแตกต่างระหว่างโปรโตคอลเหล่านี้ จำเป็นต้องพิจารณาการสื่อสารในระดับพื้นฐาน โปรโตคอลทั้งสองใช้ JSON ผ่าน WebSockets แต่โครงสร้างและการจัดการข้อความเหล่านี้แตกต่างกันอย่างมาก

2.1 เลเยอร์ WebSocket

ทั้งสองเวอร์ชันใช้การเชื่อมต่อ WebSocket แบบถาวร ซึ่งช่วยให้สามารถสื่อสารแบบสองทิศทางได้อย่างสมบูรณ์ นี่เป็นสิ่งสำคัญสำหรับการทำงานแบบเรียลไทม์ เช่น การหยุดการชาร์จจากแอปบนมือถือ หรือการรับการแจ้งเตือนข้อผิดพลาดแบบทันที

2.2 การแบ่งเฟรมข้อความ

ข้อความ OCPP ทั่วไปประกอบด้วย รหัสประเภทข้อความ รหัสข้อความที่ไม่ซ้ำกัน ชื่อการดำเนินการ และเนื้อหาข้อมูล

ตัวอย่างเฟรม OCPP 1.6J (BootNotification)

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

ตัวอย่างเฟรม OCPP 2.0.1 (BootNotification)

“json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`โปรดสังเกตความละเอียดที่เพิ่มขึ้นในเวอร์ชัน 2.0.1ฟิลด์ `reason` ช่วยให้ CSMS เข้าใจว่าการบูตเกิดจากการรีบูต การเปิดเครื่อง หรือการทำงานของ watchdog ซึ่งจะช่วยให้สามารถวินิจฉัยปัญหาได้ดียิ่งขึ้น

บทที่ 3: การเปลี่ยนแปลงกระบวนทัศน์ทางสถาปัตยกรรม: โมเดลอุปกรณ์

การเปลี่ยนแปลงทางเทคนิคที่สำคัญที่สุดใน OCPP 2.0.1 คือการนำเสนอรุ่นอุปกรณ์.

3.1 ข้อจำกัดของคีย์การกำหนดค่า 1.6J

ใน OCPP 1.6J การกำหนดค่าฮาร์ดแวร์จะถูกจัดการผ่านรายการ "คีย์การกำหนดค่า" แบบเรียบ (เช่นช่วงเวลาการเต้นของหัวใจ, หมดเวลาการเชื่อมต่อเมื่อเครื่องชาร์จมีความซับซ้อนมากขึ้น (ขั้วต่อหลายแบบ โมดูลพลังงานแบบรวม ระบบระบายความร้อนที่ซับซ้อน) รายการแบบตายตัวนี้ก็จัดการได้ยากขึ้น ไม่มีวิธีการมาตรฐานในการอธิบายลำดับชั้นทางกายภาพของสถานีชาร์จ

3.2 แนวทางการสร้างแบบจำลองอุปกรณ์ 2.0.1

OCPP 2.0.1 นำเสนอโมเดลแบบลำดับชั้นซึ่งประกอบด้วยส่วนประกอบและตัวแปรส่วนประกอบหนึ่งอาจเป็น “ตัวควบคุม” “ตัวเชื่อมต่อ” หรือ “โมดูลพลังงาน” แต่ละส่วนประกอบจะมีตัวแปรที่แสดงสถานะหรือการกำหนดค่า (เช่นอุณหภูมิ, แรงดันไฟฟ้า, กระแสสูงสุด).

• ส่วนประกอบส่วนประกอบทางกายภาพหรือเชิงตรรกะของสถานีชาร์จไฟ
• ตัวแปร: คุณลักษณะเฉพาะของส่วนประกอบนั้น
• ลักษณะเฉพาะ: ข้อมูลเมตาที่อธิบายตัวแปร (หน่วย ช่วง ประเภทการเข้าถึง)

これによりสามารถตรวจสอบได้อย่างเป็นมาตรฐาน ผู้ปฏิบัติงานสามารถสอบถามอุณหภูมิของโมดูลพลังงานเฉพาะโดยใช้เส้นทางมาตรฐาน แทนที่จะต้องพึ่งพาคีย์เฉพาะของผู้ผลิตแต่ละราย

บทที่ 4: ความปลอดภัยทางไซเบอร์: จาก “ความพยายามอย่างเต็มที่” สู่ TLS ที่บังคับใช้

ในยุคแรกเริ่มของการชาร์จรถยนต์ไฟฟ้า ความปลอดภัยมักถูกมองข้ามไป OCPP 1.6J นำเสนอโปรไฟล์ความปลอดภัย แต่การใช้งานยังไม่สม่ำเสมอในแต่ละผู้จำหน่าย

4.1 โปรไฟล์ความปลอดภัยใน 1.6J

OCPP 1.6J ได้กำหนดโปรไฟล์ความปลอดภัยไว้ 3 แบบ:

1. ไม่ปลอดภัย: ข้อความธรรมดา HTTP/WebSockets
2. การตรวจสอบสิทธิ์ขั้นพื้นฐาน: การเชื่อมต่อ TLS พร้อมชื่อผู้ใช้/รหัสผ่าน
3. ออกใบรับรอง: TLS พร้อมใบรับรองฝั่งไคลเอ็นต์

ปัญหาคือเครื่องชาร์จจำนวนมากยังคงใช้โปรไฟล์ 1 ซึ่งทำให้เสี่ยงต่อการโจมตีแบบคนกลาง (MITM) และการควบคุมโดยไม่ได้รับอนุญาต

4.2 ท่าทีที่แน่วแน่ของ 2.0.1

OCPP 2.0.1 กำหนดให้ต้องมีการสื่อสารที่ปลอดภัย โดยได้รวมคุณสมบัติความปลอดภัยขั้นสูงไว้ในตัว:

• การอัปเดตเฟิร์มแวร์ที่ปลอดภัย: การลงนามและการตรวจสอบความถูกต้องของไฟล์ภาพเฟิร์มแวร์เป็นสิ่งจำเป็น
• การบันทึกข้อมูลความปลอดภัยบันทึกรายละเอียดเกี่ยวกับเหตุการณ์ที่เกี่ยวข้องกับความปลอดภัย (เช่น ความพยายามในการเข้าสู่ระบบล้มเหลว การหมดอายุของใบรับรอง)
• การจัดการใบรับรองข้อความมาตรฐานสำหรับใบรับรองที่หมุนเวียนและอัปเดต (ดำเนินการโดย CSMS หรือดำเนินการโดยสถานี)
• TLS 1.2/1.3: รองรับมาตรฐานการเข้ารหัสล่าสุด

สำหรับผู้ประกอบการเชิงพาณิชย์ สิ่งนี้ช่วยลดความเสี่ยงจากการถูกโจมตีเครือข่ายในวงกว้าง และทำให้มั่นใจได้ว่าจะปฏิบัติตามกฎระเบียบด้านความปลอดภัยทางไซเบอร์ที่กำลังเกิดขึ้นใหม่สำหรับอุปกรณ์ IoT

บทที่ 5: การบูรณาการ ISO 15118: การเสียบปลั๊กและชาร์จ และ V2G

อนาคตของการชาร์จรถยนต์ไฟฟ้าไม่ได้เป็นเพียงแค่การเคลื่อนย้ายอิเล็กตรอนเท่านั้น แต่ยังเกี่ยวกับการแลกเปลี่ยนข้อมูลและพลังงานอย่างชาญฉลาด มาตรฐาน ISO 15118 เป็นมาตรฐานสากลสำหรับการสื่อสารระหว่างรถยนต์กับโครงข่ายไฟฟ้า (V2G) และการบูรณาการเข้ากับ OCPP คือคุณลักษณะสำคัญของเวอร์ชัน 2.0.1

5.1 ความซับซ้อนของระบบเสียบปลั๊กและชาร์จ

ระบบ Plug & Charge (PnC) ช่วยให้ผู้ขับขี่สามารถเสียบปลั๊กและเริ่มชาร์จรถได้ง่ายๆ โดยไม่ต้องใช้แอปพลิเคชันหรือบัตร RFID ซึ่งต้องใช้โครงสร้างพื้นฐานกุญแจสาธารณะ (PKI) ที่ซับซ้อน โดยเกี่ยวข้องกับรถยนต์ เครื่องชาร์จ ผู้ให้บริการ และศูนย์กลางการประมวลผลข้อมูล

ใน OCPP 1.6J โปรโตคอลพื้นฐานไม่มีการรองรับ PnC ผู้ผลิตต้องพัฒนาส่วนขยายเอง ทำให้เกิดความแตกแยก OCPP 2.0.1 ได้วางรากฐานสำหรับการรองรับ PnC โดยให้การสนับสนุนดังต่อไปนี้:

• การติดตั้งใบรับรอง: ส่งต่อใบรับรองสัญญาจาก CSMS ไปยัง EV ผ่านทาง EVSE
• การอนุญาต: ใช้รหัส e-Mobility ID (eMAID) ที่ได้มาจากใบรับรองของยานพาหนะ
• การสื่อสารที่เข้ารหัส: เพื่อให้มั่นใจว่าข้อมูลการเรียกเก็บเงินที่สำคัญซึ่งส่งผ่านระหว่างรถยนต์และระบบไฟฟ้าได้รับการปกป้อง

5.2 การชาร์จอัจฉริยะและการปรับสมดุลโหลด

ในขณะที่ 1.6J รองรับการชาร์จอัจฉริยะขั้นพื้นฐาน (การส่งสัญญาณ)ตั้งค่าโปรไฟล์การชาร์จ), 2.0.1 ยกระดับสิ่งนี้ขึ้นไปอีกขั้น โดยอนุญาตให้:

• การรวมสัญญาณภายนอก: ตอบสนองแบบเรียลไทม์ต่อสัญญาณความถี่ของระบบไฟฟ้าหรือราคาขายส่ง
• การจัดการโหลดแบบไดนามิก: ควบคุมการจ่ายพลังงานได้อย่างละเอียดมากขึ้นทั่วทั้งไซต์งานที่มีขั้วต่อหลายร้อยตัว
• การเชื่อมต่อยานพาหนะกับโครงข่ายไฟฟ้า (V2G)เวอร์ชัน 2.0.1 ประกอบด้วยช่องข้อมูลที่จำเป็นเพื่อรองรับการไหลของพลังงานแบบสองทิศทาง ทำให้รถยนต์ไฟฟ้าสามารถทำหน้าที่เป็นแหล่งพลังงานแบบกระจาย (DER) สำหรับโครงข่ายไฟฟ้าได้

5.3 การปรับปรุงส่วนติดต่อผู้ใช้/ประสบการณ์ผู้ใช้

OCPP 2.0.1 รองรับการแสดงข้อมูลโดยตรงบนหน้าจอของเครื่องชาร์จหรือแผงหน้าปัดรถยนต์ เช่น:

• ราคาแบบเรียลไทม์ในสกุลเงินท้องถิ่น
• เวลาโดยประมาณที่จะถึงระดับประจุแบตเตอรี่ 80% (SoC)
• ข้อมูลใบเสร็จรับเงินโดยละเอียดเมื่อดำเนินการเสร็จสิ้น

บทที่ 6: การจัดการและการตรวจสอบอุปกรณ์ขั้นสูง

สำหรับ CPO (Chief Pre-Owned Controller) ต้นทุนของเครื่องชาร์จไม่ได้มีเพียงแค่ราคาซื้อเท่านั้น แต่ยังรวมถึงต้นทุนรวมในการเป็นเจ้าของ (Total Cost of Ownership หรือ TCO) ด้วย การบำรุงรักษาและการหยุดทำงานเป็นตัวบั่นทอนกำไรที่สำคัญที่สุด OCPP 2.0.1 แก้ปัญหานี้ด้วยความสามารถในการตรวจสอบที่เหนือกว่า

6.1 การรายงานตามเหตุการณ์

ในเวอร์ชัน 1.6J ระบบ CSMS มักจะต้องตรวจสอบสถานะของเครื่องชาร์จหรือรอสัญญาณตอบรับการแจ้งเตือนสถานะในเวอร์ชัน 2.0.1 นั้นการตรวจสอบเหตุการณ์ระบบนี้อนุญาตให้ CSMS ตั้งค่าเกณฑ์ต่างๆ ได้ ตัวอย่างเช่น “แจ้งเตือนเฉพาะเมื่ออุณหภูมิภายในเกิน 70°C” หรือ “รายงานหากแรงดันไฟฟ้าขาเข้าลดลงต่ำกว่า 200V” ซึ่งจะช่วยลดปริมาณการรับส่งข้อมูลในเครือข่ายและช่วยให้สามารถบำรุงรักษาเชิงรุกได้

6.2 การจัดการธุรกรรม: เหตุการณ์ธุรกรรม (TransactionEvent)

หนึ่งในประเด็นที่ถูกวิพากษ์วิจารณ์มากที่สุดของ OCPP 1.6J คือการจัดการธุรกรรม การประชุมครั้งหนึ่งเกี่ยวข้องกับ...เริ่มธุรกรรมและหยุดธุรกรรมระบบ CSMS สามารถส่งข้อความได้ แต่หากเกิดการขัดข้องของเครือข่าย ระบบมักจะไม่สามารถตรวจสอบข้อมูลการเรียกเก็บเงินได้อย่างถูกต้อง

OCPP 2.0.1 แทนที่สิ่งเหล่านี้ด้วยส่วนประกอบเดียวที่แข็งแกร่งเหตุการณ์ธุรกรรมข้อความนี้ใช้สำหรับรายงานทุกขั้นตอนของวงจรชีวิตธุรกรรม (เริ่มต้น อัปเดต สิ้นสุด) โดยมีรหัสเฉพาะกำกับอยู่รหัสธุรกรรมซึ่งข้อมูลนี้จะยังคงอยู่แม้ว่าเครื่องชาร์จจะรีสตาร์ท ทำให้มั่นใจได้ว่าข้อมูลการชาร์จจะไม่สูญหาย และรายได้ก็จะไม่สูญหายเช่นกัน

6.3 การวินิจฉัยและการแก้ไขปัญหาที่ดีขึ้น

เดอะรับบันทึกและการแจ้งสถานะการวินิจฉัยข้อความในเวอร์ชัน 2.0.1 มีโครงสร้างที่ชัดเจนยิ่งขึ้น CPO สามารถขอประเภทบันทึกเฉพาะ (ความปลอดภัย การวินิจฉัย ผู้ใช้) และระบุช่วงเวลาได้ ซึ่งช่วยให้ทีมสนับสนุนระยะไกลสามารถแก้ไขปัญหาได้โดยไม่ต้องส่งช่างเทคนิคไปยังสถานที่จริง ช่วยลดค่าใช้จ่ายในการดำเนินงานได้อย่างมาก

บทที่ 7: กลไกการอัปเดตเฟิร์มแวร์: ความน่าเชื่อถือและการย้อนกลับ

การอัปเดตเฟิร์มแวร์เป็นหัวใจสำคัญของการพัฒนาฮาร์ดแวร์ แต่การอัปเดตที่ล้มเหลวอาจทำให้ที่ชาร์จใช้งานไม่ได้

7.1 กระบวนการอัปเดตเวอร์ชัน 1.6J

ใน 1.6J นั้นอัปเดตเฟิร์มแวร์คำสั่งนั้นค่อนข้างง่าย เครื่องชาร์จจะดาวน์โหลดอิมเมจและพยายามติดตั้ง ไม่มีกลไกมาตรฐานสำหรับการอัปเดตหลายขั้นตอนหรือการย้อนกลับที่ได้รับการตรวจสอบแล้ว

7.2 การอัปเดตแบบหลายขั้นตอนเวอร์ชัน 2.0.1

OCPP 2.0.1 นำเสนอวงจรชีวิตที่ซับซ้อนยิ่งขึ้นสำหรับการอัปเดตเฟิร์มแวร์:

1. ดาวน์โหลด: ตัวชาร์จจะดึงภาพและตรวจสอบค่าตรวจสอบ/ลายเซ็นของภาพนั้น
2. การติดตั้ง: การอัปเดตจะถูกนำไปใช้กับพาร์ติชันรอง
3. การตรวจสอบระบบจะตรวจสอบว่าเฟิร์มแวร์ใหม่สามารถบูตได้อย่างถูกต้องหรือไม่
4. การเปิดใช้งาน: พาร์ติชั่นหลักถูกสลับแล้ว

หากขั้นตอนใดล้มเหลว โปรโตคอลจะกำหนดวิธีการที่เครื่องชาร์จควรเปลี่ยนกลับไปใช้เวอร์ชันเสถียรก่อนหน้า และรายงานรหัสความล้มเหลวเฉพาะไปยัง CSMS ระดับความน่าเชื่อถือนี้เป็นสิ่งที่ขาดไม่ได้สำหรับการใช้งานเชิงพาณิชย์ขนาดใหญ่

7.3 การตรวจสอบลายเซ็น

เพื่อป้องกันผู้ไม่ประสงค์ดีจากการอัปโหลดเฟิร์มแวร์ที่ถูกบุกรุก เวอร์ชัน 2.0.1 กำหนดให้ใช้ลายเซ็นดิจิทัล เครื่องชาร์จจะปฏิเสธการทำงานของโค้ดใดๆ ที่ไม่ได้ลงนามด้วยคีย์ส่วนตัวของผู้ผลิต ซึ่งเป็นการเพิ่มชั้นการป้องกันที่สำคัญต่อการแฮ็กในระดับฮาร์ดแวร์

บทที่ 8: การคุ้มครองข้อมูลส่วนบุคคล การปฏิบัติตามกฎระเบียบ และ GDPR

เมื่อการชาร์จรถยนต์ไฟฟ้ากลายเป็นสิ่งจำเป็นในชีวิตประจำวัน ข้อมูลส่วนบุคคลที่ถูกสร้างขึ้นจึงมีปริมาณมหาศาล การชาร์จเพียงครั้งเดียวสามารถเชื่อมโยงข้อมูลประจำตัวของผู้ใช้ ตำแหน่งที่ตั้งของรถยนต์ รูปแบบการเดินทาง และข้อมูลทางการเงินของพวกเขาได้

8.1 ข้อมูลส่วนบุคคลที่สามารถระบุตัวตนได้ (PII) ใน OCPP

ในบริบทของกฎระเบียบว่าด้วยการคุ้มครองข้อมูลส่วนบุคคลทั่วไป (GDPR) ในยุโรป และกฎหมายที่คล้ายคลึงกัน เช่น CCPA ในแคลิฟอร์เนีย ข้อมูลต่างๆ เช่นidTag(RFID) หรืออีวีซีไอดี(หมายเลขประจำตัวรถ) ถือเป็นข้อมูลส่วนบุคคลที่ระบุตัวตนได้ (PII)

OCPP 2.0.1 ให้การควบคุมที่ดีขึ้นสำหรับการปกปิดข้อมูลส่วนบุคคล ตัวอย่างเช่นข้อมูลแบบกำหนดเองฟิลด์เหล่านี้ช่วยให้ผู้ปฏิบัติงานสามารถจัดเก็บข้อมูลเมตาโดยไม่ต้องเปิดเผยข้อมูลส่วนบุคคล (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.1J นั้นขึ้นอยู่กับปัจจัยทางการเงิน

9.1 ค่าใช้จ่ายในการดำเนินการ

• OCPP 1.6J: มีต้นทุนการใช้งานต่ำ รองรับโดยฮาร์ดแวร์ราคาประหยัด แต่มีต้นทุนแฝงสูงในด้านการบำรุงรักษาและความเสี่ยงด้านความปลอดภัย
• OCPP 2.0.1: จำเป็นต้องใช้โปรเซสเซอร์ที่มีประสิทธิภาพสูงกว่าและหน่วยความจำใน EVSE มากกว่า ต้นทุนการพัฒนา CSMS สูงขึ้นเนื่องจากความซับซ้อนของโปรโตคอล อย่างไรก็ตาม มันช่วยประหยัดค่าใช้จ่ายในการดำเนินงานได้อย่างมากผ่านการจัดการระยะไกลและความน่าเชื่อถือที่ดีกว่า

9.2 ความเชื่อผิดๆ เกี่ยวกับ “การอัปเกรดที่ราบรื่น”

มักมีการกล่าวกันว่าเครื่องชาร์จ 1.6J สามารถอัปเกรดเป็นเวอร์ชัน 2.0.1 ได้ผ่านทางซอฟต์แวร์ แต่ในความเป็นจริงแล้วนั้นแทบจะไม่เป็นเช่นนั้น ความต้องการด้านหน่วยความจำและซีพียูสำหรับเวอร์ชัน 2.0.1 (โดยเฉพาะการจัดการใบรับรอง TLS และการแยกวิเคราะห์ JSON ที่ซับซ้อนของโมเดลอุปกรณ์) มักเกินขีดความสามารถของตัวควบคุม 1.6J รุ่นเก่า

9.3 เส้นทางการย้ายถิ่นฐานเชิงกลยุทธ์

ผู้บริหารฝ่ายจัดซื้อควรพิจารณาแนวทาง “เครือข่ายแบบผสมผสาน”:

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 จะปรับปรุงการสื่อสารสำหรับ Vehicle-to-Home (V2H) และ Vehicle-to-Building (V2B) ให้ดียิ่งขึ้น ทำให้รถยนต์ไฟฟ้าสามารถจ่ายไฟให้กับบ้านเรือนในช่วงที่ไฟฟ้าดับ หรือลดความต้องการใช้ไฟฟ้าสูงสุดของอาคารพาณิชย์ได้

10.2 รองรับการชาร์จไร้สาย

เมื่อรถยนต์ไร้คนขับ (AVs) เริ่มแพร่หลาย การเสียบปลั๊กด้วยมือจะล้าสมัยไป OCPP 2.1 จะรวมข้อความมาตรฐานสำหรับการชาร์จแบบไร้สาย การจัดการการจัดตำแหน่ง และการถ่ายโอนพลังงานโดยไม่ต้องมีการแทรกแซงจากมนุษย์

10.3 การบูรณาการกับเมืองอัจฉริยะ

ในเวอร์ชันต่อๆ ไป น่าจะมีการบูรณาการที่ลึกซึ้งยิ่งขึ้นกับระบบจัดการจราจรและการพยากรณ์พลังงานหมุนเวียน สถานีชาร์จจะสามารถ "ประมูล" พลังงานในตลาดพลังงานแบบเรียลไทม์ เปลี่ยนเครือข่ายสถานีชาร์จให้กลายเป็นโรงไฟฟ้าเสมือนขนาดใหญ่ (VPPs)

ภาคผนวกทางเทคนิค: เจาะลึกการเปรียบเทียบข้อความ

เพื่อให้ได้ข้อมูลเชิงลึกทางเทคนิคอย่างครบถ้วน เราจะทำการวิเคราะห์ลำดับข้อความและส่วนต่างของเฟรมระหว่างทั้งสองเวอร์ชันโดยละเอียด

A.1 ขั้นตอนการอนุมัติ

ในเวอร์ชัน 1.6J การอนุญาตจะเป็นการตอบสนองแบบไบนารี คือ “ยอมรับ” หรือ “บล็อก”

1.6J AuthorizeResponse:“json [3, "123456", { "idTagInfo": { "status": "Accepted", "expiryDate": "2026-12-31T23:59:59Z" } }]“

ในเวอร์ชัน 2.0.1 คำตอบจะมีบริบทเพิ่มเติม เช่นidTokenประเภทและข้อมูลเพิ่มเติมสำหรับส่วนติดต่อผู้ใช้

2.0.1 AuthorizeResponse:“json [3, "987654", { "idTokenInfo": { "status": "Accepted", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "Welcome back, John! Your balance is $45.00" } } }]“

A.2 การจัดการจังหวะการเต้นของหัวใจและการเชื่อมต่อ

OCPP 2.0.1 ปรับปรุงวิธีการที่สถานีพิสูจน์ว่าตนเอง "ยังมีชีวิตอยู่" ใน 1.6J หากจังหวะการเต้นของหัวใจหากล้มเหลว สถานีมักจะพยายามใหม่เรื่อยๆ ในเวอร์ชัน 2.0.1 สถานีสามารถใช้แจ้งเตือนเหตุการณ์กลไกในการรายงานว่าการเชื่อมต่อกับแบ็กเอนด์รองขาดหายไป ในขณะที่ยังคงรักษาการเชื่อมต่อกับแบ็กเอนด์หลักไว้

A.3 ตารางข้อมูลเมตาโดยละเอียด

บทสรุป

การเปลี่ยนผ่านจาก OCPP 1.6J ไปสู่ ​​2.0.1 ไม่ใช่เพียงแค่การอัปเดตซอฟต์แวร์ แต่เป็นการวิวัฒนาการพื้นฐานของระบบนิเวศการคมนาคมด้วยไฟฟ้า สำหรับผู้ประกอบการเชิงพาณิชย์ 1.6J แสดงถึงความน่าเชื่อถือในอดีต ในขณะที่ 2.0.1 แสดงถึงอนาคตที่ปรับขนาดได้ ปลอดภัย และชาญฉลาด

การเลือกใช้เวอร์ชัน 2.0.1 ในวันนี้คือการลงทุนเพื่อความยั่งยืนในระยะยาว จะช่วยให้มั่นใจได้ว่าฮาร์ดแวร์ของคุณจะใช้งานร่วมกับรถยนต์ไฟฟ้าเจเนอเรชั่นใหม่ได้ เป็นไปตามข้อกำหนดด้านความปลอดภัยทางไซเบอร์ที่เข้มงวดขึ้น และพร้อมสำหรับโอกาสที่คุ้มค่าของการบูรณาการ V2G และสมาร์ทกริด เมื่อตลาดมีการรวมตัวกันมากขึ้น ผู้ให้บริการที่มีชุดโปรโตคอลที่แข็งแกร่งและยืดหยุ่นที่สุดจะเป็นผู้นำในตลาด

บทที่ 11: เจาะลึก: การวิเคราะห์การไหลของข้อความและแผนภาพลำดับ

ในบทนี้ เราจะวิเคราะห์ลำดับการโต้ตอบระหว่าง EVSE และ CSMS เพื่อแสดงให้เห็นถึงความแตกต่างในการทำงานระหว่างเวอร์ชัน 1.6J และ 2.0.1

11.1 ลำดับการบูตและการกำหนดค่า

เมื่อเครื่องชาร์จเชื่อมต่อกับเครือข่ายเป็นครั้งแรก เครื่องชาร์จจะต้องระบุตัวตนและซิงโครไนซ์การตั้งค่าของตนเอง

อัตราการไหลของ OCPP 1.6J:

1. การเชื่อมต่อ WebSocket: ก่อตั้งขึ้นบนท่าเรือหมายเลข 80 หรือ 443
2. การแจ้งเตือนการบูตสถานีส่งข้อมูลผู้ผลิต รุ่น และหมายเลขประจำเครื่อง
3. รับการกำหนดค่าCSMS ร้องขอคีย์ทั้งหมดเพื่อตรวจสอบสถานะปัจจุบัน
4. เปลี่ยนการกำหนดค่าCSMS จะอัปเดตคีย์เฉพาะ (เช่นช่วงเวลาการเต้นของหัวใจ).
5. การแจ้งเตือนสถานะสถานีรายงานว่า “พร้อมให้บริการ”

ขั้นตอนการทำงานของ OCPP 2.0.1:

1. การจับมือ TLS ที่ปลอดภัย: การแลกเปลี่ยนใบรับรองภาคบังคับ
2. การแจ้งเตือนการบูต: รวมถึงเหตุผล(เช่นพาวเวอร์อัพ).
3. รายงาน GetBase: แทนที่จะขอคีย์ทั้งหมด CSMS จะขอ "รายงานพื้นฐาน" ซึ่งจะแสดงลำดับชั้นทั้งหมดของรุ่นอุปกรณ์
4. ตั้งค่าตัวแปรCSMS อัปเดตตัวแปร โปรดทราบว่าเวอร์ชัน 2.0.1 อนุญาตให้ทำการอัปเดตแบบอะตอมิกได้ กล่าวคือ ตั้งค่าตัวแปรหลายตัวในข้อความเดียว และรับประกันว่าทุกตัวจะสำเร็จหรือไม่มีตัวใดสำเร็จเลย
5. แจ้งเตือนเหตุการณ์: สถานีรายงานสถานะเริ่มต้นของส่วนประกอบต่างๆ

11.2 การเจรจาต่อรองการชาร์จอัจฉริยะ

จุดเด่นที่แท้จริงของเวอร์ชัน 2.0.1 คือระบบชาร์จอัจฉริยะ โดยเฉพาะอย่างยิ่งในการจัดการโปรไฟล์การชาร์จหลายแบบ

ในเวอร์ชัน 1.6J ระบบ CSMS จะส่งข้อความตั้งค่าโปรไฟล์การชาร์จซึ่งกำหนดระดับการเรียงซ้อนและตารางเวลา หากสถานีมีตัวเชื่อมต่อหลายตัว การจัดการโปรไฟล์มักจะคลุมเครือ

ในเวอร์ชัน 2.0.1 นั้นตั้งค่าโปรไฟล์การชาร์จมีการเชื่อมโยงอย่างชัดเจนกับโปรไฟล์การชาร์จ วัตถุประสงค์.

• โปรไฟล์สูงสุดของสถานีชาร์จ: จำกัดปริมาณการรับน้ำของสถานีทั้งหมด
• TXDefaultProfile: ค่าเริ่มต้นสำหรับธุรกรรมใหม่ทุกรายการ
• TXProfile: เฉพาะเจาะจงกับธุรกรรมที่กำลังดำเนินอยู่

นอกจากนี้ เวอร์ชัน 2.0.1 ยังรองรับรับระดับสแต็กการชาร์จข้อความนี้ช่วยให้ CSMS สามารถตรวจสอบได้ว่าโปรไฟล์ใดบ้างที่กำลังใช้งานอยู่ และระบบจัดตารางเวลาภายในของ EVSE จัดลำดับความสำคัญของโปรไฟล์เหล่านั้นอย่างไร

11.3 การสั่งงานและการควบคุมระยะไกล

คำสั่งระยะไกล เช่นเริ่มธุรกรรมระยะไกล(1.6J) ได้ถูกแทนที่ด้วยร้องขอเริ่มธุรกรรม(2.0.1) ความแตกต่างที่สำคัญอยู่ที่เพย์โหลด ในเวอร์ชัน 2.0.1 CSMS สามารถรวมได้ดังนี้โปรไฟล์การชาร์จโดยตรงในคำขอเริ่มต้น ซึ่งหมายความว่ารถสามารถเริ่มชาร์จที่ระดับพลังงานที่ถูกต้องได้ทันที โดยไม่ต้องรอข้อความที่สอง ช่วยลดความล่าช้าและเพิ่มเสถียรภาพของระบบไฟฟ้า

บทที่ 12: การเปรียบเทียบ Schema และ Field ของ JSON ระดับต่ำ

สำหรับนักพัฒนาและผู้บูรณาการระบบ การเปลี่ยนแปลงโครงสร้างข้อมูลถือเป็นส่วนที่ต้องใช้แรงงานมากที่สุดในกระบวนการย้ายระบบ

12.1 ประเภทข้อมูลแบบแจงนับ (Enums)

OCPP 2.0.1 ขยายจำนวน Enum มาตรฐานอย่างมาก ลดความจำเป็นในการใช้รหัสสถานะ "กำหนดเอง" ซึ่งเป็นปัญหาในเวอร์ชัน 1.6J

• เหตุผล Enum: หน่วยงานเฝ้าระวัง, รีเซ็ตตามกำหนดเวลา, รีเซ็ตระยะไกล, การสูญเสียพลังงาน.
• สถานะ Enum: ไม่ว่าง, ที่สงวนไว้, ไม่พร้อมใช้งาน, ผิดพลาด. 2.0.1 เพิ่มมีอยู่, ไม่ว่าง, ที่สงวนไว้, ไม่พร้อมใช้งาน, ผิดพลาดแต่จะมีสถานะย่อยเพื่อแสดงรายละเอียดเพิ่มเติม

12.2 ชนิดข้อมูลและหน่วยวัด

OCPP 2.0.1 กำหนดรูปแบบการใช้หน่วยมาตรฐาน (SI) อย่างเป็นทางการ ในขณะที่ 1.6J บางครั้งไม่ได้กำหนดความแม่นยำของทศนิยมไว้ 2.0.1 จึงใช้การกำหนดดังกล่าวทศนิยมประเภทสำหรับค่ากำลังและพลังงาน เพื่อให้มั่นใจได้ว่าการเรียกเก็บเงินมีความสม่ำเสมอในฮาร์ดแวร์ของผู้จำหน่ายที่แตกต่างกัน

บทที่ 13: กรณีศึกษา: การย้ายระบบ CPO ทั่วโลกจากเวอร์ชัน 1.6J ไปยังเวอร์ชัน 2.0.1

ลองมาดูสถานการณ์สมมติของ “MegaCharge” ซึ่งเป็นศูนย์บริการรถยนต์ไฟฟ้าที่มีจุดชาร์จ 10,000 จุดกัน

13.1 ขั้นตอนที่ 1: การตรวจสอบ

MegaCharge ค้นพบว่าเครื่องชาร์จขนาด 1.6J จำนวน 40% ไม่รองรับ TLS 1.2 ซึ่งหมายความว่าเครื่องชาร์จเหล่านั้นไม่มีสิทธิ์เข้าร่วมในสัญญาของรัฐบาลที่จะเกิดขึ้นในอนาคต

13.2 ขั้นตอนที่ 2: การอัปเกรด CSMS

แทนที่จะสร้าง CSMS ใหม่ MegaCharge ได้นำ “เลเยอร์การแปลง OCPP” มาใช้ เลเยอร์นี้จัดการการเชื่อมต่อ 1.6J สำหรับฮาร์ดแวร์รุ่นเก่าและ 2.0.1 สำหรับฮาร์ดแวร์รุ่นใหม่ แต่เปิดเผย API ที่เป็นหนึ่งเดียวให้กับแอปมือถือและระบบเรียกเก็บเงินของพวกเขา

13.3 ขั้นตอนที่ 3: การเปลี่ยนฮาร์ดแวร์

สำหรับสถานที่ที่มีผู้ใช้งานจำนวนมาก MegaCharge ได้เปลี่ยนเครื่องชาร์จ 1.6J เป็นเครื่องชาร์จเร็ว DC ที่ได้มาตรฐาน 2.0.1 ผลลัพธ์คือจำนวนครั้งที่ "เริ่มต้นไม่สำเร็จ" ลดลง 15% ซึ่งส่วนใหญ่เป็นผลมาจากเครื่องชาร์จที่เสถียรยิ่งขึ้นเหตุการณ์ธุรกรรมการจัดการในเวอร์ชัน 2.0.1

13.4 การวิเคราะห์ผลตอบแทนจากการลงทุน (ROI)

การลงทุนเริ่มต้นอยู่ที่ 2 ล้านดอลลาร์ อย่างไรก็ตาม การลดจำนวนการเรียกใช้บริการซ่อมบำรุง (ด้วยระบบวินิจฉัยของ Device Model) ช่วยประหยัดค่าใช้จ่ายได้ถึง 400,000 ดอลลาร์ต่อปี นอกจากนี้ ความสามารถในการเข้าร่วมตลาดตอบสนองความถี่ V2G ยังสร้างรายได้เพิ่มอีก 200,000 ดอลลาร์ต่อปี ระยะเวลาคืนทุนอยู่ที่ประมาณ 3.3 ปี

บทที่ 14: รายการตรวจสอบขั้นสุดท้ายสำหรับผู้ซื้อในการจัดซื้อจัดจ้างตาม OCPP 2.0.1

เมื่อประเมินฮาร์ดแวร์หรือซอฟต์แวร์ใหม่ ให้ใช้รายการตรวจสอบนี้เพื่อให้แน่ใจว่าเป็นไปตามข้อกำหนดอย่างแท้จริง:

14.1 ข้อกำหนดด้านฮาร์ดแวร์ (EVSE)

• [ ]รองรับ Security Profile 3: รองรับการจัดการใบรับรองฝั่งไคลเอ็นต์หรือไม่?
• [ ]โปรเซสเซอร์ดูอัลคอร์: มีพื้นที่เหลือพอสำหรับการเข้ารหัส TLS และการแยกวิเคราะห์ JSON หรือไม่?
• [ ]ส่วนประกอบความปลอดภัย (SE)บอร์ดนี้มีฮาร์ดแวร์ Root of Trust สำหรับจัดเก็บคีย์หรือไม่?
• [ ]พร้อมใช้งานตามมาตรฐาน ISO 15118-2/20ตัวควบคุมสามารถรองรับการสื่อสารระดับสูงที่จำเป็นสำหรับ PnC ได้หรือไม่?
• [ ]ความสามารถในการแสดงผลฮาร์ดแวร์รองรับการแสดงข้อมูลราคา/สถานะผ่าน OCPP หรือไม่การถ่ายโอนข้อมูลหรือข้อความดั้งเดิม?

14.2 ข้อกำหนดด้านซอฟต์แวร์ (CSMS)

• [ ]การแสดงภาพโมเดลอุปกรณ์หน้าแดชบอร์ดสามารถแสดงมุมมองแบบลำดับชั้นของเครื่องชาร์จได้หรือไม่?
• [ ]การบูรณาการหน่วยงานออกใบรับรอง (CA)ระบบ CSMS สามารถออกและหมุนเวียนใบรับรองโดยอัตโนมัติได้หรือไม่?
• [ ]การกระทบยอดธุรกรรมระบบจัดการกับธุรกรรมที่ "ค้าง" จากเครื่องชาร์จแบบเก่าขนาด 1.6J อย่างไร?
• [ ]เครื่องชาร์จไฟอัจฉริยะ: รองรับตรรกะระดับสแต็กขั้นสูงของเวอร์ชัน 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 (เช่นรายงาน GetBase) อาจมีขนาดใหญ่มาก หากบัฟเฟอร์ของเครื่องชาร์จมีขนาดเล็กเกินไป ข้อความจะถูกละทิ้ง

• สารละลายตรวจสอบขนาดข้อความสูงสุดกำหนดค่าตัวแปรในแบบจำลองอุปกรณ์ และตรวจสอบให้แน่ใจว่า CSMS เคารพขีดจำกัดนี้

บทที่ 16: ภาพรวมด้านกฎระเบียบระดับภูมิภาคและข้อกำหนดตามพิธีสาร

การเปลี่ยนไปใช้ OCPP 2.0.1 ไม่ได้เป็นเพียงแรงผลักดันจากเทคโนโลยีเท่านั้น แต่ยังเป็นเรื่องของกฎหมายมากขึ้นเรื่อยๆ ด้วย

16.1 สหภาพยุโรป (AFIR)

ระเบียบข้อบังคับด้านโครงสร้างพื้นฐานเชื้อเพลิงทางเลือก (AFIR) ในสหภาพยุโรปกำหนดให้มีการเปิดเผยราคาอย่างโปร่งใสและสามารถทำงานร่วมกันได้ แม้ว่าจะไม่ได้ระบุถึง OCPP 2.0.1 อย่างชัดเจน แต่ข้อกำหนดเรื่อง "การแบ่งปันข้อมูลแบบเรียลไทม์" และ "การคิดค่าบริการอัจฉริยะ" ทำให้ OCPP 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 พร้อม Security Profile 3

บทที่ 17: ตัวอย่างโค้ดการใช้งาน: รายละเอียดปลีกย่อย

เพื่อช่วยเหลือนักพัฒนา เราได้จัดเตรียมการแสดงผล JSON ในเชิงแนวคิดสำหรับงานที่ซับซ้อนในเวอร์ชัน 2.0.1

17.1 ขั้นตอนการหมุนเวียนใบรับรอง

เมื่อใบรับรองใกล้หมดอายุ ระบบ CSMS จะต้องเริ่มกระบวนการหมุนเวียนใบรับรองใหม่

1. CSMS ส่งใบรับรองลงนามแล้ว:“json [2, "CERT-01", "CertificateSigned", { "certificateChain": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----", "certificateType": "V2G" }]“

2. สถานีตอบสนองยอมรับ:“json [3, "CERT-01", { "status": "Accepted" }]“

3. สถานีส่งการแจ้งเตือนเหตุการณ์ด้านความปลอดภัย:“json [2, "EVT-99", "SecurityEventNotification", { "type": "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 (Open Charge Point Protocol)ภาษาที่พวกเขาพูด
• OCA (Open Charge Alliance)องค์กรที่ร่างภาษา
• ไอโอเอส 15118: โปรโตคอลระหว่างรถยนต์และเครื่องชาร์จ
• PnC (เสียบปลั๊กและชาร์จ)ประสบการณ์การใช้งานของผู้ใช้ที่ได้รับการสนับสนุนจากมาตรฐาน ISO 15118 และ OCPP 2.0.1
• V2G (Vehicle-to-Grid): การส่งพลังงานจากรถยนต์กลับสู่โครงข่ายไฟฟ้า
• V2X (Vehicle-to-Everything): เป็นคำที่ใช้เรียกโดยรวมของ V2G, V2H และ V2B
• TLS (Transport Layer Security): การเข้ารหัสที่ช่วยรักษาความปลอดภัยของข้อมูล
• PKI (โครงสร้างพื้นฐานกุญแจสาธารณะ)ระบบใบรับรองดิจิทัลที่ใช้เพื่อความปลอดภัย
• JSON (JavaScript Object Notation)รูปแบบของข้อความ
• เว็บซ็อกเก็ต: การเชื่อมต่อแบบถาวร “ท่อ” ที่เป็นทางผ่านของการไหลของข้อความ
• รุ่นอุปกรณ์: วิธีการแบบลำดับชั้น 2.0.1 อธิบายถึงฮาร์ดแวร์
• ส่วนประกอบ: ชิ้นส่วนของฮาร์ดแวร์ (เช่น ตัวเชื่อมต่อ)
• ตัวแปร: คุณสมบัติของส่วนประกอบ (เช่น สถานะ)
• คุณลักษณะ: ข้อมูลเมตาเกี่ยวกับตัวแปร (เช่น ค่า ความสามารถในการเปลี่ยนแปลง)
• เหตุการณ์ธุรกรรมข้อความรวมสำหรับข้อมูลเซสชันทั้งหมดในเวอร์ชัน 2.0.1
• จังหวะการเต้นของหัวใจ: สัญญาณ "ฉันยังมีชีวิตอยู่" เป็นระยะๆ
• การแจ้งเตือนการบูต: สัญญาณ "สวัสดี ฉันอยู่ตรงนี้" เมื่อเครื่องชาร์จเริ่มทำงาน
• การถ่ายโอนข้อมูลข้อความ "ครอบคลุมทุกกรณี" สำหรับส่วนขยายเฉพาะของผู้จำหน่าย (ควรใช้ด้วยความระมัดระวัง!)

ข้อคิดส่งท้าย: การใช้ชีวิตในยุคมัลติโปรโตคอล

ในฐานะผู้ซื้อหรือผู้ประกอบการ สิ่งสำคัญที่สุดที่ควรทราบคือ เรากำลังเข้าสู่ยุคใหม่ยุคมัลติโปรโตคอลในช่วง 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 ไม่ใช่การปรับโครงสร้างโค้ด (refactor) แต่เป็นการเขียนโค้ดใหม่ทั้งหมด นักพัฒนาต้องปรับเปลี่ยนวิธีคิดและรูปแบบการทำงาน

19.1 การยอมรับความไม่สอดคล้องกัน

แม้ว่า WebSockets จะทำงานแบบอะซิงโครนัสโดยธรรมชาติ แต่ความซับซ้อนของเวอร์ชัน 2.0.1 หมายความว่าคำขอเดียว (เช่น ) อาจใช้เวลานานรายงาน GetBaseการประมวลผลอาจใช้เวลาหลายวินาทีบนสถานีชาร์จรถยนต์ไฟฟ้าที่มีทรัพยากรจำกัด นักพัฒนา CSMS ต้องใช้ตรรกะการหมดเวลาและการลองใหม่ที่มีประสิทธิภาพ ซึ่งคำนึงถึงความเร็วในการประมวลผลที่แตกต่างกันของผู้ผลิตฮาร์ดแวร์แต่ละราย

19.2 การแยกวิเคราะห์ JSON อย่างมีประสิทธิภาพ

การแยกวิเคราะห์ JSON อาจใช้ทรัพยากร CPU มาก สำหรับเฟิร์มแวร์ EVSE นักพัฒนาควรใช้ตัวแยกวิเคราะห์แบบสตรีมแทนการโหลดข้อมูลทั้งหมดลงใน 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 เพื่อให้มั่นใจว่าแบ็กเอนด์ของคุณสามารถรองรับข้อความจำนวนมหาศาลและข้อกำหนดด้านความปลอดภัยที่เข้มงวดของเวอร์ชัน 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 ตระกูลข้อความใหม่ — ตัวแปรแบบกำหนดประเภท การทำธุรกรรมแบบขับเคลื่อนด้วยเหตุการณ์ และการจัดการใบรับรอง — คือโครงสร้างพื้นฐานที่จำเป็นสำหรับการชาร์จแบบเสียบปลั๊กและชาร์จ การชาร์จอัจฉริยะ และการรายงานตามข้อกำหนด เครื่องชาร์จที่รองรับเฉพาะ 1.6J สามารถติดตั้งเกตเวย์เพิ่มเติมได้ แต่ CSMS ที่รองรับเฉพาะ 1.6J ไม่สามารถมอบรูปแบบความปลอดภัยที่หน่วยงานกำกับดูแลและผู้ผลิตรถยนต์ต้องการมากขึ้นเรื่อยๆ เมื่อประเมินฮาร์ดแวร์ คำว่า “พร้อมใช้งาน 2.0.1” ควรหมายความว่าเฟิร์มแวร์นั้นพร้อมใช้งานในปัจจุบัน ไม่ใช่กำหนดไว้ในปีหน้า และเนื่องจาก OCPP 2.0.1 ทำงานบน JSON-over-WebSocket แทนการขนส่ง SOAP ของ 1.6J กระแสข้อความจึงเบากว่าและแก้ไขข้อผิดพลาดได้ง่ายกว่ามาก — ซึ่งเป็นข้อได้เปรียบที่ทีมไอทีของคุณจะรู้สึกได้ตั้งแต่วันแรก

บทที่ 22: บทสรุป: การตัดสินใจอัปเกรด

สำหรับผู้ประกอบการเชิงพาณิชย์ แนวทางปฏิบัติที่ชัดเจนมีดังนี้:

• การติดตั้งใหม่ควรตั้งค่าเริ่มต้นเป็น OCPP เวอร์ชัน 2.0.1รูปแบบการรักษาความปลอดภัย การจัดการใบรับรอง และการบูรณาการมาตรฐาน ISO 15118 เป็นข้อกำหนดเบื้องต้นสำหรับสภาพแวดล้อมด้านกฎระเบียบในปี 2026
• เครื่องบินขนาด 1.6J ที่มีอยู่ไม่ได้ตกอยู่ในภาวะไร้ทางออกเกตเวย์แบบจัดการได้และแพลตฟอร์ม CSMS แบบสองโปรโตคอลจะช่วยเชื่อมช่องว่างในขณะที่คุณทยอยนำฮาร์ดแวร์ที่รองรับเวอร์ชัน 2.0.1 มาใช้
• ทดสอบก่อนไว้ใจใช้ OCTT, การทดสอบความเข้ากันได้ของอุปกรณ์ (plugfest) และการเปิดใช้งานทีละขั้นตอน — ความเข้ากันได้นั้นได้รับการพิสูจน์แล้วในภาคสนาม ไม่ใช่การคาดเดาจากเอกสารข้อมูลจำเพาะ
• เรียกร้องแผนการย้ายข้อมูลเป็นลายลักษณ์อักษรผู้ผลิตเครื่องชาร์จของคุณควรเผยแพร่แผนงานเฟิร์มแวร์ตั้งแต่เวอร์ชัน 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.