모델 기반 설계(Model-Based Design, MBD)는 자동차 제어기 및 소프트웨어를 개발하는 데 있어 확고한 솔루션으로 자리잡았다. 소프트웨어 및 시스템 모델은 개발 공정 전반에서 실행 가능한 사양으로 사용되어, 하드웨어와 소프트웨어의 설계, 개선, 최적화, 테스트, 검증을 가능하게 한다.
배터리 전기 자동차(BEV)는 일반적으로 재생 에너지에서 공급되는 전력을 활용해 탄소 중립적이며 지속 가능한 운송을 실현하는 데 도움을 준다. 고객은 BEV 배터리팩이 안정적이고 효율적이며 오래 가고 안전하기를 기대한다. 이를 보장하는 제어기가 BMS(배터리 관리 시스템)이다. BMS는 배터리팩의 작동을 모니터링하고, 성능을 최적화하며, 개별 셀 간의 불균형을 바로잡고, 조기 노화를 방지하며, 안전한 작동을 보장한다. 자동차 제조사와 공급사는 ISO 26262와 특히 ASIL D와 같은 표준을 준수하는 워크플로우를 사용해 BMS를 효과적으로 개발, 테스트, 검증 및 인증해야 한다.
모델 기반 설계(Model-Based Design, MBD)는 자동차 제어기 및 소프트웨어를 개발하는 데 있어 확고한 솔루션으로 자리잡았다. 소프트웨어 및 시스템 모델은 개발 공정 전반에서 실행 가능한 사양으로 사용되어, 하드웨어와 소프트웨어의 설계, 개선, 최적화, 테스트, 검증을 가능하게 한다. 이러한 모델은 직관적인 디지털 스레드를 형성하며, 이후 시스템의 사용자 지정과 추가적인 개발을 위해 재사용될 수 있고, 지속적 설계와 모니터링 또는 사고 대응을 위한 디지털트윈으로 재사용될 수 있다.
NXP는 반도체를 설계하고 제조하는 기업으로, 특히 자동차 프로세서 분야의 디지털 솔루션을 공급하고 있다. 모터 제어기나 BMS와 같은 임베디드 시스템 설계의 현재 과제를 해결하기 위해, NXP는 매스웍스의 매트랩(MATLAB)과 시뮬링크(Simulink)의 생태계를 NXP의 프로세서 제품군과 연결하는 툴인 모델 기반 설계 툴박스(Model-Based Design Toolbox, MBDT)를 제공한다. 이 툴박스는 모델 기반 시스템 설계, 하드웨어 구현 및 검증을 연속적인 툴체인으로 통합한다.
.jpg)
그림1. NXP의 Model-Based Design Toolbox의 주요 컴포넌트 개요
MBDT는 매트랩과 시뮬링크에서의 알고리즘 개발을 가속화하고 NXP 프로세서에서의 프로토타이핑을 지원하도록 설계된 툴 및 라이브러리 모음이다. MBDT를 사용하면 NXP 프로세서에서 애플리케이션을 구성, 생성 및 배포할 수 있으며, NXP의 S32 컨피규레이션 툴(S32 Configuration Tools)과 같은 외부 구성 툴을 사용해 핀, 클록, 주변기기를 설정할 수 있다.
또한, MBDT는 NXP의 실시간 드라이버(RTD)를 기반으로 오토사(AUTOSAR) 및 비오토사 애플리케이션을 위한 코드를 생성한다. MBDT는 임베디드 코더(Embedded Coder)를 사용해 MIL 테스트를 수행하거나, SIL, PIL, HIL 검증 및 확인을 위해 타깃으로 직접 다운로드할 수 있다. 또한, 서비스 지향 차량 소프트웨어 아키텍처로의 전환을 위해 오토사 어댑티브(AUTOSAR Adaptive)도 지원한다. MDBT에는 학습 목적뿐 아니라 사용자 지정 구현의 시작점이 될 수 있는 다양한 예제를 함께 제공한다.
하드웨어
NXP는 ISO 26262/ASIL D 등의 준수를 포함해 고전압 배터리 관리 시스템(HVBMS) 개발을 완전히 분석되고 문서화된 참조 설계를 제공한다. 참조 설계는 테스트, 구현 및 프로토타이핑을 위한 전체 하드웨어 솔루션을 포함한다. 파일 익스체인지(File Exchange, https://www.mathworks.com/matlabcentral/fileexchange)에서 제공되는 리튬-이온 배터리 설계, 테스트용 매스웍스 BMS 모델 및 S32K3 MCU를 기반으로 한 참조 설계는 자동차 시스템에 HVBMS 소프트웨어 및 하드웨어를 통합하는 과정을 단순화하고, 안정적이며, 빠르게 수행한다.
하드웨어 패키지는 배터리 관리 장치(Battery Management Unit, BMU), 셀 관리 장치(Cell Management Unit, CMU), 배터리 정션 박스(Battery Junction Box, BJB)의 세 가지 제어 보드로 구성된다. CMU는 다른 모든 BMS 모듈의 데이터를 처리하고, 셀 밸런싱을 수행하며, 안전성을 보장하기 위한 의사결정을 내린다. BMU는 차량 제어 장치(Vehicle Control Unit, VCU)와 통신하고 배터리를 인버터와 모터 또는 충전기에 연결하는 접촉기를 작동시킨다.
.jpg)
그림 2. HVBMS 설계 및 프로토타이핑을 위한 NXP 하드웨어 참조 설계
BMU는 셀 전압, 온도, 전류를 측정하고 최대 300mA의 전류로 셀의 균형을 맞춘다. BMU의 배터리 셀 제어기(Battery Cell Controller, BCC)는 데이지체인 방식으로 직렬 연결되어 있어, 더 많은 장치를 추가해 배터리 시스템을 확장할 수 있다.
BJB는 BMS 전체에 걸쳐 여러 고전압을 측정하고, 시스템의 전류를 정확하고 중복적으로 측정하며, 안전을 위해 배터리와 섀시 간의 절연 저항을 모니터링한다. BJB는 분리 전기 전송 프로토콜(Isolated Electrical Transport Protocol, IETP)을 사용해 BMU와 통신한다.
워크플로우
MBDT, 하드웨어 참조 설계, 매스웍스 툴로 만들어진 워크플로우는 요구사항부터 최종 구현까지 통합 솔루션을 제공한다.
그림 3. 매스웍스 생태계에서 NXP 제공 솔루션으로의 전환을 확인할 수 있는 MBD를 사용한 HVBMS 설계 워크플로우 개략도
모델 인 더 루프(Model-in-the-Loop, MIL)
이 단계에서는 데스크탑을 사용해 소프트웨어 및 하드웨어 요구사항으로부터 BMS를 설계하고 컴포넌트로 분할한다. 위에서 언급된 예시 BMS가 시작점으로 사용된다. 이는 단순한 등가 회로부터 특정 유형의 물리 배터리의 완전히 파라미터화된 표현에 이르기까지 다양한 배터리 모델을 대상으로 개발됐다.
이 단계에서는 애플리케이션의 전체 제어 전략을 결정하고, 이후 모델을 서로 비교 실행해 테스트한다. 시뮬링크 데이터 인스펙터(Simulink Data Inspector)를 사용하면 모든 관련 파라미터를 예상 값과 비교해 확인할 수 있다. 초기 테스트는 설계 오류를 감지해 수정하는 데에 필요한 더 많은 노력과 재작업을 방지한다.
소프트웨어 인 더 루프(Software-in-the-Loop, SIL)
초기 설계가 요구사항을 충족하고 올바르게 작동하면, 제어기 코드가 처음으로 생성된다. 임베디드 코더는 BMS 모델에서 C 코드를 생성하고, 이는 데스크탑에서 실행되고 배터리 모델에 대해 작동하는 오브젝트 파일로 컴파일된다.
이 단계에서는 모델을 C 코드로 변환할 수 있는지 확인하고 엔지니어가 필요한 부분을 수정할 수 있도록 한다. 또 다른 기능은 C 코드가 시뮬링크 모델과 정확히 동일하게 동작하는지 검증하는 것이다. 이후 최초 실행 프로파일링 데이터를 수집할 수 있다.
그림 4. 임베디드 코더를 사용한 코드 생성, 실행 결과 및 리포트
프로세서 인 더 루프(Processor-in-the-Loop, PIL)
다음으로, BMS 모델에서 C코드가 다시 생성되지만, 이번에는 크로스 컴파일된다. MBDT는 이 코드를 하드웨어 참조 설계 평가 보드에 직접 다운로드하고 시뮬링크의 SIL/PIL 탭에서 배터리 모델에 대해 자동으로 실행하는 기능을 포함한다. 코드가 성공적으로 다운로드 되었는지는 코드 프로파일링 데이터 아래에 표시되는 메시지 상자로 확인할 수 있다.
시뮬링크 데이터 인스펙터를 사용하면 결과를 시각화하고 프로세서에서 SIL 테스트와 비교해 알고리즘을 검증할 수 있다. 코드 프로파일링 데이터는 실행 시간과 함께 메모리 및 스택 사용량을 표시해 프로세서가 제어기 코드를 처리할 수 있는지 확인할 수 있다.
지금까지의 과정은 물리적 배터리나 배터리 에뮬레이터를 필요로 하지 않는다. 따라서 엔지니어는 의도한 용도와 사양에 따라 타당한 데이터를 제공하는 배터리 스택의 참조 모델에 대해 알고리즘을 설계할 수 있다. 이는 개발 속도를 높이고 프로토타입 제작의 필요성을 없앤다. 또한 배터리 모델에 대한 테스트를 통해 BEV에 전력을 공급할 수 있는 스택에 대한 새로운 제어 알고리즘을 테스트할 때 발생하는 화재나 기타 고비용 손상과 같은 위험을 방지한다.
그림 5. 데스크탑 시뮬레이션 대신 프로세서에서 실행되는 생성 코드
하드웨어 인 더 루프(Hardware-in-the-Loop)
최종 테스트 단계에서는 BMS 알고리즘이 프로세서에서 실시간으로 실행된다. 코드는 이전과 같은 방식으로 생성되지만, 이제는 스피드고트(Speedgoat) 머신과 같은 실시간 하드웨어에서 실행되는 배터리 모델이나 배터리 에뮬레이터에 대해 실행된다. 엔지니어는 물리적인 배터리 프로토타입 없이도 모델을 안전하게 테스트할 수 있다.
이 단계의 목적은 최종 BMS 설계를 실시간으로 검증해 실제 시나리오에서도 이전 단계와 동일한 결과를 제공하는지 확인하는 것이다. HIL은 신호 감쇠나 지연과 같은 물리적 통신 채널 및 입출력 인터페이스와 관련된 문제를 식별하고, 이러한 문제가 제어기의 성능과 BMS를 안전하게 제어하는 능력을 저해하는지 확인하는 데 도움을 준다.
프로토타이핑
이 마지막 단계는 일반적으로 실제 배터리 스택을 대상으로 수행된다. BMS 알고리즘이 안전하고 ASIL D를 준수하더라도, 프로토타이핑에는 상당한 설정 시간과 비용이 소요될 수 있다. 프로토타이핑을 쉽게 만들기 위해 NXP는 하드웨어 참조 설계 패키지와 함께 배터리 셀 에뮬레이터를 제공한다. 배터리 셀 에뮬레이터는 물리적인 배터리 스택과 동일하게 작동하도록 전자 장비를 갖추고 있지만, 다양한 가변저항이 장착되어 다양한 셀 전압을 모방할 수 있다.
이를 통해 여러 운영 및 결함 상태에서 테스트를 수행할 수 있다. 또한, NXP 평가 보드에는 손상된 셀을 시뮬레이션하기 위해 압력 센서 등의 센서를 연결할 수 있는 옵션이 포함되어 있다.
그림 6. 엣지 및 클라우드 연결과 하드웨어 참조 설계, 연결된 설계, 모니터링 장비를 포함한 전체 프로토타이핑 설정
전체 설정은 HVBMS 참조 설계를 포함하며, 모니터링과 전류 조정을 위한 엣지 기기로 NXP 프리마스터(NXP FreeMASTER)에 연결하거나 차량 네트워크 툴박스(Vehicle Network Toolbox)를 사용하여 CAN 통신으로 연결할 수 있다. 랩탑에서 실행되는 HVBMS 모델은 시뮬링크 외부 모드를 사용해 UART로 연결할 수 있어 실시간 수정과 즉각적인 결과 평가를 위한 코드 재생성이 가능하다. 기본 하드웨어 참조 설계에 NXP S32G 골드박스(NXP S32G Goldbox)가 추가되어 CAN으로 연결되며, 이는 매스웍스 클라우드 서비스(MathWorks Cloud Service) 또는 AWS IoT 플릿와이즈(AWS IoT FleetWise)에 액세스하는 데 사용된다.
CAN을 통해 배터리 셀 에뮬레이터의 전위차계를 조정하고 NXP 프리마스터에서 팩 전류나 온도를 설정함으로써 엔지니어는 셀 불균형, 과전압과 부족전압, 과전류와 저전류를 시뮬레이션하고 결과를 즉시 확인할 수 있다. 이 설정을 사용해 고가의 장비나 배터리 프로토타입이 손상될 위험 없이 HVBMS을 미세 조정할 수 있다.
핵심: 충전 상태(State-of-Charge, SoC) 추정
BMS의 가장 까다로운 작업 중 하나는 배터리팩의 SoC를 파악하는 것이다. 배터리 전압은 충전, 온도, 배터리의 상태나 수명으로 구성된 함수이므로 SoC를 직접 측정할 수 없다. 정의된 SoC의 배터리를 사용하고 발생한 충전 및 방전 전류(전류 적산법)를 통합하는 것은 간단해 보이지만, 이는 배터리 수명이 길어질 경우 실현 불가능하다. 배터리 노화와 환경적 조건으로 인한 전류 측정의 부정확성은 점점 증가할 수밖에 없으며, 이는 불안전성, 수명과 효율성 감소, 잠재적 위험을 초래하는데, 이는 고무결성 시스템에서 허용되지 않는다.
SoC를 추정하는 대표적인 방법은 확장 칼만 필터(Extended Kalman Filter, EKF)을 사용하는 것으로, 이는 배터리에서 발생한 전류, 전압 및 온도의 측정값을 사용해 SoC를 지속적으로 예측한다. 이 재귀적 SoC 추정을 위해서는 작동 및 환경적 조건 등 셀의 정확한 동적 모델이 필요하다. 이는 자원 집약적이고, 프로세서 부하와 요구사항이 증가시키며, 각 새로운 셀의 유형에 대해 파라미터화가 필요하다. SoC 추정의 대안은 딥러닝 기반 신경망(Neural Network, NN) 알고리즘을 사용하는 것이다. 이 알고리즘은 다양한 조건에서 수집된 전류, 전압, 온도에 대한 충분한 실험 데이터로 훈련되어야 한다.
그림 7. 가져오기, 내보내기, NN 훈련을 위한 MATLAB 옵션
매트랩은 케라스(Keras), 텐서플로우(TensorFlow), 카페(Caffe), 온엑스(ONNX) 포맷 등 널리 사용되는 툴을 통해 머신러닝과 딥러닝을 위한 NN을 구현하고, 가져오고 내보낼 수 있는 다양한 옵션을 제공한다. NN 전문가들은 매트랩에 더 익숙한 엔지니어들과 작업을 공유할 수 있어, 이러한 네 NN을 모델에 통합할 뿐만 아니라 강화 학습을 사용해 재훈련시키거나 개선할 수도 있다.
온타리오주 해밀턴에 위치한 맥마스터 자동차 자원 센터(McMaster Automotive Resource Centre)의 카를로스 비달(Carlos Vidal)과 필립 콜메이어(Phillip Kollmeyer)는 이러한 알고리즘이 SoC를 정확하게 예측할 수 있고 칼만 필터보다 자원 효율적이며 약간의 수정으로 다양한 셀 형식에 적용될 수 있다는 점을 입증했다. 이 구현에는 55개의 뉴런만이 필요하다. 이 알고리즘의 설계와 배포에 대한 기본 사항은 매스웍스 웹사이트에 게재된 ‘배터리 충전 상태를 딥러닝을 활용해 추정하는 방법’ 웨비나에서 설명됐다. 프로젝트에서 수집된 훈련 데이터는 데이터 리포지터리 플랫폼 '멘델레이 데이터(Mendeley Data)’에서 사용 가능하다.
여기서 제시된 HVBMS 모델은 시연을 목적으로 EKF 필터와 NN 알고리즘을 모두 포함한다. NN과 EKF는 앞서 시뮬레이션 결과에서 표시된 것처럼 모두 실제 SoC와 일치한다. 하지만 위에서 설명한 대로 NN이 더 효율적인 구현 방법이다.
그림 8. NN(상단)과 EKF(하단)으로 구현된 SoC 추정기(빨간색)
CAN 메시지를 통한 클라우드 서비스 사용
설명된 워크플로우의 옵션 중 하나는 NXP S32G 골드박스와 같은 CAN 버스를 사용해 웹 서비스에 연결하는 것이다. 이를 통해 엔지니어는 매스웍스 웹서비스(MathWorks Web Services) 또는 AWS IoT 플릿와이즈를 사용해 현장에서 실시간 차량 데이터를 수집하고 분석할 수 있다. 이를 위해 차량과 차량의 센서가 클라우드에서 모델링되어야 하며 데이터 수집 방식이 정의되어야 한다. 엣지 에이전트는 이러한 데이터를 수신하고 클라우드 서비스로 전송한다.
이러한 데이터를 사용하는 한 가지 방법은 차량 데이터를 수집해 소프트웨어의 다른 부분이나 SoC 추정에 사용되는 NN 알고리즘을 개선하는 것이다. 특히, 딥러닝 및 머신러닝 애플리케이션은 이 접근법에 유용하다. 또 다른 옵션은 이러한 데이터를 사고 대응에 사용하는 것이다. 한 대 이상의 차량이 예상하지 않은 동작이나 결함을 발생시키는 경우, 영향을 받은 시스템 또는 차량의 디지털트윈을 사용해 이를 분석할 수 있다.
결함이 발생한 조건을 재구성하고 각 모델을 시뮬레이션함으로써 이것이 일반적인 문제인지 판단하는 해결책을 찾을 수 있다. 두 경우 모두 영향을 받은 차량에 무선(OTA) 업데이트를 제공하는 것이 가능하다. 일반적인 문제인 경우, 엔지니어는 임시로 수정한 뒤 영구적인 해결책을 개발할 수 있다. 또한 현장 데이터를 사용해 배터리의 용량 손실을 평가하고 셀 밸런싱이나 향상된 충전 동작을 위한 더 나은 전략을 개발해 차량 상태를 유지할 수도 있다.
이러한 모든 활동은 기존의 자동차 소프트웨어 개발에서 더욱 민첩한 데브옵스(DevOps) 접근법으로 전환하는 데 기여할 수 있다. 이는 최종적으로 소프트웨어로 정의된 기능을 갖춘 차량인 SDV(소프트웨어 정의 차량)를 실현할 수 있게 하며, 지속적으로 업데이트와 최적화가 수행하고 맞춤화를 가능하게 한다.
배포된 차량의 소프트웨어 시스템을 개선하려면 엔지니어가 수집된 데이터를 디지털 트윈으로 작동하는 설계 모델에 적용해야 하고 이 문서에서 설명한 워크플로우를 다시 실행해야 한다. 엔지니어는 데이터 분석, 테스트 케이스 실행, 프로세스 구축과 같은 공정을 최대한 자동화하여 효율성을 높일 수 있다. 클라우드 서비스는 자동차 제조사가 SDV를 위한 DevOps 확립, 서비스 지향 아키텍처를 탑재한 차량에 필요한 소프트웨어 팩토리로의 전환, 최종적으로 자율주행으로 나아가는 데 중요한 도구이다.
글: 이웅재, 매스웍스 코리아 이사
<저작권자(c)스마트앤컴퍼니. 무단전재-재배포금지>