ทำความเข้าใจ OCPI: สิ่งที่ CPO และ eMSP ต้องสร้างจริงเพื่อรองรับการชาร์จข้ามเครือข่าย

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

บทความนี้ไม่ใช่การไล่อ่านสเปกโปรโตคอล แต่เป็นภาพระดับธุรกิจ: OCPI ทำหน้าที่อะไร ทำไมปี 2026 มันสำคัญกว่าเมื่อสองปีก่อน และการทำ integration ให้ใช้งานได้จริงต้องเตรียมอะไรบ้าง

ก่อนอื่น ต้องแยกให้ออก: OCPI ไม่ใช่ OCPP

โปรโตคอลตัวย่อ "OC" มีสองตัวที่ขับเคลื่อนระบบชาร์จ EV และการสับสนระหว่างสองตัวนี้คือสาเหตุอันดับต้น ๆ ที่ทำให้บรีฟทีมพัฒนาผิดพลาด

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

OCPP (Open Charge Point Protocol) เชื่อมต่อตัวเครื่องชาร์จเข้ากับระบบหลังบ้านของตัวเอง เป็นบทสนทนาระดับ "เริ่มชาร์จ หยุดชาร์จ นี่คือค่ามิเตอร์" ระหว่างสถานีกับผู้ดูแลระบบ
OCPI (Open Charge Point Interface) เชื่อมต่อ ธุรกิจสองฝ่าย: ผู้ให้บริการสถานีชาร์จ (CPO) กับผู้ให้บริการแอปสำหรับผู้ขับ (eMSP) เป็นบทสนทนาระดับ "ลูกค้าของคุณเพิ่งชาร์จที่สถานีของเรา นี่คือใบแจ้งหนี้" ระหว่างสองแพลตฟอร์ม

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

สองบทบาท: CPO และ eMSP

CPO (Charge Point Operator) เป็นเจ้าของและดูแลเครื่องชาร์จจริง ตั้งแต่เลือกทำเล ฮาร์ดแวร์ การจัดหาพลังงาน ความพร้อมใช้งาน ไปจนถึงการควบคุมฝั่ง OCPP
eMSP (e-Mobility Service Provider) เป็นเจ้าของความสัมพันธ์กับผู้ขับ ทั้งแอป บัญชีสมาชิกหรือการชำระเงิน ฝ่ายบริการลูกค้า และคำสัญญาที่ว่า "ชาร์จที่ไหนก็ได้"

หลายบริษัททำทั้งสองบทบาทพร้อมกัน แต่ทันทีที่ผู้ขับต้องการชาร์จบนเครือข่ายที่ไม่มีบัญชีตรงอยู่ จำเป็นต้องมี OCPI เพื่อให้เซสชันนั้นและเงินที่ตามมาทำงานได้จริง

ทำไมเรื่องนี้ถึงสำคัญมากขึ้นตอนนี้

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

แรงผลักดันด้านกฎระเบียบระหว่างประเทศ: กฎระเบียบโครงสร้างพื้นฐานเชื้อเพลิงทางเลือกของสหภาพยุโรปกำหนดให้ CPO สาธารณะต้องเปิดเผยข้อมูลความพร้อมใช้งานและราคาแบบเรียลไทม์ให้ eMSP โดยใช้ OCPI เป็นแนวทางมาตรฐาน แนวโน้มด้านมาตรฐานเชื่อมต่อลักษณะนี้กำลังขยายตัวในหลายภูมิภาครวมถึงโครงการที่ได้รับทุนสนับสนุนจากภาครัฐ
ความคาดหวังของผู้ขับ: ไม่มีใครอยากมีแอปชาร์จ EV ห้าแอปในเครื่อง เครือข่ายที่ไม่รองรับการชาร์จข้ามเครือข่ายจะเสียเซสชันให้เครือข่ายที่รองรับ
บริบทตลาดไทย: การขยายตัวของสถานีชาร์จในเขตพัฒนาพิเศษภาคตะวันออก (EEC) และการลงทุนของค่ายรถ EV จากจีนในไทย ทำให้เครือข่ายชาร์จในประเทศมีแนวโน้มต้องเชื่อมต่อกับผู้ให้บริการแอปหลายรายมากขึ้น ทั้งในประเทศและระดับภูมิภาค การเตรียม OCPI ตั้งแต่ต้นช่วยลดงาน integration แบบเฉพาะกิจในภายหลัง

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

การเชื่อมต่อจริงทำได้สองแบบ: Bilateral กับ Hub

Bilateral (จุดต่อจุด): เชื่อมต่อตรงระหว่าง CPO หนึ่งรายกับ eMSP หนึ่งราย พร้อมแลกเปลี่ยน access token ภายใต้สัญญา ควบคุมได้เต็มที่ แต่ทุกพาร์ทเนอร์ใหม่คือ integration ใหม่
Hub: ทั้งสองฝ่ายเชื่อมต่อกับ hub กลางแทนที่จะเชื่อมกันเอง เชื่อมครั้งเดียวเปิดทางเข้าถึงพาร์ทเนอร์ทุกรายที่อยู่บน hub ขยายได้เร็วกว่า แต่ควบคุมความสัมพันธ์แต่ละรายได้น้อยลง
แบบผสม: ผู้ประกอบการรายใหญ่มักใช้ทั้งสองแบบ — Bilateral กับพาร์ทเนอร์เชิงกลยุทธ์ไม่กี่ราย และ Hub สำหรับส่วนที่เหลือ

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

ข้อมูลอะไรบ้างที่ OCPI ส่งผ่านระหว่างแพลตฟอร์ม

Locations — ตำแหน่งเครื่องชาร์จ ประเภทหัวชาร์จ และสถานะความพร้อมใช้งานแบบเรียลไทม์
Sessions — การอนุมัติสิทธิ์ เริ่ม/หยุดการชาร์จ และสถานะเรียลไทม์ของเซสชันที่กำลังทำงาน
CDR (Charge Detail Record) — บันทึกฉบับสมบูรณ์ที่ใช้สำหรับออกบิลและชำระเงินระหว่าง CPO กับ eMSP
Tariffs — ข้อมูลราคาที่ทำให้ eMSP แสดงค่าใช้จ่ายจริงให้ผู้ขับเห็นก่อนเสียบปลั๊ก

หากชั้น CDR และการชำระเงินผิดพลาด มันจะไม่ล้มแบบชัดเจนทันที แต่จะค่อย ๆ กลายเป็นข้อพิพาทเรื่องบิลและปัญหาการกระทบยอดที่โผล่มาทีหลังหลายเดือน

สร้างเอง เชื่อมต่อ หรือใช้บริการ Hub?

สร้าง OCPI ในระบบ CSMS ของตัวเอง — เหมาะกับกรณีที่การชาร์จเป็นแกนหลักของธุรกิจ และมีทีมวิศวกรที่ดูแล backend ของเครื่องชาร์จอยู่แล้ว
ผสาน OCPI module เข้ากับ CSMS ที่มีอยู่ — เร็วกว่า แต่คุณภาพขึ้นอยู่กับว่าเชื่อมกับข้อมูล session, auth และ billing ได้ดีแค่ไหน
เชื่อมต่อผ่านผู้ให้บริการ roaming hub — ใช้แรงงานวิศวกรน้อยที่สุดในการเข้าถึงพาร์ทเนอร์จำนวนมาก แลกกับการพึ่งพา uptime และเงื่อนไขเชิงพาณิชย์ของ hub นั้น

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

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

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

OCPI กับ OICP เหมือนกันไหม?
ไม่เหมือนกัน OICP เป็นโปรโตคอลเฉพาะของ Hubject ใช้สำหรับเชื่อมต่อกับเครือข่าย Hubject โดยเฉพาะ ส่วน OCPI เป็นมาตรฐานเปิดที่เป็นกลางต่อผู้ให้บริการทุกราย และเป็นค่าเริ่มต้นสำหรับการเชื่อมต่อแบบ bilateral ส่วนใหญ่

ควรพัฒนาตาม OCPI เวอร์ชันไหน?
ระบบที่ใช้งานจริงในปี 2026 ส่วนใหญ่ยังใช้ OCPI 2.2.1 ขณะที่ 2.3.0 กำลังได้รับความนิยมเพิ่มขึ้นจากฟีเจอร์ด้านกฎระเบียบและภาษี ส่วน OCPI 3.0 ยังอยู่ระหว่างพัฒนาและยังไม่เหมาะสำหรับโครงการใหม่

ระบบ CSMS ที่ใช้ OCPP อยู่แล้วต้องสร้างใหม่ทั้งหมดไหมถ้าจะเพิ่ม OCPI?
โดยทั่วไปไม่จำเป็น หากระบบมีโครงสร้างข้อมูล session, location และ tariff ที่ชัดเจนอยู่แล้ว ชั้น OCPI จะทำงานคู่ขนานไปกับ OCPP ไม่ใช่มาแทนที่ เพราะทั้งสองโปรโตคอลดูแลคนละฝั่งของเซสชันการชาร์จเดียวกัน

การสร้างหรือขยายแพลตฟอร์มชาร์จ EV ให้รองรับการชาร์จข้ามเครือข่าย ทั้ง CDR, tariff และการเชื่อมต่อหลายพาร์ทเนอร์ คืองานที่บริการ EV CSMS — Charging Station Management System (OCPP/OCPI) ของเราถูกออกแบบมารองรับโดยตรง หากกำลังวางสโคปโครงการ OCPI หรือประเมินว่าจะสร้างเองหรือใช้บริการ ติดต่อเราได้ที่ hello@simplico.net