지난 호에 1부 “ISO 26262 개요”에서 논의한 것처럼 안전은 대부분의 자동차 회사에서 집중하고 있는 핵심 요소 중 하나로 ISO 표준과 관련 용어 체계에 대해 설명했다. 2부에서는 제품의 안전성/신뢰성을 높임으로써 자동차용 반도체 공급업체와 고객이 더욱 안전성 높은 부품을 공급할 수 있도록 하는 설계 솔루션에 대해 검토한다.
글│아쉬시 고엘 <ashish.goel@freescale.com>
사친 자인 <sachin.jain@freescale.com>
프라샨트 바르가바 <prashantb@freescale.com>, 프리스케일
설계 오류
ISO 26262에 따르면, 가혹한 환경 조건으로 인해 발생하는 불규칙한 오류에 대응할 수 있도록 충분히 안정적으로 설계가 이뤄져야 한다.
우주선과 알파 입자가 반도체 내부에서 하나 이상의 플립플롭 상태를 변화시키거나 순 가치를 일시적으로 변화시키기에 충분한 전하를 만들어낼 수 있다는 것이 알려졌다. 노화 효과로 인해 플립플롭이 장기간 동안 값을 유지하지 못할 수도 있다. 이러한 장애는 비트 반전(BF)과 같이 일시적인 속성을 가지거나 디바이스의 마모로 인한 영구적인 속성을 가질 수 있다. 장애는 디바이스의 오작동과 그에 따른 안전 목표의 위반(손상 발생)으로 이어질 수 있다.
a) 단일 장애 지점(SPF)
장애는 장애 허용 시간에 따라 두 부분으로 분류할 수 있다.
SPF란 출력을 즉시 유효하지 않은 상태로 변화시킴으로써 즉각적인 기능상 오류(장애 허용 시간이 짧음)를 일으키고 오류를 위험한 것으로 만드는(안전 목표의 실패) 장애를 가리킨다. 이러한 오류는 가능한 빨리 감지하고 정정 조치를 이행해야 한다. 이러한 오류의 예로 스티어링과 같은 핵심 기능의 고장으로 이어질 수 있는 CPU 코어의 오작동을 들 수 있다.
b) 잠재적 장애
잠재적 장애란 출력을 즉시 유효하지 않은 상태로 변화시키지는 않지만 부품 기능 저하를 일으킬 수 있는 장애를 가리킨다(장애 허용 시간이 김). 이러한 오류만으로 즉시 기능상 장애가 발생하지 않을 수도 있지만 일정한 후속 장애 상황이 이어진다면 위험할 수 있다. 잠재적 장애는 주기적으로 점검하고 정정 조치를 이행해야 한다. 잠재적 장애의 예로 메모리 내 비트 반전 또는 메모리의 데이터 저장 기능과 같은 메모리 기능 저하를 들 수 있다.
기능의 중요성에 따라 MCU는 장애에 영향을 받지 않는 장애 무시 모드, 또는 사용자에게 MCU에 결함이 발생했으며 더 이상 작동의 안전을 보장할 수 없음을 알리는 장애 표시 모드를 유지해야 한다.
실패율 의존도
ISO 26262에는 장애에 대해 높은 내성을 보장할 수 있는 프로세스가 정의돼 있다. 실패율은 기술, 부품이 작동할 환경 등 다양한 요소에 따라 달라진다. 이러한 매개변수는 일반적으로 반도체 공급업체에서 제어할 수 없다. 따라서 반도체 공급업체는 장애를 가능한 빨리 감지하거나 장애의 영향을 줄이는 방법으로 신뢰성을 높일 수 있는 설계/아키텍처 솔루션을 검토해야 한다.
설계 솔루션
아래에 회로 신뢰성을 높이기 위해 구현할 수 있는 몇 가지 설계 솔루션이 논의돼 있다.
a) 록스텝 모드 및 지연 록스텝 모드
디바이스에 추가 CPU가 통합된다. CPU 중 하나가 오작동을 하면 비교 로직에 의해 즉시 감지된다. 오류가 감지되면 안전 모드로 작동하며 사용자에게 경고를 보내도록 시스템을 설계할 수 있다.
CPU 작동을 보장하는 또 다른 방법은 기본 CPU가 다른 검사기 CPU보다 하나 또는 두 클록 느리게 작동하도록 하고 이를 고려해 비교를 수행하는 것이다. 이를 지연 록스텝 작동 모드라고 한다.
b) 장애에 대한 설계 내성을 높일 수 있도록 구조적 예비성 추가
설계에 포함된 핵심적인 플롭을 그림 5에 나온 것처럼 3중 플롭 구조로 바꿀 수 있다. 플롭을 추가하면 플롭 중 하나에서 비트 반전이 발생해 일어나는 회로 오작동의 위험을 줄일 수 있다. 플롭이 많을수록 동일한 구조 내의 두 플롭이 동시에 플립할 확률이 줄어든다.
2개의 ADC로 동일한 양을 측정하는 등과 같이 SoC 내의 핵심 모듈/주변기기를 복제해 내결함 작동을 구현할 수 있다. 모듈에 오류가 발생하면 백업 모듈을 활성화할 수 있다. 모듈/주변기기의 오류를 감지하는 구성 공간의 정기적인 LBIST, ECC 또는 CRC 스캔과 같은 안전 보호 메커니즘이 적용돼야 한다.
c) 잡음에 대한 설계 내성을 높일 수 있도록 데이터 예비성 추가
마스터에서 ECC(오류 정정 코드)를 생성하고 주소 및 데이터와 함께 전송해 목적지에서 검사할 수 있다. 잡음으로 인한 비트 반전이 일어난 경우, 수신측에서 이 오류를 감지하고 이 종단간 ECC 검사를 통해 정정 조치를 이행할 수 있다. 마찬가지로 핵심적인 모듈은 로컬 ECC 검사도 가능하다.
또한 RAM에서 쓰기가 일어날 때 데이터를 ECC와 함께 RAM에 저장하고, 나중에 읽을 때 ECC 오류를 검사할 수 있다.
d) 입력 활동 부재(장애)의 감지를 보장하는 추가 검사
특정 통신 또는 센서 인터페이스와 같은 핵심적인 인터페이스의 경우, 장애가 발생하지 않아야 하므로 인터페이스가 유휴 상태가 되었을 때 감지할 수 있는 메커니즘이 필요하다. 가장 간단한 방법은 유휴 상태 또는 센서나 인터페이스 입력의 부재를 감지하는 상태 머신을 사용하는 것이다. 상태 머신은 또한 입력에서 글리치(잡음)를 감지하고 필터링할 수 있을 정도로 지능적이어야 한다. 시스템에서 유휴 상태 또는 잡음을 감지하면 필요한 정정 조치를 실행할 수 있는 코어로 인터럽트를 전송해야 한다.
유휴 상태를 감지하는 몇 가지 방법:
- 데이터가 장시간 동안 변화되지 않는지 확인
- 입력단의 전류 흐름 확인
비슷한 방식으로 예를 들어 ADC 입력단 등에서 오버플로 상태를 확인해야 한다. ADC 입력은 항상 범위를 확인해야 하며, ADC 값이 권장 변경 범위 내가 아닐 경우 코어에 대한 인터럽트가 생성돼야 한다. 코어는 정정 조치를 실행할 수 있다.
전압 모니터를 사용해 비작동 전압 상태를 감지할 수 있다. 전원 공급기가 지정된 범위를 벗어나는 즉시, 디바이스를 안전 모드로 변경하는 인터럽트를 CPU에 전송할 수 있다.
통신 인터페이스에 내장된 CRC 검사 기능을 통해 인터페이스의 정확한 작동과 안전성을 보장할 수 있다.
e) 코드 실행 전 또는 정기적인 주기로 오류 확인
반도체의 가동 직후에 LBIST, MBIST를 실행해 모든 회로에 문제가 없는지 확인해야 한다. 회로의 정확성을 확인한 후에만 실제 애플리케이션을 시작해야 한다. LBIST를 통해 대부분의 잠재적 장애를 포착할 수 있다. 주기적인 간격으로 이 루틴을 실행해 추가적인 안정성을 확보할 수 있다.
소프트웨어에서 핵심 구성 공간/인터페이스의 정기적인 스캔(CRC 검사)을 실행해 SoC의 내결함 통신/작동을 보장해야 한다.
f) 실행 과정 도중 오류가 감지되는 경우 시스템을 안전 모드로 전환
시스템에서 오류가 감지되는 경우, 치명적인 오류라면 시스템을 초기화하고 치명적이지 않은 오류라면 시스템을 안전 모드로 전환해야 한다. 시스템에서 계속 치명적인 오류가 발생한다면 시스템의 해당 부분을 애플리케이션에서 사용하지 않아야 한다.
g) 감시 타이머
감시 타이머는 소프트웨어 오작동을 감지하는 데 사용된다. 소프트웨어 오작동은 불규칙한 하드웨어 장애로 인해 발생할 수 있다. 소프트웨어는 감시 타이머에 정기적인 서비스를 제공해야 한다. 소프트웨어에서 필요한 주기에 감시 타이머에 서비스를 제공하지 못할 경우 반도체를 초기화하거나 안전 상태로 전환해야 한다.
h) 주요 신호의 런타임 검사
설계에는 소프트웨어의 디버깅을 간편하게 해주는 로직이 다수 적용된다. 이러한 로직은 실제 애플리케이션에서 유휴 상태 또는 정적인 비작동 상태여야 한다. 해당 신호를 모니터링해 그러한 상태가 발생하면 시스템을 안전 상태로 전환시킬 수 있다. SoC의 정적 구성 또한 모니터링할 수 있다.
i) 클록 모니터
시스템 클록, PLL의 입력 및 출력 클록, 주변기기 프로토콜 클록 등과 같은 주요 클록을 모니터링해야 한다. 클록이 범위를 벗어나거나 비활성 상태가 되는 것을 감지할 수 있는 클록 모니터링 장치를 SoC 내에 유지해야 한다. 클록이 범위를 벗어나거나 비활성 상태가 되면, SoC가 자동으로 더 안정적인 다른 클록 소스로 전환하거나 코어에서 필요한 조치를 실행하도록 인터럽트를 발생시킬 수 있다.
j) 플래시 검사
모든 코드는 플래시 내에 상주하므로 플래시의 완벽한 동작을 확인하는 것이 절대적으로 필수이다. 한 가지 방법은 플래시 어레이의 일부 또는 전체에 ECC를 사용해 어레이 무결성 검사를 수행하는 것이다. ECC에서 보정이 필요함이 드러나면, 플래시에 리드백(readback)을 실행해(예: 블록의 CRC) 실행된 보정이 멀티 비트가 아니라 싱글 비트 오류로 인한 것임을 확인해야 한다. 리드백 패턴은 예상 값과 비교해 검사되거나 또는 오류의 실제 특성을 밝히기 위한 다른 ECC 오류 보정/감지를 트리거하는 데 충분한 수의 패턴을 강제로 읽도록 만들 수 있다.
k) IRQ 검사
IRQ 생성 로직은 일반적으로 복제되지 않으므로 시스템 IRQ 처리기가 잘못되거나 누락된 인터럽트를 감지할 수 있어야 한다. 이는 ISR(인터럽트 서비스 루틴)을 사용해 인터럽트가 정확한 권한으로 올바르게 호출되었는지 확인하는 검사를 수행하는 방법으로 가능하다. 예를 들어, ISR을 통해 인터럽트가 실제로 레지스터 내에서 활성화되었으며 플래그가 설정되었는지 여부를 검사할 수 있다. 주기적인 인터럽트의 경우 타이머를 사용하여 인터럽트가 올바르게 생성되었는지 확인할 수 있다. 최종 구현 방식은 SoC 요구에 따라 크게 달라질 수 있지만, 원활한 작동을 위해서는 잘못된 인터럽트 또는 의사 인터럽트를 식별하는 것이 필수적이다.
l) 폐회로 피드백
모듈의 피드백과 피드백을 확인하는 모니터를 사용하여 모듈의 작동 상태를 검사하는 메커니즘이 필요하다. 예를 들어, RAM에 대한 쓰기 액세스는 RAM 내부에서 래치 형태가 된다. 이러한 래치 상태의 주소, 데이터, 컨트롤을 래치 값이 원래 액세스와 일치하는지 확인할 수 있는 모니터로 피드백할 수 있다. 또 다른 예로 모터의 회전을 입력하고 프로그래밍된 원하는 컨트롤과 비교해 회전각을 검사할 수 있다. 불일치가 있을 경우 정정 조치가 트리거된다.
결론
의식적으로 또는 무의식적으로 사용돼 본질적으로 추가적인 안정성을 제공하며 디바이스가 가혹한 환경에서 장애 없이 계속 작동하도록 보장하는 다수의 설계 기법이 존재한다. 이러한 기법은 의료, 항공 전자, 자동차 등의 일부 핵심 애플리케이션에서 한층 더 중요성이 부각되고 있다. 현재 이러한 설계 기법이 준수돼 최종 사용자의 안전을 강화하고 있는지 확인하는 특정 표준이 있다. 자동차 애플리케이션의 경우 ISO 26262가 그러한 표준이다.
주요 대형 자동차 제조사에서 직접 이러한 표준을 도입 및 이행함에 따라, 모든 공급업체가 공급 제품에서 해당 표준을 준수하도록 강요하는 흐름이 거세지고 있다. 결국 궁극적인 목표는 자동차 업계에서 안전한 제품의 개발을 지원 및 촉진하는 것이며, 달리 말하자면 “최종 사용자의 안전을 강화”하는 것이다.
<저작권자 © AEM. 무단전재 및 재배포, AI학습 이용 금지>