The Korean Society Of Automotive Engineers

Journal Archive

Transactions of the Korean Society of Automotive Engineers - Vol. 25 , No. 1

[ Article ]
Transactions of the Korean Society of Automotive Engineers - Vol. 25, No. 1, pp.116-126
Abbreviation: KSAE
ISSN: 1225-6382 (Print) 2234-0149 (Online)
Print publication date 01 Jan 2017
Received 31 Oct 2016 Revised 07 Dec 2016 Accepted 12 Dec 2016
DOI: https://doi.org/10.7467/KSAE.2017.25.1.116

AUTOSAR 기반 ECU의 모델 기반 모드관리 개발 기법에 관한 연구
권재희1) ; 선우명호1) ; 이우택*, 2)
1)한양대학교 미래자동차공학과
2)창원대학교 제어계측공학과

A Study on Model-based Mode Management Development Process for AUTOSAR Compliant ECU
Jaehee Kwon1) ; Myungho Sunwoo1) ; Wootaik Lee*, 2)
1)Department of Automotive Engineering, Hanyang University, Seoul 04763, Korea
2)Department of Control and Instrumentation Engineering, Changwon National University, Gyeongnam 51140, Korea
Correspondence to : * E-mail: wootaik@changwon.ac.kr


Copyright Ⓒ 2017 KSAE
Funding Information ▼

Abstract

We suggest a process for the basic software configurations and application development in the mode management design of AUTOSAR-based ECU. Mode management is an essential task and AUTOSAR provides the mode management components for the runtime state handling of an ECU, such as BswM, application mode manager and RTE. BswM is used to meet the custom’s requirements for ECU state handling. The behavior of BswM is configured with a set of rules in the form of “if-else” statements, so it is a complicated job and a potential source of errors as the number of rules increases. These difficulties can be overcome using the Model-Based Development approach, which is widely used in the AUTOSAR SW development. An efficient process is proposed to apply the MBD approach to the BswM configuration. An application mode development process is also proposed to improve the mode management design by combining the MBD process. Development tools are developed to adapt these proposed processes to the traditional ones. Simulation and experimental results are provided to prove the feasibility of the proposed approach.


Keywords: AUTOSAR, BSW, SWC, Mode management, BswM, AppM, MBD
키워드: 오토사, 베이식 소프트웨어, 소프트웨어 컴포넌트, 모드관리, 베이식 소프트웨어 모드 매니저, 응용소프트웨어 모드 매니저, 모델기반개발

1. 서 론

차량의 전자화에 따라 차량내의 전자제어장치(ECU)의 수는 크게 증가되었다. 양산중인 고급 차종의 경우에는 약 100여개의 ECU가 장착되기도 한다. 차량내의 전체 ECU 수량뿐만 아니라 단일 ECU의 소프트웨어도 기존 기능의 통합 및 운전지원시스템 등의 신규 기능이 차량에 도입됨에 따라 복잡도가 크게 증가하고 그에 따른 개발비도 증가되고 있다. OEM 및 ECU 제조업체는 소프트웨어 개발의 부담을 경감하고 소프트웨어의 품질을 확보하기 위하여 소프트웨어, 데이터 포맷, 개발 프로세스 등의 재사용을 목표로 AUTOSAR 컨소시엄을 출범하였다.1,2)

ECU 소프트웨어는 실행시 초기화, 실행, 오류, 대기, 종료 등과 상태들을 고려하여야 한다. 비록 이러한 상태기계가 명시적으로 구현되지 않는다 하더라도 본질적으로 ECU는 동작상황에서 여러 상태를 가지고, 각 상태로 진입 시 설정된 동작을 단계별로 수행하고 해당 상태에서 정의된 일련의 작업을 수행하게 된다. 개별 ECU의 상태 뿐만 아니라 차량네트워크를 통하여 정보를 공유하는 상황에서는 전체 차량의 네트워크 상태 또한 관리되어야 한다. ECU의 상태 관리는 기능안전요구와 저전력요구 등이 고려되면서 더욱 복잡하게 되었다.

AUTOSAR에서는 상태기계에 해당하는 기능을 수행하기 위한 모드 관리 매커니즘을 제공한다. 네트워크 상태를 관리하기 위하여 AUTOSAR NM과 같은 네트워크 관리 서비스를 제공하고 있다. 개별 ECU의 상태를 관리하기 위하여 베이식 소프트웨어 계층에서 BswM 관련 서비스를 제공하고 있다. 또한 응용 소프트웨어의 계층에서 활용할 수 있도록 상태 관리 서비스를 제공하고 있다.3,4)

네트워크 관리 서비스의 경우 그 사용 용도가 명확하므로 미리 정의 되어 있는 네트워크의 상태에 따라 제공하는 서비스를 활용하면 된다. 그러나 ECU의 동작 상태를 관리하기 위한 BswM과 응용소프트웨어 상태관리의 경우 기본적인 서비스만 제공할뿐 구체적인 상태가 정의되어 있지 않으며 활용 방법 또한 개발자의 역량에 전적으로 의존하고 있다.

BswM이 베이식 소프트웨어 계층의 상태를 관리한다. BswM은 ECU 내부의 다른 소프트웨어 모듈에서 전달되어 오는 상태 관련 정보들을 가지고 규칙에 기반하여(Rule-based) 필요한 서비스들을 호출하는 방식이다. 이러한 규칙기반 상태 관리 방식은 개별 소프트웨어 모듈들이 가지고 있는 상태를 무시한 처리 방식이다. 이 방식은 규칙의 생성 단계에서 중복되는 상태 및 누락되는 상태를 갖게 되는 잠재적인 한계를 가지고 있으며, 상태를 고려한 시험검증을 매우 어렵게 만들고 있다.

응용 소프트웨어 컴포넌트 개발시에는 모델기반 방법으로 개발하는 것이 일반화 되어가고 있다.5,6) 그러나 응용 소프트웨어 모드 관리 소프트웨어 컴포넌트는 AUTOSAR 도구와 대표적인 모델기반 개발 도구인 Simulink가 서로 연동되지 않아 전통적인 코딩 방식으로 개발되고 있다. 이것은 모드관리자 개발을 번거롭게 할 뿐만 아니라 전체 모델기반 개발 프로세스에도 장애물로 작용하게 된다.

본 논문에서는 모델기반 개발 방법을 AUTOSAR 기반으로 모드 관리소프트웨어 개발에 효율적으로 적용할 수 있는 방안을 제시한다. BswM 파라미터 설정시 모델 기반 개발 방법론을 적용하여 개발의 가속화와 안정화를 도모한다. 어플리케이션 개발단계에서 모드 정보를 이용하여 상태기계를 생성하고 이 상태기계를 활용하여 모델기반 개발이 용이하도록 한다.


2. AUTOSAR 소프트웨어 아키텍처
2.1 AUTOSAR 개발 절차 및 ARXML 파일

AUTOSAR 소프트웨어 아키텍처는 크게 베이식 소프트웨어(BSW), 런타임환경(RTE) 및 어플리케이션으로 나눌 수 있는 계층구조를 가지고 있다(Fig. 1). 각 계층을 구성하는 BSW의 컴퍼넌트와 RTE의 소프트웨어 요구사항과 소프트웨어 설계사양을 제정하였고, 계층 간의 추상화된 인터페이스를 제공한다. 또한 RTE를 바탕으로 동작하는 응용 소프트웨어는 SW 컴포넌트로 개발되며 이를 위한 템플릿과 설계 방법을 제공한다. 어플리케이션은 SWC형태로 구성되며, 구현단계에서는 RTE가 제공하는 인터페이스와 스케줄링에 의해 동작한다.7)


Fig. 1 
AUTOSAR Software Architecture

AUTOSAR는 OEM과 ECU 공급 업체 간의 개발프로세스와 이 과정에서 필요한 데이터 파일의 형식을 정의하였다. XML형식인 ARXML 파일이 각 개발 단계에서의 데이터 파일을 정의하는데 사용되며, 각 개발단계에 필요한 사양 및 산출물을 개발 주체간의 공유를 목적으로 사용된다.8) 일반적으로 OEM에서 개발하고자 하는 차량의 특정 시스템을 가상의 버스 환경(Virtual Function Bus)상에서 소프트웨어 컴포넌트 형태로 상위설계를 수행한다. 실제 ECU의 구현은 각 ECU 제조업체에서 수행하게 되며, OEM에서는 시스템 기술파일에서 해당 ECU의 개발에 필요한 정보를 전체 추출하여 관련 정보를 전달한다. 제조업체는 이를 기반으로 자신의 ECU를 구성한 ECUC(ECU Configuration)파일을 작성하여 BSW를 설정한다. ECUC파일을 기반으로 BSW의 설정 코드가 생성되며, 상위 어플리케이션을 개발하고 RTE를 생성한 후 전체 코드를 통합하여 최종적으로 ECU가 구현된다.9,10)

2.2 AUTOSAR의 모드 관리

AUTOSAR에는 모드 요청자(Mode Requester), 모드 사용자(Mode User), 모드 관리자(Mode Manager)의 세 종류의 모드 행위자가 존재한다. 모드 요청자는 모드 관리자에게 모드의 변경을 요청을 하며, 모드 관리자는 모드 변경 요청을 처리하여 내부 모드를 변경하며, 변경된 모드를 다른 모드 사용자에게 전달한다. 모드 사용자는 모드 관리자로부터 현재모드 정보를 받거나 이를 이용하여 런어블을 수행하는 이벤트로 사용한다.

모드 정보는 RTE상의 포트인터페이스를 이용하거나 BSW단에서의 C-API 인터페이스를 이용하여 모드 관리자로부터 모드 사용자에게 제공된다. 해당 모드 정보는 ModeDeclarationGroup 형식으로 정의된다. 이 ModeDecleartionGroup은 소프트웨어 컴퍼넌트 기술 파일에 포함되며 RTE 코드를 생성과정을 거쳐 코드로 구현된다. 모드 정보를 관리하는 모드 관리자는 BswM이나 AppM으로 구현된다.

2.3 BSW 모드 관리

Fig. 2와 같이 BSW의 모드 관리를 담당하는 BswM의 설정은 크게 Mode Arbitration과 Mode Control로 구성된다.4) Mode Arbitration은 다른 BSW혹은 SWC로부터의 정보를 기반으로 규칙을 구성하며, 해당 규칙의 참/거짓 조건에 따라 할당된 Action List를 수행한다. Action List는 하나 이상의 Action으로 구성되며 이를 통하여 다른 BSW를 제어한다. SWC는 포트 인터페이스를 이용하여 BswM에게 모드를 요청 할 수 있다. RTE를 통해 정보가 전달되며 BswM은 이를 수신포트로 수신한다. BswM의 각 파라미터는 EcuC 파일에 ARXML 형식으로 기술되며, 이를 바탕으로 코드를 생성한다.


Fig. 2 
BSW Mode Management

2.4 어플리케이션 소프트웨어 모드 관리

어플리케이션 소프트웨어의 내부 상태관리는 일반적인 소프트웨어 개발 방식으로 구현할 수 있으며, 관련된 상태정보를 다른 SWC나 BswM에 제공하거나 이를 바탕으로 특정 런어블의 동작을 제어하는 기능을 수행하는 경우에는 AUTOSAR가 제공하는 모드 인터페이스를 사용하여야 한다. Fig. 3과 같이 AppM은 모드 관리자의 역할을 수행하고 다른 모드 요청자로부터의 모드 변경요청을 중재하고 모드를 변경하도록 구성할 수 있다. 처리되는 모드는 사전에 Mode Declaration Group을 이용하여 정의된다. 모드 사용자는 수신포트를 통하여 현재 모드 정보 및 모드 전환 이벤트를 받게 된다. 모드 포트 인터페이스는 이에 연결된 런어블을 트리거하거나, 다른 RTE 이벤트에 연결된 런어블의 스케줄링을 중지시킬 수 있다.5)


Fig. 3 
Application Mode Management


3. 모델기반 AUTOSAR 모드 개발
3.1 AUTOSAR와 모델기반 소프트웨어 개발

모델 기반의 차량 ECU 소프트웨어 개발은 산업계에 널리 도입되고 있다. 기존의 소프트웨어 개발과 비교하여 여러 장점이 부각되고 있다.2) MATLAB/Simulink, TargetLink 등이 활발하게 사용되고 있다. AUTOSAR환경에서도 응용 소프트웨어의 SWC 기술 파일을 상용 모델 기반 툴과 연계하여 소프트웨어개발을 수행할 수 있다. 상용 모델기반 툴을 사용하여 SWC 기술 파일에 정의된 포트 프로토타입과 런어블 정보를 추출하고 모델의 템플릿을 자동 생성한다. 템플릿 내에 알고리즘을 구현하고 자동으로 실행 코드를 생성한다.

3.2 상태기계 기반 BswM 설정

ECU의 런타임의 BSW의 동작상태는 BswM에 의해 관리된다. Fig. 4(a)와 같이 상위 어플리케이션 혹은 BSW 내부의 상태 천이에 따라 특정한 동작을 수행하는 규칙을 설정하여 동작을 제어하게 한다. BswM은 특정 조건에 대한 논리적인 판단식과 그 결과에 따른 일련의 수행 동작으로 구성되며, 그 동작방식은 if-else 형태의 조건문과 유사하다고 볼 수 있다. 각 소프트웨어 컴포넌트는 상태를 가질 수 있으나 이를 단순한 규칙에 기반하여 관리하도록 하여, 상반되는 상태, 누락되는 상태, 부적합한 조건설정 등의 많은 잠재적 오류 가능성을 갖게 되었다. AUTOSAR에서 조건간의 정합성을 검증하는 방안을 포함하고 있지 않으며, 이는 전적으로 개발자의 부가적인 검증과정에 의존된다. 이 문제를 Fig. 4(b)와 같이 상태기계를 활용함으로써 극복할 수 있다. 구체적으로 Simulink와 같은 모델기반 개발 도구와의 연계함으로써 모델기반 개발을 더욱 가속화 할 수 있다.


Fig. 4 
BswM and State Machine

BswM 관련 정보를 가지고 상태기계를 만들기 위하여서는 기존의 정보관리 방법과 상태기계의 정보와의 상관관계를 분석하여야 한다. BswM의 규칙에 있어서 각 조건의 판단에 사용되는 입력은 Mode-RequestSource로, 출력은 AvailableAction으로 AUTOSAR BswM 사양에 정의되어 있다(Table 1).

Table 1 
BswM ModeRequestSources and Actions
ID BswMModeRequestSource ID BswMAvailableActions
C0
C1
C2
C3
C4
C5
C6
C7
C8
BswMModeRequest
BswMModeSwitchNoti.
BswModeNotification
CanSMIcomIndication
CanSMIndication
ComMIndication
ComMInitiateReset
ComMPncRequest
... (이하 생략)
A0
A1
A2
A3
A4
A5
A6
A7
A8
ComMAllowCom
ComMModeLimitation
ComMModeSwitch
CoreHaltMode
DeadlineMonitoringControl
EcuMGoDown
EcuMGoHalt
EcuMGoPoll
... (이하 생략)

상태기계 구성을 위하여 먼저 상태 정보가 결합되어야 하는 컴포넌트를 고려하여 필요한 상태를 정의한다. 연관된 각 규칙의 입력을 조건식형태로 표현하여 상태 천이 조건을 만들고, 출력은 이 천이조건과 결합한다. 그러나 이 입출력을 사용하여 상태기계를 구성할 경우 천이 조건식과 동작목록이 지나치게 길어져 상태기계 가독성이 떨어지게 된다. 이 문제를 해결하기 위하여 입력과 출력에 고유한 ID를 부여하고 이를 stateflow로 구성시 사용한다. 실제 ECU의 구현에서는 복수개의 CAN 채널처럼 복수개의 인스턴스를 가질 수 있다. 이러한 복수 인스턴스에 대하여서는 인스턴스 ID를 추가하는 명명법을 사용하여 표현한다.

Ci_k : BswM RequestSource(입력)
i:BswMModeRequestSource Id, k: Instance Id of Source
Ai_k : BswM Action(출력)
i: BswMAction Id, k: Action Parameter Id

이러한 기법을 활용한 BswM 규칙과 상태기계와의 대응관계를 Fig. 5에 나타내었다.


Fig. 5 
Relationship between Stateflow and BswM Parameters

Fig. 6에서 개발 절차차원에서 기존의 방법과 모델기반 개발 프로세스 방법을 비교하였다. 두가지 방법 모두 최종 ECU에 포함되어야 하는 BSW의 구성 컴포넌트에 대한 정보를 가지고 자동코드 생성기법을 활용하여 최종적인 BSW의 소스파일을 생성하여야 한다.


Fig. 6 
Development Process of BswM

전형적인 방법에서는 AUTOSAR BSW 설정 도구를 활용하여 규칙기반으로 BswM을 설정하여야 한다.

그러나 제안하는 모델기반의 BswM 개발 과정에서는 BswM 규칙 설정을 생략하고 다음과 같이 개발할 수 있다.

1) BswM 설정 관련 정보 추출

관련정보를 추출하여 상태기계로 변환한다. 즉, 규칙과 관련될 수 있는 입력 {Ci_k}와 출력 {Ai_k}를 도출한다.

2) BswM 상태 모델 구성 및 검증

상태기계를 개발하는 도구(예, stateflow 등)를 활용하여 상태모델을 상세설계하고 개발 및 검증한다.

3) BswM 설정 ARXML 파일 생성

상태기계로부터 BswM관련 정보를 추출하여 ECUC에 반영한다. 이 과정은 모델에서 사용된 조건식에서 {Ci_k}와 {Ai_k}를 추출하여 이를 Table 1로 역 변환하여 BswM관련 Arxml을 생성하게 된다.

모델기반 BswM 개발 과정으로 상태를 갖는 시스템을 단순 규칙의 배열로 개발함으로서 발생할 수 있는 문제를 극복할 수 있다. 아울러 코드 생성 이후에 가능했던 BswM의 검증을 부분적으로 설정단계에서 가능하게 함으로서 개발기간을 더욱 단축할 수 있다.

3.3 어플리케이션 소프트웨어의 모드관리

모델기반 응용 소프트웨어 개발 프로세스에서는 AUTOSAR 도구를 사용하여 SWC의 입출력과 내부의 런어블을 포함하는 구조를 설계하고, Simulink와 같은 모델기반 개발 도구를 사용하여 SWC의 구조를 불러들이고 각 SWC의 동작을 상세하게 모델링한 후 자동으로 소스코드를 생성한다.

응용소프트웨어 모드 관리자를 활용하기 위해서는 이와는 별도의 개발 프로세스를 거쳐야 한다. 상태관련 정보를 처리하기 위해서는 모드 정보를 전달하는 포트를 구성하여야 하며, 해당 포트에는 정의된 모드 정보를 포함하고 있는 ModeDeclarationGroup을 구성하여 추가하여야 한다.

Fig. 7(a)와 같이 기존의 전형적인 개발 방법에서는 정의된 모드 정보(App Mode Manager SwC Description)를 가지고 AUTOSAR 도구를 활용하여 코드 구조를 생성하고 이 코드 구조 내에 수동으로 설계하고 프로그래밍 하여야 한다. 이렇게 개발된 모드 관리자 코드는 다른 응용소프트웨어 코드들과 함께 소스코드 단계에서 통합되어야 한다. 이와 같이 일반 응용 소프트웨어는 모델기반 자동코드 생성기법으로, 모드관리자는 수동코딩 방법으로 개발한 후 통합하는 불합리가 존재하게 된다. 이는 모드와 관련된 기능의 검증에서도 최종 코드를 가지고 통합 후 검증해야 하므로 개발 시간을 지연시키는 문제점도 안게 된다.


Fig. 7 
Development Process of Application Mode Management Component

모델기반 응용소프트웨어 모드 관리자 개발 방법에서는 이와 같은 불합리와 문제점을 개선하기 위하여 모드관련 정보를 모델기반 개발 도구로 불러들이는 방법을 제안하고 모델기반 도구로 모드 관리자를 구현 검증하고, 최종적으로 이렇게 생성된 모델을 활용하여 최종코드가 아닌 모델이 통합될 수 있다. Fig. 7(b)에서 제시하는 모델기반 AppM개발 과정을 정리하면 다음과 같다.

1) AppM Model 구조 생성

자체적으로 개발한 변환 프로그램을 활용하여 AppM Swc Description 정보로부터 응용소프트웨어 모드 정보를 추출하여 stateflow의 상태를 생성한다.

2) AppM State Model 구현 및 검증

stateflow를 활용하여 모드 관리자의 천이조건 등을 구체적으로 모델링하고 검증한다.

3) Model Merge

기존의 일반 응용 소프트웨어와 모드 관리자 모델을 연결하여 모드 관련 기능을 개발하고 검증한다.

제안된 모델기반 개발 방법을 통하여 기존에 수동코딩 방법으로 개발되는 상태기계 수동프로그램의 어려움을 극복할 수 있을 뿐만 아니라, 모드와 관련된 기능 또한 모델로 관리할 수 있게 됨으로써 보다 완성도 높은 모델기반 개발 프로세스를 완성할 수 있게 된다.


4. 검증 시스템 구성

제안된 개발 방법론을 검증하기 위하여 시험환경을 구성하였다. 벡터사의 AUTOSAR 4.2 버전을 베이식 소프트웨어로 활용하여, Fig. 8과 같이 소프트웨어 구조를 설계하였다.


Fig. 8 
Software Architecture of Target System

Fig. 9와 같이 실험환경을 구성하였다. Simulink를 활용하여 MIL(Model in the Loop) 시뮬레이션 환경을 구성하고 설계된 모델의 정합성을 검증하였다. 테스트케이스를 작성하고 이를 stateflow 모델에 인가하고, 상태기계의 변경을 관측하여 모델을 평가하는 과정을 수행하였다. 이후 코드를 자동생성 하고 타겟시스템에 적용하였다. MIL에서 사용된 동일한 테스트케이스를 HIL(HW in the Loop) 테스트에서도 활용할 수 있도록 구성하였다. 이후 MIL과 HIL의 결과를 비교하였다.


Fig. 9 
Test Environment and Target System

4.1 BswM설정

제안된 방법으로 전체 BSW관리 사양중 CAN통신의 송신 모드 부분을 설계하였다. CAN통신을 관리에는 CanSM, ComM이 연관되어 있다. 이 컴퍼넌트는 CAN자체의 상태관리와 타 소프트웨어로부터의 통신사용 요청의 관리를 각각 담당한다. 예를 들면, CanSM은 MCU내의 CAN 하드웨어의 초기화 및 Bus Off와 같은 에러 상태 등을 관리한다. BswM은 CAN의 통신 가능 상태를 CanSM을 통해서 모니터링하여 전송 기능이 필요한 경우에 Com모듈에 PduGroup의 활성화를 요청하여 통신을 가능하게 한다. Bus Off등과 같은 상태에서는 전송을 중단하기 위해 PduGroup의 비활성화를 요청한다. 이러한 동작조건을 반영하여 Fig. 10과 같이 상태기계를 설계하였고, Fig. 11과 같이 BswM 설정 파라미터를 생성하였다.


Fig. 10 
BswM Mode Management (CAN trasmit mode)


Fig. 11 
Generated BswM Parameters

4.2 어플리케이션 모드 관리

본 실험에서는 Table 2와 같이 어플리케이션에서의 요구사양을 설정하였다. 제안된 요구사양은 대부분의 ECU에서 요구되는 상태천이를 추상화하여 도출하였다. 일반적인 차체 계열 ECU에서 발견할 수 있는 대표적인 사용예이다. 최초 어플리케이션이 동작을 하게 되면, 일련의 초기화 과정을 거치고 사용자의 동작요구에 따라 특정 기능을 수행하며, 차속 등의 차량상태에 따라 동작 모드를 전환한다. 동작 중 센서이상 등의 고장 정보가 발생되면, Fail Safe상태로 천이하거나, 진단기의 요청에 따라 진단모드로 진입한다.

Table 2 
Requirements for Application State Machine
① INIT1, INIT2, RUN1, RUN2, SHUTDOWN, DIAG, FAILSAFE의 상태를 가진다.
② 어플리케이션은 초기에 INIT1상태로 진입하며, 이그니션상태가 ON이 되면 INIT2로 진입한다.
③ INIT2에서는 사용자의 기능요구요청에 의해 RUN1/2 상태로 진입한다.
④ RUN1과 RUN2는 차속의 변화에 따라 상태가 천이된다.
⑤ RUN1/2상태에서 기능요구가 없는 경우에는 INIT2로 복귀한다.
⑥ INIT2, RUN1/2 상태에서 외부 진단기의 요구가 감지되면, DIAG상태로 천이한다.
⑦ INIT2, RUN1/2 상태에서 고장이 감지되면 FAILSAFE로 전환된다.
⑧ ING상태가 OFF가 되면 SHUTDOWN으로 천이된다.

요구사양으로부터 AppM 소프트웨어 컴퍼넌트 구성에 필요한 입력과 출력을 도출하여 Fig. 12와 같이 설계하였다. 컴퍼넌트의 출력 포트로 AppMode_Switch 포트를 가지고 있으며, 해당 포트는 요구사양에서 정의된 모드정보를 ModeDeclarationGroup으로 구성하여 소프트웨어 컴퍼넌트에 포함하였다.


Fig. 12 
Application Mode Manager Software Component

개발된 툴을 이용하여 해당 소프트웨어 컴퍼넌트에 포함된 ModeDeclarationGroup정보를 추출하여 Fig. 13과 같은 템플릿을 생성한다. 이후 요구사양을 만족하는 모드관리 소프트웨어를 Fig. 14와 같이 완성하였다.


Fig. 13 
Application Mode Template


Fig. 14 
Design of Application Mode Manager

4.3 실험 결과

제안된 방법으로 시뮬레이션 및 실제 타겟에서의 테스트를 수행하였다. 4.1절에 기술한 바와 같이 CAN통신과 관련된 기능에 대한 7가지의 실험을 수행하였다. 상위 어플리케이션으로부터의 통신 요청을 관리하는 Communication Manger, CAN 모듈의 상태를 관리하는 CAN State Manager, 진단 통신을 수행하는 Diagnostic Communication Manager로부터 상태정보를 받아 BswM의 정상 동작을 확인하였고 그 결과는 Table 3과 같다.

Table 3 
Verification of CAN Communication BswM Functions
ID 요구 동작 확인
TC_00 어플의 요청에 따른 통신개시 OK
TC_01 어플의 요청에 따른 통신중단 OK
TC_02 Disable Communication Tx (진단기) OK
TC_03 Enable Communication Tx (진단기) OK
TC_04 Bus Off 발생시 전송 중단 OK
TC_05 Bus Off 회복시 전송 개시 OK
TC_06 Bus Off 상태에서의 어플의 통신 중단 OK

어플리케이션 모드관리 컴퍼넌트의 시험을 위하여 테스트 시나리오를 구성하고 Fig. 9에서 구성한 환경을 이용하여 내부 상태를 측정하였다. 상태기계에 영향을 미칠 수 있는 입력값들을 Fig. 15에서 보는 바와 같이 시간에 따라 변화하여 주었다. 예를 들어 2초에 Ignition 입력을 ON 하여 주고, 5초에 FuncReq 입력을 ON 하여 주었다. 진단(DiagReq)과 오류(ErrStatus)와 관계된 입력도 각각 28초와 52초에 변화를 주고, 차속도 연속적으로 계속 변화하여 주었다. Fig. 15 상단의 그래프와 같이 입력 정보에 따라 어플리케이션 모드(Application State)가 INIT1, INIT2, RUN1, RUN2, DAIG, 그리고 FAILSAFE의 상태값을 갖으며 변화되는 양상을 확인할 수 있다. 시뮬레이션 결과와 타겟 수행 결과가 거의 동일하게 얻어짐을 확인할 수 있다.


Fig. 15 
Comparison of Simulation and Experiment Results


5. 결 론

차량용 ECU 소프트웨어의 각종 모드 관리는 ECU의 기능을 수행함에 있어 필수적이고 중요한 역할을 수행한다. AUTOSAR에서는 이를 위한 모드관리방안과 BSW 모드관리 컴퍼넌트를 제공한다. 이러한 모드관리를 설계에 있어 상태기계 기반의 설계를 적용하여, 설계 및 검증을 수행할 수 있는 방법을 제안하였다. 이를 Simulink의 Stateflow를 이용하여 구현하여 검증하고 이를 실제 타겟시스템에 적용하여 개발 절차의 유용성을 보였다.

이러한 개발 방법은 상태기계 설계를 제공하는 다양한 UML 개발툴에 적용하거나 AUTOSAR 전용 설계툴에 상태기계기반 설계를 적용할 수 있다. 특히, 모델기반설계 방법을 이용하여, BswM 설계 과정에서 발생할 수 있는 시행착오를 줄이고 시뮬레이션 및 검증을 용이하게 하여 소프트웨어의 품질을 향상시킬 수 있다.


Acknowledgments

이 논문은 2015 ~ 2016년도 창원대학교 자율연구과제 연구비 지원으로 수행된 연구결과임.


References
1. AUTOSAR, AUTOSAR Layered Software Architecture, http://www.autosar.org/fileadmin/files/releases/4-2/software-architecture/general/auxiliary/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf, (2016).
2. S. Bunzel, K. Heidary, S. Fürst, A. Lajtkep, J. Mössinger, J. Cordes, S. Schmerler, C. Kühn, F. K. Biller, B. Frielingsdorf, R. Rimkus, R. Kacel, A. Gilberg, B. Delord, K. Nishikawa, H. Hirano, A. Titze, and B. Kunkel, “Hardwareindependent Software Development with AUTOSAR,”, Lecture Notes in Informatics, p503-508, (2010).
3. AUTOSAR, AUTOSAR Guide to Modemanagement, http://www.autosar.org/fileadmin/files/releases/4-2/software-architecture/system-services/auxiliary/AUTOSAR_EXP_ModeManagementGuide.pdf, (2016).
4. AUTOSAR, AUTOSAR Specification of Basic Software Mode Manager, http://www.autosar.org/fileadmin/files/releases/4-2/software-architecture/system-services/standard/AUTOSAR_SWS_BSWModeManager.pdf, (2016).
5. I. Park, W. Lee, and M. SunWoo, “Application Software Modeling and Integration Methodology using AUTOSAR-ready Light Software Architecture,”, Transactions of KSAE, 20(6), p117-125, (2012).
6. K. Jo, J. Kim, D. Kim, C. Jang, and M. Sunwoo, “Development of Autonomous Car-Part I: Distributed System Architecture and Development Process,”, IEEE Transactions on Industrial Electronics, 61(12), (2014).
7. K. Lee, I. Park, M. SunWoo, and W. Lee, “AUTOSAR-ready Light Software Architecture for Automotive Embedded Control Systems,”, Transactions of KSAE, 21(1), p68-77, (2013).
8. AUTOSAR, AUTOSAR Specification of ECU Configuration, http://www.autosar.org/fileadmin/files/releases/4-2/methodology-and-templates/templates/standard/AUTOSAR_TPS_ECUConfiguration.pdf, (2016).
9. I. Park, “Resource-aware Integration of AUTOSAR-COMPLIANT ECUs with an Empirical WCET Prediction Model,”, Int. J. Automotive Technology, 17(4), p717-729, (2016).
10. G. Sandmann, and M. Seibt, “AUTOSAR-Compliant Development Workflows: From Architecture to Implementation - Tool Interoperability for Round-Trip Engineering and Verification and Validation,”, SAE 2012-01-0962, (2012).