AUTOSAR란 키워드가 핫이슈로 대두되고 있는 요즘, 자동차 업계에 종사하고 있는 엔지니어라면 한번쯤 AUTOSAR 플랫폼을 활용한 시스템 개발과정에 대해 궁금하게 여겼을 것이다. 이미 양산 적용중인 한국델파이의 속도감응형 파워 스티어링(Speed Sensitive Power Steering, SSPS) 장치의 ECU에 AUTOSAR 플랫폼을 적용하는 전반적인 설계과정과 결과를 소개한다.

속도감응형 파워 스티어링 장치 개요
속도감응형 파워 스티어링 장치는 차량의 속도에 따라 조향감이 조절되어 안정성과 편의성을 높여주는 장치다. 차량 속도가 저속일 때 가벼운 핸들링을 제공하고, 고속일 때는 무거운 핸들링을 제공하여 운전자가 보다 편하고 쉽게 운전할 수 있도록 도와준다. 파워 스티어링은 구동방식에 따라 유압식과 전동식으로 구분된다. 예전에는 유압식 장치가 주류였으나 최근 들어 전동식 장치가 점차 양산에 적용되는 추세이다.
그림 7은 유압방식의 속도감응형 파워 스티어링 장치의 구성도로, 스티어링 휠의 조작감을 제어하기 위해 유압 펌프에 의해 가압된 유압을 유압 밸브를 통해 조정하게 된다. 차량 속도와 스티어링 휠의 속도를 입력받아 전자제어장치는 차량의 주행조건에 따라 운전자가 최적의 조향 성능을 확보할 수 있도록 유압을 조정한다. 속도감응형 파워 스티어링 장치 구성은 스티어링 휠, 스티어링 휠 속도센서, 차량 속도센서, ECU, 유압밸브 액추에이터로 구성된다. 여기서 ECU는 차량 속도 등의 입력에 따라 핸들의 조작력을 적절하게 조절하는 역할을 담당한다. 우리는 기존 양산중인 ECU를 AUTOSAR 플랫폼을 적용한 ECU로 새롭게 개발했다.

개발 절차
ECU를 개발하기 위해서는 개발 프로세스에 따른 툴체인을 가장 우선 구축해야 한다. 현재 자동차 업계에서 범용적으로 많이 사용하고 있는 Vector, MathWorks, Telelogic, Freescale의 제품을 위주로 그림 8과 같이 구성했다.
Telelogic의 DOORS 제품은 요구사항 관리를 담당하며, Vector의 DaVinci와 MICROSAR EAD는 AUTOSAR 플랫폼 기반의 응용 소프트웨어 설계 및 베이식 소프트웨어 설계에 이용되는 AUTOSAR 개발도구이다. MathWorks 사의 MATLAB/ Simulink는 모델링 분야에 널리 사용되어지며, Vector의 CANoe는 네트워크 관련 설계 및 테스트에 주로 사용되는 도구이다. 여러 도구들에 의해 최종적으로 생성된 코드들을 통합하여 컴파일하고 디버깅하기 위해 Freescale의 CodeWarrior 통합개발환경을 사용했다.
AUTOSAR 개발도구인 DaVinci와 MICROSAR EAD는 그림 9에서와 같이 AUTOSAR 개발방법론의 전 영역을 만족함을 확인할 수 있다.
개발과정은 크게 시스템 설계, ECU 설계, 테스트의 총 3단계로 구분했다. 각 단계를 상세히 소개한다.

시스템 설계
■ 요구사항 분석
SSPS 시스템의 요구사항은 크게 차량 속도에 따른 스티어링 휠 조향력, 스티어링 휠 회전속도에 따른 스티어링 휠 조향력, 복귀 조향력, 그리고 경고등 작동 및 자가진단에 관련된 요구사항 등 총 4개로 구분된다. 예를 들어 ‘차량의 속도가 증가할수록 핸들 조작에 필요한 힘은 커진다.’라는 항목은 차량 속도에 따른 스티어링 휠 조향력과 관련된 대표적인 요구사항이다. 이 요구사항은 DOORS 도구에 의해 작성되고 관리된다.

■ Software Architecture 설계내용
SSPS 시스템의 소프트웨어는 크게 4개의 센서/액추에이터 소프트웨어 컴포넌트와 제어 알고리즘에 해당하는 1개의 컴포지트 소프트웨어 아키텍처로 구성된다. 각 컴포넌트는 기능별로 하위 아토믹 소프트웨어 컴포넌트를 포함하고 있으며, 각 아토믹 소프트웨어 컴포넌트에서 Runnable Entity를 정의하여 트리거 조건 및 주기/입출력 인터페이스/초기화 등의 세부 내용을 설계한다.

■ Function Modeling
시스템 단위의 설계가 끝나게 되면, 각 소프트웨어 컴포넌트 내부에 포함될 모델 단위의 코드들을 생성하기 위해 요구사항에 맞게 기능 모델링 과정이 필요하게 된다. 기능 모델링은 개발자가 직접 코딩으로 기능들을 구현할 수도 있고, MATLAB/ Simulink, Statemate 등의 모델링 도구를 사용하여 개발 할 수도 있다. SSPS ECU 개발에서는 기존 코드의 활용을 위해 모델링 도구를 사용하지 않고 직접 C로 코딩하여 개발하였다. 만약 모델링 도구를 이용하면 그림 11처럼 개발될 수 있다. 그림 11은 Statemate 도구를 사용하여 기능 모델링을 상태 다이어그램으로 표현한 예이다.

■ 네트워크 토폴로지 설계(선택적)
복수의 ECU로 구성된 시스템의 경우, 다음의 예와 같이 통신 프로토콜과 버스를 선정하고 네트워크 토폴로지를 정의해야 한다. 본 SSPS 시스템은 단일 ECU로 구성돼 있기 때문에 실제 개발단계에서 네트워크 설계 관련 프로세스들은 생략한다.

■ 컴포넌트 할당(선택적)
다음 단계는 여러 개의 소프트웨어 컴포넌트(SW-C)를 해당 ECU 하드웨어에 할당하는 작업이다. 이 단계를 거치면 시스템 단위에서 정의한 VFB 정보는 RTE로 변환되면서 Internal/External 신호가 분리되게 된다. 본 SSPS 시스템은 단일 ECU로 소프트웨어 컴포넌트 간의 통신은 모두 Internal 신호로 구성되어진다. 여러 개의 ECU로 연결될 경우, 소프트웨어 컴포넌트를 그림 12와 같이 개발 ECU로 할당해야 하면 자동적으로 Internal/External 신호로 구분되어진다.
■ 네트워크 설계(선택적)
외부 ECU 간 연결되는 External 신호들은 네트워크로 연결된다. 이 과정에서는 메시지와 구성신호를 정의하고 메시지 ID, 데이터 길이, 송수신 방식 및 주기 등의 세부 정보를 설정하게 된다. 그리고 설계 완료된 결과는 네트워크 dbc 파일로 생성된다. 본 SSPS 시스템은 단일 ECU로 구성되어 있기 때문에 실제 개발단계에서 네트워크 설계 관련 프로세스들은 생략한다.

ECU 설계
시스템 단계의 설계를 마치면, ECU 단위로 내부 소프트웨어 설계를 시작한다. 할당된 소프트웨어 컴포넌트(SW-C)를 베이식 소프트웨어 설정을 거쳐 하드웨어 연결 작업을 수행하게 된다.
■ 소프트웨어 컴포넌트(SW-C) 설계
ECU 차원에서 소프트웨어 컴포넌트(SW-C) 내부의 Runnable들을 설계하고 정의해야 한다. Runnable은 함수의 실행 단위이며 1개 이상의 Runnable이 모여 하나의 소프트웨어 컴포넌트를 구성한다(그림 13).
■ Task 설계
소프트웨어 컴포넌트(SW-C) 설계를 마친 후, 복수의 Task를 정의하고 최소 실행 단위인 Runnable을 해당 Task에 할당하고 우선순위를 설정하는 단계를 거치게 된다.
■ 베이식 소프트웨어 환경설정 및 코드 생성
소프트웨어 컴포넌트(SW-C) 설계와 RTE 관련 설계를 마치게 되면 OS, I/O, 메모리, 서비스 등의 베이식 소프트웨어에 대한 환경설정을 하고 코드 생성을 하게 된다. 그림 14는 EAD, OIL Configurator, GENy라는 도구를 사용하여 베이식 소프트웨어를 설정하는 단계를 보여준다.
■ Software Integration
현재 AUTOSAR 툴체인에서는 소프트웨어 Integration과 Build 기능은 지원하지 않는다. 따라서 각각의 도구에서 생성된 코드들, 즉 응용 소프트웨어, RTE, 베이식 소프트웨어 등의 코드를 통합개발환경인 CodeWarrior에서 Integration하여 컴파일과 링크 과정을 거쳐  ECU로 포팅해야 한다(그림 15).

테스트
■ PC 환경 테스트(SILS 테스트)
Software Integration을 마친 프로젝트는 ECU 단품 테스트를 하기 이전에 PC 환경에서 기능 테스트를 수행하게 된다. 여기서는 Vector의 CANoe를 사용하여 가상의 노드를 생성하고 ECU의 입출력 값을 확인하기 위한 입출력 시뮬레이션 패널을 생성하여 요구사항 테스트 케이스를 기반으로 테스트를 수행하게 된다.
■ 단품 테스트(HILS 테스트)
PC 환경 테스트를 마친 프로젝트는 실제 하드웨어인 ECU와 입출력 장치들을 부착시킨 후 실제 입출력 값을 확인하기 위한 단품 테스트를 수행하게 된다. 차량 속도는 파형발생기, 스티어링 휠 회전속도는 실부하 스티어링 휠 센서, 출력 전류는 실부하 솔레노이드를 ECU와 연결하여 테스트 하고, 주어진 I/O 신호와 ECU 간의 인터페이스 부분에서 요구사양을 확인한다.
■ 실차 테스트
실차 테스트는 프로젝트 개발의 마지막 단계로 SILS 및 HILS 테스트를 마친 단품 ECU를 실차에 장착하여 진행하는 테스트이다. GM대우의 라세티 차량에 개발한 SSPS ECU를 탑재하여 다양한 기능에 대한 성능시험을 수행하였다. 실제 도로주행 테스트 결과, 차량의 속도 변화에 따라 조향감이 변화하였으며, 고속에서 급격한 스티어링 휠의 변화에 대한 응답부분에서도 요구사항을 만족하였다. 전반적으로 조향감 또한 현재 양산중인 제품과 유사한 성능을 보임을 확인했다.

AEM_Automotive Electronics Magazine