자동차에 전기전자 시스템이 급증하면서 원인을 알 수 없는 시스템 이상으로 인한 사고가 국내외에서 종종 보고되고 있다. 자동차 자체의 결함인지 운전자의 과실인지 명확하게 밝힐 수는 없지만 어떠한 경우라도 시스템의 이상이 감지되거나 운전자의 비 정상적인 운용이 감지된다면 그 즉시, 안전한 상태에 도달할 수 있는 대책을 시스템 차원에서 미리 세워둬야만 한다. 전기전자 시스템에 대한 안전을 규제하기 위하여 ISO26262가 발표되었다. 유럽 자동차 메이커를 중심으로 활발한 움직임이 있는 반면 국내는 구체적으로 기능안전을 만족하는 시스템 개발 자체에는 아직 낮은 수준이다.
국내·외 기술개발 현황
국내 자동차 시장에 적용된 전자제어 시스템도 과거에 비해서 꾸준히 증가해왔다. 안전 규제 강화에 대응하기위한 정책으로 연비 개선 시스템, 운전자 및 보행자를 위한 스마트 에어백, 차선이탈 방지 시스템, 운전자 상태인식 시스템, 그리고 고객의 편의성을 위해 도입된 운전자 정보 시스템, HMI, HUD, 어라운드뷰 시스템 등 수 많은 전자제어 시스템이 국내외 부품업체를 통해서 지속적으로 확대되고 있다.
2011년 한국자동차산업연구소의 ‘자동차 전자화 다이나믹스 분석’ 보고서에 따르면, 2011글로벌 전자화 시장은 2010년 약 250조원, 2020년에는 약 330조원에 이를 것이라고 보고 있다. 국내 전자화 시장 역시 연평균 8.5%로 고속 성장할 것이라고 보고 있다.
앞서 설명한 바와 같이 과거에는 섀시, 파워트래인, 바디, 인포테인먼트 도메인별로 모듈화가 흐름이었다면, 최근에는 전자 부품의 성능향상과 영역 간의 연계 기능이 필요함으로 해서 통합화가 최근 경향이다. 통합화로 인해 가격적인 경쟁력이 높아질 것이라고 기대한다.
하지만 통합화의 이면에는 소프트웨어의 복잡도를 피해갈 수 없으며 국내 업체들도 이에 대한 해결방안을 반드시 고려해야만 한다.
AUTOSAR
소프트웨어의 복잡도를 해결하기 위해서는 독립성, 재사용성, 이식성, 확장성, 조합성 등을 고려해야하며, 비용적인 측면에서는 양산성, 높은 품질, 개발 기간의 단축 등을 고려해야만 한다. 결국 소프트웨어의 플랫폼이 굉장히 중요한 이슈로 떠오르고 있다. 이에 따라 유럽은 독일을 중심으로 AUTOSAR를 통해 자동차 소프트웨어 기능의 표준화를 이루고자 하고 있으며, 일본 역시 일본 자동차社들을 중심으로 JasPar를 통해서 표준화를 이루려는 노력을 하고 있다.
국내에서는 현대자동차 그룹 자체에서 표준 플랫폼 기술 개발을 적용 중에 있으며 AUTOSAR R2.0을 기반으로 개발한 사례가 있다. ETRI에서 2008년부터 AUTOSAR R3.0을 개발한 경험이 있으나 국내 차량에 활발하게 양산 적용하지는 못하고 있지만 일부 시스템에 대해서는 선행개발 단계에서 적용하고 있다. 이는 자체 연구부족 및 AUTOSAR 플랫폼과 소프트웨어 컴포넌트의 통합 적용 경험의 부재로 보고 있다. 하지만 현대자동차 그룹과 ETRI 등이 AUTOSAR 표준 기술 및 동향 파악을 목적으로 꾸준히 표준화 활동에 참여하고 있다. 반면에 모비스, 만도 등 국내 자동차 전자부품 회사들은 AUTOSAR 적용에 OEM보다 더 적극적이다. AUTOSAR를 적용할 경우에 국내OEM과 부품 공급업체의 수직적인 구조를 탈피하여 국내 기업뿐만 아니라 AUTOSAR 적용이 훨씬 더 성숙된 해외 OEM까지도 공급할 수 있는 기회가 있기 때문이다.
ISO26262
AUTOSAR의 버전 증가에 따른 추이를 보면 안전관련 기능들이 확대 적용되고 있다. 점차 운전자 및 보행자 안전에 대한 인식이 높아지면서 자동차 기능 안전 표준인 ISO26262가 국제표준으로 제정되면서 이를 지원해야하는 요구가 AUTOSAR에 반영이 되었다. 따라서 Autosar 4.x부터 Program flow monitoring, Memory partitioning, E2E protection 등의 기능안전 부분이 추가가 되었다. 따라서 유럽을 중심으로 많은 자동차 제조사와 부품 공급업체는 이러한 흐름을 따라 기능 안전을 달성하기 위해 H&R (Hazard Analysis and Risk Assessment)을 통해 개발 아이템의 안전 목표(safety goal) 및 안전 요구사항(safety requirement)을 수립하고 실현하고 있다. 이는 자동차 제조사를 중심으로 부품 공급업체에 요구되고 있어 국내뿐 아니라 해외 자동차 제조사에 부품을 공급하는 만도 같은 경우는 오히려 국내 자동차 제조사보다 먼저 이러한 요구사항에 대응하기 위해 먼저 발 빠르게 준비하고 대응하는 수준이다.
자율주행 자동차
국내에서는 현대기아자동차를 중심으로 관련 기술 개발이 되고 있다. 2010년부터 현대기아 무인자율주행자동차 연구 경진대회를 주최하여 매 2년마다 현대자동차 남양 연구소 시험장에서 주어진 미션을 수행하는 대회를 개최하여 국내 자율주행 기술에 대한 대학의 연구를 활성화하고 있다.
ETRI에서도 차량 자동유도 시스템과 자동 발렛파킹 시스템 및 코파일럿 시스템 등의 자율주행관련 기술을 개발하고 있다. 현대차는 최근 신형 제네시스에 자율주행 차량 기술 중의 하나인 혼잡구간 주행지원 시스템(TJA, Traffic Jam Assist)을 탑재한 차량을 선보였다. 하지만 대부분 대학과 연구기관 그리고 국내 업체의 자율주행자동차는 현재까지는 연구단계에 이르고 있으며, 국외 자동차 메이커와 비교해서 확실한 미래의 비전은 보여주고 있지 못하는 실정이다.
또 하나의 걸림돌은 자율주행 자동차의 법 제정이다. 현재 미국과 같이 관련 법안을 통과시킨 주가 많은 반면 국내는 아직 법안 제정에 대한 고려를 전혀 하지 않고 있다. 유럽에서도 아직 미국과 같이 적극적으로 법안을 제정하고 있지는 않으나 독일 자동차 메이커의 자율주행 자동차에 대한 적극적인 태도에 의해서 점차 법 제정이 이루어질 전망이다.
사업내용
기능 안전에 대비하는 시스템을 개발하기 위한 단계는 아래와 같이 나열할 수 있다.
Item Definition(아이템 정의)
개발하고자 하는 시스템의 기능 콘셉트를 수립한다. 어떤 센서가 어떤 기능을 하며 ECU에 어떤 타입으로 센서 값을 송신하는지, ECU 간의 통신 그리고 엑츄에이터의 기능들을 나열하여 정의하는 단계가 필요하다.
Safety Goal(안전 목표)
안전 목표를 세운다. 안전 목표는 위험 분석과 위험 평가에 의해서 세워진다.
Functional Safety Concept and System Requirement
(기능안전 콘셉트 및 시스템 요구사항)
아이템 정의와 안전 목표를 기반으로 더 상세한 시스템 요구사항을 정의한다. 이 과정에서 필요하다면 아이템 레벨에서 ASIL 레벨을 분해할 수 있다. 즉, ASIL C를 만족해야하는 시스템에 QM 수준으로 개발된 센서를 사용한다면 ASIL C를 만족하는 ECU를 사용함으로서 전체적으로 ASIL C를 만족하게 한다.
Failure Mode(고장 모드)
아이템 정의에 의해서 고장 모드를 기술한다.
Safety Mechanism(안전 메커니즘)
고장 모드에 따라 안전 메커니즘을 정의한다.
위험분석과 시스템 분류
(Hazard Analysis & System Classification)
ISO26262 준수 이행 단계의 첫 번째는 ASIL 등급 분류이다. ASIL은 자동차 안전 무결성 수준이라고 하며, 자동차 시스템과 관련된 치명도를 표현하는 기준으로 치명적인 위험의 노출, 제어 가능성, 심각도의 함수이다. 잠재적인 심각도, 노출의 가능성 및 운전자에 의한 제어 가능성 등에 따라서 아래와 같은 표에 따라 등급을 분류할 수 있다.
경상이나 심하지 않은 부상, 생명을 위협할 가능성이 있는 심한 부상, 생명을 위협하는 부상 등에 따라 분류한다.
노출은 분석 대상 고장 모드와 동시에 발생할 경우 위험할 수 있는 작동 상황이 되는 상태로 분류된다.
제어 가능성이란 위험에 노출된 당사자가 시기적절한 대응을 통해 지정된 위해 또는 피해를 방지할 수 있는 역량으로 정의된다.
앞에서와 같은 표들에 의해서 하나의 시스템은 심각도, 노출의 가능성 및 제어 가능성 등을 종합하여 QM(Quality Management)부터 ASIL D 등급까지 나눌 수 있다. QM 등급은 안전을 고려하지 않아도 되는 시스템을 의미하며 단지 시스템의 품질 보증 수준으로 정의된다.
표 5에서는 몇 가지 ASIL 등급의 예를 표시했다.
ASIL 분해(Decomposition)
ASIL 등급의 분류에 의해서 시스템을 개발할 때 ASIL D 등급이라고 해서 하드웨어 및 소프트웨어의 모든 컴포넌트들이 모두 ASIL D를 만족해야하는 것은 아니다. ISO26262 표준에 의해서 ASIL 등급은 분해가 가능하다. 즉, 하나의 엘리먼트를 구현할 때, 주어진 안전 목표를 달성하기 위해 두 개의 낮은 ASIL 등급을 가진 독립적인 엘리먼트로 분리될 수 있으며, 반드시 다음을 만족해야 한다.
▶ 각각의 엘리먼트는 반드시 같은 안전 목표를 가져야만 한다.
▶ 각각의 엘리먼트는 반드시 같은 안전 상태를 가져야만 한다.
또한 ASIL 분해는 다음과 같은 단계에서 사용할 수 있다.
▶ 기능 안전 콘셉트 정의
▶ 시스템 디자인
▶ 하드웨어 디자인
▶ 소프트웨어 디자인
Mixed Critical S/W design
현재 QM(Quality Management) 수준을 만족하는 소프트웨어가 있다면, 어떻게 이 소프트웨어를 높은 수준의 신뢰성을 만족하게 할 수 있을까? 기존에 이미 개발했던 소프트웨어를 사용하지 않고 대신에 처음부터 신뢰성을 높일 수 있는 소프트웨어 방법론을 써서 새로 개발할 수도 있겠지만 엄청난 비용과 개발시간 및 비효율성을 감수할 수밖에 없을 것이다. 앞서 설명한 ASIL 분해(decomposition)이 여기에 적용될 수 있다.
ISO26262를 따르는 많은 시스템들은 서로 다른 ASIL 레벨에 의해서 개발된 소프트웨어 컴포넌트를 포함하고 있다. 이러한 소프트웨어 컴포넌트들 중의 하나가 비정상적인 동작을 한다면 이 동작은 다른 컴포넌트에 잠재적인 영향을 줄 수 있게 되고 결국 안전 요구사항을 만족하지 못한다.
시스템이 점차 복잡해지면서 통합의 요구가 높아지고 있다. 그림 2와 같은 분산되어 운용되었던 시스템이 하나의 ECU로 통합을 한다면 여러 가지 ASIL 레벨의 소프트웨어 컴포넌트의 혼재를 피할 수 없다.
또한 경우에 따라 ASIL 레벨의 소프트웨어 컴포넌트와 QM 수준의 소프트웨어 컴포넌트가 서로 다른 ECU에 맵핑되어야 하는 경우 역시 다른 레벨의 ASIL을 혼재해서 사용해야할 필요가 있다. 따라서 이러한 잠재적인 외란을 회피하는 개념을 ‘Freedom from Interference’라고 한다.
이러한 경우 여러 가지 잠재적인 외란이 발생할 수 있기 때문에 isolation이 서로 간의 간섭을 회피하는 가장 기본적인 전략이 될 수 있다. 하지만 단순히 하나의 isolation으로만은 부족하다. 따라서 여러 가지 기법을 이용하여 isolation을 구현하고 모니터링을 할 수 있는 안전 모니터링 소프트웨어가 필요하다. 이 때 중요하게 고려해야할 사항은 안전 소프트웨어를 별도로 개발할 때는 그 안전 소프트웨어가 어떤 시스템 혹은 어떤 ASIL 레벨에 적용되어야하는지에 대한 위험 분석 및 위험 평가를 할 수 없다. 따라서 가정에 기반을 두어 개발해야 한다. 이것을 Safety Element out of Context(SEooC) 라고 한다. 이러한 접근을 그림 5를 통해서 볼 수 있다.
고장모드(Failure Mode) 분석
ISO26262-5 Annex D에서 정의하는 고장모드를 정리하면 표 6과 같이 리스트화할 수 있다.
