ISO26262 표준을 준수하는 차량용 전장 품 개발을 위한 의존 고장 분석의 적용

Fig. 1

Cascading failure1,3-6)

위 Fig. 1은 연계 고장에 대한 참조 그림으로서 연계 고장의 메커니즘을 보여준다. Fig. 1에서 보는 바와 같이 연계고장은 엘리먼트 A의 내부 또는 외부의 근본 원인(Root cause)으로 인해 초래된 엘리먼트 A의 고장이 엘리먼트 B로 연계되어 엘리먼트 B가 고장이 발생하는 현상이다.^1,3-6) (엘리먼트 B는 엘리먼트 A와 동일한 아이템이거나 다른 아이템이 될 수 있다. 여기서의 아이템은 기능안전 ISO 26262-1:2018에서 정의된 것을 의미한다.)⁵⁾

Fig. 2

Common cause failure1,3-6)

위 Fig. 2는 공통 원인 고장에 대한 참조 그림으로서, 공통 원인 고장의 메커니즘을 보여준다. Fig. 2에서 보는 바와 같이 공통 원인 고장은 아이템의 엘리먼트 내부 또는 외부로부터 야기 되는 근본 원인(Root cause)의 결과로 두 개 이상의 엘리먼트가 고장 나는 현상이다.^1,3-6) 이러한 공통 원인 고장에는 하나의 공통된 근본 원인으로 인하여 여러 엘리먼트가 같거나 유사한 고장 모드가 동시에 발생하는 공통 모드 고장(CMF)을 포함한다.^5,7)

독립성이란 “안전 요구사항을 위반할 수 있는 두 개 이상의 엘리먼트 간에 의존 고장이 없는 상태”를 말한다.^3,5) 즉, 독립성 요구를 충족한 엘리먼트는 연계 고장(CF)과 공통 원인 고장(CCF)이 없다. 이러한 독립성 요구의 실현은 안전 설계 구현에 있어 매우 중요한 요소 중 하나이다.

하지만, 차량 전장 품 설계에 있어, 요구된 엘리먼트에 대한 독립성 실현은 쉽지 않는 것이 현실이다. 차량 아이템을 구성하는 엘리먼트인 센서 모듈이나 제어 모듈 등과 같은 서로 다른 제조사로부터 제조되고 완제품으로 존재하는 차량 전장품들에 대한 독립성 요구의 실현은 상대적으로 수월한 편이나 이와 달리, 하나의 PCB 기판에 실장 되어 동일한 공간에 존재하는 개별 전자 부품(엘리먼트)들에 대해서는 독립성 요구를 충족시키기 위한 설계는 매우 까다롭다. 특히, 공통 원인 고장을 완전히 배제시키기가 어렵다. 이는 단가를 중요하게 여기는 자동차 산업의 특수성에 따른 한정된 PCB 공간 및 한정된 하드웨어 자원으로 기인한다. 일반적으로 E/E system의 엘리먼트에 요구된 독립성 확보 하기 위한 수단으로써 이중화 된 설계를 하게 되는데 이중화 된 설계는 분리된 전원 소스와 (논리적 또는 물리적으로) 분리된 메모리, 분리된 처리 장치, 분리된 입출력 장치 등과 같은 이중화 된 리소스 등이 요구 될 수 있으며, 뿐만 아니라 더러는 EMC/EMI로부터 보호하기 위한 개별 차폐 등이 요구 될 수도 있다. 이러한 요구들로 인하여 더 넓은 PCB Size 및 더 많은 하드웨어 리소스가 필요하게 된다. 이는 결국, 단가 상승으로 이어질 수 있음으로 차량 전장 품 제조사들이 기피하는 이유가 된다. 그렇기 때문에 차량 E/E system에서의 독립성은 모든 엘리먼트에 적용하는 것 보다는 필요한 부분을 적절히 식별하여 적용하는 것이 합리적이다.

간섭으로 부터의 자유(Freedom from interference)란 “안전 요구사항을 위반할 수 있는 둘 이상의 엘리먼트 간에 연계 고장(CF)이 없는 상태”를 의미한다.^3,5) 이것은 분석 대상 엘리먼트에 대한 고장이 다른 엘리먼트의 고장으로부터 초래 된 것이라면, 분석 대상 엘리먼트는 ‘간섭으로부터 자유롭지 않다’라는 의미이다.

ISO 26262-9:2018에서 설명된 ASIL 분해³⁾는 하나의 안전 요구사항을 중복된(Redundant) 형태로 나누기 위해 안전 요구사항을 분해하게 되는데, 이 때 분해된 안전 요구사항을 구현하는 엘리먼트에 대한 독립성(Independence)을 요구한다.^2,3,5) 독립성이 요구된 개별 엘리먼트는 의존 고장 분석을 통해 연계 고장과 공통 원인 고장이 없다는 것을 증명해야 한다. 설사 의존 고장이 있더라도 이를 완화할 수 있는 안전 조치를 제시하고, 안전 조치가 효과적으로 의존 고장을 완화한다는 증명을 해야 한다. 만약 이를 증명하지 못한다면, ASIL 분해는 이루어지지 않는다.³⁾

예컨대, QM과 ASIL A 조합, ASIL B와 ASIL C 조합 등과 같은 ASIL 할당 및 ASIL 분해의 결과로 초래된 서로 다른 품질 수준을 갖게 되는 엘리먼트들 간의 조합은 기능안전 측면의 문제를 야기 하는 원인이 되기도 한다. 왜냐하면, 품질 수준이 낮은 엘리먼트는 품질 수준이 높은 엘리먼트보다 고장 날 확률이 높고, 이로 인해 안전 목표 위배 확률 역시 커질 수 있기 때문이다. 이러한 이유로, 품질 수준이 낮은 엘리먼트의 고장이 품질 수준이 높은 엘리먼트의 고장으로 이어지면 안 된다. 그렇기 때문에, 기능안전 ISO 26262-9:2018 표준에서는 아키텍처 설계 시 서로 다른 품질 수준을 갖은 엘리먼트들에 대한 조합의 조건으로 공존 기준(Coexistence criteria)을 제시한다.³⁾

Fig. 4는 서로 다른 품질 수준을 갖은 엘리먼트 조합에 있어서 공존 가능과 불가에 대한 비교 그림이다. 상위 품질 수준을 갖는 안전 관련 엘리먼트인 1과 하위 품질 수준을 갖는 비 안전 관련 엘리먼트 2와의 조합에 있어서 엘리먼트 1의 고장의 원인이 엘리먼트 2에 있다면, 이것은 연계 고장에 해당한다. 즉, 엘리먼트 1은 엘리먼트 2의 간섭으로부터 자유롭지 못하다. 이 경우, 비 안전 관련 엘리먼트 2는 엘리먼트 1의 품질 수준을 부여받아 안전 관련으로 취급된다. 하지만, 이와는 달리, 안전 관련 엘리먼트 5와 비 안전 관련 엘리먼트 6과의 조합에 있어서 상위 품질 수준을 갖는 엘리먼트 5의 고장의 원인이 하위 품질 수준을 갖는 엘리먼트 6에 있지 않는다면, 이것은 연계 고장이 없다는 것을 의미한다. 즉, 엘리먼트 5는 엘리먼트 6의 간섭으로부터 자유롭다. 이 경우, 엘리먼트 5와 엘리먼트 6은 서로 다른 품질 수준을 갖더라도 공존이 가능하다. 이러한 공존 기준 메커니즘은 서로 다른 ASIL 등급을 갖는 안전 관련 엘리먼트들 간의 조합에 있어서도 동일하게 적용된다.

Fig. 4

Coexistence criteria mechanism

기능 안전에서의 안전 메커니즘은 안전 목표를 위배할 개연성이 있는 엘리먼트의 고장을 회피하거나 억제하기 위한 설계적 관점의 실질적 수단으로서 사용된다. 이러한 안전 메커니즘이 얼마나 신뢰할 만한지 평가하기 위하여 안전 메커니즘에 대한 효과성(Effectiveness)과 더불어 안전 메커니즘의 유효성(Validity)을 확인해야 한다. 안전 메커니즘의 효과성은 안전 메커니즘의 동작이 의도한 대로 수행하는지를 확인하는 것이다. 이를 위해 안전 메커니즘에 대한 기능 및 성능 테스트를 수행한다. 그리고, 안전 메커니즘의 유효성은 안전 메커니즘이 간섭으로부터 자유로운지를 확인하는 것이다. 이를 위해 안전 메커니즘에 대한 의존 고장 분석을 수행한다.

의존 고장 분석을 통해 안전 메커니즘과 안전 메커니즘이 모니터링하는 엘리먼트 사이에 연계 고장이 없음을 확인하고, 만약 있다면, 연계 고장에 대한 완화 조치를 마련해야 한다. 왜냐하면, 최악의 경우, 안전 메커니즘이 모니터링하는 대상 엘리먼트의 고장이 안전 메커니즘의 고장으로 이어진다면, 그 안전 메커니즘은 신뢰하기 어렵기 때문이다. 이는 결국 해당 안전 메커니즘을 개선해야 할 이유가 된다. 그리고 안전 메커니즘의 유효성 측면에서 한 가지 더 고려되어야 하는 것은 안전 메커니즘에 대한 독립성이다. 사실 안전 메커니즘은 간섭으로부터 자유로운 것 보다는 독립성을 충족하는 것이 더 좋다. 그 이유는, 안전 메커니즘이 독립성을 충족할 경우, 연계 고장과 공통 원인 고장으로부터 자유롭기 때문에 간섭으로부터 자유로운 것 보다 훨씬 신뢰할 수 있기 때문이다.

하지만, 앞서 밝힌 바와 같이 차량 산업의 특수성으로 인해 동일 PCB 기판에 여러 엘리먼트들과 상호 공존하는 안전 메커니즘의 엘리먼트는 공통 원인 고장으로부터 자유롭지 못할 때가 종종 있다. 이러한 상황에서 안전 메커니즘의 유효성에 대한 최상 조건은 연계 고장과 공통 원인 고장이 없는 독립성을 충족한 것이며, 최소 조건은 연계 고장이 없는 간섭으로부터 자유를 충족한 것이다.

출시 전 의존 고장 발생의 근본 원인을 배제하여 출시 후 운용 중 의존 고장의 발생을 회피하는 조치이다.²⁾ 예) Isolation, Partitioning, Redundancy/Diversity design, Robust design, 전용 생산 시험 등.

의존 고장의 발생을 방지하지 못하지만, 안전 목표를 위반하지 못하도록 하는 조치로서, 의존고장이 발생했을 때 제어하거나 완화할 수 있는 조치이다.²⁾

예) On-line Monitoring(ECC, CMU, Watch-dog Timer,..), Self Test(Built-In Self-Test 포함) 등

식별된 모든 의존 고장에 대한 완화 조치가 필요한 것은 아니나 다음과 같은 상황에 대해서는 완화 조치가 필요하다.

• ① 서로 다른 엘리먼트들 간의 ASIL coexistence(공존)이 필요할 때
• ② 안전 관련 엘리먼트가 안전 목표를 위반할 개연성이 있을 때(이 경우, CF는 단일점 결함임)
• ③ 안전 메커니즘에 대한 유효성을 확보해야 할 때

전동식 파워 스티어링(EPS)은 전기모터의 힘으로 조향 핸들을 돌려주는 장치를 말하며, 운전자가 핸들을 틀어 방향을 정해 주면, 동력 조향 장치가 운전자가 원하는 방향만큼 동력을 가하는 장치이다. 전동식파워 스티어링은 회전각 센서, 토크 센서, 모터로 구성된다. 회전각 센서 및 토크 센서에서 입력되는 핸들의 동작에 따라 ECU에서 모터를 제어한다. ECU에서는 속도 등의 운전 상태에 따라 제어 모드를 변화시킨다. 아래 Fig. 6은 EPS에 대한 아키텍처이다.

Fig. 6

EPS Architecture

• 1) Power supply(H1)
  배터리로부터 전원을 입력 받아 EPS 장치의 전원을 공급한다.
  PWR_Motor: BLCD 모터 전원
  +5 V: 제어기 메인 전원
• 2) Power monitor circuit(H9)
  배터리 전압 상태를 모니터링하여 과전압과 저전압 상태를 알아낸다.
• 3) Steering angle sensor(H4)
  조향 각 센서로서, 핸들의 조향 속도, 조향 방향 및 조향 각을 검출하는 역할을 한다.
• 4) Torque sensor(H5)
  핸들 축의 비틀림(Torsion) 힘을 측정하는 센서이다. 운전자가 핸들에 가하는 힘(Torque)를 감지한다.
• 5) Motor position sensor(H6)
  홀 센서로 이루어져 있으며, BLDC 모터의 위치를 알아낸다.
• 6) Current Sensor(H7)
  BLDC 모터의 상태를 모니터링 하기 위한 전류 센서이다.
• 7) Vehicle Speed Input(H8)
  CAN 통신을 통해 입력되는 차량의 속도 정보.
• 8) Motor Power Relay Driver(H21) & Motor Power Relay(H24)
  BLDC 모터의 전원을 공급하는 HW Component.
  비상시 BLDC 모터의 전원을 차단해 줌으로써 핸들을 수동으로 조작 가능 하도록 한다.
• 9) Flash ROM(H29)
  Boot Code와 Calibration Code가 들어 있다.
• 10) Main MCU (H2)
  전원 상태 모니터링 로직(S3), 스티어링 회전각 처리 로직(S4), 스티어링 회전력 처리 로직(S5), 모터 위치 처리 로직(S6), 모터 소비 전류 처리 로직(S7), 차속 처리 로직(S8), 제어 로직(S1), BLDC 모터 출력 로직(S9), SPI 통신 처리 로직(S10)이 실행된다.
  제어 로직은(S4) 메인 로직으로서, 모든 처리 로직을 콜 한다. 또한 입력 처리 로직으로 부터 받은 데이터를 프로그램 된 알고리즘에 따라 계산하여 계산 결과를 BLDC 모터 출력 로직(S9)으로 전달한다.
  Main MCU (H2)는
  - Steering Angle Sensor(H4),
  - Torque Sensor(H5),
  - Vehicle Speed Input(H8)
  으로 부터 전달받은 값(Data)를 계산하여 운전자의 조향 의지를 판단한다. 판단 결과를 SPI 통신을 통해 Sub MCU(H3)로 전달하며, 판단 결과를 BLDC 모터 출력 로직(S9)으로 전달한다.
  - Vehicle Speed Input(H8)
  으로 부터 입력 받은 차량 속도에 따라 조향력을 조절한다. 저속 주행시에는 조향력을 증가시켜 운전자가 핸들 조작이 용이하게 하고, 고속 주행시에는 조향력을 감소시켜 핸들을 무겁게 만든다.
  - Motor Position Sensor(H6)
  를 통해 BLDC 모터의 위치를 제어한다. 만약, BLDC 모터가 Stuck 되어 움직이지 않는다면,
  - Motor Power Relay(H24)
  를 off 시켜, BLDC 모터의 전원을 차단해 줌으로써 핸들을 수동으로 조작 가능 하도록 한다.
  - Current Sensor(H7)
  을 통해 BLDC 모터에 대한 open/short/over current 상태를 감시한다. 만약, BLDC 모터 상태가 이상이 있을 경우
  - Motor Power Relay(H24)
  를 off 시켜, BLDC 모터의 전원을 차단해 줌으로써 핸들을 수동으로 조작 가능 하도록 한다.
  11) Sub MCU(H3)
  SPI 통신 처리 로직 (S11)과 Main MCU 상태 감시 로직(S12)이 실행된다.
  Sub MCU는 안전 메커니즘으로서,
  - Main MCU(H2)
  와의 SPI 통신을 통하여, Main MCU (H2)의 상태를 Main MCU로 부터의 계산 이벤트가 발생할 때 마다 모니터링한다.
  - Main MCU(H2)
  의 이상 동작을 감지하였을 경우,
  - Motor Power Relay(H24)
  를 off 시켜, BLDC 모터의 전원을 차단해 줌으로써 핸들을 수동으로 조작 가능 하도록 한다.

안전 요구사항을 통해 제품에 할당된 기능을 이해한다. 그리고 식별된 의존 고장이 다음의 안전 목표를 위배할 개연성이 있는 경우라면, 이에 대한 완화 조치가 마련된다.

• 1) Safety Goal 1
  주행 중 의도하지 않는 스티어링 휠의 움직임을 방지하여야 한다. (ASIL D)
  [안전 요구사항]
  - EPS_REQ-1:
  BLDC 모터의 상태를 매 20 ms 주기로 모니터링 하여야 한다.
  - EPS_REQ-2:
  주행 중 의도하지 않는 BLDC 모터의 움직임을 감지할 경우, BLDC 모터의 전원을 500 ms 이내에 차단해야 한다. (Manual 상태로 전환)
• 2) Safety Goal 2
  주행 중 스티어링 휠의 잠김을 방지하여야 한다. (ASIL D)
  [안전 요구사항]
  - EPS_REQ-1:
  BLDC 모터의 상태를 매 20 ms 주기로 모니터링 하여야 한다.
  - EPS_REQ-3:
  주행 중 운전자의 조향 의지를 BLDC 모터에 전달하였음에도 불구하고, BLDC 모터가 움직이지 않을 경우, BLDC 모터의 상태가 Stuck 일 것으로 판단하여 BLDC 모터의 전원을 500 ms 이내에 차단해야 한다.
  (Manual 상태로 전환)

시스템 아키텍처에서 식별된 하드웨어 및 소프트웨어 엘리먼트들이 분석 대상이며, 분석 대상 엘리먼트들에 대한 사용자 시나리오 기반 분석을 수행한다. 이때 운용 조건 및 환경 조건을 고려한다.

시스템 수준에 대한 의존 고장 분석의 깊이는 시스템 아키텍처 수준까지이며, 하드웨어와 소프트웨어 엘리먼트를 고려 하나, 회로도 수준(하드웨어 소자 수준) 또는 소프트웨어 소스 코드 수준까지 할 필요는 없다. 시스템 수준의 의존 고장 분석 결과로 시스템 아키텍처 설계가 개선될 수 있다(단, 본문에서는 지면상의 이유로 개선된 시스템 아키텍처에 대한 언급은 생략한다.).

하드웨어 아키텍처에서 식별된 하드웨어 엘리먼트들이 분석 대상이다. DFI 및 이에 대한 조치는 하드웨어 소자 단위로 기술한다. 하드웨어 수준에 대한 의존 고장 분석의 깊이는 하드웨어 소자 수준까지 이며, 입력 물로 하드웨어 아키텍처 및 회로도가 포함된 하드웨어 설계 명세서가 필요하다. 하드웨어 수준의 의존 고장 분석 결과로 하드웨어 설계가 개선될 수 있다(단, 본 논문에서는 지면상의 이유로 개선된 하드웨어 설계에 대한 언급은 생략한다.).

소프트웨어 아키텍처에서 식별된 소프트웨어 엘리먼트들이 분석 대상이다.

소프트웨어 수준에 대한 의존 고장 분석의 깊이는 소프트웨어 아키텍처 수준까지이며, 소프트웨어 코드 수준까지는 아니다.¹¹⁾ 입력물로 소프트웨어 아키텍처가 포함된 소프트웨어 설계 명세서가 필요하다. 그리고, ISO 26262-6:2018 부속서 E.2.2에 기술된 바와 같이, 일반적으로 하드웨어의 결함은 고려하지 않으나, 다음과 같은 일부 하드웨어 결함은 고려한다.¹¹⁾

• 1) 멀티 코어 시스템의 다른 Processing unit으로 매핑 되는 특정 소프트웨어(멀티 코어의 공유된 자원)
• 2) 소프트웨어 아키텍처 설계의 정적/동적 측면과 관련하여 소프트웨어가 실행되는 Processing unit의 세부 설계(멀티 테스킹에 따른 자원 공유, 인터럽트 처리. 특히 우선 순위)
• 3)소프트웨어 관련 하드웨어 결함과 관련하여 선택된 소프트웨어 안전 메커니즘의 달성 가능한 진단 커버리지

소프트웨어 수준의 의존 고장 분석 결과로 소프트웨어 아키텍처 설계가 개선될 수 있다(단, 본 논문에서는 지면상의 이유로 개선된 소프트웨어 아키텍처 설계에 대한 언급은 생략한다.).