오토사 (Autosar)의 의미, 구성, 현황, 과제 [출처] 오토사 (Autosar)의 의미, 구성, 현황, 과제

ref. http://blog.naver.com/PostView.nhn?blogId=bongkwankim&logNo=150109174063


 

images

 

자동차 SW업계의 화두 중의 하나가 오토사 (Autosar)이다.

자동차 전자제어에 대한 기술적 백그라운드가 부족한 사람이라도

읽어 보면 무슨 뜻인지 이해할 수 있게 나름대로 해석을 하여 자료를

가능한 쉽게 한 번 만들어 본다.

 

본 내용에 틀린 점이 있다면 순전히 필자의 오류이니 오해 없길 바란다.

 

1.오토사 제정 배경 :

 

결론부터 말한다면 오토사는 자동차 전장용 임베디드 SW 재사용을 통한 개발의 생산성 향상을 위한 SW 표준 플랫폼이다.

 

자동차가 기계 장치인가 아니면 가전제품 같은 전자 제품인가?

금년 2011년도 1월 미국 라스베가스에서 개최된 CES (Consumer electronics show) 가전쑈에 자동차 회사들이 대거 출품하였다.

이젠 자동차나 가전이나 따로 영역이 없어지는 것도 의미가 있지만

사실 그만큼 자동차의 전장 분야가 급격하게 늘어 나고 있다는 측면도 강하다.

앞으로 자동차의 “시동을 건다”라는 표현 대신 “부팅한다”라는 말을

사용하게 될지 모를 정도이다.

자동차 안에 ECU (Electronic control unit)라는 전자제어 장치,

쉽게 표현하자면 작은 컴퓨터 장치가 많이 들어 있다.

일본 TOYOTA 렉서스 같은 고급차인 경우 약 100개 정도 들어 가고 제네시스에도 약 60개 정도 들어간다고 한다.

 

더욱이 이런 각 부품들이 서로 네트워크처럼 얽혀 통신도 한다.

Autosar는 기본적으로 자동차 ECU를 위한 임베디드 SW 플랫폼이다.

16비트 혹은 32비트 차세대 ECU용 프로세서를 주요 대상으로하며 독립적인 기능을 하는 ECU 보다는 상호 통신을 통하여 작업을 하는 ECU 모듈들을 가정하고 AUTOSAR 플랫폼은 자동차 제어 네트워크에 초점을 맞춘다.

 

자동차내 통신선은 제어 네트워크라 부른다.

차량내 제어네트워크는 활용분야에 따라 서로 다른 매체를 사용한다.

 

첫째 : 에어백이나 브레이크 같이 통신의 신속성과 안전성이 보장되어야 하는 매체로는 CAN (Controller area network)을 주로 사용한다.

두번째로 문열림이나 유리창 버튼처럼 신속성도 중요하지 않고 대역폭도 좁은 것은 저가의 LIN(Local interconnect network)이 있다.

최근에는 CAN과 LIN의 영역 모두 포함할 수 있는 FlexRay라는 기술이 나와 차량내 통신선 길이 단축, 통신선간의 간섭 문제 모두를 해결할 수 있어 각광 받을 전망이다.

마지막으로 제어신호가 아닌 멀티미디어 데이터와 같은 다량의 정보를 전달하기 위한 매체로서 MOST (Media oriented systems transport)가 활용되고 있다.

 

옛날 라디오, CD Player 정도였던 Audio, Video 장치도 Multi-media뿐

아니라 통신과 네비게이션 등 각종 컨텐츠를 제공하는 텔레메틱스,

또는 인포테인먼트 장치로 진화하고 있다.

통신이 되려면 각종 휴대폰장치들을 사용할 수 있어야 하는데 OS만해도 유명한 구글의 안드로이드, 아이폰의 iOS를 비롯하여 다양하다.

 

ECU라는 Board안에는 Chip도 있고 각종 SW가 내장되어 있다.

운영체계인 OS (Operating system), 각종 성능을 담당하는

응용프로그램인 Application 등이다.

이런 ECU도 하드웨어 안에 내장되어 있다 보니 각 부품사에 따라 각각 다른 운영체제를 사용하게 되고 응용프로그램도 각 운영체계에 맞추어 개발된다.

ECU 숫자가 늘어 나고 SW의 LOC (Lines of code)가 증가하면 복잡도가 증가하고 복잡도가 증가할수록 품질이 저하될 가능성이 높다는 것이 문제점으로 대두되고 있다.

 

35년전 자동차의 SW LOC는 100라인,

2000년도에는 100만 라인,

2012년도에는 1억라인으로 예상된다고 한다.

거의 비행기 수준이다.

 

미국 NASA의 경우 소스코드 1라인당 $850의 비용을 들여 개발한 SW 1,000 lines당 오류는 0.004개로 알려져 있다.

그러면 1억라인의 SW가 들어가는 자동차의 경우 확률적으로 400개의 오류가 있다고 추정할 수 있다.

850억불, 90조원을 들여 개발해도 오류가 400개 있다면 자동차는 과연 어떻게 대처해야 하나라는 의문이 든다.

 

작년 미국에서 Toyota사태에서 보다시피 자동차 리콜 한번 크게 당하면 회사가 휘청한다.

 

특히 금년 10월쯤 공표될 예정인 자동차 국제 안전규격인 ISO 26262에 의하면 사고가 났을 경우 자동차 OEM및 부품업체는 최신의 기술과 규격에 의하여 제조하였다는 것을 입증할 수 있어야 면책이 된다고 한다.

이런 큰 변화를 정리하면;

 

(1) 전자장치의 증가

(2) SW 복잡도의 증가

(3) 표준화의 필요성 증가라고 요약할 수 있다.

 

여기서 왜 표준화의 필요성이 증가할까?

단순히 SW 수량이 늘어서?

물론 그런 이유도 있다.

자동차 하드웨어는 원가절감을 위해 한가지 부품으로 여러 차종에 공통으로 사용화하는 경향이 추세화 되었다.

부품도 단위부품들을 모아 Module화하여 단순화 시켰다.

 

마찬가지로 SW도 차종마다 모두 다르게 만들고 같은 차안에서도

각 부품사들이 납품하는 ECU안에 각각 다른 운영체제 (OS)를

사용하다 보니 효율성과 호환성이 떨어지고 안전성에도 문제가

많아지게 되었다.

 

그래서 우선 운영체제인 OS부터 자동차용으로 하나로 통일 시킨 것이

바로 OSEK이다.

OSEK 자체는 운영체제는 아니다.

POSIX와 같이 오토사를 지원하는 운영체제가 지원해야 할 표준 API 규격의 정의이다.

따라서 OSEK을 지원하는 다양한 운영체제가 존재할 수 있으며 이들 대부분은 실시간성을 동시에 지원한다.

 

한편 사업적 관점에서 본다면 현재 자동차 OEM들은 각 부품별로 납품을 받아 조립을 하는 구조인데 SW가 포함된 전장부품들을 여러 회사로부터 납품을 받다 보니 여러 가지 심각한 문제가 제기되었다.

 

첫째 : 자동차 시장의 경쟁이 치열해져서 신규모델 출시 주기가 점점 짧아지고 있다. 전장부품들은 서로 통신도 해야 하고 연결되어야 하는바 부품사들낄 협력의 필요성이 증대하여 개발 생산성 향상과 함께 공통 플랫폼의 필요성이 대두되었다.

-ECU에서 통신 프로토콜과 같이 다양한 기능 수행으로 복잡도 증가

-자동차 모델 개발 주기 감소

-기존 업계 분업 구조 파괴등의 필요에 의거 AUTOSAR라는 업계 표준 규격을 제정하게 되었다.

 

 

2.오토사의 설립과 의미

 

AUTOSAR는 ( AUTOmotive Open System Architecture)의 약자로서
2003년 유럽 자동차 업체인 BMW, Bosch, Continental, Daimler-Chrysler, Volkswagen을 주축으로 시작되었다.
처음에는 BMW 1개 회사가 독자 추진을 하다가 워낙 투자비가 많이 들어 할 수없이 공동 개발로 방향 전환을 하였다는 설도 있다.

현재도 BMW가 선두주자이다.

 

AUTOSAR는 자동차 전장용 임베디드 SW 개발의 생산성 향상에 그 근본을 두고 있다.

 

1)AUTOSAR는 표준화된 SW 구조를 정의하며 모듈화된 SW구성을 지원한다. 모듈화는 개발자 입장에서 기능들을 서로 다른 모듈로 구현하게 해줌으로서 복잡도를 감소시켜 생산성을 향상 시킨다.

 

2) 모듈간 인터페이스만 정해지면 각 모듈별로 서로 다른 업체에서 개발이 가능하므로 분업이 가능하여 개발일정을 단축시킬 수 있다.

 

3)자주 사용되는 기능을 모듈화하여 모든 ECU에서 재사용이 가능하다.

차량용 미들웨어의 대표적 사례로 자동차용 전자제어장치에 필요한 전 소프트웨어 분야의 개방형 표준을 제정하기 위한 국제협회이다.

OSEK 대비 훨씬 방대한 자동차 소프트웨어 표준화를 시도하고 있다.

자동차 산업은 전형적인 조립 산업이다.

자동차 회사는 각 부품 회사들이 납품한 부품을 조립한다.

부품은 HW와 SW로 구성되어 있는데 자동차 OEM 입장에서는 동일한 부품이라도 여러 회사가 경쟁을 해야 경쟁적인 가격의 자동차를 만들 수 있다. 하지만 HW는 표준화가 가능한데 SW는 표준화가 어렵다. 그렇다 보니 자동차 OEM이 특정 부품사에 의존하게 되는 어려움이 있다. 따라서 부품을 HW와 SW를 분리하고 더 나아가 SW를 표준화하게 되면 OEM은 SW 때문에 특정 부품사에 의존도를 낮출 수 있고 핵심 부품사는 한번 개발한 SW를 여러 차종에 재사용할 수 있는 Merit가 있다.

어쨋든 오토사의 표준화를 통해 창출 가능한 고객가치는 다음과 같이 해석된다.

가.OEM업체 :

  ① SW의 재사용성 증대 :

      A차용 SW를 B,C,D등 여러 차종에 공통 사용 가능하게 됨.

      하지만 이 경우에도 SW를 MBD (Model-based-design)으로

      개발 되어야 한다.

      여기서 코딩을 Auto-coding으로 하느냐 아니면 아직도 신뢰성

      문제로 Hand-coding을 고수할 것이냐는 논란이 있는 것 같다.

      회사의 정책 이슈이긴 하지만 핸드 코딩으로는 점점 늘어 나는 SW

      분량을 관리하는데 한계가 있고 재사용성을 올리는데도 문제가

      있어 유럽의 일류 자동차 회사는 대부분 Auto-code-generation

      하는 것으로 확인 되고 있다.

      따라서 오토사 플랫폼을 채용하는 선결조건으로 응용프로그램을

      재사용이 가능한 방식으로 개발하는 프로세스가 먼저 정립되어야

      한다.

      윗 부분의 Application은 옛날 방식으로 개발하고 아랫단만

      오토사로 바꾼다면 가장 중요한 Application program의 재사용성

      이 불가능하다면 의미가 퇴색되기 때문이다.

      하지만 이것이 모든 Application program을 송두리채 다 새로 만들

     어야 한다는 의미는 아니다. 기존 Legacy application program중

     에서도 새로 개발해야 할 것은 새로 개발하고 그대로 둘 것은 두는

     것이 맞다. 그러나 이런 Migration 방법을 수립하는 것도 대단한

     Know-how이다.

 ② 사양 표준화 :

      예를 들면 차량내 통신 프로토콜을 Flex-ray로 한다든지

      CAN으로 하든지 표준을 정하면 나중에 부품간 통합도 용이해져

      사양 표준화에 도움이 된다.

  ③ 안전성 증대 :

      일단 안전이 검증된 SW를 재사용하므로서 매번 새롭게

      코딩하는 것 보다 안전성이 확보 가능해진다.

      그리고 엄격하게 표준화된 프로세스에 의한 SW개발로 안전성이

      증대 된다.

  ④ 원가절감 :

       SW 재사용, 신차 모델 개발 기간 단축 등 원가 절감 가능

  ⑤ 부품사간 커뮤니케이션 원활 : 표준,사양등 명확한 소통 가능.

나.부품업체 :

  오토사 기반으로 부품을 만들면 현재는 특정 OEM별로 모두 별도의 사양으로 생산하였으나 이제 표준화되어 오토사를 채용하고 있는 다른 OEM에게도 납품이 가능하게 된다. 이것 때문에 Bosch, Continental 등 현재 기술적 진입장벽을 누리고 있는 업체들이 참여하고 있지 않은가 추측된다. 하지만 선발 부품사들은 그 동안 누렸던 독보적 사양에 의한 진입장벽을 표준화하여 공개하는데 따른 불이익도 있을 것으로 추측된다.

이것이 바로 오토사가 추구하고 있는 실질적인 또는 경제적 의미가 아닐까 생각한다.

3.오토사 구조 :

 오토사는 크게 3개의 계층으로 구성되었다.

  1) Autosar SW – C (Component) :  자동차의 실제 기능을 담당하는

     응용 SW 부분 임. 그 동안 각 자동차마다 각각 다른 응용프로그램

     이 올라 갔으나 오토사에 일종의 미들웨어인 RTE가 있어 차종이

     바뀌더라도 재사용이 가능한 부분이다.

  2) RTE (Run-time environment)

      SW-C와 아래에 있는 BSW 사이의 정보 교환과 연결을 시키는

      중추적 역할과 그 결과로 SW와 HW를 분리하는 핵심역할을 한다.

      하부의 ECU 하드웨어가 바뀌더라도 상위에 제작된 SW 컴포넌트

      들을 수정없이 사용할 수 있도록 만들어 주는 일종의 미들웨어

      역할을 한다.

  3) BSW (Basic software) :

      다양한 ECU에 공통으로 적용 가능하게 만드는 Layer로 HW와 SW

      를 분리 시키는 역할을 한다.

      ECU HW와 연결하는 하부 Layer로 OS, EAL (ECU Abstraction

      layer), MCAL (Microcontroller abstraction layer),

      CDD (Complex device driver)로 구성되어 있다.

      OSEK은 그 자체가 운영체제는 아니며, POSIX와 같이 AUTOSAR를 지원하는 운영체제가 지원해야 할 표준 API 규격의 정의이다.

      MCAL (엠칼)은 Freescale, inpeneon 같은 Chip회사가 각자 오토사 표준에 맞추어 개발하여 제공하므로 자연적으로 칩에 대한 의존도가 사라지게 되는 것이다.

Autosar 개발언어는 C, C+, Java를 명시하고 있지만 대부분 전장 SW는 안전성 검증이 상대적으로 수월한 C언어로 개발하는 것이 일반적이다.

C code의 신뢰성 보장 방안으로 가장 널리 알려진 기준은 MISRA-C (Motor industry sw reliability association) 규칙이다.

상기와 같이 오토사 플랫폼은 계층화된 구조를 가지고 있다. 따라서 각 계층별로 검증이 이루어지면 그 상단에서 개발되는 응용프로그램은 그 자체의 안전성만 검증하면 된다.

펌웨어 수준으로 개발되는 경우, 단위 개발자 입장에서는 단순하고 Flexible하다는 장점이 있지만 소스코드 전체에 대하여 검증이 매번 이루어져야 하는 것과 비교하면 생산성 향상이란 측면에서의미 있는 결과를 얻을 수 있다.

또한 오토사는 자동차 Domain을 아래 6개로 나누었다.

1) 바디 2) 샤시 3) 파워 트레인 4) HMI (Human-machine interface)

5) 멀티미디어/ 텔레메틱스 6) 안전 분야이다.

특히 지금 활발하게 논의되고 있는 기능 안전 표준인 ISO 26262 관련하여 Autosar 플랫폼과 프로세스를 사용할 경우 Autosar 4.x 버전에서는 ISO 26262 규정을 상당수 만족하는 것으로 알려져 있다.

4.오토사 적용 현황

  선두주자인 BMW가 2006년 시험 적용한 이후 2009년 12월에 Version 4를 배포하였고 2011년 9월에 Version 4가 완성될 예정이다. BMW는 2011년 현재 표준화된 BSW (Basic SW)를 56% 적용하고 있으며 16%는 BMW 독자 Spec을 사용하고 있는 것으로 알려져 있다. 2015년까지 100% 적용을 목표로 하고 있다.

2011년 현재 Mini는 전 부품을 오토사 표준에 의거 개발 되었으며 다른 차종으로 점차 확대 중이다.

BMW뿐만 아니라 Audi, Daimler, PSA, Volvo, Volkswagen과 그리고 Ford, GM의 미국 자동차 그리고 Toyota를 비롯한 일본 자동차업계도 JASPAR (자스파)라는 일본식 오토사에 의거 자체 Road-map을 가지고 추진 중인 것으로 알려져 있다.이 통계를 보면 오토사는 이제 더 이상 논문에 나오는 이론이 아니고 현실이다. 만약 BMW와 같은 SW기술의 리더를 벤치마킹하려는 자동차 회사이거나 그런 회사에 부품을 공급하려는 부품회사가 있다면 심각하게 진입과 투자와 인력 양성을 고민 해야할 상황인 것으로 판단된다.

왜냐하면 오토사는 상당히 복잡한 구조를 가지고 있고 단순한 기능이 아니라 SW 개발 프로세스를 바꾸는 방대한 변화를 의미하기 때문이다. 따라서 내부를 이해하고 담당자와 해당 조직이 그런 SW 역량을 체화 하는데는 최소 2~3년 정도 상당한 시간과 노력이 소요되기 때문이다.

현재 그리고 Autosar 9개 Core members (BMW, Bosch, Continental, Daimler-Chrysler, Volkswagen, Peugoot Citroen, Ford, Toyota, GM)들은 자사차량에 2012년까지 단계적으로 적용하기로 공표 하였다.

SW업계의 다수는 향후 자동차 품질 차별성과 안전성, 그리고 가격경쟁력이 모두 임베디드 SW에 달려 있고 이런 SW의 표준 플랫폼을 장악하는 것이 미래 자동차의 핵심 경쟁력이 될 것이라고 예언하고 있다.

5.오토사 버전별 특징 요약

  가.오토사 3.1 특징 : 3.0에 OBD-II 보강
나.오토사 3.2 특징 :
1)Partial networking
2)Robustness features
3)Error handing 개선
4)Safety concept (E2E Communication)
5)Extended CDD concept
6)BSW Mode manager
7)FlexRay ISO protocol

  다.오토사 4.0 특징

       가장 큰 특징은

         첫째 : 표준화의 강화

          오토사가 비록 표준 Open architecture이긴 하지만 Version 3

          까지는 각 OEM 고유의 Spec이 존재하고 있는 바 금번

           Version 4에서는 이런 차이점들은 BSW에서 제거하여 표준화

           를 완성시킨다는 것으로 알려져 있다.

          둘째 : ISO 26262의 Funtional safety 반영

          세째 : TCPIP등 새로운 모듈 추가

         -Functional safety : Memory partitioning, E2E protection등

          -Architectural improvements : Error handling, multicore,

            bootloader

           -RTE enhancement : Trigger event, API enhancement

           -Evolution of communication stack : Partial network,

             ethernet..

           -Functional enhancement : Vehicle and application mode

             management

           -Diagnostic harmonization : Dem behavior….

           -Debugging : XCP, Debug log & trace

           -Enhancement of methodology and tools : Timing mod

6.유럽 주요 OEM별 오토사 버전 적용 현황

  -BMW : 현재 3.1 내년 4.0
-Audi : 3.2
-PSA : 현재 2.1 내년 4.0
-VW : 현재 3.1 내년 3.2, 4.0
-Volvo : 2014년 4.0
-Daimler : 현재 3.1 내년 3.2

7.한국 자동차/부품사는 어떤 Version으로 갈 것이냐 ?

  결정해야 한다. 외국 OEM도 일부 회사는 Version 3.2로 도입하는 경우도 있다. 하지만 필자의 짧은 소견으로는 어차피 새로 시작해야 하는데 지금 거의 완성 단계에 있고 ISO 26262, 새로운 통신 Stack, Multi-core가 지원되는 Version 4.X로 가는 것이 유리할 것 같다. 참고로 미국의 Ford나 GM도 Autosar 후발주자로 최근 Version4로 갈 것으로 결정했다고 알려져 있다.

8.오토사 관련 한국 자동차 관련 회사의 도전과 과제

 한국 자동차 업계와 학계도 많은 관심을 가지고 열공중인 것으로 알고 있다.

현대,기아자동차. ETRI가 Premium member로 활동 중이다.

특히 대형 부품사들은 해외 수출이 증가하고 있는 바 해외고객 중의 일부가 부품 공급을 Autosar 기반으로 개발하여 공급해 줄것을 요청 받고 있어 당장 발등에 떨어진 불의 과제가 되고 있다.

해외 First class 자동차업체들의 동향을 보면 향후 미래 경쟁력의 기반이 될 가능성이 커 보이지만 당장 전문인력도 부족하고 인력 양성에도 많은 시간이 소요될 것으로 보인다.

BMW의 경우 1994년부터 시작하여 이미 17년간 활동해 왔고 오토사가 발족괸지도 벌써 7년이나 되었기 때문에 이미 상당한 Gap이 존재하고 있다. 미래 자동차의 Big trend가 될 것은 틀림 없어 보이지만 문제는 How-to-do를 결정하는 것이 쉽지 않을 것 같다.

Core member들처럼 SW에 대한 기술적 리더십이 확고한 해외업체들은 자기 주도적으로 적절한 Pace대로 실행을 해나가면 되겠지만 아직 SW 기술적 자립도가 약한 국내 자동차 업계는 로드맵 구축, 최적의 방안, 우선순위 확정, 경제적 투자 규모, 타이밍, 인력 양성 등 많은 도전과 과제와 고민이 있을 것으로 추정된다. 남들이 좋다고 해서 무작정 막대한 투자를 따라 할수도 없고 그렇다고 너무도 중요한 주제인데 안전하게 한다고 모든 것 다 따지고 난 다음에 느긋하게 천천히 뛰어 들 수도 없을 것이다. 필름 메이커인 코닥사가 디지털 카메라를 제일 먼저 개발 하고도 카메라 가격이 너무 비싸 시장성이 없다고 자기에게 유리한 판단만하여 큰 기회를 놓침과 동시에 자기 사업 기반마저 붕괴한 Case가 강건너 남의 집의 불은 아닐 것이다. 소니도 마찬가지로 디지털 제품으로 패러다임이 바뀔 때 지나치게 신중한 자세로 접근하였다가 잘 알다시피 삼성이나 LG전자등 한국업계에 추월 당하는 시련을 겪고 있다.

그러나 확실한 것은 SW의 양과 복잡도의 증가로 현재의 SW 관리방식으로는 한계에 직면할 것은 자명한 사실이다. 또한 한국 자동차업계는 그 동안 HW부품의 국산화에 성공하였지만 향후 10년간의 핵심과제는 아마도 SW의 독립과 SW의 독자적 공통플랫폼을 만들어 SW 역량과 동시에 SW 원가 경쟁력을 획기적으로 강화 시켜야 할 것이다. 그런 의미에서 오토사는 비록 유럽 자동차회사들의 주축으로 만들어져 한국자동차업체가 다소 후발이긴 하지만 이때까지 항상 그렇게 해왔듯이 남 보다 더빨리 그리고 더 잘 습득하고 응용하여 새로운 자동차 SW시대의 Leader로 발돋움하는 계기가 마련되길 간절히 빌어 본다.

따라서 최근 화두가 되고 있는 오토사 그리고 ISO 26262 등 이런 것들이 한국 자동차 업계에 진정한 기회인지 식별할 수 있는 i) 통찰력과  ii) 실행할 수 있는 용기 iii)  언제 진입할 것인지에 대한 Time-to-market의 타이밍 선정  iv) 적절한 투자 규모, v) 시행착오를 줄일 수 있는 최적의 파트너 선정 vi) 인력및 역량 강화 방안 등을 결정하는 것이 가장 중요한 과제일 것으로 보인다.

기술적 관점에서는 우선 Architecure design을 XML Base로 만들어야 하고 또한 상세한 Requirements를 만들어야 한다.

그런데 문제는 해외 OEM사의 Case를 보면 이런 Requirements가 무지무지하게 상세하게 정의되어 있다는 것이다. 기술 요구사항은 당연하고 테스팅 툴, Documentation 등 한개 부품에 수백장의 문서로 작성 되어 있는데 한국 자동차 업계에서 이런 수준까지 요구 사항을 정의하고 정리하는데는 많은 시간과 시행 착오와 투자가 필요할 것이다.

결론적으로 향후 Autosar가 추구하고 있는 사상은 당연히 좋은 것이고 바람직한 방향이다. 또한 ISO 26262가 어떤 수준의 규제로 작용할지 아직 의문의 여지가 있지만 상당한 수준의 규제로 작용할 것이라는 것이 일반론이다. 왜냐하면 유럽과 일본 자동차업계의 준비 태세를 보면 단순히 그냥 좋아서 도입하는 차원과 상술을 넘어서는 것으로 판단된다. 그렇다면 이런 큰 Trend는 일단 준비하고 대비해야 한다. 문제는 준비와 전문인력 양성에 몇 년씩 소요되기 때문이다. 모바일업계의 Nokia를 보라. 소프트웨어 혁명으로 정의되는 스마트폰 시대를 대비하지 못하여 타의 추종을 불허하며 모바일폰의 압도적 선두주자였던 Nokia가 하루 아침에 몰락의 길을 걷고 있다.

개인적인 소견으로는 보험의 차원에서라도 본 AUTOSAR와 ISO 26262에 대한 준비와 대비는 규모의 문제는 별도로 치더라도 반드시 적극적으로 대처 해야 할 분야라고 판단된다. 최악의 경우라도 몸에 좋은 약 좀 먹었다고 해서 무슨 나쁜 일인가?

물론 돈이 다소 들기는 하지만 부자는 최악의 경우에 대비하는 Risk 회피 전략이 대단히 중요하다.

여담이지만 한국은 아직 자동차는 기계 덩어리이고 독일은 소프트웨어 덩어리로 인식하는 것 같다. 이는 기술자의 인력 구조에서 명백하게 드러난다. 자동차  업계 외국 전문가의 지적에 의하면 독일 자동차는 소프트웨어 기술자가 거의 50%에 가까운데 한국 자동차업계는 기계 출신이 90%에 소프트웨어는 10% 미만이라고 한다. 우리의 갈 길이 어디인지 시사점이 큰 지적이라고 생각한다.

9.오토사 관련 제품 대표적 Global 회사

   -독일 Elektrobit(일렉트로빗: http://www.elektrobit.com/)

     한국대리점 mds테크놀로지

     (http://www.mdstec.com/main/solution01/?no=270)

   -독일 벡터 ( www.vector.com )

10.기타 자료 :

 OSEK/VDX

OSEK은 자동차 및 부품업계를 중심으로 자동차에 사용되는 ‘전자제어장치의 분산 제어에 적합한 개방형 표준 규정’을 만들려는 협력 프로젝트에서 출발하였고 참여기업으로는 독일의 BMW, 보쉬, 다임러크라이슬러, 오펠, 지멘스, 폭스바겐 등이 있다. VDX는 OSEK과 유사한 목적의 프로젝트로 프랑스의 르노, 푸조 시트로엥 등이 참여하였다.
1997년 OSEK/VDX가 OSEK표준(공식 자동차용 실시간 운영체제)을 발표하였고 현재 70%의 시장점유율을 보이고 있다. 지금 OSEK은 자동차용 OS역할을 하고 있다.

AUTOSAR
(= AUTOmotive Open System Architecture)

차량용 미들웨어의 대표적 사례로 자동차용 전자제어장치에 필요한 전 소프트웨어 분야의 개방형 표준을 제정하기 위한 국제협회이다. OSEK/VDX에 비해 훨씬 더 방대한 자동차 소프트웨어 표준화를 시도하고 있다.

ex) 응용 프로그램 간 인터페이스 규격, H/W와 S/W간 호환규격, 네트워크 프로토콜 규격 등등..

Core members include the PSA Peugeot Citroën, Toyota MotorCorporation, Volkswagen, BMW Group, Daimler AG, Ford Motor Company,Opel, and automotive suppliers Bosch, Continental AG and Siemens VDO(now Continental AG).

The AUTOSAR Idea

AUTOSAR (Automotive Open System Architecture) is a standardization initiative of leading automotive manufacturers and suppliers that was founded in autumn of 2003. The goal is the development of a reference architecture for ECU software that can manage the growing complexity of ECUs in modern vehicles. Basic elements of the AUTOSAR architecture are, among others, formally defined software components (SWC) with clearly specified interfaces to the basic software (BSW) that in turn provide fundamental standard services, such as bus communication, memory management, IO-access, system and diagnostic services. Another basic element is the runtime environment RTE that connects the SWCs with the BSW.

The Virtual Functional Bus (VFB) specified by AUTOSAR delivers the conceptual foundation for the communication of SWCs with each other and the use of BSW services. The development of the SWCs is based on the VFB. In this manner, the SWCs are independent of the ECU hardware. This makes them easier to reuse and integrate into different projects on different platforms. The VFB is implemented in a specific vehicle by using a specifically configured RTE together with a suitably configured BSW for each ECU.

The development of ECUs follows the AUTOSAR methods:

During system design, the architecture of the functional software is determined. This is done by defining SWCs and their distribution over the ECUs. Network communication is also determined in this step. The result is the system description – an AUTOSAR XML file from which one generates a specific ECU extract of system description for every ECU.

During ECU development, the SWCs are designed and implemented and the BSW and RTE are configured. The developer determines the necessary amount of basic software for his project by configuration. In this manner, he can optimize the entire ECU software. The result of the configuration is an ECU Configuration Description (AUTOSAR XML file) that is tuned to the ECU Extract of System Description.

Based on the ECU Configuration Description, code generators generate and/or adapt the BSW for the ECU software. The RTE is also created in an ECU-specific manner.

This method defined in AUTOSAR significantly simplifies the integration of application software into an ECU. Manual software adjustment becomes unnecessary.

 

참고 자료 )

 

1) OSEK과 AUTOSAR를 중심으로 본 차량용 OS와 미들웨어 기술 동향

홍성수, 박지용, 유우석 / 한국정밀공학지 제 21권 제 10호 ( 2006년 9월호)

 

2) 자동차 전자제어 장치용 소프트웨어 기술 및 표준화 동향

ETRI 한태만 자동차 융합플랫폼 연구팀장

ETRI 전자통신동향분석 제 25권 제 4호 2010년 8월

 

3) Autosar solution 대표기업 독일 Elektrobit사 Home page

 

4) Autosar solution 대표기업 Vector사 Home page