เราจะเขียน OCPP server อย่างไร
ตอนนี้กระแส EV กำลังมา เวลาเราไปตามปั๊มน้ำมันเราก็จะเห็นจุด charge ev กันใช่ไหมครับ เราเคยสงสัยไหมว่า จุด charge ติดต่อกับ server และ mobile app ของเราอย่างไร เค้าสื่อสารผ่าน OCPP protocol กัน เราลองมาทำความเข้าใจกันดีกว่า
บทความที่เกี่ยวข้อง
- ⚡ สร้างระบบ EV Charging ที่ขยายได้ สำหรับผู้ให้บริการ นักพัฒนา และนวัตกร
- 📱 ข้อเสนอระบบ OCPP สำหรับเชื่อมต่อแอป EV กับระบบศูนย์กลาง (Customer Proposal)
- 🔌 เชื่อมต่อแอปมือถือกับระบบ OCPP ด้วย FastAPI
- 🔐 วิธีเชื่อมต่อระบบยืนยันตัวตนของแอป EV เข้ากับระบบ OCPP Central
- 📊 คู่มือเริ่มต้น: แอป EV สื่อสารอย่างไร ติดตามการชาร์จ และคำนวณค่าใช้จ่ายอย่างไร
- 🧠 พัฒนาระบบ OCPP 1.6 ด้วย Flask, WebSocket แบบ Async และ MongoDB
- 🛠️ สร้างระบบ OCPP ตั้งแต่ศูนย์ – คู่มือฉบับสมบูรณ์
OCPP ( Open Charge Point Protocol ) คือมาตรฐานการสื่อสารระหว่าง OCPP client ( charger station ) และ OCPP server ( server ที่มีหน้าที่จัดการและรับส่งข้อมูลระหว่าง OCPP client ) สำหรับคนที่ยังไม่เคยชินกับ server – client architecture จะอธิบายให้เข้าใจง่ายๆ คือ ในระบบจะแบ่งกลุ่มของหน้าที่การทำงานในระบบออกเป็น สองกลุ่ม 1. Client คือกลุ่มของผู้รับบริการจาก server 2. Server คือกลุ่มของผู้ให้บริการในระบบ

กลับมาที่ OCPP server-client ที่เรากำลังสนใจอยู่

OCPP client จะอยู่ใน Charging point โดยผ่าน OCPP protocol ( ตอนนี้ 1.6 และ 2.0.1 )
คนที่เขียน program พอจะนึกภาพออกว่า ถ้าเราจะทำให้การสื่อสารระหว่าง client – server ให้ใกล้เคียงกับ realtime เราจะต้องใช้ web socket https://simplico.net/2022/04/30/web-socket-%E0%B8%84%E0%B8%B7%E0%B8%AD%E0%B8%AD%E0%B8%B0%E0%B9%84%E0%B8%A3/
ให้คิดง่ายๆว่า เราเขียน web socket server – client ที่มี flow การทำงาน และ message ที่แลกเปลี่ยนกันระหว่าง server – client ให้เป็นไปตาม OCPP protocol แล้วเราจะรู้ได้อย่างไรว่าจะต้องเขียนอะไรบ้าง เราก็ไปดูที่
https://openchargealliance.org/my-oca/ocpp/ เราก็เลือก version ที่เราต้องการจะเขียน
ผมขอยกตัวอย่าง sequence diagram ใน pdf นะครับ

Charge Point คือฝั่ง client และ Central System คือฝั่งของ server
Charge Point ส่ง Authorize request มา โดยใน diagram นี้อ้างอิง message ที่ส่งมาใน request คือ idTag ( id ของ Charge point ในระบบของเรา ที่จะต้องไม่ซ้ำกับเครื่องไหนเลย ) พอ central system รับ request ก็จะทำ process หลังบ้านอะไรก็ตาม ( ตรงนี้ขึ้นอยู่กับว่าเราจะเขียนอย่างไร ต้องเข้าใจว่า protocol คือการกำหนดข้อตกลงการสื่อสาร แต่ไม่ได้ระบุว่าระบบที่เราบอกว่ารองรับ protocol นั้นๆ จะมีรายละเอียดการทำงานด้านหลังการสื่อสารนั้นๆ อย่างไร
จาก digram , central system ก็จะส่ง Authorize.conf กลับไปให้ client พร้อมกับ idTagInfo แล้ว idTagInfo เราก็ต้องไปค้นหาดูใน pdf เราก็จะพบว่า

มี data field แบบนี้ สำหรับคนเขียน python ก็ให้คิดว่าเป็น dictionary datatype เราจะสนใจ field ที่ required กันก่อนนะครับ ในที่นี้คือ status เราก็ต้องดูว่าต่อว่า AuthorizationStatus มีค่าอะไรบ้าง

เริ่มพอเห็นแสงสว่างกันแล้วใช่ไหมครับ ในส่วนนี้เราก็ลองคิดง่ายๆ ว่าเราจะ implement เป็น code อย่างไรดี
ผมว่า Accepted, Blocked, … พวกนี้เราก็เขียนเป็น enum ดีกว่า
ผมใช้ project นี้ตั้งต้น https://github.com/mobilityhouse/ocpp เราลองมาดู schema ของ project นี้ดีกว่าว่าเค้าเขียน idTagInfo และ authorizationStatus อย่างไร


พอเราเริ่มเห็น message schema แล้ว ขั้นต่อไปเราจะเขียน logic code อย่างไร

Code ด้านบนเป็น code ที่ผมลองเขียนเอง ลองไปศึกษา https://openchargealliance.org/my-oca/ocpp/ แต่ code ที่สำคัญคือพวก @on(ActionName) decorator ครับ จากในภาพเช่น @on(Action.Authorize) เราก็เขียน function ที่อย่างน้อยต้อง return idTagInfo พร้อมกับ authorize status ในที่นี้ผมใช้ accepted
ถ้าเราเขียนระบบจริงๆ code ส่วนนี้เราควรจะต้องทำอะไรล่ะ อย่างแรกเลยต้องตรวจว่า id_tag นี้อยู่ในระบบของเราหรือไม่ ถ้าใช่ก็ return status = accepted ไปครับ
วันนี้ผมจะพอแค่นี้ก่อนแล้วกันครับ ผมใช้อะไรในการ simulate charging point ครับ ผมใช้ตัวนี้ครับ
https://github.com/vasyas/charger-simulator ลองไปเล่นกันดูนะครับ
Get in Touch with us
Related Posts
- AI会在2026年取代软件开发公司吗?企业管理层必须知道的真相
- Will AI Replace Software Development Agencies in 2026? The Brutal Truth for Enterprise Leaders
- 使用开源 + AI 构建企业级系统(2026 实战指南)
- How to Build an Enterprise System Using Open-Source + AI (2026 Practical Guide)
- AI赋能的软件开发 —— 为业务而生,而不仅仅是写代码
- AI-Powered Software Development — Built for Business, Not Just Code
- Agentic Commerce:自主化采购系统的未来(2026 年完整指南)
- Agentic Commerce: The Future of Autonomous Buying Systems (Complete 2026 Guide)
- 如何在现代 SOC 中构建 Automated Decision Logic(基于 Shuffle + SOC Integrator)
- How to Build Automated Decision Logic in a Modern SOC (Using Shuffle + SOC Integrator)
- 为什么我们选择设计 SOC Integrator,而不是直接进行 Tool-to-Tool 集成
- Why We Designed a SOC Integrator Instead of Direct Tool-to-Tool Connections
- 基于 OCPP 1.6 的 EV 充电平台构建 面向仪表盘、API 与真实充电桩的实战演示指南
- Building an OCPP 1.6 Charging Platform A Practical Demo Guide for API, Dashboard, and Real EV Stations
- 软件开发技能的演进(2026)
- Skill Evolution in Software Development (2026)
- Retro Tech Revival:从经典思想到可落地的产品创意
- Retro Tech Revival: From Nostalgia to Real Product Ideas
- SmartFarm Lite — 简单易用的离线农场记录应用
- OffGridOps — 面向真实现场的离线作业管理应用













