위키원
오토사
오토사 또는 AUTOSAR(AUTomotive Open System ARchitecture)는 차량 전장 부품용 임베디드 사용 급증에 대응하기 위해 표준화한 자동차 플랫폼이다. 정식 명칭은 개방형 자동차 표준 소프트웨어 구조로, 흔히 오토사로 약칭한다. 차량용 전자장치가 증가하고 이에 따라 소프트웨어의 수량과 복잡성도 늘어나 표준화의 필요성이 증가하면서 제조사와 개발사들에 의해 제시되었다.
목차
개요
오토사는 차량 전장부품용 임베디드 소프트웨어 사용 급증에 대응하기 위해 만들어진 표준화된 플랫폼이다. 오토사는 자동차 전장용 임베디드 소프트웨어 개발의 생산성 향상에 그 근본을 두고 있다. 표준화된 소프트웨어 구조를 정의하고, 모듈화된 소프트웨어 구성을 지원하므로 복잡도를 감소시켜 생산성을 향상시키며, 오토사를 통해 모듈 간 인터페이스만 정해지면 각 모듈별로 서로 다른 업체에서 개발이 가능하므로 분업이 가능하여 개발일정을 단축시킬 수 있다. 자주 사용되는 기능을 모듈화하여 모든 ECU(전자제어장치)에서 재사용하는 것도 가능하다.[1] 오토사는 기본 소프트웨어 모듈을 설명하고 애플리케이션 인터페이스를 정의하며 표준화 된 교환 형식을 기반으로 일반적인 개발 방법론을 구축하는 일련의 사양서(specifications)를 제공한다. 계층화된 소프트웨어 아키텍처가 제공하는 기본 소프트웨어 모듈은 각기 다른 제조업체(OEMs)의 자동차 및 여러 공급업체의 전자 부품에 사용 될 수 있는데, 이를 통해 연구 개발 비용을 줄이고 점차 확대되고 있는 자동차 및 전자 소프트웨어 구조의 복잡성에 대비 하자는 것이다. 오토사는 이러한 기본 지침에 바탕을 두고 성능, 안전성 및 환경 친화성을 개선하고 차량의 서비스 수명 동안 소프트웨어 및 하드웨어의 교환 및 업데이트를 용이하게하는 혁신적인 전자 시스템의 길을 열어 줄 수 있도록 고안되었다.[2] 오토사와 협력하고 있는 주요 업체들은 다음과 같다.
오토사 협력 업체[3] 우선 회원사 완성차 제조사 ECU 제조사 개발툴 제조사 반도체 제조사 - 프리스케일(freescale)
- 인피니언(Infineon)
- 르네사스 일렉트로닉스
(Renesas Electronics)
등장배경
2011년 1월 미국 라스베가스에서 개최된 국제전자제품박람회(CES)에 자동차 회사들이 대거 출품하였다. 이는 이젠 자동차나 가전이나 따로 영역이 없어진다는 것에도 의미가 있지만 그만큼 자동차의 전장 사업이 급격하게 성장했다는 의미이기도 하다. 미래에는 자동차에 '시동을 건다'는 표현 대신 '부팅한다'는 말을 사용하게 될지도 모를 정도이다. 자동차 안에는 ECU라는 전자제어장치 즉, 작은 컴퓨터 장치들이 많이 들어 있다. 이런 각 부품들은 서로 네트워크처럼 얽혀 통신한다. 오토사는 기본적으로 자동차 ECU를 위한 임베디드 플랫폼이다. 16 비트 혹은 32 비트 차세대 ECU용 프로세서를 주요 대상으로 하며 독립적인 기능을 하는 ECU보다는 상호 통신을 통하여 작업을 하는 ECU 모듈들을 가정하고, 자동차 제어 네트워크라 불리는 자동차 내 통신선에 초점을 맞춘다. 차량 내 제어 네트워크는 활용 분야에 따라 서로 다른 매체를 사용하는데 첫 번째로 에어백이나 브레이크 같이 통신의 신속성과 안전성이 보장되어야 하는 매체로 CAN을 주로 사용한다. 두 번째로 문열림이나 유리창 버튼처럼 신속성도 중요하지 않고 대역폭도 좁은 것은 저가의 LIN을 사용한다. CAN이나 LIN의 영역 모두 포함할 수 있는 플렉스레이(FlexRay)라는 기술이 나와 차량 내 통신선 길이 단축, 통신선 간의 간섭 문제 모두를 해결하여 각광받기도 하였다. 마지막으로 제어신호가 아닌 멀티미디어 데이터와 같은 다량의 정보를 전달하기 위한 매체로서 MOST가 활용되고 있다. 옛날의 라디오, CD 플레이어 정도였던 오디오, 비디오 장치도 멀티미디어뿐만 아니라 통신과 내비게이션 등 각종 콘텐츠를 제공하는 텔레매틱스 또는 인포테인먼트 시스템으로 진화하고 있다. 통신이 되려면 각종 휴대폰 장치들을 사용할 수 있어야 하는데 이때 사용되는 운영체제(OS)만 해도 유명한 구글(Goolge)의 안드로이드(Android), 애플(Apple)의 iOS를 비롯하여 다양하다. ECU라는 보드 안에는 칩도 있고 각종 소프트웨어가 내장되어 있다. 운영체제, 각종 성능을 담당하는 응용프로그램인 애플리케이션 등이다. 이런 ECU도 하드웨어 안에 내장되어 있다 보니 각 부품사에 따라 각각 다른 운영체제를 사용하게 되고 응용프로그램도 각 운영체제에 맞추어 개발된다. ECU 숫자가 늘어나고 소프트웨어의 LOC가 증가하면 복잡도가 증가하며, 복잡도가 증가할수록 품질이 저하될 가능성이 높다는 것이 문제점으로 대두되었다. 1990년대 자동차의 소프트웨어 LOC는 100라인, 2000년도에는 100만 라인, 2012년도에는 1억 라인을 돌파했다. 미국항공우주국(NASA)의 경우 2011년 기준 소스코드 1라인당 $850의 비용을 들여 개발한 소프트웨어 1,000 라인당 오류는 0.004개로 알려져 있다. 그러면 1억 라인의 소프트웨어가 들어가는 자동차의 경우 확률적으로 400개의 오류가 있다고 추정할 수 있다. 850억 불, 90조원을 들여 개발해도 오류가 400개 있다면 자동차의 경우 대처에 큰 어려움이 있다. 미국에서 일어난 토요타(Toyota) 리콜 사건을 보면 리콜에 자동차 회사가 휘청거린다는 것을 알 수 있다.
이런 큰 변화는 1) 전자장치의 증가 2) 소프트웨어 복잡도의 증가 3) 표준화의 필요성 증가로 요약할 수 있다. 표준화의 필요성이 증가하는 이유는 단순히 소프트웨어의 수량이 늘었다는 이유도 있지만 자동차 하드웨어는 원가절감을 위해 한 가지 부품으로 여러 차종에 공통으로 사용화하는 경향이 추세화되었다는 원인이 가장 크다. 부품도 단위 부품들을 모아 모듈화하여 단순화시켰다. 마찬가지로 소프트웨어도 차종마다 모두 다르게 만들고 같은 차 안에서도 각 부품사들이 납품하는 ECU 안에 각각 다른 운영체제를 사용하다보니 효율성과 호환성이 떨어지고 안전성에도 문제가 생기게 되었다. 그래서 우선 운영체제부터 자동차용으로 하나로 통일시킨 것이 바로 오섹(OSEK)이다. 오섹 자체는 운영체제가 아니다. 포직스(Posix)와 같이 오토사를 지원하는 운영체제가 지원해야 할 표준 API 규격의 정의이다. 따라서 오섹을 지원하는 다양한 운영체제가 존재할 수 있으며 이들 대부분은 실시간성을 동시에 지원한다. 한편 사업적 관점에서 본다면 자동차 OEM들은 각 부품별로 납품을 받아 조립을 하는 구조인데 소프트웨어가 포함된 전장 부품들은 여러 회사로부터 납품을 받다 보니 여러 가지 심각한 문제가 제기되었다. 자동차 시장의 경쟁이 치열해져서 신규모델 출시 주기가 점점 짧아졌으며, 전장부품들은 서로 통신을 해야 하고 연결되어야 하는 바 부품사 사이에서 협력의 필요성이 증대하여 개발생산성 향상과 함께 공통 플랫폼의 필요성이 대두되었다. 즉, ECU에서 통신 프로토콜과 같이 다양한 기능 수행으로 복잡도가 증가하고, 자동차 모델 주기가 감소하며, 기존 업계 분업 구조 파괴 등의 필요에 의거해 오토사라는 업게 표준 규격을 제정하게 되었다.[4]
역사
오토사 개발 파트너쉽은 2003년 7월에 열린 산업 표준 자동차 E/E 구조를 만들고 발전시키기 위해 비엠더블유(BMW), 보쉬(Bosch), 콘티넨탈(Continental), 다임러(Daimler), 지멘스(Siemens), 그리고 폭스바겐(Volkswagen)에 의해 설립되었다. 포드(Ford)가 2003년 11월에 핵심 파트너로 가입했고, 그 해 12월에는 푸조(Peugeot)와 토요타(Toyota)가 추가로 가입했다. 다음 해 11월에는 제너럴모터스(GM)가 핵심 파트너에 합류했고, 2008년 2월 지멘스가 콘티넨탈에 인수된 후 이는 자체 핵심 파트너에서 제외되었다. 2003년부터 오토사는 클래식 플랫폼(Classic Platform)을 위한 표준 자동차 소프트웨어 구조로써 4개의 릴리즈(Release)를 제공해 왔으며, 1개의 승인 테스트 릴리즈(Acceptance Tests Release)를 공개했다. 2013년 오토사 컨소시엄은 클래식 플랫폼이 표준을 유지하고 선택된 개선 사항을 제공하기 위해 지속적인 작업 모드를 시작했다. 비엠더블유와 메르세데스-벤츠(Mercedes-Benz), 제너럴모터스 등 대부분 자동차 회사들이 오는 2015년까지 차량에 탑재되는 모든 소프트웨어를 오토사 기반으로 구축하기로 한 데 이어, 현대자동차그룹도 2015년까지 구축 완료하기 위해 관련 운영체제와 개발도구를 개발했다. 2016년에는 어댑티브 플랫폼(Adaptive Platform)을 개발하기 시작했다. 첫 번째 릴리스는 2017년 초반에 발표되었고, 그 해 10월에 두번째 릴리즈인 17-10이, 그리고 2018년 3월에 18-03 릴리즈가 발표되었다. 최근의 목표는 2018년 10월 오토사 클래식, 어댑티브 및 기반(Foundation) 표준을 어우르는 릴리즈의 출시하는 것이다.[2]
구조
오토사는 2016년 표준 배포를 크게 1) 클래식 플랫폼 2) 승인테스트 3) 어댑티브 플랫폼 4) 기반표준의 네 가지로 분류하여 제공하고 있다. 먼저 기반표준은 오토사 플랫폼들 사이의 상호운용성을 강화하기 위함이며, 오토사 플랫폼들 사이에서 공유되는 공통 요구사항과 기술이 명세되어 있다. 두 번째로 클래식 플랫폼은 파워트레인, 섀시 등 주행계용 플랫폼이며 경성 실시간 및 안전성 제약사항을 가진 임베디드 시스템을 위한 오토사 솔루션이다. 세 번째로 어댑티브 플랫폼은 HMI(Human Machine Interface), 첨단 운전자 지원 시스템(ADAS) 등 정보 분야용 플랫폼으로, 자율주행과 같은 유스케이스를 지원하고 안전 관련 시스템을 빌드하기 위한 고성능 컴퓨팅의 ECUs를 위한 오토사 솔루션이다. 마지막으로 승인테스트는 클래식 플랫폼을 위한 표준 인수 시험으로, 클래식 플랫폼의 다양한 기능의 구현과 인수 시험을 지원하는 테스트 케이스를 종합하여 제공한다. 이들 클래식 플랫폼, 어댑티드 플랫폼 혹은 승인테스트는 기반표준의 전용 버전에 의존적이다. 각 의존성은 각각 표준의 배포 개요에 문서화되어 있다.[5]
클래식 플랫폼
오토사 클래식 플랫폼은 오섹 기반의 임베디드 실시간 ECU 표준이다. 주요 결과물로는 사양서(Specifications)가 있다. 오토사 클래식 플랫폼의 구조는 응용프로그램, 런타임 환경(RTE) 및 기본 소프트웨어(BSW)와 같이 마이크로 컨트롤러에서 실행되는 세 가지 소프트웨어 계층사이를 가장 높은 추상 수준으로 구별한다. 응용소프트웨어 계층은 대부분 하드웨어로부터 독립적이다. 소프트웨어 구성 요소 간의 통신과 기본 소프트웨어에 대한 액세스는 응용 프로그램의 전체 인터페이스를 나타내는 런타임 환경을 통해 발생한다. 기본 소프트웨어는 1) 서비스 2) ECU 추상화 3) 마이크로 컨트롤러 추상화의 세 가지 주요 계층과 복잡한 드라이버로 나뉜다. 서비스는 시스템, 메모리 및 통신 서비스를 위한 인프라를 대표하는 기능 그룹으로 더 나뉜다. 클래식 플랫폼의 꼭 필요한 개념중의 하나는 가상 기능 버스(virtual functional bus; VFB)이다. 이 가상 기능 버스는 특정 ECU에 아직 배치되지 않은 인프라 스트럭처에서 애플리케이션을 분리하는 추상적인 런타임 환경의 한 세트이다. 이는 전용 포트를 통해 통신하므로 응용프로그램 소프트웨어의 통신 인터페이스는 이러한 포트에 매핑되어야한다. 가상 기능 버스는 개별 ECU 내에서와 ECU들간의 통신을 처리한다. 응용 관점에서 하위 수준의 기술이나 종속성에 대한 자세한 지식을 필요로 하지 않는다. 이는 하드웨어 독립적 개발 및 응용 프로그램 소프트웨어 사용을 지원한다. 또한 클래식 플랫폼은 프랑카 인터페이스 정의 언어(IDL)를 사용하여 제니비(GENIVI)와 같은 비 오토사 시스템과도 결합할 수 있다.[2]
승인테스트
2014년 오토사는 테스트에 드는 노력과 비용을 최소화하기 위해 승인 테스트(Acceptance Tests)를 도입했다. 이 승인 테스트의 사양(Specifications)은 각 플랫폼의 지정된 인터페이스를 사용하는 시스템 테스트 사양이다. 또한 이 테스트는 버스(Bus)의 특정 행동을 고려한다. 이것들은 특정 플랫폼 기능에 대한 블랙박스 테스트 케이스로 볼 수 있다. 표준 승인 테스트의 사양서는 이러한 목표에 기여한다.[2]
어댑티브 플랫폼
자동차 업계에는 전기자동차와 자율주행이라는 새로운 패러다임이 형성되면서 차량용 인포테인먼트 시스템(In-vehicle Infotainment System), 첨단 운전자 지원 시스템(ADAS), 차량-사물 통신(V2X) 등을 필두로 차량 분야에서 전례 없는 IT 기술융합이 활발하게 일어나고 있다. 특히 리눅스를 차량에 적용하는 사례가 늘고 있는 것은 리눅스 환경이 여러 편의성을 제공하기 때문이다. 우선 비디오 코덱, 스트리밍, USB, SD카드, LTE, 와이파이(Wi-Fi), GPS 등을 위한 다양한 드라이버를 활용해 인포테인먼트, 차량-사물 통신과 같은 애플리케이션을 보다 쉽게 구현할 수 있다. 또한 멀티미디어 라이브러리와 이미지 프로세싱 라이브러리 등을 재사용하고 머신러닝, 목표물 인지, 센서 퓨전 등의 연산을 위한 첨단 운전자 지원 시스템용 고성능 하드웨어 사용도 가능하다. 이러한 리눅스 환경은 오토사 클래식 플랫폼이 가진 한계점을 보완하며 많은 장점을 갖추고는 있지만, 일반적인 차량 개발환경에 필요한 진단기능이나 CAN 통신 같은 차량 네트워크를 지원하는 소프트웨어를 갖추지 못한 태생적 한계를 지니고 있다. 이 때문에 리눅스 OS가 실행되는 프로세서와 함께 차량 기능을 실행하기 위한 오토사 OS가 실행되는 별도의 프로세서가 공존하여 하나의 제어기가 구성되거나, 멀티코어 프로세서가 탑재된 제어기의 경우 리눅스 OS와 일반 차량 기능을 관장하는 오토사 OS가 실행되는 코어가 각각 분리돼 사용됐다. 이것이 오토사 어댑티브 플랫폼이 등장하게 된 배경이다. 즉 미래 자동차 기능을 위해 필요한 고성능 하드웨어 지원, 다양한 오디오 및 비디오 드라이버 지원, 외부 인터페이스 지원과 함께 차량 진단과 차량 통신 네트워크 및 보안의 요구까지 동시에 만족시켜야 하는 시대의 요구에 따라 오토사 어댑티브 플랫폼이 등장했다.[6] 새로운 유스케이스는 어댑티브 플랫폼의 개발을 필요로 했다. 한 가지 중요한 예로는 운전자가 일시적으로 및 부분적으로 차량 주행에 대한 책임을 전하는 맥락에서의 고도로 자동화 된 운전이다. 이는 교통 표지나 신호등과 같은 교통 인프라스트럭처, 최신 교통 정보나 지도에 엑세스 하기 위한 클라우드 서버, 또는 마이크로프로세서의 사용 및 병렬 처리를 위한 고성능 컴퓨터 하드웨어의 사용을 필요로 한다. 또한 카투엑스(Car2X) 애플리케이션은 차량 및 외부 시스템과의 상호 작용을 필요로 한다. 이는 시스템이 안전한 온보드(on-board) 통신, 교차 영역 컴퓨팅 플랫폼(cross-domain computing platform) 지원, 스마트폰 통합, 비 오토사 시스템 통합 등을 제공해야 함을 의미한다. 더불어 클라우드 기반 서비스에는 보안 클라우드 상호 작용 및 비상 차량 선점과 같은 보안을 위한 전용 수단이 필요하다. 이 서비스는 원격 진단, 무선 업데이트(OTA), 수리 및 교환 처리와 같은 원격 및 분산 서비스를 가능하게 한다. 다양한 고객 애플리케이션 전개를 지원하고 하이앤드(high-end) 컴퓨팅파워를 필요로하는 애플리케이션을 위한 환경을 제공하기 위해서 오토사는 어댑티브 플랫폼을 표준화 시키고 있다. 그의 핵심은 포직스 표준에 기반한 운영체제이다. IEEE1003.13 (namely PSE51)에 따르면 이 운영체제는 POSIX의 서브셋을 거쳐 애플리케이션을 통해 사용될 수 있다. 어댑티브 플랫폼은 서비스와 애플리케이션 프로그래밍 인터페이스(APIs)와 같은 2가지 타입의 인터페이스가 가능하다. 이 플랫폼은 기능 클러스터를 포함하는데, 이는 서비스와 어댑티브 플랫폼을 기반으로 그룹화된다. 이 기능 클러스트는 다음과 같다.
- 어댑티브 플랫폼의 어셈블리 기능
- 필요 사양서의 정의
- 애플리케이션과 네트워크 관점으로부터의 소프트웨어 플랫폼 행동 묘사
- 그러나 어댑티브 플랫폼을 구현하는 아키텍처의 최종 SW 설계를 제한하지 않음
오토사 어댑티브 플랫폼 기반의 기능 클러스터는 서비스가 차량내의 네트워크에 분산되는 동안 가상머신당 최소한 하나 이상의 인스턴스를 가져야한다. 어댑티브 플랫폼의 서비스는 1) 업데이트 및 구성 관리 2) 상태 관리 3) 네트워크 관리 4) 진단 등을 포함한다. 오토사 어댑티브 플랫폼에는 사양서와 코드가 모두 포함되어 있다. 클래식 플랫폼과 비교하여 오토사는 어댑티브 플랫폼을 통해 유효성 검사주기를 단축하고 기본 개념을 설명하기 위한 구현을 개발하고 있다. 이런 오토사의 기술 구현은 모든 파트너가 사용할 수 있다.[2]
기반표준
기반을 만드는 표준 목적은 오토사 플랫폼 간의 상호 운용성을 강화하는 것이다. 이런 기반에는 공통 방법론과 함께 오토사 플랫폼간에 공유되는 공통 요구 사항과 기술 사양서(프로토콜의 예시)가 포함되어 있다.[2]
플랫폼 간 차이
일부는 클래식 플랫폼과 어댑티브 플랫폼이 공통이지만 일부는 단일 플랫폼에만 존재한다. 오토사의 핵심 요구사항은 클래식 플랫폼에만 적용되는 반면, 고성능 컴퓨팅을 지원해야 하는 요구사항은 어댑티브 플랫폼에만 적용된다. 각각의 장점이 다르기 때문에 클래식 플랫폼의 성능이 좋지 않다거나 어댑티프 플랫폼이 심층적인 임베디드일 수 없다는 뜻은 아니다. 어댑티브 및 클래식 플랫폼의 강점을 활용하기 위해 단일 시스템은 두 가지 유형의 ECU로 구성될 수 있고 오토사는 표준화된 소프트웨어 인터페이스를 제공한다. 클래식 플랫폼과 어댑티브 플랫폼은 서로 다른 플랫폼을 구현해 모두 실행 가능한 소프트웨어를 제공하지만, 내부적인 구현 방식에 있어서 클래식 플랫폼의 신호 기반 통신과 어댑티브 플랫폼의 서비스 지향 통신에서 볼 수 있듯이 완전히 다른 통신 구현 방식을 사용한다. 클래식 플랫폼은 리소스가 적은 ECU용이기 때문에 어댑티브 플랫폼보다 훨씬 간단한 하드웨어 요구사항을 가진다. 단일 주소 공간에는 가상주소 지정이 필요하지 않지만, 어댑티브 플랫폼에서는 애플리케이션 간의 더욱 정교한 메모리 분리를 위해 메모리관리장치(MMU)의 지원이 필요하다. 클래식 플랫폼은 정적으로 구성되어 완성되며, 모든 작업, 신호 등은 초기 설정 시에 정의되어야 한다. 이와 반면에, 어댑티브 플랫폼은 동적 통신 및 동시성을 지원하므로 애플리케이션이 자신의 환경이나 규모에 반응하여 배치된 ECU에 적응할 수 있는 유연성이 향상된다. 클래식 플랫폼에서는 애플리케이션이 플래시에서 직접 실행되지만 어댑티브 플랫폼에서는 애플리케이션이 파일 시스템에서 램으로 로드되어야 한다. 이는 어댑티브 플랫폼이 전체 ECU를 다시 플래싱하지 않고도 소프트웨어의 점진적인 변경을 지원할 수 있다는 것을 의미한다.[7]
오토사 클래식 플랫폼과 어댑티브 플랫폼의 차이점 오토사 클래식 플랫폼 오토사 어댑티브 플랫폼 실시간 응용 수행이 가능한 OSEK 운영체제 기반 오픈 API 플랫폼에 기반한 POSIX 운영체제 기반 ROM으로부터 응용서비스를 실행 영구메모리로부터 응용을 실행 실시간성/안전성 확보를 위한 MPU기반으로 고정메모리 통한 응용수행 MMU 기반 가상 메모리를 통한 응용 수행 실시간성을 보장하기 위한 신호기반의 통신 동기화를 사용(CAN, FlexRay) 비실시간성 서비스 지향 통신을 사용 개발자가 정의한 정적 기반의 태스크 스케즐링 운영체제에 의한 동적 기반의 태스크 스케즐링
적응성 및 유연성
오토사 클래식 플랫폼은 다양한 차종과 플랫폼 베리언트(Variant) 대응에 적합하다. 이러한 확장성은 제어기를 구성하는 기능별 소프트웨어 모듈이 모두 표준화된 소프트웨어 스택을 통해 구성되기 때문이다. 반면 오토사 어댑티브 플랫폼은 확장성보다는 적응성과 유연성에 방점을 찍고 있다. 어댑티브가 시사하는 바가 바로 이 적응성과 유연성이다. 이를 위해 어댑티브 플랫폼은 8개의 기능 클러스터와 3개의 기본 서비스를 제공한다. 3개의 기본 서비스는 미들웨어성격의 어댑티브 애플리케이션을 위한 오토사 런타임(ara::com : Autosar Runtime for Adaptive Applications)을 통해 호출할 수 있고, 8개의 기능 클러스터는 각 API를 통해 다른 애플리케이션과 통신한다. 흥미로운 점은 오직 API 구현에 대한 정의만 돼 있다는 사실인데, 이 때문에 기존 클래식 플랫폼을 구성하는 BSW 스택 구현에 비해 어댑티브 플랫폼의 기능 클러스터 구현 자유도가 훨씬 높다.[6]
SOME/IP 기반 서비스 지향 통신
오토사 어댑티브 플랫폼과 클래식 플랫폼의 가장 큰 차이점은 통신 방식에 있다. 대부분의 기존 클래식 플랫폼은 전통적인 시그널 지향(signal-oriented) 통신에 기초하지만, 어댑티브 플랫폼은 서비스 지향 커뮤니케이션(SOC; Service-Oriented Communication)에 그 기반을 두고 있다. 이는 서비스를 제공하는 서버인 스켈레톤(Skeleton)과 서비스를 소비하는 클라이언트인 프록시 사이에 필요한 서비스가 서비스 디스커버리(service discovery)와 SOME/IP(Scalable service-Oriented MiddlewarE over IP)를 통해 다이나믹하게 연결하는 통신 방법이다. SOME/IP는 어댑티브 플랫폼에서 중요한 의미가 있다. 이는 어댑티브 플랫폼의 궁극적인 지향점인 차량 애플리케이션 서버 구축과 운용에 백본이 되기 때문이다. 미래 차량은 스마트 센서와 스마트 액추에이터를 탑재하게 되고, 이는 모두 이더넷으로 연결되어 궁극적으로 차량 애플리케이션 서버에 의해 모니터링되고 제어될 수 있다. 차량 애플리케이션 서버는 어댑티브 플랫폼이 탑재된 시스템으로서 SOME/IP를 통해 스마트 센서와 스마트 액추에이터를 차량 애플리케이션의 용도에 따라 자유롭게 모니터링하고 제어할 수 있다. 이는 지난 기간 지속된 차량 전장 아키텍처와는 사뭇 다른 형태이다. 지금까지는 하나의 제어기에 연결된 센서와 액추에이터는 오직 그 제어기의 기능 수행에만 할당돼 사용됐다. 그러나 어댑티브 플랫폼에서는 센서와 액추에이터가 여러 차량 애플리케이션 소프트웨어에 사용될 수 있다. 마치 스마트폰의 하드웨어 자원이 특정 애플리케이션에만 사용되는 것이 아니라, 범용으로 모든 애플리케이션 소프트웨어에 사용되는 것과 같다고 할 수 있다. 예를 들면, 후진 시 후방을 보여주는 후방카메라를 통해 영상정보를 입력받아 모션/제스처를 인식하고, 트렁크를 제어하는 액추에이터를 제어하여 트렁크를 열어주는 차량 애플리케이션 소프트웨어 개발이 가능해진다.[6]
포직스 기반 운영체제 선택
오토사 클래식 플랫폼은 기본적으로 확장성에 따라 SC1~SC4까지 운영체제를 제공한다. 하지만 어댑티브 플랫폼은 기본으로 제공하는 운영체제가 없기 때문에 사용자가 운영체제를 선택해야 하는데, 포직스(POSIX) 기반 운영체제를 어댑티브 플랫폼에 사용할 수 있다. 이로써 클래식 플랫폼에 사용됐던 하드웨어에 비해 연산처리 능력이 월등히 뛰어난 하드웨어 지원이 가능하고, 메모리 관리 유닛 및 멀티코어 프로세스 지원이 가능하다. 포직스 운영체제 아래서 애플리케이션 소프트웨어의 실행은 곧 하나의 포직스 프로세스 생성으로 간주된다. 이때, 애플리케이션은 또 다른 프로세스를 생성할 수 없는 PSE51(POSIX System Environment Profile)을 사용한다. PSE51은 단일 프로세스를 위한 멀티스레드(Multi-thread) 서브셋(subset)으로, 287개의 API로 구성돼 있다. 여기서 한 가지 주의할 점은 애플리케이션 소프트웨어만 PSE51을 사용한다는 것이지, 운영체제가 PSE51을 사용한다는 것은 아니라는 사실이다. 다시 말해, 운영체제는 멀티-프로세스를 지원하지만 애플리케이션은 싱글-프로세스만을 지원한다.[6]
유동적 SW 전개 및 차량 앱 서버
오토사 어댑티브 플랫폼에서만 볼 수 있는 가장 획기적인 변화는 유동적 소프트웨어 전개에 있다고 해도 과언이 아닐 것이다. 차량 애플리케이션 서버를 통해 새로운 기능의 애플리케이션 소프트웨어를 설치할 수 있다. 오토사 어댑티브 플랫폼에서는 애플리케이션 서버를 이용해 기존에 설치가 됐던 소프트웨어의 업그레이드는 물론, 새로운 소프트웨어의 설치도 가능하다. 물론, 정비 센터가 아닌 운전자가 차량을 운용하면서 말이다. 이는 기존 차량 소프트웨어 배포 및 유지보수 형태와는 매우 다른 시도임이 틀림없다. 그동안은 차량에 탑재된 소프트웨어를 EOL(End of Line)에서 제어기에 프로그램된 이후, 사용자(운전자)가 임의로 변경 및 수정하는 것이 원칙적으로 용인되지 않았다. 음성적으로 제어기 매핑을 새로 하는 등의 행태가 간혹 있으나, 제조사가 원천적으로 운전자에 의한 순정 소프트웨어 변경을 허락하지 않기 때문이다. 그러나 어댑티브 플랫폼이 지향하는 바는 매우 다르다. 운전자 편의를 위한 새로운 애플리케이션 소프트웨어의 설치는 물론, 이론적으로는 차량 애플리케이션 서버에서 제어기의 소프트웨어까지도 업그레이드할 수 있게 된다. 이렇게 되면 스마트폰 앱스토어와 유사한 새로운 비즈니스 모델이 생겨날 수 있다. 예를 들면, 장거리 여행을 위해 적응형순항제어(Adaptive Cruise Control, ACC) 애플리케이션을 다운받아 일정 기간 사용하거나, 가까운 주유소 및 목적지까지 자동주행(Auto Pilot) 애플리케이션을 다운받아 사용할 수도 있을 것이다. 이러한 어댑티브 플랫폼용 애플리케이션은 차량 애플리케이션 서버에서 관련된 스마트센서와 스마트 액추에이터를 제어하며 운전자에게 필요한 서비스를 제공하게 될 수 있다.[6]
버전별 특징
버전 2.0은 총 107종의 표준 문서를 제공하며 소프트웨어 아키텍처 및 방법론/템플릿의 기본 기능을 제공한다. 버전 3.0으로 올라오면서 애플리케이션 인터페이스 표준이 제공되기 시작한다. 애플리케이션 인터페이스는 차량 도메인별 서비스 설계 시 일반적으로 많이 사용되는 API를 표준화하여 제안한 것이다. 버전 3.1의 주요 특징은 차량 진단 스택에 기존에 제공하던 UDS(ISO 14229) 이외에 OBD Ⅱ 서비스를 추가한 것이다. OBD란 차량에 문제가 발생하였을 경우 계기판에 경고등을 점등하여 운전자로부터 차량 이상을 알게 하는 시스템을 말한다. OBD Ⅱ는 단선 및 단락외의 센서의 합리성, 퍼포먼스 및 시스템 정상 여부를 진단하는 것으로 3.1 진단 스택에는 OBD Ⅱ관련 9개의 서비스를 추가하여 제공한다. 표준화 협회에서는 버전 3.0과 3.1의 차이점은 진단 서비스 추가 부분밖에 없어 유지보수의 편의를 위해 R3.0 리버전 7과 R3.1 리버전5부터는 통합하여 개정하기로 결정하였다. 버전 3.2는 4.0이 배포된 이후 작업이 들어간 3.X대의 버전이다. 파셜 네트워킹 및 오류 수정과 관련된 고객 요구사항을 위하여 2010년부터 표준화 작업에 들어가 2011년 5월에 배포되었다. 3.2 버전은 3.1 버전과 호환성을 보장하며 통신 스택의 확장에 초점을 맞춘 버전이다. 4.0이 배포된 후에 시작된 버전이라 4.0의 주요 특성인 안전성, 플렉스레이(FlexRay) ISO TP 등의 기능들이 역적용되었다. 오토사 표준화 일정 Phase Ⅲ에서는 워킹그룹 “효율적 에너지 관리(Efficient Energy Management)”가 새롭게 결성되면서 차량 에너지 감소를 위한 컨셉에 대해서 연구 중에 있는데 파셜 네트워킹은 그 중 첫 번째 이슈이다. 파셜 네트워킹(partial networking)이란 하나의 통신 버스상의 개별 ECU 통신을 중지/재시작할 수 있는 기술로, 활성화되지 않은 기능과 관련된 ECU를 저전력 모드 혹은 파워오프 모드로 유지시킴으로써 전기 절감및 CO2 배출량의 감소를 유도한다. 이러한 특성들을 반영하여 표준 문서를 보완하고 통신 스택 1종 및 시스템 스택 2종의 추가 표준 문서를 배포하였다. 버전 4.0은 2009년 12월에 첫 배포된 이후로 가장 왕성하게 표준화 작업이 진행되었다. 4.0 버전은 차량 도메인 기술에서 가장 중요한 안전성 보장을 위한 기능 추가 및 차량 멀티미디어 서비스를 목표로 한 TCP/IP 기술 접목, 디버깅 및 에러핸들링, 멀티코어프로세스 지원 등 추가된 특성이 방대하다. 기능 안전성을 위하여 추가된 대표적인 기능으로 메모리 파티셔닝(memory partitioning) 및 E2E 프로텍션(protection) 기술이 있다. 메모리 파티셔닝 기능이란 ECU 상에 올라가는 소프트웨어를 구역으로 나누어 에러가 발생하였을 때 전체 소프트웨어를 재시작하는 것이 아니라 에러가 난 부분만 종료 후 재시작함으로써 동작하게 하는 기술이다. E2E 프로텍션 기술은 애플리케이션이 송수신하는 데이터에 CRC 기술을 적용하여 데이터 안전성을 보장한다. 4.0 버전에서 추가된 또 하나의 특징은 TCP/IP 통신을 지원하는 것이다. 이를 위하여 오토사는 이더넷 드라이버, 트랜시버 드라이버, 인터페이스, 상태매니저, UDP 네트워크 매니저, 소켓어댑터 등의 모듈을 신규로 개발하였다. R4.0에서는 지속적으로 진단 데이터를 수집하여 외부사용자가 이 정보를 추적할 수 있도록 지원한다. R4.0에서는 이러한 기술들을 반영하기 위하여 기존의 표준 문서의 보완은 물론 총 27개의 모듈을 추가하고 60여종의 방대한 표준문서를 신규로 배포하였다.[8] 2013년 상반기에는 오토사 4.1.1 버전이 릴리스됐다. 오토사 4.1.1 버전과 오토사 4.0.3 버전과의 차이점은 새로운 BSW 모듈이 추가된 것이라 할 수 있다. 오토사 4.0.3 버전은 전체 69개의 모듈로 구성돼 있었는데 오토사 4.1.1 버전은 이더넷 모듈인 DoIP(Diagnostic over IP), Sd(Service Discovery), TcpIP(TCP/IP stack)과 J1939 관련 모듈인 J1939Dcm, J1939Nm, J1939Rm 등이 추가돼 77개 모듈로 구성됐다. 출시 당시 2016년에는 오토사가 적용된 ECU가 약 3억 개(2012년 대비 10배)에 달할 것으로 예상했으며, 이중 대부분은 오토사 3.X 와 오토사 4.X 기반이 될 것으로 전망되었다. 당시 대부분 제조사는 2015년부터는 오토사가 적용된 제품만을 납품받겠다고 발표한 바 있다.[9]
방법론
시스템 설계 단계에서 기능 소프트웨어의 아키텍처가 결정된다. 이는 소프트웨어 컴포넌트와 소프트웨어 컴포넌트를 ECU에 분배하는 과정을 정의함으로써 이루어지는데 네트워크 통신도 이 단계에서 결정된다. 이 작업의 결과물이 바로 오토사 XML 시스템 디스크립션 파일로서, 각각의 ECU 특정 추출물은 이 시스템 디스크립션 파일로부터 생성된다. ECU 개발 과정 중, 소프트웨어 컴포넌트는 설계되고 구현되며 베이직 소프트웨어와 런타임 환경이 구성된다. 개발자는 이 구성을 통해 프로젝트에 필요한 베이직 소프트웨어의 양을 결정한다. 이와 같은 방식으로 전체 ECU 소프트웨어를 최적화할 수 있다. 이 구성의 결과물이 ECU 익스트랙트 오브 시스템 디스크립션(Extract of System Description)에 맞춤 튜닝된 ECU 컨피그레이션 디스크립션(Configuration Description)이다. 코드 생성기는 ECU 컨피그레이션 디스크립션에 기반하여 ECU 소프트웨어용 베이직 소프트웨어를 생성 및 구현한다. 런타임 환경도 이러한 방식으로 ECU 맞춤형 기법으로 생성된다. 오토사에서 정의된 이 기법은 애플리케이션 소프트웨어를 ECU에 통합하는 과정을 확연히 간소화해주며 일일이 소프트웨어를 조정하는 과정은 필요하지 않다.[10]
적용
자율주행
자율주행 자동차의 진화에 따라 미래 자율주행 자동차를 위한 소프트웨어 구조에 대한 논의가 활발해지고 있다. 미국자동차공학회(SAE)의 자율주행 레벨 1, 2 정도로 상용화되어 있는 부분 자율주행 자동차와 높은 레벨의 시연을 보여주기도 하는 연구용 차량의 경우에는 센서, 소프트웨어 플랫폼, 통신 환경 등에서 많은 차이를 보이고 있다. 최근에는 연산 능력의 강화와 센서의 저가화로 고급 인식 기능을 가진 새로운 참조형 모델을 선보이고 있으며, 아우디(Audi)는 2018년 레벨 3 차량의 상용화를 발표하기도 했다. 향후 자율주행 자동차의 진화를 위해 새로운 전기전자 구조와 소프트웨어 플랫폼 구조가 제시되고 있다. 이더넷 기반의 내부 구조와 센서 연결, 어댑티브 오토사의 구조 진화가 예상되고 있으며, 이에 대한 연구 개발이 진행되고 있다.
2015년부터 진행된 부분 자율주행 자동차의 상용화는 자율주행 자동차 시장의 새로운 분기점이 되었다. 테슬라(Tesla), 현대자동차㈜, 메르세데스-벤츠(Mercedes-Benz), 닛산(Nissan) 등으로부터 시작된 고속도로 주행 보조(HDA) 기능은 여러 회사로 확산되었다. 또한 구글(Google) 자율주행 시범차량처럼 고가의 센서를 장착한 연구차량도 다양하게 등장해 왔다. 상용화와는 거리가 있지만 고가의 센서를 바탕으로 높은 수준의 자율주행을 위한 다양한 시도를 보여왔다. 최근에는 주요 완성차 업체들이 카메라나 라이다 기능 등 인식 시스템을 대폭 강화한 새로운 참조 모델을 선보이고 있으며, 향후 진화를 위한 다양한 시도를 보여주고 있다. 이미 상용화되어 있는 부분 자율주행 차량과 연구 개발용 차량을 대략 비교해 보면 센서와 소프트웨어 플랫폼 등에서 많은 차이를 보인다. 주요 업체들이 상용화한 차량은 카메라나 레이더에서 센서 데이터 자체가 아닌 처리된 데이터를 CAN을 통해서 받고 있다. 이에 비해 연구용 차량은 레이더가 처리된 결과를 CAN으로 받고 카메라는 HDMI를 통해서 원영상을 받으며, 라이다는 이더넷으로 연결하는 경우가 많이 있다. 이 두 구조 모두 향후 고도 자율주행 이상의 진화를 위해서는 진화해야 할 여지가 많이 있다. 특히, 원센서 데이터의 수신 및 처리를 위한 고속 네트워크와 고속 처리 플랫폼이 중요한 이슈가 되고 있다. 지금까지 자율주행 소프트웨어 구조가 제어-인식이 융합된 구조라면, 앞으로는 제어-인식-통신이 융합된 형태의 소프트웨어 구조로 진화될 것이며, 통신을 통한 클라우드의 중요성도 높아질 것이다. 기술적으로는 이더넷-어댑티브 오토사-5G-클라우드를 연결하는 구조가 될 것이다. 자율주행 자동차의 센서 정보는 이더넷 기반의 빠른 통신망을 이용해서 원데이터를 그대로 전송하고, 이 데이터를 바탕으로 경로 생성 및 제어를 수행하게 될 것이다. 특히, 어댑티브 오토사는 자율주행을 위한 데이터 처리와 경로 생성 등 핵심 알고리즘을 담당하는 소프트웨어 플랫폼이 될 것이다.
차량 제어용 소프트웨어 플랫폼을 표준화하는 단체인 오토사는 지난 2017년 3월 어댑티브 오토사 플랫폼을 발표했다. 이를 통해 차세대 스마트카 소프트웨어 플랫폼은 기존 제어용 플랫폼과 고성능 처리 및 통신용 플랫폼을 서로 나누고 연결하는 구조를 가지게 된다. 기존 차량 제어를 담당하는 플랫폼인 클래식 오토사와 고성능 컴퓨팅 및 통신을 제공하는 어댑티브 오토사 플랫폼으로 나누어 역할을 분담하게 된다. 그동안 자동차 업체는 차량 제어용 플랫폼인 오토사 플랫폼을 디지털 클러스터, 헤드 유닛 등 차량 전반으로 확장하기 위한 노력을 계속해 왔다. 하지만 차량용 카메라, V2X 모듈 등 차량 센서 플랫폼과 통신 모듈에 리눅스OS가 사용되고, 제어용 플랫폼으로는 고성능 컴퓨팅 성능을 내기가 어려워지면서 기존 오토사 OS 기반의 플랫폼이 아닌 포직스 기반의 플랫폼에 대한 진화가 필요하게 되었다. 즉, 오토사 OS 기반의 클래식 오토사 플랫폼과 포직스 기반의 어댑티브 플랫폼을 혼용하는 구조가 제안된다. 다양한 센서 정보와 통신 정보가 융합된 자율주행 데이터 처리를 위해서는 고성능 컴퓨팅을 위한 어댑티브 오토사를 적용하게 될 것으로 예상된다. 어댑티브 오토사는 포직스 기반의 OS를 사용하여 오픈CV 등의 영상처리, 통신 소프트웨어, 딥러닝 소프트웨어의 처리가 용이한 장점을 가진다. 고성능 CPU 활용에 사용되는 동시에, 여러 ECU에 분산되어 있는 서비스 기반 구조(SOA)로 이더넷 고속통신과 연동되게 된다. 따라서 향후 센서 데이터와 통신 정보를 바탕으로 한 자율주행 경로의 생성과 차량 제어를 담당하게 될 것으로 보인다. 많은 데이터의 빠른 처리를 위한 고성능 ECU에는 어댑티브 오토사가, 신뢰성을 위한 실제 제어용 ECU에는 클래식 오토사가 적용될 수 있다. 향후 차량용 소프트웨어는 인식-제어-통신을 융합하는 형태로 발전될 것이며, 오토사 플랫폼도 제어 기반의 클래식 오토사와 센서/통신 정보를 바탕으로 자율주행을 처리하는 어댑티브 오토사 플랫폼으로 나뉘어 진화할 것으로 보인다. 즉, 어댑티브 오토사가 고성능 프로세서 위에서, 센서와 통신 정보를 바탕으로 경로 생성을 담당하고 차량 제어를 위한 클래식 오토사에 명령을 내려주는 구조로의 진화를 예상해볼 수 있다.[11]
각주
- ↑ 〈오토사〉, 《네이버 지식백과》
- ↑ 2.0 2.1 2.2 2.3 2.4 2.5 〈AUTOSAR〉, 《위키백과》
- ↑ 김창욱 기자, 〈(ICT 시사용어)오토사(AUTOSAR)〉, 《전자신문》, 2014-03-31
- ↑ 마이데이, 〈오토사 (Autosar)의 의미, 구성, 현황, 과제〉, 《네이버 블로그》, 2011-05-18
- ↑ 〈스마트카기술포럼_AUTOSAR 기술 표준화〉, 《한국정보통신기술협회》, 2017-10-11
- ↑ 6.0 6.1 6.2 6.3 6.4 조재윤 매니저, 임베디드 소프트웨어 사업부, Vector Korea IT, 〈차세대 ECU를 위한 AUTOSAR Adaptive Platform〉, 《AEM》, 2017-11
- ↑ Stuart Mitchell, 〈어댑티브 플랫폼: 새로운 AUTOSAR〉, 《이타스》, 2018
- ↑ 자동차융합플랫폼연구팀 성기순 선임연구원, 한태만 팀장, 〈차량 SW 플랫폼 표준화 동향〉, 《전자통신동향분석 제26권 제6호》, 2011-12
- ↑ 이헌철, 〈AUTOSAR 4.1.1의 최신 기술과 이해〉, 《AEM》, 2013-07
- ↑ 〈AUTOSAR Classic Platform〉, 《벡터》
- ↑ 국민대학교 전자공학부 정구민 교수, 오요한·김종완 석사과정, 〈자율주행차 진화를 위한 어댑티브 오토사 플랫폼〉, 《TTA 저널》, 2017-09-10
참고자료
- 〈AUTOSAR〉, 《위키백과》
- 〈오토사〉, 《네이버 지식백과》
- 〈AUTOSAR Classic Platform〉, 《벡터》
- 마이데이, 〈오토사 (Autosar)의 의미, 구성, 현황, 과제〉, 《네이버 블로그》, 2011-05-18
- 자동차융합플랫폼연구팀 성기순 선임연구원, 한태만 팀장, 〈차량 SW 플랫폼 표준화 동향〉, 《전자통신동향분석 제26권 제6호》, 2011-12
- 이헌철, 〈AUTOSAR 4.1.1의 최신 기술과 이해〉, 《AEM》, 2013-07
- 김창욱 기자, 〈(ICT 시사용어)오토사(AUTOSAR)〉, 《전자신문》, 2014-03-31
- 국민대학교 전자공학부 정구민 교수, 오요한·김종완 석사과정, 〈자율주행차 진화를 위한 어댑티브 오토사 플랫폼〉, 《TTA 저널》, 2017-09-10
- 〈스마트카기술포럼_AUTOSAR 기술 표준화〉, 《한국정보통신기술협회》, 2017-10-11
- 조재윤 매니저, 임베디드 소프트웨어 사업부, Vector Korea IT, 〈차세대 ECU를 위한 AUTOSAR Adaptive Platform〉, 《AEM》, 2017-11
- Stuart Mitchell, 〈어댑티브 플랫폼: 새로운 AUTOSAR〉, 《이타스》, 2018
같이 보기
