SafeTI™ 컴파일러 검증 키트는 응용 과정에서 유동성을 제공하는 모델 기반의 현대식 검증 키트이다. SafeTI™ 컴파일러 검증 키트가 컴파일러 검증에 어떤 도움을 주고 어떻게 생성된 문서의 설명서를 제공하는지에 대해 설명한다.

글 | 오스카 슬로토쉬(Oscar Slotosch) 박사, 발리다스
마르셀 빔스터(Marcel Beemster) 박사
선임 소프트웨어 엔지니어
ACE 관련 컴퓨터 전문가 bv

SafeTI™ 컴파일러 검증 키트는 응용 과정에서 유동성을 제공하는 모델 기반의 현대식 검증 키트이다. 본 백서는 안전기준 및 처리에 의해 발생하는 문제점에 대해서 설명하고 모델 기반의 툴 검증의 장점에 대해 설명한다. 본 백서의 후반부는 텍사스 인스트루먼트의 C/C++ ARM® 컴파일러의 구체적 특징을 다뤘다. C/C++ ARM® 컴파일러의 모델은 TI C/C++ 컴파일러를 위한 구체적 TI 테스트 사례와 슈퍼테스트(SuperTest) 검증 수트에 의해 제공되는 C 소프트웨어 프로그래밍 언어 적합성 테스트를 통합한다.
예제를 사용하여 어떻게 검증 지원 툴이 컴파일러 검증에 어떤 도움을 주고 생성된 문서의 설명서를 제공하는지에 대해 설명한다.

1. 툴 검증의 자격요건
ISO 26262 [ISO26262], DO-178C/DO-330 [DO330], IEC 61508 [61508]과 같은 안전필수 시스템의 개발을 위한 기준은 다양하다. 이러한 기능적 안전기준은 소프트웨어 개발 과정에서 사용되는 모든 툴의 분석을 요구한다. 소프트웨어의 통합 및 검증이 그 예이다. 이러한 기준은 툴을 안전하게 사용하기 위해 세 단계로 구성되어 있다.

1. 분류: 툴들은 시스템의 개발과정에서 필요한 컨피던스(신용 증명)를 설명하는 카테고리로 분류된다. 이 분류는 툴과 처리과정 중 탐지 혹은 방지 확률에서 나타날 수 있는 오류 분석을 기반으로 이루어진다. 툴의 컨피던스 카테고리는 기준에 따라 다르다: ISO 26262 내 툴 “컨피던스 레벨”, DO-178C 내 툴 “기준”, IEC 61508 내 툴 “클래스”가 있다. 영향력이 없거나 프로세스 내 잠재적 에러에 대한 높은 탐지 가능성이 있을 경우 컨피던스를 필요로 하지 않는 툴은 분석 프로세스에서 검증 없이 사용될 수 있다.

2. 검증: 분석 프로세스에서 컨피던스가 필요한 툴들은 자격이 충족되어야 한다. 검증은 확인된 사용 사례에만 제한될 수 있으며 크리티컬 에러의 부재를 보여주기 위해 제한될 수 있다. ISO 26262에서는 4가지 검증 평가방법이 가능하다. 이는 사용으로부터의 컨피던스 증가, 프로세스 평가, 유효 검사, 안전기준에 따른 개발이다.

3. 사용: 툴은 개발 프로세스 중의 알려지거나 발견된 제한을 고려하여 사용되어야 한다. 문서는 툴 검증 중 발견된 모든 제한을 위한 분석 단계 및 대응에서 고려된 프로세스로부터의 제약을 포함해야 한다.

2. 툴 검증 프로세스 및 역할
기준이 툴 검증에 자격을 요구하지만 관련 프로세스를 설명하지는 않는다. 관련 프로세스는 툴 사용자(혹은 툴 사용을 담당하는 부서)와 툴 제공자다. 툴 검증과정 중 다음의 세 가지 처리과정을 살펴보자.

- 툴 체인 분석 (툴 사용자): 모든 툴에 필요한 컨피던스의 결정
- 툴 검증 키트의 제작 (툴 제공자)
- 툴 검증 (툴 사용자와 툴 제공자): 검증 키트의 적용



모든 프로세스는 검증 서비스 제공자에 의해 지원되며 해당 주제에 대해 툴 사용자와 툴 제공자의 경험을 공유할 수 있다.
그림 1은 툴 검증 프로세스를 보여준다. 주요 프로세스인 “툴 검증”(오른쪽에 표시)은 검증 키트를 적용함으로써 툴에 필요한 컨피던스를 생성한다. 툴 검증의 선제 조건은 아래의 두 개의 프로세스에 의해 결정된다:
- 개발 프로세스 중의 모든 툴의 툴 체인 분석 중 필요한 검증의 결정(상단 왼쪽에 표시).
- 자격 요건에 맞는 검증 키트의 유효성 (하단 왼쪽에 표시)

툴 검증에는 분류 결정 검증 요구와 이러한 요구를 충족하는 키트가 필요하다. 만약 툴 체인 분석에서 컨피던스 자격 요건이 필요 없는 툴로 분류될 경우, 검증 프로세스는 생략될 수 있다. 모든 경우에(툴 검증이 필요 없는 경우에도) 툴의 적용에는 툴의 분류 과정에서 자격 요건을 명시한 가이드라인(툴 안전 매뉴얼)이 필요하며 사용자가 올바르게 툴을 운영하기 위해서 반드시 따라야 한다(예: 사용된 기능 제한 혹은 특정 검증 절차 요구).
툴 검증 프로세스는 사용된 기능에 관한 구체적 정보와 발생 가능한 툴 에러를 감지 혹은 방지하도록 하는 적용 가능한 가이드라인을 명시한 통합적 툴 분류로부터 도움을 얻을 수 있다. 이러한 경우 툴 사용자는 툴의 “크리티컬 에러”만 충족하면 된다. 크리티컬 에러란 선택된 툴 기능의 적용 과정에서 생겨날 수 있는 에러를 뜻하며, 적용된 프로세스에서 높은 감지 능력 혹은 방지 능력이 부재하다. 좋은 검증 키트는 크리티컬 에러의 결정과정 동안 툴 사용자를 지원하며 크리티컬 에러의 부재 동안 컨피던스를 제공하는 테스트 사례를 제공한다.
물론 크리티컬 에러의 양은 완화 조치를 적용함으로써 검증 없이 줄어들 수 있다. 그러나 추가 및 비싼 프로세스 단계가 필요하다. 따라서 검증 키트 적용의 목적은 툴 애플리케이션 상 가장 적은 에러 완화 규제로 되도록 많은 기능에 충족하는 것이다. 반면 툴의 모든 기능을 테스트하는 검증 키트의 제작에는 많은 노력이 필요하다. 따라서 테스트를 성공적으로 수행함으로써 피할 수 있는 완화 조치에 따른 테스트 생성의 우선순위가 존재한다. 선택된 최적의 툴 기능을 보유한 검증 키트를 정해진 시간 내에 만드는 것은 적절한 툴의 모델과 수용 가능한 사용자 제한 없이는 불가능하다. 검증 키트의 적용과정에서 사용자는 어느 툴 기능을 사용할지 선택할 수 있다. 각각 기능에서 기능의 사용가능성을 규정하는 “검증 상태”를 확인할 수 있다. 

- 빨강: 기능의 잠재적 에러를 위한 테스트나 완화 조치가 없기 때문에 기능이 사용될 수 없다.
- 노랑: 기능의 잠재적 에러를 완화하기 위한 가이드라인을 적용한다는 규제 하에 기능을 사용할 수 있다.
- 초록: 잠재적 에러가 없다는 것을 검증해줄 수 있는 테스트가 있기에 기능을 제약 없이 사용할 수 있다.

3. 모델 기반 툴 검증
안전성 기준(ISO 26262, IEC 61508, DO-178/DO-330)에 따르면, 사용자는 안전 필수 제품의 개발을 위해 사용하는 툴을 분석해야 한다. 분석의 결과는 툴 분류 리포트에 명시되어 있는 툴의 신뢰성에 대한 자격 요건이다.
개발 프로세스에서 사용되는 툴의 사용 예제의 분석에 의해 컨피던스가 결정된다. 만약 툴이 제품의 안전성에 영향을 미치면 사용된 기능 내의 모든 잠재적 에러가 프로세스 내 어떻게 감지되고 예방될 수 있을지 분석된다. 에러 감지 및 방지 가능성이 낮다면 툴은 이러한 에러가 없다는 자격 요건을 충족해야 한다.
툴을 위한 툴 안전 매뉴얼은 툴 분류 과정 시 고려되는 모든 잠재적 툴 에러를 중재할 수 있는 조치를 포함해야 한다. 에러는 세 가지의 경우로 분류될 수 있다(그림 2 참고):



1. 사용되지 않은 기능에서의 발생 가능한 에러(그림 2의 초록색 부분) : 이러한 기능을 사용하는 것은 툴 안전 매뉴얼(그림 2의 오른쪽 상단 차트)에서 금지되어 있다. 사용자는 잠재적 에러에 대응해야 한다. 툴 안전 매뉴얼에서 이러한 제한은 차트의 흰색 파이로 표시돼 있다.

2. 완화 조치와 잠재적 에러(그림 2의 노란색 부분) : 툴 안전 매뉴얼에서 설명된 감지 및 규제 메커니즘을 위한 발생 가능한 에러를 포함한다.

3. 남아있는 잠재적 에러(그림 2의 빨간색 부분) : 툴 검증(툴 검증 계획)의 목적은 이 카테고리의 잠재적 에러의 부재를 증명하는 것이다.

툴 검증 리포트(그림 2의 오른쪽 하단 차트)는 잠재적 에러의 구체적 사례를 보여준다. 검증 리포트는 이러한 구체적 에러의 대응사례를 포함하며 안전 툴 매뉴얼(그림 2의 오른쪽 상단 차트)의 일부로 정보를 개재한다.

따라서 툴 안전 매뉴얼은 다음과 같은 정보를 반드시 포함해야 한다.

- 툴의 허락된 기능과 배열
- 잠재적 툴 에러를 완화하기 위한 검증 및 규제 적용 자격 요건:
   요청된 기능 내에 발생 가능한 에러 및 툴 검증에 제외되지 않은 에러
- 검증과정에서 발견된 알려진 버그 및 에러 대응
- 툴을 정확히 확인하기 위한 안전기준이 명시한 여타 정보(예: 버전, 배열)

툴 검증 계획은 반드시 TI C/C++ 컴파일러의 “감지 불가능, 예방 불가능한” 잠재적 에러를 발견해야 하며 발생할 수 없도록 해야 한다. 체계적인 검증방법을 적용하여 감지 불가능하며 예방 불가능한 에러들이 부재한다는 사실을 증명해야 한다. 
TI C/C++ 컴파일러가 이 계획에 따라 검증을 사용하여 자격 요건을 충족하므로, 다음의 문서가 제공된다: (모델에 따른 문서는 이탤릭체로 표기되었다.)

- 테스트 플랜 : (실행을 위한 필요 테스트 사례 명시)
- 테스트 리포트 : (테스트 결과 포함)
- 테스트 자동화 유닛 매뉴얼 : (계획된 테스트 사례를 올바르게 실행하기 위한 설명 포함)
- 테스트 수트 확인 및 검증 문서(계획 및 보고) : 테스트 플랜이 성공적으로 통과할 시 에러의 부재를 증명

모델 및 확인이 확장되고 새로운 테스트 사례가 생성되고 검증되어야 할 시 다음 문서가 요구되거나 확장되어야 한다:
- 테스트 사양 : 잠재적 오류의 부재를 증명하기 위한 전략
- 테스트 수트  확인과 검증 계획 및 보고

테스트 수트는 이것이 선택된 타깃이 올바르게 작동한다는 리뷰와 검증을 통해 실행에 대해 검증했다. 이런 양질의 프로세스는 테스트 수트의 효과 내에 컨피던스를 생성한다. 테스트 수트를 위한 V&V 문서는 검증 키트에 포함되어 사용자에게 컨피던스의 수준을 증명한다. 만약 테스트가 확장된다면 문서 역시 확장되어야 한다.



그림 3은 문서와 그들의 다양성(예: 항상 일정한 것과 사용 사례에 따라 달라지는 것)과의 관계를 보여준다.
그림 3에서는 요구되는 문서와 사용자의 프로세스에 따라 개조돼야 할 문서가 상당수다. 프로세스는 요구되는 툴 기능과 실행된 완화 조치를 선택함으로써 검증 모델에서 보관된다. 사용자맞춤형 문서 내 사용 사례 맞춤 부분은 검증 지원 툴에서 생성된다.

4. 툴 검증 모델
툴 검증 모델은 완전한 툴 체인을 수집하기 위하여 제작되며 교환되는 아티팩트를 통해 연결되는 기능과 사용사례를 포함한 툴로 구성된다. 이는 툴 체인 내 데이터 흐름을 수집하는 단순한 “구조 모델”에 기반을 한다. 검증 요구를 결정하기 위해 이 모델은 소위 “분석 모델”에 의해 확장되는데, 이는 툴의 기능 및 사용사례에 지정된 잠재적 오류 및 완화 가능성(점검 및 규제)으로 구성된다. 세 번째 모델은 “검증 모델”이다. 검증 모델은 테스트 사례 설명 및 잠재적 오류로의 지정을 포함한다. 검증 키트의 개발과정에서 검증 모델은 잠재적 오류에 대한 체계적인 테스트의 유도를 위해 사용할 수 있다. 이 접근의 더 자세한 설명은 [WPJSZ12] 혹은 [TCA]에서 찾을 수 있다.



툴 검증 모델의 구성 및 사용은 그림 4에서 볼 수 있다. 논리적 시퀀스가 구조 모델의 생성에서 시작하고 분석으로 이어지며 검증 모델링에서 끝나는 와중 검증 키트는 이미 분석 및 검증 모델을 포함한다. 이러한 모델은 미리 지정된 구조에 기반을 하는데, 이는 사용자가 고를 수 있다. 이를 통해 사용자가 기능을 분석하거나 적절한 테스트를 찾지 않아도 되기 때문에 검증 프로세스가 간소화될 수 있다. 전 섹션에서 생성된 검증 문서에 대한 설명이 명시되어 있다.

5. 모델링 툴
모델 기반 접근은 이전 섹션에서 설명한 바와 같이 많은 장점이 있다. 모델과 작업하기 위해 두 가지의 툴이 필요하다:

1. 모델을 편집하기 위한 툴(예: 새로운 요소 추가)
2. 검증을 위해 모델을 사용할 툴

모델 기반 툴 검증 접근에서 우리는 검증 지원 툴을 사용하여 모델(섹션 5.1 참고)과 함께 작업하고 툴 체인 분석기를 사용하여 모델을 편집한다(섹션 5.2 참고).

5.1 검증 지원 툴: 검증 키트의 적용
검증 지원 툴은 검증과정에서 사용자를 안내하며 선택된 타깃 디렉토리 내의 검증을 위한 모든 필요한 아티팩트를 설치한다. 툴의 주요 목적은 희망하는 구조에 기반하여 검증의 요구를 파악하고 테스트를 선택하여 실행하며 사용자의 선택을 바탕으로 검증 문서를 생성한다.
만약 잠재적 오류가 해결되지 못한다면 툴에는 검증이 필요하다. 잠재적 오류는 사용되는 툴의 기능에 따라 다르다. 오류 중재 가능성은 적용된 프로세스에 따라 정해지는데, 특히 오류 중재(점검 및 규제)가 툴의 사용사례에 적용되거나 다른 툴 내에 적용될 때 오류 중재 가능성이 결정된다.
TI C/C++ 컴파일러의 검증요구는 툴의 사용된 기능의 선택 및 적용된 중재 조치 선택에 의해 결정된다. TI C/C++ 컴파일러 기능 리스트가 일관된 가운데 중재 리스트는 선택된 기능에 따라 다르다. 예를 들어 아무런 기능도 선택되지 않았다면 중재가 필요하지 않다.
툴이 성공적으로 자격요건을 충족하는지는 다음과 같은 요소에 달려있다:

- 필요한 중재로의 약속(선택된 기능에 의해 필요할 경우). 중재는 생성된 툴 안전 매뉴얼의 일부이다.
- 테스트 사례의 성공적인 실행(선택된 기능에 의해 필요할 경우).



이에 따라, 검증요구의 결정은 테스트 사례가 실행되어야 하거나 잠재적 오류를 해결하기 위한 사용제약이 프로세스(혹은 두 상황의 혼합) 내에 통합되어야 한다는 것을 보여준다.
맞춤형 테스트 사례는 툴 검증 플랜에 기록되어 있고 오류 중재는 툴 안전 매뉴얼에 기재되어 있다. 필요한 “검증 요구”는 소위 “Use Case Definition page”에서 결정된다(그림 5 참고). 그림 5는 아래의 6개 파트로 구성되어 있다:
- 상태 정보는 사용사례 이름과 선택된 기능 및 상태 정보의 숫자와 함께 페이지 상단에 기재되어 있다. 아무런 테스트도 기재되지 않을 경우 툴은 검증이 필요 없다(오류가 해결되고 “Next” 버튼이 활성화될 시).
- 식별: TI C/C++ 컴파일러의 사용사례의 이름 정의
- 기능: 사용되는 TI C/C++ 컴파일러의 기능 선택
- 잠재적 오류: 선택된 기능의 잠재적 오류를 보여줌. 오류는 다음과 같은 컬러 인코딩을 가지고 있다(섹션 2의 검증 상태 유사함):
  - 빨강: 오류는 충족되거나 중재될 수 없다. 이러한 경우 기능은 빨간 글자로 표시되었고 사용될 수 없다.
  - 분홍: (가독성을 높이기 위해 섹션 2에서 사용한 노란색 대신 분홍색 글자를 사용) : 오류를 중재할 수 있다(그러나 테스트에 의해 충족될 수는 없다). 분홍색 오류가 선택될 경우 해당하는 중재가 중재 파트에서 표시된다. 분홍색 오류는 초록색(중재 선택 시) 혹은 이 오류를 위한 중재가 선택되지 않을 시 노란색의 중지 심벌로 표시된다.
  - 초록: 이 오류의 부재를 보여주는 테스트가 최소한 한 개 이상이다.
- 중재: 적용 가능한 셀렉션을 위한 셀렉션 가능성을 제공한다.
- 내비게이션: 하단에 사용자가 다음 장으로 넘어가거나(“Next >”) 검증 준비를 마칠 수 있는 (“Finish”) 내비게이션 라인이 있다. 충분한 중재가 선택되었을 때 이 버튼이 활성화된다.
페이지의 배경색은 전반적 검증의 상태를 나타낸다(섹션 2 참고).

 5.2 툴 체인 분석기: 검증 키트 확장
Tool Chain Analyzer 툴은 검증 키트의 일부가 아니며, 따라서 검증 키트에 포함돼 있지 않다. Tool Chain Analyzer 툴은 www.validas.de/TCA.html에서 구입 가능하다. 이를 사용하여 툴 체인을 분석할 수 있고(섹션 2의 첫 번째 프로세스를 참조하시오) 검증 키트를 확장할 수 있다.
TI C/C++ 컴파일러를 위한 툴 검증 키트는 다음의 요소를 통해 사용자에 의해 확장될 수 있다:

- 새롭거나 현재 검증 키트에서 다루어지지 않는 새 기능 요소
- 잠재적 오류 해결을 위한 새 안전 가이드라인
- 새 테스트 사례를 위한 새 테스트 요소

검증 키트의 모든 확장은 최대 네 개의 단계로 구성되어 있으며, 이에 대한 설명은 검증 키트의 사용자 매뉴얼에 기재되어 있다.

1. 모델 확장
2. 모델 인증
3. 테스트 수트 확장
4. 테스트 수트 인증

자세한 사항은 검증 키트의 사용자 매뉴얼에 기재되어 있다.

6. SafeTI™ 컴파일러 검증 키트
SafeTI™ 컴파일러 검증 키트는 이전 섹션에서 묘사된 바와 같이 모델 기반의 검증 키트다. TI C/C++ 컴파일러는 다음의 모델 기능을 보유하며 사용될 수 있다:

- ISO/IEC 9899:1990 (C++ ANSI/ISO/IEC 14882:1998)에 의해 정의된 C 언어
- Parser, Optimizer, Code Generator, Assembler, Linker 등의 컴포넌트 기능
- 썸(Thumb) 명령어 세트, 부동소수점 하드웨어, 혹은 최적화 레벨과 같은 옵션 기능

SafeTI 컴파일러 검증 키트를 통해 사용자는 사용하고자 하는 기능을 선택함으로써 맞춤형 개인사용 사례를 생성할 수 있다. 서로 영향을 주더라도 기능은 개별적으로 다루어진다. 테스트 전략은 기능을 개별적으로 분석하고 선택된 기능을 위한 테스트와 아규멘테이션(argumentation)을 각각 제공하는 것이다. 이는 TI C/C++ 컴파일러의 코드 커버리지의 분석을 통해 합리화된다. 검증 도중 테스트 커버리지가 적용 중 커버리지와 차이가 있을 경우 아규멘테이션 내의 이 간격은 다음의 단계를 통해 좁혀질 수 있다.

1. 검증 테스트 시 TI C/C++ 컴파일러의 커버리지 측정
2. 툴의 적용 시 TI C/C++ 컴파일러의 커버리지 측정
3. 두 시나리오 사이의 TI C/C++ 컴파일러의 소스코드 상 커버리지 비교 및 차이 분석

애플리케이션에 사용되는 컴파일러의 모든 기능은 검증 중 고려되어야 한다. 코드 커버리지가 충분할 경우 테스트된 기능이 충분히 독립적이거나 테스트 사례가 이미 함축적으로 콤비네이션을 시험한다는 것을 의미한다.

6.1 TI C/C++ 컴파일러
TI는 ARM을 포함한 많은 TI 임베디드 프로세서 플랫폼을 위해 C/C++ 컴파일러를 개발한다. TI는 30년 가까이 컴파일러를 개발해 왔으며 고성능 아키텍처(VLIW, DSP, SIMD, μC, RISC, CISC)의 컴파일링에 관련해 많은 작업을 해왔다.
TI 컴파일러는 최첨단 완전 프로그램 최적화를 포함한 각 타깃을 위한 고도의 최적화 코드를 생성한다. 각각의 컴파일러는 출시되기 전 고도의 통합적인 인증 및 벤치마킹 절차를 거친다.

6.2 SafeTI™ 컴파일러 검증 키트의 내용
SafeTI 컴파일러 검증 키트는 다음의 요소를 포함한다:

- 문서:
   ㆍ 검증 키트의 사용자 매뉴얼
   ㆍ 테스트 자동화 유닛(Test Automation Unit, TAU)의 사용자 매뉴얼
   ㆍ 문서의 탬플릿
- 툴 분류 리포트
- 툴 검증 플랜/리포트
- 툴 안전 매뉴얼
- 테스트(섹션 6.2.4 참고)
- 컴파일러의 C 언어 컴포먼스를 테스트하기 위한 슈퍼테스트 검증
- TI 맞춤 인증 테스트 사례
- 테스트 자동화 유닛(섹션 6.2.3 참고)
- 커버리지 측정을 위해 계기화된 버전의 컴파일러
- 코드 커버리지 측정 설치 및 수집을 위한 스크립트2
- 검증 지원 툴(검증 모델 포함, 섹션 5.1 참고)
- Validas AG로부터 24시간 검증 지원 가능

6.2.1 검증 모델
TI C/C++ 컴파일러를 위한 검증 모델은 잠재적 오류를 유도하기 위해 분석된 여러 기능을 포함한다. 모든 기능은 모델 내 서로 다른 잠재적 오류를 가진다. 검증 상태(섹션 2 참고)에 따르면 세 종류의 기능이 있다:

- 실험 가능 : 실험 가능한 기능이란 지정된 테스트 사례가 있어 기능의 모든 잠재적 오류가 없다는 것을 보여준다. 예를 들어 C 언어 기능 “루프”는 다양한 루프 및 콤비네이션을 포함하는 슈퍼테스트 검증 수트 내 통합적 테스트 사례에 지정되어 있다(섹션 6.2.4 참고). 
- 중재 가능 : 중재 가능한 오류란 쉽게 감지하고 방지할 수 있는 오류를 말한다. 예를 들어 옵티마이제이션(optimization) 사용 시 오류가 발생하면 테스트를 두 번 실행하여(한 번은 옵티마이제이션 없이, 두 번째는 옵티마이제이션과 함께) 이를 감지할 수 있다.
- 기타 : 기타 기능으로는 충족될 수 없는 (예를 들어 C++ 탬플릿 사용 시) 것들을 포함한다. 현재 이러한 기능을 위한 테스트나 중재가 없기 때문에 안전하게 사용될 수 없다.

6.2.2 검증 지원 툴
검증 지원 툴은 TI C/C++ 컴파일러를 위한 모델과 함께 설정되었으며 변경되거나 직접적으로 충족될 수 있는 레퍼런스를 포함한다. 섹션 5.1에 검증 지원 툴에 대한 설명이 기술돼 있다.

6.2.3 테스트 자동화 유닛
테스트 자동화 유닛은 타깃 상의 테스트 사례의 실행을 자동화한다. SafeTI 컴파일러 검증 키트는 검증 지원 툴이 제공하는 테스트 사례를 위한 프레임워크를 제공한다. 테스트 프레임워크는 생성되는 실행 파일을 수집하고 이를 평가 보드로 보내며 테스트 결과를 다시 수집할 것이다. 테스트 프레임워크는 윈도우 및 리눅스에서 지원 가능하며 명령 라인 옵션을 제공한다. 이는 Perl 및 CCS(Code Compo-
ser Studio) v5 통합 개발 환경(IDE)을 사용하며 하드웨어 에뮬레이션 환경에 테스트 사례를 실행한다.
이 키트는 Hercules TMS570LS
3137 MCU 하드웨어 개발 보드 [TMDX570LS31HDK]에서 온보드 에뮬레이터 USB XDS100v2와 에뮬레이터 [XDS560v2]를 사용하여 테스트되었다. 다른 Hercules™ ARM® 코어텍스™-R4 기반 MCU와 에뮬레이션 옵션은 지원 가능하다.

6.2.4 슈퍼테스트 및 TI 테스트
관련 컴퓨터 전문가(ACE)로부터의 슈퍼테스트 검증 수트는 SafeTI 컴파일러 검증 키트의 일환으로 통합된다. 이 검증 수트는 C 표준의 엄격한 준수를 보장하고 기능적 안전 기준에 대한 컴파일러 검증을 지원하기 위해 ACE의 슈퍼테스트 컴파일러 테스트 및 인증 수트로부터 유도되었다.
슈퍼테스트는 C/C++ 컴파일러의 가장 정밀한 테스팅을 제공한다. ACE는 컴파일러의 개발자 및 컴파일러 개발자 툴로서 컴파일러 테스팅 및 인증을 위해 슈퍼테스트를 주요 툴로 사용한다. 30년 전부터 개발된 슈퍼테스트는 외부 컴파일러 개발자들에 의해 사용되는 ACE의 제품 역할을 했다.
내부 사용 피드백, 외부 피드백, C 표준의 새로운 버전, 새 분석 및 최적화 테크닉 및 새 컴파일러 사용 사례를 바탕으로 슈퍼테스트는 계속해서 증가되었고 업데이트되었으며 컴파일러 테스팅 및 인증의 선두에 위치하고 있다.
슈퍼테스트 내의 테스트는 컴파일러의 모든 부분을 검증하고 언어 적합성 내의 문제를 파악하며 최적화 및 전환 같은 내부 기능 또한 파악한다. 컴파일러 커버리지 테스팅은 또한 슈퍼테스트의 연장을 위한 새 영역을 파악하기 위해서도 사용된다. 슈퍼테스트의 테스트 프로그램은 접근의 용이와 완전한 랭귀지 커버리지 보장을 위해 C 표준에 의해 명령된다. 구체적 C 기능의 경우, “유틸리티 세트”라는 것이 있는데, 이는 특별한 테스트 사례를 포함한다. 예로 “루프” 기능을 위한 유틸리티 세트는 다음의 테스트 사례를 포함하는데, 이는 두 개의 내포된 루프(nested loop)와 포인터 및 산술 주소의 비단순 처리를 구체화 한다:

i = b[0];
p = &a[i];
for( j = *p; i < AR_SIZE; ){
    q = &i;
    for( ; j >= i ; ){
        c[(*q)++] = *p;
    }
    p += (a[*q-1] = = b[j++]);
}
CVAL_VERIFY( i = = AR_SIZE );
CVAL_VERIFY( j = = AR_SIZE );
CVAL_VERIFY( p = = &a[AR_SIZE] );

예제가 보여주는 바와 같이, 테스트 사례는 적절한 코딩 스타일에 의해 반드시 깔끔하게 코드화되지 않는데, 왜냐면 컴파일러가 “지저분한” 사례도 처리할 수 있어야 하기 때문이다.
일반적으로 테스트 사례는 특정 기능에 중점을 두어 오류가 발생하면 오류의 근원이 분명하다. TI 컴파일러 검증 키트 내에 포함된 슈퍼테스트의 버전이 특별히 TI ARM C/C++ 컴파일러의 검증을 위한 TI 키트 내의 사용을 위한 것이다.
TI 테스트는 컴파일러의 모든 주요 기능에 포함되어 있는데, 예를 들어 ARM 타깃 및 코드 생성, EABI, 옵티마이제이션, 링크 타임 옵티마이제이션, 디버그 정보 생성, 프라그마/인트린직(pragmas/intrinsic), 링킹 등이 있다.

6.2.5 생성되는 문서
다음의 C/C++ 컴파일러 검증을 위한 문서는 모델 셀렉션을 바탕으로 생성된다(아래 리스트에 “”은 검증을 위해 선택된 디렉토리를 뜻하며 “”는 맞춤사용 사례를 의미한다.):

- 툴 분류 리포트: 사용에 따라 툴의 분류를 포함하며, \Validation\Documentation\TCR.docx에서 생성된다.
- 툴 검증 플랜: 사용에 따른 인증을 계획한다. \Validation\Documentation\TQP.docx에서 생성된다.
-  테스트 플랜: 검증을 위해 실행되어야 할 테스트 수트 내 디렉토리 리스트.    \Validation\TestExecution.txt에서 생성된다.
- 테스트 리포트: 테스트 결과는 디렉토리 \Validation\TestReport\ 에서 생성된다.
- 툴 검증 리포트: 인증 결과에 의한 검증 플랜의 확장\Validation\Documentation\TQR.docx에 위치한다.
- 툴 안전 매뉴얼: 분류와 검증에 따른 툴 사용 가이드라인을 포함한다. \Validation\Documentation\TSM.docx에서 생성된다.
- 툴 체인 모델: 맞춤 사용사례를 묘사한다. \Validation\Documentation\. tca에서 생성된다.

6.3 표준 준수
여기에 명시된 툴 검증 및 안전 가이드라인 관련 안전 기준 자격요건은 주로 ISO 26262, IEC 61508, DO-330으로부터 기원한다. 그 밖의 다른 안전 기준(EN50128, DO-178-C 등) 역시 비슷한 자격요건을 포함한다. 검증의 사용자 매뉴얼 내에 관련 자격요건이 명시되어 있으며, 여기에는 어떻게 자격요건이 충족되는지에 대한 설명도 포함돼 있다.

6.4 프로젝트 경력
검증 프로세스는 여러 번 적용되었다. 검증 프로젝트는 설정의 정의에서부터 검증 리포트 생성까지 대략 5주정도 소요된다. 여기에는 플래닝, 테스트 실행, 코드 커버리지 측정 및 비교, 테스트 분석, 리포트 생성 및 문서 리뷰 등이 포함된다.  ES


TI, 레고 로봇 플랫폼에 솔루션 적용

TI가 레고(LEGO)® 마인드스톰(MINDSTORMS)® EV3 로봇 플랫폼에 Sitara 프로세서와 커넥티비티 및 아날로그 솔루션을 적용했다. 이들 로봇 툴 키트는 프로그래밍이 가능한 맞춤형 로봇 제작에 필요한 하드웨어와 소프트웨어를 제공한다. 또한 TI의 Sitara AM1808 ARM9™ 프로세서에 의해 구동되는 모터 제어와 센서 모니터링, 리눅스 실행을 위해 프로그래머블 브릭 컴퓨터를 포함한다. 이 브릭 컴퓨터는 TI의 CC2560 블루투스 커넥티비티 솔루션이 적용되어, 사용자가 애플 iOS 및 안드로이드 앱을 사용하는 모바일 기기로 로봇을 제어할 수 있다. TI의 밀러 아데르(Miller Adair) Sitara 프로세서 총괄 매니저는 “마인드스톰 플랫폼은 기술 수준을 향상할 수 있는 창의적인 인터액티브 환경을 제공한다”며 “TI의 Sitara 프로세서와 블루투스 커넥티비티 솔루션은 새로운 EV3 브릭을 구동하는 핵심으로써, 사용자들이 놀이하듯이 재미있게 구축, 엔지니어링, 프로그래밍을 탐색/학습할 수 있는 환경을 제공한다”고 말했다.