새로운 ISO 26262 표준이 도입됨에 따라 안전 관련 기능에 대한 요구사항이 예전보다 크게 늘어난 동시에 보다 정확하고 명확하게 정의됐다. 이런 상황에서는 공식적으로 검증된 시스템과 기존 솔루션의 재사용(Re-use) 사이에 더 이상 문제가 발생하지 않는다. 하드웨어 및 소프트웨어에서의 일반 안전 모듈을 검증된 컴포넌트에 그냥 붙이기만 하면 된다.
글 │요아킴 캄박, 토마스 웬첼, 마틴 파슬
그림│벡터 인포매틱(Vector Informatik), 티티테크 오토모티브(TTTech Automotive)
출처│Elektronik automotive(2010, 11)
요아킴 캄박(Joachim Kalmbach) *
로틀링겐(Reutlingen)에 위치한 응용과학대학에서 컴퓨터 공학 및 자동화 전공했으며, 2006년 벡터에 입사해 현재 임베디드 소프트웨어 분야의 제품 관리자로 근무하고 있다. 주로 AUTOSAR 및 기능 안전성을 담당하고 있다.
토마스 벤첼(Thomas Wenzel) **
2006년부터 차량 기술 및 이동성(Vehicle Technology and Mobility) 기관에 근무했으며, 2010년 3월부터 기능 안전성의 역량 분야를 관리해 왔다. 또 코벤트리대학교(Coventry University)에서 제어공학 박사 학위를 취득했다.
마틴 파슬(Martin Fassl) ***
현재 엔지니어링 물리학 분야의 엔지니어(비엔나 기술 대학)로 1997년부터 통신, 항공 우주, 자동차 분야의 하드웨어/소프트웨어 개발 업무를 담당해왔으며, 2008년부터 티티테크에서 제품 매니저로 근무하고 있다. 개발 툴 및 표준 소프트웨어를 담당하고 있다.
ISO 26262는 전기/전자 시스템에 대한 기능 안전성을 적절한 방식으로 정의한다. 다양한 분야에서 사용되는 IEC 61508 표준에 기반해 자동차 분야의 안전 관련 기능이 관련이 없는 기능과도 어떤 밀접한 관계가 있고 서로 명확히 분리될 수 없다는 사실을 다룬다. ISO 26262의 목표는 안전 관련 기능을 보다 쉽게 이해할 수 있도록 하고 기능의 해석 범위를 가능한 한 좁히는 것이다.
엔지니어링 개발 시 발생하는 한 가지 과제는 잠재적 위험 요소를 모두 미리 평가하고 적절한 조치를 취해 최소화하는 것이다. 이를 위해 ISO에서는 개발 시작 단계에서 “위험 분석(Hazard and Risk Analysis)”을 수행해야 한다고 규정해 놓고 있다. 이 경우 모든 작동 상태와 관련 장애 유형이 대상 시스템 내에서 분석되며 다양한 잠재적 위험 상황이 확인된다. 그런 다음 각각의 위험 상황은 자동차 안전 무결성 기준인 ASIL(Automotive Safety Integrity Level) 레벨에 따라 A(최저)에서 D(최고)까지 지정된다.
ASIL이 높아지면 소프트웨어 개발 프로세스(테스트 범위, 요구사항 추적, 검토 문서화 등)뿐만 아니라 시스템의 하드웨어 메트릭스[FIT(Failure in Time) 비율, 테스트 범위 등]에 대한 요구사항도 증가한다. 이에 따라 시스템 공급업체는 기존의 고품질 요구사항에 비해 더욱 늘어난 요구사항을 충족해야만 한다.
점점 복잡해지는 자동차 기능을 표준화와 재사용으로 해결
최근에는 차량 내 다양한 기능들의 수와 복잡함이 날로 증가하고 있을 뿐만 아니라, 차량 전반에 걸쳐 분산되는 경우가 점점 늘고 있다. 이러한 추세는 사용 프로세서의 성능이 대폭 향상된 것에 비롯되기도 하지만, 다른 한편으로는 네트워킹에 사용할 수 있는 대역폭이 크게 증가했기 때문이다.
한편, 구현하려는 기능은 점점 복잡해져 기존 개발 방식으로는 더 이상 아키텍처 요구사항을 충족할 수 없게 됐다. 상황이 이렇게 전개됨에 따라 OEM 업체들은 2003년에 AUTOSAR 개발 파트너십에 참여하게 됐다. 이들의 공통 목표는 ECU용 통합 소프트웨어 아키텍처를 정의하고 소프트웨어와 하드웨어를 분리하는 것이다.
AUTOSAR가 정의되기 전까지 통신 스택과 진단은 주로 자동차 OEM들이 중점적으로 다루는 부분이었다. AUTOSAR에서는 기본 소프트웨어가 CAN, LIN, FlexRay, 진단 등의 분야에서 더욱 확장돼 이제는 마이크로컨트롤러에 대한 운영체제, 워치독(Watchdog), 메모리 스택, 드라이버 레이어까지 포함한다.
AUTOSAR 기본 소프트웨어는 버전 4.0이 2009년 말에 출시되면서 더욱 복잡해졌다. 현재 80개가 넘는 소프트웨어 모듈이 시스템 설명 파일(AUTOSAR System Configuration Description)을 통해 정의되며, 강력한 툴로 구성 후 해당 코드로 생성될 수 있다.
안전 관련 ECU에 사용되는 AUTOSAR 기본 소프트웨어의 요구사항
기능적 요구사항 외에 한 가지 핵심 요구사항은 기본 소프트웨어가 안전 관련 소프트웨어를 “방해”하지 않아야 한다는 것이다. 첫 번째 조건은 기본 소프트웨어가 안전 관련 소프트웨어의 메모리를 위반하지 않아야 한다는 것이며, 두 번째는 기본 소프트웨어의 실행 시간이 원래 의도한 시간보다 길지 않아야 한다는 것이다. 이 두 가지 조건을 합쳐 “간섭으로부터의 자유(Freedom from Interference)”라고도 한다.
겉으로 봤을 때 이를 충족하는 접근은 ISO 26262에 따라 분류된 안전 관련 소프트웨어 표준을 토대로 전체 기본 소프트웨어를 개발하는 것이다. 하지만 이미 언급한 대로 AUTOSAR 기본 소프트웨어는 매우 복잡하고 기능 범위가 광범위하며 소프트웨어의 사양에 대한 개정 주기가 짧다. 따라서 ISO 26262를 토대로 한 개발 작업은 매우 광범위해 질 것이다.
또 다른 접근 방식은 소프트웨어 파티션인 보호 레이어를 구현해 간섭 없이 기본 소프트웨어와 안전 관련 소프트웨어를 명확히 구분하는 것이다. 다행히도 AUTOSAR에는 이미 이를 위한 기능(메모리 보호와 프로그램 플로우 모니터링)이 있으며, QM을 따른 기본 소프트웨어와 ISO 26262를 따른 ASIL 보호 레이어의 ASIL 분해(아래 문단 참조)를 가능케 한다. 이에 ISO 26262에 따른 메모리 보호 및 런타임 동작(워치독을 통해 프로그램 플로우 모니터링)을 위한 모듈 개발만으로도 충분해진다.
ISO 26262에 따른 ASIL 분해 사용
이미 언급한 대로 ISO 26262를 적용하기 위해 모든 소프트웨어 메커니즘을 다시 개발할 필요는 없다. 정의된 안전 목표에 도달하기 위해 특정 ASIL을 달성하려면 개별 요구사항을 조합하고 안전 요구사항을 중복된 안전 요구사항으로 적절히 분할하면 된다. 예를 들어 특정 요구사항을 처리하는 동안 ASIL B와 ASIL A의 두 컴포넌트를 조합해 ASIL C를 얻을 수 있다(그림 1). ASIL 분해는 시스템, 즉 하드웨어 및 소프트웨어 레벨에서 수행할 수 있다. 분해하는 동안에는 하드웨어 아키텍처 메트릭스에 영향을 주지 않도록, 그래서 안전 목표를 위반할 가능성이 생기지 않도록 유의해야 한다. 또한 ISO 26262에서는 본래 ASIL의 안전 목표에 따른 확인 검토를 의무적으로 수행하도록 규정하고 있다(아래 예에서는 ASIL C).
ECU 내 다른 ASIL 소프트웨어 컴포넌트의 독립성 확보를 위해 ISO 26262에서는 간섭으로부터의 자유를 유지하고 검증하는 규칙을 정의하고 있다. 이러한 규칙은 안전 관련 요소와 관련이 없는 요소가 함께 “공존”해 적절한 측정 및 검증이 필요한 특수한 경우를 위해 적절히 유지되고 검증돼야 한다.
개발이 진행되는 동안 여전히 구체적인 사용 사례(또는 아이템)가 없어서 안전 목표가 정의되지 않는 일반적인 컴포넌트(서브시스템, 하드웨어 컴포넌트, 소프트웨어 컴포넌트)의 경우에는 ISO 26262에 따라 SEooC(Safety Elements out of Context)로 개발하면 된다. 이때 해당 안전 요구사항은 미지의 요소로부터 채워지기 때문에 여러 가정들이 설정되고 문서화돼야 한다(그림 2).
SEooC를 처음 사용하는 경우 가정이 사용 사례에 정의된 안전 목표 및 안전 요구사항과 일치하는지, 적합성이 뒷받침되는지, 모순되는 결과가 없는지를 판단하기 위해 제공된 안전 매뉴얼을 확인해야 한다. 그런 다음 안전 매뉴얼에 따른 올바른 사용을 보장하고 검증해야 한다.
검증 레이어의 일반 구현
티티테크(TTTech Automotive)는 “SafeExecution” 제품 안에 위에 언급된 “공존” 및 “간섭으로부터의 자유”에 대한 요구사항을 충족하고 기존 컴포넌트를 효율적으로 재사용해서 비용을 줄일 수 있는 일반 모니터링 레이어를 개발했다. 메모리 보호와 프로그램 플로우 모니터링을 위한 모듈 통합을 통해 기본 또는 애플리케이션 소프트웨어의 QM 개발 부분에 잠재적인 오류를 확실하게 찾아내고 적절한 조치를 시작할 수 있다(그림 3).
사용자는 안전 매뉴얼에 따라 Safe- Execution 모듈을 통합해 ISO/DIS 26262의 요구사항에 맞는 시스템을 만들어야 한다. 입증된 솔루션인 엔드투엔드(end-to-end) 통신 검증 제품 “SafeCOM” 외에 SafeExecution은 안전 관련 ECU의 개발에 사용된 티티테크의 두 번째 모듈이다.
통합 솔루션인 MICROSAR Safe
한 곳으로부터 검증된 기본 소프트웨어를 얻을 수 있도록 하기 위해 벡터(Vector)와 티티테크는 SafeCOM과 SafeExecution을 벡터의 검증된 AUTOSAR 솔루션인 MICRO- SAR에 통합했다(그림 4).
보증할 수 있는 방식으로 개발된 중앙 소프트웨어 컴포넌트를 다시 사용하면 애플리케이션 통합 비용을 줄일 수 있다. 티티테크와 벡터는 애플리케이션별 솔루션 대신 ISO 26262를 준수하며 안전 관련 ECU에 대한 개발 비용을 최소화할 수 있는 표준 솔루션을 함께 제공하고 있다.
<저작권자 © AEM. 무단전재 및 재배포, AI학습 이용 금지>