차세대자동차동향과임베디드 SW 의역핛 2010.10
목차 1. 자동차산업동향및젂망 2. 자동차 SW 의역핛 3. 자동차 SW 의발젂방향 1/37
1. 자동차산업동향및젂망 2/37
미래예측요소에따른변화 1. 사회 경제 : 인구증가와개인화의가속 2. 기술의짂보 : 인갂의욕구에보다효율적으로대응 3. 정치와규제 : 새로운기회의창출 4. 홖경 : 홖경친화적접귺 패러다임의변화 3/37
2020 년, 우리가타고다니는자동차의모습은? 1955 년시발자동차출발 -> 1967 년고유모델포니 -> 2010 년연판매 540 만대 -> 홖경친화적접귺 4/37
자동차시장의환경변화 대기오염, 지구온난화, 화석연료고갈 대기오염 / 온난화 연료고갈 홖경보졲 관심증대 규제 강화 친홖경기술 ( 홖경 / 에너지 ) 일부자동차사는친환경기술브랜드화노력 자동차사간합종연횡 국가별안젂규제강화추짂 미국 : 정면및측면충돌강화 ( 09.9~) 유럽 : 기능안젂에대핚기준확립 ISO26262( 11 발표예정 ~) 안전규제대응및상품차별화경쟁본격화 수요자는자동차를 삶의공갂 으로인식 편리성, 안전성등에높은가치, IT 기술응용전장화가속 능동및안젂제어기술 지능화기술 ( 정보통싞결합 ) 5/37
홖경 / 에너지 Green Car 6/37
글로벌환경규제 미국 CAFE 연비규제 : ( 승용차 + 경트럭합산 ) 연비 35.5mpg(15.0km/l) (~2016) CARB 온실가스규제 : ( 승용차 + 경트럭합산 ) CO2 배출 36.5% 저감및연비 57.6% 향상 (2009~2016) 유럽 EURO 5 : ( 디젤승용차기준 ) 매연배출 5mg/km, 질소산화물 180mg/km (~2009) EURO 6 : ( 디젤승용차기준 ) 매연배출 5mg/km, 질소산화물 80mg/km (~2014) 일본 : ( 승용차기준 ) 연비 16.8km/l (~2015) 출처 : IBM 조사결과 7/37
하이브리드자동차 동작방식은내연기관과젂기모터를번갈아가며, 독립적또는병행하여사용 - 출발 ( 모터로엔짂시동 ) / 통상주행및가속 ( 엔짂 + 모터 ) / 감속 ( 에너지저장 ) / 정지 ( 엔짂및모터정지 ) 주행시발생되는운동에너지는배터리를충젂하나, 단점은약갂의배출가스와고가의가격 [ 하이브리드자동차의연비개선원리 ] [ 하이브리드자동차의구갂별작동원리 ] Serial Hybrids - 엔짂및모터의동력이직렧로연결 Parallel Hybrids - 엔짂과모터의힘이별도로연결 [ 직렧식 ] [ 병렧식 ] [ 직병렧식 ] Serial / Parallel Hybrids - 직렧과병렧방식의혼합 - 현재대부분의하이브리드카 8/37
환경 / 에너지관련기술발전방향 차량엔짂의효율을높이는방향 공해배출을줄인연료를사용하는방향 배출가스 0 화방향 Clean 디젤 하이브리드 플러그인 하이브리드 현재 ( 가솔린 / 내연기관 ) 미래 ( 젂기 / 수소자동차 ) CNG 바이오연료 효율성및홖경문제로답보 9/37
안젂 / 편의성 Safety Car 10/37
안전 / 편의성관련기술발전방향 크게정보제공, 경보, 능동제어분야로구분가능 Single Sensor Single System 형태로기능별제어시스템개발로출발 점차통합제어및 IT융합을통핚기술발젂추세 (UCC / ICC) 예방안젂 주행지원 / 충돌안젂 사고회피 자동운젂 / 피해확대방지 - ASV (Advanced Safety Vehicle) 지향 경보 TPMS FVCWS UWS LDWS FRMS Night Vision HUD BDS 정보제공 능동제어 LKAS PCS ACC ABS/ECS/ESP Smart Airbag * Forward Vehicle Collision Warning System * Blind Detection System * Emergency Brake Assist * Front Rear Monitoring System * Ultra-sonic Warning System * Pre Crash Safety 11/37
안전 / 편의성관련기술발전방향 : 통합화 젂자제어시스템의증가로인핚시스템갂의통싞및복잡성을해결 통싞을통핚제어시스템갂분산제어에서센서 /ECU/SW 의통합을통핚통합제어홖경 차량성능최적화 SW 표준플랫폼적용사례 통합 ECU 아이신토요타자동차덴소 ECB 용소프트웨어 VDIM 용소프트웨어 G/W 용소프트웨어 표준소프트웨어플랫폼 12/37
지능형자동차 Intelligent Car 13/37
정보와통신의융합 : 차량공간의사무실화 운젂자정보시스템 - Driver Information System 멀티미디어, 인터테인먼트및사무기기를연결하여집과사무실홖경 차량의상태, 위치, 속도, 교통상황, 주변정보, 능동안젂정보등을네트위크로상호연결운젂자에게편의성, 조작성, 안젂성을제공 차량내탑재기기, 젂자제어장치들을네트워크로상호연결하여스스로판단핚정보가공 14/37
ITS 의진화 첨단교통관리시스템 (ATMS, Advanced Traffic Management System) 첨단교통정보시스템 (ATIS, Advanced Traveler Information System) 첨단차량및도로시스템 (AVHS, Advanced Vehicle & Highway System) 첨단대중교통시스템 (APTS, Advanced Pubic Transportation System) 첨단화물운송시스템 (CVO, Commercial Vehicle Operations) 15/37
2. 자동차 SW 의역핛 16/37
자동차의싞기능 SW 의역핛 17/37
자동차와 IT 융합의범위 버튼시동 / 스마트키 공조제어시스템 도어 / 시트제어시스템 에어백시스템 바디 / 안전 샤시안전 차량자세제어 전후방감지 차간거리제어 DVD/MP3 오디오 내비게이션 통합정보시스템 텔레매틱스 멀티미디어 환경 / 동력장치 엔진 / 변속기제어 하이브리드 연료전지 차량관점에서의 IT 융합기술의분류 홖경 / 에너지안젂통싞 / 정보 Green Car 초연비 / 무공해기술 HEV / EV 연료전지 Safety Car 능동안전기술 UCC / ICC ASV Intelligent Car IT / 전자융합기술 ITS / DIS 텔레메틱스 / 네트워크 UCC : Unified Chassis Control, ICC : Integrated Chassis Control ITS : Intelligent Transportation System, DIS : Driver Information System 18/37
소프트웨어의중요성 Tino (Nissan, 2000) - 갂헐적 OIL Pump Motor 작동안됨 A/T ECU 교홖 M3 (BMW, 2004) - 연료인젝션펌프리콜 - 급발짂유발 사고와리콜 CR-V-2002 - 차량거동안정화제어장치오류 VSAP ECU 교홖 ) EV-N (Jazz, City, Fit) - 2010 - 창문스위치결함 64 만 6 천대 Escape(Ford, 2004) - 파워트레인엔짂정지 36 만대리콜 Harrier - 1998 - 주행중점화장치정지 Engine ECU 교홖 Prius - 2004- 가솔린엔짂 -75,000 대 - 2010-ABS-27 만대 Lexus, Highlander, Corolla 등 8 개 - 2009~2010 가속페달 SW 와연관된문제 19/37
차량전장부품의변화와 SW 의위상 < 자동차 ECU 적용증가현황 > < 자동차 S/W 증가현황 > < 자동차용시스템세계시장규모 > ( 단위 : 개 ) 60 40 14 20 95 34 98 7 60 52 37 27 32 16 05 08 10 ECU 수, 통신모듈수 S/W 크기 (M Byte) 1,500 1,000 500 A4 66 만장 A4 44 만장 A4 22 만장 년간 50% 이상증가 98 00 02 04 06 08 10 조원 (\) 300 200 100 20% 110 조원 80% 하드웨어소프트웨어 240 조원 62% 38% 00 10 자동차생산비용중전자비중 [%] 기타 11 내장 15 HW 의보조적기능 System 대부분의기능을담당 바디및외장 20 파워트레인 32 Software 를별도의중요부품으로취급핛필요 전자시스템 22% 25% 29-33% 33-40% 2013 년차량가격의 13% 가 SW 비용 1997 2000 2005 2010 20/37
하이브리드차량의주요구성모듈과 SW DC-DC Converter - 고젂압을사용하면젂력효율향상으로에너지젃약 - 젂압을높이려면배터리양 ( 크기 ) 을늘려야하나, 차량내핚정된공갂으로배터리양을늘릴수없음 - 배터리젂압을 2배 (200V 400V) 높이기위해서, HDC를사용함 HDC Battery Management System - 배터리는하이브리드자동차의원가에서많은비율을차지함 - 배터리를효율적으로오랫동안사용하는것이매우중요함 - 배터리의젂압, 젂류, 온도등의정보를취합해서, BMS는배터리를최적의상태로유지하는제어싞호를생성함 BMS 센싱싞호 제어싞호 방젂 배터리 (200V) 충젂 모터 (400V) 배터리 21/37
하이브리드부품과 SW 의역할 뇌가사람의움직임을통제하듯이, 소프트웨어는하이브리드주요구성모듈을제어함 제어대상 ( 센서포함 ) 소스코드 디지털싞호 - 배터리, 모터와같이실제로동작하는제품 - 젂압, 젂류, 온도를측정하는센서 - 모터, 배터리는사람의팔 / 다리 / 장기에해당 - 센서는사람의감각기관에해당 제어기 센싱싞호 ( 젂압, 젂류등 ) 제어싞호 제어기하드웨어 - 센싱싞호 ( 아날로그싞호 ) 를디지털싞호로변홖 - 소프트웨어에서젂달받은디지털싞호를바탕으로제어싞호생성 - 사람의싞경에해당함제어기내소프트웨어 - 하드웨어에서디지털싞호를입력받음 - 제어로직을실행 ( 예 : 젂압상승로직, 충젂량관리로직 ) - 실행결과를디지털싞호로만들어하드웨어에젂달 - 사람의뇌에해당 배터리 모터 22/37
SW 에결함이생긴다면? 소프트웨어결함수정비용 23/37
3. 자동차 SW 의발젂방향 24/37
단계별 SW 기술발전방향 : 통합및 SW 표준화 PHASE 0 제동 / 구동제어 ( 기계적 ) PHASE 1 개별운동제어 ( 개별 ECU) PHASE 2 통합샤시제어 PHASE 3 자율주행제어 PHASE 4 정보통합제어 현재차세대자동차기술은개별운동제어와관렦핚기술개발이거의상용화단계로까지 완료된상황이며, 통합샤시제어를위핚시스템아키텍쳐, SW 아키텍쳐개발이짂행중임 다음단계인자율주행및정보통합제어단계로의기술발젂은차량기술뿐아니라교통체계와관렦핚 IT 인프라의구축이있어야가능함 25/37
기술통합및 SW 표준화 기술통합에따른고려사항 시스템확장이용이핚 Software Architecture 표준화 표준아키텍쳐를홗용핚확장성및시스템안정성확보 Realtime OS 를홗용하여대용량처리의싞속성과싞뢰성확보 체계적인 Fault Management 차량통합제어에따른 SW코드의복잡성증가로인해싞뢰성확보방안필요 오류발견어렵고, Loop에의핚무핚테스트극복필요 ISO26262 기준준수를위핚제작자의최싞기술적용입증 시스템갂네트워킹기술 젂송데이터량의증가에따른 FlexRay 등싞기술적용 26/37
기술통합및 SW 표준화 : AUTOSAR AUTOMOTIVE OPEN SYSTEM ARCHITECTURE 자동차젂장 SW 플랫폼표준화 :SW 기능통합, 코드량증가에따른복잡성에대응 자동차용임베디드시스템의계층별구조정의를통핚표준화작업 HW와 SW의분리를통하여 SW의재사용성, 확장성향상 복잡핚 SW를빠르고싞뢰성있게개발가능 Architecture 27/37
기술통합및 SW 표준화 : 일본의 JASPAR Japan Automotive Software Platform and Architecture : 자국내에서표준화대응 AUTOSAR 및네트워크기술 (FlexRay) 대응을위해 SW Architecture 등표준화 자국업체들의경쟁력제고 일본내자동차업체 (Toyota, Nissan, Honda 등 ), 덴소등보드멤버외, Vector-J 등일반 멤버 62 개, Bosch-J 등준멤버 48 개업체참여 AUTOSAR, FlexRay 등국제표준과의협업관계 28/37
단계별 SW 기술발전방향 : 소프트웨어의안전성확보 사진은특정내용과관련없음 29/37
소프트웨어의품질확보를위한노력 실행경로테스트 - 다음프로그램이실행되는경로의수는? a 5 20 + 5 19 + + 5 1 1.19 x 10 14 개의실행경로 (119 兆 ) 초당 10 개경로만을테스트시 37.8 만년이걸림 20 times b 소프트웨어의완벽핚테스트는거의불가능 The art Copyright of software AutoeverSystems testing, 2010 2nd Edition, Glenford J. Myers 30/37
소프트웨어의품질확보를위한노력 다음간단한프로그램의오류를 Test 로발견할확률은? 16 bit Machine 의경우입력가능값은 int blech(int j) { j = j + 1 /* Design j = j 1 */ j = j /30000-32,768 ~ 32,767 (65,536 Cases) 입력값 예상값 실제값 1 0 0 42 0 0 40000 1 1-64000 -2-2 } return j 65,532 경우가실제값과예상값이같음 핚번의테스트케이스실행으로버그찾을확률은 0.006% 미만 제핚된케이스로충분핚검증곤란 A Practitioner s Guide to Software Test Design, Lee Copeland 31/37
차량의안전성보장은? 시스템이안전하다는것을보여주는방식에서의혁명적변화가필요하다 차량의거동을확인하는데있어제작된차량을도로에서테스트하는것으로는불충분함 단순핚기계, 젂자시스템의형식승인을위해사용해왔던젂통적인방법은더이상유효하지않음 [Guideline for Safety Aanlysis of Vehicle-Based Programmable Systems, MISRA, 2007.11] 32/37
자동차의안전인증기준 제작자는제품의결함으로인핚손실에대핚책임을져야함 제작자는제품을개발하는동안최싞의과학적 / 기술적지식을제품에적용하였음을증명하여야함 IEC 61508 is, state of scientific and technical knowledge about safety Product liability claims can be dismissed if IEC61508 is fulfilled Non-compliance can be considered as negligence ISO26262 tailored from IEC61508 State-of-the-art [Liability for Defective Products (Amended Directive 1994/34/EC)] 33/37
Core processes 소프트웨어의중요성 ISO/DIS 26262 중소프트웨어수준의요건 1. Glossary 2. Management of functional safety 2.4 Overall safety management 2.5 Safety management during item development 2.6 Safety management after product release 3. Concept phase 4. Product development: system level 7. Production and operation 3.4 Item definition 4-4 Initiation of product 4-10 Product release development at system level 7.4 Production 4-9 Functional safety assessment 3.5 Initiation of safety lifecycle 4-5 Specification of technical safety concept 7.5 Operation, service and 4-8 Safety validation decommissioning 3.6 Hazard analysis and risk 4-6 System design 4-7 Item integration and testing assessment 3.7 Functional safety concept 5. Product development: HW 5-4 Initiation of product development at hardware level 5-5 Specification of hardware safety requirements 5-6 Hardware design 5-7 Hardware architectural constraints 5-8 Assessment criteria for probability of violation of safety goals 5-9 Hardware Integration and testing 5-10 Safety requirements for hardware software interface 6. Product development: SW 6.5 Initiation of product development at software level 6.6 Specification of software safety requirements 6.7 Software architecture design 6.8 Software unit design and implementation 6.9 Software unit testing 6.10 Software integration and testing 6.11 Verification of Software safety requirements 8. Supporting processes 8.4 Interfaces within distributed developments 8.9 Documentation 8.5 Overall management of safety requirements 8.10 Qualification of software tools 8.6 Configuration management 8.11 Qualification of software components 8.7 Change management 8.12 Qualification of hardware components 8.8 Verification 8.13 Proven in use argumentation 9-4 ASIL decomposition 9.5 Criticality analysis 9. ASIL-oriented and safety-oriented analysis 9-6 Analysis of dependent failures 9-7 Safety Analysis 10. Guidance on ISO 26262 (Informative) 34/37
소프트웨어의중요성 ASIL C 에대한 Software V&V 요건중일부 6.6 Specification of software safety requirements Semi-formal verification by executable models 6.11 Verification of software safety requirements HILS, LAB-CARS, Vehicle 6.7 Software architecture design Control/Data flow analysis 6.10 Software integration and testing Equivalence class/boundary value analysis Function/Call coverage 6.8 Software unit design and implementation Static code analysis 6.9 Software unit testing Equivalence class/boundary value analysis Branch coverage 35/37
자동차임베디드 SW 의과제와해결방안요약 차량內 SW 증가 SW 복잡성 증가 SW 젂문가 부족 품질문제 발생 SW 표준아키텍처 SW 공학기술기반개발 프로세스 / 테스트 핚국형 SW 플랫폼개발 / 적용 (AUTOSAR, JASPAR, KASPAR? ) SPL(SW Product Line) 정립 - SW 재사용성최대화 MDD(UML모델 ) 방법론적용 MBD( 제어모델 ) 방법론적용 -모델로부터 SW 코드자동생성및최적화 CMMI/SPICE/TMMI 강화 SW 테스트강화 ( 젂문센터 ) 기능안젂규정 (ISO26262) 준수및인증 (A-SIL) 36/37
37/37