채승엽, 박대영, 이우승, 이헌철 등 인포뱅크(Infobank) AUTOSAR 사업부 멤버가 AUTOSAR 최신 기술에 대한 아티클을 6회에 걸쳐 연재한다. 인포뱅크 사업부는 AUTOSAR 추세와 요구사항에 맞게 AUTOSAR Ethernet Solution, AUTOSAR 플랫폼 교육, SWC 개발 Tool과 같은 AUTOSAR 전반에 걸친 업무를 수행하고 있다. 네 번째 회는 ‘AUTOSAR MCAL’이다. 

1. AUTOSAR의 실무 이해
2. AUTOSAR OS
3. AUTOSAR RTE
4. AUTOSAR MCAL
5. AUTOSAR CAN
6. AUTOSAR FlexRay

지난 호에 이어 이번 연재에서는 차량용 반도체 회사에서 반드시 지원해야 하는 AUTOSAR용 Device Driver인 MCAL(Microcontroller Abstraction Layer)을 주제로 설명하고자 한다.
먼저 MCAL에 대해 간략히 소개하고, 종류별로 어떠한 기능에 각각 사용하는지 설명한다. MCAL의 종류가 많은 관계로 상세히 하나하나 설명하기에는 무리가 있다. 그래서 실무에서 사용하는 간단한 DIO Control하기 위한 시스템 설계를 해 ARXML을 작성하고 작성된 ARXML을 Generate해서 각각의 함수 호출관계를 도식화해 설명할 예정이다. 시스템 설계단계는 AUTOSAR 개발 단계의 1단계에 해당해 MCAL에 대해 전혀 고려해야할 대상이 아닌 것 같지만, 시스템 설계 단계에서 MCAL의 제어를 위한 Interface 과정에서 함수인자(Argument)를 MCAL 제어를 위해 동일한 데이터 형(Data Type)으로 정의를 해야지만 이상동작 없이 제어(Control)할 수 있다.
본 연재에 소개될 예제에서는 MCAL을 시스템 설계 단계에서부터 설명하기 위해서 참고용으로 설계한 것이니 참고하기 바란다. 그리고, MCAL에서 생성된 소스코드는 사용할 Generator Tool과 독자 Parameter에 따라서 소스가 상이할 수 있으니 주의하기 바란다.

MCAL이란 무엇인가

한마디로 말하면 Device Driver라고 할 수 있다. MCAL로 제공된 Device Driver는 OS가 제공되지 않는 Embedded 환경에서도 동작이 가능하다는 것이다.
즉, Firmware Level에서는 Device Driver를 제어(Control)할 수 있도록 제공되는 것이 Driver인데 AUTOSAR용 MCAL은 AUTOSR에서 규정한 API 이름을 사용해 Device Driver를 제어할 수 있도록 제공한다. 차량용 반도체 회사에서는 AUTOSAR에서 규정한 API만으로는 각 MCU의 고유한 특징을 제어하기에 부족할 경우에는 독자적인 Parameter를 제공을 하고 있다. AUTOSAR용 MCAL의 가장 큰 특징은 XML 형식을 이용한 소스코드 자동 생성이므로, MCU Vendor에 의존한 독자 Parameter를 제공할 경우 XML 형식으로 독자 Parameter를 설정할 수 있어야 하며 자동으로 독자 Parameter의 확장 API 소스코드를 생성할 수 있도록 제공해야만 한다.
MCAL은 AUTOSAR Software Architec ture상 다음 그림처럼 Microcontroller 위에 위치 해 Microcontroller를 직접적으로 컨트롤할 수 있다.

MCU Vendor에서 제공하는 독자 Parameter와 AUTOSAR에서 규정한 Parameter를 구분해 분석하기 위해서 인포뱅크는 자체 개발한 Tool을 이용한다. 그림 2와 같이 ARXML을 엑셀로 자동 변환하면 쉽게 독자 Parameter에 이해를 높일 수 있다.
독자 Parameter와 AUTOSAR에서 규정한 Parameter를 구분하는 Tag는 그림 2에서 Origin이다. 필드 값이 AUTOSAR_ECUC이면 AUTOSAR에서 제공하는 규정된 Parameter이며, 독자 Parameter는 MCUVendor의 이름(예, Freescale)으로 표기된다.
MCAL은 아래와 같이 크게 4가지로 분류된다.
1. Microcontroller Devices
2. Memory Driver
3. Communication Driver
4. I/O Driver
위의 4가지 분류에는 각각의 MCAL이 존재하는데 MCAL의 종류에 대해서 하나씩 살펴보도록 하겠다.

1. Microcontroller Devices:     
① GPT(General Purpose Timer)는 MCU driver의 prescaler와 PLL을 사용해 HW timer(OS사용)로 사용되면 time에 관련된 interrupt, wakeup에 사용할 수가 있다. GPT 사용을 위해서는 MCU의 Parameter 설정과정에서 설정해줘야만 하는 Parameter들이 있다. MCU Vendor에서 제공하는 독자 Parameter 부분도 상당부분이 존재한다.
Gpt_SetMode를 사용해 Stop 또는 Active 상태로 상태를 천이하고 Gpt_GetTime Elapsed를 사용해 주기적인 시간 기준으로 경과 시간을 알아낼 수 있다. Gpt_GetTime Remaining을 사용하면 주기적인 시간 기준으로 남은 시간에 대해서 알아낼 수 있다.


② WDT는 SW가 Logic상의 Error 등으로 인해 무한 루프 등에 빠지면 정상적인 동작을 못할 경우를 감시해 system reset 등을 수행하도록 한다. 종류는 원하던 상태로 Active되었는지를 Monitoring하는 WdgMAliveSupervision, 원하던 시간 안에 Logic이 처리되었는지를 Monitoring하는 WdgMDeadlineSupervision, 설계한 Logic대로 동작하는지를 Monitoring하는 WdgMExternalLogical Supervision 등이 있다.

③ MCU는 Clock, PLL을 초기화하고, RAM 영역의 Section들도 초기화한다. MCU는 절전모드를 활성화할 수 있으며 Reset을 할 수 있도록 한다. 그리고 Reset 원인에 대해서도 API로 제공한다. MCU는 Microcontroller 동작을 위해서 최우선적으로 설정을 해야만 하는 Device Driver이다. MCU의 초기화 함수인 Mcu_Init은 AUTOSAR 표준을 준수한다면 EcuM.c의 EcuM_Init함수에서 호출돼야 한다.

2. Memory Driver:
① EEPROM, Flash Driver는 Memory를 control하기 위한 NvM(NV RAM Manager), MemIf(Memory Interface), Ea(EEPROM Abstraction), Fee(Flash EEPROM Emulation), Eep(EEPROM), Fls(Flash)에 관련된 Device Driver이다.
 

SW-C에서는 Memory와 관련해 NvM(NV RAM Manager), MemIf(Memory Interface)을 통해서만이 Memory Control을 할 수 있다. Memory 처리의 전체 흐름은 다음 그림과 같이 처리된다.

3. Communication Driver
① SPI는 확장성이 매우 높아 UART, PLC 등 외부 chip과 통신에서도 사용이 가능한 Device Driver이다. 가장 구현이 어려운 Device Driver이며, Tool 회사가 어디까지 지원하는지 반드시 확인하고 나서 개발이 시작돼야 한다. SPI는 100% 자동생성으로 처리 되지 않음으로 제어 Logic을 I/O Hardware Abstraction SW-C, CDD(Complex Device Driver)로 구현해야만 한다.

4. I/O Driver
① ICU(Input Capture Unit)는 신호의 Rising edge Falling edge의 Signal을 설정하고 Notification을 받아내고 이를 분석해 사용하도록 하는 Device Driver이다.
Sequence는 Icu_Init(ConfigPtr)→Icu_
EnableWakeup(Ch1)→Icu_SetActivation Condition(Ch1)→Icu_SetActiation Condition(Ch1, ICU_FALLING_EDGE)→Icu_EnableNotificaion(Ch1) 설정하고 나면 Falling edge가 발생하면 Icu_SignalNofifiaion _Ch1이 호출된다.
호출된 함수에 Logic을 추가해서 기능을 구현하면 된다.
② PWM(Pulse width modulation)은 일정한 주기 내에서 Duty비를 변화시켜서 평균전압을 제어해 DC모터의 속도제어나 LED 등 헤드램프의 광량을 조절하는데 많이 사용된다. Duty Cycle은 1초 동안 반복되는 주기이며, 그 한 주기에 “HIGH Value를 유지한 %가 얼마인지가 Duty rate이다. Duty ratio가 30%일 때는 시간당 가해지는 신호의 평균값은 DC 신호의 30%가 된다. 즉, 30%의 DC신호가 가해지는 것과 거의 유사한 효과를 내는 것이다.

Duty cycle설정에 사용되는 API는 Pwm_SetDutyCycle(ChannelNumber, DutyCycle)이며, 주기와 Duty설정 API는 Pwm_SetPeriodAndDuty(Pwm_ChannelType, Pwm_PeriodType, uint16)를 사용한다.

③ ADC(Analogue Digital Converter)는 Analogue 신호를 Digital 신호로 바꾸어서 읽어 들이도록 하는 Device Driver이다. ADC Channel과 ADC Channel Group으로 나눠서 값을 읽어낼 수 있는데, ADC Channel은 ADC port 1개에 대해서만 읽어낼 때 사용되고, ADC Channel Group은 여러 개의 ADC Port가 하나의 기능을 위해 묶음으로 돼 있는 것을 읽어낼 때 사용된다.

④ DIO(Digital Input output)는 DIO channel, DIO port, DIO channel group으로 나눠 pin에 대한 input output을 설정하도록 하는 Device Driver이다.

⑤ PORT는 MCU의 기본설정 이후에 Board상의 Pin을 어떤 목적으로 사용할지를 결정하고, Pin direction(Input /output), Pin의 Level 초기값을 설정하고 실행 중에 Pin direction 변경을 위한 API를 생성할 것인지 또는 실행 중에 Port Mode의 변경을 위한 API를 생성할 것인지를 설정하는 Device Driver이다.

이제 실무에서 직접적으로 사용할 수 있는 DIO Control을 위한 ARXML을 간단히 설계해서 실제 MCAL이 어떻게 사용되는지에 대해 알아보도록 하겠다.

DIO Control을 직접 제어하기 위해서는 시스템 설계에서 일반적으로 I/O Hardware Abstraction을 이용해 Client/Server Interface에서 Server Port만 사용해야 한다. 주의 사항은 I/O Hardware Abstraction는 Sender/ Receiver Interface를 사용할 수 없다.  I/O Hardware Abstraction는 MCAL의 함수들을 직접(direct) 호출할 수 있도록 설계된다. I/O Hardware Abstraction은 EcuAbstractionSwComponent
Type으로 설계되며, I/O Hardware Abstraction을 통해서 제어 가능한 MCAL에는 GPT Driver, SPI Driver, ICU Driver, PWM Driver, ADC Driver, DIO Driver, Port Driver 이상 총 7가지가 있다. 그리고 상위 SWC(Application SWC와 SensorAcuator SWC) 2개 중에서 EcuAbstraction SWC와 Port간 통신이 가능한 것은 Sensor Acuator SWC만 가능한 것이 AUTOSAR 표준이다. Sensor Acuator SWC에서는 Logic을 구현하고 EcuAbstraction SWC는 MCAL API의 직접 호출하도록 기능이 분리돼 있다.

ARXML은 다음 그림과 같이 간단하게 DIO에 대한 값을 읽고 쓰기 위한 설계를 한 것이다.
위의 시스템 설계 ARXML은 Dio_Level Type Dio_ReadChannel(Dio_ChannelType ChannelId), void Dio_WriteChannel
(Dio_ChannelType ChannelId, Dio_Level Type Level) 이렇게 2개의 DIO API만을 Control하기 위해서 설계를 한 것이다. 시스템 설계 과정에서 Client/Server의 Port(server Port1)에서의 Queue Length는 반드시 1이상으로 설정을 해야만 하는 필수 사항임을 참고 하기 바란다.

설계된 ARXML은 그림과 같이 VFB로 도식화 될 수 있다.
위에서 설계한 내용을 수직관계로 도식화하면 그림 8, 9와 같다.

위의 시스템 설계 ARXML을 Generator해서 동작을 확인하기 위해서는 OS Task를 생성, Task에 RTE Event를 Mapping하고 MCAL의 기본인 MCU를 먼저 설정하고 어떤 용도로 Pin을 사용할지 정의하는 PORT를 설정한 이후에 DIO MCAL을 설정하도록 한다.
각각의 파일에서 생성되고 호출되는 함수들은 다음과 같다.
상위 App인 SASwc에서 Button의 상태를 체크해서 상태 값을 Led를 Control하기 위한 값으로 사용해서 Button의 상태에 따라서 Led가 On/Off하도록 하는 시스템 설계에 대한 전체적인 흐름에 대해서 살펴보았다. 앞에서도 언급했지만 시스템 설계단계의 Interface 과정에서 함수인자(Argument)는 MCAL 제어를 위해서 동일한 Data Type으로 정의돼야 한다는 것을 명심하기 바란다. 위의 예제에서는 Dio_LevelType, Dio_ChannelType이 사용됐다.


SW-C에서는 Rtc_Call_<port name> _<operation>호출해 사용하는 것이 표준이다. 그러나, Rte.c에서는 Rtc_Call_<swc name> _<port name>_<operation> 형태로 사용된 것을 확인할 수 있을 것이다. 이유는 Rte.c내의 RTE API AUTOSAR 표준은 SWC name을 포함해야 되며, SWC내의 RTE API 호출의 표준은 SWC name이 삭제된 상태에서 호출돼야 하는 것이 AUTOSAR 표준이다.
따라서, AUTOSAR 표준을 준수해 SWC 내의 RTE API 호출은 SWC name을 넣지 않도록 주의가 필요하다.

마치며

이번 호에는 AUTOSAR MCAL에서 가장 기본이 되는 DIO(Digital Input output) Control의 간단한 예제를 작성해서 MCAL에서 제공된 API를 사용해서 전체적인 큰 그림의 사용법에 대해서 알아봤다. 사실 MCAL은 MCU Vendor가 제공하는 독자 Parameter에 대해서 파악하고 사용방법을 익혀야 한다. MCAL 전체를 본다면 여기에 소개된 내용으로는 턱없이 부족한 내용들이지만, 이번 호에서는 실무에 바로 적용할 수 있고 이해에 도움이 될 수 있는 내용들을 위주로 설명해봤다. Communication Driver인 LIN, CAN, FlexRay는 다음호의 연재에서 좀 더 자세히 다룰 것이다.
다음에 연재할 내용은 AUTOSAR CAN (Controller Area Network)에 대한 내용이다. CAN은 차량용 Network를 위해 개발된 Serial 통신 프로토콜인데 CAN은 여러 가지 ECU(Electronic Control Unit)들을 병렬로 연결해 통신한다.