ชาร์จเจอร์ EV ทำอะไรเมื่ออินเทอร์เน็ตหลุด: พฤติกรรมออฟไลน์ของ OCPP 1.6J และจุดที่ Local CSMS Proxy มีประโยชน์

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

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

บทความนี้พูดถึงทั้งสองจังหวะ สำหรับ OCPP 1.6J ซึ่งเป็นเวอร์ชันที่แพลตฟอร์มของเราใช้งานจริงอยู่ในปัจจุบัน

ใครเป็นผู้ตัดสินใจ: ตัวชาร์จเจอร์

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

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

ค่าตั้งค่าที่กำหนดพฤติกรรมออฟไลน์

OCPP 1.6 กำหนด configuration key ที่เกี่ยวข้องไว้ ตัวที่สำคัญที่สุดสำหรับการทำงานออฟไลน์:

Key	ควบคุมอะไร
LocalAuthorizeOffline	อนุญาตให้ชาร์จเจอร์ตรวจสอบ ID tag จากข้อมูลในเครื่องได้หรือไม่ ขณะไม่มีการเชื่อมต่อ
LocalPreAuthorize	อนุญาตให้เริ่มชาร์จทันทีจากการตรวจสอบในเครื่อง โดยไม่รอคำตอบจาก CSMS หรือไม่
AuthorizationCacheEnabled	เก็บแคชผลการอนุมัติครั้งก่อนไว้หรือไม่
LocalAuthListEnabled	ใช้รายชื่อผู้ใช้ที่อนุมัติในเครื่องหรือไม่ (CSMS ส่งรายชื่อไปให้ชาร์จเจอร์)
AllowOfflineTxForUnknownId	ID tag ที่ชาร์จเจอร์ไม่รู้จัก เริ่มชาร์จขณะออฟไลน์ได้หรือไม่
TransactionMessageAttempts และ TransactionMessageRetryInterval	ส่งข้อความธุรกรรมซ้ำกี่ครั้ง และห่างกันเท่าไร
MeterValueSampleInterval	อ่านค่าพลังงานทุกกี่วินาทีระหว่างชาร์จ

ชาร์จเจอร์ไม่ได้รองรับทุก key และค่าเริ่มต้นต่างกัน วิธีที่เชื่อถือได้คืออ่านค่าจริงจากเครื่อง (GetConfiguration ของ OCPP) และถามผู้ผลิตตรง ๆ ว่าออฟไลน์แล้วทำงานอย่างไร แทนที่จะเชื่อบรรทัดเดียวใน datasheet

หน้า EV CSMS ของ Simplico ระบุไว้ในระดับปฏิบัติเช่นกัน ชาร์จเจอร์ที่เป็นไปตาม OCPP อนุญาตให้เซสชันที่ได้รับอนุมัติในเครื่องทำงานต่อด้วยข้อมูล RFID ที่แคชไว้ แล้วซิงก์ธุรกรรมเมื่อเชื่อมต่อกลับมา

เกิดอะไรกับเซสชัน

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

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

สิ่งที่ CSMS ต้องทำให้ถูกเมื่อกลับมาออนไลน์

ตรงนี้คือจุดที่แพลตฟอร์มแสดงฝีมือ สี่ข้อที่เราใช้วัด CSMS ทุกตัว:

1. ใช้เวลาของชาร์จเจอร์ ไม่ใช่เวลาที่ข้อความมาถึง เซสชันที่เริ่ม 20:03 แต่มาถึง 20:27 เกิดขึ้นตอน 20:03 การคิดค่าไฟ รายงาน และช่วงเวลาอัตราค่าบริการขึ้นกับเรื่องนี้
2. ต้องเป็น idempotent การส่งซ้ำทำให้ข้อความเดิมมาถึงสองครั้งได้ การรับซ้ำต้องไม่สร้างเซสชันซ้ำหรือเก็บเงินซ้ำ หลักการเดียวกับที่เราอธิบายไว้สำหรับ API การชำระเงินใน Idempotency in Payment APIs (บทความภาษาอังกฤษ)
3. กระทบยอดก่อนออกบิล อย่าปิดหรือออกใบแจ้งหนี้ขณะที่ชาร์จเจอร์ยังส่งข้อมูลย้อนหลังไม่เสร็จ รอให้ข้อความหยุดและค่ามิเตอร์สุดท้ายมาครบก่อน
4. เก็บข้อความ OCPP ดิบไว้ เมื่อเซสชันดูผิดปกติ ข้อความต้นฉบับคือหลักฐาน แพลตฟอร์มเดโมของเราบันทึกข้อความ OCPP ดิบควบคู่กับเซสชันเพื่อใช้ดีบักเรื่องแบบนี้

เรื่องการชำระเงินทำให้ภาพเปลี่ยน

การทำงานออฟไลน์ราบรื่นสำหรับผู้ใช้ที่ชาร์จเจอร์ตรวจสอบตัวตนได้ในเครื่อง เช่น แท็ก RFID ที่อยู่ในรายชื่อหรือแคช

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

Local CSMS Proxy ใช้เมื่อไร

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

flowchart TD
    A["ชาร์จเจอร์"] --> B["Local CSMS Proxy ที่หน้างาน"]
    B -->|"อัปลิงก์ปกติ"| C["CSMS ส่วนกลาง"]
    B -.->|"อัปลิงก์หลุด เก็บข้อมูลไว้ในเครื่อง"| D["บัฟเฟอร์ในเครื่อง"]
    D -.->|"อัปลิงก์กลับมา ส่งต่อ"| C

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

เป็นการตัดสินใจรายสถานที่ ไม่ใช่ค่าเริ่มต้น เพราะเพิ่มส่วนประกอบที่ต้องดูแล อัปเดต และเฝ้าระวังอีกหนึ่งตัว จึงคุ้มเฉพาะที่ต้นทุนของการหลุดสูงพอ ควรวัดก่อนว่าสถานที่นั้นหลุดบ่อยแค่ไหนจริง ๆ

การทดสอบตอนส่งมอบที่ควรเพิ่ม

ไม่ว่าจะใช้สถาปัตยกรรมแบบไหน ควรทดสอบความล้มเหลวจริง แทนการเชื่อว่าจะผ่าน สำหรับชาร์จเจอร์แต่ละรุ่น:

1. เริ่มเซสชันด้วยแท็ก RFID ที่อยู่ในรายชื่อในเครื่อง
2. ตัดอัปลิงก์กลางเซสชัน (ปิดโมเด็มหรือถอดสายเครือข่าย)
3. ปล่อยให้ชาร์จต่อ แล้วหยุดเซสชันที่ตัวชาร์จเจอร์
4. คืนอัปลิงก์
5. ตรวจว่าเซสชันปรากฏครั้งเดียว เวลาเริ่มและหยุดถูกต้อง พลังงานตรงกับที่หน้าจอชาร์จเจอร์แสดง และไม่มีการเรียกเก็บซ้ำ
6. ทำซ้ำกับเซสชันที่จ่ายผ่าน QR แล้วจดว่าผู้ใช้เจออะไร

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

บทความนี้อ้างและไม่อ้างอะไร

• อธิบายพฤติกรรม OCPP 1.6J ในภาพรวม ชาร์จเจอร์แต่ละรุ่นต่างกัน จึงต้องทดสอบรุ่นของคุณ
• ข้อความเกี่ยวกับแพลตฟอร์มของ Simplico จำกัดอยู่ที่สิ่งที่หน้าสินค้าระบุ คือเซสชัน RFID ที่แคชไว้ทำงานต่อแบบออฟไลน์และซิงก์ได้ และเราติดตั้ง local CSMS proxy ได้สำหรับสถานที่ที่สัญญาณไม่เสถียร
• Local proxy กำหนดขอบเขตรายสถานที่ ไม่ได้อยู่ในทุกการติดตั้ง
• OCPP 2.0.1 มีเส้นทางอัปเกรดสำหรับการติดตั้งใหม่ และไม่ได้ครอบคลุมในบทความนี้

คำถามที่พบบ่อย

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

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

ต้องมี local proxy ไหม?
สถานที่ส่วนใหญ่ไม่จำเป็น ควรคุยกันเมื่อสัญญาณหลุดบ่อยหรือมีต้นทุนสูง เรากำหนดขอบเขตรายสถานที่

รองรับชาร์จเจอร์ยี่ห้อไหนบ้าง?
ชาร์จเจอร์ใดก็ตามที่รองรับ OCPP 1.6J ผ่าน WebSocket เราตรวจสอบรุ่นของคุณระหว่างส่งมอบงาน

ลองดูการทำงานจริง

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

หากกำลังวางแผนสถานีชาร์จและต้องการให้ทดสอบพฤติกรรมออฟไลน์อย่างจริงจัง บอกเราสามอย่าง คือสถานที่ จำนวนหัวชาร์จ และวันที่อยากเปิดใช้งาน เราจะส่งข้อเสนอที่กำหนดขอบเขตแล้วภายใน 48 ชั่วโมง: hello@simplico.net นอกจากนี้เรายังเปิดโปรแกรม Founding Partner (ภาษาอังกฤษ) สำหรับผู้ให้บริการกลุ่มแรกที่ใช้แพลตฟอร์มแบบ self-hosted

OCPP เป็นเครื่องหมายการค้าของ Open Charge Alliance PromptPay และ QR30 เป็นบริการของธนาคารแห่งประเทศไทย