¶ 기존 BMS 콘솔 시스템 구성 분석보고서
프로젝트: Seoul Metro Battery Management
원본 상대경로:outputs/customer-data-analysis/기존_BMS_콘솔_시스템_구성_분석보고서.md
형식:MD
분류:분석 산출물
추출 방식:text
동기화:2026-06-29 09:51:06
¶ 원본 위치
outputs/customer-data-analysis/기존_BMS_콘솔_시스템_구성_분석보고서.md
¶ 처리 메모
- 없음
¶ 본문
¶ 기존 BMS 콘솔·운영 PC·현장 시스템 구성 분석 보고서
- 작성일: 2026-06-25
- 대상 독자: 서울교통공사 민관협력 PoC 기획자, 현장 실사 담당자, BMS 데이터 분석 담당자
- 분석 대상:
Docs/고객 기존 데이터/모터카 정비교범외문서군, 축전지/BMS 승인원·사양서, 운영 PC 사양서, 창동3호 BMS 저장파일 파싱 결과
¶ 1. 분석 목적
본 보고서는 정비교범, 운용 교범, 축전지/BMS 승인원, 운영 PC 사양서를 근거로 기존 차량의 BMS 관련 콘솔 또는 현장 시스템이 어떤 계층으로 구성되어 있는지 정리한다. 특히 “콘솔”을 중앙 관제 시스템으로 단정하지 않고, 문서에서 확인되는 차량컴퓨터, 조작판, 경고등, 판넬PC, 운영 PC, 로컬 로그 파일의 관계를 구분한다.
¶ 2. 결론 요약
| 영역 | 현재 문서상 판단 | PoC 설계상 의미 |
|---|---|---|
| 시스템 형태 | 기존 BMS는 차량 내부 배터리 팩과 Master/Slave BMS를 중심으로 구성되고, 상태정보가 차량컴퓨터 또는 VCU 계층으로 전달된다. | 분석 시스템은 기존 BMS를 교체하거나 제어하지 않고, 차량컴퓨터/운영 PC에 이미 올라온 데이터를 읽는 방식이 우선이다. |
| 운전자 표시 계층 | 저전압 경고등, 잔량 확인 장치, 전압계, 발광 Diode, 계기판 경보 등이 반복적으로 언급된다. | 현장 사용자는 세부 셀 데이터보다 알람, 잔량, 운행 가능 여부 중심으로 상태를 인지한다. |
| 판넬PC/운영 PC | 2019 궤도모터카 교범에는 판넬PC가 알람 상세 표시와 운전조작/알람 로깅을 수행한다고 명시된다. 차량군별 PC 모델은 EPC104-N, UNO-2372G, ARK-2121F, UNO-2473G, EPC70-J, ARK-1123H 계열로 혼재한다. | 단일 배포 방식보다 차량군별 OS, 포트, 저장 경로, 계정 권한, 기존 프로그램 점유 상태를 먼저 실사해야 한다. |
| 화면 기반 운용 기능 | 2022.12 운전자 매뉴얼의 차량정보 상태모니터에는 메인 대시보드, 상태알림 및 경고/알람 상세, BMS 상세정보 버튼, 저장폴더 운행 데이터 확인, USB 백업 기능이 명시된다. 2024.10 문서도 차량정보 상태모니터가 운전·알람 로그를 기록한다고 설명한다. |
To-Be 시스템은 단순 파일 파서가 아니라 기존 화면의 운전자 워크플로를 계승하는 대시보드, 알람 드릴다운, BMS 상세, 데이터 반출 상태 관리 화면을 가져야 한다. |
| 충전 화면/패널 | 2024.10 운전자 매뉴얼은 충전제어패널 터치 화면으로 충전 설정 변경과 시작/정지를 수행하고, 충전준비완료·충전중·충전완료·충전이상·A/B팩 충전 상태등과 경보 알람 부저를 제공한다고 설명한다. | PoC는 충전 중/운행 중 데이터를 분리하고, 충전 이상 이벤트를 배터리 이상 징후와 별도 라벨로 관리해야 한다. |
| 통신·알람 인터페이스 | 축전지/BMS 문서에서 CAN_L/CAN_H, 24V, W/U Signal, Alarm 1~4, Warning/Fault, RS232 디버깅, CAN 외부통신 단서가 확인된다. | 데이터 수집은 CAN 직접 연결보다 기존 로그 파일·DB·운영 PC export 경로부터 확인해야 하며, 알람 접점은 이벤트 라벨링 근거로 사용한다. |
| 창동3호 로그와의 연결 | 파싱된 vcu_*.txt에는 BMS CAN Rack 전압/전류/SOC/SOH/셀전압/온도와 차량 주행·제어 배터리 값이 같은 시간축에 기록되어 있다. |
BMS 데이터는 이미 VCU 또는 운영 PC 로깅 계층까지 전달된 것으로 보이며, PoC는 이 저장파일을 비침습적으로 수집·해석하는 구조가 가장 현실적이다. |
| 확인 한계 | 문서로 차량정보 상태모니터와 충전제어패널의 존재 및 주요 메뉴는 확인되지만, 실제 현장 PC의 파일 경로, DB 구조, 사용자 계정, 차량별 화면 버전, CAN ID별 의미, 알람 코드 전체표는 확정할 수 없다. | 실증 전 현장 PC 접속, 화면 캡처, 로그 경로 확인, 코드표 확보가 필수다. |
¶ 3. 근거 자료 범위
| 자료 | 위치 | 본 보고서에서 사용한 내용 |
|---|---|---|
| 정비/운용 교범 | Docs/고객 기존 데이터/모터카 정비교범외/*/1. 정비교범 |
BMS 상태정보 전달, 차량컴퓨터 감시·제어, 저전압 경고등, 잔량 표시, 판넬PC 알람 표시·로깅, 차량정보 상태모니터, BMS 상세 버튼, 저장폴더/USB 백업, 충전제어패널 |
| 축전지/BMS 승인원·사양서 | Docs/고객 기존 데이터/모터카 정비교범외/*/2. 축전지 승인원&사양서 |
Battery System 구성, Master/Slave BMS, CAN_L/H, Alarm 1~4, Warning/Fault, 보호조건 |
| 운영 PC 사양서 | Docs/고객 기존 데이터/모터카 정비교범외/*/3. PC사양서 |
차량군별 PC 모델, OS 후보, 직렬/LAN/USB/저장장치 등 수집 환경 |
| 기존 분석 산출물 | outputs/customer-data-analysis/모터카_정비교범외_심층분석보고서.md |
문서군 요약, 세대별 BMS/PC 사양, 통신·보호조건 정리 |
| 창동3호 BMS 파싱 결과 | outputs/customer-data-analysis/changdong3_bms_parsed_full.csv |
VCU 로그 안에 포함된 BMS CAN 값, 차량/주행/제어 배터리 값, 이벤트 전후 시간축 |
| BMS 컬럼 사전 | outputs/customer-data-analysis/changdong3_bms_column_dictionary.csv |
각 필드의 의미, 단위, 분석 용도 |
¶ 4. 문서상 확인되는 시스템 구조
문서 근거를 종합하면 기존 BMS 관련 시스템은 중앙 서버형 콘솔보다 차량 탑재형 계층 구조에 가깝다. 배터리 팩의 셀·모듈 상태는 BMS에서 취합되고, BMS 상태정보는 차량컴퓨터 또는 VCU로 전달되며, 운전자는 조작판·경고등·잔량 표시·판넬PC를 통해 결과를 확인한다.
¶ 5. 구성 계층별 분석
| 계층 | 문서상 역할 | 확인된 단서 | 확인 수준 | PoC 영향 |
|---|---|---|---|---|
| 배터리 팩 | 주행용 또는 제어용 축전지 에너지 공급 | 2019 궤도모터카 8P 84S/168S, 613.2Vdc 계열 단서. 전기모터카 84S, 310.8V 계열 단서. | 문서 기준 확인, 차량별 실제 구성은 추가 확인 필요 | 같은 전압도 84S/168S 여부에 따라 정상/이상 판정이 달라진다. |
| Slave BMS | 셀 전압·온도 측정, 하위 모듈 상태 수집 | 2021년 이후 승인원에서 Slave/Master BMS 반복. 하남선 승인원에서 84ch 셀 전압, 8ch 온도 측정 단서 확인. | 문서 기준 확인 | 셀 단위 이상탐지에는 Slave 계층의 측정 정밀도와 누락 여부를 고려해야 한다. |
| Master BMS | 팩 상태 취합, SOC/SOH, 보호조건, Warning/Fault, 릴레이 차단 | 2016 전기모터카는 Master 1, Slave 7, 릴레이 차단, RS232 디버깅, CAN 외부통신 단서가 명확하다. | 문서 기준 확인 | BMS가 이미 보호 동작을 수행하므로 PoC는 제어보다 이상 조기탐지·정비 판단 지원에 집중한다. |
| 차량컴퓨터/VCU | BMS 상태정보 수신, 축전지 감시·제어, 충방전량 모니터링·기록 | 교범에서 BMS 상태정보가 차량컴퓨터에 전달되어 감시·제어 가능하다고 반복된다. 창동3호 로그 파일명도 vcu_*.txt이다. |
강한 근거 | 기존 데이터 수집 지점은 BMS 단자보다 VCU/운영 PC 저장 계층일 가능성이 높다. |
| 조작판/계기판 | 잔량 확인, 전압 표시, 저전압·경보 표시 | 잔량 확인 장치, 저전압 경고등, 발광 Diode, 계기판 경보가 반복 언급된다. | 문서 기준 확인 | 현장 대시보드는 운전자 표시와 정비자 상세진단을 분리해야 한다. |
| 판넬PC/운영 PC | 상세 알람 표시, 운전조작·알람 발생 정보 로깅 | 2019 궤도모터카 교범에서 판넬PC의 상세 알람 표시와 로깅 기능이 확인된다. PC 사양서는 차량군별로 존재한다. | 일부 차량군 명시 확인, 전체 차량군 일반화는 추가 확인 필요 | PoC 에이전트 설치보다 기존 로그 저장 위치, 계정 권한, 프로그램 점유 상태 확인이 우선이다. |
| 로컬 로그/저장파일 | BMS CAN 값과 차량 상태값 저장 | 창동3호 저장파일 파싱 결과에 Rack 전압/전류, SOC/SOH, 셀 전압·온도, BMS CAN 0x111 상태비트, 차량속도 등이 포함된다. | 실제 데이터 확인 | 분석 모델의 1차 입력은 이미 저장된 로컬 파일을 표준화한 데이터셋으로 구성 가능하다. |
¶ 6. 콘솔의 성격: 중앙 관제보다 현장 HMI에 가까움
현재 문서에서 명확히 확인되는 콘솔 성격은 중앙 서버나 웹 관제 화면이 아니라 차량 탑재 현장 HMI이다.
| 구분 | 문서상 확인 여부 | 해석 |
|---|---|---|
| 중앙 서버형 BMS 관제 콘솔 | 미확인 | 문서군에는 클라우드, 서버, 중앙 DB, 원격 관제 화면 구조가 확인되지 않는다. |
| 차량 조작판·계기판 | 확인 | 잔량, 전압, 저전압 경고, 경보 표시가 운전자 인지 계층이다. |
| 판넬PC | 일부 차량군에서 명시 확인 | 알람 상세 표시와 운전조작/알람 정보 로깅을 담당하는 현장 콘솔로 볼 수 있다. |
| 운영 PC | 사양서로 확인 | 산업용 패널 PC 또는 임베디드 박스 PC가 차량군별로 혼재한다. |
| BMS 전용 유지보수 콘솔 | 직접 화면은 미확인 | RS232 디버깅, CAN 외부통신 단서가 있어 정비용 진단 경로는 존재할 가능성이 있다. |
따라서 PoC 문서에서 “기존 콘솔 연계”라고 표현할 때는 중앙 관제 연동이 아니라 기존 차량 내 표시·로깅 장치와의 연계를 의미하도록 범위를 명확히 해야 한다.
¶ 7. 통신·알람 인터페이스 분석
| 인터페이스 | 문서상 단서 | 예상 용도 | PoC 접근 기준 |
|---|---|---|---|
| CAN_L/CAN_H | 2019 이후 Battery System 문서에서 외부 전원/통신 커넥터 항목으로 확인 | BMS 상태정보 외부 전달, VCU와 BMS 간 통신 | 우선 직접 연결하지 않고 기존 로그가 CAN 값을 포함하는지 확인한다. 직접 수집은 안전성·보증·절연·프로토콜 승인 후 검토한다. |
| CAN2.0A/B 125~500Kbps | 하남선 전기모터카 승인원에서 BMS 보드 사양으로 확인 | BMS 보드 간 또는 외부 통신 | CAN ID, 스케일, 엔디언, 상태비트 정의서가 필요하다. |
| Alarm 1~4 | Battery System 문서에서 외부 알람 커넥터로 반복 확인 | 저전압, 온도, Warning/Fault 등 이산 알람 전달 | 원시 로그 이벤트와 사고보고서 시각을 라벨링할 때 사용할 수 있다. |
| Warning/Fault | BMS 체크리스트와 보호조건에서 확인 | 경고와 고장 상태 구분 | 이벤트 심각도 등급화 기준으로 사용한다. |
| 24V, W/U Signal | 외부 전원/통신 커넥터에서 확인 | BMS 또는 충전/기동 상태 신호 | 수집 장비를 붙이는 전원으로 오해하면 안 되며, 기존 회로 목적 확인이 필요하다. |
| RS232 디버깅 | 2016 전기모터카 배터리 사양서에서 확인 | BMS 유지보수·디버깅 | 운영 중 상시 수집 경로로 쓰기보다 현장 진단 또는 프로토콜 확인용으로 본다. |
| LAN/USB/저장장치 | 운영 PC 사양서에서 확인 | 로그 반출, 로컬 DB, 원격 접속 후보 | 보안·계정권한·USB 반출 정책 확인 후 read-only 수집 방식을 설계한다. |
¶ 8. 운영 PC·판넬PC 세대별 구성
| 차량군 | 운영 PC 모델 | 문서에서 확인된 주요 사양 | 수집 관점의 의미 |
|---|---|---|---|
| 궤도 2019.02 / 2019.12 | EPC104-N | Celeron Braswell N3160, DDR3 2GB, SSD 64GB, COM 2~4EA RS-232, USB2/3, HDMI 2EA, LAN 2EA, DC 9~35V, Windows 7/10 계열 | 패널 PC 성격이 강하다. 알람 표시·로깅 프로그램의 파일 위치와 Windows 계정 권한 확인이 우선이다. |
| 궤도 2021.11 | UNO-2372G | Atom E3845 또는 Celeron J1900, 4GB DDR3L, GbE 2EA, USB 4EA, RS-232/422/485 4EA, mPCIe, -20~60℃ | 박스형 산업용 PC 성격이다. 직렬·LAN·확장 모듈 점유 상태와 기존 로그 저장장치 확인이 필요하다. |
| 궤도 2022.12 | ARK-2121F-U0A2E | 모델명만 확인, PDF 텍스트 추출 불가 | OCR 또는 실장 장비 확인이 필요하다. 최신 차량군 수집방식 확정 전 미확정 항목으로 둔다. |
| 궤도 2024.10 | UNO-2473G-J3AE | 모델명만 확인, PDF 텍스트 추출 불가 | OS, 저장장치, 네트워크, serial/CAN 확장 여부를 현장 실사로 확인해야 한다. |
| 전기 2016.09~2017.02 | EPC70-J | Atom Baytrail J1900, DDR3 2GB, SSD 32GB/HDD 500GB, RS-232 4EA, USB, LAN 2EA, DC 12V/5A | 직렬 포트 기반 진단 가능성이 있으나, 실제 로그는 운영 프로그램의 저장 경로를 먼저 확인한다. |
| 전기 2021.09 / 2022.11 | ARK-1123H-A4 | Celeron J1900, DDR3L 최대 8GB, GbE 2EA, RS-232/422/485 1EA, USB, 2.5형 SATA, mSATA, Windows 10/Linux 지원 | 설치형 에이전트보다 파일 감시 또는 주기적 export 방식이 단순하고 안전하다. |
¶ 9. 창동3호 BMS 저장파일로 본 실제 데이터 흐름
창동3호 파싱 데이터는 문서상 구조가 실제 로그에 반영되어 있음을 보여준다. changdong3_bms_parsed_full.csv는 파일명 vcu_*.txt에서 재구성되었고, 같은 시간축에 다음 값이 포함된다.
| 데이터 범주 | 주요 컬럼 | 의미 |
|---|---|---|
| BMS 팩 상태 | rack_voltage_v, rack_current_a, soc_pct, soh_pct |
BMS가 취합한 팩 전압·전류와 상태값 |
| 셀 전압 | avg_cell_voltage_mv, low_cell_voltage_mv, high_cell_voltage_mv, cell_voltage_spread_mv |
셀 평균/최저/최고/편차 |
| 온도 | avg_temp_c, low_temp_c, high_temp_c, temp_spread_c |
셀 또는 모듈 온도 분포 |
| 차량 상태 | vehicle_speed_kmh, motor_speed, engine_torque, 공기압 계열 |
운행 상태와 BMS 이상을 함께 해석하기 위한 보조 신호 |
| 제어·주행 배터리 | drive_bat_voltage_v, drive_bat_current_a, ctrl_bat_voltage_v 등 |
차량 측 전원 상태와 BMS 팩 상태의 교차 검증 |
| BMS 상태비트 | bms_can_0x111_* |
CAN 상태 원문. 비트 정의서 확보 시 알람 원인 분류 가능 |
| 품질·이벤트 파생값 | data_valid, acquisition_state, event_phase, estimated_serial_cells |
사고 전후 값의 정상 취합/부분 취합/무효 상태 구분 |
이 구조는 BMS, VCU, 운영 PC가 완전히 분리되어 있지 않고, 적어도 로그 저장 단계에서는 BMS CAN 계열 값과 차량 운행 값이 결합되어 있음을 의미한다. 따라서 PoC의 1차 목표는 CAN을 새로 취득하는 것이 아니라 이미 결합된 VCU/운영 PC 로그를 안정적으로 수집하고, BMS 상태비트를 해석 가능한 이벤트로 변환하는 것이다.
¶ 10. BMS 보호·알람 계층
| 보호·알람 항목 | 문서상 단서 | 분석 적용 |
|---|---|---|
| Pack Over/Under Voltage | 2019 Battery System 문서에서 Warning/Fault 및 Relay 차단 조건 확인 | 팩 전압 급락·상승 이벤트의 심각도 판정 기준 |
| Cell Over/Under Voltage | 2016 전기모터카 문서에서 셀 4.1V 이상, 3.2V 이하 보호조건 확인 | 셀 단위 이상탐지 기준. 단, 차량군별 기준값 차이를 반영해야 한다. |
| Min_V 알람 | 2021년 이후 궤도모터카 승인원에서 Min_V 알람 단서 확인 | 최저 셀 전압 중심의 조기경보 후보 |
| 온도 알람 | 2024 문서에서 온도 0℃ 이하 알람 단서, 일반 BMS 문서에서 OTP 등 확인 | 저온/고온 운행 조건 분리 필요 |
| Cell Volt deviation | 하남선 BMS 보드 사양에서 보호항목으로 확인 | 셀 간 전압차 기반 이상탐지의 핵심 근거 |
| SOC 30% 미만 | 하남선 승인원에서 SOC 저하 알람 단서 확인 | 운행 가능성·충전 필요 알림으로 분리 |
| Relay 차단 | 2016 문서에서 릴레이 차단 명시 | 사고 순간 팩 전압 급락 또는 부분 취합 상태 해석에 필요 |
¶ 11. 현장 시스템 관점의 업무 흐름
| 단계 | 기존 시스템 역할 | PoC에서 추가할 최소 기능 |
|---|---|---|
| 운행 전 | 조작판·계기판에서 잔량, 전압, 경고등 확인 | 최근 로그 기준 배터리 상태 요약, 수집 누락 여부 표시 |
| 운행 중 | BMS가 상태를 감시하고 차량컴퓨터가 경고·제어를 수행 | 경고 전조 패턴, 셀 편차, 온도 편차를 사후 분석용으로 축적 |
| 알람 발생 | 판넬PC가 상세 알람을 표시하고 알람/조작 이력을 로깅 | 알람 전후 5~10분 데이터 자동 추출, 사고보고서와 시간 매칭 |
| 정비 판단 | 정비자는 경고등, 교범, 점검 절차, 현장 측정값을 바탕으로 조치 | BMS 로그 기반 원인 후보, 재발 여부, 차량군 기준값 대비 편차 제공 |
| 사후 분석 | 저장파일을 별도로 확보해 분석 | 표준 파싱, 데이터 품질 라벨, 이벤트 윈도우, 보고서 자동 생성 |
¶ 12. PoC 시스템 구성 제안
기존 하드웨어를 바꾸지 않는 조건에서는 다음 구조가 가장 보수적이다.
| 구성요소 | 역할 | 배치 위치 | 설계 원칙 |
|---|---|---|---|
| Read-only 로그 수집기 | 운영 PC 또는 반출 저장매체의 BMS/VCU 로그 파일을 복사 | 운영 PC 내부 또는 정비실 PC | 원본 파일 수정 금지, 파일 잠금 회피, 수집 실패 재시도, 해시 기록 |
| 파서 | vcu_*.txt 등 원시 파일을 표준 CSV/Parquet로 변환 |
정비실 PC 또는 온프레미스 분석 PC | 차량군별 스키마 버전 관리, 무효/제로 데이터 분리 |
| 이벤트 추출기 | 사고·알람 전후 구간, 셀 편차, 상태비트 변화 추출 | 분석 PC | 사고보고서 시각과 로그 시각 동기화, 부분 취합 상태 표시 |
| 현장 리포트 | 차량별 배터리 상태, 알람 이력, 위험 후보 표시 | 정비자용 PC 또는 Wiki/문서 | 운전자 경고와 정비자 상세진단을 분리 |
| 기준정보 관리 | 차량군, BMS 버전, PC 모델, 알람 코드표, 보호조건 관리 | 온프레미스 DB 또는 파일 기반 마스터 | 차량별 기준값 차이를 모델 입력에 반영 |
¶ 13. 현장 실사 체크리스트
| 확인 항목 | 확인 방법 | 왜 필요한가 |
|---|---|---|
| 판넬PC 화면 | 알람 발생 이력 화면, 잔량/전압/경고 화면 사진 확보 | 문서상 기능이 실제 UI에 어떻게 구현되어 있는지 확인 |
| 운영 PC OS·계정 | Windows/Linux 버전, 로그인 방식, 관리자 권한, 자동실행 프로그램 확인 | 에이전트 설치 가능성보다 read-only 접근 가능성을 판단 |
| 로그 저장 경로 | 파일명 패턴, 생성 주기, 저장 위치, 보존 기간, 파일 잠금 여부 확인 | 수집 설계의 핵심 입력 |
| BMS/VCU 시간 동기화 | PC 시간, 로그 시간, 사고보고서 시간 비교 | 이벤트 전후 분석 정확도 확보 |
| CAN/알람 코드표 | CAN ID, 스케일, 상태비트, Alarm 1~4 의미, Warning/Fault 조건표 요청 | 상태비트를 정비 언어로 변환 |
| 차량별 BMS 버전 | BMS 펌웨어, 파라미터, 배터리 팩 구성, 교체 이력 확인 | 차량군별 정상범위 차이 반영 |
| 운영 PC 포트 점유 | RS-232/422/485, LAN, USB, CAN 확장 모듈 사용 현황 확인 | 기존 장비 운행에 영향 없는 수집 방식 선택 |
| 반출·보안 정책 | USB 사용 가능 여부, 네트워크 분리 여부, 개인정보/운행정보 반출 기준 확인 | 보안 정책 위반 없이 분석환경 구성 |
| 알람 발생 절차 | 알람 발생 시 운전자·정비자 조치 절차 확인 | 분석 리포트가 실제 의사결정 흐름과 맞는지 검증 |
| 정비 이력 연계 | 배터리 교체, 용량시험, 충전기 점검, 고장조치 이력 확보 | SOH/RUL 모델의 검증 라벨 확보 |
¶ 14. 미확정 사항과 리스크
| 리스크 | 현재 상태 | 대응 |
|---|---|---|
| 중앙 관제 시스템 존재 여부 | 문서상 확인되지 않음 | 현장 실사에서 별도 서버/관제 PC/DB 존재 여부 확인 |
| 최신 궤도모터카 PC 사양 | ARK-2121F, UNO-2473G 데이터시트는 텍스트 추출 불가 | OCR 또는 실제 장비 정보 수집 |
| CAN 상태비트 의미 | 창동3호 로그에 원문 비트는 있으나 의미표 미확보 | BMS 제조사 또는 유지보수 문서에서 코드표 확보 |
| 차량별 팩 구성 차이 | 84S/168S 등 문서상 혼재 | 차량번호별 배터리 구성 마스터 작성 |
| 원시 로그 품질 | 사고 후 부분 취합·무효/제로 데이터 발생 가능 | data_valid, acquisition_state를 모델 입력과 리포트에 명시 |
| 운영 PC 영향 | 기존 운행 프로그램과 충돌 가능성 | 초기 PoC는 원본 파일 복사 기반 read-only 방식으로 제한 |
¶ 15. PDF 발췌 이미지 근거
아래 이미지는 원본 PDF 페이지를 PNG로 렌더링한 것이다. 각 이미지는 시스템 구조를 추정하기 위한 시각 근거이며, 원문 PDF의 세부 수치·커넥터 명칭·알람 정의는 현장 실사 또는 제조사 자료와 다시 대조해야 한다.
| 그림 | 원문 PDF / 페이지 | 보고서에서 해석한 구성 요소 |
|---|---|---|
| 그림 1 | 2019.02 궤도모터카 운용 및 정비 교범.pdf p.36 |
판넬PC가 알람 상세 표시와 운전조작/알람 로깅을 담당한다는 현장 HMI 근거 |
| 그림 2 | 2019.02 궤도모터카 Battery System 사양서 p.14 |
Pack PRA 구성도, Slave BMS 개발 사양, 측정·통신 계층 |
| 그림 3 | 2019.02 궤도모터카 Battery System 사양서 p.15 |
Slave BMS Board와 Master BMS Board 물리 구성 |
| 그림 4 | 2024.10 궤도모터카 Battery System 승인원 p.14 |
System Block-diagram, System 통신 및 신호 연결도 |
| 그림 5 | 2024.10 궤도모터카 Battery System 승인원 p.19 |
외부 전원/통신 커넥터, CAN_L/CAN_H, W/U Signal, Alarm 1~4 의미 |
| 그림 6 | 2019.02 궤도모터카 EPC104-N.pdf p.1 |
산업용 패널 PC의 화면·터치·RS-232·LAN·저장장치 기반 운영 PC 환경 |
| 그림 7 | 2022.12 궤도모터카 운전자 매뉴얼.pdf p.59 |
차량정보 상태모니터 메인 대시보드, 상태알림 및 경고/알람, BMS, 기본메뉴얼, 저장폴더, USB 백업 |
| 그림 8 | 2024.10 궤도모터카 운전자 매뉴얼.pdf p.15 |
차량정보 상태모니터가 차량 상태 표시와 운전·알람 로그 기록을 담당하고, 모니터 USB로 저장 데이터를 반출하는 구성 |
| 그림 9 | 2021.11 궤도모터카 운용 및 정비 교범.pdf p.66 |
제어배터리 전압·충전전류·방전전류를 운전대 차량정보 모니터링계에서 확인하는 절차 |
| 그림 10 | 2024.10 궤도모터카 운전자 매뉴얼.pdf p.39 |
충전제어패널 터치 화면, 충전 상태등, 충전 이상 경보 알람 부저 |
| 그림 11 | 2022.11 전기모터카 운용 및 정비 교범.pdf p.8 |
차량컴퓨터가 충방전량을 상시 모니터링·기록하고, 조작판에서 축전지 잔량을 확인하는 구조 |
| 그림 12 | 2019.02 궤도모터카 Battery System 사양서 p.18 |
Download 커넥터, Slave Download, Master Download, CAN, Alarm 출력의 물리 인터페이스 |
그림 1은 운전대 주변 표시·조작 계층을 보여준다. 같은 페이지에 비상제동스위치, 속도계, 판넬PC, 제동레버, 경고등이 함께 배치되어 있어, 판넬PC가 별도 사무용 PC가 아니라 운전·정비 현장 HMI의 일부임을 보여준다. 특히 판넬PC 항목은 알람 발생 시 상세 알람을 표시하고 운전조작 및 알람 발생 정보를 로깅한다고 설명한다. 따라서 BMS 데이터 분석 시스템은 판넬PC 또는 그 하위 로그 저장 경로를 우선 확인해야 한다.
그림 2는 배터리 팩 내부가 단순 셀 묶음이 아니라 PRA, Relay Control, Master BMS, Slave BMS가 결합된 구조임을 보여준다. Slave BMS 개발 사양에는 입력 전원, 동작 온도, MCU, 셀 전압, 온도, 셀 밸런싱, CAN, 진단 항목이 포함된다. 이는 원시 로그의 셀 전압·온도·상태비트가 BMS 내부 측정과 통신 절차를 거쳐 만들어진 값이라는 점을 뒷받침한다.
그림 3은 Master BMS와 Slave BMS가 물리적으로 분리된 보드 계층임을 보여준다. Slave BMS는 셀 측정·밸런싱에 가까운 하위 계층이고, Master BMS는 DC Bus Current, SOC, CAN, Protection 같은 팩 단위 판단에 가까운 계층으로 해석된다. 사고 분석에서는 셀 단위 이상, 팩 단위 보호 판단, 외부 알람 출력이 서로 다른 단계에서 발생할 수 있음을 전제로 해야 한다.
그림 4는 최신 궤도모터카 계열에서 System Block-diagram과 System 통신 및 신호 연결도가 함께 제시된 페이지다. 배터리 팩, Power Relay Assembly, Master BMS, 외부 장치가 전원선·CAN·Wake-up·알람 신호로 연결되는 구조가 확인된다. 이 그림은 기존 시스템이 BMS 단독 장치가 아니라 차량 전장·충전·운영 표시 계층과 연결된 폐쇄형 온보드 시스템이라는 점을 설명하는 핵심 근거다.
그림 5는 외부 전원/통신 커넥터와 외부 알람 커넥터의 Pin Info를 보여준다. 2024 문서 기준으로 외부 전원/통신 커넥터에는 24V, W/U Signal, Charge W/U Signal(24V), CAN_L, CAN_H가 배치되어 있고, 외부 알람 커넥터에는 Alarm 1(Min_V), Alarm 2(온도 0도 이하), Alarm 3(Warning), Alarm 4(Fault)가 배치된다. 이 정보는 로그 상태비트와 실제 현장 알람을 매핑할 때 가장 먼저 대조할 항목이다.
그림 6은 2019 궤도모터카에 사용된 EPC104-N 산업용 패널 PC 사양이다. 터치 LCD, SSD, Windows Embedded/Windows 10 IoT, RS-232, USB, LAN, DC 입력 조건이 확인된다. 이는 PoC 시스템을 설계할 때 운영 PC를 일반 노트북처럼 볼 수 없고, 산업용 패널 PC의 저장장치·권한·포트 점유·운영 프로그램 자동실행 구조를 기준으로 접근해야 함을 의미한다.
그림 7은 누락되었던 화면 기반 As-Is 분석의 핵심 근거다. 2022.12 운전자 매뉴얼은 차량정보 상태모니터의 메인화면이 차량 속도·주행방향, 주차제동상태·미션단수, 주배터리 잔량·전류, 제어배터리 전압·충전전류·방전전류, EV/ENGINE 운전모드, 콤프레샤 상태, 주행시간, 배터리 소모량을 표시한다고 설명한다. 또한 상태알림 및 경고/알람을 눌러 상세내역을 확인하고, BMS 버튼으로 주행용 축전지 상세정보를 확인하며, 저장폴더에서 운행 데이터를 확인하고 USB로 백업할 수 있다고 명시한다.
그림 8은 2024.10 운전자 매뉴얼의 차량정보 상태모니터와 모니터 USB 항목이다. 차량정보 상태모니터는 차량 상태를 표시하고 운전 및 알람 로그를 기록하는 장치로 설명되며, 모니터 USB는 저장폴더 메뉴에서 저장된 운행 데이터를 확인하고 USB를 연결해 백업하는 구성으로 제시된다. 즉 기존 콘솔은 화면 표시와 로컬 데이터 반출이 분리된 것이 아니라 하나의 현장 HMI 워크플로에 묶여 있다.
그림 9는 제어용 축전지 충전상태 확인 절차다. 아날로그 계기와 램프뿐 아니라 운전대의 차량정보 모니터링계에서도 제어배터리 충전/방전 전류를 확인할 수 있다고 설명한다. 이는 To-Be 대시보드가 주행용 고전압 배터리만 표시해서는 부족하고, 저전압 제어계통의 충전기 상태, 제어배터리 전압, 충전전류, 방전전류, 저전압 제어 경고까지 함께 다뤄야 함을 의미한다.
그림 10은 충전제어패널 화면이다. 문서상 이 터치패널은 충전 설정 변경과 충전 시작·정지를 수행하고, 충전준비완료, 충전중, 충전완료, 충전이상, A팩 충전, B팩 충전 상태등을 제공한다. 충전 경고등 점등 시 경보 알람 부저가 울린다는 설명도 함께 있다. 따라서 충전 중 이벤트는 운행 중 이벤트와 별도의 상태 맥락으로 분리해 분석해야 하며, To-Be 시스템은 충전 세션별 이상 여부를 별도 타임라인으로 제공해야 한다.
그림 11은 전기모터카 문서의 충방전 모니터링 설명이다. 차량컴퓨터가 충방전 상황을 상시 입력받아 충방전량을 모니터링하고 기록하며, 운전제어대에서 축전지 잔량을 확인할 수 있다는 구조가 확인된다. 이는 창동3호 vcu_*.txt처럼 차량 상태와 BMS 상태가 함께 저장되는 로그 구조가 예외적 산출물이 아니라, 차량컴퓨터 중심 운영 방식에서 자연스럽게 생성되는 데이터임을 뒷받침한다.
그림 12는 사용자가 지적한 BMS 다운로드 관련 근거다. 해당 페이지의 Download는 운전자용 대시보드 메뉴라기보다 Slave Download, Master Download, 외부 전원/통신, 외부 알람 커넥터로 구성된 물리 인터페이스 항목이다. 따라서 To-Be 시스템 관점에서는 이를 “화면 다운로드 버튼”으로 해석하기보다, 제조·정비·진단 시 BMS 보드 또는 Master/Slave 계층에 접근할 수 있는 하드웨어 경로로 보고, 현장 실사 시 실제 사용 가능 여부와 권한·절차를 확인해야 한다.
¶ 16. 실제 시스템 동작 절차 해설
문서와 발췌 이미지를 합치면 기존 BMS 관련 시스템은 다음 절차로 동작하는 것으로 보는 것이 가장 타당하다. 아래 절차는 문서상 확인된 구성에 창동3호 vcu_*.txt 로그 구조를 연결한 운영 관점의 설명이다.
¶ 16.1 정상 운행 중 데이터 생성 절차
| 순서 | 동작 주체 | 절차 | 생성·전달 데이터 | 확인 근거 |
|---|---|---|---|---|
| 1 | 배터리 팩 | 셀과 모듈이 주행용 전원을 공급한다. | 셀 전압, 셀 온도, 팩 전압, 팩 전류의 물리 상태 | Battery System 구성도, Pack Block-diagram |
| 2 | Slave BMS | 각 셀 또는 모듈의 전압·온도를 측정하고 하위 상태를 취합한다. | 평균/최저/최고 셀 전압, 온도, 셀 밸런싱 상태 | Slave BMS 개발 사양 |
| 3 | Master BMS | Slave BMS 값을 받아 팩 단위 상태를 계산하고 보호조건을 판정한다. | Rack 전압, Rack 전류, SOC, SOH, Warning/Fault, 보호 판단 | Master BMS 개발 사양, BMS 보드 사진 |
| 4 | BMS 외부 인터페이스 | Master BMS가 외부 전원/통신 커넥터와 알람 커넥터로 상태를 내보낸다. | CAN_L/CAN_H, W/U Signal, Alarm 1~4 | 외부 커넥터 Pin Info |
| 5 | 차량컴퓨터/VCU | BMS 상태정보를 수신하여 차량 운행 상태와 함께 감시·제어한다. | BMS CAN 값, 차량속도, 공기압, 주행/제어 배터리 값 | 정비교범의 차량컴퓨터 설명, 창동3호 vcu_*.txt |
| 6 | 조작판/계기판 | 운전자가 필요한 수준으로 잔량, 전압, 저전압 경고, 경보를 표시한다. | 운전자 표시값, 경고등, 잔량 표시 | 정비교범의 조작판·경고등 설명 |
| 7 | 판넬PC/운영 PC | 상세 알람을 표시하고 운전조작·알람 발생 정보를 로깅한다. | 알람 이력, 조작 이력, 로컬 로그 파일 | 그림 1, 운영 PC 사양서 |
| 8 | 로컬 저장파일 | VCU 또는 운영 PC 계층에서 주기적으로 원시 로그가 저장된다. | vcu_*.txt, Rack/Cell/온도/상태비트/차량상태 |
창동3호 파싱 결과 |
| 9 | 사후 분석 | 저장파일을 반출·복사해 표준 컬럼으로 파싱하고 사고 시각과 매칭한다. | 표준 CSV, 이벤트 윈도우, 이상징후 리포트 | changdong3_bms_parsed_full.csv, 사고 분석 산출물 |
¶ 16.2 알람 발생 시 절차
| 순서 | 조건 | 시스템 반응 | 분석상 해석 |
|---|---|---|---|
| 1 | 특정 셀 전압 저하, 셀 간 전압차 확대, 저온, 과전압/저전압 등 조건 발생 | Slave BMS가 측정값을 갱신하고 Master BMS로 전달한다. | 원인 후보는 셀 단위 측정값부터 확인한다. |
| 2 | Master BMS가 보호조건 또는 Warning/Fault 조건을 만족한다고 판단 | Warning, Fault, Min_V, 온도 알람 등 내부 상태가 변경된다. | 상태비트 또는 알람 접점 변화가 이벤트 라벨 후보가 된다. |
| 3 | 외부 알람 커넥터로 Alarm 1~4가 전달 | 2024 문서 기준 Alarm 1은 Min_V, Alarm 2는 온도 0도 이하, Alarm 3은 Warning, Alarm 4는 Fault로 제시된다. | 차량군별 알람 정의가 다를 수 있으므로 반드시 해당 차량 문서와 대조한다. |
| 4 | 차량컴퓨터/VCU가 BMS 상태를 수신 | 경고등, 계기판 표시, 운행 제어, 충방전 모니터링에 반영된다. | 로그에는 BMS 값과 차량 상태값이 같은 시간축에 남을 가능성이 높다. |
| 5 | 판넬PC가 상세 알람을 표시 | 운전자는 알람명을 보고 조치하고, 정비자는 알람 상세와 조작 이력을 확인한다. | PoC 리포트는 알람명을 정비자 용어로 번역해야 한다. |
| 6 | 운영 PC 또는 VCU 로그가 저장 | 사고 전후 데이터, 상태비트, 무효/부분 취합 상태가 기록된다. | 사고 직후 통신 손상·부분 취합 가능성을 고려해 data_valid와 acquisition_state를 함께 제시한다. |
¶ 16.3 충전·기동·Wake-up 신호 절차
| 순서 | 절차 | 근거 | PoC 확인 포인트 |
|---|---|---|---|
| 1 | 외부 전원/통신 커넥터에서 24V와 W/U Signal이 사용된다. | 외부 전원/통신 커넥터 Pin Info | W/U Signal은 수집 장비 전원이 아니라 기존 BMS/차량 회로 신호로 취급한다. |
| 2 | 2024 문서에는 Charge W/U Signal(24V)이 별도 항목으로 제시된다. | 그림 5 | 충전 상태와 주행 상태의 로그 패턴이 다를 수 있으므로 충전/주행 상태 라벨이 필요하다. |
| 3 | BMS는 충방전 상태와 보호조건을 차량컴퓨터에 전달한다. | 정비교범의 충방전 모니터링 설명 | 충전 중 로그와 운행 중 로그를 구분해 모델 학습 데이터를 구성한다. |
| 4 | 알람 발생 시 Warning/Fault가 외부 알람 접점 또는 CAN 상태로 전달된다. | Alarm 1~4, CAN_L/CAN_H | 알람 접점과 CAN 상태비트의 시간 차이 또는 누락 여부를 현장 샘플로 검증한다. |
¶ 16.4 로그 파일이 만들어지는 절차적 해석
창동3호 저장파일은 vcu_YYYYMMDDHHMMSS.txt 형태로 보이며, 파싱 결과에는 BMS 값과 차량 상태값이 함께 들어 있다. 따라서 로그 생성 절차는 다음처럼 해석할 수 있다.
- BMS가 셀·팩 상태를 측정한다.
- Master BMS가 CAN 또는 내부 통신으로 상태를 송신한다.
- 차량컴퓨터/VCU가 BMS 상태와 차량 운행 상태를 같은 주기로 취합한다.
- 판넬PC 또는 운영 PC 계층이 알람 상세 표시와 함께 운전조작·알람 정보를 저장한다.
- 저장파일이 일정 시각 기준으로 생성되고, 파일 내부 행 번호 또는 초 단위 카운터로 시간축이 재구성된다.
- 사고 분석 단계에서 파일 시작시각, 행 번호, 사고보고서 시각을 매칭해 이벤트 전후 구간을 만든다.
- 이벤트 직후에는 통신 손상 또는 부분 취합 때문에 팩 전압·셀 수 추정값이 급변할 수 있으므로, 단순 수치 급락을 곧바로 물리적 팩 전압 급락으로 단정하지 않는다.
¶ 16.5 현장 실사 절차
| 단계 | 현장에서 할 일 | 산출물 |
|---|---|---|
| 1 | 차량번호, 차종, 도입시기, 문서군, 배터리 팩 구성, BMS 버전을 대조한다. | 차량-BMS-문서 매핑표 |
| 2 | 판넬PC 화면에서 알람 이력, 잔량/전압 표시, 경고등 상태 화면을 촬영한다. | 화면 증빙 이미지 |
| 3 | 운영 PC 모델, OS, 자동실행 프로그램, 계정 권한, 저장장치 용량을 확인한다. | 운영 PC 실사표 |
| 4 | 로그 파일명, 저장 경로, 생성 주기, 보존 기간, 파일 잠금 여부를 확인한다. | 로그 경로·보존 정책 |
| 5 | 동일 시각의 판넬PC 표시값과 원시 로그 값을 비교한다. | 화면-로그 매칭표 |
| 6 | 외부 커넥터의 CAN_L/CAN_H, W/U, Alarm 1~4 의미를 문서와 실제 배선에서 대조한다. | 신호·알람 코드 매핑표 |
| 7 | 1일 이상 샘플 로그를 read-only로 복사하고 파서 결과를 검증한다. | 샘플 파싱 CSV, 누락률, 무효행 비율 |
| 8 | 사고보고서 또는 정비 이력의 시각과 로그 이벤트를 맞춘다. | 이벤트 라벨 목록 |
| 9 | 현장 운영자에게 알람 발생 시 실제 조치 절차를 확인한다. | 알람별 조치 절차표 |
| 10 | PoC 수집 방식은 원본 파일 수정 없는 복사 방식으로 고정한다. | read-only 수집 절차서 |
¶ 17. 화면 중심 As-Is 콘솔 운영 분석과 To-Be 구현 방향
이전 판에서는 BMS 승인원, 시스템 블록도, 운영 PC 사양서, 창동3호 저장파일을 중심으로 기존 시스템을 해석하면서, 운전자 매뉴얼에 흩어져 있는 실제 화면·메뉴 근거가 충분히 반영되지 않았다. 보완 분석 결과 기존 콘솔은 단순 알람 표시기가 아니라 차량정보 상태모니터, 상태알림 및 경고/알람, BMS 상세정보, 저장폴더 데이터 확인, USB 백업, 충전제어패널이 결합된 현장 운영 콘솔에 가깝다.
¶ 17.1 As-Is 화면·메뉴 기능 맵
| As-Is 화면/메뉴 | 지침서상 확인 기능 | 운영자가 실제로 하는 일 | To-Be 구현 시 반영할 기능 |
|---|---|---|---|
| 차량정보 상태모니터 메인화면 | 차량 속도, 주행방향, 주차제동, 미션단수, 주배터리 잔량·전류, 제어배터리 전압·충전전류·방전전류, EV/ENGINE 모드, 콤프레샤, 주행시간, 배터리 소모량 표시 | 운행 가능 상태, 배터리 잔량, 제어전원 이상 가능성, 운전모드를 한 화면에서 확인 | 운행 개요 대시보드: 차량 상태, 주행/충전 모드, 주배터리 SOC/전류, 제어배터리 전압/전류, 알람 요약을 한 화면에 표시 |
| 상태알림 및 경고/알람 | 상태알림과 경고/알람 상세내역 확인 | 알람 발생 시 알람명을 열어 원인을 확인하고 운행 지속/정지/정비 요청을 판단 | 알람 드릴다운: 알람명, 등급, 발생/복구 시각, 관련 BMS 값, 추천 점검 절차, 원시 로그 링크 제공 |
| BMS 버튼 | 주행용 축전지 상세정보 확인 | 메인화면에서 잔량 이상, 경고, 운행 불가 징후가 보이면 주행용 축전지 상세 상태를 확인 | BMS 상세: 팩/랙 전압, 전류, SOC, SOH, 최고/최저/평균 셀 전압, 셀 간 전압차, 온도, 상태비트, 보호조건 표시 |
| 기본메뉴얼 | 운행 메뉴얼 확인 | 현장 운전자가 화면에서 운행 기준과 조치 절차를 확인 | 운영 지침 연계: 알람별 SOP, 정비교범 해당 절, 점검 체크리스트를 화면 이벤트와 연결 |
| 저장폴더 | 저장된 운행 데이터 확인 | 운행 데이터 파일을 찾아 정비자 또는 분석 담당자에게 전달 | 데이터 수집 상태: 파일 생성 시각, 수집 성공/누락/중복, 파싱 성공률, 원본 보존 여부 표시 |
| USB 백업 | USB 연결 후 운행 데이터 백업 | 차량 PC에서 외부 저장매체로 데이터를 반출 | 반출·감사 로그: 반출 대상, 사용자, 시각, 파일 해시, 원본 경로, 개인정보/보안 점검 상태 기록 |
| 차량정보 상태모니터 로그 | 차량 상태 표시와 운전·알람 로그 기록 | 운전조작과 알람 발생 이력을 사후 확인 | 이벤트 타임라인: 운전조작, 알람, BMS 이상, 충전상태, 파일 생성 이벤트를 시간축으로 통합 |
| 충전제어패널 | 충전 설정 변경, 충전 시작/정지, 충전준비완료·충전중·충전완료·충전이상·A팩/B팩 충전 상태 표시, 경보 알람 부저 | 상용충전 또는 충전 이상 상황을 현장에서 확인하고 조치 | 충전 세션 화면: 충전 시작/종료, A/B팩 상태, 충전 이상, 온도/전압 추이, 충전 중 보호조건을 별도 분석 |
| BMS Download 커넥터 | Slave Download, Master Download, CAN, Alarm 출력 등 물리 인터페이스 | 제조사 또는 정비 담당자가 진단·다운로드·보드 접근에 사용할 가능성 | 운영 화면 기능으로 단정하지 않고 진단 인터페이스 관리: 사용 가능 조건, 권한, 케이블, 포트, 절차, 데이터 포맷을 현장 실사 항목으로 분리 |
¶ 17.2 As-Is 콘솔 운영 흐름
As-Is 운영의 중심은 “운전자가 화면으로 이상을 인지하고, 필요 시 BMS 상세와 저장폴더로 들어가 데이터를 확인·반출한다”는 절차다. 창동3호 저장파일은 이 절차의 마지막 단계에서 반출된 원시 로그에 가깝다. 따라서 To-Be 시스템은 원시 파일을 단순 표로 보여주는 데서 끝나면 현장 콘솔의 맥락을 잃는다. 메인 상태, 알람, BMS 상세, 충전, 저장폴더/반출 이력을 하나의 사건 흐름으로 묶어야 한다.
¶ 17.3 To-Be 대시보드 화면 구성 제안
| To-Be 화면 | 핵심 목적 | 표시 데이터 | As-Is 근거 |
|---|---|---|---|
| 차량 운행 개요 | 운행 가능 여부와 배터리 상태를 10초 안에 판단 | 차량번호, 운행/충전/정비 상태, EV/ENGINE 모드, 속도, 주배터리 SOC·전류, 제어배터리 전압·충전/방전 전류, 주요 알람 수 | 차량정보 상태모니터 메인화면 |
| BMS 상세 | 배터리 이상 원인을 셀/팩/랙 단위로 좁힘 | Rack 전압·전류·SOC·SOH, 최고/최저/평균 셀전압, 셀 간 전압차, 최고/최저 온도, 상태비트, Warning/Fault | BMS 버튼, 창동3호 vcu_*.txt |
| 알람·이벤트 | 운전자 화면 알람과 원시 로그 이벤트를 연결 | 알람명, 등급, 발생/해제, 관련 값, 차량 상태, 조치 이력, 원시 파일 위치 | 상태알림 및 경고/알람, 판넬PC 알람 로깅 |
| 충전 세션 | 충전 중 이상과 운행 중 이상을 구분 | 충전 시작/종료, 충전준비완료/충전중/충전완료/충전이상, A/B팩 상태, 충전 중 전압·전류·온도 추이 | 충전제어패널 |
| 데이터 수집/반출 | 기존 운영 PC 파일을 안전하게 수집·보존 | 저장폴더 경로, 파일명, 생성시각, 복사 상태, 파싱 상태, 누락률, 파일 해시, USB 반출 이력 | 저장폴더, USB 백업, 로컬 로그 |
| 정비 지침/증거 | 알람 발생 시 조치와 보고서 근거를 즉시 제공 | 알람별 SOP, 정비교범 페이지, 사고보고서 링크, 현장 사진, 실사 체크리스트 | 기본메뉴얼, 정비교범 |
¶ 17.4 구현 요구사항으로 변환한 As-Is 분석
| 요구사항 | 설명 | 우선순위 |
|---|---|---|
| 기존 PC/로그 read-only 수집 | 운영 PC 또는 VCU 저장 경로에서 원본 파일을 수정하지 않고 복사한다. 파일 잠금, 부분 쓰기, 중복 복사, USB 반출을 고려한다. | 상 |
| 화면 용어 기반 데이터 모델 | 운전자 화면 용어인 주배터리, 제어배터리, 상태알림, 경고/알람, BMS 상세, 저장폴더, 충전이상을 데이터 필드와 메뉴명에 반영한다. | 상 |
| BMS 상세 지표 표준화 | 셀 간 전압차, 최저 셀 전압, 최고 셀 전압, 온도 편차, Rack SOC/SOH, Warning/Fault를 표준 지표로 계산한다. | 상 |
| 알람-원시값 매칭 | Alarm 1~4, Warning/Fault, 상태비트, 운전자 화면 알람명을 동일 시간축으로 연결한다. 차량군별 코드표가 없으면 미확정으로 표시한다. |
상 |
| 충전/운행 상태 분리 | 충전제어패널의 충전중·충전완료·충전이상 상태와 운행 중 BMS 이벤트를 별도 세션으로 분리한다. | 상 |
| 반출 감사와 원본 보존 | 저장폴더와 USB 백업 방식이 기존 절차이므로, To-Be는 파일 해시, 복사 시각, 사용자, 실패 사유를 남긴다. | 중 |
| 현장 SOP 연동 | 화면 알람에서 바로 정비교범/운전자 매뉴얼의 관련 절과 점검 절차를 열 수 있게 한다. | 중 |
| 진단 커넥터 분리 관리 | Download 커넥터는 일반 운영 메뉴가 아니므로, 권한 있는 정비/제조사 진단 절차와 일반 분석 데이터 수집 절차를 분리한다. |
중 |
| 온프레미스 운영 | 서울교통공사 요구에 맞춰 외부 클라우드 의존 없이 현장 PC 또는 내부망 서버에서 동작하고, 반출 파일은 내부 정책에 맞춰 처리한다. | 상 |
¶ 17.5 현장 인터뷰와 실사에서 반드시 확인할 질문
| 질문 | 확인 이유 | 기대 산출물 |
|---|---|---|
| 차량정보 상태모니터의 실제 화면 버전과 차량별 차이가 있는가? | 문서와 현장 UI 버전이 다를 수 있다. | 차량별 화면 캡처 세트 |
BMS 버튼을 누르면 어떤 상세항목이 표시되는가? |
To-Be BMS 상세 화면의 필수 컬럼을 정한다. | BMS 상세 화면 항목표 |
저장폴더의 실제 경로, 파일명 규칙, 생성 주기는 무엇인가? |
자동 수집기 설계의 입력값이다. | 로그 경로·파일명 규칙 |
| USB 백업 시 권한, 절차, 보안 제한이 있는가? | 반출 감사와 사용자 권한 설계에 필요하다. | 반출 절차서 |
| 알람 상세 화면의 알람명과 Alarm 1~4/상태비트가 어떻게 연결되는가? | 분석 리포트에서 원시 비트를 운전자 언어로 번역해야 한다. | 알람 코드 매핑표 |
| 충전제어패널의 충전이상 이벤트가 로그에 남는가? | 충전 중 이상과 운행 중 이상을 분리해야 한다. | 충전 이벤트 샘플 로그 |
Download 커넥터는 현장 정비에서 실제 사용하는가? |
제조사 진단 경로와 PoC 데이터 수집 경로를 혼동하지 않기 위해 필요하다. | 진단 커넥터 사용 절차 |
¶ 18. 최종 판단
기존 BMS 관련 시스템은 배터리 팩 내부의 BMS, 차량컴퓨터/VCU, 운전자 조작판, 판넬PC/운영 PC, 로컬 로그 저장 계층으로 이어지는 차량 탑재형 구조로 보는 것이 타당하다. 문서상 BMS 상태정보는 차량컴퓨터에 전달되고, 저전압 등 주요 상태는 경고등과 잔량 표시로 운전자에게 제공되며, 판넬PC는 알람 상세 표시와 운전조작/알람 로깅을 수행한다.
추가 보완한 화면 근거를 반영하면, 기존 콘솔의 핵심 기능은 차량정보 상태모니터의 메인 대시보드, 알람 상세, BMS 상세, 저장폴더/USB 백업, 충전제어패널로 구성된다. 따라서 민관협력 PoC의 1차 방향은 새로운 BMS 또는 별도 계측 하드웨어를 추가하는 것이 아니라, 기존 운영 PC 또는 VCU 로그 저장 경로에서 데이터를 안전하게 확보하고, BMS CAN 값·알람·차량 운행 상태를 정비자가 이해할 수 있는 화면과 사고/고장/열화 리포트로 변환하는 것이다. 실증 전에는 운영 PC 화면, BMS 상세 화면, 저장폴더 실제 경로, USB 백업 절차, 알람 코드표, BMS 버전, 차량별 배터리 구성, 정비 이력을 한 세트로 확보해야 한다.