ADAS 검증 위한 SystemC FMU
SystemC FMU For Verification Of Advanced Driver Assistance Systems
2019년 11월호 지면기사  / 글│케롤레스 칼릴, 마그디 A. 엘모르시, 멘토, 지멘스 비즈니스

SystemC FMU For Verification Of Advanced Driver Assistance Systems
첨단 운전자 지원 시스템 검증 위한 SystemC FMU

이 글에서는 이기종 자동차 시스템의 기계 부품을 갖춘 전자 시스템(디지털 및 아날로그 장치 포함)의 시뮬레이션을 위한 통합 프레임워크를 설명한다. 수많은 전자제어장치(ECU)로 구성된 전자 시스템을 모델화 해 메카트로닉 시스템의 기능을 시뮬레이션한다. 최근에 개발된 기능 모형 인터페이스 표준 접근방식을 복잡한 가상 물리 자동차 시스템의 모델 작성에 사용했다. 이 프레임워크는 가상 ECU에서 실행될 하드웨어(HW)와 소프트웨어(SW)를 포함한 실제 시스템을 시뮬레이션 한다. 이를 통해 기계 시스템이 연결되어 있는 상태에서 자동차 시스템의 소프트웨어와 하드웨어를 공동개발 할 수 있다. 하드웨어와 소프트웨어의 디버깅은 개발된 방법을 사용해 이뤄진다. 자동차 메카트로닉스 시스템의 개발 주기는 제안된 프레임워크를 이용해 크게 단축시킬 수 있다.

글│케롤레스 칼릴(Keroles Khalil), 마그디 A. 엘모르시(Magdy A. El-Moursy), 멘토, 지멘스 비즈니스
원문│ https://verificationacademy.com/verification-horizons/june-2019-volume-15-issue-2/systemc-fmu-for-verification-of-advanced-driver-assistance-systems


 
율주행(AD)에는 정교한 전자 시스템이 필요하다. 오늘날의 자동차 전장 시스템의 디자인에는 많은 시스템 온 칩(SoC)이 포함되어 있다[1, 2]. 버그나 고장 위험이 없도록 하기 위해서는 심층 검증이 필요하다. 첨단 운전자 지원 시스템(ADAS)의 안전성은 열, 기계 및 전기 부품을 포함한 시스템 전체의 검증 없이는 보장될 수 없다. ADAS를 탑재한 자동차는 광범위한 데이터 처리 및 의사결정 기능을 갖추고 있다. 위험할 수 있는 상황을 운전자에게 경고해 피할 수 있도록 하거나, 위험 상황이 불가피할 경우에는 시스템 온 보드(SoB)가 자동차를 제어해 예컨대 충격 지점으로부터 방향을 튼다. 본고에서는 소프트웨어와 하드웨어를 포함한 ADAS의 작동을 검증하기 위해 자동차 시스템 전체의 모델링을 채택한다.

가상 플랫폼(VP)이 실제 제품의 가상 프로토타입을 제작하고 SW 및 HW 시스템의 통합설계를 가능케 해주는 핵심 기술로 부상하고 있다. 가상 플랫폼을 통해 신속한 아키텍처 탐색, 소프트웨어의 조기 개발 및 효율적인 성능 분석을 수행할 수 있다[3-7]. 가상 플랫폼은 하드웨어 블록들과 이들의 인터커넥션을 나타내는 시뮬레이션 모델들의 앙상블이다. 가상 플랫폼은 대개 SystemC/TLM2와 같이 모델링 및 시뮬레이션에 맞춤화 된 고급 프로그래밍 언어를 통해 모델화 된다[1]. 하이브리드 카 시스템에서는 가상 플랫폼, 플랜트 시뮬레이터, 디지털 시뮬레이터, HW 에뮬레이터 및 기계 시뮬레이터를 포함해 여러 도메인의 서로 다른 툴과 모델들(복합 시스템) 간에 시너지가 필요하다. 가상 플랫폼은 프로세서와 하드웨어 주변장치, 그리고 자동차 소프트웨어 스택을 실행하기 위한 컨트롤러를 포함한 ECU(즉, 가상 ECU 또는 VECU)를 모델화 한다[8-12]. ADAS VECU에는 다수의 센서가 탑재되어 있으며, 실제 상황을 보다 잘 인식할 수 있도록 센서 판독 기능이 결합돼 있다. 본고에서 제시하는 프레임워크는 자율주행 및 비 자율주행 VECU의 검증에 모두 사용된다. ADAS ECU 역할을 하는 VECU에는 그 위에서 실행되는 AUTOSAR SW[13]가 있다. VECU는 그림 1에서 보듯이, FMI(functional mock-up interface) 표준[14]을 통해 다양한 종류의 센서 및 액추에이터와 연결된다.


그림 1|다양한 FMU와 인터페이스 되는 가상 ECU


SystemC/TLM 가상 플랫폼은 Vista™ 툴[15]을 이용해 생성되며, MATLAB®[16] 및 TASS® Prescan에 의해 생성된 센서/액추에이터에 연결된다[17]. TASS는 차량의 물리적 환경에서 발생할 수 있는 위험상황 시나리오를 개발할 수 있는 기능을 제공한다. 이러한 시뮬레이션 시나리오 덕분에 엔지니어는 초기 설계 단계에서 실제 시스템 설계 문제에 더 많은 시간을 할애할 수 있다. 개발자는 제안된 프레임워크를 사용해 VECU 상의 실제 코드를 검증하고, 많은 센서와 액추에이터를 다양한 시나리오에서 다루며, 그러한 시나리오에서 ADAS를 사용하는 데 따른 효과를 연구할 수 있다. 제시된 방법론은 VECU를 FMI를 사용하는 FMU(functionalmock-up unit)로서 통합한다.

[1]의 작업은 가상 플랫폼을 FMU로서 생성하기 위한 접근방법을 제시한다. 가상 플랫폼은 FMU 공유 개체로 출하되며, 함께 제공되는 FMI 모델 설명 XML은 FMU 파일에 들어 있다. FMI 마스터는 VP DLL을 로드한다. 본고에서 제안하는 메커니즘은 FMU 래퍼의 생성에 좌우된다는 점에서 다르다. FMU 래퍼는 FMI 마스터가 IPC 메커니즘을 통해 가상 플랫폼과 함께 로드할 수 있다. 가상 플랫폼의 I/O 인터커넥트는 FMI 마스터에 의해 트리거 되는 FMI V.2.0 통합 시뮬레이션 API에 의해 제어된다. I/O 변경 사항은 SystemC/TLM 기반 가상 플랫폼의 특성과 호환되는 이벤트 기반 실행 메커니즘을 통해 전파된다. 이 메커니즘을 사용하면 [1]에 기술된 메커니즘에 비해 이식성이 높아지는데, 이는 FMU 부분을 변경하지 않고도 가상 플랫폼을 수정 및 컴파일 할 수 있기 때문이다. 본고의 나머지 부분은 다음과 같이 구성되어 있다. 제안된 FMU를 사용한 설계 방법론을 섹션 II에서 제시하며, 완전한 자동차 시스템에 대한 사례 연구를 섹션 III에서, 결론은 섹션 IV에서 제시한다.


개발된 방법론

SystemC 가상 플랫폼을 FMU로 래핑하기 위해 두 개의 래퍼(wrapper)를 사용한다. 그림 2에서 보듯이, 하나는 가상 플랫폼, 즉 내부 FMU 제어장치(IFC) 내부에 있고, 다른 하나는 외부, 즉 FMU 래퍼(EFW)에 있다. IFC는 EFW와 통신하고 가상 플랫폼을 다른 FMU(전기적 또는 기계적인)와 동기화 시키는 TLM SystemC 모델이다. IFC는 IPC 메커니즘을 통해 EFW와 연결된다. EFW는 XML과 DLL로 구성된다. 이는 다른 시뮬레이션 툴 내의 외부 FMI 마스터에 의해 파싱 및 로드될 수 있다. FMU는 FMI V.2.0 통합 시뮬레이션 표준을 따르는 것으로 가정한다. 또한 FMU는 사전 컴파일된 공유 라이브러리(윈도우에서는 *.DLL, 리눅스 시스템에서는 *.so)로서 제공되는 것으로 가정한다. 런타임 라이브러리 종속성은 가상 플랫폼이 실행 중인 동일 호스트에서 사용할 수 있는 것으로 가정한다. EFW는 입력 및 출력 핀을 몇 개든 가지도록 구성할 수 있다. 아날로그 포트는 실수로 표시되고, 디지털 핀은 정수로 표시된다. 각 핀마다 고유의 기준 값(V_reference)을 갖는다. EFW 구성은 XML 파일에서 설정할 수 있다. IFC는 EFW와 동일한 구성을 갖는다.




그림 2|FMU 포트 구조의 동적 배열


EFW XML은 아래 그림 2에서 보듯이, 각 핀에 대해 S_FMU_PORT 구조의 동적 배열을 갖는다. S_FMU_PORT 구조는 FMU_Container_Value를 정의하며, 이는 VP와 FMI 마스터 간에 송수신 될 값을 나타낸다. FMU_Container_Type은 데이터 유형(실수 또는 정수)을 나타낸다. V_reference는 XML 파일에 정의되어 있는 핀의 기준 값을 나타낸다. 핀 값이 마스터나 슬레이브의 어느 쪽에 의해서든 업데이트 되면 업데이트 된 값이 설정된다. XML 파일의 핀 방향으로부터 핀이 입력인지 출력인지 여부를 식별할 수 있다. C_socket은 아래 그림 3에서 보듯이, 핀에 매핑 된 가상 소켓을 나타낸다.



그림 3|EFW 전송 시퀀스V


V_reference의 기본 초기화 값은 -1이다. 초기화는 FMI 마스터가 FMU 초기화 API를 호출하기 시작하면 수행된다.
FMI 마스터는 INTEGRR 값을 FMU로 전송하고 나면 fmi2SetInteger API를 호출한다. 그 다음에는 EFW가 입력 방향과 일치하는 기준 값을 갖는 모든 S_FMU_PORT 를 검색한다. EFW는 다른 FMU가 보내는 값으로 FMU_Container_Value를 설정한다. XML V_reference 가 존재하지 않을 경우, V_reference는 -1로 설정된다. 최종적으로, 이 값은 그림 4와 같이 해당되는 가상 소켓으로 전송된다.



그림 4|IFC 수신 시퀀스


반면에, IFC는 매퍼 서브 블록에 의한 핀 값의 송수신을 처리한다. EFW는 IPC 가상 소켓을 이용해 문자열을 전송한다. 이 문자열은 세미콜론으로 구분된 5개의 데이터 값(핀 값, 데이터 유형, 변수 참조, 업데이트된 플래그 및 방향)으로 구성된다. IFC 내부의 매퍼는 이 문자열을 파싱해 그림 4와 같이 XML의 V_reference 와 일치하는 다용도 입출력(GPIO) TLM 핀에서 트랜잭션을 발행한다. 각 TLM 핀에는 고유의 V_reference가 있다.

GPIO가 GPIO 핀에서 데이터 전송을 위해 트랜잭션을 발행할 경우 유사한 거동이 일어난다. 매퍼는 데이터 값을 해당 가상 소켓 상의 EFW로 전송한다. FMI 마스터는 FMU로부터 데이터를 읽고 나면 Fmi2getint API를 호출하고 저장된 값을 FMI 마스터로 돌려보낸다. FMI 마스터의 외부 툴과 가상 플랫폼 간에 교환된 데이터는 FMU 슬레이브로 래핑 되며, 그림 5에서 보는 바와 같다. 많은 VECU가 함께 통신하는 사례 연구(이 중의 하나인 ADAS VECU는 Matlab FMI 마스터에 연결된 FMU 역할을 한다)에 대해서는 다음 섹션에서 설명한다.


그림 5|VECU 핀과 외부 툴의 FMI 마스터 간의 데이터 교환


사례 연구

CAN 버스에 연결된 네 개의 VECU로 구성된 자율주행 차량의 ADAS가 아래의 그림 6에서 보듯이, VP를 FMU로 사용하는 예를 보여주기 위한 사례 연구에 사용되었다. 대시보드 VECU는 패킷 생성 및 모니터링을 위해 CANoe®[18]를 사용해 모델화 된다. 다양한 입력(페달/각도, 브레이크/각도, 변속 및 엔진 정지 등)과 출력(모니터 속도/RPM)이 대시보드를 통해 스티뮬레이트 및 관찰된다. 엔진 제어 VECU는 AUTOSAR 스택/애플리케이션을 실행하기 위해 Vista Architect®[15]를 사용해 PowerPC 가상 플랫폼으로서 모델화 된다. 엔진 제어 VECU는 대시보드로부터 입력 조합을 읽어 명령/페달/브레이크 각도를 변속기 컨트롤러 VECU로 전송한다. 변속기 컨트롤러 VECU는 베어 메탈 애플리케이션을 실행하는 가상 SoC(ARM® CortexM3 기반의)로 모델화 된다. 이것은 엔진 컨트롤러 VECU로부터 페달 각도를 판독해 RPM/속도를 계산한다. 제동 시스템은 메카트로닉 구성 요소를 갖춘 Simcenter Amesim®[19]을 이용해 모델화 되는데, 이는 슬레이브 FMU로서 익스포트 되며 호스트 머신에서 실행되는 Vista FMI 마스터에 연결된다. FMU 입력은 엔진 컨트롤 VECU 내부의 디지털-아날로그 컨버터(DAC) 모델로부터 오는 제동력이며, 출력은 차량의 4륜 캘리퍼(Calipers)에 가해지는 힘이다.



그림 6|ADAS VECU에 의해 제어되는 비상 자동제동 장치 (사례 연구)


이 시나리오는 액터 정보 수신자(AIR) 센서가 도로 위를 지나가는 사람을 감지하는 것으로 시작되는데, 이는 PreScan®을 이용해 모델화된다[17]. AIR 센서는 비상 자동제동 장치(AEBS) 베어메탈 애플리케이션을 실행하는 가상 ADAS 제어 VECU에 연결되며, FMU로 래핑된다. ADAS VECU는 그림 7에서 보듯이 MathWorks의 MATLAB Simulink®[16] 내부에 통합되어 있다. 아무런 물체도 감지되지 않을 경우, AIR 센서의 출력은 0이 된다. VECU의 아날로그-디지털 컨버터(ADC)는 AIR 센서에 연결된다.



그림 7|FMU 연결로서 래핑되는 ADAS VECU


ADAS를 테스트 하기 위해 1만 개의 주행 시나리오 중 하나를 선택하게 된다. 시뮬레이트 된 차량은 시뮬레이트 된 도로에서 정상적으로 주행된다. 차 안의 AIR 센서는 차량 전방 20미터 거리에서 도로를 가로질러 달리는 사람을 감지해낸다. ADAS VECU는 이 센서 정보를 이용해 회피 조치를 취하지 않으면 사람과 충돌하게 된다고 판단한다. ADAS는 제동 시스템에게 차를 멈추라는 신호를 보낸다. VECU는 저마다 고유의 CAN ID를 갖고 있다. VECU 간의 통신은 그림 8과 같이 CAN 프레임에 의해 이뤄진다.



그림 8|가상 CAN 버스 상의 CAN 프레임 데이터 흐름


ADAS VECU는 FMU로 래핑 되어 MATLAB Simulink로 임포트 된다. 이것은 변속기 컨트롤러 VECU로부터 속도/RPM CAN 패킷을 수신해 PreScan에서 자동차 애니메이션을 제어한다. 사람이 차량 앞에 나타나면 센서가 물체를 감지하며, ADAS VECU는 CAN 패킷(ID=0x70)을 브레이크 각도가 포함된 데이터와 함께 자동 전송한다. 변속기 컨트롤러 VECU가 Simcenter Amesim의 기계식 브레이크 시스템에 제동력 값을 보내고, 자동차는 멈추게 된다. 자동차 속도의 자연감소 기울기는 도로 마찰에 의해 발생한다. AIR 센서가 20미터 거리에 있는 물체를 감지하면 ADAS 제어 VECU가 자동적으로 브레이크 신호 프레임을 보내며, 흐름자동차 속도는 급격히 감소해 14미터 거리에서 정지하게 된다. 이 시뮬레이션 시나리오는 아래 그림 10과 같다. 자동차 속도는 1초 동안에 시속 20킬로미터에서 시속 0킬로미터로 감소한다.


그림 9|(a) AIR 센서 거리(m)와 차량 속도(km/h) (b) ADAS VECU는 앞에 있는 사람을 감지하면 차를 멈춘다.


또 다른 시나리오에서는 그림 10과 같이 자동차 속도가 971밀리초 동안에 시속 90킬로미터에서 시속 40킬로미터로 감소한다. 이 경우, 고속 주행하다가 갑자기 보행자와 맞닥뜨리면서 차량과 사람이 부딪히게 된다. 많은 시나리오를 다양한 속도로 검증할 수 있다. 각 시나리오에 대한 AUTOSAR SW 분석을 그림 11과 같이 생성하고 검증할 수 있다.



그림 10|충돌은 자동차의 고속주행 결과로 발생하게 된다. AIR 센서 거리(m)와 자동차 속도(km/hr)

그림 11|ADAS VECU에 대한 AUTOSAR SW 분석



본고에서 보듯이, 대상 VECU의 가상 플랫폼과 FMI 표준을 사용함으로써 완전한 이기종 자동차 시스템의 시뮬레이션이 가능해지고 있다. 전기 시스템 뿐만 아니라 기계 시스템도 제시된 방법론을 이용해 시뮬레이션 및 검증할 수 있다. 가상화를 효율적으로 사용함으로써 AUTOSAR SW를 기능 시뮬레이션에서 실행할 수 있다. 전기(디지털과 아날로그) 및 기계 서브시스템이 포함된 ADAS가 짧은 시간 내에 (고성능으로) 모델링 및 시뮬레이트 된다. 복합 시스템(SoS)의 이기종 부분 통합이 자동차 시스템 개발에 있어서 필수적이 되고 있다. 본고에서는 FMI 표준을 사용해 SoC 플랫폼 전체를 FMU로 모델화 한다. FMI는 통합 프레임워크를 이용해 디지털, 아날로그 및 기계 부품을 시뮬레이트 할 수 있게 해준다. 실제 소프트웨어가 모델화 된 시스템에서 효율적으로 실행되므로 시스템 작동을 검증할 수 있다. ADAS는 개발된 가상 시스템에서 검증된다. 제시된 방법론을 통해 하드웨어로 소프트웨어를 디버깅하기가 보다 쉬워졌다.


 
참고문헌

[1] R. L. Bucs, L. G. Murillo, E. Korotcenko, G. Dugge, R. Leupers, G. Ascheid, A. Ropers, M. Wedler, and A. Hoffmann. “Virtual hardware- in-the-loop co-simulation for multi-domain automotive systems via the functional mock-up interface,” in Specification and Design Languages (FDL),p.1-8(2015).
[2] R. Leupers, F. Schirrmeister, G. Martin, T. Kogel, R. Plyaskin, A. Herkersdorf, and M. Vaupel. “Virtual Platforms: Breaking New Grounds,” in Design, Automation & Test in Europe Conference & Exhibition (DATE), Germany, p. 685-690(March 2012).
[3] M. Shedeed, G. Bahig, M. W. Elkharashi, and M. Chen, “Functional Design and Verification of Automotive Embedded Software: An Integrated System Verification Flow,” In The Proceedings of The IEEE Saudi International Electronics, Communications and Photonics Conference, pp. 1-5, July 2013.
[4] R. Saleh, S. Wilton, S. Mirabbasi, A. Hu, M. Greenstreet, G. Lemieux, P. Pande, C. Grecu, and A. Ivanov, “System-on-Chip: Reuse and Integrate,” In The Proceedings of The IEEE, Vol. 94, No. 6, pp. 1050-1069, June 2006.
[5] R. Leupers, F. Schirrmeister, G. Martin, T. Kogel, R. Plyaskin, A. Herkersdorf, and M. Vaupel, “Virtual Platforms: Breaking New Grounds,” In The Proceedings of The IEEE Design Automation and Test in Europe Conference and Exhibition, pp. 685-690, March 2012.
[6] C-S. Peng, Li-C. Chang, C-H. Kuo, and B-D. Liu, “Dual-Core Virtual Platform with QEMU and SystemC,” In The Proceedings of The IEEE International Symposium on Next-Generation Electronics, pp. 69-70, November 2010.
[7] L. B. and S. Sujatha, “Creating Virtual Platform for Cloud Computing,” In The Proceedings of The IEEE International Conference on Computational Intelligence and Computing Research, pp. 1-4, December 2010.
[8] M. A. El-Moursy, A. Sheirah, M. Safar, and A. Salem, “Efficient Embedded SoC Hardware/Software Codesign using Virtual Platform,” In The Proceedings of The International Design & Test Symposium, December 2014.
[9] M. Safar, A. Bakr, M. A. El-Moursy, and A. Salem, ”AUTOSAR Software Debug and Analysis using Virtual Platforms," In The Proceedings of The IEEE International Workshop on Automotive Reliability & Test, December 2016.
[10] C.-C. Wang, R.-P. Wong, J.-W. Lin, C.-H. Chen, System-level development and verification framework for high-performance system accelerator,” In The Proceedings of The International Symposium on VLSI Design, Automation and Test, pp. 359–36, April 2009.
[11] F. Mendoza, C. Kollner, J. Becker, and K. Muller-Glaser, “An Automated Approach to SystemC/Simulink Co-Simulation,” In The Proceedings of The IEEE International Symposium on Rapid System Prototyping, pp. 135–141, May 2011.
[12] F. Wawrzik, W. Chipman, J. Molina, and C. Grimm, “Modeling and Simulation of Cyber-Physical Systems with SICYPHOS,” In The Proceedings of The International Conference on Design and Technology of Integrated Systems in Nanoscale Era, pp. 1–6, April 2015.
[13] AUTOSAR (AUTomotive Open System ARchitecture). Available at: AUTOSAR.org
[14] Functional Mock-up Interface (FMI). Available at: fMI-Standard.org
[15] Mentor, A Siemens Business, Vista Architect®.
[16] MathWorks®, MATLAB/Simulink. Available at: Mathworks.com.
[17] TASS A Siemens Business, PreScan. Available at: Siemens.com.
[18] Vector CANoe, Vector.com
[19] Siemens PLM Software, Simcenter Amesim. Available at: PLM.Automation.Siemens.com.

 



<저작권자 © AEM. 무단전재 및 재배포, AI학습 이용 금지>

PDF 원문보기

본 기사의 전문은 PDF문서로 제공합니다. (로그인필요)
다운로드한 PDF문서를 웹사이트, 카페, 블로그등을 통해 재배포하는 것을 금합니다. (비상업적 용도 포함)

  • 100자평 쓰기
  • 로그인



TOP