전형적인 HEV 제어기 개발 과정

보다 효율적이고 경제적인 HEV를 개발하기 위한 도전은 계속되고 있다. 이 점은 완성차 업체들이 일반적으로 하이브리드 파워트레인을 개발하는 데 협력하지 않는 이유이기도 하다. HEV가 시장에서 빠른 시간 내에 성공하기 위해서는 완성차 업체의 파워트레인을 완전히 재설계하거나 대폭 변경하지 않고 새로운 기술을 적용하는 것이 중요하다. 또한 HEV 개발은 하이브리드화의 정도(마이크로, 마일드, 풀 하이브리드)와 구조(시리즈, 패럴렐 또는 분할)에 따른다.
개발 과정은 일반적으로 하이브리드화 정도와 구조를 포함하는 개념 설계에서 시작되고 각종 하이브리드용 시뮬레이션 툴(PSAT, Simulink, GT-Drive, DYNA4 등)을 사용하는 단계로 이어진다.
이 단계에서 엔진의 크기, 변속기의 구조 등이 결정되고 동력 성능, 연비, 배기가스 등이 최적화된다. 또한 배터리 충방전 사이클, 회생제동 또는 HEV 제어기 개발에 중요한 변속기 기어 변속 등에 대한 정보도 전달해준다. 동시에 완성차 업체는 전자제어기(ECU)의 구조도 결정하게 된다. 어떤 경우에는 기존의 ECU에 하이브리드와 관련된 기능을 추가하기도 하고 완전히 새로운 ECU를 개발하는 경우도 있다. 전형적인 하이브리드 ECU의 구조를 그림 1에서 확인할 수 있다.
대부분의 경우에 HEV 제어기 개발은 기존의 가솔린/디젤 ECU 개발 과정과 동일하다. 하이브리드 카를 위한 엔진 제어기(Engine Control Module, ECM)의 경우, 약 80%의 기본 ECM 코드와 공유하며 나머지 20% 정도의 코드가 하이브리드 기능을 위한 전용 코드로 되어 있다(전용 코드의 예: 회생제동, 파워 모드 등). 추가적인 하이브리드 기능은 하이브리드에 대한 지식을 갖춘 전문가에 의해 수작업으로 작성되는 경우가 많다.
또한 1세대 HEV 차량을 위한 하이브리드 제어기(HCU)나 배터리, 모터 제어기(BCU, MCU)용 소프트웨어도 대부분 수작업으로 작성되었다. 이것은 하이브리드 프로젝트에 따른 개발 기간에 대한 압박을 가중시켰고, 하이브리드 개념을 검증하기 위한 충분한 자원과 시험 차량이 제공되는 상황에서 가능한 방법이었다. 그러므로 대부분의 완성차 업체는 1세대의 HEV 개발 시 일반적인 ECU 개발을 위한 V 사이클을 따르지 않았다. 모델 기반 개발은 충분히 활용되지 못했고 RCP(Rapid Controller Prototyping)은 많이 사용되지 않았으며 HIL(Hardware-In-the-Loop) 검증은 부분적으로 사용되었다.

HEV 제어 시스템 개발자가 직면한 과제

초기 하이브리드 소프트웨어 개발에 V 사이클이 적용되지 않았기 때문에 개발자는 “개선해야 할(clean-up)” 많은 과제물을 떠안게 되었다. 예를 들면 하이브리드 엔지니어는 중앙 집중적 소프트웨어 개발 과정을 거치지 않고 메인스트림에 포함되지 않는 ECM 코드의 개별 명세를 만듦으로써 코드에 대한 독자적인 책임을 지게 되었다.
이제 OEM에서 하이브리드 카 개발이 점차 파워트레인 개발의 핵심 과제가 됨으로써 ECM의 개별 명세는 다시 표준화된 프로세스로 통합되어야 할 필요가 생겼다. 이 점은 수작업 코딩을 하고 있는 하이브리드 카 개발 과정을 자동 코드 생성이 가능하고 차기 프로그램 개발에 재사용 가능한 그래픽 모델 형태로 바꿀 것을 요구하고 있다. 게다가 하이브리드 카는 가솔린차나 디젤차 기술 발전에도 도움이 될 것이다.
하이브리드 카 개발 엔지니어가 직면한 또 다른 과제는 전기 모터, 배터리, 그리고 제너레이터/인버터를 제어하는 추가된 여러 ECU로부터 야기되는 전반적인 하이브리드 카 시스템 구성상의 복잡성에서 벗어나는 것이다. 각각의 ECU를 실제 사용환경에서 시험하는 것이나 CAN 네트워크 상에서 ECU들의 상호작용을 시험하는 것 차제가 어려운 일이다. 게다가 하이브리드 카 개발은 각각의 고유한 전문지식, 개발 장비, 그리고 개발 과정에 따라 여러 그룹으로 분리되어 있다.