OpenCV를 이용하여 이미지 처리 및 웹 관련 에 관심있는 개발자

4 분 소요

M6에서 충전기용 이미지가 완성됐다. 빈 카드에 굽고 WiFi 접속 정보 한 줄만 넣으면 지금까지 시험한 기능이 모두 동작한다. 이미지에는 everest-core도 들어 있지만 아직 한 번도 실행하지 않았다. M7은 이 EVerest를 보드 위에서 돌리고, 충전기 하드웨어(CP 신호, 릴레이, 비상정지 입력)와 잇는 단계다.

목표 끝났다고 보는 기준
보드에서 EVerest가 실제 충전 하드웨어를 움직인다 저항 지그로 차량 연결 → 충전 → 해제를 흉내 냈을 때 EVerest가 CP PWM과 주 릴레이(K1)를 제어하고, 한 사이클이 이벤트 로그로 남는다

1. 지금까지 온 길

이정표 내용 날짜
M1~M4 TF-A(DDR) → OP-TEE → U-Boot → Linux 6.6 부팅 10/30
M5 주변장치 기능 시험 (GPIO, UART, I2C, ADC, PWM, PLC, USB, WiFi/BT, 워치독) 11/02~11/03
M6 Yocto 레이어로 정리, 충전기용 이미지, 새 카드 회귀 시험 11/04
M7 EVerest 보드 실행과 하드웨어 연동 11/05~

EVerest가 이 칩에서 돌 수 있는지는 10/29에 이미 한 번 확인했다. 옛 OS(MYiR Linux 5.4) 위에서 새 rootfs를 chroot로 돌려 시뮬레이터 충전 세션을 실행했다. 결과는 CPU 합계 31%(코어 1개 기준), 메모리 PSS 50MB였다. 이번에는 6.6 위에서, chroot가 아니라 이미지에 들어간 그대로 돌린다.

2. M7에서 하는 것과 하지 않는 것

한다 하지 않는다 (M8 이후)
EVerest 실행, CPU·메모리 실측 ISO 15118 (PLC로 차량과 고수준 통신, SLAC)
CP 상태 판정 기준 만들기 OCPP (충전기 관리 서버 연동)
보드 BSP 시제품 (CP PWM, CP 상태, K1, 비상정지·RCD) 기능 안전 설계 (CP 판정·차단을 M4 코어로 옮길지)
AC 없이 충전 한 사이클 AC 220V 인가 시험

AC 시험을 뺀 이유는 단순하다. K1이 켜지면 충전 출력 단자에 220V가 나간다. 이 시험은 안전 조치를 정하고 설계자와 함께 별도로 한다.

3. 일정

날짜 단계 할 일 끝났다고 보는 기준
11/05 (목) M7-1 EVerest 실행 이미지의 everest-core 버전·설정 위치 확인, 10/29 구성 그대로 실행, CPU·메모리 측정 시뮬레이터 충전 1회, 10/29 결과와 비교표
11/06 (금) M7-2 CP 기준표 저항 지그로 차량 상태 A/B/C, PWM 1kHz에서 상태별 AD_CP 측정 상태별 ADC 값 표와 판정 문턱값
11/09~10 (월·화) M7-3 BSP 시제품 EVerest evse_board_support 인터페이스 ↔ 보드 하드웨어 연결 EVerest 명령대로 PWM과 K1이 움직임
11/11~12 (수·목) M7-4 충전 흐름 보드용 EVerest 설정, 지그로 A→B→C→B→A, AC 없이 충전 한 사이클과 이벤트 로그
11/13 (금) 정리 레이어 반영, 서비스 자동 시작, 보류 항목 결정, 블로그 새 카드 부팅만으로 EVerest 실행

M7-3과 M7-4는 처음 해 보는 일이라 하루 이틀 밀릴 수 있다.

4. 단계별로 보는 것

4-1. M7-1: 같은 구성을 다시 돌리는 이유

10/29 측정과 같은 설정 파일로 돌린다. 바뀐 것을 OS 하나(5.4 chroot → 6.6 네이티브)로 묶어 두어야 숫자가 비교된다. 바로 확인할 것은 두 가지다.

  • 이미지에 든 everest-core 버전과 10/29 설정 파일이 맞는가. 모듈 이름이나 설정 키가 버전마다 바뀐다.
  • EVerest와 mosquitto가 부팅 때 어떤 순서로 뜨는가. 네트워크를 기다리는지도 본다(5절).

4-2. M7-2: CP를 먼저 재는 이유

충전기와 차량은 CP(Control Pilot) 선 하나로 기본 상태를 주고받는다. 충전기는 ±12V, 1kHz PWM을 내보낸다. 차량은 저항으로 High 쪽 전압을 끌어내려 자기 상태를 알린다(IEC 61851).

상태 차량 쪽 CP High 전압
A 연결 안 됨 +12V
B 연결됨, 충전 대기 +9V (2.7kΩ)
C 충전 요청 +6V (2.7kΩ ∥ 1.3kΩ)

보드에서는 이 전압이 절연 증폭기를 거쳐 ADC(AD_CP)로 들어온다. 11/02에는 PWM 0%와 100%에서만 값을 봤다. 상태 B와 C에서 ADC가 얼마인지는 아직 모른다. BSP가 상태를 판정하려면 이 표가 먼저 있어야 한다.

또 PWM이 켜진 동안에는 ADC가 High와 Low(-12V)를 섞어 읽는다. High 구간에서만 읽는 방법도 여기서 정한다. 리눅스 사용자 공간에서 될지, 타이머로 ADC를 트리거해야 할지가 관건이다.

4-3. M7-3: BSP는 MQTT 외부 모듈로 시작

EVerest에서 보드 하드웨어를 맡는 부분이 BSP 모듈이다. 하는 일은 이렇다.

EVerest → 보드 보드 → EVerest
pwm_on(duty) / pwm_off → CP PWM (pwmchip0) CP 상태 변화 이벤트 (A/B/C…)
allow_power_on → 주 릴레이 K1 비상정지(EM_INT), 누전(RCD_INT) → 오류 보고

구현 방법은 두 가지다.

방법 장점 단점
MQTT 외부 모듈 (EVerest 공개 API) EVerest를 다시 빌드하지 않음, 언어 자유, 빨리 고침 프로세스 하나 더, 지연이 조금 더
C++ EVerest 모듈 EVerest 안에서 동작, 배포가 깔끔 고칠 때마다 크로스 빌드

시제품은 MQTT 외부 모듈로 시작한다. CP 판정 기준이 아직 없어서 여러 번 고쳐야 하기 때문이다. 동작이 굳으면 C++ 모듈로 옮길지 정한다.

4-4. M7-4: AC 없이 충전 한 사이클

BSP, EvseManager, 인증 생략(모든 사용자 허용), 전력량계를 묶은 보드용 설정을 만든다. 저항 지그의 스위치로 차량 동작을 흉내 낸다.

A(연결 없음) → B(꽂음) → PWM 시작 → C(충전 요청) → K1 ON
            → B(충전 중지) → K1 OFF → A(뽑음) → PWM 끔

릴레이는 딸깍 소리와 LED로 확인한다. 전력량계는 JSY-MK-163T 레지스터 표를 구하면 실제 장치를 붙이고, 못 구하면 가상 전력량계로 진행한다.

5. M6에서 넘어온 보류 항목

항목 M7에서 다루는 이유
네트워크 없이 부팅하면 wait-online이 2분 대기 후 degraded EVerest와 mosquitto가 network-online을 기다리는지 보고 정책을 정한다. 충전기는 네트워크 없이도 충전돼야 한다
블루투스 자동 켜기 (main.conf 없음) 한 줄짜리 수정이라 M7 정리 때 같이 할 수 있다
전력량계 레지스터 의미 EVerest 전력량계 설정에 필요

첫 부팅 유선 이더넷 문제(YT8511 절전 추정), TF-A 디버그 출력, OLDEST_KERNEL은 제품 빌드를 정리할 때로 미룬다.

6. 시작 전에 준비할 것

준비물 / 결정 필요한 시점
CP 저항 지그 (2.7kΩ + 다이오드, 1.3kΩ, 스위치 2개) 또는 EV 시뮬레이터 장비 11/06 M7-2
BSP 구현 방식 (제안: MQTT 외부 모듈로 시작) 11/09 M7-3
JSY-MK-163T 데이터시트 (레지스터 표) 11/11 M7-4 (없으면 가상 전력량계)
AC 인가 시험의 안전 조치와 일정 M7 이후

위험 요소

  • CP를 정확한 시점에 읽기: 리눅스 사용자 공간의 타이밍으로 PWM High 구간을 맞추기 어려울 수 있다. 그러면 ADC 하드웨어 트리거(타이머 연동)를 DTS와 드라이버에서 다시 봐야 한다.
  • EVerest 버전 차이: WSL에서 SIL을 만든 버전(2026.10 계열)과 이미지의 meta-everest 버전이 다르면, 설정 파일을 고쳐야 한다.
  • CPU 여유: 10/29 측정은 시뮬레이터 구성이었다. 실제 BSP와 전력량계 통신이 붙으면 다시 재야 한다.

댓글남기기

참고