자동차 IT기술 융합 및 전자 장치용 소프트웨어 기술 동향

Automotive Embedded System

Embedded World 2008Feature Story_Automotive Embedded System자동차 IT기술 융합 및 전자 장치용 소프트웨어 기술 동향메카트로닉스의 결정체인 자동차와 정보통신 기술의 융합으로 이동수단 위주의 자동차는 더욱 안전하고 편리한 자동차, 서비스 지향 자동차로 거듭나고 있다. 점차 편리와 안전 서비스를 제공하기 위한 자동차는 서비스 제공을 위한 전자제어 장치들이 보편화 되고 있으며, 전자 제어 장치들은 차량 내부 버스 네트워크를 통한 상호 연동으로 제어 서비스들의 개발이 이루어졌다. 따라서 자동차 내부에서는 신뢰성을 제공할 수 있는 차량 전장용 고속 네트워크 기술들이 개발되었으며, 서비스 개발 분야에서도 전통적인 코드 개발에서 점차 MBD(Model based Development) 형태의 개발로 이어져, 차량 탑승자들의 눈에 띄지는 않지만, 자동차 개발 프로세서 전반에 걸쳐 다양한 IT 기술들이 접목되어 자동차가 개발되고 있다. 이 글에서는 자동차 서비스 개발 사이클에서 사용되는 IT 기술들의 집합체라고 할 수 있는 전자장치용 소프트웨어의 표준 플랫폼 격인 AUTOSAR(AUTomotive Open System Architecture) 플랫폼의 표준화 동향과 각 업체별 표준에 따른 AUTOSAR 플랫폼 및 개발지원 도구들의 개발현황을 살펴본다.글 : 한태만, 박미룡, 박경민 / 자동차융합기술연구팀한국전자통신연구원 / www.etri.re.kr서 론21세기 들어 자동차는 단순한 이동수단으로부터 섀시프레임의 개별제어, 통합제어 및 자율주행 제어로 이어져 차량 탑승자의 안전을 제공하며 편리한 새로운 기능들이 추가되고 있다. 자동차 산업은 90년대 부품 모듈의 개별제어 수준에서 점차통합 모듈 제어 방식으로 진화되고 있으며, 외관과 디자인 위주에서 점차 편의성이나 안전 등의 서비스 개발로 추진되고 있다. 미래 지능형 자동차는 편의와 안전 등의 서비스들이 더욱 발달할 것으로 전망된다.산업 발전에 비춰볼 때, 자동차를 생산하는 완성차 업체들은 공통 부품 모듈을 다양한 차량 모델에 적용하고자 하고, 부품 개발업체 입장에서는 다양한 완성차 업체에 유사한 부품 모듈 납품으로 제조원가를 낮추려고 하는 것은 지극히 자연스러운 현상이다[4].이러한 일련의 공통 모듈 재사용성이나 차량별 부품 호환성 등의 문제를 해결하고자 전세계 완성차 업체, 부품공급회사 및 IT 기술 업체들이 협력하여 자동차의 표준 운영체제인 OSEK/VDX를 표준화하였고, 최근에는 전장 소프트웨어의 재사용성과 안전성 및 응용 소프트웨어의 하드웨어 의존성 제거 등을 목표로 전장 소프트웨어플랫폼 전체를 표준화하려는 노력이 AUTOSAR라는 단체를 중심으로 진행 중에 있다.또한 AUTOSAR에서는 자동차 도메인을 바디, 섀시, 파워트레인, HMI, 멀티미디어/텔레매틱스, 및 안전 분야로 나누고 각 워크 패키지별로 표준화를 단계에 따라 페이즈 1, 2, 3으로 나누어 진행 중에 있다.자동차 전제제어장치 소프트웨어 고도화자동차 전자제어장치의 변화자동차의 모습이 점차 지능형 자동차로 발전하게 됨에 따라 안전 분야에서는 수동적인 안전을 제공하는 자동차의 사고방지를 위해 초기 안전벨트나 에어백 장착 및 범퍼 등의 완충장치 장착수준에서 점차 제동의 미끄럼 방지를 위한 ABS(Anti-lock Brake System), 가속 미끄럼 방지용 TCS(Traction Control System), 그리고 고속 주행 중 발생하는 긴급상황에서 조향의 안전을 제공할 수 있도록 각 바퀴별 회전 제어가 가능하도록 하는 ESP(Electronic Stability Program) 나 ESC(Electronic Stability Control) 등이 현재 차량에 장착이 되어 탑승자의 안전성을 높여주고 있다.또한 운전자의 편의를 높여줄 수 있는 다양한 바디 제어 제품들이 차량에 장착되고 있으며, 차내 iPod 등의 멀티미디어 장치들을 연결하여 탑승자의 멀티미디어 정보를 통합하여 제어할 수 있는 기술들과, 차량 후방 안전 확보를 위한 후방 카메라 시스템, 앞차와의 거리에 따라 속도를 자율 조절할 수 있는 SCC (Smart Cruise Control) 및 자율 주차를 제공할 수 있는 APS (Auto Parking System) 등을 장착한 차량들이 출시되어 판매되고 있다.미래 지능형 자동차를 위하여 연구되고 있는 분야로는 바디 통합제어를 위한 BCM(Body Control Module), 종축 및 횡축의 특성을 종합할 수 있는 섀시 통합 제어 모듈, 능동형 사고 방지나 사고회피를 위해 기존 IT 분야에서 개발되었던 Ad-hoc 통신기술 및 다양한 통신기술들을 차량과 접목시키는 차간 통신이나 센터 통신 등의 VMC(Vehicle Multihop Communication) 기술들이 개발되고 있다. 그리고 운전자의 운전에 도움을 줄 수 있는 차선이탈 경보를 할 수 있는 LKS(Lane Keeping System), 사각지대 장애물 인식시스템이나 야간 장애물을 초음파 등을 통해 시각화 시켜 DIS(Driver Information System) 등을 통해 알려줄 수 있는 기술, 차량 내외부 정보를 통합 제어할 수 있는 통합 제어 게이트웨이 시스템, 텔레매틱스 시스템과 연계된 차량 전자장치 제어 기술 등에 이르기까지 다양한 기술들이 연구되고 있다.이러한 기술들에는 센서와 제어기 및 구동기로 구분되며, 제어기에는 ECU(Electronic Control Unit)라는 핵심 제어장치가 있으며, ECU에 앞서 예기한 서비스들이 설계되고 실제 ECU에 기록되어 지능형자동차 서비스가 된다.OSEK/VDX초기 ECU들은 펌웨어라고 하는 하드웨어에 의존적인 코드 개발을 통하여 서비스들이 개발되었다. 하드웨어 의존적인 개발은 개발기간의 장기화 및 재사용성의 어려움 및 통일된 플랫폼으로 진행하기 어려웠다. 따라서 자동차 업계에서는 자동차용 ECU 장치에 적합한 운영체제에 대한 요구가 증가되었다.OSEK/VDX는 자동차용 임베디드 시스템 표준화 문제를 해결을 하기 위해, 1993년 BMW, 다임러-벤츠, 오펠, 지멘스, 폭스바겐 등 유럽의 자동차 업체들과 모토로라가 참여하여 만든 표준화 단체이자 표준규격이다.주요 규격 구성요소로는 실시간 운영체제, 통신 프로토콜, 네트워크 관리, OSEK 구현 언어, OSEKtime OS, FTCOM(Fault Tolerant Communication)이 있다. 그림 1은 OSEK/VDX의 구성을 도식한 것이다.운영체제는 응용 프로그램에 표준화된 인터페이스를 제공함으로써 하드웨어에 독립적인 응용개발을 가능케 하며, 확장성과 안정성을 높일 수 있다. 또한 스케줄링을 통하여 여러 작업을 한 ECU에서 분산 수행할 수 있어 하드웨어 자원 활용을 극대화 할 수 있다. 기본 메커니즘은 컨트롤러에서 처리되는 프로그램의 기본 단위-태스크를 우선순위에 따라 관리하며, 태스크 간의 동기화를 위한 자원 및 이벤트 관리(Resource and Event Management), 경고(Alarm), 카운트(Counter) 그리고 오류처리(Error handling) 기능을 제공한다.통신규격 부분은 차량 네트워크에 필요한 상위 계층 표준 인터페이스와 프로토콜을 제공하며 상호작용층(interaction layer), 네트워크층(network layer), 데이터링크층(data link layer)으로 구성된다. 상호작용층은 같은 ECU에서 동작 하는 응용 간에 주고받는 메시지와 네트워크로 연결된 다른 ECU에서 동작하는 응용 간에 메시지를 주고받을 때 동일한 API를 사용하여 응용 프로그램들이 마치 같은 ECU상에서 동작하는 것처럼 보이게 만든다. 네트워크층은 상호작용층에서 받은 메시지를 데이터 링크층으로 전송하는 서비스를 제공한다. 데이터링크층에서는 상위의 네트워크층에서 사용된 통신 프로토콜에 따른 데이터를 포함한 패킷을 unacknowledged 전송 방식으로 송수신하는 서비스를 제공한다.네트워크 관리부분은 네트워크 시스템에서 통신이 올바르게 동작하는지를 감시하고 관리하는 역할을 한다. 네트워크를 관리하는 방식에는 직접 네트워크 관리(Direct network management) 및 간접 네트워크 관리(Indirect network management) 두 가지 방식이 있다. 직접 네트워크 관리 방식은 네트워크를 형성하고 있는 모든 노드들이 다른 노드에 의해 모니터링 되는 방식이다. 이를 위하여 노드들은 논리 링(Logical ring)을 구성하고 논리 링 간에 별도의 네트워크 메시지를 사용한다. 간접 네트워크 관리 방식은 네트워크 메시지를 사용하는 것이 아니라 주기적으로 전송되는 응용 메시지를 이용한다.현재 사용되고 있는 주요 상용 제품으로는 CodeWarrier IDE를 제공하는 프리스케일사의 OSEKturbo, Tornado IDE를 제공하는 윈드리버사의 OSEKWorks가 있으며, 그밖에 라이브디바이시스사의 Realogy RTA(Real-Time Architect), 윈도우 기반의 GUI를 제공하는 3소프트사의 proOSEK, 벡터사의 osCAN, 부품 모듈을 생산 판매하는 보쉬사의 CPS와 Bootloader, Mixed 선점형 스케줄링 방법을 제공하는 nucleus OSEK 등 상용제품이 있다.공개 소프트웨어 가운데는 sourceForge의 openOsek, 일본의 iTron계열의 TOPPERS/OSEK, 오픈소스 RTOS 프로젝트인 tramponline, PIC 계열에 적합한 오픈 PICos18, 레고 로봇에 적용한 LEJOS OSEK, uCos-2 기반 HSE-FreeOSEK 등 다양한 솔루션들이 나와 있다.OSEK 표준 개정작업이 안정화됨에 따라 신규 제품의 출시는 줄어든 상태이며, 이러한 OSEK 기반의 개발은 전통적인 V 프로세서에서 코드 개발 시 OSEK/VDX 기반에서 코드가 개발자에 의하여 개발되던 방식에서 점차 MBD 방식의 개발로 이어졌다. MBD 방식에서는 업체별 제공하는 MBD 툴을 이용하여 설계와 연계되어 모델을 상세화 시키고 상세화된 모델의 세부 구현부분을 전자회로 등의 모델을 통하여 세부 설계하고 이를 시뮬레이션을 통하여 전체 흐름을 검증하고 코드를 자동생성하는 방식으로 개발과정의 변천을 맛보았다.하지만 MBD 방식은 표준화가 되어 있지 않아 업체별 상호 호환성이 떨어지고, 완성차 업체와 부품조달업체 간 의사소통이 원활하지 않아 초기 요구하던 모델을 충족시키기에 많은 시간과 노력을 투자해야 했다. 또한 완성차 업체별 요구사항이 틀려 부품업체에서도 통일된 플랫폼으로 대응하기 어려운 문제점들이 대두되면서 완성차 업체중심의 AUTOSAR 표준이 형성되게 되었다.AUTOSAR 표준 동향해외 선진 자동차 업계에서는 자동차 임베디드 시스템의 기술 혁신을 위해 표준화, 개발 방법론 등의 개발을 위해 노력하고 있다. 대표적인 AUTOSAR 표준화 사례는 하드웨어와 소프트웨어의 분리를 통하여 소프트웨어의 재사용성, 확장성 등을 향상시켜 복잡한 소프트웨어를 모델 기반으로 개발할 수 있는 도구 기반의 개발 방법론과 도구 간의 인터페이스를 표준화된 XML 문서로 상호 연동할 수 있도록 하여 신규 서비스들을 빠르고 신뢰성 있게 개발할 수 있는 방법론 및 소프트웨어 플랫폼을 표준화 시켰다.AUTOSAR는 2003년 6월 자동차의 전기/전자 아키텍처에 대한 공개 표준을 제정하는 것을 목표로 유럽, 일본, 미국 등의 자동차 제조업체들과 부품 제조업체들이 공동으로 참여하는 협력체로 탄생되었다. AUTOSAR 협력체는 3단계의 회원 자격 구조로 이루어져 있으며 2008년 8월 현재 그림 2에서와 같이, 10개의 코어 파트너, 54개의 프리미엄 멤버, 78개의 관련 멤버 및 6개의 개발 멤버로 구성되어 있으며 국내에서는 현대/기아 자동차가 프리미엄 멤버로 한국전자통신연구원, 대우정밀, 만도, 대구경북과학기술연구원이 관련 멤버로 활동 중에 있다.표 1에서는 AUTOSAR 표준화 활동 이력을 보여준다. 2007년 12월 3.0 규격이 완성되었으며, 2008년 현재 지속적인 수정 작업이 진행되고 있다.그림 3에서와 같이 AUTOSAR는 현재 2단계(페이즈 2: 2007년~2009년) 규격 보완작업으로 기존 표준화된 R3.0의 지속적인 검토와 보완작업, 규격 호환성 테스트 작업, 멀티미디어와 신뢰성 검증분야 규격작업 및 지속적인 응용시스템의 표준화 등을 목표로 진행 중에 있으며, 2008년 말 규격 4.0을 공개할 계획이다. 또한 이와 더불어 3단계 작업(페이즈 3: 2010년~ )도 계획하고 있는데 멀티미디어 분야는 특히 업체별 표준화가 지연되는 분야로서 전장 분야보다 복잡성도 크고, 또한 운영체제 등에서도 규격화가 어려운 분야로서 3단계 작업 후 표준화가 완성될 것으로 예측된다.현재 자동차 완성차 업체에서는 규격이 적용된 자동차를 시험하고 있으며, 이르면 2010년에 AUTOSAR 기술이 접목된 자동차가 시장에 출시될 예정이다. 코어 파트너 업체들은 AUTOSAR 기술이 적용된 자동차를 출시할 계획을 갖고 있으며, 이에 따라 부품 협력업체들의 부품 모듈에 AUTOSAR 소프트웨어 플랫폼이 적용될 수 있도록 유도하고 있다.AUTOSAR 구조는 크게 AUTOSAR 소프트웨어-C(Software Component), RTE(Run-Time Environment), B소프트웨어 (Basic Software) 3계층으로 나누어지며, 기본 설계는 RTE 개념을 도입하여 응용 소프트웨어-C와 하드웨어 관련 소프트웨어인 B소프트웨어를 분리함으로써, 하드웨어에 독립적인 응용 서비스를 개발할 수 있도록 하는 것이다. 그림 4에서는 AUTOSAR 소프트웨어 구조를 나타내고 있다.각 AUTOSAR 소프트웨어-C는 응용 소프트웨어 기능의 일부를 구현하며, ECU에 매핑되는 기본단위이며, 포트와 인터페이스를 통하여 상호 송수신할 신호와 데이터를 정의하고 정의된 규격에 따라 태스크들의 동작으로 메시지들을 교환한다. 센서/액추에이터 소프트웨어-C는 AUTOSAR 소프트웨어-C의 한 종류로써 ECU의 센서 및 액추에이터의 구현을 위한 소프트웨어-C이다. RTE는 각 소프트웨어-C 사이 및 소프트웨어-C와 B소프트웨어 사이의 정보 교환을 위한 중추적인 역할을 하며 소프트웨어와 하드웨어를 분리시키는 핵심역할을 한다. RTE는 하부의 많은 서비스 계층의 컴포넌트들을 추상화하여 RTE_ 형태의 API들을 제공해 향후 ECU 보드가 바뀌더라도 상위 제작된 소프트웨어 컴포넌트 수정 변경 없이 사용할 수 있도록 가상 버스 개념을 접목하고 있다.B 소프트웨어의 표준 계층으로 서비스 계층, EAL(ECU Abst- raction Layer), MCAL(Microcontroller Abstraction Layer) 그리고 CDD(Complex Device Driver)로 구성된다.서비스계층은 OS, 네트워크, 메모리, 검증, ECU 상태관리 등의 서비스 기능을 수행한다. EAL은 ECU 내부의 장치들과 인터페이스를 제공하며, ECU에 독립적인 상위계층의 설계를 제공한다. MCAL은 상위 계층에서 마이크로컨트롤러의 레지스터를 직접 조작하는 것을 피하게 해주며 디지털 입출력, 아날로그 디지털 변환, 파형변환, 직병렬 변환 등으로 구성된다.이러한 계층화에 반하여 기존 동작중인 안정화된 장치들을 AUTOSAR 플랫폼과 호환성을 가지고 동작될 수 있도록 CDD(Complex Device Driver)라는 개념으로 수용하고 있다. 특히 MOST(Media Oriented System Transport) 등의 경우 해외 MOST 칩 밴더나 소프트웨어 개발 툴킷들을 제공하는 업체들을 중심으로 안정된 장치 드라이버를 사용할 수 있도록 CDD 형태로 접목시킬 수 있으며, 또한 이더넷과 같은 장치들도 필요시 CDD를 제작하여 AUTOSAR 인터페이스를 제공한다면 RTE 하부에 동작시킬 수 있다. AUTOSAR에서는 CDD를 제공함으로 기존에 안정적으로 동작되던 장치들의 최소한의 수정으로 서비스를 지속할 수 있도록 Backward Compatibility를 제공하려고 노력하고 있다.그림 5에서는 AUTOSAR WP(Work package) 1에서 표준화되고 있는 도구별 상호 운용성을 제공할 수 있는 전장 응용 서비스의 개발 방법론을 보여주고 있다. AUTOSAR 소프트웨어 개발은 시스템 설정단계와 ECU 설정단계로 나누어진다. 시스템 설정단계에서는 소프트웨어-C의 데이터 타입, 인터페이스와 연결 상태 등을 기술하는 소프트웨어-C 명세서(Component Description), 각 ECU의 하드웨어 구성을 기술하는 ECU 자원명세서(Resource Description), 그리고 버스 시그널, 토폴로지 등 시스템 제약명세서(Constraint Description)를 작성한다.각 소프트웨어-C 내부에는 응용 소프트웨어 구현을 위한 태스크 동작정의 및 트리거 조건을 정의한다. 다음은 소프트웨어-C를 각 ECU에 매핑하고 네트워크 설계를 하여 시스템 설계명세서(System Configuration Description)를 기술한다. 작성된 파일은 XML 형식의 템플릿을 사용하며 XML을 사용함으로써 데이터의 공유 및 전달을 표준화 할 수 있다.다음 단계는 시스템 설계명세서로부터 각 ECU 정보를 추출하여 ECU 설계를 하며 태스크 정의 및 할당, RTE 생성, B소프트웨어 등을 설계하여 ECU 설계 명세서(Configuration Descrip- tion)를 기술한다. 응용 소프트웨어와 함께 RTE, OS, Commu- nication 등의 AUTOSAR 소프트웨어 모듈 코드를 생성하고 컴파일, 링크를 거쳐 실행 파일을 만들어 ECU 응용서비스를 구현한다. 구현된 동작 가능한 결과물은 설계된 ECU에 올려 시험할 수 있다.전장 소프트웨어의 신뢰성과 안정성소프트웨어 품질 모델자동차를 포함하여 항공, 원자력발전소, 의료, 기차 등 사람의 생명과 직결되는 안전 결정적(safety-critical) 시스템에서 필연적으로 다루는 소프트웨어 안정성과 신뢰성을 올바로 이해하기 위해서는 소프트웨어 품질에 대한 기본 개념을 이해해야 한다. 그림 6은 소프트웨어 개발 전 생명주기에 걸친 품질 모델 프레임워크를 도식한 것이다.소프트웨어가 사용되는 시점에 요구되는 품질(quality in use)은 소프트웨어 제품의 내적(internal) 및 외적(external) 품질 특성(attribute)에 영향을 받으며, 소프트웨어 제품의 내적, 외적 품질 특성은 근본적으로 소프트웨어를 생산하는 프로세스의 품질에 좌우된다[14].전통적 제조 산업 분야에서 초창기 제품의 생산성 향상과 제품의 품질 제고를 위해 제품 자체의 품질을 관리하던 추세에서 TQM(Total Quality Management)이나 품질 관리 시스템(ISO 9000)와 같은 프로세스 품질 관리로 패러다임이 전환되는 것이나, CMMI나 SPICE(ISO 15504) 등과 같은 프로세스 평가 기법이 광범위하게 활용되는 것은 그러한 관점에서 접근한 좋은 예이다.소프트웨어 관점의 안정성과 신뢰성의 관계안정성(safety)이란, 소프트웨어가 사용되는 특정한 상황(context)에서 사람, 비즈니스, 소프트웨어, 자산 (property) 혹은 환경에 대한 위해(harm)로부터 감수할만한 위험(risk) 수준을 유지하는 소프트웨어 제품의 능력(capability)이며, 위험이란 보통 소프트웨어 기능, 신뢰성, 사용편의성 및 유지보수성의 결핍으로부터 파생되는 결과이다.신뢰성(reliability) 이란, 소프트웨어를 특정 조건에서 사용할 때 일정 수준의 성능(performance)을 유지하는 능력이며, 소프트웨어 신뢰성 문제는 일반적으로 요구사항, 설계, 구현 등의 결함(faults)에 기인한다[14].자동차와 같은 안전 결정적 시스템에서 요구되는 안전성은 효과성(effectiveness), 생산성(productivity) 및 만족성(satisfaction)과 함께 사용자 관점에서 요구되는 소프트웨어 4대 품질(quality in use) 중 하나이며, 신뢰성은 소프트웨어 제품의 6대 내적 및 외적 품질 특성기능성(functionality), 신뢰성(reliability), 사용편의성(usability), 효율성(efficiency), 유지보수성(maintainability), 이식성(portability) - 중 하나이다.궁극적으로 자동차와 같은 안정 결정적 시스템이 추구하는 안정성은, 다른 5가지 소프트웨어의 내외적 품질 특성과 함께 목적하는 소프트웨어의 요구사항분석, 시스템설계, 구현 등 일련의 생산 과정에서 발생할 수 있는 결함을 최소화하여 신뢰성을 최대한 확보함으로써, 사용(혹은 운용) 시점에 사용자가 수용할 수 있는 일정 수준의 위험을 감내하는 소프트웨어 능력을 확보하는 것이다.소프트웨어의 안전성은 그림 6에서와 같이 신뢰성에 종속되며 자동차 안정성 제고를 할 때, 단순히 자동차 성능 시험 문제로 해결하거나 안정성을 위해 HIL(Hardware in Loop) 시험하는 것은 근본적인 문제 해결 대책이 될 수 없다. 시험은 본질적으로 자동차 안정성에 문제(failure)가 있음을 드러내는 것에 불과하며, 근본적인 원인(cause of failure)인 결함 자체를 드러내는 것은 아니기 때문이다.즉, 자동차 전장 소프트웨어 신뢰성을 고려 않고 안정성 확보는 어려운 것이며, 전장 소프트웨어의 신뢰성 제고는 근본적으로 소프트웨어 생산과 관련된 일련의 과정(요구사항분석, 설계, 구현 등) 개선 없이는 불가능하다. 해외 자동차 분야에서 활발히 진행되고 있는 안정성과 신뢰성 제고를 위한 다양한 연구개발과 표준화 노력은 동일한 맥락에서 접근해야 한다.전장 소프트웨어의 안전성과 신뢰성 확보 노력소프트웨어 품질 모델에 근거한 안정성과 신뢰성의 관계 관점에서 보면, AUTOSAR는 단순한 전장 소프트웨어 플랫폼 표준화 이상의 의미이다. 즉, 전장 하드웨어와 소프트웨어 분리를 통하여 소프트웨어 재사용성과 확장성을 높이고, 복잡해지는 전장소프트웨어를 보다 빠르고 신뢰성 있게 개발하려는 AUTOSAR 소프트웨어 플랫폼은 품질 프레임워크 관점에서 소프트웨어 내적/외적 품질 특성인 효율성, 유지보수성, 이식성 및 신뢰성 등을 제고하기 위한 노력으로 이해할 수 있다.또한, AUTOSAR는 AUTOSAR 규격 시험(Conformance Testing) 표준화를 통해 향후 시장에 출시될 AUTOSAR 플랫폼 기반 전장 소프트웨어(엄밀히 말해 AUTOSAR B소프트웨어)의 규격 일치 여부 판정 기준이 되는 시험 명세, 시험 데이터 생성 및 시험 프로세스를 명시함으로써 보다 구체적이고 실질적인 전장 소프트웨어의 신뢰성과 안정성 확보를 위한 기능 시험 가이드라인을 제시한다.앞서 살펴 본 ISO/IEC 9126의 포괄적인 안정성 정의는 자동차와 같은 전기전자적인 시스템에 관련해서 안정성에 대해 보다 구체적으로 정의하고 있는데, 전기전자적 안정성 관련 시스템과 관련된 안정성이란 재물이나 환경에 대한 피해의 결과로, 직간접적으로 야기되는 사람 건강에 대한 피해 혹은 물리적 상해에 대해 수용할 수 없는 수준의 위험이 없는 것이라고 정의하며, 인간의 안전성을 확보하기 위해 시스템은 반드시 안정 보장 기능(functional safety)을 마련해야 한다고 명시하고 있다[15].AUTOSAR에서 정의하는 6가지 자동차 도메인 기능-파워트레인, 바디와 편의, 섀시, HMI(Human-Machine Interface), MM/T(Multi-Media & Telematics) 및 안전-중 안전이란, 사람의 안전을 보장하기 위한 시스템적 안전 기능(functional safety)을 의미하며, 그 안전의 수준은 IEC 61508 표준에 근거하여 AUTOSAR 소프트웨어 플랫폼 기반 소프트웨어 컴포넌트 개발 프로세스의 SIL(Safety Integrity Level)-3 호환성을 명시하고 있다[16].SIL이란, 기능적 안정성 보장수준이며 안정성이 보장되어야 하는 시스템의 신뢰성 수준에 대한 통계적 기준이다. 즉, 안정성 보장이 요구되는 시스템을 운영할 때 발생한 재앙의 발생 건수가 일정 기준 시간 이상 되어야 함을 의미한다. AUTOSAR 기본 요구사항으로서 요구되는 안정성 수준인 SIL-3은 AUTOSAR 기본 요구사항에서처럼 발생 가능성(LoC: Likelihood of Occurrence per operational hour)이 1*10-9 < LoC < 1*10-7 범위 안에 있어야 한다(AUTOSAR 기본 요구사항에서는 실패비율이 시간당 10-8 이하여야 한다고 명시하고 있다[16]). IEC-61508은 그러한 SIL에 대한 4가지 등급별 기준과 각 기준별 달성해야 할 요구사항을 기술하고 있다[15].IEC 61508 안전 표준은 자동차를 비롯한 항공, 원자력발전 시스템, 기차, 의료 등 안정성 결정적 시스템에서 기본적으로 준용하는 가장 포괄적인 표준이며, 각 도메인에서는 IEC-61508 표준을 근간으로 각 도메인에 최적화된 형태의 특화된 안정성 평가 모델을 제시하고 적용하고 있다.항공분야 시스템 안정성 평가 표준으로서 미국 RTCA(Radio Technical Commission for Aeronautics)와 유럽연합 EUROCAE (European Organization for Civil Aviation Equipment)가 개발하고 각각 FAA(Federal Advisory Committee)와 EASA (European Aviation Safety Agency)가 채택한 DO-178B/ED-12B나 원자력 발전소 설비 제어 시스템 안정성에 관한 국제 표준인 IEC 61504는 IEC 61508을 프레임워크로 각 도메인에 특화된 안정성 평가 모델의 대표적인 사례이다.AUTOSAR에서는 자동차용 전장소프트웨어 개발 언어로서 C, C++ 및 Java를 명시하고 있지만 대부분의 전장소프트웨어는 안정성 검증이 상대적으로 수월한 C로 개발하는 것이 일반적이다. C 코드의 신뢰성 보장 방안으로 가장 널리 알려진 기준은 MISRA (Motor Industry Software Reliability Association)로 C 언어의 사용이 규칙이고, 자동차 전장 제어용 소프트웨어의 안정성 보장을 위한 기본 규칙이다. 하지만 ECU의 기능이 복잡해지고 분산 처리가 요구되면서 소프트웨어 기능 또한 비례적으로 복잡해졌고, 수십만 라인에 이르는 전장소프트웨어를 단순히 코드 수준에서 검증하는 것만으로 자동차의 안정성과 신뢰성을 보장하기 어려워졌다.이러한 문제에 대응하기 위해 AUTOSAR에서는 FMEA(Failure Mode & Effects Analysis) 호환성을 요구하고 있다[16]. FMEA는 원래 하드웨어 분야에서 기계적인 운영 실패 모드와 그 효과에 대한 정적 분석 기법(IEC 60812)으로 널리 활용되었으나, 최근 소프트웨어 분야의 모델 수준에서 FMEA 기법을 도입하여 적용하고 체계화 하려는 움직임을 보이고 있다.기타, AUTOSAR 표준화 그룹과 별도로 주목할 만한 표준 기술로서 SPICE 사용자 그룹을 중심으로 한 자동차SIG (Special Interest Group)에서 제정하고 자동차 완성차 업체의 합의로 만든 오토모티브 SPICE가 있는데, 이는 SPICE라는 범용적인 소프트웨어 혹은 시스템 프로세스 평가 모델을 자동차 도메인 관점에서 재해석한 전장소프트웨어 개발 프로세스 평가 모델이다.그리고 미국 카네기멜론 대학의 소프트웨어 공학연구소에서 시작된 SPIN(Software and Systems Process Improvement Networks)는 소프트웨어와 시스템에 관련된 노하우들을 인적 네트워크를 통하여 전달하고 상호 교류를 통하여 프로세스 개선 노력을 기울이기 위한 단체로서 현재 120여개 이상의 지역단체들이 활동하고 있다. 특히 독일과 이탈리아 등의 오토모티브 SPIN은 자동차 전자장치에 적용되는 소프트웨어들을 공학적으로 접근하고 이를 널리 전파하고자 상호 협력하고 있다.국내에서도 SPIN 네트워크가 형성되어 있지만 아직 포괄적으로 활동을 하고 있지는 않다. 하지만 향후 AUTOSAR와 관련된 국내 기업과 단체들을 연합하여 오토모티브 SPIN을 형성할 필요성을 느낄 때가 다가왔다.결 론차량 탑승자의 편의와 안전을 제공하기 위한 다각도의 노력으로 국내에서 생산되는 차량들의 편의성과 안정성은 해외 유수 자동차 업체와 비교해도 뒤지지 않는 수준에 이르렀다. 또한 정부 주도로 이루어지는 미래 자동차의 로드맵과 연구 추진으로 미래 무인자동차와 자동화는 점차 현실로 다가오는 듯하다. 편의/안전 서비스의 증가는 전자장치의 모듈화를 가속화시켰고 전자 장치별 상호 연동을 통한 네트워킹 또한 증가 되었다. 복잡성의 증가와 소프트웨어 적용 빈도가 높아지면서 모델 기반 개발방법 등 소프트웨어의 공학적 접근법이 조심스럽게 추진되고 있으며, 이러한 조류와 더불어 사용빈도가 높아지는 자동차용 운영체제와 AUTOSAR 소프트웨어 플랫폼의 표준화는 가시적인 성과를 거두고 있다.미래는 AUTOSAR와 같은 통일된 소프트웨어 플랫폼을 적용하는 부품 모듈들의 조립에 의한 자동차 모델 개발이 가능하게 되며, 재사용성의 증가로 신차모델의 개발기간 단축과 안정성이 보장되는 부품모델의 제공으로 서비스 신뢰성 향상을 기대한다. 또한 신뢰성을 제공하는 소프트웨어 플랫폼은 자유로운 부가서비스 개발로 이어져 항상 변화하는 지능형 자동차 모습을 앞당길 것으로 예측된다.이와 더불어 국내 전장 업체와 완성차 업체 및 IT 업체들은 오토모티브 SPIN등을 통해 배우고 익힌 지식을 사회 전반에 적용할 수 있도록 상호 협력과 개방을 통해 윈윈 전략을 수립해야 할 것이다.참조 문헌>>[1] 유우석, 박지용, 홍성수,"분산형 실시간 차량제어 시스템을 위한 RTOS, 미들웨어 및 결함 허용성 요소기술 연구,"2006.[2] 장승주, "자동차용 임베디드 소프트웨어 기술동향," 주간기술동향, 2006.12.[3] 장승주, 권오훈,"자동차용 임베디드 운영체제 기술 동향," 주간기술동향, 2007.08.[4] 최상원, 선원웅, " 자동차 전장기술의 동향과 전망," 한국자동차산업연구소 연구보고서 2005-19, 2005.12.[5] Frost & Sullivan, "Strategic Analysis of the European Market for Software in Passenger Cars," M03B-26, 2007.10 (http://www.frost.com)[6] AUTOSAR Technical Overview 3.0, AUTOSAR, Dec. 2007.( http://www.autosar.org)[7] Hladik, P.-E. et al, "Adequacy between AUTOSAR OS specification and real-time scheduling theory,"SIES`07. Jul. 2007.[8] Lars-Berno Fredriksson,"CAN for Critical Embedded Automotive Networks," IEEE Micro. Vol. 22, No. 4, Jul. 2002.[9] Ingo Sturmer, et al,"Systematic Testing of Model-Based Code Generators," IEEE Trans on Software Engineering, Vol. 33, No. 9, Sep. 2007.[10] OSEK, OSEK/VDK Operating System Specification 2.2.3, 2005. 2. (http://www.osek-vdx.org)[11] 나지하, 권기선, "비IT 분야 임베디드 소프트웨어 기술융합 동향,"2007.06.[12] ISO/IEC 9126-1: Software engineering-Product quality-Part1 : Quality model[13] IEC 61508: Functional safety of E/E/PE safety-related systems[14] AUTOSAR Main Requirements 3.0, AUTOSAR, Dec. 2007.[15] AUTOSAR Layered Software Architecture, AUTOSAR, Dec. 2007.[16] MOST Specification, Dec. 2006, http://www.mostcooperation.com/[17] SPIN, http://www.sei.cmu.edu/collaborating/spins/index.html

회원가입 후 이용바랍니다.

개의 댓글

회원로그인

작성자 비밀번호

댓글 내용입력

댓글 정렬

최신순 추천순 답글순

BEST댓글

BEST 댓글 답글과 추천수를 합산하여 자동으로 노출됩니다. 닫기

더보기

김의겸 (webmaster@techworld.co.kr)

기자의 다른기사 보기

저작권자 © 테크월드뉴스 무단전재 및 재배포 금지