페이퍼요약 - 실시간 시스템 테스팅의 난제 by Grindal

제목: 실시간 시스템 테스팅의 난제(Challenges in Testing Real-Time Systems)

저자: Mats Grindal 외 1인, 스웨덴

문서유형: 페이퍼(총 13페이지)

 

실시간 시스템 설계의 대표적인 패러다임인 이벤트 트리거(event-triggered)와 타임 트리거(time-triggered)에 대하여 테스트용이성(관측성과 통제성) 측면에서 고찰한 자료

---

실시간 시스템 이란

• 실시간 작업(a real-time task)은 주어진 입력(이벤트)에 대한 처리(computation) 결과를 요구되는 마감 시간(deadline) 내에 생성해야 하는 것을 의미하며, 실시간 시스템은 적어도 하나 이상의 실시간 작업을 포함한 시스템을 말한다.
• 실시간 시스템에서는 정확한 결과 값과 시간 준수의 두 가지 측면이 모두 중요시된다.

실시간 시스템 구분

실시간 시스템은 데드라인 준수 엄격성 정도에 따라 아래와 같은 4가지 그룹으로 분류됨

• 소프트리얼타임 시스템(a soft real-time system): 데드라인을 준수하는 것이 가장 좋겠지만 데드라인 이후에 작업을 완료해도 여전히 유용하며 때때로 데드라인을 넘기는 것이 허용됨
• 펌리얼타임 시스템(a firm real-time system): 데드라인 이후에 작업을 완료하는 것이 유용하지는 않지만 그로 인한 비용을 발생시키지도 않음
• 하드에센셜리얼타임 시스템(a hard essential real-time system): 데드라인을 지키지 못함으로 인한 비용이 필수적으로 발생(예, 빌링 시스템)
• 하드크리티컬 시스템(a hard critical system): 데드라인 준수를 못하는 경우 인명 피해 같은 치명적인 결과를 초래(예, 항공 교통 통제 시스템)

실시간 시스템의 입력 이벤트

• 실시간 시스템 설계에서 이벤트의 타입(예, 온도 센싱, 키보드 명령어, 엘리베이터 콜 버튼 누름)과 빈도가 중요한 고려사항임
• 특정 환경에서 예상되는 최고부하치(peak load)도 대개 이벤트의 타입과 그 빈도를 고려하여 산정됨
• 이벤트 타입은 아래와 같이 세 가지로 구분될 수 있음
  - 주기적(periodic): 특정 이벤트 타입의 이벤트가 일정한 (그리고 알려진) 주기를 가지고 발생할 때
  - 산발적(sporadic): 특정 이벤트 타입의 이벤트가 아무 때나 발생하기는 하지만 두 개의 연속된 이벤트 간에 알려진 최소한의 도착간격시간(inter-arrival time)이 존재할 때
  - 비주기적(aperiodic): 이벤트가 얼마나 자주 발생하지 언제 발생할지 등에 대해 아무것도 알려진 바가 없을 때

실시간 시스템 테스팅

• 전통적인 테스팅 원칙, 즉 비실시간 시스템의 결과값 측면(the value domain)을 테스트 하는데 사용되는 전략과 방법 대부분이 별다른 변경 없이 실시간 시스템에 적용 가능함
• 실시간 시스템 테스팅에서 주요 과제는 시간이라는 패러미터가 중요시 되면서 애플리케이션이 결과값 측면(the value domain)에서 뿐만 아니라 시간 측면(the temporal domain)에서도 테스트되어야 한다는 점
• 시간 측면의 테스팅을 위해서는 아래 같은 여러 사항들이 고려될 필요가 있음
  - 테스트 오브젝트에 대한 입력이 정확하게 특정 시점에 일어나야 함
  - 테스트 실행 시작 시 테스트 오브젝트의 시간적 상태(temporal state)를 통제해야 함
  - 테스트 결과의 타이밍이 관측되어야 함
  - 비확정성(non-determinism)의 가능성이 존재
• 시스템의 원활한 테스팅을 위해 요구되는 테스트용이성(testability)은 관측성과 통제성의 두 개념에 크게 의존함. 관측성(observability)은 시스템이 무엇을, 어떻게, 언제 수행 하는지에 대한 관측/모니터를 용이하게 하는 기능이며, 통제성(controllability)은 테스트 케이스의 실행/재실행을 사용자가 통제 할 수 있게 하는 기능을 의미

스케쥴링(Scheduling)

• 대부분의 실시간 시스템에서 하나 이상의 작업(task)이 동시에 실행되지만 한번에 하나의 작업만이 프로세서나 기타 컴퓨팅 자원을 사용할 수 있음(멀티프로세서 시스템은 범위에서 제외)
• 따라서 작업들의 실행 순서를 결정하는 규칙(rules)이 필요한데, 이렇게 특정 규칙에 기반하여 작업 실행 순서를 결정하는 것을 스케쥴링(scheduling)이라 함
• 스케줄링은 정적 스케쥴링(static scheduling)과 동적 스케쥴링(dynamic scheduling)로 구분되며 테스팅 전략에 영향을 미치는 중요한 설계 항목임
• 정적 스케쥴링에서는 작업의 실행 순서가 사전에 결정됨. 프로세서는 한 작업의 실행이 완료되자마자 사전 계산된 순서가 저장된 테이블을 참고하여 실행할 다음 작업을 찾음
• 동적 스케쥴링에서는 사전 계산된 실행 순서가 없고 대신 두 개 이상의 작업이 동시에 실행을 원할 때 이를 어떻게 해결할지에 대한 규칙들이 존재함. 예를 들어 각 작업에 우선순위를 할당하고 우선순위에 따라 실행 순서를 결정. 이 때 높은 우선순위의 작업이 낮은 우선순위의 작업의 실행을 가로채는 preemption이 종종 발생함

설계 패러다임

실시간 시스템 설계 패러다임은 시스템과 환경 간의 커뮤니케이션이 언제 수행되는지에 차이가 있는 타임 트리거(time-triggered)와 이벤트 트리거(event-triggered)의 두 가지로 구분됨

1) 타임 트리거 시스템(a time-triggered system)

• 사전 정의된 특정 시점에만 주변 환경과 커뮤니케이션함. 지난 커뮤니케이션 시점 이후로 발생한 이벤트들은 다음 커뮤니케이션 시점이 될 때 까지는 실시간 시스템에 의해 식별되거나 처리되지 않으며, 마찬가지로 시스템의 처리 결과도 다음 커뮤니케이션 시점이 되기 전까지는 주변 환경에 전달되지 않음
• 두 커뮤니케이션 시점 간의 시간인 사이클 타임(the cycle time)이 예상되는 작업(또는 작업들의 조합)의 최대 실행 시간(the worst-case execution time)을 커버할 수 있도록 충분히 길어야 함. 즉 최악 경우(a worst case)를 가정하여 시스템이 설계됨
• 대개 폴링(polling)을 통해 구현되며 정적 스케쥴링을 사용함

2) 이벤트 트리거 시스템(an event-triggered system)

• 시스템과 환경 간에 커뮤니케이션이 발생하는 특정 시점이 존재하지 않으며 대신 이벤트를 관찰하여 발생 시 이에 반응함. 시스템에서 생성된 결과도 준비가 되자마자 바로 주변 환경에 전달됨
• 반드시 동적으로 스케줄 되어야 하며, 일반적으로 인터럽트(interrupts)를 통하여 구현됨
• 타임 트리거 시스템과 달리 과부하 상황(overload situations)에 직면할 수 있으므로 그런 상황을 동적으로 처리할 수 있도록 설계되어야 함. 즉, 데드라인 준수를 못하게 되는 경우가 생길 수 있으며, 설계자는 그런 상황에서 피해를 최소화 하고 적어도 일정 수준의 서비스는 보장되도록 해야 한다(예, 최고 부하 수준을 정확하게 산정하여 과부하에서도 최저 수준 서비스를 보장할 수 있는 충분한 자원을 가진 시스템을 설계)

실시간 시스템 설계 패러다임의 테스팅 이슈

위의 두 가지 설계 패러다임 중 어떤 것을 선택하느냐에 따라 실시간 시스템의 특성이 달라지고 테스팅에도 영향을 미치게 된다.

1) 테스트용이성(Testability)

• 타임 트리거 설계: 모든 이벤트가 동시에(즉, 다음 커뮤니케이션 시점)에 커뮤니케이션 되므로 특정 관측 기간(the observation interval) 동안 발생된 이벤트 순서가 중요하지 않음. 이벤트 발생 순서와 상관없이 각 이벤트에 상응하는 작업들이 정적 스케쥴의 순서에 따라 실행되므로 시스템의 가능한 동작이 한정되어 커버리지 기반의 테스트가 가능해짐
• 이벤트 트리거 설계: 동적 스케쥴링 알고리즘이 현재 상황(시스템의 상태와 입력 이벤트)에 기반하여 지속적으로 작업 실행의 순서를 변경시키므로 이벤트의 순서가 달라지면 동작도 달라짐. 더욱이 같은 순서를 가진 두 이벤트 시퀀스도 스케쥴링의 동적인 동작으로 인해 각 이벤트가 발생한 시점에 따라 결과가 달라질 수 있음. 또한 많은 동적 스케쥴링 알고리즘이 휴리스틱(heuristic)을 사용하므로 동일한 초기 상태에서 동일한 타이밍에 동일한 입력을 실행했어도 그 결과가 달라질 수 있다. 이런 특성이 테스팅을 더 어렵게 만들고 통계적 테스팅(statistical testing)의 사용을 요구하게 됨

2) 예측가능성(Predictability)

특정 작업(a task)과 그것의 실행 환경에 대한 지식으로부터 작업 결과(영향)를 명확하게 도출 가능한 경우 시스템이 “예측가능(predictable)하다”고 하지만, 임의성(Randomness), 휴리스틱(heuristics), 경쟁상황(race-conditions) 같이 예측가능성(predictability)에 부정적 영향을 주는 요인이 존재한다.

• 타임 트리거 설계: 작업 인터리빙(interleaving)이 사전에 완전하게 결정되는 정적 스케쥴링과 특정 관측 구간 동안의 이벤트 발생 순서의 무의미성이 시스템의 예측가능성을 증가시킴. 높은 예측가능성은 체계적인 커버리지 기준(systematic coverage criteria)의 테스팅을 가능하게 함. 예측가능성은 시스템이 모든 상황에서 의도대로 동작하는지에 대한 높은 신뢰도(confidence)가 요구되는 하드크리티컬리얼타임 시스템에서 특히 중요한 요소임
• 이벤트 트리거 설계: 동적 스케쥴링과 스케쥴링 의사결정에 관여된 휴리스틱이 주어진 입력 시퀀스에 대한 동작의 예측가능성을 저하시킴. 이는 테스트 결과에 대한 신뢰도를 감소시키며 회귀 테스팅도 어렵게 만듬. 이런 이유로 이벤트 트리거 시스템에서는 통계적 테스트 방법이 주로 사용됨(통계적 방법은 특정 입력 시퀀스와 관련된 모든 조건 하에서 시스템이 올바르게 동작한다는 신뢰도를 높이기 위해서 동일한 입력 시퀀스를 여러 번 반복 실행함). 예측가능성이 낮은 이벤트 트리거 설계는 하드리얼타임 시스템에 거의 사용되지 않음

3) 유연성(Flexibility)

• 타임 트리거 설계: 시스템의 변경에 있어 유연성이 낮음. 시스템 용량 확장이나 선행(전제) 조건 변경을 위해서는 정적 스케쥴을 재계산해야만 하고 그에 따른 시스템의 재통합과 재테스트가 요구됨(때때로 시스템의 재설계까지도 요구됨)
• 이벤트 트리거 설계: 본질적으로 유연성이 높음. 동적 스케쥴링과 과부하를 다룰 수 있는 능력으로 인해 예측이 어려운 환경에서 더 적합한 시스템이 될 수 있음. 하지만 시스템에 변경을 가하면 이전의 테스트 결과가 모두 무효가 될 수 있음에 주의해야 함

4) 효율성(Efficiency)

• 타임 트리거 설계: 스케쥴이 대개 정적이며 산발적 작업(Sporadic tasks)도 주기적인 작업인 것처럼 스케쥴됨. 작업들은 최대 실행 시간(the worst-case execution time)을 기준으로 실행됨. 작업이 최대 실행 시간보다 빨리 완료되어도 남은 시간을 다른 작업에 사용하지 못하므로 산발적 작업들의 실행 시간이 최대인 경우(the worst case)와 평균인 경우(the average case)의 차이가 크면 자원 낭비가 심함
• 이벤트 트리거 설계: 동적 스케쥴링을 통해 산발적 작업이 도착하는 대로 스케쥴 됨(현재 실행중인 작업보다 더 중요한 작업은 preemption을 통해 먼저 실행되는 반면 중요도가 낮은 작업들은 기다려야 함). 사용되지 않은 시간을 동적 스케쥴링을 통해 덜 중요한 작업을 위해 쓸 수 있으므로 평균 실행 시간(the average-case execution time)과 최대 실행 기간(the worst-case execution time) 간의 차이가 있는 경우 타임 트리거 시스템에 비하여 효율성이 훨씬 좋음

100% 완전하게 타임 트리거이거나 이벤트 트리거인 시스템은 드물며 많은 시스템이 양쪽 패러다임의 특성을 골고루 가지고 있을 수 있다. 예를 들어 시스템의 핵심 부분(the critical parts)을 비핵심 부분(the non-critical parts)으로부터 분리가 가능한 경우 핵심 부분은 높은 예측가능성을 위해 타임 트리거 패러다임으로 설계하고 나머지는 효율성이 더 좋은 이벤트 트리거 패러다임으로 설계할 수 있다.

실시간 시스템의 관측성(observability)과 통제성(controllability) 확보 방안

1) 추적(Traces) 또는 계측(Instrumentations)

• 테스팅에서 관측성(observability)을 용이하게 하기 위해 흔히 사용하는 방법인 추적(traces)은 테스트 대상 오브젝트에 특정 관심 변수의 값을 출력하는 코드 구문(write statements)을 추가하고 해당 코드가 테스트 실행 중에 생성한 로그를 분석하여 테스트 결과를 판단하거나 실패 원인을 식별함
• 단점은 테스트에서 인스트루먼트된(계측 코드가 추가된) 시스템의 동작이 실제 시스템 최종 버전의 동작과 달라지게 되는 탐사 효과(probe effect)가 생길 수 있는데, 두 가지 이유에서 비실시간 시스템보다 실시간 시스템에서 probe effect이 더 심각함
  - 첫째, 시간 정보를 포함하기 위하여 더 많은 정보를 traces에 담을 필요가 있으며 이는 더 많은 인스트루멘테이션 코드의 삽입으로 이어짐
  - 둘째, 삽입된 코드(code instructions)가 실행 시간에 영향을 주어 시스템의 시간 측면 동작(the temporal behavior)이 달라질 수 있음. 즉, 작업 실행 인터리빙에 영향을 주어 특정 작업의 응답 시간을 증가 또는 감소시킴(결과적으로 데드라인 준수 여부도 달라질 수 있음). 이는 테스트 오브젝트의 인스트루멘테이션된 버전으로부터 얻은 테스트 결과가 동일한 오브젝트의 원래 버전에서는 유효하지 않을 수도 있음을 의미함
• probe effect 해결법으로 인스트루멘테이션을 최종 제품에 그대로 남겨두는 방법이 있을 수 있지만, 이 경우 최종 사용자가 원하지 않는 인스트루멘테이션 정보를 감추는 메커니즘이 제공되어야 하며 또한 이 메커니즘 사용 자체가 애플리케이션의 타이밍을 변경시키지 말아야 할 것을 요구함 

2) 시스템 상태 조작 지원(Support for system state manipulation)

• 테스트 케이스의 시작 시점에 테스트 대상 시스템이 특정한 내적 상태가 되어 있어야만 하는 경우가 있음(예, 특정 변수가 특정 값을 가지고 있거나, 작업 큐에 특정 작업이 포함되어 있거나, 일정 양의 동적 메모리가 이미 할당되어 있거나 등). 따라서 테스트 케이스 실행에 앞서 시스템을 원하는 상태로 만드는 일이 테스터의 과제 중 하나임
• 이렇게 테스트 케이스 실행에 앞서 올바른 시스템 상태를 확보하는 일은 통제성(controllability)과 밀접하게 관련됨. 또한 의도한 시스템 상태가 정말로 달성되었는지 테스터가 확인하는 일도 포함되므로 관측성(observability)과도 관련됨
• 실시간 시스템에서는 테스트 케이스 실행을 위한 사전 조건에 시간적 요구사항(timing requirements)이 포함될 수도 있음(예, “특정 작업이 정확히 10 밀리초에 거쳐 이미 실행된 상태여야 한다”). 즉, 시간 측면(the temporal domain)에서도 시스템을 통제해야 하므로 값 측면(the value domain)에서만 시스템을 통제하는 비실시간 시스템의 테스팅보다 어려움이 더 가중됨
• 실시간 시스템에서 테스트 케이스 실행에 앞서 시간 도메인에 대한 요구사항이 있는 경우 현실적인 테스팅 방법으로는 통계적 접근법(a statistical approach)이나 시도-관찰 접근법(a trial-and-observe approach)이 있음
  - 통계적 접근법은 테스트 케이스를 충분히 여러 번 반복한다면 적어도 한번은 원하는 조건이 달성되었을 것이라는 가정에 기반하고 있으며 이를 확실하게 체크하지는 않음
  - 시도-관찰 접근법은 원하는 조건이 만족되었는지 판단이 가능하도록 테스트 케이스 실행에 앞서 실제 상태를 관측할 수 있는 수단이 마련될 것을 요구함

 

테스트 케이스 실행에 앞서 요구되는 내적 상태를 만드는 방법으로 두 가지를 들 수 있다.

• 첫째, 테스트 대상 시스템을 원하는 상태로 직접 전환 할 수 있는 특별한 테스트 베드 기능(test-bed functions)을 테스트 대상 시스템에서 제공하도록 요구함
• 둘째, 일단 초기 상태(an idle state)에서 시작하여 타 테스트 케이스와 셋업 스크립트(set-up scripts)의 실행을 통해 시스템을 의도한 상태로 만듬

테스터 입장에서는 첫 번째 방법(전용 테스트 베드 기능이 시스템에 포함되어 있음)이 훨씬 간편하지만 이 접근법이 아예 불가능한 경우도 있으며(예, 소프트웨어 컴포넌트를 다른 곳에서 import 해 올 때) 또는 가능하다 해도 수반하는 비용과 복잡성 때문에 실용적이지 않을 수도 있음. 또한 첫 번째 방법에서는 시스템 내에 빌트인 되어 있는 전용 테스트 베드 기능들이 악용되어 보안 위협이 되지 않도록 주의가 필요함

두 번째의 테스트 케이스와 셋업 스크립트를 사용하는 방법은 통제성(controllability)에 제약이 있기는 하지만 많은 경우에 유일하게 활용 가능한 옵션임

캐싱(Caching)

오늘날의 대부분의 상용 프로세서가 단일 또는 멀티 레벨의 캐시를 포함하고 있는데, 캐싱은 시스템의 성능을 향상시키지만 테스트용이성 측면에서는 취약점을 불러온다.

 

1) 캐싱이란

• 캐시(cache)는 프로세서 칩 상에 프로세서와 함께 올라가 있는 작은 메모리. 프로세서에 가깝게 위치해 있으므로 캐시 메모리로의 접근이 별도의 메모리 칩 상에 구현된 일반 메모리로의 접근보다 몇 배 빠름
• 따라서 캐시 메모리에 저장된 코드와 데이터를 가진 프로그램은 해당 프로그램이 일반 메모리에 저장된 경우보다 더 빠르게 실행됨
• 대개 캐시 메모리 크기가 작으므로 효율적인 사용을 위하여 프로그램이 곧 필요로 하는 데이터와 명령문(instructions)을 가져와서 캐시에 저장하고 더 이상 필요하지 않은 모든 데이터는 캐시에서 삭제함. 이런 작업은 캐시 교체 알고리즘(a cache replacement algorithm)에 의해 수행되지만 어떤 데이터가 곧 필요하게 될지, 어떤 데이터가 더 이상 사용되지 않아 교체 가능한지를 항상 완벽하게 추측하기는 불가능함

2) 캐싱으로 인한 실행 시간 예측불가능성

• 필요한 코드와 데이터가 필요한 시점에 캐시에 있는지 아닌지에 따라 실제 실행 시간이 달라짐. 즉, 작업의 실행 시간이 캐시 교체 정책(a cache replacement policy), 캐시 크기, 현재 캐시에 저장된 내용물 등에 의존하게 됨
• 컴퓨터 시스템에 캐시의 도입으로 인하여 실행 시간에 어느 정도의 예측불가능성(unpredictability)이 나타나게 되는데, 비실시간 시스템 테스팅의 경우 특정 작업의 실행 시간의 변동이 해당 작업의 결과에 영향을 주는 것이 아니므로 이 점이 대개 이슈가 되지 않음
• 하지만 실시간 시스템 테스팅에서는 캐싱이 테스트 결과에 깊은 영향을 미침. 예를 들어 캐시를 가진 시스템에서 데드라인을 준수하며 완료된 작업이 있다고 가정했을 때, 한 극단적 상황에서는 모든 메모리 접근이 캐시를 통해 가능했고(즉, 최소 실행 시간) 또 다른 극단적 상황에서 모든 메모리 접근이 일반 메모리를 통해서 수행되었을 수도 있음(즉, 최대 실행 시간). 테스터의 어려움은 캐싱 상황(the caching situation)이 어떠했는지가 대개 알려지지 않는다는 점

3) 실시간 시스템 테스트에서 캐싱을 다루는 일반적인 방법

• 테스팅 동안에는 캐시를 완전히 비활성화시키고 최악(최대) 실행 시간을 기준으로 함. 만약 특정 작업이 캐싱 없이 제 시간에 완료되면 캐시가 활성화된 상태에서도 제때에 완료가 될 것으로 가정함
• 하지만 이런 가정이 동적 스케쥴링에 따라 여러 작업들이 동시에 실행되는 이벤트 트리거 시스템에서는 항상 참이 아니다. 이유는 캐시가 활성화되면 캐시가 꺼져 있을 때와 작업 실행 시간이 달라지고 작업 인터리빙에도 변화가 생기기 때문임(인터리빙의 변화로 높은 우선순위의 작업이 현재 테스트 중인 작업에 프로세서가 할당되는 것을 막아 데드라인을 준수하지 못하게 만들 수 있음)
• 따라서 이벤트 트리거 실시간 시스템의 테스팅에서 캐시 문제의 최종 해결법은 시스템으로부터 캐시를 완전히 제거하는 것이며, 만약 캐싱이 사용된다면 유일하게 실용적인 테스팅 전략은 통계적 테스팅(statistical testing)이다.
• 타임 트리거 시스템에서는 사전 계산된 스케쥴이 최대 실행 시간(the worst case execution time)을 기준으로 해야 한다(즉, 캐시가 있는 시스템에서 필요한 데이터가 캐시에 존재하는 않은 경우를 가정함)

결론

위에 기술된 것처럼 실시간 시스템이 어떻게 설계되는지가 테스팅 전략 및 테스트용이성(testability)에 큰 영향을 미치므로 테스터가 개발 초기 단계부터 설계에 참여하여 쉽게 간과될 수 있는 테스트용이성 확보를 위해 노력해야 한다.