충전기 장애 진단하기
들어가는 말
“일단 재부팅해보자”, “현장에 가서 확인해보자”, “릴레이 문제일 수 있다”는 식의 CS 대응은 초기 운영 단계에서는 가능하지만, 충전기 대수가 늘어나면 빠르게 한계에 부딪힙니다. 현장 출동 비용은 증가하고, 엔지니어링팀은 재현하기 어려운 장애를 추적해야 하며, 운영팀은 사용자에게 정확한 원인을 설명하기 어렵습니다.
서비스 품질을 높이고 운영 리소스를 최적화하기 위해서는 충전기 상태를 원격에서 가시화하고, 문제를 사전에 파악할 수 있는 진단 환경이 필요합니다. 단순히 장애가 발생했는지 아는 것을 넘어, 장애가 어느 단계에서 발생했는지 좁혀갈 수 있어야 합니다.
이 글에서는 데이터 기반의 정량적 분석을 통해 매출에 즉각적인 영향을 주는 한편, 사용자 평판에도 큰 타격을 주는 충전 시작 실패와 충전 중단 문제를 어떻게 분석하고 운영팀과 엔지니어링팀에 인사이트를 제공할 수 있는지 설명합니다.
사례: 충전 시작 실패와 충전 중단
충전 시작 실패는 운영 난이도가 높은 문제입니다. "충전이 시작되지 않는다"는 일반적인 증상은 사용자에게는 하나의 문제처럼 보이지만, 실제로는 여러 단계에서 발생할 수 있는 다양한 원인들이 존재합니다.
- 차량이 전기적으로 감지되지 않음
- 충전기가 정상 PWM duty/frequency를 제공하지 못함
- CP 측정값이 경계값 근처에서 흔들림
- ADC 보정 또는 측정 오류로 CP 상태 판별이 불안정함
- 충전 준비 상태에 도달했지만 릴레이가 동작하지 않음
- 릴레이는 닫혔지만 실제 전류가 흐르지 않음
- CSMS 통신 문제로 인증 또는 세션 시작이 지연됨
- 충전 중 차량 또는 충전기가 세션을 중단함
- 온도 또는 계량기 문제로 충전이 제한됨
이 문제를 구분하기 위해 CP(Control Pilot) 상태를 핵심 진단 지표로 사용했습니다.
CP는 차량과 충전기가 충전 가능 여부를 판단하기 위해 주고받는 기본 제어 신호입니다. CP 상태를 보면 차량이 연결됐는지, 차량이 충전 준비 상태까지 도달했는지, 충전기가 정상적인 PWM 신호를 제공하고 있는지 확인할 수 있습니다.
CP 상태를 데이터화하면 충전 실패가 차량 연결 이전의 문제인지, 충전 준비 단계의 문제인지, 혹은 CP 이후 전력 전달 단계의 문제인지 빠르게 구분할 수 있습니다. 즉, 막연한 추측이 아니라 원인 후보를 단계적으로 줄여갈 수 있는 근거가 생깁니다.
다만 CP가 모든 원인을 확정해주는 것은 아닙니다. CP는 원인 후보를 빠르게 줄여주는 1차 진단축입니다. 실제 운영에서는 CP뿐 아니라 릴레이, 계량기, ADC, 온도, CSMS 연결성 지표를 함께 봐야 합니다.
무엇을 수집했나
다음 질문에 즉각적으로 대답할 수 있도록 지표를 설계하고 수집했습니다.
- 사용자가 실제로 커넥터를 꽂았는가?
- 차량이 충전 준비 상태까지 도달했는가?
- 충전기가 규격에 맞는 PWM duty/frequency를 제공했는가?
- CP 측정값이 신뢰할 수 있는가?
- 상태 전이가 반복적으로 흔들리는가?
- CP 전압이 정상 범위를 벗어나는가?
- 온도 조건 때문에 충전이 제한되거나 중단됐는가?
- CSMS 통신 문제로 인증 또는 세션 시작이 지연되고 있지는 않은가?
이를 위해 충전기에서는 다음과 같은 CP 관련 지표를 수집합니다.
CP 상태 및 신호 지표
| 지표 | 의미 | 운영상 해석 |
|---|---|---|
PilotStatus |
현재 CP 상태 | 차량 미연결, 차량 연결, 충전 준비, fault 상태 구분 |
PilotMilliVolts |
측정된 CP 전압값 | 상태 판별 안정성, 전압 이상, 보정 문제 확인 |
PilotDutyPct |
CP PWM duty 비율 | 차량에 광고한 허용 전류 수준 확인 |
PilotFrequency |
CP PWM 주파수 | PWM 생성, 타이머, 펌웨어 이상 확인 |
PilotMeasureCount |
CP 측정 횟수 | 측정 신뢰도와 비율 계산의 분모 |
PilotDutyErrorCount |
duty 계산 또는 판별 오류 횟수 | duty 측정/계산 이상 가능성 |
PilotBoundaryValueCount |
경계값 근처 측정 횟수 | A/B/C 상태 판별이 흔들릴 가능성 |
PilotAnomalyCount |
CP 이상 패턴 횟수 | 신호 품질 저하 또는 비정상 상태 |
PilotOutlierCount |
이상치 측정 횟수 | 노이즈, 접촉 불량, ADC 불안정 가능성 |
이 지표들은 다음 질문에 대한 답을 제공할 수 있습니다:
- 차량이 연결됐는가?
- 차량이 충전 준비 상태까지 도달했는가?
- 충전기가 정상 duty를 광고했는가?
- PWM frequency가 정상 범위에 있는가?
- CP 신호가 경계값 근처에서 흔들리는가?
CP 측정 품질 지표
| 지표 | 의미 | 운영상 해석 |
|---|---|---|
PilotMeasureTimeMax |
CP 측정에 걸린 최대 시간 | 측정 루틴 지연, MCU 부하 가능성 |
PilotMeasureTimeMin |
CP 측정에 걸린 최소 시간 | 측정 시간 분포 기준 |
PilotIntervalMax |
CP 측정 간격의 최대값 | 측정 주기 지연, scheduler 문제 가능성 |
PilotIntervalMin |
CP 측정 간격의 최소값 | 측정 주기 안정성 확인 |
PilotOverrunCount |
측정 루틴 overrun 횟수 | 실시간성 저하, 태스크 부하, 펌웨어 문제 |
PilotReadErrorCount |
CP read 실패 횟수 | 측정 경로 또는 ADC read 문제 가능성 |
이 지표들은 CP 신호 자체보다 CP를 제대로 측정하고 있는지를 설명합니다. CP 값이 이상할 때 원인은 두 가지일 수 있기 때문에 이 구분은 중요합니다.
- 실제 CP 신호가 이상함
- CP 측정 로직이나 ADC 측정값이 이상함
예를 들어 다음 패턴은 커넥터보다 측정 로직 또는 펌웨어 스케줄링 문제를 먼저 의심해야 합니다.
- PilotOverrunCount 증가
- PilotReadErrorCount 증가
- PilotMeasureTimeMax 증가
- PilotIntervalMax 증가
반대로 측정 품질 지표는 정상인데 PilotBoundaryValueCount와 PilotOutlierCount만 특정 충전기에서 반복적으로 높다면, CP 라인, 커넥터, 접지, 회로 편차를 우선 봐야 합니다.
CSMS / 네트워크 연결성 지표
| 지표 | 의미 | 운영상 해석 |
|---|---|---|
CSMSDowntime |
CSMS와의 연결 불가 또는 비정상 연결 지속 시간 | 충전기가 백엔드와 정상 통신하지 못한 시간 |
PingFailureCount |
ping 실패 횟수 | 네트워크 reachability 저하, 회선 불안정 가능성 |
PingTimeMax |
ping 응답 시간 최대값 | latency spike, 회선 품질 저하 가능성 |
PingTimeMin |
ping 응답 시간 최소값 | 정상 조건에서의 baseline latency |
충전기는 차량 연결과 충전 준비 상태를 확인한 뒤에도 CSMS와 통신해야 합니다. OCPP는 charge point와 central system 사이의 통신을 표준화하기 위한 프로토콜이며, 실제 운영에서는 인증, 세션, 상태관리, 원격 제어 등 여러 흐름이 CSMS 연결성에 의존합니다.
따라서 CP가 정상이어도 CSMS 연결성이 나쁘면 사용자는 동일하게 “충전이 시작되지 않는다”고 느낄 수 있습니다.
릴레이 동작 지표
| 지표 | 의미 | 운영상 해석 |
|---|---|---|
RelayPickupCount |
릴레이 pickup 동작 횟수 | 릴레이를 닫기 위한 초기 구동 시도 |
RelayHoldCount |
릴레이 hold 동작 횟수 | 릴레이 유지 동작 |
RelayOffCount |
릴레이 off 동작 횟수 | 릴레이 차단 동작 |
RelayPickupDuty |
pickup 시 구동 duty | 릴레이 초기 구동 강도 |
RelayHoldDuty |
hold 시 구동 duty | 릴레이 유지 구동 강도 |
릴레이 지표는 CP 이후 단계의 진단에 중요합니다.
CP가 C 상태에 도달했다면 차량은 충전 준비 상태입니다. 하지만 실제 충전이 시작되려면 릴레이가 정상적으로 pickup되고 hold 상태로 유지되어야 합니다.
예를 들어 다음 두 상황은 완전히 다른 케이스입니다:
PilotStatus = C
RelayPickupCount 변화 없음
MeterEnergyDeltaAccumulated = 0
이 경우는 차량이 준비됐지만 릴레이 제어 단계로 가지 못한 것입니다. 인증, CSMS 제어 조건, 상태머신, 릴레이 제어 로직을 봐야 합니다.
PilotStatus = C
RelayPickupCount 증가
RelayHoldCount 증가
MeterEnergyDeltaAccumulated = 0
반면, 이 경우는 릴레이는 동작했지만 실제 에너지 전달이 발생하지 않은 것입니다. 릴레이 접점, 출력 경로, 차량 OBC, 계량기 측정 문제를 확인해야 합니다.
상태별 카운터
| 지표 | 의미 | 운영상 해석 |
|---|---|---|
ChargerStateACount |
보고 주기 내 A 상태로 진입한 횟수 | 차량 미연결 상태로 복귀, 연결 해제 |
ChargerStateBCount |
보고 주기 내 B 상태로 진입한 횟수 | 차량 연결 인식, 재연결, C→B 복귀, 사용자 재시도 가능성 |
ChargerStateCCount |
보고 주기 내 C 상태로 진입한 횟수 | 차량이 충전 준비 상태에 도달한 이벤트 |
ChargerStateDCount |
보고 주기 내 D 상태로 진입한 횟수 | 환기 필요 상태 진입, 일반 운영에서는 예외적 |
ChargerStateECount |
보고 주기 내 E 상태로 진입한 횟수 | CP fault 계열 상태 진입 |
ChargerStateFCount |
보고 주기 내 F 상태로 진입한 횟수 | EVSE fault 상태 진입 |
이 값은 두 가지 방식으로 사용됩니다.
- 상태 점유 비율을 계산합니다.
- 충전 시도와 충전 실패 유형을 추정하는 간접 지표(proxy)로 사용합니다.
보고 주기 내 전체 상태 관측 수는 다음과 같이 계산됩니다:
State Sample Total = ChargerStateACount + ChargerStateBCount ChargerStateCCount ChargerStateDCount ChargerStateECount ChargerStateFCount
이를 기준으로 각 상태 비중을 계산할 수 있습니다:
State Ratio = ChargerStateXCount / State Sample Total
이 비율은 상태 체류 비율이 아닙니다. 이 값은 보고 주기 내 상태 진입 이벤트 중 어떤 상태로의 진입이 많았는지를 보여줍니다.
예를 들어 B 진입 이벤트가 많다면 다음 가능성을 생각할 수 있습니다:
- 차량 연결 인식이 반복됨
- 사용자가 여러 번 연결을 시도함
- A↔B 상태가 흔들림
- CP 신호가 경계값 근처에서 흔들림
ADC 오류 지표
| 지표 | 의미 | 운영상 해석 |
|---|---|---|
ADCErrorPipe |
ADC pipeline 오류 | ADC 처리 경로 문제 |
ADCErrorConversion |
ADC conversion 오류 | 변환 실패 또는 드라이버 문제 |
ADCErrorRead |
ADC read 오류 | ADC 데이터 읽기 실패 |
ADCErrorParam |
ADC parameter 오류 | 설정값 또는 호출 파라미터 문제 |
ADCErrorCalibration |
ADC calibration 오류 | 보정값 적용 또는 보정 데이터 문제 |
ADCErrorSequence |
ADC sequence 오류 | 측정 순서/시퀀스 문제 |
ADCError |
ADC 일반 오류 | ADC 계층 오류 총괄 |
운영자가 흔히 하는 실수는 PilotMilliVolts가 이상할 때 곧바로 CP 회로 문제나 커넥터 문제로 보는 것입니다. 하지만 ADC 오류가 동시에 증가한다면 실제 신호가 아니라 측정 계층의 문제일 수 있습니다.
예를 들어 다음 패턴은 ADC 보정 또는 측정 경로 문제 가능성이 큽니다.
- PilotBoundaryValueCount 증가
- PilotOutlierCount 증가
- ADCErrorCalibration 증가
- ADCErrorConversion 증가
반대로 ADC 오류는 없는데 특정 충전기에서만 PilotAnomalyCount와 ChargerStateECount가 반복된다면 CP 회로, 커넥터, 접지, 차량과의 상호작용을 우선 봐야 합니다.
온도 지표
| 지표 | 의미 | 운영상 해석 |
|---|---|---|
TemperatureWarningCount |
온도 warning 횟수 | 열적 위험 증가 |
TemperatureErrorCount |
온도 error 횟수 | 보호 동작 또는 충전 중단 가능성 |
TemperatureMax |
최대 온도 | 설치 환경, 냉각, 부품 열화 가능성 |
TemperatureSampleIntervalMax |
온도 샘플링 간격 최대값 | 온도 측정 지연 또는 태스크 문제 |
충전 중단은 CP만으로 설명하면 안 됩니다. CP와 릴레이, 계량기가 정상이어도 온도 warning/error가 증가하면 열 보호 또는 설치 환경 문제가 원인일 수 있습니다.
운영팀이 얻는 인사이트
운영팀에게 필요한 것은 raw metric이 아닙니다. 운영팀은 “그래서 지금 무엇을 해야 하는가?”를 알아야 합니다.
예를 들어 다음과 같은 형태의 일간 리포트를 만들 수 있습니다.
Daily CP Operations Report
전체 충전 시도: 8,420건
CP 관련 의심 실패: 276건 (3.3%)
주요 실패 유형:
1. B-state stall: 112건
2. Charge ready but no current: 84건
3. CP flapping: 51건
4. PWM abnormal: 21건
5. E/F fault: 8건
우선 조치 대상:
- CHG-1023: C 상태에서 전류 0 반복 → 릴레이/출력/CT 점검 필요
- CHG-1182: A/B flapping 상위 → 커넥터 접촉 상태 점검 필요
- CHG-2041: B-state stall 증가 → PWM/차량 호환성/펌웨어 확인 필요
이런 보고가 가능해지면 현장 출동 방식도 달라집니다. 무작정 방문하는 것이 아니라, 어떤 부품과 어떤 로그를 확인해야 하는지 미리 정한 상태로 출동할 수 있습니다.
엔지니어링팀이 얻는 보고서
엔지니어링팀은 운영팀과 다른 질문을 합니다.
운영팀은 “어느 충전기를 먼저 봐야 하는가?”를 묻습니다. 엔지니어링팀은 “이 문제가 제품 문제인가, 환경 문제인가, 특정 버전 문제인가?”를 봐야 합니다.
따라서 엔지니어링 리포트는 충전기 단위뿐 아니라 펌웨어, 하드웨어 리비전, 사이트, 설치 기간별로 나눠야 합니다.
예시는 다음과 같습니다.
Weekly CP Engineering Report
1. Firmware Regression
- v1.8.3 배포 이후 PWM abnormal rate가 0.2% → 1.9%로 증가
- 동일 사이트의 이전 버전 충전기에서는 증가 없음
- PWM 타이머 또는 duty 계산 로직 regression 가능성
2. Hardware Revision
- HW rev.B에서 cp_voltage_out_of_range rate가 rev.A 대비 2.4배 높음
- A/B/C 모든 상태에서 전압이 일정 비율로 낮게 측정됨
- ADC 보정 테이블 또는 분압 회로 편차 확인 필요
3. Site Pattern
- Site-17에서 CP flapping rate가 전체 평균 대비 3.1배 높음
- 동일 펌웨어/하드웨어의 다른 사이트에서는 정상
- 접지, 전원 노이즈, 커넥터 사용 환경 확인 필요
4. Charger Aging
- 설치 후 18개월 이상 충전기에서 A/B flapping 증가
- 커넥터 접점 마모 또는 케이블 스트레스 가능성
이 보고서는 단순 장애 대응을 넘어 제품 개선으로 연결됩니다. 특정 보드 리비전의 CP 전압 편차, 특정 펌웨어 버전의 PWM 이상, 설치 기간에 따른 커넥터 접촉 문제를 조기에 발견할 수 있기 때문입니다.
나가는 말
전기차 충전기 운영에서 충전 시작 실패와 충전 중단은 매출과 사용자 경험에 직접적인 영향을 주는 문제입니다. 하지만 사용자 신고만으로는 원인을 특정하기 어렵습니다. 같은 “충전이 안 된다”는 증상 뒤에는 커넥터 접촉 문제, CP 신호 이상, 차량 준비 실패, PWM 광고 문제, 릴레이 제어 문제, 출력 경로 문제 등 여러 가능성이 숨어 있습니다.
충전기 운영 규모가 커질수록 중요한 것은 더 많은 현장 확인이 아니라, 현장에 가기 전에 무엇을 확인해야 하는지 아는 것입니다. CP 기반 진단은 그 출발점입니다.
파직은 Pulse를 통해 이 지표들을 수집하고, 충전 실패를 추측의 영역에서 계측 가능한 운영 문제로 바꾸고 있습니다.