AUTOSAR

< 알아야하는 기본 개념들 >

*ECU (Electronic Control Unit) : 차량 내 특정 기능을 제어하고 관리하는 작은 컴퓨터 
 -> 간단하게 말하자면, ST 칩이나 intel 칩 등의 하나의 MCU와 주변 회로 및 소프트웨어를 합쳐서 부르는 시스템 단위

 

*ADAS (Advanced Driver Assistance System) : 운전자가 안전하고 편리하게 주행할 수 있도록 도와주는 모든 기능
 -> 주로 카메라, 레이더, 라이다 등의 센서 기술을 활용하여 주행 중 정보를 수집하고, 처리하여 운전자에게 경고 및 제동 등의 기능을 수행
 -> ex) 차선 유지 보조, 주차 보조 시스템 등

 

*ARA(AUTOSAR Runtime for Adaptive AUTOSAR) : Adaptive 플랫폼 소프트웨어 간 사용되는 API로, 이 플랫폼의 애플리케이션과 소프트웨어 간 통신 및 상호작용을 표준화하는 역할 
-> SOA를 기반으로 설계됨

• 주요 ARA API 모듈
  • ARA::COM : 서비스 간 통신 관리
  • ARA::NET : 네트워크 통신 관리
  • ARA::PER : 퍼시스턴스(데이터 저장) 관리
  • ARA::SOME/IP : Service-Orientied 통신을 위한 프로토콜

*SOA (Service-Oriented Architecture) : 서비스 지향 아키텍처로, 시스템 내에서 독립적인 서비스 단위로 설계하는 소프트웨어 아키텍처 스타일

• SOA 특징
  • 유연성과 재사용성 : 새로운 기능 추가시 기존 서비스를 수정하지 않고, 확장 가능
  • SOME/IP 기반 통신
  • 서비스 기반 설계 : 각 기능이 독립적인 서비스로 제공되며, 서비스 간 메세지 기반 통신을 통해 협력

 

 

PopcornSAR Architecture

AUTOSAR ( Automotive Opem System Architecture) : 차량 소프트웨어 개발을 표준화하기 위해 설계된 플랫폼
 -> 자동차 전자 제어 시스템의 복잡성을 효과적으로 관리하고, 개발 효율성을 높이기 위해 필요

 

< AUTOSAR는 왜 필요한가? >

• 자동차를 제어하기 위해서는 많은 ECU가 필요하다 그런데 여기서 자동차를 제어하는 ECU가 바뀔때마다 또는 해당 ECU의 개발을 담당하는 개발자들의 코드를 통합할때 사용한 언어가 다양하고 통신 방식의 다양성으로 인해 어려움이 있다. 이러한 문제점들을 해결하기 위해 ECU 간의 통신 방식이나 주고받는 데이터 형식 등을 일치시키기 위해 AUTOSAR라는 것이 나오게 되었다.
  -> 즉, AUTOSAR라는 것은 각각의 ECU 간의 주고받는 데이터의 일관성과 통신 인터페이스를 미리 정의해 놓아서 각각의 개발자간에 코드를 통합하기에 원활하게 해주도록 하는 것이다. 
  -> 유지보수의 편리성 제공
  -> 예를들어 자율주행 주차 기능을 자동차에 추가하고 싶을때, 네트워크만 연결되어 있다면 자동차를 가지고 카센터에 가지 않더라도 버튼 클릭 하나만으로도 그 기능을 추가할 수 있게 되는것이다.
  -> 필자는 조금더 세상이 발전하면 자동차 내부에서 자동차에 추가 기능을 업그레이드 하고 싶을때 스마트폰에 기본적으로 깔려있는 Play Store 처럼 여러 회사들이 자동차의 기능을 플랫폼(Application처럼)으로 만들어서 등록한 자동차 스토어에 들어가서 간단한 결제 후에 버튼 클릭 한번만 해도 그 기능을 자동차에 자동으로 적용할 수 있는 시대가 올 것이라 생각한다.

< AUTOSAR의 종류 2가지 >

1. Classic AUTOSAR :실시간 통신 및 제어 시스템에 사용, 제한된 리소스를 가진 전통 ECU에 적합한 정적인 아키텍처, 브레이크 시스템 등 과 같은 기본적인 자동차 기능 담당
   -> 즉, 하드웨어적으로 자동차가 만들어지고나서 엔진 제어, 브레이크 시스템 등과 같은 하드웨어 센서들이 필수로 가져야하는 기본적인 기능을 정의하는 플랫폼
   -> 소프트웨어를 빈번하게 업데이트 하는 것이 안된다.
2. Adaptive AUTOSAR : 높은 컴퓨팅 성능과 유연성이 필요한 고급 용도로 사용, 동적인 아키텍처를 제공, 주로 자율주행에 사용하는 플랫폼
   -> 쉽게 말하자면 위에서 필자가 예시로 들었던 자동차 스토어(Play Store같은)에 등록될거 같다는 자율주행 주차 기능 등  이 플랫폼에 속한다.
   -> 차량 출고 후부터 폐차하기 전까지 앱을 통해 실시간으로 SW 업데이트가 가능하다.

-> Adaptive AUTOSAR를 이용한 ECU 간의 통신은 보통 SOME/IP 통신을 이용한다.
-> SOME/IP 통신 : 차량에서 ECU 디바이스 간의 DATA 통신을 지원하기 위해 만들어진 이더넷 기반 프로토콜로, 실시간성이 중요한 서비스 지향적인 프로토콜
        -> 각각의 ECU가 가지는 고유 ip를 가지고 TCP 또는 UDP 통신을 하게 되는 것을 뜻한다.

 

 

< Adaptive AUTOSAR의 3개의 Manager>

 

*EM (Execution Manager) : 전반적인 관점에서 플랫폼의 전체적인 초기화 그리고 플랫폼 상에서 구동될 어플리케이션들의 시작과 종료를 제어하는 매니저 -> Manifest 파일들을 통해 기술되어 진다.
-> Adaptive AUTOSAR 플랫폼 소프트웨어 중 가장 먼저 실행

• 주기능
  •  Adaptive Processor의 생존 주기(실행부터 종료까지) 관리
  •  각 프로세스들의 스케줄링 정책 정의 ( 구동 중 실제 스케줄링은 해당 운영체제 방식에 따름)
  •  상태 관리(Machine State와 Function Group State 등)를 통한 프로세스 제어
       -> 각 Component를 언제 실행하고, 종료할 것인가?
  •  어플리케이션 제어(에러 상황 시 종료 및 재실행 등) 및 자원 모니터링
       -> 할당 자원 제약

 

*SM (State Manager) :  EM에게 전달 받은 것(Component 상태 변경 요청)에 따라서 기능별로 묶은 각 Component의 상태 변경 및 EM에게 각각의 Component의 상태를 알리는 역할을 하는 매니저

<State 기본 종류>

1. Startup : 시스템 또는 컴포넌트가 초기화되고, 준비 상태로 진입하는 단계

• 주요 작업
  • 시스템 리소스 초기화
  • 필요한 데이터를 로드하고, 의존성 확인
  • 컴포넌트가 정상적으로 동작할 준비가 완료되었다는 것을 뜻함
• 상황 예시
  • 차량 전원을 켜고 ECU가 초기화되는 상태
  • Adaptive AUTOSAR 어플리케이션이 실행되기 전 준비 상태

2. Restart : 컴포넌트를 다시 시작하거나 재설정하는 상태

• 주요 작업
  • 현재 동작 중인 상태를 종료하고, 초기 상태로 복귀
  • 오류가 발생한 경우 안전하게 시스템을 다시 시작
  • 특정 조건에 따라 필요한 설정을 재적용
• 상황 예시
  • 소프트웨어 업데이트 후 다시 시작
  • 오류 복구를 위해 ECU 또는 어플리케이션을 재부팅

3. Shutdown : 시스템 또는 컴포넌트가 종료 단계로 진입하는 단계

• 주요 작업
  • 동작 중인 프로세스를 안전하게 종료
  • 데이터 손실 방지를 위해 현재 상태 저장
  • 필요한 자원(메모리, 통신 등) 해제
• 상황 예시
  •  차량 전원을 끄는 과정에서 ECU가 안전하게 종료
  • 어플리케이션 업데이트를 위한 종료 준비

4. Verify : 시스템이나 컴포넌트가 정상적으로 동작할 준비가 되었는지 확인하는 상태

• 주요 작업
  • 각 컴포넌트의 상태를 점검
  • 정상적인 동작을 위한 모든 조건이 충족되었는지 확인
  • 문제가 발견되면 적절한 오류 처리를 수행
• 상황 예시
  • 차량 네트워크 연결 상태 점검
  • ECU 내부 진단 후 이상 유무 확인

<SM이 다루는 State들>

 

*CM (Communication Manager) : 통신 매니저로서, 로컬 또는 원격으로 어플리케이션 간의 통신 경로를 관리하는 모듈

• 주기능
  • 통신 그룹화
  •  통신/네트워크 바인딩(묶음)

 

<Manifest>

1. Execution Manifest : 설계 시 생성 / 실행자 (Executable)와 같이 머신 상에 배치
 -> 시작 파라미터, 자원 그룹 할당, 스케줄링 정책 등을 표준화된 방식으로 기술

2. Service Instance Manifest : 설계시 Execution Manifest와 함께 생성되어 머신 상에 배치
 -> 어플리케이션에서 사용되는 서비스 관련된 정보 기술

3. Machine Manifest : 특정 머신을 위해 통합 시에 생성되며, Exection Manifest와 같이 내부 변경이 있을 시 교체
-> 특정 실행자나 그것의 인스턴스 등에 할당 될 수 없는 모든 정보 포함

4. 포맷 : 매니페스트(Manifest) 파일이 저장되는 데이터 구조나 형식으로, AUTOSAR에서는 표준 ARXML 파일 형식에서 플랫폼에 특성화되어 처리된 매니패스트(Processed Manifest)형식으로 변경하여 사용

 

< 시스템 구동 순서 >

1. 운영체제 시작
2. EM이 CM에게 각 센서 또는 모듈과의 통신 연결 명령 전송
    -> Classic AUTOSAR를 통해 모든 센서들이 실질적으로 제어되기 때문에 사실상 Classic AUTOSAR에게 해당 IP를 통해 "각 센서 동작 시작해" 라고 명령을 내리는 것과 같다고 볼 수 있다.
3. 각 센서들 또는 하나의 AA 박스들(Component)의 상태를 받기 시작하라고 SM에게 명령을 내림
4. SM에서는 실시간으로 각 ARA 상태를 지니고 있으며, 상태 제어가 가능
5. EM은 SM을 통해서 모든 AA 박스(Component)가 시작할 수 있는 상태 즉, Startup 상태에 있다는 것을 전달 받음
6. 이제 EM이 설계된 AA 구성도에 맞추어 모든 시스템을 작동시키기 시작함

PopcornSAR의 AUTOSAR 실행

< AUTOSAR  설계 및 작성 규칙 >

• AP는 어플리케이션에 대한 소스코드 이식성을 지원해야 한다
• 기존IP의 재사용을 보장한다.
• 표준에 지정한 ARA를 사용하여 개발을 하면 어플리케이션에서 지정한 최소 C++버전만 만족하면 소스코드를 변경하거나 조건부 컴파일구성이 필요하지 않다.
• 어플리케이션 구현 시 AP표준을 위반하지 않는 한에서 ARA를 사용하지 않은 어플리케이션을 제공할 수 있다. 하지만 그렇게 구현하더라도 SWS에 지정되어 있지 않은 선언 또는 정의를 ARA네임스페이스 또는 해당 하위 네임스페이스에 추가해서는 안된다.
• 어플리케이션은 최소한 C++ 버전14과 호환되어야 한다. 물론 패키지의 C++버전을 제한하여서 C++버전17등을 사용할 수 있으나 표준은 C++ 버전 14를 호환하게 개발하여야 한다
• 모드범위에서 AP의 네임스페이스는 ara이며 ara네임스페이스 각 기능 cluster는 정확히 하나의 고유한 네임스페이스를 가지며 모든 네임은 소문자만 사용하여야 하며 _ 는 사용 가능하다
• 모든 Function cluster는 각 공개에 대한 자체를 포함한 헤더파일을 제공해야 한다
• 모든 Function cluster에 대해 공개 유형의 이름은 대문자 카멜표기법으로 표준화되어야 한다.
• _는 사용불가능하며 고정 너비 정수 유형을 제외하고 postfix_t는 사용불가하다.
• 대문자로 표시된 두 문자어는 단일단어로 사용되어야 한다
• 모든 Function cluster의 경우 공개 메소드 및 기능 이름은 대문자 카멜케이스를 사용해야 된다
•  _는 사용 불가능하며 대문자로 표시된 두 문자어는 단일 단어로 사용된다 
• 모든 펑션 클러스터의 경우 공개 메소드의 매개변수 이름은 소문자 카멜 표기법을 사용해야 한다
• Function cluster는 복구 가능한 작업과 복구 불가능한 작업을 구별하여야 한다.
• 인터페이스는 적절한 반환을 통해 복구 가능한 오류를 보고하도록 설계되어야 한다
  (ara::core::Result 또는 ara::core::Future같은 유형)
• 모든 문자열 유형의 기본 인코딩은 UTF-8이어야한다 경우에 따라 인코딩이 UTF-8에서 벗어나면 API정의에 문서화해야 한다

교육 받기 전 AUTOSAR 설계

 

2024ESWContest_자율주행 레이싱_10051_짱짱맨_개발계획서 .docx

4.43MB

-> 교육을 제대로 받기 전에 작성한 개발 계획서이다.

 

*****필자와 같은 경우 자율주행 레이싱이라는 공모전에서 예선을 통과하여 AUTOSAR를 배울 수 있는 기회를 얻었고, 실제로 PopcornSAR라는 회사에서 직접 만든 AUTOSAR를 만들 수 있는 Tool을 제공받아 직접 설계하고, 만들어 보았다. 

다음 페이지에서 그 내용과 결과를 설명하려고 한다.*************

 

 

자율주행 레이싱 (DeepRacer + AUTOSAR)