자동차전자제어장치용소프트웨어기술및표준화동향 Technology Trends in Automotive Electronic Control Units IT 융합기술의미래전망특집 한태만 (T.M. Han) 조진희 (J.H. Cho) 자동차융합플랫폼연구팀팀장자동차융합플랫폼연구팀책임연구원 목차 Ⅰ. 서론 Ⅱ. 자동차전장소프트웨어의고도화 Ⅲ. 자동차전장소프트웨어의안전성 Ⅳ. 결론 과거단순한이동수단이목적이었던자동차는더욱안전하고편리한자동차, 서비스지향자동차로거듭나고있다. 점차편리와안전서비스를제공하기위한전자제어장치의장착이확대되고전자제어장치간의연동을통한서비스개발이늘고있으며, 이로인해신뢰성및안전성이슈가최근에많이대두되고있다. 본고에서는자동차응용서비스의개발에서 IT 기술들의집합체라고할수있는전자장치용소프트웨어의표준플랫폼인 의동향과차량전자제어장치의안전성보장을위한 ISO 26262 표준동향및이슈를살펴본다. C 2010 한국전자통신연구원 69
Ⅰ. 서론 21세기들어자동차는단순한이동수단으로부터섀시프레임의개별제어, 통합제어및자율주행제어로이어져차량탑승자의안전을제공하며편리한새로운기능들이추가되고있다. 자동차산업은 1990년대부품모듈의개별제어수준에서점차통합모듈제어방식으로진화되고있으며, 외관과디자인위주에서점차편의성이나안전등의서비스개발로추진되고있다. 미래지능형자동차는편의와안전등의서비스들이더욱발달할것으로전망되며, 향후차량의 80% 이상의혁신은전기전자시스템을기반으로할것이다 [1]-[4]. 산업발전에비춰볼때, 자동차를생산하는완성차업체들은공통부품모듈을다양한차량모델에적용하고자하고, 부품개발업체입장에서는다양한완성차업체에유사한부품모듈납품으로제조원가를낮추려고하는것은지극히자연스러운현상이다 [5]. 이러한일련의공통모듈재사용성이나차량별부품호환성등의문제를해결하고자전세계완성차업체, 부품공급회사및 IT 기술업체들이협력하여자동차전장소프트웨어의재사용성과안전성및응용소프트웨어의하드웨어의존성제거등을목표로전장소프트웨어플랫폼 표준화를진행하고있다 [6]. 에서는자동차도메인을바디, 섀시, 파워트레인, HMI, 멀티미디어 / 텔레매틱스및안전분야로나누고각워크패키지별로표준화를단계에따라 Phase 1, 2, 3로나누어진행중에있다 [7]. 또한기존에파워트레인, 섀시, 바디등도메인별독립적으로개발되고시험되던기능들이향상된기능을위해융합되면서 ( 예, 자동항법장치, 차체자세제어시스템등 ) 기존의수동안전기능 ( 예, 에어백, 충돌등 ) 중심의개별적이고단편적기능안전보장접근방식 ( 형식승인 ) 에서차량의개발초기단계부터폐기에이르는전생명주기에걸친체계적이고포괄적인기능안전보장이요구된다. 이에기존안전산 업분야 ( 철도, 항공, 원자력, 화학공정등 ) 에적용하던기능안전성 (functional safety) 개념을자동차분야에도입하여 ISO 26262 표준을개발하고있으며 2011년중반에정식제정될예정이지만, 이미선진업체에서는이를적용하고있다 [8]. 다음두장을통해서자동차전장소프트웨어의표준플랫폼인 와차량기능안전성표준 ISO 26262에대한동향과주요이슈를살펴본다. Ⅱ. 자동차전장소프트웨어의고도화 1. 자동차전자제어장치의변화 자동차의모습이점차지능형자동차로발전하게됨에따라차량내전자제어장치의적용비중이높아졌다. 차량안전분야에서는자동차의사고방지를위해안전벨트나에어백장착및범퍼등의완충장치장착등수동적인안전을제공하는수준에서점차제동의미끄럼방지를위한 ABS, 가속미끄럼방지용 TCS, 그리고조향안전을제공하는 ESP/ESC 등의능동적안전장치들이현재차량에장착이되어탑승자의안전성을높여주고있다. 또한운전자의편의를높여줄수있는다양한바디제어제품들이차량에장착되고있으며, 차내멀티미디어장치들을연결하여탑승자의멀티미디어정보들을통합ㆍ제어할수있는기술들, 차량후방안전확보를위한후방카메라시스템, 앞차와의거리에따라속도를자율조절할수있는 SCC 및자율주차를제공할수있는 APS 등을장착한차량들이출시되어판매되고있다. 미래지능형자동차를위하여연구되고있는분야로는바디통합제어를위한 BCM, 종축및횡축의특성을종합할수있는섀시통합제어모듈, 기존 IT 분야에서개발되었던 ad-hoc 통신기술및센터통신기술등의다양한통신기술들을차량과접목시키는차간통신기술 (VMC) 들이개발되고있으며, 차선이탈을경보하는 LKS, 사각지대장애물인식 70 C 2010 한국전자통신연구원 70
한태만외 / 자동차전자제어장치용소프트웨어기술및표준화동향 시스템, 야간장애물을초음파등을통해시각화시켜알려주는기술, 차량내ㆍ외부정보를통합제어할수있는통합제어게이트웨이시스템, 텔레매틱스시스템과연계된차량전자장치제어기술등의다양한기술들이연구되고있다. 이러한기술들에는센서와제어기및구동기로구분되고, 제어기에는 ECU라는핵심제어장치가있으며, ECU에앞서얘기한서비스들이설계되고실제 ECU에기록되어지능형자동차서비스가실현된다. 2. 표준배경및동향해외선진자동차업계에서는자동차임베디드시스템의기술혁신을위해표준플랫폼및개발방법론의구축을위해노력하고있다. 대표적인사례가 표준화이다. 는하드웨어와소프트웨어의분리를통하여소프트웨어의재사용성및확장성의향상을도모한다. 또한복잡한소프트웨어를모델기반으로개발할수있는도구기반의개발방법론과도구간의인터페이스를표준화된 XML 문서로상호연동할수있도록하여, 신규서비스들을빠르고신뢰성있게개발할수있는방법론과소프트웨어플랫폼을표준화시켰다. 는 2003년 6월자동차의전기 / 전자아키텍처에대한공개표준제정을목표로유럽, 일본, 미국등의자동차제조업체들과부품제조업체들이공동으로참여하는협력체로탄생되었다. 협력체는 3단계의회원자격구조로이루어져있으며, 2009년 10월현재 ( 그림 1) 에서와같이, 9개의코어파트너, 57개의프리미엄멤버, 86개의관련멤버및 10개의개발멤버로구성되어있다. 국내는현대기아자동차, 한국전자통신연구원이프리미엄멤버로, 대성전기, 대우정밀, 만도, 대구경북과학기술연구원이관련멤버로활동중이다. < 표 1> 에서는 표준화활동이력을보여준다. 2003년 가결성된이후지속적으로표준을제정ㆍ갱신하고있다. 앞서언급했던바와같이표준화는자동차도메인 -Core Partners and Members Status: 22nd October 2009 9 Core Partner 57 Premium Member General OEM < 자료 >: Up-to-date status see: http://www.autosar.org 연도 2002. 8. 2003. 7. Generic Tier 1 Standard Tools and Services ( 그림 1) 주요회원사 < 표 1> 표준활동 활동 10 Development Member Semiconductors BMW, Bosch, Continental, DaimlerChrysler and Volkswagen 의 Initial Discussion BMW Group, DaimlerChrysler, Bosch, Volkswagen, Continental, Siemens VDO 초기코어멤버결성 2003. 11. Ford Motor 추가코어멤버참여 2003. 12. Toyota, Peugeot 코어멤버참여 2004. 10. 개념정립 2004. 11. GM 코어멤버참여 2005. 6. Release 1.0 배포 (23 개소프트웨어컴포넌트 ) 2006. 5. Release 2.0 배포 (42 개컴포넌트완성 ) 2007. 12. Release 3.0 배포 (2008-02 Rev-002 완성 ) 2009.12. Release 4.0 배포 별로단계적으로진행중에있다. ( 그림 2) 에서와같이 는 Phase 2(2007~2009년 ) 규격화작업을완료하고규격 4.0을공개했다. 또한 Phase 3(2010~2012년 ) 을시작했는데멀티코어프로세서의지원, 기능안전성을위한기능추가가주요이슈이다. 현재자동차완성차업체에서는규격이적용된자동차를적용하고있으며, 선두주자인 BMW가 2006 년에시험적용한이후, ( 그림 3) 에서보듯이 AUTO- SAR의 9개핵심멤버들은자사의차량에 2012년까지단계적으로 플랫폼을적용하기로공표했다. C 2010 한국전자통신연구원 71
Phase Ⅱ(2007~2009) Specification R3.0 Finalizat. Basic & RTE Maintain R3.0 Specifications Concepts R4.0 Specification R4.0 Improvements R4.0 Specifications Maint. R4.0 CT Pilot Conformance Test Specifications R4.0 Maintain CTS Validator 2 Validation R4.0(BSW/RTE + Methodology) Methodology and Templates Methodology & Templates R3.0 Finalizat. Methodology & Templates R4.0 Improvements R4.0 Maint. R4.0 Application s Specification Appl. s R3.0 Finalizat. Specification Application s R4.0 Maint. R4.0 Milestones 28.09.07 30.11.07 12.12.08 24.07.09 25.09.09 Specification 3.0 Ready Full Release 3.0 Specification 4.0 Ready Validation & CT 4.0 Full Release 4.0 1H 2007 2H 2007 1H 2008 2H 2008 1H 2009 2H 2009 2007 2008 2009 ( 그림 2) Phase 2 일정 Core Partner 2008 년 2009 년 2010 년 2011 년 2012 년 re 10 BSW modules as part of Std Core in vehicles, tool/serial support in place Body Computer with subset of specs incorporated Instrument Cluster with subset of specs incorporated ACC ECU using architecture Powertrain EDC/ME(D) 17 ECUs using architecture Domain Control Unit using BSW Body ECU using architecture Powertrain ECUs using architecture Chassis ECU using architecture Body Computer using architecture Powertrain-, Chassis- ECU using architecture First First usage of AUTOcompatible ECUs in SAR modules in vehicles vehicles 1-2 conformant ECUs first use of conformant tools/methodology Continuous roll-out of ECUs into vehicle architecture increased use of conformant tools/methodology First usage of modules Powertrain-, Chassis-, Safety-, Body-ECUs use architecture Introduction of architecture and methododology in vehicles First usage of architecture ECU Powertrain ECU using architecture First modules in series production Body ECU using architecture First usage of modules First complete ECUs in series production architecture ECU ( 그림 3) 핵심멤버의 적용계획 72 C 2010 한국전자통신연구원 72
한태만외 / 자동차전자제어장치용소프트웨어기술및표준화동향 3. 소프트웨어개발 구조는크게 SW-C, RTE, BSW의 3계층으로나누어지며, 기본설계는 RTE 개념을도입하여응용 SW-C 와하드웨어관련소프트웨어인 BSW를분리함으로써, 하드웨어에독립적인응용서비스를개발할수있도록하는것이다. ( 그림 4) 에서는 소프트웨어아키텍처를보여주고있다. 각 SW-C는응용소프트웨어인기능의일부를구현하고, ECU에매핑되는기본단위이며, 포트와인터페이스를통해상호송수신할신호와데이터를정의하고정의된규격에따라태스크들의동작으로메시지들을교환한다. Sensor/Actuator SW-C는 SW-C의한종류로써 ECU의센서및액추에이터의구현을위한 SW-C 이다. RTE는각 SW-C 사이및 SW-C와 BSW 사이의정보교환을위한중추적인역할을하며소프트웨어와하드웨어를분리시키는핵심역할을한다. RTE는하부많은서비스계층의컴포넌트들을추상화하여 API들을제공하여향후에 ECU 보드가바뀌더라도상위제작된소프트웨어컴포넌트수정변 경없이사용할수있도록가상버스개념을접목하고있다. BSW의표준계층으로는 Service Layer, EAL, MCAL 그리고 CDD로구성된다 [9]. 서비스계층은 OS, 네트워크, 메모리, 검증, ECU 상태관리등의서비스기능을수행한다. EAL은 ECU 내부의장치들과의인터페이스를제공하며, ECU에독립적인상위계층의설계를제공한다. MCAL은상위계층에서마이크로컨트롤러의레지스터를직접조작하는것을피하게해주며, 디지털입출력, 아날로그디지털변환, 파형변환, 직ㆍ병렬변환등으로구성된다. 이러한계층화에반하여기존동작중인안정화된장치들을 플랫폼과호환성을가지고동작될수있도록 CDD라는개념으로수용하고있다. 특히 MOST 등의경우, 해외 MOST 칩벤더나소프트웨어개발툴킷들을제공하는업체들을중심으로안정된장치드라이버를사용할수있도록 CDD 형태로접목시킬수있으며, 또한이더넷과같은장치들도필요시 CDD를제작하여 인터페이스를제공한다면 RTE 하부에동작시킬수있다. 에서는 CDD를제공하므로기존에안정 Component Different Kinds of s Application Component Actuator Component Sensor Component Application Component ECU Firmware Runtime Environment(RTE) Standard API 2 VFB & RTE Relevant API 1 RTE Relevant API 0 API 3 Private s inside Basic Possible Operating System Services Basic Communication ECU-Hardware ECU Abstraction Microcontroller Abstraction Complex Device Drivers ( 그림 4) 소프트웨어아키텍처 C 2010 한국전자통신연구원 73
Act Methodology Overview.XML System Configure Configuration System Input: System.XML System Extract Configuration ECU-Specific Description: Information System.XML ECU Extract of System Configuration: System.XML Configure ECU ECU Configuration Description ( 그림 5) 표준개발방법론 Generate Executable.exe ECU Executable 적으로동작되던장치들을최소한의수정으로지속적으로서비스할수있도록 backward compatibility를제공하려고노력하고있다. ( 그림 5) 에서는 WP 1에서표준화되고있는도구별상호운용성을제공할수있는전장응용서비스의개발방법론을보여주고있다. 소프트웨어개발은시스템설정단계와 ECU 설정단계로나누어진다. 시스템설정단계에서는 SW-C의데이터타입, 인터페이스와연결상태등을기술하는 SW-C 명세서 (component description), 각 ECU의하드웨어구성을기술하는 ECU 자원명세서 (resource description), 그리고버스시그널, 토폴로지등시스템제약명세서 (constraint description) 를작성한다. 각 SW-C 내부에는응용소프트웨어구현을위한태스크동작정의및트리거조건을정의한다. 다음은 SW-C 를각 ECU에매핑하고네트워크설계를하여시스템설계명세서 (system configuration description) 를기술한다. 작성된파일은 XML 형식의템플릿을사용하며, XML을사용함으로써데이터의공유및전달을표준화할수있다. 다음단계는시스템설계명세서로부터각 ECU 정보를추출하여 ECU 설정을하며, 태스크정의및 할당, RTE 생성, BSW 설정을통해 ECU 설계명세서 (configuration description) 를기술한다. 응용소프트웨어와함께 RTE, OS, Communication 등의 소프트웨어모듈코드를생성하고, 컴파일, 링크를거쳐실행파일을만들어 ECU 응용서비스를구현한다. 구현된동작가능한결과물은설정된 ECU에올려시험할수있다. Ⅲ. 자동차전장소프트웨어의안전성 1. 의안전성확보노력 자동차의안전성확보라는관점에서보면 AUTO- SAR는단순한전장소프트웨어플랫폼표준화이상의의미이다. 즉, 전장하드웨어와소프트웨어분리를통하여소프트웨어재사용성과확장성을높이고, 복잡해지는전장소프트웨어를보다빠르고신뢰성있게개발하려는 소프트웨어플랫폼은품질관점에서소프트웨어내적 / 외적품질특성인효율성, 유지보수성, 이식성및신뢰성등을제고하기위한노력으로이해할수있다. 또한, 는규격적합성시험 (conformance testing) 표준화를통해향후 플랫폼기반으로시장에출시되는전장소프트웨어의규격일치여부를판정하는기준이되는시험명세, 시험데이터생성및시험프로세스를명시함으로써보다구체적이고실질적인전장소프트웨어의신뢰성과안전성확보를위한기능시험가이드라인을제시한다. 전기전자제어장치와관련하여안전성이란, 재물 (property) 이나환경에대한피해 (damage) 의결과뿐만아니라직접적으로사람의건강에대한피해나물리적상해에대해수용할수없는수준의위험이없는것이라고정의하며, 사람에대한안전성을확보하기위해시스템은반드시안전보장기능 (functional safety) 을마련해야한다고명시하고있다 [10]. 에서정의하는 6가지자동차도메인기능 파워트레인, 바디와편의, 섀시, HMI, MM/T 74 C 2010 한국전자통신연구원 74
한태만외 / 자동차전자제어장치용소프트웨어기술및표준화동향 및안전 (safety) 중안전이란, 사람의안전을보장하기위한시스템적안전기능을의미하며, 그안전의수준은 IEC 61508 표준에근거하여 소프트웨어플랫폼기반소프트웨어컴포넌트개발프로세스의 SIL-3 호환성을명시하고있다 [7],[10], [11]. SIL이란, 기능적안전성보장수준이며안전성이보장되어야하는시스템의신뢰성수준에대한통계적기준이다. 즉, 안전성보장이요구되는시스템을운영할때발생한재앙의발생건수가일정기준시간이상되어야함을의미한다. 기본요구사항으로써요구되는안전성수준인 SIL-3 은 기본요구사항에서처럼발생가능성이 10-7 < LoC < 10-6 범위안에있어야한다 ( 기본요구사항에서는실패비율이시간당 10-8 이하여야한다고명시하고있다 ). IEC 61508은그러한 SIL에대한 4 가지등급별기준과각기준별달성해야할요구사항을기술하고있다 [10]. IEC 61508 안전표준은자동차를비롯한항공, 원자력발전시스템, 기차, 의료등안전성결정적시스템에서기본적으로준용하는가장포괄적인표준이며, 각도메인에서는 IEC 61508 표준을근간으로각도메인에최적화된형태의특화된안전성평가모델을제시하고적용하고있다. 항공분야시스템안전성평가표준으로서미국의 RTCA와유럽연합의 EUROCAE가개발하고각각 FAA와 EASA가채택한 DO-178B/ED-12B나원자력발전소설비제어시스템안전성에관한국제표준인 IEC 61504- Nucreal power plants-instrumentation and control systems Important to Safety는 IEC 61508을프레임워크로각도메인에특화된안전성평가모델의대표적인사례이다. 에서는자동차용전장소프트웨어개발언어로서 C, C++ 및 Java를명시하고있지만대부분의전장소프트웨어는안전성검증이상대적으로수월한 C 언어로개발하는것이일반적이다. C 코드의신뢰성보장방안으로가장널리알려진기준은 MISRA-C 언어사용규칙이고, 자동차전장 제어용소프트웨어의안전성보장을위한기본규칙이다. 하지만 ECU의기능이복잡해지고분산처리가요구되면서소프트웨어기능또한비례적으로복잡해졌고, 수십만라인에이르는전장소프트웨어를단순히코드수준에서검증하는것만으로자동차의안전성과신뢰성을보장하기어려워졌다. 이러한문제에대응하기위해 에서는각기법들에대한 FMEA 적용가능성을요구하고있다 [11]. FMEA는원래하드웨어분야에서기계적인운영실패모드와그효과에대한정적분석기법 (IEC 60812) 으로널리활용되었으나, 최근소프트웨어분야의모델수준에서 FMEA 기법을도입하여적용하고체계화하려는움직임을보이고있다. 2. 차량기능안전성표준 ISO 26262 차량안전에관하여서는전통적으로차량의기능별로관련규정과지침및형식승인을통해차량안전보장을요구해왔으나, 최근차량이기계장치중심에서전기전자장치중심으로발전하고차량기능간통합및교류가증가하면서선진국을중심으로기존의기계장치중심의형식승인을전자장치중심으로강화한규정및지침의필요성이대두되고있다 [12]. 이에글로벌자동차기업들을중심으로기존의안전관련시스템의전기전자장치에대한기능안전표준인 IEC 61508을자동차분야에적용해본결과도출된문제점을해소하기위해자동차분야의특성을반영한새로운표준의필요성을인식하여 ISO 26262를개발중이며, 늦어도 2011년이면공포될예정이다 [13]. BMW, Daimler, GM, Bosch 등의글로벌자동차메이커및공급업체들은 ISO 26262 를자체개발프로젝트에이미도입하고있으며, 포괄적인적용을위해노력하고있다 [14],[15]. ISO 26262는차량의전기전자장치의기능안전성에관한요건을정의한표준으로서 ISO 산하기술위원회 TC22의 SC3(Road Vehicle Subcommittee), WG16(Electrical and Electronic Equipment) 에서작업중인문서이다. 2004년말부터표준제정 C 2010 한국전자통신연구원 75
움직임이시작되어 2009년 7월현재 DIS로서 ISO 회원국에배포된상태이고 2011년중순전후하여최종안이제공될것으로예상하고있다. 전기전자장치안전에관한포괄적규격으로는 IEC 61508이있는데 2000년대초반 FAKRA 를중심으로독일자동차업계에서 IEC 61508을자동차분야에적용한결과여러가지문제점이제기되었다. 일반전기전자장치안전에관한포괄적규격인 IEC 61508은제어시스템과안전메커니즘 ( 예, 1, 2, 3차보호시스템등 ) 을별개로고려하는데반해차량은기본적으로이동성을전제로하는시스템으로서제어시스템과안전메커니즘은통합되어야한다. IEC 61508은또한자동차개발생명주기와도맞지않으며, 자동차산업의특성상완성차업체 (OEM) 와부품공급업체간의전문화, 분업화된생산방식에적합하지않았다. 특히, IEC 61508은최종제품 ( 자동차 ) 을사용하는소비자관점의 안전 이아니라, 안전이보장된제품을제공해야하는공급자중심의제품 안전 에초점을맞추고있는점이가장큰문제점으로지적되었다. 이러한문제점을해결하기위해 ISO 26262에서는 IEC 61508의핵심개념인안전성보전등급 (SIL) 과하드웨어중심의안전생명주기 (safety lifecycle) 를개선하여 ASIL 과시스템중심의안전생명주기를도입하고있다. 3. ASIL 개념 ISO 26262의차량안전성보전등급 (ASIL) 이란 IEC 61508의안전성보전등급 (SIL) 개념을자동차제품특성에맞게개선한차량의안전성보전등급을말한다. IEC 61508의안전성보전등급 ( 최저 SIL 0부터최고 SIL 4) 을결정하는 2가지핵심요소는재난을야기하는위험발생확률 (probability of occurrence) 과발생가능한재난 (hazard) 결과로써안전에미칠영향의심각도 (severity of its effects) 이다 [10]. 이에반해, ISO 26262에서는안전성보전등급을재난상황에노출가능성 (probability of exposure), 위험의잠 재적심각도 (potential severity) 그리고통제가능성 (controllability) 에따라차량안전성보전등급을결정한다. 이것은자동차제품의특성을반영한것으로 ASIL은최저등급인 ASIL A부터최고등급인 ASIL D까지총 4개등급이다 [13]. < 표 2> 는 ISO DIS 26262에제시된재난의심각성 (S: 최저 S0, 최고 S3), 노출확률 (E: 최저 E0, 최고 E4) 및통제가능성 (C: 최저 C0, 최고 C3) 요소에따라 ASIL을결정하는데참조하는 ASIL 결정기준 표를보여준다 ( 표에는 ASIL 판정제외요건이되는 S0, E0, C0는표시되어있지않다 ). S1 S2 S3 Potential Risk Additional Risk Reduction Measures Standard Development < 표 2> ASIL 결정 C1 C2 C3 E1 QM QM QM E2 QM QM QM E3 QM QM A E4 QM A B E1 QM QM QM E2 QM QM A E3 QM A B E4 A B C E1 QM QM A E2 QM A B E3 A B C E4 B C D ASIL A ASIL B ASIL C ASIL D QM(Quality Management) ( 그림 6) ASILs 비교 Required Risk Reduction by the Technical Solution ASIL이높다는것은그개발대상의오류로인해사고가날경우상대적으로피해가클수있으며, 그위험을줄이기위해높은수준의안전메커니즘이필요하므로안전에대한요구사항이강력해지는것이다. ( 그림 6) 은각 ASIL별상대적인비교를보여주고있다. SIL과 ASIL 을결정하는구성요소를통해짐작할수있듯이, IEC 61508에서제시하는 SIL 결정방식이일반적인재난분석과위험심사를통한포괄적인 76 C 2010 한국전자통신연구원 76
한태만외 / 자동차전자제어장치용소프트웨어기술및표준화동향 기준이라면, ISO 26262의 ASIL 은자동차의특성을반영한것이다. 즉, 재난분석을통해식별된위험이안전에미치는심각성이높다하더라도실제그위험에노출될확률이낮거나, 설사심각한위험에대한노출확률이높다하더라도자동차운전자나보행자등자동차안전과관련된이해관계자가충분히그위험상황을통제할수있다면굳이안전메커니즘을고려하지않아도되지만, 그러려면부품공급사혹은제조사는그에상응하는충분히문서화된증거자료를제조사혹은권한을지닌기관에제출할것을명시하고있다 [13],[15]. 품목 (item) 개발프로젝트의수행자관점에서는 ASIL이높아짐에따라개발과정에서수행하는활동의엄격한정도가달라진다. 가령, 소프트웨어개발단계에서요구사항을검증하기위한기법을적용함에있어서개발대상품목이 ASIL A등급이라면워크스루 (walkthrough) 를통한비공식적검증방법을강력히권고 (highly recommended) 하며인스펙션은단순권고 (recommended) 하는수준이다. 반면에그보다높은 ASIL C등급인경우는준정형 (semiformal) 검증방법을강력히권고하며, ASIL D등급의경우정형검증방법을권고하면서 ASIL A등급에서권고하던워크스루는오히려사용하지말아야할검증방법으로정의하고있다. < 표 3> 은 ISO 26262에서 ASIL 등급별적용기법에대한예이다. < 표 3> 요구사항검증기법 ASIL Methods A B C D 1a Informal verification by walkthrough ++ + o o 1b Informal verification by inspection + ++ ++ ++ 1c Semi-formal verification a + + ++ ++ 1d Formal verification o + + + * a : Method 1c can be supported by executable models. ++: highly recommended, +: recommended, o: no recommendation 4. ISO 26262 구성 IEC 61508에서참조하는생명주기모형은 V 주기모형을기반으로하며, 하드웨어의안전요구사 항이결정된후소프트웨어 ( 전장소프트웨어 ) 의안전요구사항을추출하여접근하는전형적인하드웨어중심의시스템개발생명주기특성을띤다 [10]. 이에반해 ISO 26262는기본적으로 IEC 61508 과동일한 V 주기모형을따르고는있지만하드웨어와소프트웨어구성요소를모두고려한시스템수준에서독립적인제품개발단계 (( 그림 7) 의 4. Product development: system level) 를통해시스템을설계한후 (( 그림 7) 의 4.8 System design) 하드웨어와소프트웨어개발이독립적으로병행될수있는구조로구성되어있다. ISO 26262의파트별구성을간략히기술하면다음과같다. 1) Vocabulary 관련용어를정의함 2) Management of functional safety 기능안전성에관련된개발활동을계획, 조정, 추적하는요건을정의하며안전문화와같이조직차원에서갖추어야할것에서부터품목개발, 생산이후에걸친전반적인안전성관리요구사항을정의함 3) Concept phase - 개발품목정의를기반으로해저드분석및위험심사를통해 ASIL을판정하며, 안전목표와안전메커니즘을정의함 4) Product development: system level - 시스템수준에서의개발은기본적으로 V모델을따르며기술적요구사항과시스템디자인, 그리고테스트프로세스가통합의왼쪽부분에오고, 검증, 확인과심사가오른쪽부분에위치함. 전기전자시스템외의타기술로구현된안전메커니즘을확인 (validation), 외부수단으로구현된안전개념의효과확인, 사람의통제성및작동작업에대한전제등을검증하는것을포함함 5) Product development: hardware level 시스템설계명세를기반으로하여아이템의하드웨어개발이이루어지는데, V모델의개념에따른하드웨어의개발, 통합, 검증등에대한요구사항을정의함 C 2010 한국전자통신연구원 77
1. Vocabulary 2. Management of functional safety 2.5 Overall safety management 2.6 Safety management during development 2.7 Safety Management release for production 3. Concept phase 4. Product development: system level 7. Production and operation 3.5 Item definition 3.6 Initiation of the safety lifecycle 3.7 Hazard analysis and risk assessment 3.8 Functional safety concept 4.5 Initiation of product development at the system level 4.6 Specification of the technical safety requirements 4.7 System design 5. Product development: hardware level 5.5 Initiation of product development at the hardware level 5.6 Specification of hardware safety requirements 5.7 Hardware design 5.8 Hardware architectural metrics 5.9 Evaluation of violation of safety goals due to random hardware failures 5.10 Hardware integration and testing 4.11 Release for production 4.10 Functional safety assessment 4.9 Safety validation 4.8 Item integration and testing 6. Product development: software level 6.5 Initiation of product development at the software level 6.6 Specification of software safety requirements 6.7 architectural design 6.8 unit design and implementation 6.9 unit testing 6.10 integration and testing 6.11 Verification of software safety requirements 7.5 Production 7.6 Operation, service(maintenances and repair), and decommissioning 8.5 within distributed developments 8.6 Specification and management of safety requirements 8.7 Configuration management 8.8 Change management 8.9 Verification 8. Supporting process 8.10 Documentation 8.11 Qualification of software tools 8.12 Qualification of software components 8.13 Qualification of hardware components 8.14 Proven in use argument 9. ASIL-oriented and safety-oriented analysis 9.5 Requirements decomposition with respect to ASIL tailoring 9.7 Analysis of dependent failures 9.6 Criteria for coexistence of elements 9.8 Safety analysis 10. Guidelines on ISO 26262(informative) ( 그림 7) ISO 26262 구조 6) Product development: level 소프트웨어수준의개발에대해 V모델의개념에따라개발, 통합, 검증등에대한요구사항을정의함 7) Production and operation 품목생산을위한계획, 샘플생산, 양산, 서비스등에관한요구사항을정의함 8) Supporting process 안전요구사항의관리와명세방법, 형상관리, 변경관리, 검증, 문서화, 지원도구의자격검증 (qualification), 재사용소프트웨어의자격검증, 하드웨어의자격검증, 실제사용을통해서입증된안전성 (proven in use argument) 등에대한요구사항을정의함 9) ASIL-oriented and safety-oriented analysis 안전요구사항 ASIL 을분해하는방법, 안전관련구성요소사이의공존의조건인상호간섭의정도, 위험분석방법등을기술함 10) Guidelines on ISO 26262 주요개념, 안전케이스, ASIL 분해등 ISO 26262의이해에도움이되는정보를기술함 ISO 26262 적합성을인정받기위해서는위에서정의하는각요구사항에따라개발이되어야하며, 반드시문서화된증거자료로입증해야한다. 다음절에서는 ISO 26262를개발에적용할경우개발조직차원에서미치는영향을기술한다. 78 C 2010 한국전자통신연구원 78
한태만외 / 자동차전자제어장치용소프트웨어기술및표준화동향 5. ISO 26262 제정이국내업계에미칠영향 ISO 26262를도입한다는것은자동차산업계에큰도전이라고한다 [14]. 왜냐하면 ISO 26262 는차량의개발초기에서부터생산, 폐기에이르는전체생명주기에걸친방대한안전관련요구사항을제시하는데, 개발조직의내부상황을고려하여이요구사항들을효율적으로구현해야하며, 이것은성숙된 (matured) 개발프로세스역량이요구되기때문이다. 비근한예로, 유럽의안전성에관한선행연구개발 (EASIS) 보고서에의하면 CMMI 레벨 4 정도의조직이 ASIL C 정도를만족할수있다고한다. 가. 개발체계 ( 프로세스 ) 에미칠영향 기존에는품목개발생명주기와안전생명주기를별개로하는이중구조로구성되어각담당자별로나뉘어수행되었다. 또한차량개발시다양한개발품목이병행개발되며, 개발품목별로 CMMI, Automotive SPICE, 기타품질시스템을충족해야하는데여기에추가로 ISO 26262를도입하면개발체계및품질체계는그복잡도가훨씬증가하게된다. 또한자동차생산에있어서글로벌기업들과의협력은필수인상황에서이해당사자모두가받아들일수있는표준이요구된다. 따라서이러한프로세스복잡도증가를해소하고표준프로세스를제공하기위해 ISO 26262 기능안전성표준, 기존개발프로세스, Automotive SPICE, CMMI, 기타사내표준등을모두포괄하는참조프로세스의개발이필요하다 [15]. 나. 새로운지원도구의필요성 ISO 26262의요구사항을충족하기위해서는차량의개발초기부터체계적인재난분석, 개발품목에적절한 ASIL 결정, 전체생명주기에걸쳐서다양한기법이적용되는안전관리활동이요구되고이활동의성공적인수행을문서화된증거로서입 증할수있어야한다. 이것은개발자에게많은추가부담이될것이며이를경감시킬수있는다음과같은새로운개념의지원도구가필요하다. 다. ASIL 분석도구개발품목의안전성보장을위해서는차량에대한체계적인재난분석을통해합당한 ASIL을결정하여야한다. 재난분석을위해서는기존의 HAZOP, FMEA, FTA, Markov chain 등의분석기법을적용할수있는데, 현재는각기법들과관련된단편적인도구들과함께 DOORS나 MS 엑셀등을이용하여관련정보를관리하고있다. 그러나이러한단편적인도구들을연계하여사용하는것으로는개발초기의상위수준의재난분석에서부터개발후반부의상세한수준에서서로다른분석기법을통한재난분석을반복적으로수행하고그에따라 ASIL을결정해서관련정보를체계적으로관리하기가어렵다. 그리고 ISO 26262 의적합성을입증하기위해재난분석활동의성공적인수행결과를쉽게입증하기위해서는새로운 ASIL 분석을지원하는도구가필요하다. 라. ASIL와통합된프로젝트관리지원도구앞서언급한바와같이 ASIL 은개발품목의개발활동의엄격함정도에영향을미친다. 개발품목은내부에여러개의서브시스템혹은구성요소로구성될수있으며, 이것들은다시여러구성요소로분해되고개발되는것이일반적이다. 이때분해된각구성요소들은 ISO 26262의 ASIL 분해원칙에따라초기의 ASIL 이여러개의하위 ASIL 로분해될수있고, 이것은하나의품목아래다양한 ASIL 이존재할수있다. 이 ASIL 의등급에따라개발과정에서적용해야하는안전메커니즘, 검증기법, 시험기법이달라지게된다. 이것은전통적으로미리정해진사내표준프로세스및방법론에의거일괄적으로단순히적용하던방식을더이상적용하기어렵다는것을의미한다. 이러한복잡한프로세스 ( 개발활동 ) 를관리하는 C 2010 한국전자통신연구원 79
방법을단순하게나눈다면두가지방법이있을수있다. 첫번째는높은 ASIL 등급에적용가능한고수준의기법을일괄적으로적용하도록단순화시키는방법이고, 두번째는효율적인도구를활용하는것이다. 전자의경우의예는 ASIL A등급에워크스루를사용하고 ASIL B등급에는인스펙션을하도록되어있는것을, 사내에서 ASIL A, B 모두에인스펙션을적용하도록단순화하는방법이다. 그러나이러한방법은일부의개발활동에는적용할수있으나개발품목이많은수의구성요소로이루어질때에는복잡도가크게달라지지않을수있다. 결국이렇게개발품목의많은구성요소들과다양한 ASIL로인한실행프로세스의복잡도를관리해줄수있는프로세스지원도구가필요하다. Ⅳ. 결론 차량탑승자의편의와안전을제공하기위한다각도의노력으로국내에서생산되는차량들의편의성과안전성은해외유수자동차업체와비교하여도뒤지지않는수준에이르렀다. 또한정부주도로이루어지는미래자동차의로드맵과연구추진으로미래무인자동차와자동화는점차현실로다가오는듯하다. 편의 / 안전서비스의증가는전자장치의모듈화를가속화시키고전자장치별상호연동을통한네트워킹이증가시켰다. 복잡성의증가와소프트웨어적용빈도가높아지면서모델기반개발방법등소프트웨어의공학적접근법이조심스럽게추진되고있으며, 이러한조류와더불어사용빈도가높아지는자동차용운영체제와 소프트웨어플랫폼의표준화는가시적인성과를거두고있다. 미래는 와같은통일된소프트웨어플랫폼을적용하는부품모듈들의조립에의한자동차모델개발이가능하게되며, 재사용성의증가로신차모델의개발기간단축과안전성이보장되는부품모델의제공으로서비스신뢰성향상이기대된다. 또한신뢰성을제공하는소프트웨어플랫폼은자유로운부가서비스개발로이어져항상변화하는지능 형자동차모습을앞당길것으로예측된다. 국내자동차산업에서는기능안전성개념이아직은생소하다. 소수업체에서기능안전성표준 ISO 26262에관심을가지고있으나, 아직은많은개발자와전문가들이도메인별로단편적인안전기능개발에만관심을두고있고, 기능테스트를열심히하는것으로안전성이보장되는것으로여긴다. 그러나자동차분야에서이미 30~40% 의개발은소프트웨어로그기능이개발되고소프트웨어는그엄청난복잡성으로인해충분히테스트한다는것은불가능하다는것이알려져있다. 미국 NASA의경우소스코드 1라인당 850달러의비용을들여개발한소프트웨어의 KLOC(1,000 lines of codes) 당오류는 0.004개로알려져있다. 최근의자료에따르면고성능자동차의경우 1억라인의소프트웨어가들어갈예정이라고하는데 NASA 만큼개발비용을들인다하더라도확률적으로 400개의오류가들어있다는결론이나온다 [4],[16]. 향후자동차에있어서혁신의대부분 (80% 이상 ) 은전기전자시스템을통해이루어지는데그중심에는최근에부각되고있는 X-by-wire 라는개념이있다 [4]. 이것은차량내기존의기계적인장치를네트워크통신으로연결된구동기, 휴먼인터페이스및전기전자제어시스템으로대체함으로써무게를줄이고기능을고도화한다는개념이다. 이들전기전자시스템에서제어소프트웨어의사용은날로증가할것이다. 따라서이러한상황을고려했을때 제품이서비스되는시점에서최신의과학과기술을적용해야한다 라고하는유럽의 85/374/EEC 규정은미래자동차산업을준비하는업체에있어현실적인대안이라고할수있다. 이규정에는최신의기술을적용하였고그것을증빙할수있을경우, 비록결함으로인해사고가났더라도면책한다는내용이포함되어있으며만약최신기술을적용하지않았을경우, 태만 으로여긴다는것이다. 이규정은제조업체나소비자모두에게 win-win 이다. 소비자입장에서는보다안전한자동차를구입하기위해자동차업체들로하여금최신의기술을적용하도록강제할 80 C 2010 한국전자통신연구원 80
한태만외 / 자동차전자제어장치용소프트웨어기술및표준화동향 수있으며, 자동차업체는최신의기술을적용함으로써피할수없는오류로인해발생할수있는책임을면할수있기때문이다. 현재까지는 IEC 61508 이공식적인최신기술이며, 향후 2011년중순이후자동차분야에서는 ISO 26262가정식배포되면서이것을대체할것이다. 다만국내현실에서우려되는것은기존의차량배기가스의규제가후발업체에게는비관세 (nontariff) 무역장벽화되었다는것을고려하면차량의안전성이란명목으로 ISO 26262가향후더높은비관세무역장벽이될수있다는우려가일본에서도제기되었다 [17]. 그러한전망은 MISRA의 Guidelines of Safety Analysis 자료에서도곧현실화될수있음을알수있는데, ISO 26262가향후전통적인형식승인을대체하는새로운차량안전관리규정으로공식대두될것으로전망하고있다 [12]. LoC MCAL MISRA MM/T MOST RTCA RTE SCC SIL SW-C TCS VMC WP Likelihood of Occurrence per operational hour Microcontroller Abstraction Layer Motor Industry Reliability Association Multi-Media & Telematics Media Oriented System Transport Radio Technical Commission for Aeronautics Run-Time Environment Smart Cruise Control Safety Integrity Level Component Traction Control System Vehicle Multihop Communication Work Package 참고문헌 용어해설 ESP/ESC: 고속주행중발생하는긴급상황에서조향의안전을제공할수있도록각회전바퀴별로따로제어가가능하도록하는기술 약어정리 ABS Anti-lock Brake System APS Auto Parking System AUTomotive Open System Architecture BCM Body Control Module BSW Basic CDD Complex Device Driver EAL ECU Abstraction Layer EASA European Aviation Safety Agency ECU Electronic Control Unit ESC Electronic Stability Control ESP Electronic Stability Program EUROCAE European Organization for Civil Aviation Equipment FAA Federal Advisory Committee FMEA Failure Mode & Effects Analysis HMI Human-Machine LKS Lane Keeping System [1] 유우석, 박지용, 홍성수, 분산형실시간차량제어시스템을위한 RTOS, 미들웨어및결함허용성요소기술연구, 2006. [2] 장승주, 자동차용임베디드 SW 기술동향, 주간기술동향, 2006. 12. [3] 장승주, 권오훈, 자동차용임베디드운영체제기술동향, 주간기술동향, 2007. 8. [4] Robert N. Charette, This Car Runs on Code, http://www.spectrum.ieee.org/greentech/advanced-cars/this-car-runs-on-code, Feb. 2009. [5] 최상원, 선원웅, 자동차전장기술의동향과전망, 한국자동차산업연구소연구보고서, 2005-19, 2005. 12. [6] Frost & Sullivan, Strategic Analysis of the European Market for in Passenger Cars, M03B-26, 2007. [7] Technical Overview 3.0,, Dec. 2007. [8] 나지하, 권기선, 비 IT 분야임베디드 SW 기술융합동향, 2007. 6. [9] Layered Architecture,, Dec. 2007. [10] IEC 61508: Functional safety of E/E/PE safetyrelated systems. [11] Main Requirements 3.0,, Dec. 2007. C 2010 한국전자통신연구원 81
[12] MISRA Guidelines for Safety analysis of vehicle based programmable systems, Nov. 2007. [13] ISO DIS 26262 Road Vehicles - Functional safety, July 2009. [14] Axel Dold and Daimler AG, Implementation of Requirements from ISO 26262 in the Development of E/E Components and Systems, http://www.eacxpo.com/forum_2008/pdf/day_ 1/axeldold.pdf, Automotive Electronics and Electrical Systems Forum 2008, May 6, 2008, Stuttgart, Germany. [15] SAE World Congress & Exhibition, Reinhold Hamann - Robert Bosch GmbH, Application of ISO 26262 in Distributed Development ISO 26262 in Reality, Apr. 2009. [16] Balachander Swaminathan, Agile Overview, http://agileindia.org/agilecoimbatore07/presentations/agileoverview.pdf [17] Daichi Mizuguchi, A Report of the Current Situation on Certification in Japan, http://www.jaist.ac.jp/joint-workshop/verite/ 06JaistAist_mizuguchi.pdf 82 C 2010 한국전자통신연구원 82