MATLAB/Simulink 및 CANoe 를 사용한 소프트웨어 시뮬레이션

모델 기반 ECU 개발 MATLAB/Simulink 및 CANoe 를 사용한 소프트웨어 시뮬레이션 MATLAB/Simulink 는 공학 및 과학 부문에 널리 사용되는 툴이다. 예를 들어 자동차 영역에서 이 툴은 제어 시스템 등의 동적 시스템을 모델링하고 상태 및 상태의 전환을 기술하는 데 사용된다. 이러한 알고리즘은 서로 통신하는 여러 ECU 에서 실행되므로 개발 프로세스를 진행하는 동안 차량 네트워크에 액세스할 수 있도록 하는 것이 중요하다. 액세스는 버스 하드웨어와 통신하는 Simulink 블록을 통해 모델에서 직접 이루어진다. 그럼에도 불구하고 이 접근 방식에는 다음과 같은 여러 가지 단점이 있다. AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 1/13

모델이 항상 네트워크에 속해 있다. 서브시스템을 활용한 지능적인 구성을 통해 네트워크 및 애플리케이션 컨텐츠를 분리할 수 있지만 서로 다른 네트워크에 매우 손쉽게 적응시킬 수 있는 일반적인 모델을 사용하는 것이 더 유리하다. Simulink 모델에서 네트워크 관리(NM), 상호 작용 계층(IL) 또는 전송 프로토콜(TP) 같은 추가 프로토콜 계층과 잔여 버스 시뮬레이션을 구현하려면 많은 노력을 기울여야 한다. 예를 들어 Vector 의 시뮬레이션 및 테스트 소프트웨어 툴인 CANoe 를 사용하면 네트워크에 손쉽게 액세스할 수 있다. 이 소프트웨어는 일반적으로 전체 해당 노드와 함께 ECU 네트워크를 시뮬레이션하는 데 사용된다(잔여 버스 시뮬레이션). 각 노드의 통신 계층에서는 올바른 전송 유형으로 전송(CAN) 또는 스케줄링(FlexRay)과 같은 네트워크 관련 작업을 수행한다. NM 또는 TP 등의 다른 프로토콜은 OEM 별 컴포넌트의 형태로 손쉽게 추가할 수 있다. MATLAB/Simulink 모델을 통해 기술되는 동작인 노드의 애플리케이션 계층은 순수 신호 인터페이스 위에 배치된다(그림 1). 특정 네트워크에 대한 추가 참조는 없다. 모델에서는 해당 출력에 신호 값을 쓰고 입력에서 신호 값을 읽기만 한다. 모델 측면에서는 신호가 CAN 메시지에 정의되어 있든 LIN 또는 FlexRay 프레임에 정의되어 있든 관계가 없다. 신호 레벨의 이러한 추상화를 통해 사용자는 실질적으로 변경되지 않은 기존 모델을 다시 사용할 수 있다. 필요한 것은 모델의 입력 및 출력 포트를 네트워크의 관련 신호에 매핑하기만 하면 된다. 그림 1: 가상 노드를 이용한 CANoe 시뮬레이션 AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 2/13

CANoe 와 Simulink 모델 시스템 간에 신호를 교환할 수 있을 뿐 아니라 시스템 변수도 교환할 수 있는데, 이러한 변수는 사용자가 명시적으로 생성하거나 자동으로 생성될 수 있는 CANoe 내부 변수이다. 자동 생성 기능은 디지털/아날로그(D/A) 하드웨어를 CANoe 에 연결하는 방식으로 구현할 수 있다. 여기서 D/A 하드웨어의 각 포트는 전용 시스템 변수에 매핑된다. 이렇게 하면 모델이 연결된 D/A 하드웨어와 직접 상호 작용할 수 있다. Vector 의 CANoe MATLAB 통합 패키지를 설치하면 CANoe 와의 데이터 교환을 위한 관련 블록과 함께 Simulink Blockset 을 사용할 수 있게 된다. 이러한 블록은 주로 버스 신호, 시스템 변수 및 환경 변수를 읽고 쓰기 위한 함수로 구성되어 있다. 또한 CAPL 함수를 호출하기 위한 블록도 포함되어 있다. 뿐만 아니라 Simulink 에서 트리거된 서브시스템을 제어하는 등의 목적을 위해 CAPL 함수의 호출에 반응할 수도 있다. 신속한 프로토타이핑을 위한 오프라인 모드 이 모드는 모델을 여전히 자주 변경해야 하고 실제 기존 네트워크가 아직 중요한 역할을 하지 않는 초기 개발 단계에 선택해야 한다. 애플리케이션 개발자는 여전히 완전히 시뮬레이션된 네트워크에 대해 모델의 동작을 테스트할 수 있다. 또한 이러한 초기 단계에 개발한 모델도 네트워크를 추가로 수정하지 않고 이후의 모든 단계에서 다시 사용할 수 있다. 오프라인 모드(Offline mode) 내에서는 시뮬레이션이 Simulink 환경에서 시작된다. CANoe 는 슬레이브 모드로 작동하고 Simulink 는 시뮬레이션 세션에 대한 마스터가 된다. 시뮬레이션은 특정 컴퓨터 속도에 따라 계산된다. 여기서 Simulink 의 모든 디버그 기능을 사용할 수 있으며, 실제 하드웨어를 CANoe 에 연결할 필요는 없다. 초기 개발 단계를 위한 동기화 모드 이 모드 역시 모델이 아직 완성된 상태에 이르지 못한 초기 개발 단계를 위한 것이다. 오프라인 모드와 비교해 동기화 모드(Synchronized mode)에서는 실제 하드웨어를 통합하기 위한 추가 옵션을 제공한다. 여기서도 시뮬레이션은 Simulink 에서 시작된다. 오프라인 모드와 달리 이 모드에서는 CANoe 의 시간이 시뮬레이션 시간의 기초 역할을 하며 시뮬레이션은 실시간으로 AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 3/13

계산된다. 주목할 만한 한 가지 제한 사항은 모델이 그다지 복잡하지 않아 계산을 실시간으로 신속하게 수행하지 못할 수 있다는 점이다. 이는 Simulink 시간 을 CANoe 시간 에 맞춰 조정하면 Simulink 의 실행 속도가 느려지고 CANoe 의 실시간 기반에 따르게 되기 때문이다. 그러나 모델 계산에 상당히 많은 노력이 요구되는 경우에는 이러한 속도 저하가 발생할 수 없다. 모델이 위에 언급된 조건을 충족하는 경우 이 작동 모드에서는 실제 하드웨어에 대한 완전한 액세스가 보장된다. Simulink 의 디버그 기능도 사용할 수 있지만 모델 실행이 일시적으로 정지될 때마다 시뮬레이션 시간의 동기화가 손실된다. 온라인 모드 또는 HIL(Hardware-In-The-Loop) 모드 이 모드에서는 모델 계산이 완전히 CANoe 환경에서만 실행된다. 이 과정에 CANoe 에서 노드 및 실행할 수 있는 DLL 이 Simulink 모델에서 생성된다. 여기서 MATLAB/Simulink 의 실시간 워크샵(Real-Time Workshop)에서는 코드 생성을 제어한다. CANoe 용 코드를 생성하기 위해 생성 프로세스를 제어하는 실시간 워크샵 환경을 위한 특수한 타겟 메이크 파일(Target makefile) 이 개발되었다. 그런 다음 생성된 코드는 Microsoft Visual Studio 컴파일러를 사용하여 컴파일 및 링크된다. 이렇게 하면 CANoe 내부 API 를 구현하고 시뮬레이션 셋업에서 노드에 컴포넌트로 추가할 수 있는 Nodelayer DLL 이 만들어진다. 이러한 컴포넌트의 다른 예로는 OEM 별 상호 작용 계층과 네트워크 관리 또는 전송 프로토콜용 컴포넌트가 있다. CANoe 에서는 이러한 컴포넌트를 측정 시작 시 로드하며 측정이 끝나면 해제한다. 따라서 모델을 다시 컴파일하는 경우 시뮬레이션에서 변경된 컴포넌트를 통합하려면 측정을 끝내기만 하면 된다. 결과적으로 모델 실행은 완전히 CANoe 의 실시간 환경 내에서만 이루어진다. 네트워크 작업, 타이머 및 사용자 입력 등의 모든 이벤트는 정밀한 주기로 계산된다. 모델은 CANoe 구성의 일부이며 다른 사람에게 손쉽게 전송할 수 있다. 뒷부분에서는 모델을 다시 컴파일하지 않고 이후에도 계속 파라미터화하는 방법을 소개할 예정이다. 먼저 CANoe 에서 모델이 실행되는 방식에 대해 좀 더 자세히 살펴보기로 하자. CANoe 에서의 모델 계산 AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 4/13

모델 계산을 보다 깊이 이해하려면 CANoe 에서의 모델 계산을 이해해야 한다. 본질적으로 CANoe 는 이벤트 중심적인 방식으로 계산을 수행한다. 이러한 상황에서 이벤트는 들어오는 네트워크 메시지 또는 타이머이다. 들어오는 각 이벤트와 관련하여 CANoe 의 시뮬레이션 시간은 지정된 이벤트의 타임 스탬프로 설정된다. 시간 기반은 네트워크 인터페이스의 고해상도 비윈도우 타이머에서 파생된다. 이러한 방식을 통해 CANoe 가 윈도우에서 실행되더라도 높은 정밀도 레벨의 타임 스탬프를 얻게 된다. 이제 생성된 MATLAB/Simulink 모델이 DLL 형태로 구성에 추가되면 주기적으로 계산해야 한다. 앞에서 언급한 대로 타이머 역시 CANoe 의 시뮬레이션 시간을 설정할 수 있는 이벤트이다. 따라서 타이머는 Simulink 모델의 Solver 설정에 지정된 시간을 사용하여 모델에서 설정한다. 모델 파라미터화 사용자들은 나중에 모델을 다시 컴파일하지 않고 수정하길 원하는 경우가 많다. 사용 사례는 다음과 같이 분류할 수 있다. 모델에서 시뮬레이션 시작 시 정의되는 특정한 시작 조건이 실제 모델 로직을 변경시킬 수 없지만 테스트 시나리오마다 완전히 다를 수 있는 경우. 예를 들어 서로 다른 제어 특성을 테스트하기 위해 제어 루프에서 게인(Gain) 요소를 수정해야 할 수 있다. 실시간 워크샵 및/또는 Microsoft Compiler 를 사용할 수 없거나, 자주 다시 컴파일하는 데 드는 시간이 너무 길거나, 모델 파일 자체가 없는 경우. 여기서 사용자는 여전히 MATLAB/Simulink 를 설치하지 않고도 런타임에 모델을 수정할 수 있다. 이러한 사례에서는 별도로 생성된 DLL 을 통해 모델을 파라미터화하기가 다소 번거롭다. 시뮬레이션 설정의 노드에서 오랜 시간 동안 계속해서 컴포넌트를 재구성해야 하기 때문이다. 이러한 사용 사례에 적절히 대처하려면 CANoe 에 대해 생성된 컴포넌트를 컴파일 후에도 파라미터화할 수 있도록 만들어야 한다. 코드 생성 시에는 모델의 각 파라미터에 대한 시스템 변수가 생성되며 나중에 CANoe 에서 이를 읽고 쓰게 된다. 모델 파라미터는 일반적으로 개별 AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 5/13

Simulink 블록의 속성에 해당한다. Integrator 블록의 경우 이는 해당 블록의 초기 상태일 수 있고 정현(Sinusoidal) 블록의 경우에는 해당 블록의 빈도, 위상, 옵셋 또는 크기일 수 있다. 시스템 변수(예: Simulink Gain 블록의 게인 요소를 나타내는 변수)는 분석 창(Graphic, Data, Trace)과 패널에서는 물론 CAPL 프로그램 및 테스트에서도 사용할 수 있다. 또 다른 이점은 내부 파라미터를 반복해서 변경하기가 쉽기 때문에 모델을 세부적으로 조정할 수 있다는 것이다. CANoe 에서 Simulink 모델 보기 MATLAB/Simulink 모델을 CANoe 에서 관찰하려면 해당 모델이 생성된 컴포넌트의 형태로 존재해야 한다. 이를 위해 적절히 구성된 별도의 창을 특정 노드에서 사용할 수 있다(그림 4). 나중에 모델을 수정하려면 모델 표시 창에서 끌어다 놓는 방식으로 생성된 모든 내부 모델 파라미터를 CANoe 분석 창으로 이동할 수 있다. 이를 위하여 MATLAB/Simulink 라이선스가 있어야 할 필요는 없다. AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 6/13

그림 4: CANoe 의 Model Viewer 응용 예: FlexRay 버스를 이용한 전자식 섀시 제어 시스템 시뮬레이션 차량 모델을 포함하여 전자식 섀시 제어 시스템의 디자인은 흥미로운 예로 활용할 수 있다. 차량 모델은 차량 동역학을 충분히 사실적으로 시뮬레이션하고 능동 댐퍼를 갖춘 섀시 제어 시스템을 위한 플랫폼 역할을 수행할 수 있어야 한다. 여기서 목표는 제어 시스템을 사용하여 가장 안락한 주행 동작을 얻는 것이다. 여기서 전체 모델은 크게 다음과 같은 두 개의 블록으로 나뉜다. 1) 환경 모델(컨트롤러에 대한 환경 시뮬레이션): 차량의 다중 차체 모델(기계식 차량 모델) 파워트레인 모델(단순화된 엔진 모델) 브레이크 모델 네 개의 휠 모델 도로 모델 2) 섀시 제어 시스템: 차량 관측기 주 섀시 컨트롤러 능동 댐퍼를 위한 네 개의 종속 전력 컨트롤러 환경 모델은 차량 모델과 도로 모델로 나뉜다. 차량 모델은 15 자유도의 다중 차체 모델로 디자인된다. 다중 차체 모델은 컴퓨터 대수학 시스템(Computer Algebra System)을 활용하여 기호를 통해 정의되며, 이 모델에서 운동 방정식이 파생된다(약 4,400 회의 가산 및 20,800 회의 승산). 차량 모델에서는 가속 및 브레이크 페달 위치, 맞물리는 기어, 스티어링 각도, 주차 브레이크 상태, 제어 대상 값(편안함 또는 스포티함) 같은 자극을 위한 추가 입력을 제공한다. 이러한 파라미터는 CANoe 에서 시스템 변수를 통해 전달된다. 운전자 입력은 관련 제어 기능이 있는 컨트롤 패널에서 양방향으로 설정할 수 있다. 또한 자동 재생을 위해 적절한 매크로 기록을 주행 AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 7/13

프로필로 사용할 수도 있다. 도로 모델은 도로 표면의 높낮이 및 표면 상태가 포함된 조회 테이블을 통해 모델링된다. 마찬가지로 표면 조성은 모든 도로 위치에서 마찰 계수로 설명된다. 섀시 제어 시스템은 LQ 컨트롤러와 관측기로 구성되어 있다. 컨트롤러는 휠 서스펜션의 능동적인 힘의 요소에 대한 목표 힘을 계산한다. 여기서는 본질적으로 다음과 같은 두 가지 시스템 목표를 설정한다. 차체 가속 감소. 이를 통해 차량 운전자의 안락함이 향상된다. 일정한 휠 접촉 영역 유지(휠 접촉력 변동 최소화). 이를 통해 차량 운전자 입장에서는 안전 및 차량 동역학이 개선된다. 관측기는 자유도가 7 의 단순화된 선형 차량 모델을 적용하여 측정 불가능한 차량의 상태를 재구성한다. 섀시 제어 시스템에는 두 자이로 센서에서 얻은 차체 기울어짐의 각가속도(Angular Acceleration)와 가속도계에서 얻은 차체의 양력 가속도에 대한 측정 파라미터 값이 필요하다. 차량 시뮬레이션을 수행하면 이러한 파라미터를 사용할 수 있게 되며, 이들 파라미터는 CANoe 에서 시스템 변수를 통해 섀시 컨트롤러로도 전달된다. 힘 컨트롤러는 섀시 제어 시스템에 지정된 값을 목표로 능동적인 힘 요소의 힘을 조절한다. 예를 들어 이는 전류 안정화를 위한 단순한 PI 제어 시스템으로 디자인할 수 있다. CANoe 에는 환경 시뮬레이션(Environment simulation) 노드(차량 모델), 섀시 컨트롤러(Chassis controller) 노드 그리고 네 개의 힘 제어(Force control) 노드 등의 여섯 개의 시뮬레이션 노드가 정의되어 있다(그림 5). 이 여섯 개의 노드에서는 FlexRay 버스를 통해 힘 액추에이터의 네 가지 목표 힘과 휠 서스펜션의 네 가지 변형(Deflection)에 대한 데이터를 서로 교환한다. 버스를 통한 이러한 신호의 주기적인 전송은 피드백 제어 루프의 데드 타임을 활용한 이산 샘플링을 나타낸다. 이산 샘플링은 애매한 특성과 규모로 인해 제어 품질에 좋지 않은 영향을 주는 경우가 많다. 그럼에도 불구하고 이러한 신호는 FlexRay 버스를 사용하여 지터 없이 매우 안정적으로 전송할 수 있을 뿐 아니라 높은 클럭 속도(2.5 ~ 5ms)로 전송할 수도 있다. 또한 이를 통해 CAN 버스에 비해 전체 제어 시스템의 제어 품질이 크게 개선된다. AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 8/13

그림 5: 액티브 섀시 제어 시스템 모델 결론 CANoe/Matlab 통합 환경에서는 Simulink 를 동시에 사용하여 복잡한 애플리케이션 동작을 모델링하고 동일한 개발 프로세스 내에 관련 차량 내 네트워크를 통합할 수 있다. 사용자는 개발 과정에 친숙한 MATLAB/Simulink 환경에서 작업을 수행할 수 있으며 네트워크 관련 세부 사항에 대해서는 신경 쓰지 않아도 된다. AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 9/13

참고 *Solver 란? Solver 는 모델의 시간 종속형 변수를 계산하는 데 사용되는 수학적 근사 방법(Mathematical Approximation Method)을 지정한다. Simulink 에서는 가변 스텝 폭 또는 고정 스텝 폭 Solver 알고리즘을 제공한다. 가변 스텝 폭 Solver 는 모델에서 데이터가 변경되는 속도에 따라 알고리즘을 최적화한다. Solver 가 불연속성을 발견하는 경우 같은 극단적인 상황에서는 특정 시뮬레이션 시간 지점이 보다 작은 스텝 폭으로 다시 계산된다. 반면 모델 데이터가 크게 바뀌지 않는 시간에 대해서는 큰 스텝 폭이 사용되며, 이렇게 되면 시뮬레이션 시간이 빨라진다. 고정 스텝 폭 Solver 는 항상 지정된 스텝 폭 값으로 계산한다. 또한 이 유형의 Solver 는 불연속성을 감지하지 않는다. *Solver 의 선택: 사용자는 CANoe 인터페이스로 인해 그리고 이후의 코드 생성을 고려하여 고정 스텝 폭 Solver 를 선택해야 한다. 가변 스텝 폭 Solver 는 다음과 같은 제한이 있기 때문이다. 가변 스텝 폭 Solver 는 코드 생성에 사용할 수 없다. 이러한 Solver 를 사용하면 다음 시뮬레이션 스텝을 계산해야 하는 시기와 소요 시간을 예측할 수 없다. 이러한 사실은 일반적인 대상 플랫폼에서 요구되는 실시간 동작에 위배된다. 이 제한 사항은 일반적으로 모든 대상 플랫폼에 적용된다. Solver 는 입력 및 출력 블록의 데이터 변경 사항을 인지하지 못하므로(비결정론적 버스 신호인 경우는 제외) 가변 스텝 폭으로는 최적화를 수행할 수 없다. CANoe 의 MATLAB 통합 환경을 활용한 코드 생성 시에는 세 가지 작동 모드를 사용할 수 있는데, 오프라인 모드 및 동기화 모드 에서는 두 소프트웨어 툴이 모두 활성화되며 시뮬레이션은 Simulink 에서 시작된다. 하지만 온라인 모드 또는 HIL 모드 에서는 CANoe 에 대한 코드가 모델에서 생성된다. *Blockset 란? AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 10/13

Blockset 의 개별 블록은 서브시스템으로 구현되며, 특정 기능을 구현하는 소위 S-함수로 구성되어 있다. 대부분의 경우 S-함수는 MATLAB/Simulink 에서 제공하는 API 를 구현하는 사용자 관련 코드이다. 이를 통해 개발자는 MATLAB/Simulink 의 기능적 특징을 보다 손쉽게 사용자에게 확장시킬 수 있다. AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 11/13

저자: 요흔 노이퍼(Jochen Neuffer) 에실링겐(Esslingen)에 위치한 응용 과학 대학교(University of Applied Science)에서 IT 를 전공했으며, 2002 년부터 Vector Informatik GmbH 에서 근무하며 네트워크 및 분산 시스템용 툴 영역에서 제품 관리 엔지니어로 일하고 있다. 카르스텐 뵈케(Carsten Böke) 패더본 대학교(University of Paderborn)에서 컴퓨터 공학을 전공했다. 1995 년부터 2004 년까지는 Heinz Nixdorf Institute 의 병렬 시스템 디자인 부문에서 과학 어시스턴트(Scientific Assistant)로 근무했다. 2004 년부터는 Vector Informatik GmbH 에서 수석 소프트웨어 개발 엔지니어로 근무하며 FlexRay 시스템의 버스 분석 및 버스 시뮬레이션용 툴을 개발하고 있다. Vector Informatik GmbH Ingersheimer Str. 24 70499 Stuttgart Germany www.vector.com AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 12/13

본 자료 배포시 최종 인쇄물을 당사에 보내주시면 감사하겠습니다. 배포와 관련하여 문의사항이 있으시면 언제든지 연락주시기 바랍니다: 벡터코리아 편집자 연락처: 마케팅부 양희영 과장 서울특별시 구로구 구로동 222-12 마리오타워 1406 호 Tel. 02-807-0600 Ext.5002, Fax. 02-807-0601 E-mail: ronald.yang@vector.com AUTOSAR 베이직 소프트웨어를 통한 CAN-MOST 게이트웨이 구현 13/13