본문 바로가기
자율주행 개발 프로세스/Functional Safety (ISO26262)

ISO26262 - Processing Unit 의 Safety Mechanism 및 Diagnostic Coverage

by 멘토_ 2022. 3. 19.
반응형

안녕하세요. 자율주행 SW 안전 전문가를 목표로 하는 플라잉 준입니다.

 

오늘은 차량의 기능안전(ISO26262) 과 관련하여 E/E 시스템의 하드웨어 요소 중 하나인 Processing Unit 과 관련된 안전 매커니즘 (Safety Mechanism) 및 진단 커버리지 (Diagnostic Coverage) 에 대해 정리하도록 하겠습니다.

 

Processing Unit

Processing Unit 은 E/E 시스템의 하드웨어 요소를 통제하고 프로그램의 연산을 실행 및 처리하는 장치입니다. 위의 E/E 시스템에 나와있는 Signal Processing Accelerator 도 하나의 Processing Unit 으로 볼 수 있습니다. 

 

Safety Mechanism & Diagnostic Coverage

 이러한 연산 및 처리하는 장치인 Processing Unit 에 대해 적용할 수 있는 안전 매커니즘을 정리하면 다음과 같습니다.

  1. Self-test by software: limited number of patterns
  2. Self-test by software cross exchange between two independent units
  3. Self-test supported by hardware (one-channel)
  4. Software diversified redundancy (one hardware channel)
  5. Reciprocal comparison by software
  6. HW redundancy (e.g. dual core lockstep, asymmetric redundancy, coded processing)
  7. Configuration register test
  8. Stack over/under flow detection
  9. Integrated hardware consistency monitoring

추가로, E/E 시스템 전체에 적용할 수 있는 안전 매커니즘도 적용이 가능하며 이는 다음과 같습니다.

  1. Failure detection by online monitoring
  2. Comparator
  3. Majority voter
  4. Dynamic principles
  5. Analogue monitoring of digital signals
  6. Self-test by software cross exchange between two independent units

Processing Unit 은 내부적으로 다양한 기능을 수행하는 장치로 이에 대한 안전 매커니즘도 다양하게 적용할 수 있습니다.

 

각 안전 매커니즘에 대한 설명은 아래와 같은 형태로 정리하겠습니다.

 

Safety Mechanism (Diagnostic Coverage : Coverage)

목적 : 

설명 : 

예제 :

참고사항 :

 

Self-test by software (limited number of patterns (one channel) (DC : 중간 (Medium, 90%))

목적 : 소프트웨어를 이용해 처리 장치 및 물리적 저장소(예: 레지스터) 또는 기능 장치(예: 명령어 decoder 또는 EDC coder/decoder) 로 구성된 기타 하위 요소의 오류를 가능한 한 빨리 감지하기 위함

설명 : 물리적 스토리지(예: 데이터 및 주소 레지스터) 또는 기능 유닛(예: 명령 디코더) 테스트용 데이터 패턴 / 셋트를 구축하고 해당 데이터 패턴을 사용하여 소프트웨어 에서 자체 테스트를 수행하여 오류를 감지

예제

  • 처리 장치는 명령당 하나 이상의 패턴을 적용하여 기능적 정확성을 테스트합니다.일반적으로 모든 전용 및 특수 목적 레지스터, 코어 타이머 및 예외를 다룰 수 있는 것은 아닙니다.테스트된 게이트의 실제 적용 범위를 결정하려면(커버된 명령어와 대조적으로) 일반적으로 광범위한 오류 시뮬레이션이 필요합니다.
  • 이 테스트는 소프트 오류에 대해 매우 제한적이거나 전혀 적용되지 않습니다.
  • 파이프라인 또는 타이밍 관련 오류 모드와 같은 주문 종속성에 대한 적용 범위는 제한될 수 있습니다.
  • 안전 관련 경로에서 실행되지 않은 명령은 테스트에서 생략할 수 있지만 처리 장치의 모든 게이트가 테스트되지는 않으므로 적용 범위가 제한될 수 있습니다.
  • EDC 코더/디코더와 같은 하위 요소의 경우 소프트웨어는 미리 작성된 의도적으로 손상된 단어를 읽어 EDC 로직의 동작을 테스트할 수 있습니다.적용 범위는 패턴의 양과 풍부함에 따라 다릅니다. 이 테스트는 소프트 오류에 대한 커버리지를 제공하지 않습니다.
  • 손상된 단어는 EDC와 메모리 인터페이스에 데이터와 코드 비트 모두에 액세스할 수 있는 HW 스위치가 있는 경우 소프트웨어 테스트 자체에 의해 기록될 수도 있습니다.

 

 

Self-test supported by hardware (one-channel) (DC : 중간 (Medium, 90%))

목적 : failure detection 을 위한 특정 하드웨어 모듈을 사용하여 처리 장치 및 물리적 저장소(예: 레지스터) 또는 기능 장치(예: 명령어 decoder 또는 EDC coder/decoder) 로 구성된 기타 하위 요소의 오류를 가능한 한 빨리 감지하기 위함

설명

  • 추가적인 특수 하드웨어 시설은 게이트 수준에서 처리 장치 및 기타 하위 요소(예: EDC 코더/디코더)의 오류를 감지하는 자체 테스트 기능을 지원합니다.
  • 테스트는 높은 적용 범위를 달성할 수 있습니다.
  • 일반적으로 방해 특성으로 인해 처리 장치의 초기화 또는 전원 차단 시에만 실행됩니다.
  • 일반적인 사용은 다중 지점 오류 감지입니다.

예제

  • EDC 코더/디코더와 같은 하위 요소의 경우 논리 BIST와 같은 특수 HW 메커니즘을 추가하여 코더-디코더에 대한 입력을 생성하고 예상 결과를 확인할 수 있습니다.
  • 일반적으로 입력은 랜덤 패턴 생성기(예: MISR)에 의해 생성됩니다. 적용 범위는 패턴의 양과 풍부함에 따라 다르지만 일반적으로 자동 패턴 생성으로 인해 적용 범위가 상당히 높습니다.
  • 이 테스트는 소프트 오류에 대한 커버리지를 제공하지 않습니다.

 

Self-test by software cross exchange between two independent units (DC : 중간 (Medium, 90%))

목적 : 물리적 저장 장치(예: 레지스터)와 기능 장치(예: 명령어 디코더)로 구성된 처리 장치의 오류를 가능한 한 빨리 감지하기 위함

설명 : 

장애 감지는 두 개 이상의 처리 장치를 통해 완전히 실현됩니다.

각 처리 장치는 물리적 스토리지(데이터 및 주소 레지스터)와 기능 유닛(예: 명령어 디코더)을 테스트하기 위해 자체 테스트(예: 워킹 비트 패턴)를 수행하는 추가 소프트웨어 기능을 실행 후 처리 장치는 결과를 교환하여 오류를 감지합니다.

해당 safety mechanism 은 soft error 에 대해 매우 제한적이거나 전혀 적용되지 않습니다.

 

Software diversified redundancy (one hardware channel) (DC : 높음 (High, 99%))

목적 : 소프트웨어 비교를 통해 처리 장치의 오류를 가능한 한 빨리 감지

설명 :

 

해당 mechanism 은 하나의 하드웨어 채널을 대상으로 값을 입력 받아 두 개의 다른 소프트웨어로 처리하여 값의 비교를 통해 오류를 감지

  • 경우에 따라 다른 하드웨어 리소스(예: 다른 RAM, ROM 메모리 범위)를 사용하면 diagnostic coverage 를 높게 측정 할 수 있음

 

예제

 

기본 경로라고 하는 한 가지 구현은 잘못 계산된 경우 위험을 초래할 수 있는 계산을 담당합니다.

중복 경로라고 하는 두 번째 구현은 기본 경로의 계산을 확인하고 오류가 감지되면 조치를 취하는 역할을 합니다.

종종 중복 경로는 소프트웨어 다양성을 제공하기 위해 별도의 알고리즘 설계 및 코드를 사용하여 구현됩니다.

두 경로가 모두 완료되면 두 개의 중복 소프트웨어 구현의 출력 데이터 비교가 수행됩니다.

감지된 차이점은 실패 메시지로 이어집니다.

설계에는 두 경로를 조정하고 일시적인 오류에 대한 경로를 재동기화하는 방법이 포함됩니다.

 

일반적으로 비교에는 다양한 소프트웨어 경로로 인한 사소한 차이를 허용하는 일부 유형의 히스테리시스 및 필터링이 포함됩니다.

알고리즘 다양성의 예는 A+B=C 대 C-B=A, 일반 계산을 사용하는 경로와 2의 보수 수학을 사용하는 다른 경로입니다.

중복 경로는 기본 경로 계산에 대한 크기 또는 속도 제한 검사만큼 간단할 수 있습니다.

 

이 안전 메커니즘의 또 다른 버전은 중복 경로를 기본 경로의 정확한 복사본으로 구현하거나 기본 경로를 두 번 실행하는 것입니다. (soft error 에만 적용 가능)

예상 출력 세트에 대해 검증할 출력을 생성하는 알려진 입력으로 코드를 세 번째로 실행하면 Diagnostic Coverage Medium (중간) 달성 가능합니다.

해당 메커니즘은 통과-실패 기준(비교 결과가 정확히 일치할 것으로 예상됨)과 구현(중복 경로를 설계할 필요가 없음)이 매우 쉽습니다.

그러나 동일한 코드가 여러 번 실행되기 때문에 개념에서는 history terms(예: dynamic states, integrators, rate-limits, etc.)를 보존해야 합니다.

 

참고사항

  • 기본 경로와 이중화 경로 간의 잠재적인 공통 원인 오류로 인해 추가 워치독 프로세서를 사용하여 질문 및 응답 진단을 통해 기본 컨트롤러의 작동 확인 가능

Reciprocal comparison by software (in separate processing units) (DC : 높음 (High, 99%))

목적 : 소프트웨어 비교를 통해 처리 장치의 오류를 가능한 한 빨리 감지

설명 : 

두 개의 처리 장치가 데이터 (ex. 결과, 중간 결과 및 테스트 데이터 포함)를 상호 교환합니다.

데이터 비교는 각 장치의 소프트웨어를 사용하여 수행되며 감지된 차이는 오류 메시지로 이어집니다.

이 접근 방식은 서로 다른 프로세서 유형과 별도의 알고리즘 설계, 코드 및 컴파일러가 사용되는 경우 하드웨어 및 소프트웨어 다양성을 허용합니다.

설계에는 프로세서 간의 차이 (ex. 루프 지터, 통신 지연, 프로세서 초기화)로 인한 false error detection 를 방지하는 방법이 포함됩니다.

경로는 듀얼 코어 프로세서의 별도 코어를 사용하여 구현할 수 있습니다.

이 경우 방법에는 두 코어의 공유 다이 및 패키지로 인한 일반적인 원인 장애 모드를 이해하기 위한 분석이 포함됩니다.

참고사항

예제

 

HW redundancy (e.g. dual core lockstep, asymmetric redundancy, coded processing) (DC : 높음 (High, 99%))

목적 : 내부 또는 외부 결과를 단계별로 비교하여 처리 장치의 오류를 감지하기 위함

설명 : 

이러한 유형의 진단 기술인 Dual Core Lockstep의 한 버전에서는 두 개의 대칭 처리 장치가 하나의 다이에 포함되어 있습니다(참고문헌 [22] 참조).

처리 장치는 잠금 단계(또는 고정 기간 지연)로 중복 작업을 실행하고 결과를 비교합니다.

불일치로 인해 오류 상태가 발생하고 일반적으로 재설정 상태가 됩니다.

이것은 일시적인 오류 및 ALU 유형 오류에 매우 효과적입니다.

이중화 수준에 따라 적용 범위는 메모리 주소 지정 라인 및 구성 레지스터로 확장될 수 있습니다.

이 기술은 병렬 경로에 대한 별도의 코드가 필요하지 않다는 장점이 있지만 단일 처리 장치의 성능만 제공하는 두 개의 처리 장치를 갖는 단점이 있습니다.

좋은 설계에서는 일반적인 원인 오류를 이해하고 해결합니다(예: 일반적인 클럭 오류).

이 접근 방식 자체는 체계적인 오류에 대한 커버리지를 제공하지 않습니다.

 

비대칭 중복과 같은 다른 유형의 하드웨어 중복이 가능합니다.

이러한 아키텍처에서 다양하고 전용 처리 장치는 내부 및 외부 결과의 단계별 비교를 가능하게 하는 인터페이스를 통해 주 처리 장치와 밀접하게 연결됩니다.

이것은 DC 모두에 매우 효과적입니다. (직류) 오류 모델 및 소프트 오류용 또한 인터페이스는 예를 들어 처리 장치 레지스터 뱅크에 영향을 미치는 오류의 경우 복잡성을 줄이고 오류 감지 대기 시간을 단축합니다.

병렬 경로에는 별도의 코드가 필요하지 않으며 전용 처리 장치는 기본 처리 장치보다 작을 수 있습니다.

하드웨어 다양성은 일반적인 원인 오류 및 시스템 오류에 대한 효과적인 적용 범위를 제공합니다.

이 접근 방식의 단점은 진단 범위를 증명하기 위해 자세한 분석이 필요할 수 있다는 것입니다.

 

 

Configuration register test (DC : 높음 (High, 99%))

목적 : 처리 장치의 구성 레지스터에서 가능한 빨리 오류를 감지하기 위함

설명 : 

구성 레지스터 설정을 읽은 다음 예상 설정(예: 마스크)의 인코딩과 비교하여 설정이 일치하지 않으면 레지스터가 의도한 값으로 다시 로드되며 일치하지 않는 횟수를 카운팅 합니다. 이 카운팅 횟수가 지속적으로 상승하면 오류라고 판단

 

Stack over/under flow detection (DC : 낮음 (Low, 60%))

목적 : stack over/under flow 를 감지하기 위함

설명 : 

Stack 의 Over / Under 경계는 미리 정해놓고, Processing Unit 이 실행 중에 메모리의 주소 값을 확인하여 해당 주소 값이 Over or Under 의 경계 값을 넘었을 경우 오류를 감지

  • 스택 경계 외부의 쓰기가 메모리 관리 장치에 의해 제어되는 경우 테스트가 필요하지 않습니다.

 

Integrated hardware consistency monitoring (DC : 높음 (High, 99%))

목적 : 처리 장치의 부적합 상태 (condition) 를 감지하기 위함

설명 : 

대부분의 프로세서에는 오류가 감지될 때 하드웨어 예외를 트리거하는 메커니즘이 장착되어 있습니다(예: 0으로 나누기 및 잘못된 연산 코드).

그런 다음 이러한 오류의 인터럽트 처리를 사용하여 이러한 조건을 트랩하여 영향으로부터 시스템을 격리할 수 있습니다.

일반적으로 하드웨어 모니터링은 시스템 오류를 감지하는 데 사용되지만 특정 종류의 임의 하드웨어 오류를 감지하는 데 사용할 수도 있습니다.

이 기술은 일부 코딩 오류에 대해 낮은 적용 범위를 제공하며 좋은 설계 방법입니다.

 

Failure detection by online monitoring (DC : 낮음 (low, 60%))

목적 : 온라인 상황에서 정상적인 작동에 대한 응답으로 시스템의 동작을 모니터링하여 오류를 감지하기 위함

설명 : 특정 조건에서 시스템의 시간 동작에 대한 정보를 사용하여 오류를 감지하는 매커니즘

예제

  • 스위치가 정상적으로 작동되고 있는 상황에서 예상 시간에 상태가 변경되지 않으면 오류가 감지된 것입니다. 일반적으로 문제가 발생하는 특정 Element / Component 를 찾는건 불가능하다.

참고사항

  • 일반적으로 online monitoring 을 구현을 위한 특정 하드웨어 요소는 없음
  • 온라인 모니터링은 시스템 활성화의 특정 조건과 관련하여 시스템의 비정상적인 동작을 감지
    예를 들어, 차량 속도가 0과 다를 때 특정 파라미터가 반전되면 이 파라미터와 차량 속도 사이의 일관성 감지가 고장 감지로 이어집니다.

온라인 모니터링 기법은 크게 두 가지로 구분됩니다.

  • 1. 모델 기반 기법 (Model-based technique)
    • State estimation, parity space, parameter identification 등의 기법을 적용하여 센서가 모니터링하는 대상에 대한 수하적 모델을 개발하여 모니터링
  • 2. 모델 프리 기법 (Model-free technique)
    • 대상에 대한 수학적 모델이 아닌 관찰된 결과를 기반으로 개발된 감지기를 통해 모니터링

모델 기반 기법 (Model-based technique)

모델 기반 기법의 경우는 위에서 설명한 수학적 모델에 기능적으로 중복된 값들을 입력하여 예측값 계싼, 예측값과 실제 모니터링 된 값 비교 등을 수행함으로써 오류를 감지합니다. 이는 제어 대상에 대한 이해를 바탕으로 함으로 화이트 박스 접근 (white-box approach) 로 분류되며 해당 기법을 적용할 경우 아래의 기능들이 개발되어야 합니다.

  • 모델 (model): 기능적으로 중복된 입력 값들을 활용하여 예측 값을 계산
  • 차이 측정 (distance measure): 예측 값과 실제 모니터링 된 센서 값과의 차이 (residual0 을 계산, 신호 상의 노이즈 등에 대한 강건한 판단을 위해 평균, 분산 등의 통계적 연산이 활용
  • 오류 감지 (detecting rule): 측정된 차이를 통해 오류 여부 판정

모델 프리 기법 (Model-free technique)

모델 프리 기법의 경우의 오류 감지기는 일반적으로 휴리스틱 기반의 규칙들로 구성되거나, 인공지능 기법들인 신경망 (neural network), 패턴 분류 (pattern classification) 들이 활용됩니다. 해당 기법은 모델 기반 기법과는 다르게 제어 대상에 대한 이해 보다는 제어 대상의 외부에서 관찰된 결과에 기반함으로 블랙-박스 접근(black-box approach) 로 분류됩니다.

 

Comparator (DC : 높음 (High, 99%))

목적 : 독립 하드웨어 또는 소프트웨어의 (비동시적) 오류를 가능한 한 빨리 감지하기 위함

설명 : 독립 하드웨어의 출력 신호 또는 독립 소프트웨어의 출력 정보는 Comparator 에 의해 주기적으로 또는 지속적으로 비교하여 두 값의 차이가 존재할 경우 오류를 감지하는 매커니즘

예제

  • 두 개의 처리 장치가 데이터(결과, 중간 결과 및 테스트 데이터 포함)를 상호 교환합니다. 데이터 비교는 각 장치의 소프트웨어를 사용하여 수행되며 감지된 차이는 실패 메시지로 이어집니다.

 

Major voter (DC : 높음 (High, 99%))

목적 : 세 개 이상의 채널 중 하나에서 오류를 감지하고 마스킹하기 위함

설명 : 동일한 값을 출력하는 세 개 이상의 채널에서 다수결 원칙(2 out of 3, 3 out of 4, m out of n)을 사용하여 다른 값을 출력하는, 즉 오류가 발생한 컴포넌트를 감지하는 매커니즘

참고사항

  • Comparator 와 달리 다수결 방식은 한 채널이 손실된 후에도 이중화 채널의 기능을 확보하여 가용성을 높임

 

Dynamic principle (DC : 중간 (Medium, 90%))

목적 : 동적 신호처리 (dynamic signal processing) 을 이용하여 정적 오류를 감지

설명 :  정적 신호(내부 또는 외부에서 생성)의 강제 변경을 통해 요소의 정적 오류를 감지하는 매커니즘

참고사항

  • 이 기술은 종종 전기 기계 요소와 관련됨

 

Analog monitoring of digital signals (DC : 낮음 (Low, 60%))

목적 : 측정된 신호의 신뢰도를 향상시킵니다.

설명 :  잘못된 신호 레벨을 감지하기 위해 binary signal 를 아날로그 레벨에서 평가 하여 오류를 감지하는 매커니즘

예제

  • 스위치는 신호가 높을 때 닫히고 낮으면 열림입니다.지정된 범위는 접지 단락, 공급 전압 단락 및 개방 커넥터가 잘못된 레벨로 이어지는 방식으로 선택
  • 모니터링은 출력 레벨이 지정된 범위 내에 있는지 감지

 

Self-test by software cross exchanged between two independent units (DC : 중간 (Medium, 90%)

목적 : 물리적 저장 장치(예: 레지스터)와 기능 장치(예: 명령어 디코더)로 구성된 처리 장치의 오류를 가능한 한 빨리 감지하기 위함

설명 : 2개 이상의 처리 장치를 통해 각 장치의 self-test 를 수행하여 처리 결과를 교환하여 오류를 감지하는 매커니즘

참고사항

  • 해당 매커니즘은 Soft error 에 대해서는 매우 제한적이거나 적용되지 않음

 

정리

위에서 정리한 내용은 특정 도메인에서 프로젝트를 진행할 때 참고할 수 있는 내용 정도로 생각해 주시고 활용해주시면 감사하겠습니다 :)

 

긴글 읽어 주셔서 감사드립니다.

반응형