한세경 경북대학교 전기공학과 부교수 (공학박사)

▲한세경 경북대 전기공학과 부교수 (공학박사)
한세경
경북대학교
전기공학과 부교수
(공학박사)

[이투뉴스 칼럼 / 한세경] 배터리 미들웨어를 통한 ‘Battery-as-a-Service’

현재까지 알려진 ESS 화재사고만 30건 이상, 전기자동차의 경우 작년 한 해에만 20건이 넘는다. 조사단까지 꾸려졌지만 그 원인을 두고 배터리 셀 제조 불량이니 운용의 문제니 각자의 입장과 시각에 따라 다양한 얘기들을 한다. 필자도 관련 조사에 참여한 적이 있는데, 사실 이들의 주장 모두 맞는 말이다.

누군가 암에 걸려 말기 진단을 받고 사망하게 되었을 때 그 원인을 유전적(즉, 제조적)인 관점에서 찾을 수도 있고, 관리문제(흡연이나 음주 등)로 볼 수도 있다. 혹은 말기까지 발견을 못한 건강 진단시스템의 문제로 치부할 수도 있고, 수술 실패를 사망의 직접적 원인으로 볼 수도 있다. 모두 옳은 얘기이며, 배터리 사고 역시 이러한 관점에서 접근해야 한다. 즉, 생산, 운영관리, 진단, 그리고 사후대책 등 모든 측면에서 개선을 위한 노력이 이루어져야 하는데, 사고 이후 실제로 배터리 셀 품질 개선이나 소방 설비 의무화, 사고확산 방지를 위한 배터리 팩 기구설계 변경 등 생산과 사후대책 측면에서는 많은 개선이 이루어지고 있다.

그렇다면 운영관리와 진단 측면은 어떠할까? 일단 운영관리 개선책은 아주 단순하고 보수적으로 이루어지고 있다. 원래 100%를 쓸 수 있는 배터리를 80%까지만 쓰도록 강제하고 있다. 충전전류의 크기도 배터리 상태와 무관하게 일괄적인 수치로 제한하기도 한다. 암에 걸리지 않기 위해 담배를 줄이고 술을 줄이라는 것과 같은 처방이다. 방향적으로는 맞지만 과연 비싼 돈을 내고 산 배터리를 이렇게 보수적으로 운영하는 것만이 답인지는 생각해볼 측면이 있다.

또한 정도(degree)의 문제가 있다. 음주가 안 좋다 하지만 맥주 한잔이 문제인지 소주 한 병이 문제인지 일반화하기가 어렵다. 그렇다면 어느 정도가 과연 적절한가? 참 모호하다. 그 전까지는 100%로 운용하던 배터리를 갑자기 80%로 제한하면 사고가 안 날 것인가? 70%나 90%는? 그래도 사고가 난다. 따라서 이러한 막연한 제한 조치 대신, 객관화된 데이터 및 방법론으로 상태를 계량화하고 과학적인 배터리별 맞춤 운용 방안이 마련돼야 한다.

이러한 운영관리 체계화보다 더 중요한 것은 사실 진단 기능의 강화다. 아무리 건강한 라이프 스타일을 가졌다 하더라도 병에 걸릴 확률이 0이 아닌 이상, 발병 전이나 발병 후라도 문제가 심화되기 전에 적절한 조치를 취할 수 있도록 빨리 진단해내는 것이 중요하다. 그런데 현재까지는 앞서 언급한 다른 노력들 대비 배터리 진단기능 개선이 가장 미진한 것이 현실이다. 기껏해야 사후적 분석을 위해 배터리 전압, 전류 등을 원론적 차원에서 일정기간 보관하도록 의무화고 있을 뿐이다.

사실 이는 노력 부족이라기보다 진단 역량의 부족으로 보는 것이 타당할 것이다. 현재의 배터리 관리 시스템, 즉 BMS가 어떻게 만들어지고 동작하는지를 보면 그 이유를 알 수 있다. 지금까지의 BMS는 기본적으로 개별 시스템에서 독자적으로 동작하는 일종의 스탠드얼론 임베디드 장치(Stand-alone embedded device)이다. 메모리, 계산 능력이 일반적인 PC 수준에도 못 미칠 만큼 떨어져 복잡한 로직을 적용하기 어려운 데다 제한적 사전 시험 데이터를 기반으로 동작하고 있어 근본적으로 배터리 상태변화나 이상진단 등 고차원적인 동작을 할 수 없다. 최근 유행하는 엣지컴퓨팅(Edge computing)처럼 하드웨어적 보강을 시도해볼 순 있겠지만 여전히 제조사나 모델별로 특성이 다른 배터리에 대한 데이터가 부족하기 때문에 근본적인 성능개선이 이루어지기 어렵다. 사전 시험을 통해 특정상황에서의 현상을 이해할 순 있어도 배터리별로 천차만별인 동작환경과 노후화에 따라 달라지는 전기적 거동을 실험실의 몇 줄 데이터로는 일반화할 수 없기 때문이다.

번역이나 음성 인식 등도 전통적으로는 미리 학습된 데이터에 기반해 로컬장치에서 수행하다보니 성능이 수십 년 간 답보상태였었다. 하지만 온라인 기반의 빅데이터 플랫폼에서 이러한 작업을 수행하도록 패러다임을 바꾼 후 불과 몇 년 만에 드라마틱한 발전을 이루게 되었다. 마찬가지로 배터리관리시스템도 이러한 패러다임의 변화가 필요한 시기가 되었다. 기존의 핸드폰이나 노트북과 같이 작은 장치에서는 배터리 수명보다 기기 수명이 먼저 도래하는 경우가 흔했고 셀의 용량이나 숫자도 작아 대형 사고로 이어지는 경우가 드물었기에 임베디드 기반의 로컬 BMS로도 충분했다. 하지만 수백, 수천 개 단위의 셀이 조합되는 전기차나 ESS 등에서는 기존 형태의 BMS로는 성능개선의 한계에 다다른 것이 최근 일련의 사고를 통해 목도되고 있다.

그렇다면 단순히 데이터를 온라인 서버에 모으기만 하면 될까? 앞서 언급한 분석용 데이터 수집장치(블랙박스)를 클라우드상에 구현하기도 하는데, 이를 클라우드 BMS라고 부를 수는 없다. 엄밀한 의미에서 클라우드 BMS란 단순히 데이터 저장만이 아닌 기존 BMS가 수행하는 배터리 상태진단, 운영 등을 클라우드에서 실시간 서비스 형태로 수행할 수 있어야 한다. 이에 더해 배터리별로 다른 구동환경과 이에 따른 상태변화를 운영데이터 기반으로 스스로 학습할 수 있어야 하고 배터리의 다양한 상태추정이 온라인에서 동적으로 이뤄질 수 있어야만 진정한 의미에서의 클라우드 BMS라 할 수 있다.

이를 위해서는 데이터 수집, 전처리, 가공, 학습, 그리고 상태추정 서비스까지 체계적이고 효율적으로 일어날 수 있도록 구조화되고 표준화된 형태의 미들웨어 플랫폼 설계가 뒷받침돼야 한다. 배터리에 직접 장착된 로컬 BMS는 데이터의 실시간 수집과 처리, 1차 가공 등을 담당하며, 클라우드는 이를 기반으로 다양한 배터리 관련 특징인자들을 추출하고 통계화해 학습해 나아갈 수 있어야 한다. 그리고 지능화된 상태추정 결과들이 다시 로컬 BMS 로 피드백되며 상호 유기적인 배터리 운영이 가능해야 한다. 또한, 서비스 알고리즘 설계자가 데이터 취득방식이나 결과 처리, 데이터베이스(DB)와 연동 등을 신경 쓰지 않도록 표준화된 미들웨어 형태로 서비스 플랫폼이 설계돼야 한다. 이러한 형태의 배터리 관리 시스템을 진정한 의미에서의 ‘Battery-as-a-Service’라 부를 수 있을 것이다.

미들웨어 플랫폼 기반의 서비스 사례로 대표적인 배터리 상태 값 중 하나인 SoC(충전량) 추정을 들어보자. SoC 추정치는 필연적으로 배터리의 용량에 따라 값이 달라질 수밖에 없는데, 배터리의 용량은 온도, 전류 크기 등의 구동환경뿐 아니라 노화에 따라서도 그 값이 가변적이다. 하지만 통상의 BMS는 배터리 용량 자체는 고정된 값으로 가정하고 로직을 설계하기 때문에 아무리 뛰어난 SoC 알고리즘이라 하더라도 실제 환경에서는 오차를 수반할 수밖에 없게 된다.

이를 극복하기 위해서는 SoC 알고리즘 구현 시 배터리의 실질 용량 추정을 함께 실시해야 하는데 이 역시 만만한 일이 아니다. 실질 용량 추정은 전류의 적산치나 전압 변화 등 로컬 BMS가 취득한 센서 값에 민감할 수밖에 없는데, 센서에는 계량화되지 않는 BMS 자체의 소모전류 같은 암전류나 센서 자체의 바이어스 값 등으로 인해 센싱 오차가 존재할 수밖에 없다. 이러한 오차를 극복하기 위해선 다양한 수학적 방법론을 적용해 필터 등 센싱 오차를 극복하기 위한 노력이 선행돼야 하며, 결국 이는 하드웨어 구성이나 구동환경에 대한 이해 없이는 극복하기 어렵게 된다.

결과적으로 SoC 서비스 하나를 만들기 위해서는 구동 환경에 대한 이해나 데이터 처리, 보정, 가공, 그리고 선행 배터리 관련 상태추정 등 거의 모든 것을 이해하고 다뤄야하므로 SoC 알고리즘 연구자가 다루기 쉽지 않고 통상 펌웨어 개발자가 하드웨어에 대한 이해를 기반으로 단순로직으로 설계할 수밖에 없게 된다. 하지만 마치 JAVA나 .NET 프레임웍이 구동환경에 대한 추상화를 통해 응용 프로그램 개발자에게 표준화되고 편리한 개발환경을 제공하듯이 Battery-as-a-Service를 위한 플랫폼이 이러한 미들웨어 형태의 기능을 제공한다면 서비스 개발자는 해당 알고리즘 자체에 집중하며 훨씬 고도화된 성능을 구현해낼 수 있게 된다.

배터리 미들웨어는 각 서비스가 배터리 구동데이터 취득을 위한 데이터베이스 접속이나 형식에 대한 지식 없이도 이들 데이터를 획득할 수 있도록 표준화된 형태의 데이터 입출력구조를 제시해야 한다. 또한 데이터의 전처리나 기계학습, 통계화(예: 셀-셀 간 혹은 셀-전류 간 상관계수, 분산치 등) 등이 손쉽게 수행될 수 있도록 다양한 유틸리티 서비스도 제공해야 한다. 서비스 프레임웍 역시 데이터의 성격에 따라 실시간성을 요하는 경우, 주기성을 요하는 경우, 다른 서비스의 결과물이나 특정 이벤트에 연계돼 동작하는 경우 등 다양하면서도 효율적인 형태로 서비스가 구현될 수 있도록 설계돼 있어야 한다.

바야흐로 사물인터넷(IoT. Internet-of-Things) 시대다. 말 그대로 모든 기기가 인터넷에 연결되는 초연결 시대에 대규모 셀 조합으로 이루어지는 전기차나 ESS 등의 대형 배터리 장치가 스탠드얼론으로 동작하는 BMS에 의존한다는 건 시대에 뒤떨어진 조치다. 이제 배터리는 독립 장치라는 기존의 사고를 벗어던지고 Battery-as-a-Service 플랫폼 형태의 운영관리와 진단을 위한 노력이 이루어져야 한다.

저작권자 © 이투뉴스 무단전재 및 재배포 금지