글로벌오토뉴스

상단배너

  • 검색
  • 시승기검색
ä ۷ιλƮ  ͼ  ī 󱳼 ڵδ ʱ ڵ 躴 ͽ ǽ ȣٱ Ÿ̾ Auto Journal  Productive Product

[오토저널] 가상차량 프로토타입 구성과 연동시뮬레이션 유형

페이지 정보

글 : 오토저널(ksae@ksae.org) ㅣ 사진 : 원선웅(mono@global-autonews.com)  
승인 2020-11-06 10:28:10

본문

전통적인 차량개발 프로세스에서는 설계를 마치고 양산을 시작하기에 앞서, 실차검증을 위한 시험차량을 수작업으로 제작한다. 시점상으로는 <그림 1>에 나타난 프로세스(화살표)에서 ‘1st Prototype’으로 명명한 지점에 해당한다. 이때 제작하는 시험차량을 차량 프로토타입(Vehicle prototype)이라 하며, 차량제조사는 이를 이용해 부품 장착성, 설계상 오류, 목표성능, 법규대응항목 등의 사항을 양산 전에 미리 점검할 수 있다. 더 많은 시험차량을 제작할수록 더 많은 시험을 수행할 수 있어 보다 완성도 높은 차를 생산할 가능성이 커진다. 하지만 제한된 개발기간과, 한대당 수억원에 달하는 차량 프로토타입 가격으로 인해 시험차량 제작을 무작정 늘이는데는 한계가 있다.

 

민첩한 개발방법론을 적용한 모델기반 차량개발 프로세스에서도 차량 프로토타입과 유사한 성격의 시험차량모델이 필요하다. 가상차량 개발환경에서 활용하는 시험차량모델이므로 이를 가상차량 프로토타입(Virtual Vehicle Prototype)이라 부른다. 가상차량 프로토타입 구성의 주목표는 빠른 개선을 통한 차량개발주기의 단축이다. <그림 1>에 나타난 것처럼 차량시스템 검증과정을 개발프로세스 초기부터 반복수행 할 수 있다면, 개발환경변화에 민첩하게 대응할 수 있을뿐만 아니라, 친환경차/자율주행차로 인해 비현실적으로 증가한 개발요구사항을 보다 효과적으로 만족할 수 있다.

f14ddd37a109350a62ddd8c4e0a8b25d_1604626

차량부품을 일일이 조립하는 차량 프로토타입 제작과는 다르게, 가상차량 프로토타입은 도메인별 하위모델을 가상의 차량모델로 통합해 구성한다<그림 2 단계4-5>. 완성한 가상차량 프로토타입을 이용해 차량개발목표(연비, 스펙 등)를 평가하기 위해서는 통합차량모델을 단일시스템으로 해석하는 연동시뮬레이션 기법을 적용해야 한다. 따라서 가상차량 프로토타입을 효과적으로 구성하고 활용하려면 연동시뮬레이션 기법에 대한 자세한 이해를 갖출 필요가 있다.

본 고에서는 가상차량 프로토타입 구성방법을 연동시뮬레이션 유형을 바탕으로 자세히 알아보고, 가상차량 프로토타입을 평가하는데 있어 고려할 사항은 무엇인지 간단히 살펴보고자 한다.

연동시뮬레이션 유형
아직까지는 연동시뮬레이션 유형을 명확히 구분하기 애매하다. 연동시뮬레이션 기법이 아직 충분히 성숙하지 못했을 뿐만 아니라 산업계별로 필요한 연동시뮬레이션 성격과 시스템 특성이 다르기 때문이다. 따라서 모델을 통합하고 해석할 때 맞닥뜨릴 수 있는 몇몇 상황들을 기준으로 그 유형을 구분해 보고자 한다. 모델을 통합해 해석하고자 할 때 흔히 던질 수 있는 질문은 다음과 같다.

•하위모델을 몇개로 구분할 것인가?
•하위모델을 어떤 방식으로 연결할 것인가?
•하위모델별 솔버/솔버단위시간을 통일해야 하는가?
•통합모델과 실제 하드웨어간 연동이 필요한가?

위 질문을 통해 연동시뮬레이션의 다양한 유형을 정의할 수 있고, 효과적인 연동시뮬레이션 전략을 세우는 것이 가능해진다.

●모델 통합 방식에 따른 구분
전통적인 모델통합 방식으로 ‘들여오기(Import) /내보내기(Export)’ 기능이 있다. 연동시뮬레이션을 수행할 마스터 소프트웨어(Master Software) 모델을 선정하고 나머지 모델은 마스터 소프트웨어로 들여와(Import) 통합하는 방식이다. 각 소프트웨어마다 들여오기/내보내기 기능을 구현해야 하므로 이러한 방식을 코드기반 연동시뮬레이션이라 한다. 코드기반 연동시뮬레이션에서는 모델정보 교환을 용의하게 하기 위해 FMU, dll 형식의 파일을 표준으로 사용하기도 한다. 하지만 모든 소프트웨어가 들여오기/내보내기 기능과 FMU, dll 형식을 지원하지는 않기 때문에 통합하려는 모델 수가 증가할수록 개발효율이 크게 떨어지는 단점이 있다.

f14ddd37a109350a62ddd8c4e0a8b25d_1604626

코드기반 연동시뮬레이션의 한계를 극복하기 위해 도구기반 연동시뮬레이션 기법을 활발히 연구하고 있다. 도구기반이라는 단어에서 알 수 있듯이 도구기반 연동시뮬레이션은 하위모델별 소프트웨어를 독립적으로 다루며, 들여오기/내보내기 기능을 따로 구현하지 않는다. 이 경우 하위모델은 소프트웨어 고유의 솔버를 이용해 해석하고, 그 결과를 특정 동기화시점마다 공유하는 방식으로 전체 시스템을 해석한다. 하지만 정보교환을 위해 동기화시점마다 하위시스템 소프트웨어 실행을 중지하는 플랫폼과, 동기화 과정에서 발생하는 정보손실을 방지하는 알고리즘까지 개발해야 하는 어려움이 있다.

●하위시스템 수에 따른 구분
두개의 하위시스템을 통합해 해석하는 것을 소규모(Small-scale) 연동시뮬레이션이라 한다. 차량모델과 제어기모델을 통합하는 경우가 대표적인 예이다. 전통적인 연동시뮬레이션 사례 대부분이 이 범주에 속하며, 일반적으로 코드기반의 모델 통합 방식을 사용한다.

이에 반해 세개 이상의 하위시스템을 통합해 해석하는 것을 대규모(Large-scale) 연동시뮬레이션이라 부른다. 두개의 하위시스템에 하나의 하위시스템만 추가하더라도 전체 통합시스템을 해석하는 일은 매우 어려운 과제가 된다. 통합에 필요한 소프트웨어 중 하나라도 들여오기/내보내기 기능을 지원하지 않거나, FMU/dll 형태로의 변환이 어렵다면 코드기반의 시스템 통합/해석이 불가능하기 때문이다. 도구기반 방식으로 통합해 해석하더라도 증가한 인터페이스로 인해 정보교환시 오차 발생 가능성이 커진다. 이러한 오차는 연동시뮬레이션 정확도와 안정도에 영향을 미치므로 가상차량 프로토타입을 대규모 통합모델로 구성할 경우 세심한 고려가 필요하다.

●실시간 조건에 따른 구분
일반적인 시뮬레이션 소프트웨어는 실시간 조건을 중요하게 생각하지 않는다. 하지만 통합하려는 하위시스템에 하드웨어가 포함된다면 이야기가 달라진다. 하드웨어는 기본적으로 경성실시간(Hard real-time)조건을 만족하므로, 연동시뮬레이션 결과도 반드시 벽시계시간(Wall-clock time) 조건을 보장해야 한다. 이는 통합모델을 
해석하는데 필요한 시스템시간이 벽시계시간과 동일해야 함을 의미한다. 다른 표현으로는 RTF(Real Time Factor)가 1이라고 한다. RTF를 1로 유지하는 것은 실시간 연동시뮬레이션에서 매우 어려운 도전과제 중 하나이다.

f14ddd37a109350a62ddd8c4e0a8b25d_1604626

실제로는 경성실시간조건 만족을 위해 통합모델의 시스템시간을 벽시계시간보다 빠르게 만든다. 즉, 통합모델의 RTF를 1보다 작게 한다. 보통은 벽시계시간을 시스템시간의 정수배로 정의하는 경우가 일반적이다. 

병렬 하이브리드 차량의 가상 프로토타입
지금까지 알아본 연동시뮬레이션 유형을 바탕으로 <그림 3>에 나타난 병렬하이브리드차량을 가상차량 프로토타입으로 구축하는 방안을 생각해보자. 전체시스템을 구성하는 하위시스템 수가 일곱개이므로 대규모 연동시뮬레이션에 해당한다.

먼저 대규모 병렬하이브리드차량모델을 코드기반으로 통합/해석하는 경우를 살펴보자. 각각의 소프트웨어가 FMU, dll 파일 형식이나 들여오기/내보내기 기능을 지원하므로 시스템을 코드기반으로 통합하는 것이 가능하다. 하지만 통합시 다루어야 할 모델 개수가 상당하고, 하위모델을 수정할 때마다 전체시스템을 새롭게 구성해야 하는 번거로움이 존재한다. 또한 차체모델의 경우 강성(Stiffness) 특성을 내재하는 경우가 대부분이어서 통합시스템을 단일솔버(Implicit) 설정으로 해석할 경우 해석시간이 급증할 수 있다. 따라서 병렬하이브리드차량 같은 대규모 시스템을 코드기반으로 통합/해석하는 것은 매우 비효율적이다.

대규모 시스템 통합에는 도구기반 방식을 사용하는 것이 가장 효과적이다. <그림 4>에 나타낸 것처럼 각 하위시스템을 적절히 통제하는 플랫폼이 존재한다면 대규모 시스템을 통합/해석하는 과정이 매우 직관적이고 단순해진다. 각 하위시스템을 독립적으로 해석하므로 다양한 솔버와 솔버설정을 사용해 유연한 연동시뮬레이션 전략을 세우는게 가능하다. 

반면 도구기반 방식의 가장 큰 단점은 하위시스템간 정보교환시 내부루프<그림 4, 화살표>를 형성한다는 것이다. 내부루프는 연동시뮬레이션을 어렵게 만드는 주요요인이다. 그럼에도 대규모 시스템을 효과적으로 통합해 연동시뮬레이션 하기 위해서는 도구기반 방식을 적용하되, 그로 인해 발생하는 문제점들을 차례로 개선해 가는 것이 가장 현실적이면서도 효과적인 공학적 접근법이다.

실제 차량개발에서 필요한 가상차량 프로토타입 대부분은 대규모 시스템에 해당한다. 결과적으로 차량개발시 필요한 연동시뮬레이션 유형은 ‘대규모-도구기반-비실시간’ 특성을 갖는 것으로 간주할 수 있다. 통합모델을 하드웨어(예: HiL, ViL, Testbed 등)와 연결할 경우 ‘대규모-도구기반-실시간’ 특성으로까지 확장할 수 있다. 지금까지 살펴본 내용을 바탕으로 가상차량 프로토타입 구축시 참고할 수 있는 연동시뮬레이션 유형을 <그림 5>에 정리해 나타냈다.

차량개발에서의 연동시뮬레이션 도전 과제
마지막으로 가상차량 프로토타입을 연동시뮬레이션할 때 고려해야 할 도전과제들을 간단히 살펴보고자 한다. 도전과제 대부분은 ‘도구기반’, ‘실시간’ 특성에서 기인한다.도구기반 방식으로 하위모델을 통합한 시스템에서는 <그림 4> 화살표 상에 나타난 것처럼 내부루프가 형성된다. 이 내부루프를 <그림 6>에 자세히 나타냈다. 내부루프상에 존재하는 두개 하위시스템은 서로 입출력 값을 교환한다. 즉, 하위시스템1은 하위시스템2의 출력을 입력으로 받는다. 하지만 내부루프로 인해, 하위시스템1이 입력을 받는 동기화(Coupling) 시점에 하위시스템2의 입력값이 존재하지 않아 출력 자체가 나올 수 없는 인과성충돌(Causality conflict)이 발생한다. 일반적으로 내부루프 문제는 외삽법(Extrapolation)을 사용해 해결하는데 외삽법은 항상 외삽오차(또는 커플링오차)를 동반한다. 커플링오차는 연동시뮬레이션 정확도와 안정도를 떨어뜨릴 수 있어, 이를 효과적으로 보상하는 알고리즘 적용이 반드시 필요하다.

f14ddd37a109350a62ddd8c4e0a8b25d_1604626

하드웨어를 연동한 시스템에서는 하드웨어 특성에서 기인하는 문제점들을 자세히 다뤄야 한다. 첫째로는 통합모델과 하드웨어간 정보교환 시간이 경성실시간 조건을 위반하지 않을만큼 충분히 작아야 한다. 앞서 실시간 연동시뮬레이션에서는 통합모델의 시스템시간이 벽시계시간과 동일해야 한다고 했는데, 시스템시간에 정보교환시간까지 더해지면 경성실시간조건뿐만 아니라 해석안정도까지 크게 해칠 수 있기 때문이다. 한 예로, 경성실시간 연동시뮬레이션을 수행하는 소프트웨어는 윈도우를 실행하는 CPU와 동일한 코어에서 동작시키면 안된다. 윈도우 상에서는 수없이 많은 인터럽트가 발생하고, 이러한 인터럽트 총합이 정보교환시간에 그대로 더해지기 때문이다. 다음으로 통합모델이 실제 하드웨어 센서신호를 입력으로 받을 경우 센서신호에 담긴 잡음을 효과적으로 제거해야 한다. 이러한 잡음은 정보교환시간만
큼이나 연동시뮬레이션 정확도와 안정도에 악영향을 끼치므로 통합모델이 하드웨어 센서입력을 포함할 경우 잡음제거를 위한 노력에 심혈을 기울여야 한다.

f14ddd37a109350a62ddd8c4e0a8b25d_1604626

본 고에서는 가상차량 프로토타입 구성의 필요성을 간단히 알아보고, 가상차량 프로토타입 구성방법을 연동시뮬레이션 유형을 바탕으로 자세히 살펴보았다. 다음 호에서는 ‘대규모-도구기반’ 연동시뮬레이션을 수행할 때 경험하는 도전과제들은 무엇인지 알아보고, 이를 해결하기 위한 다양한 전략을 제시할 예정이다. 당연한 이야기일 수 있지만, 최적의 연동시뮬레이션 결과는 효과적인 연동시뮬레이션 시나리오를 통해서만 얻을 수 있다.

글 / 김규태 (한국AVL)
출처 / 오토저널 2020년 8월호 (http://www.ksae.org) 
  • 페이스북으로 보내기
  • 트위터로 보내기
  • 구글플러스로 보내기
하단배너
우측배너(위)
우측배너(아래)