0. 문서 개요

• 표준 OCPP 2.0.1 메시지(payload 필드·enum·제약)는 OCA OCPP 2.0.1 규격(Part 2 / Part 4)을 그대로 따르므로 본 문서에서는 지원 여부만 목록화합니다(2장).
• 2.0.1에는 자사 벤더 확장(DataTransfer)이 없습니다. 그 대신 표준 메시지에 대해 CSMS가 어떻게 판정·응답하는지(처리 규칙)를 상세히 기술합니다(4장). 충전기 구현은 이 처리 규칙을 전제로 해야 합니다.

대상 독자: 충전기 펌웨어/연동 개발자  |  전제 지식: OCPP 2.0.1 규격(Part 2 메시지, Part 4 JSON/WebSocket, Security), WebSocket, JSON, TLS

0.1 OCPP 1.6 대비 용어·구조 변화

1. 연결 개요

충전기는 OCPP 2.0.1 JSON(OCPP-J) 프로토콜로 CSMS에 WebSocket 연결합니다. 연결 시 반드시 아래 규격을 따라야 합니다.

1.1 환경별 엔드포인트

1.2 연결 수립 순서

1. 충전기가 wss://<host>/ocpp2/<id>로 WebSocket 핸드셰이크 — subprotocol ocpp2.0.1 + 보안 프로파일에 따른 인증 재료(Basic Auth 헤더 또는 클라이언트 인증서).
2. CSMS가 핸드셰이크 단계에서 식별자 등록 여부·보안 프로파일·자격증명을 검증합니다 (실패 시 HTTP 400/401/403으로 업그레이드 거부).
3. 연결 직후 충전기가 BootNotification 전송 → CSMS가 Accepted / Pending / Rejected + interval 응답(4.1).
4. Accepted 이후 충전기는 interval 주기로 Heartbeat, EVSE·커넥터 상태는 StatusNotification(evseId, connectorId)로 통지합니다.

1.3 보안 프로파일 (Security Profile)

CSMS는 접속의 전송 계층을 실측해 제시된 프로파일을 판정하고, 충전기 등록 정보(보안 프로파일 1/2/3, 기본 2 · Basic Auth 모드 기본/사용/미사용)와 대조합니다. 등록 값은 운영팀이 전달합니다.

핸드셰이크 판정 규칙

서버 인증서 · 비밀번호 · 프로파일 승격

• 서버 인증서: RSA + ECDSA(P-256) 듀얼 인증서, 발급자는 공인 CA가 아닌 사설 CSMS-CA입니다. 서버 인증서 검증을 켜는 충전기는 CSMS-CA 루트 인증서를 사전 설치해야 합니다(운영팀 제공). TLS 1.2 이상, cipher는 TLS 1.3 3종 + ECDHE(RSA/ECDSA) GCM + TLS_RSA_WITH_AES_*(OCPP SP2/3 요구)를 지원합니다.
• 비밀번호 변경: CSMS는 SetVariables(SecurityCtrlr.BasicAuthPassword)로 Basic Auth 비밀번호를 갱신합니다. 충전기가 Accepted로 응답하면 CSMS도 새 비밀번호로 전환하고, Rejected면 기존 비밀번호를 유지합니다.
• 프로파일 승격: CSMS는 SetNetworkProfile로 새 접속 프로파일을 내려보낼 수 있습니다(SP1→2, SP2→3). 충전기는 규격에 따라 재접속합니다.

1.4 메시지 프레임 (OCPP-J) 과 오류 응답

모든 메시지는 JSON 배열입니다.

CALL       [2, "<messageId>", "<Action>", {<payload>}]
CALLRESULT [3, "<messageId>", {<payload>}]
CALLERROR  [4, "<messageId>", "<errorCode>", "<description>", {<details>}]

• CSMS는 관용 파싱을 합니다 — 규격이 허용하는 customData 등 확장 필드가 포함되어도 거부하지 않습니다.
• CSMS가 보내는 CALLERROR의 errorCode는 OCPP 2.0.1 Part 4 정의를 따릅니다:

예시 — Heartbeat

→ [2, "msg-001", "Heartbeat", {}]
← [3, "msg-001", {"currentTime": "2026-09-18T09:00:00Z"}]

2. 표준 OCPP 2.0.1 메시지 지원 목록

아래 메시지의 payload 필드·enum·제약 조건은 OCPP 2.0.1 규격서를 그대로 따릅니다. 충전기는 규격서 기준으로 구현하면 되며, CSMS 고유의 판정·응답 규칙은 4장을 참조합니다.

2.1 Charging Station → CSMS (충전기가 전송)

2.2 CSMS → Charging Station (CSMS가 전송, 충전기가 처리)

2.3 기능 블록별 요약

3. 프로토콜 프로파일과 DataTransfer

• 1.6의 자사 확장(Bionever SetPaymentInfo·GetUnitPrices·SetChargePreference, AMANO, K-VAS 배터리 데이터, ChangeConfiguration 커스텀 키)은 2.0.1에 제공되지 않습니다. 해당 기능이 필요한 사업은 운영팀과 별도 협의합니다.
• 1.6의 DataTransfer 래핑 PnC(org.openchargealliance.iso15118pnc)도 2.0.1에서는 사용하지 않습니다 — 네이티브 Action(Authorize의 인증서 필드, Get15118EVCertificate, GetCertificateStatus, 인증서 관리 4종)을 사용합니다(4.8).
• CSMS → CS DataTransfer는 운영 진단 목적으로 발신될 수 있습니다. 충전기는 표준대로 UnknownVendorId / UnknownMessageId를 응답하면 됩니다.

4. CSMS 처리 규칙 (2.0.1 고유)

표준 메시지에 대해 CSMS가 어떻게 판정하고 무엇을 응답하는지 정리합니다. 충전기 펌웨어는 아래 규칙을 전제로 상태 전이·화면 처리를 구현해야 합니다.

4.1 BootNotification 판정과 부팅 게이트

→ [2, "b-01", "BootNotification", {"chargingStation": {"model": "EVC-200", "vendorName": "ACME"}, "reason": "PowerUp"}]
← [3, "b-01", {"currentTime": "2026-09-18T09:00:00Z", "interval": 300, "status": "Pending"}]
→ [2, "h-01", "Heartbeat", {}]
← [4, "h-01", "SecurityError", "BootNotification status is Pending", {}]

• CSMS는 chargingStation.model / vendorName / reason을 기록하고 온라인 상태를 갱신합니다.
• 부팅 게이트: Pending / Rejected 응답 이후 같은 접속에서 BootNotification 외의 CALL이 오면 위 예시처럼 SecurityError로 거부합니다. 게이트는 접속 단위이며 소켓이 끊기면 해제됩니다.
• Pending은 운영자가 부팅 전 설정(GetVariables/SetVariables/GetBaseReport 등)을 마치는 용도입니다. 충전기는 Pending 중에도 CSMS 발신 명령에 응답해야 하며, interval 경과 후 또는 TriggerMessage(BootNotification) 수신 시 BootNotification을 재전송합니다.

4.2 Authorize — idToken 판정

Authorize.req의 idToken.type에 따라 CSMS 판정 경로가 다릅니다.

응답 예시 — 그룹 카드

{
  "idTokenInfo": {
    "status": "Accepted",
    "groupIdToken": { "idToken": "GROUP-A", "type": "Central" }
  }
}

• groupIdToken: 카드에 그룹(1.6의 parentIdTag)이 설정되어 있으면 위처럼 type = "Central"로 반환합니다. 마스터패스·그룹 인가(같은 그룹 카드로 종료)에 사용됩니다.
• Authorize 판정에는 예약 여부를 포함하지 않습니다(예약 매칭은 충전기 로컬 규칙 + TransactionEvent.reservationId).

4.3 TransactionEvent 처리

거래 ID(transactionInfo.transactionId)는 충전기가 생성한 UUID 문자열이며 CSMS는 이 값으로 거래를 식별합니다. evse.id / evse.connectorId로 EVSE·커넥터를 식별합니다.

4.3.1 Started — 거래 시작

• idToken을 4.2 규칙으로 판정합니다. 비회원 선결제 토큰은 1회용이라 재사용 시 Invalid입니다.
• 판정이 Accepted가 아니면 거래를 생성하지 않습니다. 응답의 idTokenInfo.status가 Invalid면 충전기는 규격대로 충전을 중단해야 합니다.
• transactionInfo.remoteStartId가 있으면 원격 시작 거래로 기록합니다. 동봉된 meterValue는 저장합니다.

4.3.2 Updated — 진행 중

• meterValue를 저장하고, 응답에 진행 중 요금 totalCost를 싣습니다(조회 시점 계산).
• idToken이 실려 오면 재인가로 보고 엄격 판정해 idTokenInfo를 응답합니다.
• seqNo가 중복이면 무시(응답은 정상), 건너뛰면 유실 경고 후 반영합니다. 이미 종료된 거래의 Updated도 무시하고 정상 응답합니다.

4.3.3 Ended — 거래 종료

• 거래를 종료하고 요금을 확정합니다(transactionInfo.stoppedReason 기록). 응답 totalCost는 확정 요금입니다.
• 멱등입니다 — 중복 Ended도 정상 응답하며 확정 요금을 다시 싣습니다. 존재하지 않는 거래의 Ended에도 idToken 판정은 응답합니다.

응답 예시 — Updated

← [3, "t-12", {
  "totalCost": 4200.0,
  "idTokenInfo": { "status": "Accepted" }
}]

4.4 StatusNotification — EVSE·커넥터 상태

• evseId가 CSMS 커넥터 행에 대응합니다(어드민 표기 "EVSE"). evseId = 0은 충전기 전체 상태로 취급하며 커넥터 행을 만들지 않습니다.
• 커넥터 가용 상태 복귀는 충전기의 StatusNotification(Available)로만 반영됩니다 — 거래 종료가 상태를 선반영하지 않습니다.

4.5 MeterValues (거래 외 검침)

TriggerMessage(MeterValues) 등으로 전송되는 거래 외 MeterValues는 정상 응답만 하고 저장하지 않습니다. 정산·이력에 쓰이는 검침은 TransactionEvent의 meterValue로 보냅니다.

4.6 원격 제어 (CSMS → CS)

예시 — RequestStartTransaction

← [2, "r-01", "RequestStartTransaction", {
  "remoteStartId": 1024,
  "idToken": { "idToken": "APP-7F3A", "type": "Central" },
  "evseId": 1
}]
→ [3, "r-01", { "status": "Accepted" }]
→ [2, "t-01", "TransactionEvent", { "eventType": "Started", "triggerReason": "RemoteStart",
     "transactionInfo": { "transactionId": "5f1c…", "remoteStartId": 1024 }, ... }]

CSMS는 응답 status를 명령 이력에 기록하며, 세션이 없으면 명령을 보내지 않고 실패로 기록합니다.

4.7 스마트 차징

ISO 15118 협상 (K15~K17)

CSMS는 위 두 경우 외에는 프로파일을 자발적으로 재전송하지 않습니다.

4.8 인증서 관리 · ISO 15118

4.8.1 충전기 인증서 갱신 (SignCertificate → CertificateSigned)

→ [2, "c-01", "SignCertificate", { "csr": "-----BEGIN CERTIFICATE REQUEST-----…", "certificateType": "ChargingStationCertificate" }]
← [3, "c-01", { "status": "Accepted" }]                       // ① CSR 접수 응답이 먼저
← [2, "c-02", "CertificateSigned", { "certificateChain": "-----BEGIN CERTIFICATE-----…" }]   // ② CSMS-CA 서명 후 전송
→ [3, "c-02", { "status": "Accepted" }]

• CSMS는 SignCertificate 응답이 소켓에 먼저 나간 뒤 CertificateSigned를 전송하도록 순서를 보장합니다.
• certificateType = V2GCertificate의 CSR은 Rejected입니다 — V2G 충전기 인증서는 CSMS가 발급하지 않습니다.

4.8.2 인증서 설치·조회·삭제 (CSMS → CS)

4.8.3 ISO 15118 (PnC) — 계약 인증서

4.9 예약

4.10 로컬 인가 목록

4.11 장치 모델 · 진단 · 펌웨어

4.12 표시 메시지

표시 메시지의 정본은 충전기이며 CSMS는 요청·조회 결과 표시만 합니다.

5. 운영 · 시험

5.1 어드민 등록 항목 (운영팀 수행)

5.2 충전기 QR 생성

5.3 시험 환경

• 연동 시험은 개발 환경(cp2.dev.oasis-arca.com)에서 진행합니다. 개발 환경은 TLS 접속도 SP1로 판정되므로 시험 충전기는 SP1로 등록합니다(1.1).
• 식별자·자격증명·PnC 설정은 운영팀이 발급합니다.
• 필요 시 CSMS 시뮬레이터의 "OCPP 2.0.1 Standard" 프로파일로 메시지 형태를 대조할 수 있습니다.

6. 부록

6.1 OCPP 1.6 ↔ 2.0.1 메시지 대응

6.2 구현 체크리스트 (제조사)

• ☐subprotocol ocpp2.0.1로 /ocpp2/<chargingStationId>에 접속한다(미제시 시 400).
• ☐할당된 보안 프로파일대로 접속한다 — Basic Auth username = chargingStationId, SP3는 CN = chargingStationId, CSMS-CA 루트 사전 설치(1.3). 개발 환경은 SP1로 시험한다(1.1).
• ☐BootNotification의 Pending / Rejected와 부팅 게이트를 처리한다 — 게이트 중 Boot 외 CALL은 SecurityError(4.1).
• ☐Authorize / TransactionEvent 응답의 idTokenInfo.status와 groupIdToken을 처리한다. Started에서 Invalid면 충전을 중단한다(4.2, 4.3).
• ☐TransactionEvent에 seqNo를 단조 증가로 채우고, Energy.Active.Import.Register(Wh)를 반드시 포함한다. totalCost를 화면에 표시할 수 있다(4.3).
• ☐거래 외 검침은 저장되지 않음을 전제로 한다 — 정산용 검침은 TransactionEvent로(4.5).
• ☐RequestStartTransaction의 remoteStartId를 TransactionEvent(Started)에 반영한다(4.6).
• ☐DataTransfer 벤더 확장은 구현하지 않는다 — CS → CSMS DataTransfer는 UnknownVendorId를 받는다(3장).
• ☐(스마트 차징) 프로파일 3종·GetCompositeSchedule·ReportChargingProfiles와 ISO 15118 협상 응답(Accepted/Rejected 후 재협상)을 구현한다(4.7).
• ☐(PnC 대상) Authorize 인증서 필드, Get15118EVCertificate, GetCertificateStatus, 인증서 관리 4종을 네이티브로 구현한다. SignCertificate는 ChargingStationCertificate만 CSMS가 서명한다(4.8).
• ☐SendLocalList는 2.0.1 형식(versionNumber, idToken{idToken,type})으로 받는다(4.10).

6.3 문의

식별자 등록, 보안 프로파일·Basic Auth 발급, CSMS-CA 루트 인증서, PnC 사용 설정 등은 CSMS 운영팀에 문의하십시오.

문의: axd@bionever.com