[테크월드=정환용 기자] 초창기 온도 센서는 온도의 변화에 따라 저항을 변경하는 실리콘 조각에 불과했다. 당시 온도 센서는 순수한 아날로그 디바이스로서 로직 소자는 포함하지 않았다. 애플리케이션 프로세서가 온도 센서를 알기위해 온도 센서는 센서의 출력에서 전압을 측정, 다음 온도 값을 계산할 수 있도록 아날로그-디지털 변환 작업을 수행해야 했다.
오늘날 시스템 설계자는 디지털 출력을 제공하는 온도 센서를 사용한다. ‘스마트’ 디지털 센서는 더욱 향상된 정확도, 내장된 보정, 진단과 고장 탐지 기능, 구성 가능한 필터, 프로그래밍 가능한 인터럽트 등 다양한 장점을 사용자에게 제공한다. 또한, 디지털 센서는 알고리즘을 사용해 실내 공기질 같이 직접 측정할 수 없는 값을 유도할 수 있는데, 이를 통해 공기 중 휘발성 유기 화합물(Volatile Organic Compounds, VOC)의 농도 등을 알 수 있다.
측정 신호는 센서에서 디지털화되므로 애플리케이션 프로세서에 대한 오버헤드를 상당히 줄여줘 설계를 간소화하고 시스템 전력 소모를 낮추는 데 도움을 준다. 그러나 디지털 센서는 내장된 소프트웨어, 즉 임베디드 소프트웨어를 실행하기 때문에 예전의 아날로그 센서와 같이 더 이상 단순한 전자부품이 아니다. 소프트웨어는 새로운 위험 요소를 내포한다.
센서의 하드웨어 성능은 제품 데이터시트에 매우 정밀하게 특성화하고 문서화할 수 있다. 또 자동차 산업의 PPAP(Production Part Approval Process) 같은 산업 표준 프로세스는 생산 단위의 품질을 검증 가능한 방식으로 수치화할 수 있게 한다. 그 결과 시스템 설계자는 알려진 동작 조건에서 예상되는 센서 하드웨어 성능에 대해 높은 수준의 신뢰도를 가질 수 있다.
그렇다면 센서에 내장된 소프트웨어에 대해서도 이와 동일한 수준의 신뢰도를 가질 수 있을까 임베디드 소프트웨어에 의한 오작동 위험은 실제로 존재한다. 2016년 11월 유럽우주국(European Space Agency)의 웹사이트에 발표된 예비 조사에 의하면 화성 표면에서 스키아파렐리(Schiaparelli) 모듈이 착륙에 실패한 원인이 1초도 안 되는 짧은 시간 동안 예상치 못한 센서 출력 조건에 의해 유발된 모듈의 제어 소프트웨어 오류에 의한 것으로 나타났다. 막대한 비용이 들어가는 우주 탐사 프로젝트의 특성 상 2016년에 스키아파렐리 모듈보다 더 엄격한 테스트를 거친 임베디드 시스템은 없었으리라고 판단되지만, 그럼에도 발사 시 소프트웨어에 버그가 남아 있었던 것이다.
물론 우주 모듈이 노출되는 조건을 견디도록 자신의 제품을 설계해야 하는 사람은 거의 없다. 그렇지만 대부분의 설계자는 요구하는 품질 수준과 예상되는 동작 수명을 달성해야 하는 의무가 있다. 이에 따라 임베디드 소프트웨어의 오류 가능성을 검증할 수 있는 방법이 요구되는데 이런 방법들은 예산과 개발 자원, 개발 기간 등 설계 제약 조건을 충족할 수 있어야 한다.
이 글에서는 센서 제조업체가 이러한 요구사항를 충족하는데 도움이 될 수 있도록, 센서 IC 내에 내장되는 소프트웨어에 대한 검증 방법을 설명한다.
임무 또는 안전이 중요한 센서 솔루션
어떤 센서 제품들은 신뢰성 보장이 필수인 복잡한 측정 애플리케이션에 사용된다. ams가 제공하는 이런 유형의 센서들로는 다음과 같은 제품들을 들 수 있다.
냉수 계량기에 사용되는 [그림 1]의 유량센서는 유틸리티 회사가 고객에게 보내는 청구서는 센서 출력의 정확도에 따라 달라진다.
[그림 2]의 가스센서는 오염물질의 위험한 농도를 신뢰성 있게 검출할 수 있는 센서의 기능이 중요한 역할을 한다.
[그림 3]의 바이오센서는 몸에 착용하는 건강 모니터가 수행하는 광학 심박수 측정은 의사가 환자의 상태를 정확히 진단하는 데 영향을 미친다.
이런 모든 애플리케이션에서 디지털 센서는 측정(하드웨어에서 실행)과 데이터 처리(소프트웨어에서 실행)를 결합하고 있다. 하드웨어에서 발생하는 오류의 범위는 디바이스의 동작 파라미터로 쉽게 특성화하고 데이터시트에 문서화할 수 있다. 그러나 센서의 소프트웨어에서 발생하는 오류의 범위를 특성화하기 위해서는 문제를 각 부분별로 세분화하는 것이 최선의 방법이다.
거의 모든 디지털 센서는 ▲원시 데이터(Raw data) 수집을 수행하는 아날로그 프런트 엔드 ▲하드웨어에 접속하는 드라이버 코드 ▲데이터 처리와 분석을 수행하는 알고리즘 ▲애플리케이션 자체에 데이터를 전달하는 글루 로직(Glue logic) 등으로 구성된다.
이는 모든 디지털 센서가 다음과 같이 서로 다른 요구사항을 갖는 다양한 소프트웨어 구성요소를 포함한다는 것을 의미한다. ▲일부 소프트웨어 요소는 특정 하드웨어 구성요소와 결합 ▲일부 소프트웨어 요소는 임계 타이밍 ▲일부 소프트웨어는 높은 컴퓨팅 성능을 요구 이러한 코드 베이스의 서로 다른 부분에서 다양한 오류들이 발견될 수 있기 때문에, 테스트 루틴은 모든 유형의 오류를 발견할 수 있도록 신중하게 작성돼야 한다.
알고리즘 코드 테스트는 간단하다. 특정 입력 값에 대해 어떤 출력이 예상될지 테스트 엔지니어가 정확히 알 수 있다. 이 코드 섹션은 데이터 출처를 알 필요가 없으므로 센서 하드웨어에 구애 받지 않는다. 반면에 드라이버 코드 테스트는 예컨대 센서가 레지스터 액세스를 올바르게 수행하는지 확인하려면 하드웨어 시뮬레이션이 필요하다. 코드의 섹션 테스트는 오버플로우, 버퍼 외부 액세스 발생, 잘못된 루프 종료 조건과 같은 버그를 효율적으로 찾아내기는 하지만 이러한 테스트만으로는 완전한 센서 시스템의 기능을 검증하기에는 충분치 않다.
전체는 부분의 합보다 크다
아리스토텔레스는 이미 2천 년 전에 전체는 부분의 합보다 크다는 사실을 발견했다. 이 진리는 임베디드 소프트웨어에도 어김없이 적용된다. [그림 6]처럼 소프트웨어의 각 섹션을 개별적으로 테스트한 후에는 모든 섹션의 협조가 적절히 이루어지는지 검증하는 것이 필수다.
특히 테스트 엔지니어는 해당 소프트웨어가 사용될 가능성이 있는 모든 하드웨어 환경에서 올바르게 수행할 수 있다는 것을 보장해야 한다. 예를 들어 휴대전화는 일반적으로 센서에 더 많은 인터럽트를 발생시키기 때문에 독립적인 센서 디바이스보다 훨씬 더 까다로운 하드웨어 환경이다. 따라서 센서 IC에 있는 다양한 인터페이스가 단 1바이트의 데이터 손실도 없이 인터럽트 과부하를 견딜 수 있는지를 검사하기 위한 스트레스 테스트가 필요하다.
시스템 테스트는 또한 시스템의 시퀀싱을 검증할 필요가 있다. 예를 들어 초기화 루틴과 계산 루틴을 독립적으로 검증할 수 있다. 하지만 시스템 소프트웨어는 이들 루틴을 반드시 올바른 순서대로 호출해야 하며, 그렇지 않을 경우 센서가 고장날 수 있다.
마지막으로, 이상 조건(unusual condition)에서 소프트웨어 동작을 검증해야 한다. 특히 스키아파렐리 모듈은 예기치 못한 센서 출력 조건을 만난 후 고장을 일으켰다. 물론 센서가 노출될 수 있는 가능한 모든 극한 상황에 대해 테스트하기란 불가능하다. ams에서 수행하는 소프트웨어 검사는 매우 광범위한 비표준적인 조건에 걸쳐 성능을 검사하는 것을 목적으로 한다. 예컨대 전원 장치에서 발생하는 비정상적인 변동을 견딜 수 있는지 확인하기 위해, 인위적으로 높은 전류를 소비할 때 센서 소프트웨어가 적절히 동작하는지 정기적으로 테스트한다.
센서의 소프트웨어 무결성 검증 방법
모든 특정 센서 IC에 대한 소프트웨어 테스트 프로그램의 이론적인 목표는 사용자에게 센서 시스템이 모든 애플리케이션과 모든 동작 조건에서 항상 적절히 동작한다는 것을 100% 보장하는 데 있다. 결국 이것은 사용자가 이상적으로 원하는 것이기도 하다.
하지만 실제로는 화성 착륙 모듈의 예에서 보듯이 100% 보장할 수 있는 것은 없다. 그렇다면, 사용자는 어떻게 소프트웨어 버그로 인한 센서 IC의 고장 가능성을 추정할 수 있을까? 이 질문에 정확하게 답하기는 어렵다. 자동차 전자장치 분야에서는 시스템에 대한 안전 표준으로 ISO 26262가 있다. 이 표준은 의도된 애플리케이션에서 시스템의 고장률을 예측하는 기본적인 틀을 제공한다. 또한 고장 모드를 분석하고, 각각의 모드에서 고장률을 측정하는 엄격한 프로세스를 시행한다.
그러나 테스트 과정이 엄격할수록 시간과 비용이 증가한다. 통상적으로 ISO 26262 방식의 검증 과정은 비용과 시간 면에서 모두 컨수머 제품에는 적합하지 않다. 그러나 명성이 있는 컨슈머 제품 제조업체는 제품에 사용되는 센서 IC의 품질과 신뢰성에서 높은 신뢰도를 가질 필요가 있다.
ams에서는 모든 고객에게 ams 센서의 임베디드 소프트웨어에 대한 신뢰도 수준을 평가할 수 있는 방법을 제공하기 위해 자체적인 소프트웨어 품질 요구사항(Software Quality Requirements) 표준을 개발했다. 이 표준 규격은 ams의 모든 소프트웨어 프로젝트에 대한 소프트웨어 품질 수준과 요구사항을 정의하고 표준 개발과 테스트 프로세스를 지정한다.
작성: 스테판 퓨리-조비 ams 엔지니어
그래도 삭제하시겠습니까?