ถ้า Backend ล่ม สถานีชาร์จจะดับทั้งเครือข่ายไหม? สิ่งที่เจ้าของสถานีอยากได้จริง ๆ เมื่อขอ OCPP Endpoint Fallback

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

เมื่อเจ้าของสถานีบอกเราว่า "อยากได้ OCPP endpoint fallback" ภาพนี้คือสิ่งที่เขากังวล เขาต้องการที่อยู่ที่สองให้หัวชาร์จไปต่อได้เมื่อที่อยู่แรกใช้ไม่ได้ เพื่อไม่ให้ปัญหาที่ backend จุดเดียวทำให้ทุกสถานีออฟไลน์พร้อมกัน

ฟังเหมือนฟีเจอร์เดียว แต่จริง ๆ แล้วเป็นปัญหาสามแบบที่ต้องแยกกันก่อน

สามเรื่องที่คนเรียกรวมว่า "fallback"

	อะไรล่ม	กระทบใคร	อ่านต่อที่ไหน
อินเทอร์เน็ตของสถานีขาด	หัวชาร์จออกอินเทอร์เน็ตไม่ได้	สถานีนั้นแห่งเดียว	บทความเรื่อง พฤติกรรม offline ของ OCPP 1.6J และ local CSMS proxy (ภาษาอังกฤษ)
Backend หรือ endpoint ล่ม	หัวชาร์จออกอินเทอร์เน็ตได้ แต่ที่อยู่ของ CSMS ไม่ตอบ หรือตอบผิด	ทุกหัวชาร์จที่ชี้ไปที่นั่น	บทความนี้
เปลี่ยนผู้ให้บริการ	อยากย้ายไป CSMS ใหม่ หรือรันคู่กัน	ทั้งเครือข่าย	พูดถึงสั้น ๆ ด้านล่าง

เจ้าของสถานีมักมองรวมเป็นเรื่องเดียว เพราะอาการเหมือนกันคือจุดแดง แต่วิธีแก้ไม่เหมือนกัน

ปัญหาที่เจ้าของสถานีเล่าให้ฟังบ่อย

ที่อยู่เดียว จุดล้มเหลวเดียว หัวชาร์จแต่ละตัวมี URL ของ CSMS เพียงอันเดียว ถ้าที่อยู่นั้นใช้ไม่ได้ ก็ไม่มีที่ให้ลองต่อ

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

ข้อมูลบิลหายหรือสับสน เซสชันที่เกิดระหว่างระบบล่มต้องถูกเก็บไว้ที่หัวชาร์จแล้วส่งภายหลัง ถ้า backend ที่กลับมามีกฎหรือการนับ transaction ต่างจากเดิม เซสชันอาจซ้ำหรือหายได้

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

ติดกับผู้ขายรายเดียว (lock-in) หัวชาร์จที่ผูกกับ backend ของผู้ขายรายเดียวทำให้เจ้าของย้ายออกลำบาก และทดลองระบบอื่นกับหัวชาร์จบางตัวก่อนก็ทำไม่ได้

การเชื่อมต่อกลับพร้อมกันทั้งฝูง เมื่อ backend กลับมา หัวชาร์จหลายร้อยตัวพยายามเชื่อมต่อในเวลาเดียวกัน ระบบที่เพิ่งฟื้นล้มซ้ำอีก

ทำไมเรื่องนี้ยากใน OCPP

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

OCPP 1.6J เท่าที่เรารู้ สเปกไม่ได้กำหนดรายการ endpoint สำรอง ที่อยู่ของ CSMS อยู่ในการตั้งค่าของหัวชาร์จเอง มักเป็นคีย์เฉพาะของผู้ผลิต ดังนั้นการรองรับที่อยู่ที่สองขึ้นอยู่กับเฟิร์มแวร์ล้วน ๆ คู่มือ improving uptime ของ Open Charge Alliance อธิบายพฤติกรรม offline ละเอียด แต่ไม่ได้พูดถึงการใช้ backend URL หลายอันหรือ CSMS failover

OCPP 2.0.1 เพิ่มวิธีเก็บ connection profile ไว้ในหัวชาร์จ CSMS ส่งข้อความ SetNetworkProfile เพื่อวาง profile ซึ่งมีที่อยู่ CSMS และ security profile ลงใน configuration slot ที่มีหมายเลขได้ และสเปกยังมี use case สำหรับย้ายหัวชาร์จไปยัง CSMS ใหม่ ซึ่งทำให้หัวชาร์จมีที่ไปมากกว่าหนึ่งแห่ง แต่หัวชาร์จเลือกระหว่างกันอย่างไรและสลับเมื่อไรต้องยืนยันกับผู้ขาย หัวชาร์จที่ติดตั้งอยู่จริงจำนวนมาก รวมถึงในไทย ยังเป็น 1.6J จึงอย่าเพิ่งพึ่งเส้นทาง 2.0.1

ข้อสรุปเชิงปฏิบัติคือ สำหรับหัวชาร์จส่วนใหญ่ที่ติดตั้งแล้ว fallback ต้องออกแบบรอบ ๆ หัวชาร์จ ไม่ใช่อยู่ในโปรโตคอล

สี่ชั้นที่ทำ fallback ได้

flowchart TD
    A["หัวชาร์จ"] --> B["ชั้น 1 URL สำรองในเฟิร์มแวร์"]
    A --> C["ชั้น 2 hostname คงที่หนึ่งชื่อ"]
    C --> D["CSMS หลัก"]
    C --> E["CSMS สำรอง"]
    A --> F["ชั้น 3 local proxy ที่หน้างาน"]
    F --> C
    A --> G["ชั้น 4 โหมด offline ของหัวชาร์จ"]

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

ชั้น 2: hostname คงที่หนึ่งชื่อ แล้วทำ failover ไว้ข้างหลัง ให้หัวชาร์จชี้ไปที่ชื่อเดียวที่คุณควบคุมเอง ด้านหลังชื่อนั้น DNS หรือ load balancer ส่งการเชื่อมต่อไปยัง backend ที่ยังปกติ และ standby รับช่วงได้โดยไม่ต้องแตะหัวชาร์จสักตัว วิธีนี้ใช้ได้กับหัวชาร์จที่รู้จัก URL เดียว ข้อแลกเปลี่ยนคือคุณต้องดูแลชื่อ ใบรับรอง และ health check เอง

ชั้น 3: local proxy ที่หน้างาน บริการขนาดเล็กในเครือข่ายของสถานีทำให้หัวชาร์จคุยกับอะไรสักอย่างที่อยู่ใกล้ เก็บข้อความไว้ แล้วส่งต่อเมื่อติดต่อ backend ได้ และยังถือรายการ backend ได้ด้วย เหมาะที่สุดกับสถานีห่างไกลหรือสถานีที่ดาวน์ไทม์แพง มันเพิ่มชิ้นส่วนที่ต้องอัปเดตและเฝ้าดู จึงเป็นการตัดสินใจรายสถานี

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

สิ่งที่ fallback แก้ไม่ได้

ระวังคนที่บอกว่าแค่เพิ่ม URL ที่สอง

• สอง backend ต้องรู้เรื่องเดียวกัน standby ที่ไม่มีรายชื่อหัวชาร์จ รายการ RFID ค่าไฟ และข้อมูลยืนยันตัวตนชุดเดียวกัน จะปฏิเสธหัวชาร์จหรือคิดเงินผิด
• ห้ามมีสองสมองคุมหัวชาร์จตัวเดียว ถ้าสอง backend คิดว่าตัวเองเป็นเจ้าของหัวชาร์จเดียวกัน จะเกิดเลข transaction ซ้ำและคำสั่งขัดกัน ต้องกำหนดว่าตัวไหน active และประกาศส่งมอบอย่างไร
• ใบรับรองและข้อมูลยืนยันตัวตนต้องตามหัวชาร์จ standby ต้องมีใบรับรองที่ถูกต้องสำหรับชื่อที่หัวชาร์จคาดหวัง และต้องรับ identity และรหัสผ่านหรือใบรับรองชุดเดียวกัน
• การเชื่อมต่อกลับต้องมีจังหวะ สำหรับหัวชาร์จ OCPP 2.0.1 Open Charge Alliance แนะนำให้ปรับค่า back-off โดยให้เวลารอขั้นต่ำน้อย ๆ แต่ช่วงสุ่มกว้าง เพื่อไม่ให้ทั้งฝูงกลับมาพร้อมกัน
• การชำระเงินเป็นอีกหนึ่งการพึ่งพา เซสชัน QR และ PromptPay ขึ้นกับเส้นทางยืนยันการชำระเงิน ไม่ใช่แค่ OCPP
• การให้คนที่ไม่รู้จักชาร์จตอน offline มีต้นทุน การอนุญาตให้ใครก็ชาร์จได้ตอน offline คือความเสี่ยงที่เจ้าของรับเอง คู่มือของ OCA ระบุว่าเรื่องนี้มักยอมรับได้กับเครื่อง AC แต่มักเสี่ยงเกินไปสำหรับ DC fast charger

คำถามที่ควรถามผู้ขายหัวชาร์จและผู้ให้บริการ CSMS

คำถาม	ทำไมสำคัญ
เฟิร์มแวร์รับ CSMS URL ที่สองไหม และเลือกอย่างไร	บอกว่ามีชั้น 1 หรือไม่
เปลี่ยน URL ทางไกลได้ไหม หรือต้องไปหน้างาน	บอกต้นทุนเมื่อ backend ล่ม
ใช้ OCPP เวอร์ชันไหน และ 2.0.1 รองรับ SetNetworkProfile ไหม	บอกตัวเลือกที่มี
หัวชาร์จเก็บและส่งซ้ำ transaction ที่ค้างได้นานแค่ไหน	ปกป้องบันทึกการเรียกเก็บเงิน
ค่า back-off หลังเชื่อมต่อไม่สำเร็จเป็นเท่าไร	ป้องกันการเชื่อมต่อกลับพร้อมกัน
หัวชาร์จใช้ hostname ที่เราควบคุมพร้อม TLS ได้ไหม	ทำให้ชั้น 2 เป็นไปได้
CSMS สำรองนำเข้าข้อมูลหัวชาร์จ แท็ก และค่าไฟชุดเดียวกันได้ไหม	ทำให้ standby ใช้ได้จริง
เคยทดสอบ failover กับรุ่นนี้จริงหรือยัง	หลักฐานเดียวที่นับ

สิ่งที่เรามีวันนี้ และสิ่งที่เป็นงานโครงการ

เราแยกสองส่วนนี้ให้ชัด

เป็นส่วนของแพลตฟอร์มวันนี้: OCPP 1.6J engine, OCPP 2.0.1 เป็นเส้นทางอัปเกรด, managed hosting พร้อม backup และการซ้อมกู้คืน, การเฝ้าดู uptime และเวร on-call และตัวเลือก local CSMS proxy สำหรับสถานีที่เครือข่ายไม่เสถียร

ประเมินเป็นรายโครงการ ไม่ใช่สวิตช์ที่เปิดได้ทันที: การออกแบบ hostname คงที่และ failover หน้า backend ของคุณ การจัดเตรียม standby และการซิงก์ข้อมูลที่ต้องใช้ การทบทวนค่า back-off และการเชื่อมต่อกลับสำหรับฝูงหัวชาร์จของคุณ และการทดสอบ failover ตอน commissioning สำหรับหัวชาร์จแต่ละรุ่นที่คุณใช้

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

ถ้าคุณมีหัวชาร์จที่ใช้งานอยู่และอยากรู้ว่าเสี่ยงแค่ไหน ส่ง ยี่ห้อและรุ่นหัวชาร์จ เวอร์ชัน OCPP วิธีตั้งค่าที่อยู่ CSMS และจำนวนสถานี มาที่ hello@simplico.net หัวข้อ "OCPP fallback review" เราจะตอบกลับพร้อมแนวทางโดยสรุปภายใน 48 ชั่วโมง หรือติดต่อทาง LINE: iiitum1984

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

เพิ่ม URL ที่สองให้ทุกหัวชาร์จเลยได้ไหม?
ได้เฉพาะเมื่อเฟิร์มแวร์รองรับ บน OCPP 1.6J ไม่มีรายการสำรองมาตรฐาน หัวชาร์จจำนวนมากจึงรับที่อยู่เดียว วิธีที่ใช้บ่อยคือ hostname คงที่ที่มี failover อยู่ข้างหลัง

OCPP 2.0.1 แก้ปัญหานี้ได้ไหม?
ช่วยได้ เพราะหัวชาร์จเก็บ connection profile ได้มากกว่าหนึ่งอัน แต่คุณยังต้องยืนยันว่าหัวชาร์จของคุณเลือกระหว่าง profile อย่างไร และหัวชาร์จที่ติดตั้งอยู่จำนวนมากยังเป็น 1.6J

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

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

local proxy กับ CSMS สำรองเหมือนกันไหม?
ไม่เหมือน proxy เก็บและส่งต่อให้สถานีเดียว CSMS สำรองคือระบบกลางที่สองที่รับช่วงทั้งฝูงได้ บางการออกแบบใช้ทั้งสองอย่างร่วมกัน

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

ใครอยู่เบื้องหลังบทความนี้?
Simplico บริษัทพัฒนาซอฟต์แวร์ในประเทศไทย เราสร้างและดูแลแพลตฟอร์มสถานีชาร์จ EV ให้ผู้ประกอบการในไทยและเอเชียตะวันออกเฉียงใต้

บทความที่เกี่ยวข้อง

• What an EV Charger Does When the Internet Drops: OCPP 1.6J Offline Behaviour and Where a Local CSMS Proxy Fits
• How to Build an EV Charging Network Using OCPP: Architecture, Technology Stack and Cost Breakdown
• Scoping an EV Charging Platform for a Large Property Owner
• แพลตฟอร์มสถานีชาร์จ EV (CSMS) ของ Simplico
• Improving uptime with OCPP, Open Charge Alliance