Plug & Charge (PnC) - Use Cases

이 문서는 EVSE와 MO(Mobility Operator) 관점에서 고객, 전기차(EV), 충전기(EVSE), CSMS 사이의 Plug & Charge (PnC) 흐름을 설명합니다.

개요

Plug & Charge는 고객이 충전 케이블을 연결하면 EV가 보유한 계약 인증서(Contract Certificate)를 기반으로 자동 인증하고, 승인된 경우 충전과 과금 절차가 이어지는 방식입니다.

관점	주요 역할
고객	MO 서비스 가입, 차량 등록, Plug & Charge 이용 동의, 커넥터 연결/분리
MO	고객 계약 관리, PCID 수집, eMAID 생성, 멤버십 카드와 eMAID 매핑, 계약 인증서 발급/갱신, 계약 상태 및 결제 수단 관리
EV	OEM Provisioning 인증서와 계약 인증서 보관, PCID/eMAID 기반 ISO 15118 인증 정보 제공
EVSE	ISO 15118 세션 처리, 인증서 설치 요청 중계, Plug & Charge 결과에 따라 충전 제어
CSMS	EVSE가 전달한 Plug & Charge 요청 처리, 인증서 상태 확인 결과 전달, 거래 시작/종료 관리

사전 조건

EV와 EVSE는 ISO 15118 기반 Plug & Charge를 지원해야 합니다.
EVSE는 V2G Root, MO Root 등 Plug & Charge 검증에 필요한 신뢰 앵커를 보유해야 합니다.
EVSE는 SECC 인증서와 개인키를 안전하게 보관해야 합니다.
고객의 EV에는 유효한 계약 인증서가 설치되어 있거나, EV가 계약 인증서 설치/갱신 절차를 요청할 수 있어야 합니다.
MO는 차량의 PCID(Provisioning Certificate Identifier)를 수집하고, 계약 식별자인 eMAID(e-Mobility Account Identifier)를 생성·관리하며, eMAID와 고객 멤버십 카드를 매핑해야 합니다.
OCPP 1.6 EVSE는 ISO 15118 확장 메시지를 DataTransfer로 처리할 수 있어야 합니다.
OCPP 2.0.1/2.1 EVSE는 Authorize, Get15118EVCertificate, SignCertificate, InstallCertificate 등 표준 인증서 메시지를 처리할 수 있어야 합니다.

인증서 설치 절차

Plug & Charge 이용 전에는 EVSE 인증서, 신뢰 앵커, EV 계약 인증서가 준비되어야 합니다. 인증서는 운영 중 갱신·폐지될 수 있으므로 EVSE는 설치뿐 아니라 조회, 갱신, 삭제 실패 상황도 안전하게 처리해야 합니다.

1. EVSE Leaf 인증서 설치 또는 갱신

EVSE는 CSMS와 EV 사이에서 SECC(Supply Equipment Communication Controller) 역할을 수행하므로, ISO 15118 TLS 세션에 사용할 EVSE Leaf 인증서를 보유해야 합니다. 이 인증서는 InstallCertificate로 설치하는 Root 인증서가 아니라, EVSE가 생성한 CSR을 CA가 서명한 뒤 CertificateSigned로 전달되는 인증서 체인입니다.

EVSE가 키 쌍을 생성하고 CSR(Certificate Signing Request)을 준비합니다.
EVSE는 SignCertificate로 CSR을 CSMS에 전달합니다. ISO 15118-2 기반 SECC 인증서이면 certificateType은 V2GCertificate를 사용합니다.
CSMS가 요청을 수락하면 CSR을 인증기관으로 전달하여 Leaf 인증서 서명 처리를 진행합니다.
서명된 Leaf 인증서가 준비되면 CSMS가 CertificateSigned로 EVSE에 전달합니다. certificateChain은 Leaf 인증서로 시작하고 필요한 SubCA 인증서를 뒤에 포함할 수 있습니다.
EVSE는 인증서 체인을 검증하고 안전 저장소에 설치합니다.
설치에 성공하면 이후 ISO 15118 세션에서 새 인증서를 사용합니다.

certificateType 의미

SignCertificate와 CertificateSigned의 certificateType은 인증서가 Leaf인지 Root인지를 나타내는 값이 아니라 서명·반환되는 인증서의 사용 목적을 나타냅니다. 따라서 ISO 15118-2용 SECC Leaf 인증서는 V2GCertificate, ISO 15118-20용 SECC Leaf 인증서는 V2G20Certificate, CSMS 연결용 충전기 인증서는 ChargingStationCertificate를 사용합니다.

EVSE Leaf 인증서 운영

EVSE Leaf 인증서는 일반적으로 짧은 유효 기간으로 운영될 수 있습니다. EVSE는 만료 전에 갱신을 시작할 수 있도록 인증서 만료일을 추적하고, 새 인증서 설치가 완료되기 전까지 기존 유효 인증서와 개인키를 삭제하지 않아야 합니다.

OCPP 2.1 SignCertificate 예시

[
  2,
  "uuid-sign-certificate",
  "SignCertificate",
  {
    "csr": "-----BEGIN CERTIFICATE REQUEST-----...-----END CERTIFICATE REQUEST-----",
    "certificateType": "V2GCertificate",
    "requestId": 1001
  }
]

OCPP 2.1 CertificateSigned 예시

[
  2,
  "uuid-certificate-signed",
  "CertificateSigned",
  {
    "certificateChain": "-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----",
    "certificateType": "V2GCertificate",
    "requestId": 1001
  }
]

2. Root 인증서와 신뢰 앵커 설치

CSMS는 EVSE가 EV 계약 인증서 체인을 검증할 수 있도록 V2G Root, MO Root 등 필요한 Root 인증서를 설치할 수 있습니다. 이 절차는 EVSE Leaf 인증서 설치가 아니라, EVSE의 신뢰 저장소에 Root 인증서를 추가하는 절차입니다.

CSMS가 InstallCertificate로 Root 인증서를 EVSE에 전달합니다.
EVSE는 인증서 형식, 만료일, 체인 관계, 중복 여부를 확인합니다.
설치가 가능하면 Accepted로 응답하고 신뢰 저장소에 반영합니다.
설치할 수 없는 경우 Rejected 또는 사유에 맞는 상태로 응답하고 기존 신뢰 저장소는 유지합니다.
CSMS는 필요 시 GetInstalledCertificateIds로 설치 상태를 확인하고, 더 이상 사용하지 않는 인증서는 DeleteCertificate로 삭제할 수 있습니다.

OCPP 2.1 InstallCertificate 예시

[
  2,
  "uuid-install-certificate",
  "InstallCertificate",
  {
    "certificateType": "MORootCertificate",
    "certificate": "-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----"
  }
]

3. EV 계약 인증서 설치

고객이 MO 서비스에 가입하면 MO는 고객·차량 계약에 대한 계약 인증서를 발급합니다. 계약 인증서에는 계약 식별자인 eMAID가 포함되며, MO는 차량 식별자인 PCID, eMAID, 고객 멤버십 카드의 매핑을 관리해야 합니다. 계약 인증서는 앱/차량 OTA 방식으로 EV에 설치될 수 있으며, 계약 인증서가 없는 차량은 EVSE 화면에서 멤버십 카드를 태깅해 등록한 뒤 EVSE를 통해 설치 요청을 중계할 수도 있습니다.

EVSE를 통한 설치 흐름은 다음과 같습니다.

고객이 차량을 EVSE에 연결합니다.
EVSE는 계약 인증서가 없음을 확인하면 고객에게 Plug & Charge 등록이 필요하다고 안내합니다.
고객이 동의하면 EVSE는 멤버십 카드 태깅을 요청합니다.
User가 멤버십 카드를 RFID Reader에 태깅합니다.
EV가 ISO 15118 세션에서 계약 인증서 설치 또는 갱신을 요청합니다.
EVSE는 EV가 전달한 EXI 요청을 Get15118EVCertificate로 CSMS에 전달합니다.
CSMS는 계약 인증서 설치 응답을 EVSE에 반환합니다.
EVSE는 응답을 EV에 전달합니다.
EV가 설치를 완료하고 eMAID를 확인할 수 있게 되면, EVSE는 DataTransfer:com.skelectlink:PncRegister로 eMAID와 멤버십 카드 번호의 매핑 등록을 요청합니다.
등록이 성공하면 다음 Plug & Charge부터 새 계약 인증서를 사용합니다.

OCPP 2.1 Get15118EVCertificate 예시

[
  2,
  "uuid-get-15118-ev-certificate",
  "Get15118EVCertificate",
  {
    "iso15118SchemaVersion": "urn:iso:15118:2:2013:MsgDef",
    "action": "Install",
    "exiRequest": "BASE64_ENCODED_EXI_REQUEST"
  }
]

OCPP 1.6 DataTransfer 예시

[
  2,
  "uuid-get-15118-ev-certificate-16",
  "DataTransfer",
  {
    "vendorId": "org.openchargealliance.iso15118pnc",
    "messageId": "Get15118EVCertificate",
    "data": {
      "iso15118SchemaVersion": "urn:iso:15118:2:2013:MsgDef",
      "action": "Install",
      "exiRequest": "BASE64_ENCODED_EXI_REQUEST"
    }
  }
]

충전 워크플로우

고객 및 MO 관점

고객이 MO 앱 또는 서비스 채널에서 Plug & Charge 이용에 동의하고 차량을 등록합니다.
MO는 차량 PCID를 수집하고 계약 식별자인 eMAID를 생성합니다.
MO는 고객 계약과 결제 수단을 확인하고 계약 인증서를 발급·배포합니다.
고객의 EV에 계약 인증서가 설치되었거나, EV가 ISO 15118 세션 중 계약 인증서 설치/갱신을 요청할 수 있는 상태가 됩니다.
고객이 EVSE에 커넥터를 연결합니다.
EVSE는 PLC 통신에서 SLAC를 수행하고, EV와 ISO 15118 HLC로 업그레이드합니다.
HLC 업그레이드가 되지 않거나 EV가 Plug & Charge를 선택하지 않으면, EVSE는 일반 사용자 인증 화면 또는 현장 정책에 맞는 fallback으로 전환합니다.
EV가 유효한 계약 인증서를 보유한 경우 EVSE는 eMAID, 인증서 해시, 필요한 경우 계약 인증서를 수신하고 사용자 인증 use-case의 Plug & Charge 절차를 수행합니다.
EV가 계약 인증서를 보유하지 않았거나 갱신이 필요한 경우 EVSE는 고객에게 등록 절차를 안내하고 멤버십 카드 태깅을 받은 뒤 계약 인증서 설치 절차를 중계합니다. 설치 후 PncRegister로 eMAID와 멤버십 카드 번호를 매핑하고, 등록이 성공하면 EV와 다시 필요한 ISO 15118 절차를 진행한 뒤 Plug & Charge 절차를 수행합니다.
고객이 등록을 취소하거나 계약 인증서 설치/매핑 등록을 완료할 수 없으면 EVSE는 Plug & Charge를 중단하고 일반 사용자 인증 fallback을 제공합니다.
승인된 경우 EVSE는 충전 준비 및 거래 시작 절차를 진행합니다.
충전 종료 후 CSMS와 MO는 eMAID 등 계약 식별자 기준으로 과금/정산에 필요한 결과를 처리합니다.

인증 요청/응답 상세

실제 Plug & Charge (PnC) 요청/응답 프레임, 응답 예시, 결과별 EVSE 동작은 사용자 인증 use-case의 Plug & Charge (PnC) 인증 섹션을 참고합니다.

EVSE 구현 가이드

인증서 설치·갱신 실패가 충전 실패로 이어질 수 있으므로, 실패 사유와 사용자 조치 방법을 간단히 안내합니다.
Root 인증서 또는 EVSE 인증서 갱신 중 기존 유효 인증서를 즉시 삭제하지 않습니다. 새 인증서 설치가 완료된 뒤 전환합니다.
만료가 임박한 EVSE Leaf 인증서는 CSMS 요청 또는 EVSE 로컬 정책에 따라 사전에 SignCertificate 갱신 절차를 시작할 수 있어야 합니다.
EVSE Leaf 인증서를 폐기하거나 교체할 때는 DeleteCertificate 또는 로컬 인증서 저장소 삭제 후, ISO 15118 세션에서 더 이상 폐기된 인증서가 사용되지 않도록 해야 합니다.
EVSE의 시간 동기화가 맞지 않으면 인증서 유효 기간 검증이 실패할 수 있으므로, Plug & Charge 세션 전 시간 동기화 상태를 확인합니다.
EVSE가 EV의 TLS status_request 또는 status_request_v2 확장을 처리하지 않는 경우에도 TLS handshake가 실패하지 않도록 안전하게 무시하거나, 지원 가능한 OCSP stapling 동작을 명확히 구현해야 합니다.
OCPP 연결 보안 인증서와 ISO 15118 V2G 인증서는 서로 다른 목적의 인증서입니다. Plug & Charge 구현은 OCPP Security Profile 2 또는 3에 따른 TLS 연결 보안을 별도로 충족해야 하며, V2G PKI 인증서가 CSMS 연결용 인증서를 대체하지 않습니다.
OCPP 1.6 DataTransfer 예시는 OCPP JSON CALL/CALLRESULT array 전체를 표시하며, data는 문자열 래핑 없이 JSON object로 작성합니다.
OCPP 2.1에서는 가능한 경우 표준 메시지를 우선 사용하고, 커스텀 DataTransfer로 중복 구현하지 않습니다.
Plug & Charge 실패 시 fallback은 필수입니다. EVSE는 우선 맥인증을 시도하고, MAC 주소가 미등록이면 맥인증 등록 절차를 제공해야 합니다.
DC 충전에서 Authorize 이전 단계에 Plug & Charge가 실패하면 Step_E/F를 수행하고 Only EIM 모드로 전환합니다.
AC 충전에서 Authorize 이전 단계에 Plug & Charge가 실패하면 Step_E/F를 수행하고 Only EIM 모드로 전환합니다.
AC 충전이 ChargingStatus로 진행 중 통신 이상으로 중단되면 Step_E/F와 BC(Basic Charging)를 수행할 수 있습니다. 이 동작은 기술 규격/시험 규격상 충전기 선택사항입니다.

OCPP 2.1 호환성

기능	OCPP 1.6 ISO 15118 확장	OCPP 2.1 표준 메시지	호환성 판단
Plug & Charge (PnC)	`DataTransfer:Authorize`	`Authorize`	동일한 인증 개념을 사용하지만 OCPP 2.1은 표준 메시지로 처리합니다.
EV 계약 인증서 설치	`DataTransfer:Get15118EVCertificate`	`Get15118EVCertificate`	메시지 의미가 호환됩니다. OCPP 2.1에서는 `action`, `exiRequest`, `exiResponse` 구조를 표준 필드로 사용합니다.
EVSE 인증서 서명 요청	`DataTransfer:SignCertificate`	`SignCertificate`	OCPP 2.1 표준 메시지로 호환됩니다.
서명 인증서 전달	`DataTransfer:CertificateSigned`	`CertificateSigned`	OCPP 2.1 표준 메시지로 호환됩니다.
Root 인증서 설치	`DataTransfer:InstallCertificate`	`InstallCertificate`	OCPP 2.1 표준 메시지로 호환됩니다. `certificateType`은 `V2GRootCertificate`, `MORootCertificate`, `OEMRootCertificate` 등 Root 계열 값을 사용합니다.
설치 인증서 조회/삭제	`DataTransfer:GetInstalledCertificateIds`, `DataTransfer:DeleteCertificate`	`GetInstalledCertificateIds`, `DeleteCertificate`	운영 절차가 호환됩니다.
인증서 상태 확인	`DataTransfer:GetCertificateStatus`	`GetCertificateStatus`	OCSP 등 상태 확인 개념은 호환됩니다. 다만 EVSE Leaf 인증서의 OCSP 전달 방식은 EVSE의 TLS `status_request`/OCSP stapling 지원 범위에 따라 별도 합의가 필요할 수 있습니다.

OCPP 1.6 확장은 Plug & Charge 기능을 DataTransfer로 터널링하는 방식이고, OCPP 2.1은 동일 영역을 표준 메시지로 제공합니다. 따라서 EVSE가 OCPP 2.1로 전환될 때는 메시지 이름과 주요 도메인 개념을 유지하되, OCPP 1.6 DataTransfer.data object를 OCPP 2.1 표준 payload 구조로 매핑해야 합니다.

개요​

사전 조건​

인증서 설치 절차​

1. EVSE Leaf 인증서 설치 또는 갱신​

2. Root 인증서와 신뢰 앵커 설치​

3. EV 계약 인증서 설치​

충전 워크플로우​

고객 및 MO 관점​

EVSE 구현 가이드​

OCPP 2.1 호환성​

개요