검수요청.png검수요청.png

"오토사"의 두 판 사이의 차이

해시넷
이동: 둘러보기, 검색
25번째 줄: 25번째 줄:
  
 
==참고자료==
 
==참고자료==
 +
* 〈[https://ko.wikipedia.org/wiki/AUTOSAR AUTOSAR]〉, 《위키백과》
 +
* 〈[https://www.vector.com/kr/ko/know-how/autosar/autosar-classic/ AUTOSAR Classic Platform]〉, 《벡터》
 +
* 〈[http://www.dism.co.kr/2018/ETAS/newsletter/09/images/3_KR_TheAdaptivePlatform.pdf 기술 표준화]〉, 《스마트카기술포럼》
 +
* 조재윤 , 〈[https://www.autoelectronics.co.kr/article/articleView.asp?idx=2593 차세대 ECU를 위한 AUTOSAR Adaptive Platform]〉, 《AEM》, 2017-11
 +
* Stuart Mitchell, 〈[http://www.dism.co.kr/2018/ETAS/newsletter/09/images/3_KR_TheAdaptivePlatform.pdf 어댑티브 플랫폼: 새로운 AUTOSAR]〉, 《ETAS》
 +
*
 +
  
 
==같이 보기==
 
==같이 보기==

2021년 10월 7일 (목) 11:36 판

오토사 또는 AUTOSAR(AUTomotive Open System ARchitecture)는 전장 개방형 시스템 아키텍처로 자동차에서 사용되는 개방형 시스템 아키텍처이다. 2003년에 만들어진 자동차 관련 분야의 세계적인 개발 파트너십이다. 자동차 ECU 개방형 표준 소프트웨어 구조를 개발하고 설립하는데 목적을 두고 있다. 구체적인 목표로는 다양한 차량 및 플랫폼 변형, 소프트웨어 이전 가능성, 가용성 및 안전 요구 사항 고려, 다양한 파트너 간의 협력, 천연 자원의 지속 가능한 활용 및 전체 제품 수명주기에 걸친 유지 관리 가능성에 대한 확장성이 포함된다.

역사

자동차에 들어가는 기술이 날이 갈수록 더욱 다양해지고 있어 더 많은 ECU가 탑재되고, 각 ECU에 들어가는 소프트웨어들 또한 더욱 더 복잡해지고 있다. 이 복잡해지는 소프트웨어로 인하여 다양한 문제들이 발생하는데, 이런 문제점들을 극복하고자 유럽의 주요 자동차회사와 부품회사들이 모여서 만든 것이 오토사이다.[1] 오토사 개발 파트너쉽은 2003년 7월에 열린 산업 표준 자동차 E/E architecture 구조를 만들고 발전시키기 위해 BMW, 보쉬, 콘티넨탈, 다임러, 지멘스 VDO 그리고 폭스바겐에 의해 설립되었다. 포드 자동차가 2003년 11월에 핵심 파트너(Core Partner)로 가입했고, 그 해 12월에는 푸조토요타가 추가로 가입했다. 다음 해 11월에는 제네럴모터스가 핵심 파트너에 합류했고, 2008년 2월 지멘스 VDO가 콘티넨탈에 인수된 후 이는 자체 핵심 파트너에서 제외되었다. 2003년부터 AUTOSAR는 클래식 플랫폼(Classic Platform)을 위한 표준 자동차 소프트웨어 구조로써 4개의 릴리즈(Release)를 제공해 왔으며, 1개의 승인 테스트 릴리즈(Acceptance Tests Release)를 공개했다. AUTOSAR 클래식 플랫폼의 작업은 Phase I (2004-2006): 표준을 위한 기본 개발 (Releases 1.0, 2.0 and 2.1), Phase II (2007-2009): 구조와 방법론 측면에서의 표준 확장(Releases 3.0, 3.1 and 4.0) 마지막으로 Phase III (2010-2013): 유지 보수 및 개선(Releases 3.2, 4.1 and 4.2) 이렇게 세 단계로 나눌 수 있다. 2013 년 AUTOSAR 컨소시엄은 클래식 플랫폼이 표준을 유지하고 선택된 개선사항을 제공하기 위해 지속적인 작업 모드를 시작했다. 2016년에는 어댑티브 플랫폼(Adaptive Platform)을 개발하기 시작했다. 그의 첫 번째 릴리스는 2017년 초반에 발표되었고, 그 해 10월에 두번째 릴리즈인 17-10이, 그리고 2018년 3월에 18-03 릴리즈가 발표되었다. 최근의 목표는 2018년 10월 AUTOSAR 클래식, 어댑티브 및 기반(Foundation)표준을 어우르는 릴리즈의 출시를 위해 주요 개발 활동을 마무리하고 그것을 포함시키는 것이다.[2]

소프트웨어 구조

  • 베이직 소프트웨어(Basic Software, BSW) : 상위 소프트웨어 계층의 기능적 부분을 실행하는 데 필요한 서비스를 제공하는 기능적 작업 자체가 없는 표준화 된 소프트웨어 모듈
  • 런타임 환경(Runtime Environment, RTE) : 응용 프로그램 소프트웨어 구성 요소 간 및 기본 소프트웨어와 응용 프로그램 간의 ECU 내부 및 내부 정보 교환을 위해 네트워크 토폴리지에서 추출한 미들웨어
  • 응용 프로그램 계층 : 런타임 환경과 상호 작용하는 응용 프로그램 소프트웨어 구성 요소

방법론

시스템 설계 단계에서 기능 소프트웨어의 아키텍처가 결정된다. 이는 소프트웨어 컴포넌트와 소프트웨어 컴포넌트를 에 분배하는 과정을 정의함으로써 이루어지는데 네트워크 통신도 이 단계에서 결정된다. 이 작업의 결과물이 바로 오토사 XML-시스템 디스크립션 파일로서, 각각의 ECU 특정 추출물은 이 시스템 디스크립션 파일로부터 생성된다. ECU 개발 과정 중, 소프트웨어 컴포넌트는 설계되고 구현되며 베이직 소프트웨어와 런타임환경이 구성된다. 개발자는 이 구성을 통해 프로젝트에 필요한 베이직 소프트웨어의 양을 결정한다. 이와 같은 방식으로 전체 ECU 소프트웨어를 최적화할 수 있다. 이 구성의 결과물이 ECU Extract of System Description에 맞춤 튜닝된 ECU Configuration Description이다. 코드 생성기는 ECU Configuration Description에 기반하여 ECU 소프트웨어용 베이직 소프트웨어를 생성 및 구현한다. 런타임 환경도 이러한 방식으로 ECU 맞춤형 기법으로 생성된다. 오토사에서 정의된 이 기법은 어플리케이션 소프트웨어를 ECU에 통합하는 과정을 확연히 간소화해주며 일일이 소프트웨어를 조정하는 과정은 필요하지 않다.[3]

플랫폼

클래식 플랫폼

오토사 클래식 플랫폼은 주행계용 플랫폼이며 경성 실시간(hard realtime) 및 안전성 제약사항을 가진 OSEK 기반의 임베디드 ECU 표준이다. 오토사의 전반적인 구조를 제시하고, 차량 어플리케이션이 공통적으로 사용하는 기능인 베이직 소프트웨어를 표준화한다. 오토사 클래식 플랫폼의 구조는 응용 프로그램, 런타임 환경(RTE) 및 베이직 소프트웨어(BSW)와 같이 마이크로 컨트롤러에서 실행되는 세 가지 소프트웨어 계층사이를 가장 높은 추상 수준으로 구별한다. 응용 소프트웨어 계층은 대부분 하드웨어로부터 독립적이다. 소프트웨어 구성 요소 간의 통신과 베이직 소프트웨어에 대한 액세스는 응용 프로그램의 전체 인터페이스를 나타내는 런타임 환경을 통해 발생한다. 클래식 플랫폼에 꼭 필요한 개념중의 하나는 가상 기능 버스(virtual functional bus:VFB)이다. 이 가상 기능 버스(VFB)는 특정 ECU에 아직 배치되지 않은 인프라 스트럭처에서 어플리케이션을 분리하는 추상적인 런타임 환경과 한 세트이다. 이는 전용 포트를 통해 통신하므로 응용 프로그램 소프트웨어의 통신 인터페이스는 이러한 포트에 매핑되어야한다. 가상 기능 버스는 개별 ECU 내에서와 ECU들 간의 통신을 처리한다. 응용 관점에서 하위 수준의 기술이나 종속성에 대한 자세한 지식을 필요로 하지 않는다. 이는 하드웨어 독립적 개발 및 응용 프로그램 소프트웨어 사용을 지원한다. 또한 클래식 플랫폼은 프랑카 인터페이스 정의 언어(Franca interface description language:IDL)를 사용하여 제네비(Genivi)와 같은 비 오토사 시스템과도 결합할 수 있다.[2][4]

어댑티브 플랫폼

오토사 어댑티브 플랫폼은 정보분야용 플랫폼이며 자율 주행과 같은 유스케이스를 지원하고 안전 관련 시스템을 빌드하기 위한 고성능 컴퓨팅 ECU를 위한 오토사 솔루션이다. 자동차 업계에는 전기차와 자율주행이라는 새로운 패러다임이 형성되면서 IVI(In-Vehicle-Infotainment), ADAS(Advanced Driver Assistance System), V2X(Vehicle-to-X) 등을 필두로 차량 분야에서 전례 없는 IT 기술융합이 일어나고 있다. 특히 리눅스를 차량에 적용하는 사례가 늘고 있는 것은 리눅스 환경이 다음과 같은 편의성을 제공하기 때문이다. 비디오 코덱, 스트리밍, USB, SD-Card, LTE, Wi-Fi, GPS 등을 위한 다양한 드라이버를 활용해 인포테인먼트, V2X와 같은 애플리케이션을 보다 쉽게 구현할 수 있다. 또한 멀티미디어 라이브러리와 이미지 프로세싱 라이브러리 등을 재사용하고 머신러닝, 목표물 인지, 센서 퓨전 등의 연산을 위한 ADAS용 고성능 HW 사용도 가능하다. 이러한 리눅스 환경은 오토사 클래식 플랫폼이 가진 한계점을 보완하며 많은 장점을 갖추고는 있지만, 일반적인 차량 개발환경에 필요한 진단기능이나 CAN 통신 같은 차량 네트워크를 지원하는 소프트웨어를 갖추지 못한 태생적 한계를 지니고 있다. 이 때문에 리눅스 OS가 실행되는 프로세서와 함께 차량 기능을 실행하기 위한 오토사 OS가 실행되는 별도의 프로세서가 공존하여 하나의 제어기가 구성되거나, 멀티코어 프로세서가 탑재된 제어기의 경우 리눅스 OS와 일반 차량 기능을 관장하는 오토사 OS가 실행되는 코어가 각각 분리돼 사용됐다. 이것이 오토사 어댑티브 플랫폼이 등장하게 된 배경이다.[5] 한 가지 중요한 예로는 운전자가 일시적으로 또는 부분적으로 차량 주행에 대한 책임을 전하는 맥락에서의 고도로 자동화 된 운전이다. 이는 교통 표지나 신호등과 같은 교통 인프라스트럭쳐, 최신 교통 정보나 지도에 엑세스 하기 위한클라우드 서버, 또는 마이크로프로세서의 사용 및 병렬 처리를 위한 고성능 컴퓨터 하드웨어의 사용을 필요로 한다. 또한 Car-2-X 애플리케이션은 차량 및 외부 시스템과의 상호 작용을 필요로 한다. 이는 시스템이 안전한 온보드(on-board) 통신, 교차 영역 컴퓨팅 플랫폼 (cross-domain computing platform) 지원, 스마트 폰 통합, 비 오토사 시스템 통합 등을 제공해야 함을 의미한다. 더불어 클라우드 기반 서비스에는 보안 클라우드 상호 작용 및 비상 차량 선점과 같은 보안을 위한 전용 수단이 필요하다. 이 서비스는 원격 진단, 무선 업데이트 (OTA), 수리 및 교환 처리와 같은 원격 및 분산 서비스를 가능하게한다. 다양한 고객 애플리케이션 전개를 지원하고 하이앤드(high-end) 컴퓨팅 파워를 필요로하는 애플리케이션을 위한 환경을 제공하기 위해서 오토사는 근래에 어댑티브 플랫폼(Adaptive Platform)을 표준화 시키고 있다. 그의 핵심은 포직스(POSIX) 표준에 기반한 운영 체제이다. IEEE1003.13 (PSE51)에 따르면 이 운영체제는 포직스의 서브셋을 거쳐 어플리케이션을 통해 사용될 수 있다. 어댑티브 플랫폼은 서비스와 애플리케이션 프로그래밍 인터페이스 APIs와 같은 2가지 타입의 인터페이스가 가능하다. 이 플랫폼은 기능 클러스터를 포함하는데, 이는 서비스와 어댑티브 플랫폼을 기반으로 그룹화된다. 오토사 어댑티브 플랫폼에는 사양서와 코드가 모두 포함되어 있다. 클래식 플랫폼과 비교하여 오토사는 어댑티브 플랫폼을 통해 유효성 검사주기를 단축하고 기본 개념을 설명하기 위한 구현을 개발하고 있다.[2]

클래식 플랫폼과 어댑티브 플랫폼 차이점

일부는 클래식 플랫폼과 어댑티브 플랫폼이 공통적인 반면 일부는 단일 플랫폼에만 존재한다. 핵심 오토사 요구사항은 클래식 플랫폼에만 적용되는 반면, 고성능 컴퓨팅을 지원해야 하는 요구사항은 어댑티브 플랫폼에만 적용된다. 각각의 장점이 다르기 때문에 클래식 플랫폼의 성능이 더 안좋다거나 어댑티프 플랫폼이 심층적인 임베디드 시스템일 수 없다는 뜻은 아니다. 어댑티브 및 클래식 플랫폼의 강점을 활용하기 위해 단일 시스템은 두 가지 유형의 ECU로 구성될 수 있고 오토사는 표준화된 소프트웨어 인터페이스를 제공한다. 클래식 플랫폼과 어댑티브 플랫폼은 서로 다른 플랫폼을 구현해 모두 실행 가능한 소프트웨어를 제공하지만, 내부적인 구현 방식에 있어서 클래식 플랫폼의 신호 기반 통신과 어댑티브 플랫폼의 서비스 지향 통신에서 볼 수 있듯이 완전히 다른 통신구현 방식을 사용한다. 클래식 플랫폼은 리소스가 적은 ECU용이기 때문에 어댑티브 플랫폼보다 훨씬 간단한 하드웨어 요구사항을 가진다. 단일 주소 공간에는 가상주소 지정이 필요하지 않지만, 어댑티브 플랫폼에서는 애플리케이션 간의 보다 정교한 메모리 분리를 위해 MMU지원이 필요하다. 클래식 플랫폼은 정적으로 구성되어 완성되며, 모든 작업, 신호 등은 초기 설정 시에 정의되어야 한다. 이와 반면에, 어댑티브 플랫폼은 동적 통신 및 동시성을 지원하므로 애플리케이션이 자신의 환경이나 규모에 반응하여 배치된 ECU에 적응할 수 있는 유연성이 향상된다. 클래식 플랫폼에서는 애플리케이션이 플래시에서 직접 실행되지만 어댑티브 플랫폼에서는 애플리케이션이 파일 시스템에서 램으로 로드되어야한다. 이는 어댑티브 플랫폼이 전체 ECU를 다시 플래싱하지 않고도 소프트웨어의 점진적인 변경을 지원할 수 있다는 것을 의미한다.[6]

각주

  1. 끔손, 〈(AUTOSAR 001) AUTOSAR(오토사)의 개념 및 배경〉, 《티스토리》, 2020-02-21
  2. 2.0 2.1 2.2 AUTOSAR〉, 《위키백과》
  3. AUTOSAR Classic Platform〉, 《벡터》
  4. 기술 표준화〉, 《스마트카기술포럼》
  5. 조재윤 , 〈차세대 ECU를 위한 AUTOSAR Adaptive Platform〉, 《AEM》, 2017-11
  6. Stuart Mitchell, 〈어댑티브 플랫폼: 새로운 AUTOSAR〉, 《ETAS》

참고자료


같이 보기


  검수요청.png검수요청.png 이 오토사 문서는 전기자동차에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.