Journal Archive

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

Fig. 1 
AUTOSAR Software Architecture

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

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

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

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

Fig. 2 
BSW Mode Management

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

Fig. 3 
Application Mode Management

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

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).

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

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. 5 
Relationship between Stateflow and BswM Parameters

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

Fig. 6 
Development Process of BswM

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

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

모델기반 응용 소프트웨어 개발 프로세스에서는 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개발 과정을 정리하면 다음과 같다.

제안된 방법으로 전체 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

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

요구사양으로부터 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.1절에 기술한 바와 같이 CAN통신과 관련된 기능에 대한 7가지의 실험을 수행하였다. 상위 어플리케이션으로부터의 통신 요청을 관리하는 Communication Manger, CAN 모듈의 상태를 관리하는 CAN State Manager, 진단 통신을 수행하는 Diagnostic Communication Manager로부터 상태정보를 받아 BswM의 정상 동작을 확인하였고 그 결과는 Table 3과 같다.

어플리케이션 모드관리 컴퍼넌트의 시험을 위하여 테스트 시나리오를 구성하고 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