จาก Zero สู่ OCPP: สร้างแพลตฟอร์มชาร์จ EV แบบ White-Label

  • March 11, 2026
  • tum

บทนำ

ตลาด EV ในประเทศไทยกำลังเติบโตอย่างรวดเร็ว ทั้งจากนโยบาย 30@30 ของภาครัฐที่ต้องการให้ยานยนต์ไฟฟ้าคิดเป็น 30% ของการผลิตภายในปี พ.ศ. 2573 รวมถึงการขยายตัวของผู้ผลิตรถยนต์ไฟฟ้าจากจีนอย่าง BYD, NETA และ MG ที่บุกตลาดไทยอย่างต่อเนื่อง ความต้องการสถานีชาร์จจึงพุ่งสูงขึ้นตามไปด้วย

แต่ชั้นซอฟต์แวร์ที่อยู่เบื้องหลังระบบชาร์จคือจุดที่สร้างความได้เปรียบทางการแข่งขันที่แท้จริง ไม่ว่าคุณจะเป็น startup ด้าน mobility, บริษัทพลังงาน หรือองค์กรที่กำลังพัฒนาระบบชาร์จสำหรับยานพาหนะในองค์กร การสร้างแพลตฟอร์ม OCPP แบบ white-label ของตัวเองจะให้คุณควบคุมระบบได้อย่างสมบูรณ์, รองรับการขยายตัว และเป็นเจ้าของแบรนด์ได้อย่างแท้จริง ซึ่งเป็นสิ่งที่ SaaS สำเร็จรูปทั่วไปไม่สามารถมอบให้ได้

คู่มือนี้จะพาคุณไปทุกขั้นตอน ตั้งแต่ศูนย์จนถึงระบบจัดการสถานีชาร์จ EV แบบ white-label ที่ใช้งานได้จริง — ครอบคลุมพื้นฐานของโปรโตคอล, สถาปัตยกรรมระบบ, การ implement backend, ชั้น branding และแนวทาง go-to-market ในบริบทของตลาดไทย

Related Posts

1. OCPP คืออะไร และทำไมถึงสำคัญ?

OCPP (Open Charge Point Protocol) คือมาตรฐานเปิดที่ใช้กันอย่างแพร่หลายที่สุดสำหรับการสื่อสารระหว่างจุดชาร์จ EV (hardware) กับ Central System (backend ของคุณ) ดูแลโดย Open Charge Alliance (OCA) โดยกำหนดวิธีที่เครื่องชาร์จเชื่อมต่อ, ยืนยันตัวตน, รายงานสถานะ และจัดการธุรกรรม

ในไทย ผู้ผลิตเครื่องชาร์จรายใหญ่อย่าง Delta Electronics (ผลิตในไทย) และแบรนด์นำเข้าจากจีนอย่าง EVlink, Wallbox รวมถึงแบรนด์ยุโรปอย่าง Schneider ล้วนรองรับ OCPP ทั้งสิ้น การออกแบบระบบให้ hardware-agnostic ผ่าน OCPP จึงเป็นกลยุทธ์ที่ถูกต้องตั้งแต่วันแรก

เวอร์ชันหลักที่ควรรู้

  • OCPP 1.6 — เวอร์ชันที่แพร่หลายที่สุดในปัจจุบัน ใช้ SOAP หรือ JSON over WebSocket ยังคงเป็น baseline ของอุตสาหกรรมและรองรับโดย hardware vendor ส่วนใหญ่ในตลาดไทย
  • OCPP 2.0.1 — มาตรฐานรุ่นใหม่ ใช้ JSON-only over WebSocket มี security profile ที่ดีกว่า, smart charging และระบบจัดการอุปกรณ์ที่ครบถ้วน จำเป็นสำหรับการรับรองมาตรฐานใหม่ๆ

ทำไมต้องสร้างแพลตฟอร์มเอง?

แนวทาง การควบคุม ต้นทุนเมื่อขยาย ความเป็นเจ้าของแบรนด์
SaaS สำเร็จรูป ต่ำ สูง ไม่มี
White-label reseller ปานกลาง ปานกลาง บางส่วน
Custom OCPP platform เต็มที่ ต่ำ เต็มที่

หากคุณคาดว่าจะมีจุดชาร์จมากกว่าหลักร้อย หรือต้องการ integrate กับ ecosystem ของผลิตภัณฑ์อย่างลึกซึ้ง การสร้างแพลตฟอร์มเองมักเป็นการลงทุนที่คุ้มค่าที่สุดในระยะยาว โดยเฉพาะในตลาดไทยที่ความต้องการด้าน localization (ภาษาไทย, สกุลเงินบาท, การชำระเงินผ่าน QR Code) เป็นสิ่งที่ SaaS ต่างชาติมักไม่รองรับ

2. ภาพรวมสถาปัตยกรรมระบบ

แพลตฟอร์ม OCPP แบบ white-label ระดับ production ประกอบด้วย 5 ชั้นหลัก:

graph TD
    A["🖥️ White-Label Frontend\nดาชบอร์ดผู้ดำเนินการ / แอปผู้ขับขี่"]
    B["🔀 API Gateway Layer\nREST / GraphQL APIs"]
    C["⚡ OCPP Central System\nWebSocket Server"]
    D["⚙️ Business Logic & Event Bus\nSession · Billing · Notifications"]
    E["🗄️ Data & Infrastructure\nPostgreSQL · Redis · Kafka · S3"]

    A -->|"คำขอจาก Operator / Driver"| B
    B -->|"คำสั่ง OCPP"| C
    C -->|"Event จากเครื่องชาร์จ"| D
    D -->|"Read / Write"| E

    style A fill:#1A6FBF,color:#fff,stroke:#0d4d8a
    style B fill:#2E86C1,color:#fff,stroke:#1a5276
    style C fill:#2874A6,color:#fff,stroke:#1a4f72
    style D fill:#21618C,color:#fff,stroke:#154360
    style E fill:#1B4F72,color:#fff,stroke:#0e2f44

รายละเอียดแต่ละ Component

Component หน้าที่ เทคโนโลยีแนะนำ
OCPP WebSocket Server รับการเชื่อมต่อจากเครื่องชาร์จ Node.js / Python (ocpp lib)
REST API Endpoint สำหรับ operator และ driver FastAPI / Express
Session Manager ติดตาม session การชาร์จที่ active Redis + PostgreSQL
Event Bus ประมวลผล event จากเครื่องชาร์จแบบ async Kafka / RabbitMQ
Billing Engine คำนวณค่าไฟฟ้า, ออกใบแจ้งหนี้ Custom + Omise (สำหรับตลาดไทย)
Notification Service แจ้งเตือนผ่าน Line OA / SMS / Push Line Messaging API / Firebase
Frontend Dashboard UI แบบ white-label สำหรับ operator React / Next.js
Driver Mobile App แอปสำหรับผู้ใช้งาน (optional) React Native / Flutter

หมายเหตุสำหรับตลาดไทย: ควรพิจารณาใช้ Omise หรือ 2C2P แทน Stripe เพื่อรองรับการชำระเงินผ่าน PromptPay QR Code ซึ่งเป็นช่องทางหลักของผู้ใช้ในไทย และผสานการแจ้งเตือนกับ Line OA เนื่องจากคนไทยกว่า 54 ล้านคนใช้งาน Line เป็นประจำ

3. ตั้งค่า OCPP Central System

Central System คือหัวใจของแพลตฟอร์ม — มันรักษา WebSocket connection แบบ persistent กับจุดชาร์จทุกตัว

3.1 เลือก WebSocket Library

สำหรับ Node.js แพ็กเกจ community ocpp เป็นจุดเริ่มต้นที่ดี สำหรับ Python ไลบรารี ocpp ของ mobilityhouse ผ่านการทดสอบใน production และรองรับทั้ง 1.6 และ 2.0.1

# ติดตั้งด้วย pip
pip install ocpp websockets

3.2 Central System พื้นฐานด้วย Python

import asyncio
import websockets
from ocpp.routing import on
from ocpp.v16 import ChargePoint as cp
from ocpp.v16 import call_result
from ocpp.v16.enums import Action, RegistrationStatus

class ChargePoint(cp):

    @on(Action.BootNotification)
    async def on_boot_notification(self, charge_point_vendor, charge_point_model, **kwargs):
        return call_result.BootNotificationPayload(
            current_time=datetime.utcnow().isoformat(),
            interval=10,
            status=RegistrationStatus.accepted
        )

    @on(Action.Heartbeat)
    async def on_heartbeat(self):
        return call_result.HeartbeatPayload(
            current_time=datetime.utcnow().isoformat()
        )

async def on_connect(websocket, path):
    charge_point_id = path.strip("/")
    cp = ChargePoint(charge_point_id, websocket)
    await cp.start()

async def main():
    server = await websockets.serve(
        on_connect,
        "0.0.0.0",
        9000,
        subprotocols=["ocpp1.6"]
    )
    await server.wait_closed()

asyncio.run(main())

3.3 OCPP Messages หลักที่ต้อง implement

Core Profile (จำเป็นต้องมี)

  • BootNotification — เครื่องชาร์จลงทะเบียนกับระบบของคุณ
  • Heartbeat — keepalive ตามช่วงเวลา
  • Authorize — ตรวจสอบ Token/RFID
  • StartTransaction / StopTransaction — วงจรชีวิตของ session
  • MeterValues — รายงานการใช้พลังงาน
  • StatusNotification — การเปลี่ยนแปลงสถานะของเครื่องชาร์จ

Remote Control (จำเป็นสำหรับ operator)

  • RemoteStartTransaction — เริ่ม session จาก dashboard
  • RemoteStopTransaction — หยุด session จากระยะไกล
  • ChangeAvailability — เปิด/ปิดใช้งาน connector
  • Reset — รีบูทเครื่องชาร์จแบบ soft หรือ hard

Smart Charging (OCPP 2.0.1 / ขั้นสูง)

  • SetChargingProfile — กำหนดขีดจำกัดกำลังไฟหรือตารางเวลา
  • GetCompositeSchedule — ดึงข้อมูลตารางที่ active อยู่

4. Multi-Tenancy: แกนหลักของ White-Label

การทำ white-label ต้องการโมเดล multi-tenancy ที่แข็งแกร่ง ผู้ดำเนินการ (tenant) แต่ละรายควรมี:

  • Domain ที่มีแบรนด์ของตัวเอง (เช่น app.pea-volt.co.th)
  • ข้อมูลที่แยกจากกัน (จุดชาร์จ, session, ผู้ใช้)
  • การ branding แบบกำหนดเอง (โลโก้, สี, ชื่อแอป)
  • รูปแบบการกำหนดราคาที่ปรับได้

4.1 Tenant Data Model

-- Tenants (ผู้ดำเนินการ)
CREATE TABLE tenants (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    slug        TEXT UNIQUE NOT NULL,       -- เช่น "pea-ev", "ea-anywhere"
    name        TEXT NOT NULL,
    domain      TEXT,                       -- custom domain
    logo_url    TEXT,
    theme       JSONB,                      -- { primary_color, font, etc. }
    locale      TEXT DEFAULT 'th',          -- ภาษาหลัก
    currency    TEXT DEFAULT 'THB',         -- สกุลเงิน
    created_at  TIMESTAMPTZ DEFAULT NOW()
);

-- จุดชาร์จเป็นของ tenant
CREATE TABLE charge_points (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id   UUID REFERENCES tenants(id),
    ocpp_id     TEXT UNIQUE NOT NULL,       -- ID ที่ใช้ใน WebSocket path
    name        TEXT,
    location    JSONB,
    status      TEXT DEFAULT 'Unknown',
    created_at  TIMESTAMPTZ DEFAULT NOW()
);

4.2 Routing การเชื่อมต่อตาม Tenant

เมื่อเครื่องชาร์จเชื่อมต่อผ่าน WebSocket ให้ดึง OCPP ID จาก path และค้นหาว่าเป็นของ tenant ใด:

async def on_connect(websocket, path):
    ocpp_id = path.strip("/")

    # ค้นหา tenant จาก charge point registry
    tenant = await db.get_tenant_by_ocpp_id(ocpp_id)
    if not tenant:
        await websocket.close(code=1008, reason="Unknown charge point")
        return

    cp = TenantAwareChargePoint(ocpp_id, websocket, tenant)
    await cp.start()

5. การจัดการ Session และระบบ Billing

5.1 วงจรชีวิตของ Session

sequenceDiagram
    participant CP as เครื่องชาร์จ
    participant CS as Central System
    participant DB as ฐานข้อมูล
    participant BE as Billing Engine

    CP->>CS: Authorize(idTag)
    CS->>DB: ตรวจสอบ token
    DB-->>CS: Accepted
    CS-->>CP: AuthorizeResponse(Accepted)

    CP->>CS: StartTransaction(connectorId, idTag, meterStart)
    CS->>DB: เปิด session record
    CS-->>CP: StartTransactionResponse(transactionId)

    loop ทุก 60 วินาที
        CP->>CS: MeterValues(transactionId, energy)
        CS->>DB: บันทึกค่ามิเตอร์
    end

    CP->>CS: StopTransaction(transactionId, meterStop, reason)
    CS->>DB: ปิด session
    CS->>BE: คำนวณค่าใช้จ่าย
    BE-->>CS: สร้างใบแจ้งหนี้แล้ว
    CS-->>CP: StopTransactionResponse

5.2 บันทึก Meter Values

@on(Action.MeterValues)
async def on_meter_values(self, connector_id, meter_value, **kwargs):
    for reading in meter_value:
        for sampled in reading.get("sampledValue", []):
            await db.insert_meter_reading({
                "session_id": self.active_session_id,
                "timestamp": reading["timestamp"],
                "measurand": sampled.get("measurand", "Energy.Active.Import.Register"),
                "value": float(sampled["value"]),
                "unit": sampled.get("unit", "Wh")
            })

5.3 รูปแบบการกำหนดราคาที่ควรรองรับ

  • ต่อ kWh — พบบ่อยที่สุด คิดตามพลังงานที่จ่ายจริง
  • ต่อนาที — เหมาะสำหรับการจัดการที่จอดรถ
  • ราคาเหมา/ครั้ง — ราคาคงที่ต่อการชาร์จหนึ่งครั้ง
  • แบบผสม — เช่น ฿5/kWh + ฿2/นาทีหลังจาก 60 นาที
  • สมาชิกรายเดือน — ยอดนิยมในโมเดลธุรกิจแบบ subscription ที่กำลังเติบโตในไทย

เก็บการกำหนดราคาเป็น JSONB config ต่อ tenant หรือต่อจุดชาร์จเพื่อความยืดหยุ่นสูงสุด

6. ความปลอดภัยและการยืนยันตัวตน

6.1 การยืนยันตัวตนของจุดชาร์จ

OCPP 1.6 รองรับ Basic Auth ผ่าน WebSocket URL:

ws://username:password@yourplatform.com/ocpp/CP001

สำหรับ OCPP 2.0.1 ใช้ Security Profile 3 พร้อม TLS client certificates สำหรับ production deployment

6.2 Auth & RBAC Flow

flowchart LR
    CP["⚡ จุดชาร์จ"] -->|"WSS + Basic Auth\nOCPP 1.6"| WS["WebSocket Server"]
    CP2["⚡ จุดชาร์จ"] -->|"WSS + TLS Cert\nOCPP 2.0.1"| WS
    OP["👤 แอปผู้ดำเนินการ"] -->|"HTTPS + JWT"| API["REST API"]
    API -->|"ตรวจสอบ RBAC\nAdmin / Operator / Viewer"| BL["Business Logic"]
    WS -->|"Forward events"| BL

    style CP fill:#27AE60,color:#fff,stroke:#1e8449
    style CP2 fill:#27AE60,color:#fff,stroke:#1e8449
    style OP fill:#8E44AD,color:#fff,stroke:#6c3483
    style WS fill:#1A6FBF,color:#fff,stroke:#0d4d8a
    style API fill:#1A6FBF,color:#fff,stroke:#0d4d8a
    style BL fill:#1B4F72,color:#fff,stroke:#0e2f44
  • ใช้ JWT tokens ที่มี tenant-scoped claims สำหรับ operator API
  • implement RBAC (Admin, Operator, Viewer roles) ต่อ tenant
  • Rate-limit endpoint ที่เปิดสาธารณะทั้งหมด
  • บันทึก audit log สำหรับทุก remote command ที่ส่งไปยังเครื่องชาร์จ

7. สร้าง White-Label Frontend

ดาชบอร์ดของ operator คือสิ่งที่ลูกค้าของคุณมองเห็นทุกวัน ต้องรวดเร็ว, rebrand ได้ และใช้งานได้จริง

7.1 ฟีเจอร์หลักของ Dashboard

  • แผนที่แบบ live — สถานะเครื่องชาร์จแบบ real-time บนแผนที่ (ควรรองรับ Longdo Map หรือ Google Maps สำหรับตลาดไทย)
  • ติดตาม session — session ที่กำลัง active พร้อมพลังงานและระยะเวลา
  • จัดการจุดชาร์จ — เพิ่ม, ตั้งค่า, เปิด/ปิดเครื่องชาร์จ
  • จัดการผู้ใช้ — บัตร RFID, บัญชีผู้ขับขี่, การควบคุมการเข้าถึง
  • Analytics — รายได้, การใช้งาน, พลังงานที่จ่ายตามช่วงเวลา
  • ตั้งค่าราคา — กำหนดราคาต่อสถานที่หรือต่อ connector
  • Remote actions — เริ่ม/หยุด session, รีบูทเครื่องชาร์จ

7.2 ระบบ Theming

ใช้ CSS variables + tenant config endpoint เพื่อให้การเปลี่ยน theme เป็นเรื่องง่าย:

// โหลด tenant theme เมื่อแอปเริ่มต้น
const { data: tenant } = await api.get('/api/v1/tenant/config');

document.documentElement.style.setProperty('--color-primary', tenant.theme.primary_color);
document.documentElement.style.setProperty('--color-secondary', tenant.theme.secondary_color);
document.title = tenant.name;

7.3 ตัวเลือก Deployment แบบ White-Label

ตัวเลือก ความซับซ้อน การแยกข้อมูล
Subdomain ต่อ tenant (tenant.yourplatform.com) ต่ำ Infrastructure ร่วม
Custom domain พร้อม SSL (app.pea-ev.co.th) ปานกลาง Infrastructure ร่วม
Deployment แยกต่อ tenant สูง แยกสมบูรณ์

สำหรับ use case ส่วนใหญ่ในไทย เริ่มด้วย subdomain routing แล้วค่อยเพิ่ม custom domain support ผ่าน Nginx + Let’s Encrypt อัตโนมัติเมื่อฐานลูกค้าขยายใหญ่ขึ้น

8. โครงสร้างพื้นฐานและการ Scale

8.1 สถาปัตยกรรมเริ่มต้น (0–500 จุดชาร์จ)

graph LR
    CH["⚡ จุดชาร์จ"] -->|"WebSocket"| WS["WebSocket Server\n1 node"]
    OP["👤 Operators"] -->|"HTTPS"| API["REST API\n1-2 nodes"]

    WS -->|"Read / Write"| PG[("PostgreSQL")]
    WS -->|"Session cache"| RD[("Redis\nSession Cache")]
    API -->|"Read / Write"| PG
    API -->|"Store logs"| S3[("S3\nLogs / Reports")]

    style CH fill:#27AE60,color:#fff,stroke:#1e8449
    style OP fill:#8E44AD,color:#fff,stroke:#6c3483
    style WS fill:#1A6FBF,color:#fff,stroke:#0d4d8a
    style API fill:#1A6FBF,color:#fff,stroke:#0d4d8a
    style PG fill:#1B4F72,color:#fff,stroke:#0e2f44
    style RD fill:#C0392B,color:#fff,stroke:#922b21
    style S3 fill:#D68910,color:#fff,stroke:#9a6709

8.2 Scale ไปยัง 10,000+ จุดชาร์จ

ที่ scale ใหญ่ขึ้น WebSocket layer จะกลายเป็น bottleneck เครื่องชาร์จแต่ละตัวรักษา connection แบบ persistent ดังนั้นคุณต้องการ:

  • Horizontal scaling ของ WebSocket server พร้อม shared session store (Redis)
  • Message broker (Kafka หรือ RabbitMQ) เพื่อกระจาย event ไปยัง downstream services
  • Connection routing เพื่อให้ remote command ไปถึง node ที่ถือ socket ของเครื่องชาร์จนั้น
graph TD
    CH["⚡ จุดชาร์จ"] -->|"WebSocket"| LB["Load Balancer"]
    LB -->|"Sticky session"| WS1["WS Node 1"]
    LB -->|"Sticky session"| WS2["WS Node 2"]
    LB -->|"Sticky session"| WS3["WS Node N"]

    WS1 & WS2 & WS3 -->|"Publish events"| KF[["Kafka\ncharger.events"]]
    WS1 & WS2 & WS3 -->|"Register socket"| RD[("Redis\nConnection Registry")]

    KF -->|"session.started/stopped"| SS["Session Service"]
    KF -->|"meter.values"| BS["Billing Service"]
    KF -->|"status.changed"| NS["Notification Service"]

    SS & BS & NS -->|"Persist"| PG[("PostgreSQL")]

    style CH fill:#27AE60,color:#fff,stroke:#1e8449
    style LB fill:#566573,color:#fff,stroke:#2c3e50
    style WS1 fill:#1A6FBF,color:#fff,stroke:#0d4d8a
    style WS2 fill:#1A6FBF,color:#fff,stroke:#0d4d8a
    style WS3 fill:#1A6FBF,color:#fff,stroke:#0d4d8a
    style KF fill:#E67E22,color:#fff,stroke:#ca6f1e
    style RD fill:#C0392B,color:#fff,stroke:#922b21
    style SS fill:#21618C,color:#fff,stroke:#154360
    style BS fill:#21618C,color:#fff,stroke:#154360
    style NS fill:#21618C,color:#fff,stroke:#154360
    style PG fill:#1B4F72,color:#fff,stroke:#0e2f44

8.3 Checklist ด้าน Observability

  • Prometheus metrics สำหรับ WebSocket connections, message latency และ error rates
  • Structured JSON logging ต่อ charger/tenant
  • แจ้งเตือนเมื่อเครื่องชาร์จหลุด connection จำนวนมาก
  • Grafana dashboard สำหรับ real-time charger health

9. OCPI Integration สำหรับ Roaming

เมื่อแพลตฟอร์มพร้อมใช้งานแล้ว ผู้ดำเนินการจะต้องการ roaming — ให้ผู้ขับขี่จากเครือข่ายอื่นชาร์จที่สถานีของตนได้ ซึ่งจัดการผ่าน OCPI (Open Charge Point Interface)

ในประเทศไทย การเชื่อมต่อกับ aggregator อย่าง PlugShare และการแลกเปลี่ยนข้อมูลกับผู้ให้บริการ EV รายอื่นในอาเซียนกำลังเป็นที่ต้องการมากขึ้น โดยเฉพาะสำหรับผู้ดำเนินการที่ต้องการรองรับนักท่องเที่ยวต่างชาติ

flowchart LR
    DR["🚗 ผู้ขับขี่\nจากเครือข่ายอื่น"] -->|"Auth Token"| EM["eMSP\nผู้ให้บริการ Mobility"]
    EM -->|"OCPI 2.2.1"| HUB["OCPI Hub /\nAggregator"]
    HUB -->|"CDRs / Locations / Tariffs"| YOUR["แพลตฟอร์มของคุณ\nบทบาท CPO"]
    YOUR -->|"OCPP"| CP["⚡ จุดชาร์จ"]

    style DR fill:#27AE60,color:#fff,stroke:#1e8449
    style EM fill:#8E44AD,color:#fff,stroke:#6c3483
    style HUB fill:#E67E22,color:#fff,stroke:#ca6f1e
    style YOUR fill:#1A6FBF,color:#fff,stroke:#0d4d8a
    style CP fill:#1B4F72,color:#fff,stroke:#0e2f44

OCPI ช่วยให้แพลตฟอร์มของคุณ:

  • แสดงสถานที่และอัตราค่าบริการบน aggregator สาธารณะ (PlugShare, ABRP)
  • รับการชำระเงินจากผู้ขับขี่ที่ใช้เครือข่ายอื่น
  • แชร์ข้อมูลความพร้อมใช้งานแบบ real-time กับแอปนำทาง

การ implement OCPI 2.2.1 ในบทบาท CPO (Charge Point Operator) เป็นจุดเริ่มต้นที่พบบ่อยที่สุด

10. แนวทาง Go-to-Market สำหรับตลาดไทย

การวางตำแหน่งแพลตฟอร์ม White-Label ของคุณ

  • Hardware-agnostic — รองรับเครื่องชาร์จที่เป็นไปตาม OCPP ทุกยี่ห้อ (นี่คือจุดขายที่แข็งแกร่งที่สุด โดยเฉพาะเมื่อ hardware จากจีนราคาถูกกำลังทะลักเข้าตลาดไทย)
  • Localized UX — ภาษาไทยเป็นภาษาหลัก, สกุลเงินบาท, รองรับ PromptPay และ QR Code
  • Line OA Integration — การแจ้งเตือนผ่าน Line เป็นสิ่งที่ลูกค้าไทยคาดหวัง
  • Self-serve onboarding — ให้ผู้ดำเนินการเพิ่มจุดชาร์จได้โดยไม่ต้องโทรหา support
  • Compliance-ready — การรับรอง OCPP จาก OCA เพิ่มความน่าเชื่อถือในตลาด

รูปแบบราคาสำหรับแพลตฟอร์มของคุณ

  • ต่อจุดชาร์จต่อเดือน (คาดเดาได้มากที่สุด)
  • แบ่งรายได้จากค่า session (จูงใจทั้งสองฝ่าย)
  • ค่าติดตั้งครั้งเดียว + ค่าลิขสิทธิ์รายปี (สำหรับ enterprise)

Roadmap การเปิดตัว

gantt
    title แผนการเปิดตัวแพลตฟอร์ม
    dateFormat  YYYY-MM-DD
    section Phase 1 - Core
    OCPP 1.6 Central System     :p1, 2024-01-01, 30d
    การจัดการ session พื้นฐาน  :p2, after p1, 20d
    Operator dashboard v1       :p3, after p1, 30d
    section Phase 2 - Business
    Multi-tenancy และ billing   :p4, after p2, 30d
    White-label theming         :p5, after p3, 20d
    RFID และการยืนยันตัวตน     :p6, after p4, 15d
    section Phase 3 - Scale
    Smart charging OCPP 2.0.1   :p7, after p6, 30d
    OCPI roaming integration    :p8, after p6, 30d
    Kafka horizontal scaling    :p9, after p7, 20d
    section Phase 4 - Growth
    แอปมือถือสำหรับผู้ขับขี่   :p10, after p8, 45d
    Analytics และรายงาน         :p11, after p9, 20d

ลูกค้ากลุ่มแรกในตลาดไทย

  • นิคมอุตสาหกรรมและ logistics — WHA, Amata, Rojana มีความต้องการสูงสำหรับระบบชาร์จยานพาหนะในองค์กร
  • Developer อสังหาริมทรัพย์ — คอนโดมิเนียมและอาคารสำนักงานในกรุงเทพฯ บังคับโดย EV Readiness standard ที่กำลังจะมา
  • โรงแรมและรีสอร์ท — กลุ่ม hospitality ต้องการ white-label dashboard ที่มีโลโก้ของตัวเอง
  • ผู้ให้บริการ fleet — บริษัทเช่ารถ, ขนส่ง และ Grab/Bolt ที่กำลัง electrify ยานพาหนะ
  • การไฟฟ้าและ PTT — เป็น partner ที่มีศักยภาพสูงในฐานะ infrastructure owner

สรุป

การสร้างแพลตฟอร์ม OCPP แบบ white-label เป็นงาน engineering ที่ต้องลงทุนพอสมควร แต่ก็เป็น competitive moat ที่แข็งแกร่งมากเมื่อระบบพร้อมใช้งาน milestone หลักคือ:

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

  1. สร้าง OCPP 1.6 Central System ที่ทำงานได้ พร้อม BootNotification, Authorize และ transaction handling
  2. เพิ่ม multi-tenancy ที่ชั้นข้อมูลและ routing ตั้งแต่แรก — การย้อนกลับมาทำทีหลังทำให้ระบบยุ่งยากมาก
  3. สร้าง operator dashboard พร้อม live status, remote actions และ analytics พื้นฐาน
  4. เพิ่ม billing, smart charging และ OCPI เมื่อแพลตฟอร์มเติบโตขึ้น
  5. ลงทุนด้าน observability — ผู้ดำเนินการในไทยจะโทรหาคุณทันทีเมื่อเครื่องชาร์จออฟไลน์

ตลาดซอฟต์แวร์สถานีชาร์จ EV ในไทยยังอยู่ในช่วงเริ่มต้น ทีมที่ ship ได้เร็ว, รองรับ hardware ได้หลากหลาย และเป็นเจ้าของความสัมพันธ์กับลูกค้าผ่าน white-labeling จะอยู่ในตำแหน่งที่แข็งแกร่งเมื่อตลาดเติบโตเต็มที่ตามนโยบาย 30@30

สร้างด้วย OCPP 1.6 / 2.0.1 · Open Charge Alliance · Python · Node.js · PostgreSQL · Redis · Omise · Line Messaging API

Get in Touch with us

Email to Us

hello@simplico.net
LINE QR
Chat with Us on LINE

iiitum1984

Speak to Us or Whatsapp

(+66) 83001 0222

Related Posts

Our Products

Simplify Gym Management with SimpliGym
SimpliShop, All-in-One E-Commerce Platform with AI-Driven Features
รับออกแบบและพัฒนา Responsive Website / Web application
สอนพัฒนา website ด้วย Wordpress 5
สอนเขียน Ionic Framework: Cross-Platform Mobile App Development
สอนเขียน Python / Django Web Framework
SimpliLearn ระบบเรียน online ที่มาพร้อมกับ AI
SimpliRun, แอปสำหรับ virtual run และขายของ online
Mobile application สำหรับธุรกิจกีฬาที่ครบวงจร
ระบบแนะนำสินค้าสำหรับขายของ Online
simpliRec , ระบบแนะนำหนังสือที่ชาญฉลาด
Integrated Measurement Communication System ( IMCS )
SimpliFactory ชุดเทคโนโลยีสำหรับโรงงานอุตสาหกรรม , Software/Hardware