Transactions of KSAE, Vol. 25, No. 1, pp.116-126 (2017) Copyright C 2017 KSAE / 146-15 pissn 1225-6382 / eissn 2234-0149 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 Kwon 1) Myungho Sunwoo 1) 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 (Received 31 October 2016 / Revised 7 December 2016 / Accepted 12 December 2016) 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. Key words : AUTOSAR( 오토사 ), BSW( 베이식소프트웨어 ), SWC( 소프트웨어컴포넌트 ), Mode management( 모드관리 ), BswM( 베이식소프트웨어모드매니저 ), AppM( 응용소프트웨어모드매니저 ), MBD( 모델기반개발 ) 1. 서론 1) 차량의전자화에따라차량내의전자제어장치 (ECU) 의수는크게증가되었다. 양산중인고급차종의경우에는약 100여개의 ECU가장착되기도한다. 차량내의전체 ECU 수량뿐만아니라단일 ECU 의소프트웨어도기존기능의통합및운전지원시스템등의신규기능이차량에도입됨에따라복잡도가크게증가하고그에따른개발비도증가되고 * Corresponding author, E-mail: wootaik@changwon.ac.kr 있다. OEM 및 ECU 제조업체는소프트웨어개발의부담을경감하고소프트웨어의품질을확보하기위하여소프트웨어, 데이터포맷, 개발프로세스등의재사용을목표로 AUTOSAR 컨소시엄을출범하였다. 1,2) ECU 소프트웨어는실행시초기화, 실행, 오류, 대기, 종료등과상태들을고려하여야한다. 비록이러한상태기계가명시적으로구현되지않는다하더라도본질적으로 ECU는동작상황에서여러상태를가지고, 각상태로진입시설정된동작을단계별로수행하고해당상태에서정의된일련의작업을수 116
AUTOSAR 기반 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) 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), 모 Transactions of the Korean Society of Automotive Engineers, Vol. 25, No. 1, 2017 117
Jaehee Kwon Myungho Sunwoo Wootaik Lee Fig. 1 AUTOSAR Software Architecture 드사용자 (Mode User), 모드관리자 (Mode Manager) 의세종류의모드행위자가존재한다. 모드요청자는모드관리자에게모드의변경을요청을하며, 모드관리자는모드변경요청을처리하여내부모드를변경하며, 변경된모드를다른모드사용자에게전달한다. 모드사용자는모드관리자로부터현재모드정보를받거나이를이용하여런어블을수행하는이벤트로사용한다. 모드정보는 RTE상의포트인터페이스를이용하거나 BSW단에서의 C-API 인터페이스를이용하여모드관리자로부터모드사용자에게제공된다. 해당모드정보는 ModeDeclarationGroup 형식으로정의된다. 이 ModeDecleartionGroup은소프트웨어컴퍼넌트기술파일에포함되며 RTE 코드를생성과정을거쳐코드로구현된다. 모드정보를관리하는모드관리자는 BswM이나 AppM으로구현된다. 2.3 BSW 모드관리 Fig. 2와같이 BSW의모드관리를담당하는 BswM Fig. 2 BSW Mode Management 의설정은크게 Mode Arbitration과 Mode Control로구성된다. 4) Mode Arbitration은다른 BSW혹은 SWC 로부터의정보를기반으로규칙을구성하며, 해당규칙의참 / 거짓조건에따라할당된 Action List를수행한다. Action List는하나이상의 Action으로구성되며이를통하여다른 BSW를제어한다. SWC는포트인터페이스를이용하여 BswM에게모드를요청할수있다. RTE를통해정보가전달되며 BswM은 118 한국자동차공학회논문집제 25 권제 1 호, 2017
A Study on Model-based Mode Management Development Process for AUTOSAR Compliant ECU 이를수신포트로수신한다. BswM의각파라미터는 EcuC 파일에 ARXML 형식으로기술되며, 이를바탕으로코드를생성한다. 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와같은모델기반개발도구와의연계함으로써모델기반개발을더욱가속화할수있다. BswM 관련정보를가지고상태기계를만들기위하여서는기존의정보관리방법과상태기계의정보와의상관관계를분석하여야한다. BswM의규칙에있어서각조건의판단에사용되는입력은 Mode- RequestSource로, 출력은 AvailableAction으로 AUTO- SAR BswM 사양에정의되어있다 (Table 1). 상태기계구성을위하여먼저상태정보가결합되어야하는컴포넌트를고려하여필요한상태를정의한다. 연관된각규칙의입력을조건식형태로표현하여상태천이조건을만들고, 출력은이천이조건과결합한다. 그러나이입출력을사용하여상태기계를구성할경우천이조건식과동작목록이지나치게길어져상태기계가독성이떨어지게된다. 이문제를해결하기위하여입력과출력에고유한 ID를부여하고이를 stateflow로구성시사용한다. 실제 ECU의구현에서는복수개의 CAN 채널처럼복수개의인스턴스를가질수있다. 이러한복수인스턴스에대하여서는인스턴스 ID를추가하는명 Transactions of the Korean Society of Automotive Engineers, Vol. 25, No. 1, 2017 119
권재희 선우명호 이우택 Fig. 4 BswM and State Machine Table 1 BswM ModeRequestSources and Actions ID BswMModeRequestSource ID 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 BswMAvailableActions ComMAllowCom ComMModeLimitation ComMModeSwitch CoreHaltMode DeadlineMonitoringControl EcuMGoDown EcuMGoHalt EcuMGoPoll... ( 이하생략 ) 명법을사용하여표현한다. C i_k : BswM RequestSource( 입력 ) i:bswmmoderequestsource Id, k: Instance Id of Source A i_k : BswM Action( 출력 ) i: BswMAction Id, k: Action Parameter Id 이러한기법을활용한 BswM 규칙과상태기계와의대응관계를 Fig. 5에나타내었다. Fig. 6에서개발절차차원에서기존의방법과모델기반개발프로세스방법을비교하였다. 두가지방법모두최종 ECU에포함되어야하는 BSW의구성컴포넌트에대한정보를가지고자동코드생성기법을활용하여최종적인 BSW의소스파일을생성하여야한다. 전형적인방법에서는 AUTOSAR BSW 설정도구를활용하여규칙기반으로 BswM을설정하여야한다. 그러나제안하는모델기반의 BswM 개발과정에서는 BswM 규칙설정을생략하고다음과같이개발할수있다. Fig. 5 Relationship between Stateflow and BswM Parameters Fig. 6 Development Process of BswM 120 한국자동차공학회논문집제 25 권제 1 호, 2017
AUTOSAR 기반 ECU 의모델기반모드관리개발기법에관한연구 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 기존의일반응용소프트웨어와모드관리자모델을연결하여모드관련기능을개발하고검증한다. 제안된모델기반개발방법을통하여기존에수 Transactions of the Korean Society of Automotive Engineers, Vol. 25, No. 1, 2017 121
Jaehee Kwon Myungho Sunwoo Wootaik Lee 동코딩방법으로개발되는상태기계수동프로그램의어려움을극복할수있을뿐만아니라, 모드와관련된기능또한모델로관리할수있게됨으로써보다완성도높은모델기반개발프로세스를완성할수있게된다. 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의결과를비교하였다. 4.1 BswM설정제안된방법으로전체 BSW관리사양중 CAN통신의송신모드부분을설계하였다. CAN통신을관리에는 CanSM, ComM이연관되어있다. 이컴퍼넌트는 CAN자체의상태관리와타소프트웨어로부터의통신사용요청의관리를각각담당한다. 예를들면, CanSM은 MCU내의 CAN 하드웨어의초기화및 Bus Off와같은에러상태등을관리한다. BswM은 CAN의통신가능상태를 CanSM을통해서모니터링하여전송기능이필요한경우에 Com모듈에 Pdu- Group의활성화를요청하여통신을가능하게한다. Bus Off등과같은상태에서는전송을중단하기위해 PduGroup의비활성화를요청한다. 이러한동작조건을반영하여 Fig. 10과같이상태기계를설계하였고, Fig. 11과같이 BswM 설정파라미터를생성하였다. Fig. 9 Test Environment and Target System Fig. 10 BswM Mode Management (CAN trasmit mode) 122 한국자동차공학회논문집제 25 권제 1 호, 2017
A Study on Model-based Mode Management Development Process for AUTOSAR Compliant ECU Table 2 Requirements for Application State Machine Fig. 11 Generated BswM Parameters 4.2 어플리케이션모드관리본실험에서는 Table 2와같이어플리케이션에서의요구사양을설정하였다. 제안된요구사양은대부분의 ECU에서요구되는상태천이를추상화하여도출하였다. 일반적인차체계열 ECU에서발견할수있는대표적인사용예이다. 최초어플리케이션이동작을하게되면, 일련의초기화과정을거치고사용자의동작요구에따라특정기능을수행하며, 차속등의차량상태에따라동작모드를전환한다. 동작중센서이상등의고장정보가발생되면, Fail Safe상태로천이하거나, 진단기의요청에따라진단모드로진입한다. 요구사양으로부터 AppM 소프트웨어컴퍼넌트구성에필요한입력과출력을도출하여 Fig. 12 와같이설계하였다. 컴퍼넌트의출력포트로 AppMode_Switch 포트를가지고있으며, 해당포트는요구사양에서정의된모드정보를 ModeDeclarationGroup으로구성하여소프트웨어컴퍼넌트에포함하였다. 1 INIT1, INIT2, RUN1, RUN2, SHUTDOWN, DIAG, FAILSAFE의상태를가진다. 2 어플리케이션은초기에 INIT1상태로진입하며, 이그니션상태가 ON이되면 INIT2로진입한다. 3 INIT2에서는사용자의기능요구요청에의해 RUN1/2 상태로진입한다. 4 RUN1과 RUN2는차속의변화에따라상태가천이된다. 5 RUN1/2상태에서기능요구가없는경우에는 INIT2 로복귀한다. 6 INIT2, RUN1/2 상태에서외부진단기의요구가감지되면, DIAG상태로천이한다. 7 INIT2, RUN1/2 상태에서고장이감지되면 FAIL- SAFE로전환된다. 8 ING상태가 OFF가되면 SHUTDOWN으로천이된다. Fig. 12 Application Mode Manager Software Component Fig. 13 Application Mode Template Transactions of the Korean Society of Automotive Engineers, Vol. 25, No. 1, 2017 123
권재희 선우명호 이우택 Fig. 14 Design of Application Mode Manager 개발된툴을이용하여해당소프트웨어컴퍼넌트에포함된 ModeDeclarationGroup정보를추출하여 Fig. 13과같은템플릿을생성한다. 이후요구사양을만족하는모드관리소프트웨어를 Fig. 14와같이완성하였다. 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) 과 124 한국자동차공학회논문집제 25 권제 1 호, 2017
AUTOSAR 기반 ECU 의모델기반모드관리개발기법에관한연구 Fig. 15 Comparison of Simulation and Experiment Results 오류 (ErrStatus) 와관계된입력도각각 28초와 52초에변화를주고, 차속도연속적으로계속변화하여주었다. Fig. 15 상단의그래프와같이입력정보에따라어플리케이션모드 (Application State) 가 INIT1, INIT2, RUN1, RUN2, DAIG, 그리고 FAILSAFE의상태값을갖으며변화되는양상을확인할수있다. 시뮬레이션결과와타겟수행결과가거의동일하게얻어짐을확인할수있다. 5. 결론차량용 ECU 소프트웨어의각종모드관리는 ECU의기능을수행함에있어필수적이고중요한역할을수행한다. AUTOSAR에서는이를위한모드관리방안과 BSW 모드관리컴퍼넌트를제공한다. 이러한모드관리를설계에있어상태기계기반의설계를적용하여, 설계및검증을수행할수있는방법을제안하였다. 이를 Simulink의 Stateflow를이용하여구현하여검증하고이를실제타겟시스템에적용하여개발절차의유용성을보였다. 이러한개발방법은상태기계설계를제공하는다양한 UML 개발툴에적용하거나 AUTOSAR 전용설계툴에상태기계기반설계를적용할수있다. 특히, 모델기반설계방법을이용하여, BswM 설계과정에서발생할수있는시행착오를줄이고시뮬레이션및검증을용이하게하여소프트웨어의품질을향상시킬수있다. 후 기 이논문은 2015 ~ 2016년도창원대학교자율연구과제연구비지원으로수행된연구결과임. References 1) AUTOSAR, AUTOSAR Layered Software Architecture, http://www.autosar.org/fileadmin/files/ releases/4-2/software-architecture/general/auxil iary/autosar_exp_layeredsoftwarearchitec ture.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 AUTO- SAR, Lecture Notes in Informatics, pp.503-508, 2010. 3) AUTOSAR, AUTOSAR Guide to Modemanagement, http://www.autosar.org/fileadmin/files/ releases/4-2/software-architecture/system-services /auxiliary/autosar_exp_modemanagementgu ide.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_bsw ModeManager.pdf, 2016. 5) I. Park, W. Lee and M. SunWoo, Application Transactions of the Korean Society of Automotive Engineers, Vol. 25, No. 1, 2017 125
Jaehee Kwon Myungho Sunwoo Wootaik Lee Software Modeling and Integration Methodology using AUTOSAR-ready Light Software Architecture, Transactions of KSAE, Vol.20, No.6, pp.117-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, Vol.61, No.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, Vol.21, No.1, pp.68-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_ecucon figuration.pdf, 2016. 9) I. Park, Resource-aware Integration of AUTO- SAR-COMPLIANT ECUs with an Empirical WCET Prediction Model, Int. J. Automotive Technology, Vol.17, No.4, pp.717-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. 126 한국자동차공학회논문집제 25 권제 1 호, 2017