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

5 분 소요

어제(11/04) BSP 첫 버전은 EVerest 없이 시험했다. EVerest가 보낼 명령을 mosquitto_pub으로 흉내 냈다. 오늘은 그 자리에 실제 EVerest(EvseManager) 를 넣었다. 차량은 여전히 저항 지그이고, AC는 연결하지 않았다.

항목 결과
작업물 보관 레이어 meta-sc6, 작업 기록 sc6-work를 GitHub 비공개 저장소로. 독점 펌웨어는 이력에서 제거
보드용 EVerest 구성 모듈 4개 (BSP API, EvseManager, EnergyNode, EnergyManager)
첫 실행 BSP 버그 1개 발견·수정 (enable 뒤 CP 상태)
충전 한 사이클 A → B → C → B → A, 두 번 통과. K1 딸깍 확인

1. 먼저, 작업물 보관

지금까지 코드는 WSL 한 곳에만 있었다. 레이어는 git이었지만 원격 저장소가 없었다. 빌드 스크립트와 보드 시험 스크립트는 git도 아니었고, 블로그 글은 세션 임시 폴더에 있었다. GitHub 비공개 저장소 두 개로 나눴다.

저장소 내용
meta-sc6 Yocto 레이어 (머신, DTS 4종, 레시피, BSP)
sc6-work 빌드·분석 스크립트, 보드 시험 스크립트, 가이드 문서, 블로그 글

1-1. 독점 펌웨어는 이력에서 빼기

레이어에는 외부 업체 파일이 네 개 있었다. Qualcomm QCA7005의 펌웨어(.nvm)와 설정(.pib), AP6212 모듈의 nvram과 BT 패치(.hcd)다. 비공개 저장소라도 외부 클라우드에 올리는 것은 피하기로 했다. 지금 파일만 지우면 이전 커밋에는 그대로 남는다. 그래서 복제본에서 전체 이력을 다시 썼다.

git clone ~/work/meta-sc6 ~/work/repo/meta-sc6     # 원본은 건드리지 않는다
cd ~/work/repo/meta-sc6
git filter-branch --index-filter "git rm --cached --ignore-unmatch <펌웨어 4개>" --prune-empty -- --all
git reflog expire --expire=now --all && git gc --prune=now --aggressive

커밋 18개는 그대로 남았고, 이력 어디에도 펌웨어가 없다. .git은 2.2 MB에서 244 KB로 줄었다. 대신 커밋 해시가 모두 바뀐다. 원본 저장소는 백업으로 따로 두었다.

펌웨어는 레이어 옆 폴더에 두고, 레시피가 그쪽을 찾게 했다.

# conf/layer.conf
SC6_LAYERDIR := "${LAYERDIR}"
SC6_PROPRIETARY_DIR ?= "${SC6_LAYERDIR}/../sc6-proprietary"

# recipes-bsp/qca7005-fw/qca7005-fw.bb, recipes-bsp/sc6-firmware/sc6-firmware.bb
FILESEXTRAPATHS:prepend := "${SC6_PROPRIETARY_DIR}/${PN}:"

SRC_URI의 file:// 이름은 그대로 두고 찾는 경로만 늘렸다. 두 레시피를 처음부터 다시 빌드해 패키지 안 펌웨어의 md5가 원본과 같은 것을 확인했다.

1-2. 옮기다 생긴 일 두 가지

경로: 스크립트 폴더(~/work/sc6-dt)를 새 저장소 안으로 옮기고, 옛 경로에는 심볼릭 링크를 남겼다. 기존 명령이 그대로 돈다.

“변경됨” 표시: Windows 쪽 git 도구로 저장소를 열자 문서와 블로그 글 28개가 전부 “변경됨”으로 보였다. 내용은 같았다. Windows 폴더(/mnt/c)에서 복사해 오면서 WSL이 파일마다 실행 비트(755)를 붙였고, 그대로 커밋됐다. Windows 도구는 \\wsl.localhost 경로에서 실행 비트를 읽지 못하니 “커밋은 755, 지금은 644”로 본 것이다. 권한을 644로 고치고, 두 저장소에 core.filemode false를 설정했다.

이 과정에서 같은 저장소를 Windows 도구와 WSL 양쪽에서 커밋하는 일이 한 번 생겼다. 서로 모르는 사이에 이력이 섞이니, 커밋은 한쪽(WSL)에서만 하기로 했다.

2. 보드용 EVerest 구성

10/29 실측에 쓴 SIL 구성에는 가상 차량, 가상 BSP(YetiSimulator), ISO 15118, SLAC, Node-RED API까지 다 들어 있다. 실제 하드웨어 시험에 필요한 것만 남겼다.

EvseManager ── evse_board_support_API (bsp_1) ══MQTT══ sc6-bsp ── CP PWM / CP ADC / K1
     └── EnergyNode (32A, 단상) ── EnergyManager

connector_1:
  module: EvseManager
  config_module:
    charge_mode: AC
    ac_hlc_enabled: false
    has_ventilation: false        # 상태 D 는 오류
    disable_authentication: true  # 인증 생략
  connections:
    bsp:
      - module_id: bsp_1
        implementation_id: main
모듈 넣은 이유
evse_board_support_API (bsp_1) 우리 BSP와 MQTT로 잇는 EVerest 쪽 창구
EvseManager 충전 흐름 (IEC 61851 상태 기계)
EnergyNode + EnergyManager 충전 전류 한도 계산. 이게 없으면 EvseManager가 PWM을 시작하지 않는다

EvseManager 설정에 disable_authentication이 있어서 인증 모듈(Auth, 토큰 제공·검증)도 뺐다. 전력량계도 연결이 필수가 아니라서 이번에는 넣지 않았다. 대신 충전량(kWh)은 기록되지 않는다.

모듈별 필수·선택 연결은 각 모듈의 manifest.yaml로 확인했다. 그런데 아침에 빌드 PC가 꺼져 있어서 패키지를 열어 볼 수 없었다. 그래서 WSL에 받아 둔 EVerest 소스(2026.10 계열)의 manifest를 읽었다.

3. 첫 실행: BSP가 기다리고, EVerest도 기다리고

EVerest는 0.6초 만에 떴고, BSP도 MQTT로 붙었다. 그런데 거기서 멈췄다.

09:36:34.818 sc6-bsp: 안전 상태: K1 OFF, CP F (시작)
09:36:43.473 sc6-bsp: ← enable true
             (그 뒤로 CP 상태 보고가 없음)
  생각한 것 실제
BSP enable 다음에 EVerest가 cp_state_X1을 보내 줄 것 enable만 오고 X1은 오지 않음
EvseManager — BSP가 상태 A 를 보고하기를 기다림

BSP는 시작할 때 안전 상태로 CP를 F(-12V)에 둔다. -12V를 내보내는 동안에는 차량 쪽 저항이 보이지 않으니 상태를 판정할 수 없다. EVerest는 A 보고를 기다리고, BSP는 X1 명령을 기다리는 교착이었다.

API 명세의 enable 설명은 “비활성화하면 보통 CP 상태 F”뿐이다. 거꾸로 읽으면, 활성화되면 BSP가 스스로 사용 가능 상태(X1, +12V)로 돌아가야 한다. 어제 시험에서는 내가 enable 다음에 cp_state_X1을 직접 보내서 이 구멍이 가려졌다.

} else if (mode == MODE_F) {
	/* 사용 가능 = CP X1(+12V). EvseManager 는 enable 뒤 따로 X1 을 보내지 않고
	 * BSP 가 보고하는 CP 상태(A)를 기다린다 */
	cp_output(MODE_X1, 100);
}

고친 뒤에는 이렇게 흘렀다.

09:43:04.127  BSP: CP - -> A (+12.01V)  → EVerest
09:43:04.149  EVerest → BSP: cp_state_X1
09:43:04.158  EVerest → BSP: allow_power_on false   (대기)

커넥터 종류 이름이 둘

첫 실행에는 경고도 하나 있었다.

[WARN] connector_1:Evs  :: Unknown/invalid connector type: IEC62196Type2Cable

같은 “Type 2 케이블 일체형”을 EVerest 안에서 두 가지 이름으로 부른다.

쓰는 곳 이름
BSP가 보내는 하드웨어 정보 (capabilities) IEC62196Type2Cable
EvseManager 설정 (ConnectorTypeEnum) cType2 (소켓은 sType2, Type 1은 cType1)

BSP 쪽 값을 그대로 EvseManager에 넣어서 생긴 경고다. 정하다 보니 더 큰 질문이 나왔다. 국내 완속충전기는 대부분 Type 1(J1772) 이다. 커넥터는 아직 정하지 않았으니 EvseManager 값은 Unknown으로 두었다. CP 신호는 Type 1과 Type 2가 같아서 이번 시험에는 영향이 없다.

4. 충전 한 사이클

이번에는 명령을 하나도 보내지 않았다. 지그 스위치만 바꾸고 나머지는 EVerest가 했다.

시각 지그 BSP EVerest
17.796 A → B CP A -> B (+8.96V) 세션 시작, 인증 생략 → PrepareCharging
17.841   PWM 53.3% (BSP 에 pwm_on)
23.432 B → C CP B -> C (+6.00V, PWM 중 20/40 샘플) Charging
23.443   K1 ON allow_power_on: true
25.712 C → B K1 OFF (스스로)  
25.740   CP C -> B 보고  
25.744     allow_power_on: false → Car Paused
27.152 B → A CP B -> A → Finished, 세션 종료

볼 만한 숫자가 세 개 있다.

  1. PWM 53.3%: 32A ÷ 0.6 = 53.3%. BSP가 하드웨어 정보로 알린 최대 32A를 EVerest가 받아 듀티를 계산했다. B 보고에서 PWM 시작까지 45 ms가 걸렸다.
  2. C 보고 → K1 ON 11 ms: EVerest가 C를 받고 허가를 보내 BSP가 릴레이를 켜기까지의 왕복 시간이다.
  3. K1 OFF가 EVerest보다 32 ms 먼저: BSP는 C가 아닌 값이 처음 읽힌 순간 스스로 K1을 끊었다. 상태 보고(3회 연속 확인)와 EVerest의 차단 명령은 그 뒤에 왔다. 어제 정한 “켜기는 여러 번 확인, 끄기는 즉시” 규칙이 실제 EVerest와 함께 돌 때도 그대로 동작했다.

충전 중 B로 돌아가는 것은 규격상 차량이 충전을 일시 중지한 것이다. 그래서 세션이 끝나지 않고 Car Paused가 됐다. 이때 EVerest는 PWM을 끄고 CP를 X1(+12V 고정)으로 바꿨다. 케이블을 뽑자(A) 세션이 끝났다. 사이클을 한 번 더 돌려도 같았고, K1이 딸깍 붙고 떨어지는 것도 확인했다.

5. 정리

커밋

meta-sc6  fcbd8cb M7-4: sc6-bsp - enable 을 받으면 CP 를 X1(+12V) 로
          dc23ae9 README: ...
          90b4f60 독점 펌웨어를 레이어 저장소 밖(SC6_PROPRIETARY_DIR)으로
sc6-work  0bbc5e7 M7-4: 보드용 EVerest 구성(config-sc6-bsp.yaml)과 실행 스크립트(run-m7-bsp.sh)

오늘 배운 것

  1. 흉내 낸 시험은 내 가정까지 흉내 낸다. 어제는 내가 EVerest 역할을 하면서 “enable 다음엔 X1이 온다”는 내 가정대로 명령을 보냈다. 실제 EVerest를 붙이자 바로 드러났다.
  2. 서로 기다리는 교착은 로그가 조용하다. 오류 한 줄 없이 멈춰 있었다. 마지막으로 오간 메시지가 무엇이고, 다음에 누가 무엇을 보내야 하는지를 따라가야 보인다.
  3. 같은 개념에 이름이 둘일 수 있다. 커넥터 종류는 BSP API와 EvseManager 설정이 다른 목록을 쓴다. 경고가 나오면 값보다 “어느 목록인가”를 먼저 보자.
  4. 이력은 지워야 지워진다. 파일을 지우는 커밋만으로는 이전 커밋에 남는다. 올리기 전에 정리하고, 원본은 백업해 두자.
  5. 한 저장소는 한 곳에서 커밋하자. Windows 도구와 WSL을 섞으면 서로 모르는 커밋이 생긴다.

다음 할 일

순서 할 일
M7-5 비상정지(EM_INT)·누전(RCD_INT) 입력 극성 시험 → BSP 오류 보고 (MREC8EmergencyStop, MREC2GroundFailure)
M7-6 sc6-bsp 서비스, EVerest 자동 시작, 이미지 반영, 새 카드 확인
결정 대기 충전 커넥터 종류 (케이블/소켓, Type 1/2), 최대 전류, 전력량계 레지스터 표

댓글남기기

참고