글로벌 상용 충전 사업자를 위한 OCPP 1.6J와 2.0.1의 전략적 비교: 네트워크 확장성, 고급 사이버 보안, ISO 15118 통합 및 지속 가능한 전기차 성장을 위한 장기적인 인프라 미래 보장 확보
요약 보고서
전기차(EV) 충전 환경이 지각변동을 겪고 있습니다. 전 세계적으로 전기차 보급이 가속화됨에 따라, 전기차 충전 장비(EVSE)와 충전소 관리 시스템(CSMS) 간의 상호 작용을 관장하는 기본 통신 프로토콜이 상용 충전 사업자(CPO)의 기술 전략의 핵심으로 떠올랐습니다. 오픈 차지 얼라이언스(OCA)에서 관리하는 오픈 차지 포인트 프로토콜(OCPP)은 단순한 메시징 프레임워크에서 정교하고 안전하며 확장성이 뛰어난 표준으로 발전했습니다.
이 가이드는 OCPP 1.6J에서 OCPP 2.0.1로의 전환에 대한 포괄적인 기술 분석을 제공합니다. 아키텍처 차이점, 보안 강화, 장치 관리 패러다임, 그리고 ISO 15118 통합의 핵심적인 역할에 대해 자세히 살펴봅니다. 구매자와 운영자에게 이 문서는 빠르게 성장하는 시장에서 정보에 기반한 구매 및 마이그레이션 결정을 내리는 데 필요한 최고의 참고 자료가 될 것입니다.
제1장: 전기차 충전 표준의 진화: 역사적 배경
개방형 충전소 프로토콜(OCPP)은 상호 운용성에 대한 필요성에서 탄생했습니다. 전기차 충전 초기에는 하드웨어 제조업체와 소프트웨어 제공업체가 독자적인 프로토콜을 사용하여 경쟁과 혁신을 저해하는 "폐쇄형 생태계"를 만들었습니다. OCPP 1.2 및 1.5 버전의 도입으로 기반이 마련되었지만, 업계를 진정으로 통합한 것은 OCPP 1.6 버전이었습니다.
1.1 OCPP 1.6J의 지배력
2015년에 출시된 OCPP 1.6은 JSON over WebSockets(1.6J) 구현을 도입했습니다. SOAP 기반 메시징에서 벗어난 이 방식은 오버헤드를 크게 줄이고 개발자의 구현을 간소화했습니다. 스마트 충전 및 추가 상태 알림과 같은 기능을 제공하여 거의 10년 동안 업계 표준으로 자리 잡았습니다.
1.2 OCPP 2.0.1의 탄생
1.6J 버전의 성공에도 불구하고, 업계의 성장은 그 한계를 드러냈습니다. 보안 문제, 복잡한 장치 관리, 그리고 고급 전력망 통합(V2G)에 대한 기본 지원 부족으로 인해 OCPP 2.0이 개발되었고, 이후 개선된 OCPP 2.0.1(2020년 출시)이 나왔습니다. OCPP 2.0.1은 단순한 업데이트가 아니라, 차세대 고출력, 스마트, 보안 충전 네트워크를 지원하기 위한 완전한 재설계입니다.
제2장: 기본 통신 패러다임: JSON, 웹소켓 및 프레임 구조
이 두 프로토콜의 차이점을 이해하려면 저수준 통신을 살펴봐야 합니다. 두 프로토콜 모두 웹소켓을 통해 JSON을 사용하지만, 메시지의 구조와 처리 방식은 상당히 다릅니다.
2.1 웹소켓 계층
두 버전 모두 양방향 통신이 가능한 영구적인 WebSocket 연결을 사용합니다. 이는 모바일 앱에서 충전 세션을 중지하거나 즉각적인 오류 알림을 수신하는 등의 실시간 작업에 매우 중요합니다.
2.2 메시지 프레임 분석
일반적인 OCPP 메시지는 메시지 유형 ID, 고유 메시지 ID, 작업 이름 및 페이로드로 구성됩니다.
OCPP 1.6J 프레임 예제(부팅 알림)
“json [2, "123456", "BootNotification", { "chargePointVendor": "MidaPower", "chargePointModel": "Terra-X", "chargePointSerialNumber": "SN001", "firmwareVersion": "v1.2.3" }]“
OCPP 2.0.1 프레임 예제(부팅 알림)
“json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`2.0.1 버전에서 더욱 세밀해진 것을 확인하세요.`reason` 필드를 통해 CSMS는 부팅이 재부팅, 전원 켜짐 또는 워치독 트리거로 인한 것인지 파악할 수 있으므로 더 나은 진단 로직을 구현할 수 있습니다.
제3장: 아키텍처 패러다임의 전환: 디바이스 모델
OCPP 2.0.1에서 가장 중요한 기술적 변화는 다음과 같은 기능의 도입입니다.기기 모델.
3.1 1.6J 설정 키의 한계
OCPP 1.6J에서는 하드웨어 구성이 "구성 키"의 평면 목록(예:심장 박동 간격, 연결 시간 초과충전기가 점점 더 복잡해짐에 따라(다중 커넥터, 통합 전력 모듈, 복잡한 냉각 시스템 등), 이러한 평면적인 목록은 관리하기 어려워졌습니다. 충전소의 물리적 계층 구조를 설명하는 표준화된 방법이 없었던 것입니다.
3.2 2.0.1 장치 모델 접근 방식
OCPP 2.0.1은 계층적 모델을 도입합니다.구성 요소그리고변수구성 요소는 "컨트롤러", "커넥터" 또는 "파워모듈"일 수 있습니다. 각 구성 요소에는 상태 또는 구성을 나타내는 변수가 있습니다(예:온도, 전압, 최대 전류).
- 요소충전소의 물리적 또는 논리적 구성 요소.
- 변하기 쉬운: 해당 구성 요소의 특정 속성입니다.
- 형질변수를 설명하는 메타데이터(단위, 범위, 접근 유형).
이를 통해 표준화된 모니터링이 가능해집니다. 이제 운영자는 공급업체별 고유 키에 의존하는 대신 표준화된 경로를 사용하여 특정 전력 모듈의 온도를 조회할 수 있습니다.
제4장: 사이버 보안: "최선의 노력"에서 TLS 의무화까지
전기차 충전 초기에는 보안이 종종 부차적인 고려 사항이었습니다. OCPP 1.6J는 보안 프로파일을 제공했지만, 공급업체별로 구현 방식이 일관되지 않았습니다.
4.1 1.6J 버전의 보안 프로필
OCPP 1.6J는 세 가지 보안 프로필을 정의했습니다.
- 담보되지 않음: 일반 텍스트 HTTP/WebSockets.
- 기본 인증TLS(사용자 이름/비밀번호 사용).
- 인증서 기반클라이언트 측 인증서를 사용하는 TLS.
문제는 많은 충전기가 프로필 1에 머물러 있어 중간자 공격(MITM)과 무단 제어에 취약하다는 점이었습니다.
4.2 2.0.1의 강화된 입장
OCPP 2.0.1은 안전한 통신을 의무화하며, 고급 보안 기능을 기본적으로 통합합니다.
- 안전한 펌웨어 업데이트펌웨어 이미지에 대한 필수 서명 및 검증.
- 보안 로깅보안 관련 이벤트(예: 로그인 실패, 인증서 만료)에 대한 자세한 로그를 제공합니다.
- 인증서 관리: 인증서 갱신 및 업데이트에 대한 표준화된 메시지(CSMS 주도 또는 스테이션 주도).
- TLS 1.2/1.3최신 암호화 표준을 지원합니다.
상업 운영자의 경우, 이는 대규모 네트워크 침해 위험을 줄이고 IoT 장치에 대한 새로운 사이버 보안 규정을 준수하도록 보장합니다.
제5장: ISO 15118 통합: 플러그 앤 차지 및 V2G
전기차 충전의 미래는 단순히 전자를 이동시키는 것만이 아니라, 데이터와 에너지의 지능적인 교환에 달려 있습니다. ISO 15118은 차량-전력망(V2G) 통신을 위한 국제 표준이며, OCPP와의 통합은 2.0.1 버전의 핵심 특징입니다.
5.1 플러그 앤 차지의 복잡성
플러그 앤 차지(PnC)는 운전자가 앱을 사용하거나 RFID 카드를 등록할 필요 없이 차량을 충전기에 연결하기만 하면 바로 충전을 시작할 수 있도록 하는 기술입니다. 이를 위해서는 차량, 충전기, 운영자, 그리고 데이터 처리 센터를 아우르는 복잡한 공개 키 인프라(PKI)가 필요합니다.
OCPP 1.6J에서는 기본 프로토콜에 PnC 지원 기능이 없었습니다. 벤더들은 자체 확장 기능을 구현해야 했고, 이로 인해 프로토콜이 파편화되었습니다. OCPP 2.0.1은 다음과 같은 기능을 지원하여 PnC를 위한 "기반"을 제공합니다.
- 인증서 설치CSMS에서 EVSE를 통해 전기차로 계약 인증서를 전달합니다.
- 권한 부여차량 인증서에서 발급된 e-모빌리티 ID(eMAID)를 사용합니다.
- 암호화된 통신차량과 전력망 간에 전송되는 민감한 요금 데이터가 보호되도록 보장합니다.
5.2 스마트 충전 및 부하 분산
1.6J는 기본적인 스마트 충전(전송)을 지원했지만충전 프로필 설정), 2.0.1 버전은 이를 향상시킵니다. 다음과 같은 기능을 제공합니다.
- 외부 신호 통합전력망 주파수 또는 도매 가격 신호에 실시간으로 대응합니다.
- 동적 부하 관리수백 개의 커넥터가 있는 현장에서 전력 분배를 더욱 세밀하게 제어할 수 있습니다.
- 차량-전력망(V2G)버전 2.0.1에는 양방향 에너지 흐름을 지원하는 데 필요한 데이터 필드가 포함되어 있어 전기차가 전력망의 분산 에너지 자원(DER) 역할을 할 수 있습니다.
5.3 사용자 UI/UX 개선
OCPP 2.0.1은 다음과 같은 정보를 충전기 화면이나 차량 대시보드에 직접 표시하는 기능을 지원합니다.
- 현지 통화로 실시간 가격이 표시됩니다.
- 배터리 충전량(SoC) 80%에 도달하는 데 걸리는 예상 시간.
- 완료 시 상세 영수증 정보를 제공합니다.
제6장: 고급 장치 관리 및 모니터링
CPO(인증된 구매 담당자)에게 충전기 비용은 단순히 구매 가격만이 아닙니다. 총 소유 비용(TCO)이 포함됩니다. 유지 보수 및 가동 중단 시간은 수익을 저해하는 가장 큰 요인입니다. OCPP 2.0.1은 탁월한 모니터링 기능을 통해 이러한 문제를 해결합니다.
6.1 이벤트 기반 보고
1.6J 버전에서 CSMS는 일반적으로 충전기의 상태를 확인하기 위해 폴링을 하거나 응답을 기다려야 했습니다.상태 알림2.0.1 버전에서는이벤트 모니터링이 시스템을 통해 CSMS는 임계값을 설정할 수 있습니다. 예를 들어, "내부 온도가 70°C를 초과할 경우에만 알림을 받도록 설정"하거나 "입력 전압이 200V 미만으로 떨어지면 보고하도록 설정"할 수 있습니다. 이는 네트워크 트래픽을 줄이고 사전 예방적 유지 관리를 가능하게 합니다.
6.2 거래 처리: TransactionEvent
OCPP 1.6J에서 가장 비판받았던 부분 중 하나는 거래 처리 방식이었습니다. 한 세션에서 다음과 같은 일이 있었습니다.거래 시작그리고거래 중지메시지 전송은 가능했지만, 네트워크 장애가 발생하면 CSMS는 청구 데이터를 대조하는 데 어려움을 겪는 경우가 많았습니다.
OCPP 2.0.1은 이러한 것들을 하나의 견고한 시스템으로 대체합니다.거래 이벤트이 메시지는 트랜잭션의 모든 라이프사이클 단계(시작됨, 업데이트됨, 종료됨)를 보고하는 데 사용됩니다. 고유한 식별자가 포함되어 있습니다.거래 ID충전기가 재부팅되더라도 설정이 유지되므로 충전 데이터 손실, 즉 수익 손실이 발생하지 않습니다.
6.3 향상된 진단 및 문제 해결 기능
그만큼로그 가져오기그리고진단상태알림2.0.1 버전의 메시지는 더욱 구조화되었습니다. CPO(최고 제품 책임자)는 특정 로그 유형(보안, 진단, 사용자)을 요청하고 시간 범위를 지정할 수 있습니다. 이를 통해 원격 지원팀은 기술자를 현장에 파견하지 않고도 문제를 해결할 수 있어 운영 비용을 크게 절감할 수 있습니다.
제7장: 펌웨어 업데이트 메커니즘: 신뢰성 및 롤백
펌웨어 업데이트는 하드웨어 발전의 핵심이지만, 업데이트 실패는 충전기를 먹통으로 만들 수 있습니다.
7.1 1.6J 업데이트 프로세스
1.6J 버전에서,펌웨어 업데이트명령어는 비교적 간단했습니다. 충전기가 이미지를 다운로드하고 설치를 시도하는 방식이었죠. 다단계 업데이트나 검증된 롤백을 위한 표준화된 메커니즘은 없었습니다.
7.2 2.0.1 다단계 업데이트
OCPP 2.0.1은 펌웨어 업데이트를 위한 더욱 정교한 라이프사이클을 도입했습니다.
- 다운로드충전기는 이미지를 가져와서 체크섬/서명을 확인합니다.
- 설치업데이트는 보조 파티션에 적용됩니다.
- 확인시스템은 새 펌웨어가 정상적으로 부팅되는지 확인합니다.
- 활성화기본 파티션이 전환되었습니다.
어떤 단계에서든 오류가 발생하면 프로토콜은 충전기가 이전의 안정적인 버전으로 되돌아가는 방법과 특정 오류 코드를 CSMS에 보고하는 방법을 정의합니다. 이러한 수준의 신뢰성은 대규모 상용 배포에 있어 필수적입니다.
7.3 서명 확인
악의적인 공격자가 변조된 펌웨어를 업로드하는 것을 방지하기 위해 2.0.1 버전에서는 디지털 서명 사용을 의무화했습니다. 충전기는 제조업체의 개인 키로 서명되지 않은 코드는 실행하지 않으므로 하드웨어 수준의 해킹에 대한 중요한 보호 계층을 추가합니다.
제8장: 데이터 프라이버시, 규정 준수 및 GDPR
전기차 충전이 일상생활의 필수 요소가 되면서 생성되는 개인 데이터의 양은 엄청납니다. 단 한 번의 충전으로 사용자의 신원, 차량 위치, 이동 패턴, 금융 정보까지 연결될 수 있습니다.
8.1 OCPP의 개인 식별 정보(PII)
유럽의 일반 데이터 보호 규정(GDPR) 및 캘리포니아의 CCPA와 같은 유사 법률의 맥락에서, 다음과 같은 데이터 항목은idTag(RFID) 또는EVCCID차량 식별 정보는 개인 식별 정보(PII)로 간주됩니다.
OCPP 2.0.1은 데이터 익명화를 위한 더 나은 제어 기능을 제공합니다. 예를 들어,사용자 정의 데이터이 필드를 통해 운영자는 개인 식별 정보(PII)를 핵심 프로토콜 로그에 노출하지 않고 메타데이터를 저장할 수 있습니다. 또한, 강화된 보안 프로필은 이 데이터가 전송 중과 저장 시 모두 암호화되도록 보장합니다.
8.2 잊힐 권리 및 데이터 이동성
2.0.1 디바이스 모델의 구조화된 특성 덕분에 CSMS 제공업체는 "데이터 삭제" 요청을 더 쉽게 구현할 수 있습니다. 1.6J 시스템에서는 서로 다른 구성 키와 로그에서 사용자 ID의 모든 인스턴스를 찾는 것이 수작업으로 하기에는 매우 어려운 작업이었습니다. 2.0.1에서는 디바이스 상태와 트랜잭션 데이터가 명확하게 분리되어 데이터베이스 아키텍처를 더욱 깔끔하게 구성할 수 있습니다.
8.3 사물인터넷 보안 법규 준수
현재 많은 지역에서 IoT 기기에 고유한 비밀번호와 안전한 업데이트 메커니즘을 의무화하는 법률을 제정하고 있습니다. OCPP 2.0.1의 필수 TLS 및 서명된 펌웨어는 단순히 "있으면 좋은" 기능이 아니라 캘리포니아나 영국과 같은 시장에서 하드웨어를 판매하기 위한 법적 요구 사항입니다.
제9장: 구매자의 관점: 총소유비용(TCO), 투자수익률(ROI) 및 전략적 마이그레이션
상업용 충전 사업자에게 1.6J 버전을 유지할지 아니면 2.0.1 버전으로 전환할지는 재정적인 결정에 달려 있습니다.
9.1 구현 비용
- OCPP 1.6J구현 비용이 저렴하고 저가 하드웨어로 널리 지원되지만, 유지 관리 및 보안 위험 측면에서 숨겨진 비용이 높습니다.
- OCPP 2.0.1: 전기차 충전기(EVSE)에 더 강력한 프로세서와 더 많은 메모리가 필요합니다. CSMS는 프로토콜의 복잡성으로 인해 개발 비용이 더 높습니다. 하지만 원격 관리를 통해 운영 비용을 크게 절감하고 안정성을 향상시킬 수 있습니다.
9.2 "순조로운 업그레이드"라는 신화
흔히 1.6J 충전기를 소프트웨어 업그레이드를 통해 2.0.1 버전으로 업그레이드할 수 있다고 하지만, 실제로는 그렇지 않은 경우가 많습니다. 2.0.1 버전에 필요한 메모리와 CPU 용량(특히 TLS 인증서 처리 및 복잡한 JSON 형식의 장치 모델 파싱 작업)이 기존 1.6J 컨트롤러의 성능을 초과하는 경우가 흔하기 때문입니다.
9.3 전략적 이주 경로
CPO는 "하이브리드 네트워크" 접근 방식을 고려해야 합니다.
- 기존 사이트기존 저전력 AC 충전기는 1.6J로 계속 작동하도록 하십시오.
- 새로운 DC 고속 충전소: 모든 새로운 고출력 구축에 대해 PnC 및 V2G를 지원하도록 의무화하는 2.0.1 버전입니다.
- 프록시 솔루션1.6J 메시지를 CSMS용 2.0.1 호환 형식으로 변환할 수 있는 프로토콜 게이트웨이를 사용하여 단일 통합 관리 대시보드를 구현하십시오.
제10장: 미래 대비: OCPP 2.1과 자율 충전으로 가는 길
OCPP 2.0.1 버전이 점차 인기를 얻고 있는 가운데, 오픈 차지 얼라이언스는 이미 OCPP 2.1 개발에 착수했습니다. 이 차기 버전은 프로토콜의 활용 범위를 더욱 확장할 것입니다.
10.1 양방향 충전(V2X)
2.0.1 버전은 기본적인 V2G(차량 대 지상 전력) 통신을 지원하지만, 2.1 버전에서는 V2H(차량 대 가정) 및 V2B(차량 대 건물) 통신을 개선하여 전기차가 정전 시 가정에 전력을 공급하거나 상업용 건물의 피크 수요를 줄일 수 있도록 할 예정입니다.
10.2 무선 충전 지원
자율주행차(AV)가 등장함에 따라 수동 충전은 점차 사라질 것입니다. OCPP 2.1은 유도식(무선) 충전을 위한 표준화된 메시지를 포함하여 사람의 개입 없이 차량 정렬 및 에너지 전달을 관리할 것입니다.
10.3 스마트 시티와의 통합
향후 버전에서는 교통 관리 시스템 및 재생 에너지 예측 시스템과의 통합이 더욱 심화될 것으로 예상됩니다. 충전기는 실시간 에너지 시장에서 전력 구매에 참여할 수 있게 되어 충전 네트워크가 대규모 가상 발전소(VPP)로 변모할 것입니다.
기술 부록: 메시지 비교 심층 분석
기술적 깊이를 최대한으로 끌어올리기 위해 이제 두 버전 간의 특정 메시지 시퀀스 및 프레임 차이점을 분석해 보겠습니다.
A.1 권한 부여 흐름
1.6J 버전에서 인증은 "승인됨" 또는 "차단됨"이라는 이진 응답으로 처리되었습니다.
1.6J AuthorizeResponse:“json [3, "123456", { "idTagInfo": { "status": "Accepted", "expiryDate": "2026-12-31T23:59:59Z" } }]“
2.0.1 버전에서는 응답에 다음과 같은 더 많은 맥락 정보가 포함됩니다.idToken사용자 인터페이스에 대한 유형 및 추가 정보입니다.
2.0.1 AuthorizeResponse:“json [3, "987654", { "idTokenInfo": { "status": "Accepted", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "존님, 다시 오신 것을 환영합니다! 잔액은 $45.00입니다." } } }]“
A.2 하트비트 및 연결 관리
OCPP 2.0.1은 스테이션이 "활성" 상태임을 증명하는 방식을 최적화합니다. 1.6J 버전에서는 만약심장 박동실패하면 방송국은 종종 계속해서 재시도만 했습니다. 2.0.1 버전에서는 방송국이 다음을 사용할 수 있습니다.NotifyEvent기본 백엔드와의 연결을 유지하면서 보조 백엔드와의 연결이 끊어졌음을 보고하는 메커니즘입니다.
A.3 상세 메타데이터 표
| 특징 | OCPP 1.6J | OCPP 2.0.1 |
|---|---|---|
| 수송 | 웹소켓을 통한 JSON | 웹소켓을 통한 JSON |
| 보안 | 선택적 TLS, 기본 인증 | 필수 TLS, 클라이언트 인증서 |
| 기기 모델 | 플랫 설정 키 | 계층적 구성 요소/변수 |
| ISO 15118 | 확장 전용 | 네이티브 지원(PnC, V2G) |
| 거래 ID | CSMS에서 생성됨 | EVSE에서 생성됨 |
| 스마트 충전 | 기본(프로필) | 고급(전력망 신호, V2X) |
| 메시지 | ~30가지 동작 | 약 60가지 동작 |
| 디스플레이 지원 | 없음 | 네이티브 메시지 지원 |
결론
OCPP 1.6J에서 2.0.1로의 전환은 단순한 소프트웨어 업데이트가 아니라 전기 이동성 생태계의 근본적인 진화입니다. 상용 사업자에게 1.6J는 안정적인 과거를, 2.0.1은 확장성, 보안성, 그리고 지능성을 갖춘 미래를 의미합니다.
지금 2.0.1 버전을 선택하는 것은 장기적인 성공을 위한 투자입니다. 이 버전을 통해 하드웨어는 차세대 전기차와의 호환성을 확보하고, 강화되는 사이버 보안 규정을 준수하며, V2G(차량 대 네트워크) 및 스마트 그리드 통합의 유망한 기회를 활용할 수 있게 됩니다. 시장이 통합됨에 따라 가장 강력하고 유연한 프로토콜 스택을 갖춘 사업자가 시장을 선도하게 될 것입니다.
제11장: 심층 분석: 메시지 흐름 분석 및 시퀀스 다이어그램
이 장에서는 EVSE와 CSMS 간의 상호 작용 순서를 분석하여 1.6J와 2.0.1 버전 간의 작동상 차이점을 보여줍니다.
11.1 부팅 및 구성 순서
충전기가 네트워크에 처음 연결될 때, 자체 식별 및 구성 동기화를 수행해야 합니다.
OCPP 1.6J 유량:
- 웹소켓 연결: 80번 또는 443번 항구를 통해 설립되었습니다.
- 부트알림스테이션에서 제조사, 모델명, 시리얼 번호를 전송합니다.
- 구성 가져오기CSMS는 현재 상태를 확인하기 위해 모든 키를 요청합니다.
- 구성 변경CSMS는 특정 키(예:
심장 박동 간격). - 상태 알림: 방송국에서 "이용 가능"이라고 보고했습니다.

OCPP 2.0.1 흐름:
- 안전한 TLS 핸드셰이크필수 인증서 교환.
- 부트알림: 포함되는 사항
이유(예:파워업). - GetBaseReportCSMS는 모든 키를 요청하는 대신 장치 모델의 전체 계층 구조를 제공하는 "기본 보고서"를 요청합니다.
- 변수 설정CSMS에서 변수를 업데이트합니다. 참고로, 2.0.1 버전에서는 원자적 업데이트가 가능합니다. 즉, 하나의 메시지로 여러 변수를 설정하고 모든 업데이트가 성공하거나 모두 실패하도록 보장할 수 있습니다.
- NotifyEvent: 스테이션은 초기 구성 요소 상태를 보고합니다.
11.2 스마트 충전 협상
스마트 충전은 2.0.1 버전의 진정한 강점이며, 특히 여러 충전 프로필을 처리할 때 더욱 빛을 발합니다.
1.6J 버전에서 CSMS는 다음을 전송합니다.충전 프로필 설정이는 스택 레벨과 스케줄을 정의합니다. 스테이션에 여러 커넥터가 있는 경우 프로파일 처리가 모호해지는 경우가 많습니다.
2.0.1 버전에서,충전 프로필 설정명시적으로 연결되어 있습니다충전 프로필 목적.
- 충전소 최대 프로필역 전체의 흡입량을 제한합니다.
- TXDefaultProfile: 모든 신규 거래의 기본값입니다.
- TXProfile진행 중인 거래에 한정됩니다.
또한, 2.0.1 버전은 다음을 지원합니다.GetChargingStackLevel이 메시지를 통해 CSMS는 현재 활성화된 프로필과 EVSE의 내부 스케줄러가 해당 프로필에 어떤 우선순위를 부여하는지 확인할 수 있습니다.
11.3 원격 트리거링 및 제어
원격 명령은 다음과 같습니다.원격 시작 거래(1.6J)는 다음으로 대체되었습니다.RequestStartTransaction(2.0.1). 핵심적인 차이점은 페이로드에 있습니다. 2.0.1 버전에서 CSMS는 다음을 포함할 수 있습니다.충전 프로필시작 요청에 직접 포함됩니다. 즉, 차량은 두 번째 메시지를 기다릴 필요 없이 즉시 적절한 전력 레벨로 충전을 시작할 수 있으므로 지연 시간이 줄어들고 전력망 안정성이 향상됩니다.
제12장: 저수준 JSON 스키마 및 필드 비교
개발자와 시스템 통합업체에게 있어 스키마 변경은 마이그레이션 과정에서 가장 많은 시간과 노력이 필요한 부분입니다.
12.1 열거형(Enums)
OCPP 2.0.1은 표준화된 열거형의 수를 크게 확장하여 1.6J 구현에서 골칫거리였던 "사용자 지정" 상태 코드의 필요성을 줄였습니다.
- 이유 열거형:
지키는 개,예약된 재설정,원격 재설정,전력손실. - 상태 열거형:
가득차 있는,예약된,없는,결함 있음. 2.0.1 버전에서 다음 내용이 추가됩니다.사용 가능,가득차 있는,예약된,없는,결함 있음하지만 더 자세한 정보를 위해 하위 상태가 있습니다.
12.2 데이터 유형 및 단위
OCPP 2.0.1은 표준 단위(SI) 사용을 공식화합니다. 1.6J 버전에서는 소수점 정밀도를 정의하지 않은 경우가 있었지만, 2.0.1 버전에서는 이를 사용합니다.소수전력 및 에너지 값에 대한 유형을 지정하여 다양한 공급업체 하드웨어에서 일관된 요금 청구를 보장합니다.
제13장: 사례 연구: 1.6J에서 2.0.1로의 글로벌 CPO 마이그레이션
10,000개의 충전소를 보유한 CPO(공인 충전소)인 "메가차지"라는 가상의 시나리오를 살펴보겠습니다.
13.1 1단계: 감사
MegaCharge는 자사의 1.6J 충전기 중 40%가 TLS 1.2를 지원하지 않는다는 사실을 발견했습니다. 이는 해당 충전기들이 향후 정부 계약 대상에서 제외된다는 것을 의미했습니다.
13.2 2단계: CSMS 업그레이드
MegaCharge는 새로운 CSMS를 구축하는 대신 "OCPP 변환 계층"을 구현했습니다. 이 계층은 기존 하드웨어의 경우 1.6J 연결을, 새로운 하드웨어의 경우 2.0.1 연결을 처리하면서 모바일 앱과 결제 엔진에 통합 API를 제공했습니다.
13.3 3단계: 하드웨어 교체
MegaCharge는 이용객이 많은 지역에서 1.6J 충전기를 2.0.1 규격을 준수하는 DC 고속 충전기로 교체했습니다. 그 결과, "충전 시작 실패" 횟수가 15% 감소했는데, 이는 주로 더욱 안정적인 충전기 덕분입니다.거래 이벤트2.0.1 버전에서의 처리 방식.
13.4 투자수익률(ROI) 분석
초기 투자액은 200만 달러였습니다. 하지만 디바이스 모델의 진단 기능 덕분에 유지보수 요청 건수가 줄어들어 연간 40만 달러를 절감할 수 있었습니다. 또한, V2G 주파수 응답 시장에 참여함으로써 연간 20만 달러의 추가 수익을 창출했습니다. 투자 회수 기간은 약 3.3년이었습니다.
제14장: OCPP 2.0.1 구매를 위한 구매자 최종 체크리스트
새로운 하드웨어 또는 소프트웨어를 평가할 때, 이 체크리스트를 사용하여 진정한 규정 준수를 확인하십시오.
14.1 하드웨어(EVSE) 요구사항
- [ ]보안 프로필 3 지원클라이언트 측 인증서 관리를 지원합니까?
- [ ]듀얼 코어 프로세서TLS 암호화 및 JSON 파싱을 위한 여유 공간이 충분한가요?
- [ ]보안 요소(SE)보드에 키 저장을 위한 하드웨어 루트 오브 트러스트가 있습니까?
- [ ]ISO 15118-2/20 준비 완료컨트롤러가 PnC에 필요한 고수준 통신을 처리할 수 있습니까?
- [ ]디스플레이 기능하드웨어가 OCPP를 통해 가격/상태 정보를 표시하는 것을 지원합니까?
데이터 전송아니면 네이티브 메시지인가요?
14.2 소프트웨어(CSMS) 요구사항
- [ ]장치 모델 시각화대시보드에서 충전기의 계층 구조를 볼 수 있나요?
- [ ]인증 기관(CA) 통합CSMS는 인증서를 자동으로 발급하고 갱신할 수 있습니까?
- [ ]거래 대조시스템은 1.6J 구형 충전기에서 발생하는 "대기" 트랜잭션을 어떻게 처리합니까?
- [ ]스마트 충전 엔진2.0.1 버전의 고급 스택 레벨 로직을 지원합니까?
- [ ]확장성WebSocket 핸들러가 5만 개 이상의 지속적인 TLS 연결을 동시에 관리할 수 있습니까?
제15장: OCPP 구현 시 흔히 발생하는 문제 해결
표준이 존재하더라도 구현 방식은 다양합니다. 가장 흔한 "함정"들을 소개합니다.
15.1 웹소켓 타임아웃
많은 네트워크 방화벽은 유휴 TCP 연결을 차단합니다. 만약심장 박동 간격전압이 너무 높게 설정되면 충전기가 분리될 수 있습니다.
- 해결책: 보장하다
심장 박동 간격방화벽의 타임아웃 시간(일반적으로 60~120초)보다 짧습니다.
15.2 인증서 체인 문제
2.0.1 버전에서 흔히 발생하는 오류 중 하나는 "신뢰할 수 없는 인증서" 오류입니다. 이 오류는 일반적으로 충전기에 CSMS의 루트 CA가 설치되어 있지 않을 때 발생합니다.
- 해결책: 사용하세요
인증서 설치시운전 중에 메시지를 보내 신뢰 체계가 완성되었는지 확인합니다.
15.3 JSON 페이로드 크기
일부 2.0.1 메시지(예:GetBaseReport)는 매우 클 수 있습니다. 충전기의 버퍼가 너무 작으면 메시지가 손실됩니다.
- 해결책: 확인하세요
최대 메시지 크기장치 모델의 변수를 설정하고 CSMS가 이 제한을 준수하는지 확인하십시오.
제16장: 지역별 규제 환경 및 프로토콜 의무 사항
OCPP 2.0.1로의 전환은 단순히 기술적인 이유 때문만은 아닙니다. 점점 더 법적인 문제로 대두되고 있습니다.
16.1 유럽 연합(AFIR)
EU의 대체 연료 인프라 규정(AFIR)은 가격 투명성과 상호 운용성을 의무화합니다. 이 규정에서 OCPP 2.0.1을 명시적으로 언급하지는 않지만, "실시간 데이터 공유" 및 "스마트 충전"에 대한 요구 사항으로 인해 OCPP 2.0.1은 새로운 공공 인프라에 적용할 수 있는 유일한 실질적인 표준이 되었습니다.
16.2 북미(NEVI)
미국에서는 국가 전기 자동차 인프라(NEVI) 공식 프로그램에서 충전기가 "상호 운용 가능"해야 한다고 규정하고 있습니다. 캘리포니아와 같은 주에서는 한 걸음 더 나아가 캘리포니아 에너지 위원회(CEC)가 ISO 15118 지원을 추진하고 있는데, 앞서 논의했듯이 이는 OCPP 2.0.1을 통해 구현하는 것이 가장 좋습니다.
16.3 중국과 아시아태평양
중국은 자체 표준(GB/T)을 사용하지만, 수출 중심의 제조업체들은 OCPP 2.0.1에 집중적으로 투자하고 있습니다. 호주와 싱가포르 같은 시장에서는 공공 충전 네트워크 구축을 위한 정부 입찰에서 보안 프로필 3을 포함한 OCPP 2.0.1을 거의 예외 없이 요구하고 있습니다.
제17장: 구현 코드 조각: 세부 사항
개발자들을 지원하기 위해 복잡한 2.0.1 작업에 대한 개념적인 JSON 표현을 제공합니다.
17.1 자격증 순환 흐름
인증서 만료일이 가까워지면 CSMS는 인증서 갱신을 시작해야 합니다.
1. CSMS는 전송합니다증명서 서명됨:“json [2, "CERT-01", "CertificateSigned", { "certificateChain": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----", "certificateType": "V2G" }]“
2. 방송국 응답수락됨:“json [3, "CERT-01", { "status": "Accepted" }]“
3. 방송국에서 보냅니다보안 이벤트 알림:“json [2, "EVT-99", "SecurityEventNotification", { "type": "CertificateRotated", "timestamp": "2026-08-09T10:00:00Z" }]“
17.2 계통 연계형 충전 프로필 설정
전력망 운영자가 네트워크 전체의 전력 생산량을 줄여야 한다고 가정해 보세요.
CSMS가 보냅니다충전 프로필 설정:“json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "ChargingStationMaxProfile", "chargingProfileKind": "Absolute", "chargingSchedule": { "id": 1, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 11000 }, { "startPeriod": 3600, "limit": 22000 } ] } } }]“
제18장: OCPP 2.0.1 용어의 종합 용어집
모든 이해관계자의 이해를 돕기 위해 확장된 용어집을 제공합니다.
- CSMS(충전소 관리 시스템)충전기를 제어하는 백엔드 클라우드 플랫폼입니다.
- EVSE(전기차 충전 장비)물리적인 충전소.
- OCPP(Open Charge Point Protocol): 그들이 사용하는 언어.
- OCA(Open Charge Alliance)언어를 만드는 기관.
- ISO 15118: 차량과 충전기 간의 프로토콜.
- PnC(플러그 앤 차지)ISO 15118 및 OCPP 2.0.1을 통해 구현된 사용자 경험.
- V2G(차량-전력망 통신)자동차에서 생산된 전력을 전력망으로 되돌려 보내는 것.
- V2X(차량 대 모든 사물 통신)V2G, V2H, V2B를 포괄하는 용어입니다.
- TLS(전송 계층 보안)데이터를 안전하게 보호하는 암호화 기술입니다.
- PKI(공개 키 인프라): 보안을 위해 사용되는 디지털 인증서 시스템.
- JSON(자바스크립트 객체 표기법)메시지의 형식입니다.
- 웹소켓메시지가 흐르는 지속적인 연결 "파이프"입니다.
- 기기 모델: 2.0.1 버전에서 하드웨어를 설명하는 계층적 방식.
- 요소하드웨어 부품(예: 커넥터)
- 변하기 쉬운: 구성 요소의 속성(예: 상태).
- 기인하다변수에 대한 메타데이터(예: 값, 변경 가능성).
- 거래 이벤트2.0.1 버전에서는 모든 세션 데이터에 대한 통합 메시지가 제공됩니다.
- 심장 박동주기적인 "나는 살아있다" 신호.
- 부트알림충전기가 작동을 시작할 때 나오는 "안녕하세요, 저 여기 있어요"라는 신호입니다.
- 데이터 전송: 공급업체별 확장 기능에 대한 "포괄적인" 메시지입니다(주의해서 사용하세요!).
결론: 다중 프로토콜 시대를 헤쳐나가기
구매자든 운영자든 가장 중요한 점은 우리가 새로운 시장에 진입하고 있다는 것입니다.다중 프로토콜 시대향후 3~5년 동안은 1.6J와 2.0.1 버전이 공존할 것입니다. 하지만 그 균형은 빠르게 변화하고 있습니다.
오늘 OCPP 2.0.1을 선택하는 것은 단순히 프로토콜을 구매하는 것이 아니라, 일종의 보험을 드는 것과 같습니다. 새로운 차량, 새로운 법규, 새로운 수익원에 맞춰 네트워크를 유연하게 확장할 수 있도록 보장하는 것입니다. 2.0.1의 복잡성은 발전을 위한 대가이며, 향상된 가동 시간, 위험 감소, 그리고 탁월한 고객 경험을 통해 그 가치를 충분히 입증합니다.
상업용 충전은 더 이상 틈새 산업이 아닙니다. 미래 교통 시스템의 핵심입니다. 그 핵심을 가장 견고한 기반 위에 구축하십시오: OCPP 2.0.1.
제19장: OCPP 2.0.1 개발: 소프트웨어 엔지니어를 위한 모범 사례
1.6J 코드베이스에서 2.0.1로 전환하는 것은 리팩토링이 아니라 재작성입니다. 개발자들은 완전히 다른 사고방식을 가져야 합니다.
19.1 비동시성 수용
WebSocket은 본질적으로 비동기적이지만, 2.0.1 버전의 복잡성으로 인해 단일 요청(예: ...)이 처리되는 데 시간이 오래 걸릴 수 있습니다.GetBaseReport리소스가 제한된 EVSE에서 처리하는 데 몇 초가 걸릴 수 있습니다. CSMS 개발자는 다양한 하드웨어 공급업체의 처리 속도 차이를 고려하여 강력한 타임아웃 및 재시도 로직을 구현해야 합니다.
19.2 효율적인 JSON 파싱
JSON 파싱은 CPU 자원을 많이 소모할 수 있습니다. 전기차 충전기(EVSE) 펌웨어 개발자는 전체 페이로드를 RAM에 로드하는 대신 스트림 기반 파서를 사용해야 합니다. 이는 특히 다음과 같은 경우에 중요합니다.NotifyEvent하나의 프레임에 수백 개의 변수 업데이트가 포함될 수 있는 메시지입니다.
19.3 상태 머신 처리
2.0.1 버전의 트랜잭션 상태 머신은 1.6J 버전보다 더 경직되어 있습니다. 개발자는 전환 규칙을 엄격하게 준수해야 합니다.거래 이벤트예를 들어, 다음을 보낼 수 없습니다.끝났습니다먼저 메시지를 보내지 않고 이벤트를 진행하지 않은 경우시작됨해당 특정 이벤트거래 ID.
제20장: 테스트, 검증 및 OCPP 규정 준수 테스트 도구(OCTT)
OCPP의 핵심 약속은 상호 운용성이지만, 이는 엄격한 테스트를 통해서만 실현될 수 있습니다.
20.1 OCA 인증의 역할
Open Charge Alliance는 인증 프로그램을 제공합니다. 구매자는 "OCPP 2.0.1 Certified" 라벨을 확인해야 합니다. 이 인증은 해당 구현이 모든 필수 프로파일을 포괄하는 일련의 자동화 테스트를 통과했음을 보장합니다.
20.2 OCTT 사용
OCPP 규정 준수 테스트 도구(OCTT)는 테스트의 표준으로 인정받고 있습니다. 이 도구는 CSMS와 EVSE를 모두 시뮬레이션합니다.
- EVSE 제조업체를 위한 정보OCTT를 사용하여 스테이션이 정상적인 시나리오와 예외적인 상황(예: 펌웨어 업데이트 중 네트워크 끊김)을 제대로 처리하는지 확인하십시오.
- CSMS 제공업체용OCTT를 사용하여 백엔드가 2.0.1의 방대한 메시지 종류와 엄격한 보안 요구 사항을 처리할 수 있도록 하십시오.
20.3 현장 테스트 및 상호 운용성 테스트
OCA는 자동화 테스트 외에도 벤더들이 자사의 하드웨어와 소프트웨어를 가져와 실제 시나리오에서 서로 비교 테스트하는 "플러그페스트"를 개최합니다. 이를 통해 인증서 호환성 문제나 사소한 JSON 형식 차이와 같은 미묘한 버그까지 발견하고 해결할 수 있습니다.
제21장: 심층 비교표: OCPP 2.0.1의 60가지 이상의 기능
완전한 참조 자료를 제공하기 위해 2.0.1 버전의 주요 메시지를 분류하고 1.6J 버전의 해당 메시지와 비교합니다.
21.1 프로비저닝 및 구성
| 2.0.1 액션 | 1.6J 상당 | 기능 |
|---|---|---|
부트알림 | 부트알림 | CSMS에 등록하기. |
GetBaseReport | 구성 가져오기 | 구조화된 보고서 형식으로 장치의 전체 구성을 확인하세요. |
변수 설정 | 설정 구성 | 스키마 유효성 검사를 통해 구성 값을 변경하고 오류 발생 시 롤백합니다. |
변수 가져오기 | 구성 가져오기 | 형식화된 메타데이터를 사용하여 구성 및 모니터링 값을 읽습니다. |
보고서 데이터 | (없음) | CSMS에 주기적인 데이터 보고서(사용량, 구성 요소 상태, 이벤트)를 전송합니다. |
다시 놓기 | 다시 놓기 | 감사 추적을 위한 이유 코드를 사용하여 스테이션을 원격으로 재부팅합니다. |
21.2 거래 처리
| 2.0.1 액션 | 1.6J 상당 | 기능 |
|---|---|---|
거래 이벤트 | 거래 시작 / 거래 중지 | 사유 코드 및 중간 업데이트를 포함한 통합된 이벤트 기반 거래 보고 기능. |
거래 상태 가져오기 | (없음) | 재연결 또는 재시작 후 현재 트랜잭션 상태를 조회합니다. |
데이터 전송 | 데이터 전송 | 벤더별 확장 메시지가 이제 스키마 유효성 검사를 거칩니다. |
21.3 보안 및 펌웨어 관리
| 2.0.1 액션 | 1.6J 상당 | 기능 |
|---|---|---|
증명서 서명됨 | (없음) | CSMS에서 발급받은 서명된 인증서(TLS, ISO 15118)를 설치하십시오. |
서명 인증서 | (없음) | CSMS의 인증 기관에서 새 인증서에 서명하도록 요청하십시오. |
GetInstalledCertificateIds | (없음) | 감사 및 규정 준수 보고를 위해 설치된 인증서 목록을 표시합니다. |
펌웨어 업데이트 | 펌웨어 업데이트 | 예약된 펌웨어 업데이트와 상태 보고 및 롤백 신호 기능. |
21.4 표가 네트워크에 미치는 영향
이 표는 한 가지 사실을 명확히 보여줍니다. OCPP 2.0.1은 1.6J의 이름만 바꾼 버전이 아닙니다. 새로운 메시지 패밀리(타입 변수, 이벤트 기반 트랜잭션, 인증서 관리)는 플러그 앤 차지, 스마트 충전, 규제 보고에 필요한 핵심 요소입니다. 1.6J만 지원하는 충전기는 게이트웨이를 추가하여 개조할 수 있지만, 1.6J만 지원하는 CSMS(충전 관리 시스템)는 규제 기관과 자동차 제조업체가 점점 더 요구하는 보안 모델을 제공할 수 없습니다. 하드웨어를 평가할 때 "2.0.1 지원"이라는 것은 펌웨어가 내년 출시 예정이 아닌 현재 출시되어 있음을 의미합니다. 또한 OCPP 2.0.1은 1.6J의 SOAP 전송 방식이 아닌 JSON-over-WebSocket을 사용하기 때문에 메시지 흐름이 더 가볍고 디버깅이 훨씬 쉽습니다. 이는 IT 팀이 첫날부터 체감할 수 있는 실질적인 이점입니다.
제22장: 결론: 업그레이드 결정하기
상업 운영자에게 있어 실질적인 지침은 명확합니다.
- 새로운 배포 시에는 기본적으로 OCPP 2.0.1 버전을 사용해야 합니다.보안 모델, 인증서 처리 및 ISO 15118 통합은 2026년 규제 환경을 위한 필수 요건입니다.
- 기존 1.6J 엔진 탑재 차량들은 더 이상 운용할 필요가 없습니다.관리형 게이트웨이와 듀얼 프로토콜 CSMS 플랫폼은 2.0.1 네이티브 하드웨어를 단계적으로 도입하는 동안 발생하는 격차를 해소해 줍니다.
- 신뢰하기 전에 테스트해 보세요.OCTT, 플러그페스트, 단계적 출시를 활용하세요. 상호 운용성은 데이터시트에 명시되어 있는 것이 아니라 현장에서 입증된 것입니다.
- 이주 경로를 서면으로 요구하십시오.충전기 제조사는 1.6J부터 2.0.1까지의 펌웨어 로드맵을 구체적인 날짜와 함께 공개해야 하며, 막연한 약속만 해서는 안 됩니다.
행동 촉구: MIDA Power와 프로토콜 전략에 대해 상담하세요
MIDA Power ships OCPP 1.6J and 2.0.1 on every charger, with field-upgradeable firmware and a cloud platform that manages mixed-protocol fleets in a single dashboard. Contact sales@midapower.com for our protocol migration guide, OCTT test reports, and a free compatibility review of your existing network.
게시 시간: 2026년 8월 9일
휴대용 전기차 충전기
가정용 EV 월박스
DC 충전 스테이션
BESS 충전소
V2G V2H V2V V2L
전기차 충전 모듈
DC 충전 커넥터
전기차 액세서리