แอปชาร์จ EV ที่คุณไม่ต้องสร้างเอง: ระบบ QR Code กับ OCPP ID Tag

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

หากคุณเคยอ่านบทความ การสร้างระบบกลาง OCPP 1.6 ด้วย Flask, WebSocket และ MongoDB ของเรา คุณจะคุ้นเคยกับฝั่งที่เครื่องชาร์จคุยกับ backend อยู่แล้ว บทความนี้เติมเต็มอีกครึ่งหนึ่งที่มักถูกมองข้าม

ทีมส่วนใหญ่ที่วางแผนสร้างแอปสำหรับผู้ขับ EV จะเริ่มด้วยแนวคิด "สร้างแอป native" ซึ่งกลายเป็นรายการค่าใช้จ่ายที่แพงที่สุดในโปรเจกต์แบบเงียบๆ: สอง codebase, รอบการรีวิวจาก App Store, บังคับอัปเดตทุกครั้งที่โครงสร้างค่าบริการเปลี่ยน และขั้นตอนดาวน์โหลดที่ผู้ขับส่วนใหญ่ไม่อยากทำเพื่อชาร์จครั้งเดียว

มีรูปแบบที่ง่ายกว่า และเป็นแบบที่เราใช้งานจริงในโปรดักชัน: QR code ที่หัวชาร์จเปิดหน้าเว็บบนมือถือ ไม่ต้องติดตั้ง ไม่ต้องสมัครสมาชิก และผู้ขับเริ่มชาร์จได้ภายในสี่การแตะ บทความนี้อธิบายว่าระบบนี้ทำงานอย่างไรภายใต้ OCPP, backend ของคุณต้องสร้างอะไรบ้าง และมีเดโมที่ใช้งานได้จริงให้คุณสร้าง QR code ทดสอบได้ทันที

สารบัญ

การยืนยันตัวตนผู้ขับอยู่ตรงไหนใน OCPP
สองวิธียืนยันตัวตน: RFID กับ ID Tag ที่แอปสร้างขึ้น
ขั้นตอน QR Code แบบครบวงจร
สิ่งที่ Backend ของคุณต้องสร้าง
ทดลองใช้งานจริง
ข้อควรพิจารณาด้านการปฏิบัติตามกฎหมาย
คำถามที่พบบ่อย

การยืนยันตัวตนผู้ขับอยู่ตรงไหนใน OCPP

OCPP 1.6 ไม่สนใจว่าผู้ขับได้รับการยืนยันตัวตนมาอย่างไร — มันสนใจแค่ว่ามี idTag แนบมากับ Authorize.req หรือ StartTransaction.req สเปกไม่ระบุแหล่งที่มาของ tag นั้น อาจเป็น:

บัตร RFID จริง ที่เครื่องชาร์จอ่านเอง
tag ที่พิมพ์ผ่านคีย์แพดของเครื่องชาร์จ
tag ที่ backend ของคุณส่งให้เครื่องชาร์จทางไกลผ่าน RemoteStartTransaction.req

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

CS→CP: RemoteStartTransaction.req(connectorId, idTag)
CP→CS: RemoteStartTransaction.conf(status=Accepted)
CP→CS: StatusNotification.req(status=Preparing)
CP→CS: StartTransaction.req(connectorId, idTag, meterStart, timestamp)
CS→CP: StartTransaction.conf(transactionId, idTagInfo.status=Accepted)

นี่คือลำดับข้อความเดียวกับที่ dashboard ของคุณใช้เมื่อผู้ดูแลระบบกด "Remote Start" บนเครื่องชาร์จ — แอปผู้ขับก็เป็นเพียงผู้เรียกฟังก์ชัน backend เดียวกันตัวที่สอง แค่จำกัดขอบเขตไว้ที่เครื่องชาร์จเดียวและเซสชันเดียว

สองวิธียืนยันตัวตน: RFID กับ ID Tag ที่แอปสร้างขึ้น

ทั้งสองรูปแบบทำงานคู่กันได้บน CSMS เดียวกัน และระบบโปรดักชันส่วนใหญ่ก็ทำแบบนั้น:

	บัตร RFID	ID Tag ที่แอปสร้างขึ้น
การตั้งค่าต่อผู้ใช้	บัตรจริง ส่งทางไปรษณีย์หรือแจกมือ	ไม่ต้องมี — สร้างเมื่อสแกนครั้งแรก
จุดที่ยืนยันตัวตน	ที่เครื่องอ่านของหัวชาร์จ	Backend แล้วส่งผ่าน RemoteStart
เหมาะกับ	ศูนย์ชาร์จของฟลีต, พนักงาน, ผู้ใช้ประจำที่มีบัตรอยู่แล้ว	หัวชาร์จสาธารณะ, แขกโรงแรม, ผู้มาเยือนครั้งเดียว
การเพิกถอนสิทธิ์	ปิดใช้งาน `id_tag` ของบัตร	จำกัดขอบเขตแค่เซสชัน ไม่มีอะไรต้องเพิกถอน
สิ่งที่ Backend ต้องมี	ระเบียน User ที่มี `id_tag` ตรงกัน	การแมป URL กับเครื่องชาร์จ + คำสั่ง RemoteStart

เส้นทาง RFID ต้องการระเบียน User ที่ฟิลด์ id_tag ตรงกับสตริงที่บัตรส่งมาทุกตัวอักษร — tag ที่ไม่ได้ลงทะเบียนจะถูกปฏิเสธทันที ส่วนเส้นทาง ID tag ที่แอปสร้างขึ้นข้ามขั้นตอนระเบียนผู้ใช้ไปเลยสำหรับผู้ขับทั่วไป: หน้าเว็บสร้าง tag แบบใช้ครั้งเดียวที่ผูกกับเซสชันนั้นและลงทะเบียนให้อัตโนมัติ

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

ขั้นตอน QR Code แบบครบวงจร

flowchart TD
    A["ผู้ขับสแกน QR code ที่หัวชาร์จ"] --> B["หน้าเว็บมือถือเปิดขึ้นไม่ต้องติดตั้ง"]
    B --> C["เลือกขั้วต่อถ้าเครื่องชาร์จมีมากกว่าหนึ่งขั้ว"]
    C --> D["ตั้งงบประมาณการชาร์จหรือกำหนดเอง"]
    D --> E["แอปสร้าง ID tag และเรียก RemoteStartTransaction"]
    E --> F["เครื่องชาร์จยืนยันตัวตนและเริ่มเซสชัน"]
    F --> G["หน้าจอเซสชันสดแสดงพลังงาน ค่าใช้จ่าย และระยะเวลา"]
    G --> H["ผู้ขับกดหยุด"]
    H --> I["ระบบสร้างใบเสร็จ"]

QR code แต่ละอันเข้ารหัส URL เดียว: รหัสเครื่องชาร์จและหมายเลขขั้วต่อ (ถ้ามี) เช่น https://your-domain.com/ev?cp=CP_014&connector=2 นั่นคือขั้นตอน "ติดตั้งแอป" ทั้งหมด — กล้องมือถือของผู้ขับอ่านค่าแล้วเปิดแท็บเบราว์เซอร์ ไม่มีรายการใน App Store ไม่มีคิวรีวิวจาก Play Store ไม่มีการบังคับอัปเดตเมื่อคุณเปลี่ยนโครงสร้างราคาไตรมาสหน้า

สิ่งที่ Backend ของคุณต้องสร้าง

สามส่วน บนพื้นฐาน OCPP server ที่คุณน่าจะมีอยู่แล้ว:

1. รูปแบบ URL แบบไม่มี state GET /ev?cp={charge_point_id}&connector={n} — ไม่ต้องใช้ session token จนกว่าผู้ขับจะเริ่มชาร์จจริง นี่คือสิ่งที่ QR code เข้ารหัส และทำให้มันพิมพ์แล้วติดถาวรได้ คุณไม่ต้องออก QR code ใหม่เพราะ URL ไม่มีวันหมดอายุหรือหมุนเวียน

2. Endpoint RemoteStartTransaction ที่จำกัดขอบเขตต่อเครื่องชาร์จ เมื่อผู้ขับกด "เริ่ม" backend ของคุณสร้าง idTag แบบใช้ครั้งเดียว (UUID ก็เพียงพอ) ลงทะเบียนกับระเบียนเซสชันแบบมีอายุสั้น แล้วเรียก RemoteStartTransaction บนเครื่องชาร์จที่ระบุจาก URL

3. ระบบ polling หรือ WebSocket feed สำหรับหน้าจอเซสชันสด ข้อความ MeterValues.req มาจากเครื่องชาร์จทุก 10–60 วินาทีระหว่างเซสชันที่ใช้งานอยู่ แสดง Energy.Active.Import.Register เป็น kWh สะสมแล้วคูณด้วยอัตราค่าไฟของคุณเพื่อแสดงค่าใช้จ่ายแบบเรียลไทม์

ทดลองใช้งานจริง

แทนที่จะอธิบายเป็นทฤษฎี เราสร้างขั้นตอนจริงให้ทดลอง: กรอกรหัสเครื่องชาร์จ แล้วรับ QR code และ URL แอปผู้ขับที่ใช้งานได้จริง สร้างสดจาก CSMS เดโมจริง

เปิดหน้าตั้งค่าและสร้าง QR →

หน้านี้รองรับภาษาไทยในตัว และพาคุณผ่านขั้นตอนเชื่อมต่อเครื่องชาร์จ ขอข้อมูลรับรอง WebSocket ลงทะเบียน ID tag และ — ส่วนที่เกี่ยวข้องที่สุดกับบทความนี้ — สร้าง URL แอปผู้ขับและ QR code สำหรับเครื่องชาร์จใดก็ได้ พร้อมมุมมองสดว่าเครื่องชาร์จเดโมใดเชื่อมต่ออยู่บ้าง

ข้อควรพิจารณาด้านการปฏิบัติตามกฎหมาย

แอปเว็บแบบไม่ต้องติดตั้งยังคงเก็บข้อมูล — ระยะเวลาเซสชัน พลังงานที่ส่งมอบ และ (ถ้ารับชำระเงิน) บันทึกธุรกรรม สิ่งที่ควรออกแบบไว้ตั้งแต่ต้นแทนที่จะแก้ทีหลัง:

การลดข้อมูลส่วนบุคคลให้น้อยที่สุดตาม PDPA ID tag ที่แอปสร้างขึ้นควรจำกัดขอบเขตแค่เซสชันเดียว ไม่ผูกกับตัวตนผู้ขับแบบถาวร เว้นแต่ผู้ขับจะสร้างบัญชีเอง ซึ่งช่วยลดขอบเขตความรับผิดชอบหากอุปกรณ์สูญหายหรือเซสชันเป็นข้อพิพาท
การเก็บรักษาใบเสร็จ ผู้ประกอบการ EV ในไทยที่รายงานภายใต้นโยบายส่งเสริม EV ต้องมีบันทึกเซสชัน (พลังงานที่ส่งมอบต่อเซสชัน, รหัสเครื่องชาร์จ, timestamp) ที่เรียกดูได้ — ควรส่งใบเสร็จทางอีเมลหรือ SMS เมื่อจบเซสชันแทนที่จะแสดงในเบราว์เซอร์เท่านั้น
ความโปร่งใสของอัตราค่าบริการ แสดงอัตราต่อ kWh หรือต่อนาทีก่อนที่ผู้ขับจะยืนยันงบประมาณ ไม่ใช่แค่ยอดรวมหลังจบเซสชัน

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

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

ถ้าผู้ขับปิดแท็บเบราว์เซอร์กลางเซสชันจะเกิดอะไรขึ้น
เซสชันการชาร์จเองไม่ได้รับผลกระทบ — มันทำงานอยู่ที่เครื่องชาร์จและติดตามโดย backend ผ่าน transaction ID โดยไม่ขึ้นกับแท็บเบราว์เซอร์ การเปิด URL ที่เข้ารหัสใน QR เดิมอีกครั้งจะเชื่อมต่อกลับเข้าสู่เซสชันที่กำลังดำเนินอยู่

ใช้ร่วมกับแอป native สำหรับผู้ขับฟลีตที่ลงทะเบียนได้ไหม
ได้ ใช้ RFID หรือแอป native สำหรับผู้ใช้ที่ลงทะเบียนมีบัญชีถาวร และใช้ขั้นตอน QR/เว็บสำหรับการชาร์จสาธารณะหรือผู้มาเยือนบนเครื่องชาร์จและ backend เดียวกัน

รองรับ OCPP 2.0.1 นอกจาก 1.6 ไหม
รองรับ โดยมีข้อแตกต่างหนึ่งอย่าง: 2.0.1 ใช้ RequestStartTransactionRequest แทน RemoteStartTransaction.req และ ID token มีฟิลด์ type ชัดเจน (Central, ISO14443 เป็นต้น) แทนสตริงเปล่า

กำลังสร้างส่วนหน้าสำหรับผู้ขับของระบบ OCPP หรืออยากดูว่าส่วนนี้เข้ากับ CSMS แบบเต็มรูปแบบอย่างไร เราใช้สแตกนี้ในโปรดักชันจริง

ทดลองเดโมสด — สร้าง QR code จริงได้ภายในไม่ถึงหนึ่งนาที

hello@simplico.net — เราตอบกลับภายในหนึ่งวันทำการ

Simplico Co., Ltd. · กรุงเทพฯ ประเทศไทย · ให้บริการทั่วอาเซียนและญี่ปุ่น

บริการที่เกี่ยวข้อง