기능안전성은 전문적인 요구사항에서 일반적인 요구사항이 되고 있다. 기능안전성은 IP 업체들이 이행하고 벤더들이 각 개발에 대한 성과를 최대한 많은 실리콘파트너들에게 라이선스하기 위해 실행해야 하는 IP 라이선스 모델에 대한 요구사항을 증가시키고 있으며, 이는 파트너에서도 마찬가지다. 품질과 내구성 측면에서 확고한 뿌리를 내리고 있기 때문에 기능안전성을 실현하기 위해 수행한 작업들은 광범위한 이점을 지니고 있다. 이러한 이점은 산업 전반에서 품질 및 제품 탄력성을 향상시키는 기폭제 역할을 한다.

자동차 업계는 자동차를 설계, 사용 및 판매하는 방식을 변화시키는 급속한 발전 시기에 들어갔다. 운전자 안전 기술, 교통 정체, 환경 문제, 자동차를 사용하는 방법에 대한 기본적인 전제조건 등이 차세대 자동차에 영향을 미치고 있다. 이러한 문제를 해결하기 위해 많은 OEM 업체가 컴퓨팅 성능을 향상시켜 통제권을 강화하고 있다. Euro NCAP은 차선 유지 지원과 같은 안전성 지원 기능들이 최고 등급인 5스타를 달성하기 위해 요구된다고 밝혔다.

각 시장 영역의 프로세서 수는 급격히 증가했으며 현재 자동차 1대 당 평균 40~50개의 프로세서를 탑재하고 있으며 거의 120개 프로세서로 이뤄진 고급형 모델도 출시되고 있다. 또한 세미캐스트 리서치(Semicast Research)는 엔진룸의 자동차 ECU 관련 연간 매출 규모가 2015년부터 2022년까지 연평균 7%의 성장률을 기록하면서 530억 달러에서 860억 달러로 증가할 것으로 전망했다. 이로 인해 자동차 전자부품 사업은 반도체 업계에는 성장을 위한 좋은 기회가 되고 있다.

이런 반도체 칩들은 무선통신을 이용해 동력장치의 배기가스 문제를 향상시키고 안전성을 높이며 다른 자동차 및 도로 인프라와 연결하게 될 것이다. 하지만, 이렇게 정교한 시스템들은 운전자를 안전하게 지켜주는 풀 프루프(fool-proof) 방식, 일명 기능 안전성(functional safety)을 요구한다.

기능안전성이란 무엇인가

“기능안전성이란 전기/전자 시스템의 오작동으로 발생한 위험에 따른 비합리적인 위험이 없는 상태”쉽게 말해, 기능안전성은 제품에 문제가 생긴 경우에도 계속해서 안전하게 작동되도록 보장하는 것으로, 특정 시장에 제약 없는 개발을 주도하는 ARM의 문화적인 사고방식(cultural mind-set)을 형성하고 있다.

각 산업은 일반적으로 개발에 대한 지침과 최소한의 기대치를 규정하는 표준을 보유하고 있으며 자동차 전자부품의 경우, 기능안전성을 규정한 ISO 26262 표준이 있다.

전기 및 전자 시스템의 표준인 IEC61508과 항공기 전자 하드웨어의 표준인 DO-254와 같이 각 시장의 표준마다 고유의 정의를 보유하고 있고, 더욱 중요한 것은 목표 수준을 포함해 엔지니어링 개발을 위한 특정 용어와 지침을 규정하고 있다는 것이다. 따라서, 개발 중간에 새로운 개발 프로세스를 추가하는 것은 비효율적일 수 있기 때문에 개발에 착수하기 전에 목표 시장을 파악하고 적합한 프로세스에 따라 진행하는 것이 중요하다.



그림 1은 실리콘 IP에 적용되는 다양한 표준을 나타낸다. 실제로 각 표준의 특정 요구사항을 이해하고 다양한 표준에 정의된 공통된 실행방안을 적용해 여러 표준의 요구사항을 충족시킬 수 있다.

실제로 기능안전성은 목표로 삼은 표준에 따라 독립 평가기관에게 안전성을 입증할 수 있는 시스템을 뜻한다. 안전성은 기능의 수행이나 점진적인 기능 저하(graceful degradation) 또는 리셋 및 재시작으로 연결되는 완전 종료 등에서 일어날 수 있는 예측 가능한 장애 모드(failure mode)를 필요로 한다.

고장(fault)이 난다고 해서 모든 것이 위험한 상황(Hazardous event)으로 바로 이어지는 것은 아니다. 예를 들어 자동차 동력 조향장치가 고장이 났다면 부정확하면서 갑작스러운 핸들 조작으로 이어질 수 있다. 하지만 전자 및 기계 설계는 자연스러운 동작지연 시간을 가지고 있기 때문에, 고장은 일정 시간 동안 허용되며 이러한 허용가능한 시간은 수십 혹은 수백 밀리세컨드(many milliseconds)를 넘기도 한다. ISO26262에서는 이 기간을 고장 허용 시간(Falut tolerant time interval)이라고 하며 잠재적으로 위험한 이벤트와 시스템 설계에 따라 결정된다. 안전성이 필수적인 애플리케이션일수록 안전하지 못한 고장 문제를 더 많이 해결할 수 있어야 한다.

이상적으로는 기능안전성이 시스템 성능에 아무런 영향을 미치지 않아야 하지만, 설계자들이 실제로 이용 가능한 대부분의 대응 방안이 성능, 전력 및 공간에 큰 영향을 미칠 수 있다. 따라서 설계자들이 당면한 과제 중 하나는 기능안전성을 충분히 확보하는 동시에 시스템 또는 설계/제조비용에 부정적인 영향을 미치지 않도록 하는 것이다.

왜 기능안전성이 필요한가

과거에는 실리콘 IP를 위한 기능안전성은 틈새 활동(niche activity)이였으며 자동차, 공업, 항공 우주 및 기타 유사 시장의 소규모 칩 및 시스템 개발자 그룹으로 제한됐다. 하지만 차량용 애플리케이션이 점차 다양해지면서 지난 몇 년 동안 이 부문은 획기적으로 변화했다. 뿐만 아니라, 보다 많은 전자기기들이 출시되고 있으며, 시스템이 기능적으로 안전하게 유지되는 한 많은 업계에서 이를 통해 상당한 이익을 거두게 될 것이다. 의료, 전자기기 및 항공업계가 가장 대표적이다.

지난 몇 년 간 자율주행 기술은 많은 주목을 끌었으며 점차 더 많은 기능을 갖춘 첨단 운전자 지원 시스템(ADAS)과 차량용 멀티미디어 인포테인먼트(IVI)에서 시작해 현재 자율주행자동차에 대한 보다 구체적인 목표가 생겨나면서 사람들의 관심을 사로잡고 있다. 그러나 자율주행이 성숙 단계에 이르기 위해서는 여전히 많은 노력이 필요하다. 다양한 유형과 규격의 드론이 등장하고 산업용 사물인터넷(IoT)이 더욱 광범위하게 확산되는 현상도 기능안전성이 요구되는 흥미로운 예로 ARM의 기술은 경쟁우위로 작용한다.

기능안전성을 위한 ARM 기술

주목을 불러일으키는 다른 기술과 마찬가지로 이렇게 급성장하는 차량용 애플리케이션들이 기능안전성을 갖추기 위해선 반도체가 필요하며, 급속한 제품 혁신 속도는 ARM 파트너들의 많은 관심을 끌었다. 가장 기능적으로 안전한 임베디드 시스템의 핵심요소 중 하나는 안전성과 실시간 기능의 결합이다. 이러한 요구사항을 해결하기 위해 ARM Cortex-R 프로세서 제품군은 신뢰성, 고가용성, 내고장성 및/또는 확정적 실시간 응답이 필요한 임베디드 시스템을 위해 고성능 컴퓨팅 솔루션을 제공한다.

이러한 기능들은 시스템에서 가장 중요한 처리 작업들을 수행하고, 서비스 안전성 관련 인터럽트(Service safety related interrupts) 처리, 다른 시스템들과의 통신 그리고 낮은 무결성 수준의 복잡한 기능들을 관리하기 위한 슈퍼바이저 역할에 사용될 수 있다. 이로 인해 ADAS 및 IVI용 장치에서 안전 무결성을 위한 토대를 제공한다.

장애란 무엇인가?

장애는 사양 및 설계 중 사람이 범하는 실수와 같이 시스템적인 것과 사용하는 툴(tool)에 따른 것일 수 있다. 이와 같은 실수를 줄이는 한 가지 방법은 계획, 검토 및 측정 평가 등의 범위를 포함하는 엄격한 품질 프로세스를 마련하는 것이다. 요구사항을 관리 및 추적할 수 있도록 하는 것 역시 중요하며, 사용되는 툴에 대한 올바른 계획 및 인증도 마찬가지로 중요하다. ARM은 추가적인 컴파일러 인증 없이 안전성에 대한 개발을 진행할 수 있도록 TU¨ V SU¨ D의 검증을 받은 ARM Compiler 5를 제공한다.



또 다른 장애 분류는 우발적인 하드웨어 고장으로서 그림 2에서 보는 것과 같이 영구적인 형태의 고장일 수 있다. 아니면, 자연 방사선에 노출되면서 일시적으로 발생하는 소프트 오류(soft error)일 수 있다. 이와 같은 고장은 하드웨어 및 소프트웨어에 설계된 대응 방안을 통해 식별될 수 있으며 시스템 차원의 접근 방식을 적용하는 것이 중요하다. 예를 들어, 소프트 에러와 영구 고장을 구별하기 위해 로직 BIST(Logic Built-In-Self-Test)를 시스템을 시작하거나 종료할 때 적용할 수 있다.

대응 방안

설계자들이 당면한 문제를 해결하기 위해 시스템 차원과 마이크로아키텍처 기법을 모두 적용하기 시작하면서 고장 감지와 제어를 위한 대응 방안 채택 및 구상 단계는 가장 흥미로운 절차의 한 부분이 됐다. 시작하기 좋은 한 가지 방법은 개념 수준의 고장유형 및 영향분석(Failure Modes and Effects Analysis, FMEA)을 통해 잠재적인 장애 모드 목록과 얼마나 큰 영향력이 지니고 있는지 파악하는 것이다. 이러한 목록과 시스템의 복잡성에 대해 이해함으로써 가장 심각한 장애 모드를 식별하고 대응 방안을 구상할 수 있다.

잠재적인 장애를 해결하는 많은 방법들이 있지만 일반적으로 활용되는 기술은 아래와 같다.

- 다양한 검사기(checker): 주 회로에 장애가 발생했는지 여부를 파악하기 위해 다양한 회로를 사용하는 것을 의미한다. 검사기 회로의 한 가지 예로는, 요청된 인터럽트(interrupt)와 시스템에 보고된 인터럽트의 목록을 유지하는 인터럽터 제어기(Interrupt controller)를 위한 스코어보드가 있다.

- 풀 록스텝 복제(Full lock-step replication): 이 기술은 Cortex-R5를 위해 사용되며 프로세서와 같은 IP를 구성하는 중요한 요소를 한 번 100 Development Feature 101이상 인스턴싱(instancing)하며 인스턴스들 간의 작동시간을 몇 사이클씩 지연시켜 시공간적 중복성(redundancy)을 생성하는 과정이 필요하다. 이 기법은 매우 강력하기는 하지만 많은 비용이 소요되므로 필요한 공간을 줄이기 위해 대형 메모리들을 종종 인스턴스 간에 공유되도록 한다.

- 선택적 하드웨어 중복성(Selective hardware redundancy): 결정권자 노드(Arbiter)와 같은 하드웨어의 중요한 부분만이 중복되도록 한다.

- 소프트웨어 중복성(Software redundancy): 하드웨어 중복성의 오버헤드(overhead)와 복잡성은 필수적인 것은 아니며 자원을 융통성 없이 활용하는 것이기도 하다. 이에 대한 대안으론 하나의 계산(Calculation)을 두 번 이상 서로 다른 프로세서 코어에서 실행하고 그 결과가 서로 일치하는 지를 확인하는 것이다.

- 오류 감지 및 수정 코드: 이것은 메모리와 정보 전송 회로(bus)를 보호하기 위해 일반적으로 사용되는 널리 알려진 기술이다. 다양한 종류의 코드가 존재하지만 그 목적은 기본적인 데이터를 완전히 복제하는 것이 아니라 몇 가지 추가적인 비트를 통해 중복성을 생성하는 것이다. 차량용 시스템을 위한 최첨단 기술은 충분한 중복성을 적용해 메모리 워드의 2비트 오류를 식별하는 것이다. 선택적 수정(correction)이 적용될 수도 있다.

고장 로그(Fault logging)

일단 고장을 식별하면 이를 기록함으로써 슈퍼바이저 소프트웨어가 시스템 상태를 확인하고 계속해서 안전한 상태를 유지하도록 보장한다. 메모리 수정(memory correction)과 같이 안전한 고장과 복구 불가능한 하드웨어 오류와 같은 위험한 고장의 구분은 별도로 기록돼야 한다.

고장 로그는 일반적으로 인터럽트(Interrupt)와 유사하게 신호로 전달되는 이벤트의 발생 횟수를 세는 시스템 차원의 인프라나 혹은 IP 자체에 탑재돼 있는 계수기(Counter)를 통해 고장 횟수를 계산하는 것으로부터 시작한다. 이러한 이벤트에 대한 이해를 돕기 위해 가장 오래된 이벤트를 시작으로, 이를 야기한 원인이 무엇인지를 파악하는 것도 바람직하다.

이와 같은 요구사항을 지원하고 디버깅(debugging)을 효과적으로 하기 위해서 일부 IP는 고장이 감지된 메모리의 주소와 같은 세부사항을 포착하고 이를 보통 소프트 리셋(soft reset) 시에도 유지되게 한다. 이를 통해 시작(Startup)이나 자가 테스트(Self-tests) 수행 시 이러한 메모리 주소의 정보를 읽을 수 있다.

고장은 안전성 인프라에서도 생길 수 있다는 사실을 기억하는 것은 중요하다. 일반적으로 사용 중에 빠르게 직면하게 되는 활성화된 하드웨어에서 발생한 고장과 달리, 안전성 검사 회로의 장애는 휴면상태(Dormant state)를 유지할 수 있으며 위험한 고장이 파악되지 않은 상태에서 확산되도록 한다. 이와 같은 고장은 잠재장애(latent faults)로 불리며, 주기적인 안전성 검사 회로에 대한 테스트를 통해 완화될 수 있다.

안전 무결성 기준(Safety Integrity Levels, SIL)

표준에는 기능의 중요도를 반영하기 위한 다양한 수준의 안전성이 있다. 예를들어, 자동차 유리창 와이퍼, 에어백 또는 브레이크 등을 제어하는 ECU는 속도계나 주차 센서 등을 제어하는 것보다 높은 수준의 무결성을 갖춰야 한다. 그 이유는 자동차 유리창을 통한 시야 확보가 필수적이며 의도하지 않은 브레이크 작동이나 에어백 전개는 치명적일 수 있으며, 운전자는 그 어떠한 현실적인 대안이 없기 때문이다.

반면, 속도계나 주차 센서는 자동차를 안전하게 정지시키는 경우에는 사람에게 필수적이지는 않다.
따라서, 요구되는 무결성 수준은 위험한 상황을 방지하는 사람의 역량 및 필요성과 관련이 있으며, 표준은 필요한 무결성의 수준을 규정할 수 있도록 돕는 지침과 시스템의 무결성을 수치화하는 측정 지표를 제공한다.

IEC 61508은 1부터 4(4가 가장 높은 무결성 수준) 범위의 안전 무결성 기준을 규정한다. 마찬가지로 ISO 26262에서는 ASIL A에서 가장 높은 무결성 레벨인 ASIL D에 이르는 차량용 SIL(Automotive SILs)의 개념을 규정한다. 표 1과 같이 ISO26262는 ASIL B에서 ASIL D까지 단일 지점 고장(Single point fault), 잠재장애(Latent fault) 및 PMHF(Probabilistic Metric of Hardware Failure) - 엔터프라즈 마켓(Enterprise market)에서는 장애 지속기간(failure in time)으로 알려짐 - 을 위한 측정 지표를 제안한다. 감지할 수 있는 고장의 비율은 진단 커버리지(diagnostic coverage)로 알려져 있다.

이러한 측정 지표들은 제품 데이터시트에 기입할 항목을 추가하는 것이 아니라 안전한 제품을 가능하게 하기 위한 것들이기 때문에, 실제로 자동차 애플리케이션을 위한 제안사항들이지만 종종 규범적인 요구사항인 것처럼 보인다. 앞서 제시된 사례로 돌아가서, 차량용 앞유리 와이퍼, 브레이크 및 에어백 전개는 ASIL D로 분류될 수 있으며 속도계 및 주차 센서는 전반적인 시스템설계 및 안전성 케이스에 따라 ASIL B 또는 그 이하가 될 수 있다.

달성한 진단 커버리지와는 별도로, 기능적으로 안전한 애플리케이션을 구현할 때 적합한 프로세스를 따르는 것이 필요하며 바로 이 부분에서 표준이 큰 도움을 제공한다. 뿐만 아니라 엄격한 품질 프로세스는 기능안전성이 해당되는지 여부와는 관계 없이 모든 애플리케이션을 위한 전반적인 제품품질을 향상시킨다.

기능안전성을 갖춘 IP 설계 위한 프로세스

기능적으로 안전한 애플리케이션을 위한 IP 개발의 핵심 요소는 아래에 열거된 프로세스이며, 여기에는 초기 단계에서부터 안전성에 대한 고려와 안전성을 지원하는 문화 확립이 포함돼야 한다.

프로세스에 포함돼야 하는 주요 측면은 다음과 같다.

- 안전성 관리: 명확한 역할과 책임에 대한 정의, 안전성 문화, 안정성 라이프사이클과 기능안전성 지원 수준에 대한 정의등을 포함한 부서 조직을 아우른다. 안전성 라이프사이클은 성공을 위한 계획과 개발을 지원하는 적절한 툴을 선택하고 부서가 적절한 교육을 받을 수 있도록 지원하는 것과 같은 요구사항을 포함한다.

- 고장 감지/제어 기능의 요구사항 관리 및 추적 기능(대응 방안): 요구사항을 추적하기 위해서는 명확하면서 중복되지 않고 상세한 정의를 내려야 한다. 추적성 수준은 무결성 요구사항에 따라 결정되며 문서 간의 개략적인 수준이거나 제품 요구사항에서 고장 감지 및 제어 기능을 위한 인증 결과에 이르는 상세한 수준이 될 수도 있으며 이들 모두는 철저하게 검증돼야 한다.

- 품질 관리는 요구사항 추적 기능을 넘어설 것이며, 오류(Errata)는 적절하게 관리 및 처리돼야 한다. ARM은 이 분야에서 오랜 경험을 축적했다. 진행해야 하는 프로세스를 문서화하고 소통하는 것도 중요하다.

안전성 문서화 패키지(Safety Documentation Package)

IP 개발은 ARM이 파트너를 지원하는 한 가지 방법이지만, 그 관계는 IP를 제공받는 시점에 끝나는 것이 아니다. IP 개발과 관련한 기능안전성을 위해 ARM은 2가지 레벨의 안전성 문서화 패키지를 규정하고 있다.

- ASIL B까지의 사용 지원을 위한 표준 레벨 문서 패키지
- ASIL D까지의 사용 지원을 위한확장 레벨 문서 패키지

각 안전성 패키지는 진행해야 하는 프로세스를 설명하고 고장 탐지 및 제어 기능 그리고 여타 세부사항과 함께 이러한 기능을 사용한다는 가정 하에 구성된 안전성 매뉴얼(Safety manual)이 포함돼 있다.

또한, IP를 이용해 달성할 수 있는 진단 커버리지에 대한 예제를 제공하고 파트너별 칩 레벨에서 추가적인 분석을 지원하기 위한 고장 모드 및 영향 분석 보고서(FMEA)도 포함된다. 이 패키지는 또한 ARM과 라이선시 간 개발 인터페이스의 명확한 정의도 포함하고 있다.

SEooC(Safety Element out of Context)

안전성 케이스(safety case)는 계층적으로 사용된다. 반도체 칩 개발자가 작성한 케이스는 각 IP 제공자의 아이디어를 요구하며, 이후엔 고객들의 의견도 반영될 수 있다. 대부분의 라이선스 가능한 반도체 IP는 설계자들이 추후에 반도체를 어떻게 활용할 것인지에 대해 구체적으로 알지 못하는 SEooC(Safety Element out of Context)로 개발될 것이다. 따라서 안전성 매뉴얼은 IP 개발자들이 예상하는 해당 IP 사용에 대한 이해를 정확히 담고 있어야 하며, 이를 통해 IP의 적절치 못한 사용을 방지할 수 있다.

마찬가지로, 티어1 컨트롤러 공급업체에서 OEM까지도 SEooC 모델을 적용해 제품을 개발할 수 있다. IP 레벨의 안전성 문서화 패키지를 통해 전반적인 가치사슬을 만드는 것이 가능하게 하며, 이에 따라 모든 IP 제품군에서 매우 중요한 부분이 되고 있다.

필수 요구사항이 된 기능안전성

자동차, 의료 및 공업용 기기에 이르는 전자기기들을 활용한 복합적인 애플리케이션의 수가 증가하고 있기 때문에 기능안전성은 전문적인 요구사항에서 일반적인 요구사항이 되고 있다. 기능안전성은 IP 업체들이 이행하고 벤더들이 각 개발에 대한 성과를 최대한 많은 실리콘 파트너들에게 라이선스하기 위해 실행해야 하는 IP 라이선스 모델에 대한 요구사항을 증가시키고 있으며, 이는 파트너에서도 마찬가지이다. 품질과 내구성 측면에서 확고한 뿌리를 내리고 있기 때문에 기능안전성을 실현하기 위해 수행한 작업들은 광범위한 이점을 지니고 있다. 이러한 이점은 산업 전반에서 품질 및 제품 탄력성을 향상시키는 기폭제 역할을 한다.

이는 칩 개발자들이 자동차 내에서 운전자 안전성, 연료 효율성, 편안함 및 IVI 등을 위해 보다 높은 수준의 성능에 대한 요구를 지원할 수 있는 시스템의 개발을 위한 토대다.