시스템의 복잡도가 높아져 잠재적 문제가 내포될 확률이 높아졌으며, 제품의 신뢰성, 안정성의 요구사항 증가로 테스트의 중요성이 많이 부각되고 있다. 하지만 여러 제약사항이 있는 임베디드 소프트웨어, 특히 소형화와 다기능화 되어있는 임베디드 시스템의 동작을 위한 MCU를 제어하는 펌웨어, 어플리케이션의 테스트는 일반적인 소프트웨어 시스템과 다르므로 특화된 테스트 프로세스가 요구된다.



의료기기를 포함한 모든 임베디드 시스템은 시간이 지날수록 점점 소형화되고, 고성능, 다기능, 저전력 등의 많은 발전이 요구된다. 이러한 다양한 요구사항에 적합하도록 디지털 전자기기를 제어하는 MCU(Micro Controller Unit) / MPU(Micro Process Unit)는 많은 발전을 이루었다.

MCU는 하드웨어적으로 1971년 최초의 4bit 인텔 MCU부터 현재의 32/64 bit의 arm 코어 사용 MCU까지 다양한 성능 발전이 있었다, 동작 속도 또한 700KHz 이하에서 현재는 최대 1GHz 이상으로 증가하였다. 그 외 소프트웨어가 저장되고 동작하는 메모리의 크기도 수 바이트에서 수 메가 단위로 증가하였다. 간단한 입출력 제어 수준에서 지금은 영상 분석과 신호 처리, 다양한 통신 프로토콜 구현 등 복잡한 동작과 기능 구현이 가능하게 되었다. MCU의 사용 범위도 간단한 신호 제어용의 컨트롤러 역할 뿐 아니라 작은 소형 단말기 두뇌의 역할까지 넓어졌다.

MCU를 제어하는 소프트웨어도 아주 높은 복잡도를 갖게 되었다. 하드웨어의 성능과 기능 향상으로 이전 단순한 코드가 아닌, 매우 많은 기능을 수행해야 하기 때문이다. 복잡도가 높은 소프트웨어는 복잡도가 낮은 소프트웨어보다 분석이 어려워 소프트웨어 코드내 잠재된 문제점 파악이 어렵다. 복잡도가 높은 소프트웨어의 품질 관리가 제대로 되지 않는다면 당연히 많은 문제점을 내포할 확률이 높다. 내포된 문제점이 개발 후 또는 양산, 출시 이후에 발견된다면 문제해결의 비용은 초기 대비 기하급수적으로 증가할 것이다.

이에 따라 복잡도가 높은 소프트웨어의 품질 향상을 위하여 소프트웨어 벨리데이션 강화와 개발 시작 단계부터의 소프트웨어 테스팅이 강조된다.

임베디드 소프트웨어의 테스팅

일반적으로 V모델의 개발방법론에 따라 소프트웨어 테스팅은 설계, 구현이 되면 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 순으로 진행된다.



단계별 테스트에 대하여 설명하면, 우선 단위 테스트는 소프트웨어의 최소 단위로 분류하고 구현이 설계안대로 되었는지 평가하는 방법이다. 테스트된 단위들이 모여 하나의 모듈 형태의 소프트웨어가 된다면, 조금 더 큰 범위의 통합 테스트를 진행한다. 이 후 통합 테스트가 완료된 후 하나의 큰 시스템이 완성되면 전체의 시스템 테스트를 수행한다. 마지막 단계로 완성된 소프트웨어를 이관하기 전 인수 과정에 필요한 테스트들 진행한다.

테스트의 방법은 일반적으로 크게 정적, 동적 분석 방법으로 구분한다. 정적 분석 방법의 경우는 소프트웨어의 작성된 코드 자체 또는 설계된 문서 등의 정적인 테스트 대상물을 분석하고 문제점을 찾아내는 방법이다. 동적 분석 방법은 실제 구현된 소프트웨어 코드를 동작시키며 동작 중 문제점을 찾아내는 테스트 방법이다. 정적, 동적 방법의 테스트 시점과 한계점을 고려하여 모든 테스트 단계에서 정적, 동적 방법을 모두 사용하여 테스트 설계되고 수행하기를 권장한다.

그렇다면 테스트를 하기 위한 테스트의 설계, 테스트 케이스를 만드는 방법으로 일반적으로 많이 사용하는 기법은 명세 기반 기법, 구조 기반 기법, 경험 기반 기법이 있다. 가장 보편적으로 많이 사용되고 비교적 쉽게 테스트 케이스 작성이 가능한 기법은 경험 기반 기법이다.




소프트웨어 테스팅은 위의 설명된 방법과 단계로 진행된다. 하지만 크로스 개발환경의 임베디드 시스템 소프트웨어 테스팅은 네이티브 개발 환경의 소프트웨어 시스템 테스팅과 많은 차이와 제약사항이 있다.

첫째, 임베디드 소프트웨어 테스팅에는 리소스에 제약이 있다. 일반적으로 MCU의 성능이 PC의 CPU만큼 매우 고성능이 아니며 메모리 또한 한정된 자원으로 사용하게 된다. 이러한 리소스의 제약으로 테스트를 위한 테스트 소프트웨어를 주입하여 동작한다거나 소프트웨어 에뮬레이션 한계성 등의 제약이 발생한다.

둘째, 소프트웨어의 개발 환경과 실제 동작 환경이 다른 크로스 개발환경이다. 소프트웨어의 개발 환경과 실제 동작 환경이 분리되어있기에 동적 분석 테스트가 어렵다. 임베디드 소프트웨어 자체가 하드웨어 의존성이 매우 높다. 개발 PC에서 동작에 이상이 없더라도 실제 동작 환경에서는 하드웨어의 상황에 따라 다른 동작이 발생할 수 있다. 또한 하드웨어의 결함이 존재하는 경우 동작 소프트웨어의 테스트가 어렵다.

아울러 동작 하드웨어의 온습도 등 외부 환경 요소에 민감성에 따라 동작이 다를 수 있다. 이 점 또한 크로스 개발에서의 테스트 한계성에 속한다. 이처럼 임베디드 시스템의 소프트웨어는 테스트를 위하여 하드웨어와 분리가 어렵다.

마지막으로 셋째, 소프트웨어의 단위 구분이 어렵다. 위에서 언급되었듯이 소프트웨어의 테스트 단계는 일반적으로 단위, 통합, 시스템 그리고 인수 테스트 단계로 구분된다. 하지만 MCU를 제어하는 소프트웨어는 주로 구조 기반 기법의 언어인 C, Assembly 언어를 사용한다. 이러한 구조 기반 기법의 언어는 주로 객체지향 언어를 사용하는 소프트웨어 시스템 대비 소프트웨어 단위를 구분하기 어렵다. 따라서 일반적인 소프트웨어 테스팅 단계를 따르기 어려운 한계점이있다.

이러한 다양한 제약사항이 존재하는 임베디드 소프트웨어 테스팅은 좀 더 유연한 단계와 프로세스가 필요하다. 아울러 이전 언급되었듯이 소프트웨어 테스팅에서 테스트의 품질 만큼 중요한 요소가 테스팅의 시점이다. 위에서 언급되었듯이 소프트웨어의 잠재된 문제를 가능한 초기에 최대한 많은 문제점을 찾아내어 해결하는 것이 문제해결 비용을 최소화 할 수 있는 방법이다. 테스팅 단계, 방법 그리고 시점을 고려하여 적절한 임베디드 소프트웨어 테스트 프로세스 정립이 필요하다.



IDE 기능을 활용한 소프트웨어 개발 품질 향상

임베디드 소프트웨어의 복잡성이 높아지고 고도화됨에 따라 크로스 환경의 임베디드 소프트웨어를 개발하는 통합 개발 환경 또한 많은 변화가 생겨났다. 2000년대 초반 임베디드 시스템 시장의 확장 초기에는 소프트웨어 기술에 많이 집중되었다. 따라서 개발 환경 또한 소프트웨어 최적화 빌드, 코드의 소형화, 빠른 수행 속도 구현에 집중되었다.

IAR Systems의 통합 개발 환경인 IAR Embedded Workbench 또한 코드 최적화 기술력 확장에 많은 노력이 더해졌다. 이 후 임베디드 시스템의 발전으로 소프트웨어의 복잡도 증가로 좀 더 품질 좋은 소프트웨어 개발에 많은 기술 집중이 되었다. 이에 따라 임베디드 소프트웨어의 개발 규격에 소프트웨어 밸리데이션 강화 등 많은 산업 변화가 있었다.

의료기기에서 소프트웨어 품질은 반드시 중요한 요소이다. 소프트웨어의 품질을 높이기 위한 여러 방법들이 규격, 가이드라인 등에서 제안된다. 기업 입장에서 중요한 점은 비용 최소화로 최대의 품질 향상 효과를 기대할 수 있는 솔루션이 필요하다.

앞에서 언급되었듯이 소프트웨어 개발 중 발생되는 문제 해결 비용의 최소화의 방법은 가능한 개발 초기에 최대한 많은 문제를 찾아내 해결하는 것이다. 개발 시작부터 정적, 동적 분석을 통해 개발자가 범한 코딩 실수 또는 개발된 코드에 잠재된 문제점 등 최대한 많은 문제를 찾아내는 것이 비용 최소화로 최대의 품질 향상의 핵심이다.

오늘날 개발환경은 소프트웨어 개발 품질 향상을 위하여 개발 초기에 많은 문제점을 찾아내도록 지원하는 다양한 기능을 추가하고 있다. 크로스 개발 환경의 임베디드 시스템의 여러 제약사항을 다양한 장비, 기능으로 보완하기 위하여 많은 노력이 더해지고 있다. 예를 들어 MCU의 펌웨어 작성을 위해 가장 많이 사용되는 IAR Systems사의 통합 개발 환경인 IAR Embedded Workbench는 컴파일러, 링커, 디버거 외 코드 작성 후 코드에 내포된 문제를 빠르게 검사할 수 있도록 정적분석 기능을 추가 하였다. 또한 IDE를 활용한 디버깅 중 동적 검사가 가능하여 개발자의 코딩 실수 또는 디버깅이 어려운 버그를 쉽게 찾도록 지원한다.

이처럼 임베디드 소프트웨어 개발 환경이 작성된 코드를 번역하는 컴파일, 빌드 품질 향상 뿐 아니라 코드 작성 중의 정적, 동적 분석 방법 지원으로 코드 작성 자체의 품질 향상을 위하여 변화하고 있다.

임베디드 소프트웨어 개발 환경이 변화에 맞춰 개발자 또한 개발 환경의 이점을 최대한 활용할 수 있도록 변화한다면 다른 경쟁사보다 높은 품질과 시장 선점에 도움이 될 것으로 예상한다.

맺음말

의료기기를 포함한 임베디드 시스템은 하드웨어와 소프트웨어 모두 많은 발전이 이뤄졌다. 시스템의 규모가 커짐으로 시스템의 복잡도가 높아져 잠재적 문제가 내포될 확률이 높아졌으며, 제품의 신뢰성, 안정성의 요구사항 증가로 테스트의 중요성이 많이 부각되고 있다. 하지만 여러 제약사항이 있는 임베디드 소프트웨어, 특히 소형화와 다기능화 되어있는 임베디드 시스템의 동작을 위한 MCU를 제어하는 펌웨어, 어플리케이션의 테스트는 일반적인 소프트웨어 시스템과 다르므로 특화된 테스트 프로세스가 요구된다.

다른 각도에서 임베디드 소프트웨어 테스트를 바라보았을 때 테스트의 프로세스도 중요하지만 테스트의 시점 또한 중요하다. 문제 해결비용의 최소화를 위하여 개발 시작부터 최대한 많은 문제점을 찾아 위험성을 제거할 수 있는 임베디드 소프트웨어 개발을 고려해야한다.