페이퍼요약 - 실시간 시스템의 설계: 명세부터 구현과 검증까지 by Kopetz

제목: 실시간 시스템의 설계: 명세부터 구현과 검증까지(The design of real-time systems: from specification to implementation and verification)

저자: H. Kopetz 외 5인, 오스트리아

문서유형: 저널페이퍼(총 11페이지), 1991년

 

분산 하드 실시간 시스템의 설계(개발) 방법론을 기술한 자료

---

하드리얼타임시스템(hard real-time system) 설계의 주요 특성

신뢰성 있고 명확한(모호하지 않은) 하드리얼타임시스템을 구축하기 위해 요구되는 주요 특성으로 아래를 들 수 있다(설계 방법론이 이러한 특성을 제공해야 함)

• 예측가능성(Predictability): 타이밍 요구사항에 대한 고려사항을 개발 초기부터 통합하고 지원하여 예측 가능한 모든 부하 상황 및 에러 상황에서 명세된 타이밍 동작의 준수가 보장되는(그리고 준수 여부가 확인 가능한) 시스템이 배출되도록 한다.
• 테스트용이성(Testability): 테스트 커버리지, 관측성(observability), 통제가능성(controllability) 측면이 보장되어야 한다. 테스트 용이성은 많은 부분이 개발되는 시스템의 아키텍쳐 속성에 의해 결정되지만, 소프트웨어 설계 및 테스트 방법론에서 이러한 속성들을 잘 활용하여 테스트용이성이 확보되도록 주의 깊은 노력을 기울여야 한다.
• 에러 허용(Fault tolerance): 사람 대신 컴퓨터에 의한 통제가 증가하는 현실에서 에러 허용은 서비스 신뢰성을 달성할 수 있는 유용한 방법임. 실시간 애플리케이션은 문제 발생시 모든 작동이 중단되고 안전 상태(a safe state)로 돌아가는 ‘fail-stop’과 에러 하에서도 지속적으로 서비스가 제공되어야만 하는 ‘fail-operational’의 두 가지 타입으로 구분되며, 에러의 영향이나 처리 방법이 애플리케이션에 종속적이므로 시스템 설계 초기 단계부터 에러에 대한 추정 및 시스템 동작에 미치는 영향을 분석해야 한다(즉, 설계자가 기능적 요구사항과 별도로 에러 허용 측면도 고려해야 함)
• 시스템 설계(System design): 실시간 소프트웨어 개발은 본질적으로 기저가 되는 하드웨어(주변장치, 통신미디어, CPU)와 운영체제의 영향을 받으므로 타겟 시스템의 특징을 고려하지 않은 애플리케이션 소프트웨어 구축은 부적절하다. 즉, 실시간 시스템에서는 ‘소프트웨어 설계’ 보다는 ‘시스템 설계’가 고려되어야 하며, 설계 방법론도 하드웨어와 소프트웨어의 동시 개발을 일관성 있고 명확한 방식으로 허용하는 메커니즘을 제공해야 한다.
• 체계적 분해(Systematic decomposition): 설계 대상 시스템이 초기 요구사항부터 시작하여 더 작은 단위(이해가 쉽고 개별적으로 다룰 수 있는 모듈)로 점진적으로 분해되어야 한다. 이런 점진적 분해 프로세스는 시스템 개발 주기 전반에 거쳐 지속적으로 이어져야 한다.
• 평가가능성(Evaluability): 시간이 많이 소요되는 테스트 단계가 시작되기 전에 설계된 시스템을 평가하는 것이 바람직하다. 특히 시스템의 주요 부분이 수정되어야만 하는 상황(비용 손해가 큼)을 피하려면 평가 활동이 시스템 설계 프로세스에 통합되어 가능한 빠른 시점에 시작되어야 한다. 실시간 시스템에서의 주요 평가 활동으로 신뢰성 평가(dependability evaluation)와 타이밍 분석(timing analysis)을 들 수 있다.

아키텍쳐 가정(Architectural assumptions)

본 논문에서 제시한 설계 방법론은 아래 그림과 같은 시스템 아키텍쳐를 가정한다. 분산 하드리얼타임 시스템은 한 무리의 컴포넌트로 구성되며, 각 컴포넌트는 고정된 한 무리의 태스크(a fixed set of tasks)를 실행한다. 컴포넌트들은 확정적(deterministic) 커뮤니케이션 특징을 가지는 실시간 버스에 의해 상호 연결되며, 컴포넌트 간의(또한 태스크 간의) 커뮤니케이션은 주기적인 상태 메시지(periodic state messages)를 통해서만 실현된다. 높은 내적 논리 연결성을 가진 컴포넌트들이 모여(즉, 동일한 또는 밀접하게 연결된 시스템 기능을 책임지는 컴포넌트들) 하나의 클러스터(cluster)를 형성한다.

[참고 아키텍쳐]

주요 설계 오브젝트(design objects)

본 방법론에서 설계 오브젝트와 이 오브젝트들간의 상호관계는 설계 정보를 수집하고 유지하는 기본 메커니즘이 된다. 대표적인 설계 오브젝트로 아래가 있다.

• 트랜잭션(Transactions):
  - 시스템(또는 시스템 부분)의 기능적 동작과 타이밍 동작을 표현.
  - 자극(stimulus)에 의해 활성화(triggered)되고 그에 따른 반응(response)을 생성.
  - 자극은 트랜잭션이 활성화되는 조건을 결정(예, 기온>80 and 압력>2). 여기서 ‘기온’과 ‘압력’은 데이터 아이템(data items)을 나타냄.
  - 설계 과정에서 하나의 트랜잭션이 서브트랜잭션 시퀀스로 상세화되며, 최종적으로는 한 무리의 태스크 실행 및 프로토콜 실행(a set of tasks and protocol executions)으로 변환됨
  - 각 트랜잭션(또는 서브트랜잭션)은 추상화 레벨에 따라 전체 시스템, 클러스터, 클러스터 경로(즉, 두 클러스터간의 인터페이스), 또는 컴포넌트로 매핑됨
  - 트랜잭션의 중요 패러미터로 MART(MAximum Response Time: 최대 반응 시간)와 MINT(Minimal INTerval between two invocations of the same transaction: 동일 트랜잭션 호출의 최소 간격)가 있음
• 데이터 아이템(Data items):
  - 데이터 지향 요구사항(data-oriented requirements)을 기술하기 위해 사용됨.
  - 환경의 외부 상태와 통제하는 시스템(the controlling system)의 내부 상태를 나타냄.
  - 실시간 시스템의 환경 상태는 시간 경과에 따라 지속적으로 변하므로 각 데이터 아이템은 유효 시간(a validity time)을 가짐

하드리얼타임시스템 설계 방법론

본 방법론은 런타임 아키텍쳐가 정적 스케쥴링을 기반으로 하고 있고 시간 도메인에서 시스템 액션을 조정하기 위한 글로벌하게 동기화된 시간 기준이 존재한다고 가정한다. 아래 그림과 같이 ‘설계 생성 스텝(design creation step)’과 ‘설계 검증 스텝(design verification step)’으로 크게 구분되며, 검증은 설계 생성 활동과 동시에 수행되는 ‘정적 검증(평가)’과 시스템이 (부분적으로라도) 완성되고 실행 가능할 것을 요구하는 ‘동적 검증(테스팅)’으로 구별된다. 그림에서 가로 점선은 대규모 프로그래밍(the programming-in-the-large) 활동들과 소규모 프로그래밍(the programming-in-the-small) 활동들을 구분한다.

[하드리얼타임 애플리케이션 설계 방법론]]

1) 설계 생성(Design creation)

• 요구사항 정의(Requirements definition): 기본적인 시스템 요구사항을 상세화한다. 전체적인 시스템 트랜잭션을 기술하고, 주변 장치(물리적 요소)와 해당 장치에 의해 소모되거나 생성되는 데이터를 데이터 아이템을 이용하여 기술한다.
• 시스템 설계와 클러스터 정의(System design and cluster definition): 시스템을 클러스터로 분해하고 시스템 트랜잭션을 서브트랜잭션으로 상세화한다. 상세화 결과로 나온 클러스터 트랜잭션을 해당 클러스터에 할당한다. 시스템은 대개 최소한 두 개의 클러스터로 구성되며(하나는 통제 받는 오브젝트를 다른 하나는 통제 하는 오브젝트를 나타냄), 종종 세 번째 클러스터인 오퍼레이터 클러스터가 도입된다. 밀접하게는 아니더라도 클러스터들이 서로 연결되어 있으므로 클러스터간 의존성(inter-cluster dependencies)을 반영하는 설계 오브젝트가 존재하며 이를 클러스터 경로(cluster paths)라 부른다.
• 클러스터 설계와 컴포넌트 정의(Cluster design and component definition): 통제하는 시스템(the controlling system)의 각 클러스터가 시스템의 나머지 부분과 독립적으로 설계된다. 각 클러스터는 다수의 컴포넌트로 분해되며, 동시에 클러스터 트랜잭션도 서브트랜잭션으로 상세화되어 해당 컴포넌트로 할당된다(즉, 컴포넌트 트랜잭션이 됨). 또한 외부 메시지(즉, 다른 컴포넌트들간에 교환되는 메시지)가 정의되고, 이 메시지들은 컴포넌트 트랜잭션에 의해 교환되는 데이터 아이템에 직접 매핑된다.
• 컴포넌트 설계와 태스크 정의(Component design and task definition): 컴포넌트의 내부 소프트웨어 구조가 상세화된다. 각 컴포넌트 트랜잭션이 오로지 내부 메시지를 통해서만 커뮤니케이션 하는 한 무리의 태스크로 구체화되며, 결과적인 커뮤니케이션 구조는 협업하는 태스크들간의 우선순위 관계(precedence relations)를 암묵적으로 결정한다. 이 정보는 MAXT_E(estimated maximum execution time: 추정된 최대 실행 시간) 및 관련된 태스크의 주기성(periodicity)과 더불어 적절한 오프라인 스케쥴(즉, 명세된 트랜잭션 데드라인의 준수가 보장됨) 결정의 전제조건이 된다. 만약 스케쥴러가 유효한 스케쥴 결정에 실패하면 소프트웨어가 재설계 되어야만 한다.
• 태스크 구현(Task implementation): ‘컴포넌트 설계와 태스크 정의’ 단계에서 도출된 개별 태스크들을 구현한다. 구현 시 MAXT_E 제약사항을 고려하여 데드라인을 준수하는 태스크를 생성 해 낸다.
• 최종 스케쥴링(Final scheduling): 모든 태스크가 구현되었다면 설계에서 나온 제약사항(constraints)들을 고려하여 태스크 집합(task set)에 대한 스케쥴링을 수행한다. 이 스케쥴링은 ‘컴포넌트 설계와 태스크 정의’ 단계 후에 수행된 타이밍 분석과 유사한 방식으로 수행되며, 유일한 차이점은 MAXT_E가 MAXT 분석에서 얻어진 MAXT_C(calculated maximum execution time: 계산된 최대 실행 시간)로 대체된다는 것이다.

2) 설계 평가(Design evaluation)

• 신뢰성 평가(Dependability evaluation): ‘시스템 설계와 클러스터 정의’ 단계부터 ‘태스크 구현’ 단계까지 동안 점진적으로 수행됨.
  - ‘시스템 설계와 클러스터 정의’ 단계에서 설계자는 추정된 신뢰성 속성(dependability attributes)을 각 클러스터 및 클러스터 트랜잭션에 매핑하고, 이렇게 명세된 신뢰성 요구사항(dependability requirements)이 충족될 수 있는지를 체크한다. 클러스터와 트랜잭션에 대한 신뢰성 데이터(Dependability data)는 관련 프로젝트로부터 추정해 내거나 표준(standards)에서 도출해 낸다.
  - 설계가 더 구체화되는 ‘클러스터 설계와 컴포넌트 정의’ 단계에서는 이전 단계에서 식별된 신뢰성 속성을 상세화하여 각 컴포넌트와 컴포넌트 트랜잭션에 매핑한다. 이 단계에서는 컴포넌트 수준의 시스템 구조가 확립되므로 더 구체적인 신뢰성 평가가 시작될 수 있다(예, 여러 아키텍쳐 옵션, 패러미터 옵션, 민감도 분석 등을 통해 시스템의 핵심 부분 및 병목 구간을 밝혀내고 개선 방법을 제안).
  - 사용되는 하드웨어, 논리 단위의 중복 정도, 태스크 집합 등이 명세되는 ‘컴포넌트 설계와 태스크 정의’ 단계에서는 하드웨어의 정확한(precise) 신뢰성 속성과 태스크의 추정된(estimated) 신뢰성 속성을 고려한다. 이 단계에서는 하드웨어가 이전 단계로부터 도출된 신뢰성 요구사항을 충족할 수 있는지 체크가 가능하다.
  - 특정 클러스터의 모든 태스크들에 대한 ‘태스크 구현’이 완료되면 해당 태스크들의 실패율을 더 정확하게 추정할 수 있다(‘클러스터 테스트’ 단계 동안 수행된 테스트 런의 실패 이력을 통하여 데이터가 확보됨)
• 타이밍 분석(Timing analysis): 태스크의 실행 시간(the execution time of tasks)과 태스크들의 인터액션에 필요한 시간(the time needed for their interaction)의 두 가지 타이밍 정보에 의존하여 태스크 인터액션과 순서(ordering) 측면을 연구함. 즉, 타이밍 동작을 결정하는 아래 이슈들을 스케쥴링에서 고려한다.
  - 태스크 의존성(Task dependencies): 태스크들의 동기화 요구사항(synchronisation requirements)은 선후 제약(precedence constraints)에 의해 기술됨. 태스크는 자신의 선행 작업들의(predecessors) 실행이 모두 완료되고 자신에게 보내진 메시지를 모두 받기 전에는 실행을 시작해서는 안 된다. 애플리케이션의 타이밍 제약(timing constraints)은 각 트랜잭션의 완료 시간에 대한 상한선(데드라인)인 MART(MAximum Response Time)를 명세하여 정의됨. 스케쥴러가 MART를 충족시킬 수 없는 경우 설계자에게 통보한다.
  - 최대실행시간(Maximum execution times): 트랜잭션의 MART를 결정하기 위해서는 관련된 태스크들의 실행 시간에 대한 정보가 필수적이다.
  - 시스템 패러미터(System parameters): 타이밍 제약, 커뮤니케이션 제약, 동기화 제약을 만족시키는 스케쥴 생성을 위해서는 ‘태스크 간 커뮤니케이션 프로토콜의 최대 실행 시간’과 ‘애플리케이션 태스크에 가용한 CPU 시간’에 대하여 알아야 한다. 이는 운영체제에 의해 야기되는 타임 오버헤드(예, 태스크 스위칭 시간, 주기적 클락 인터럽트, 네트워크 액세스 등을 위해 DMA에 의해 사용되는 CPU 사이클)가 한정되고 알려져 있어야만 함을 의미한다.
• MAXT 분석: 구현된 태스크의 최악 경우 타이밍 동작을 평가함. 즉, 태스크들의 최대 실행 시간 상한선을 계산하고(MAXT_C) 추정된 최대 실행 시간인 MAXT_E와 비교. 어떤 상황에서든 태스크가 MAXT_C를 넘어서면 전체 시스템의 타이밍 동작이 더 이상 보장되지 못함을 의미함
  - 코드 기반 MAXT_C 계산은 사용되는 하드웨어의 타이밍 속성, 주요 시스템 개념(예, 최대 인터럽트 빈도, 태스크 preemption 가능성 등), 사용되는 언어 구문의 시맨틱에 대한 상세한 정보를 요구한다.
  - 또한 태스크의 MAXT를 계산하기 위해서는 해당 태스크의 모든 부분(예, 시퀀스, 루프, 대안 경로 등)에 대한 MAXT가 반드시 계산 가능해야 한다. 

3) 테스팅

테스트 단계는 설계 단계와 연관되어 있다(즉, 각 설계 단계가 생성한 결과물을 상응하는 테스트 단계가 평가하도록 구성됨). 테스트 단계에 컴포넌트 테스트(component test)가 빠져 있는데, 그 이유는 컴포넌트는 정보 교환이 있을 수도 있고 없을 수도 있는(그리고 동일 트랜잭션에 속할 수도 있고 속하지 않을 수도 있는) 태스크 집합을 실행하므로 이런 임의의 태스크 집합(an 'arbitrary' set of tasks)을 테스트 하는 것보다 하나의 완전한 트랜잭션을 테스트 하는 편이 훨씬 더 유용하다고 판단했기 때문이다.

• 태스크 테스트(Task test): 이 테스트 전체가 호스트 시스템에서 수행되며 개별 태스크의 기능 테스팅(functional testing)에 중점을 둔다. 태스크가 볼 수 있는 유일한 시간 정보인 타임스탬프가 값 도메인(the value domain)으로 전환되므로 실시간 태스크의 테스팅이 비실시간 코드의 테스팅과 다르지 않다(즉, 타임스탬프도 값 도메인상의 추가적인 입력값으로 여겨짐). 태스크의 속성 중 실행 시간은 여기서 평가를 할 수가 없지만 MAXT 분석을 통해 다루어진다.
• 클러스터 테스트(Cluster test): 클러스터 테스트와 그 이후의 테스트들은 모두 타겟 시스템에서 수행됨. 개방 루프 클러스터 테스트(open-loop cluster test)와 폐쇄 루프 클러스터 테스트(closed-loop cluster test)의 두 가지 변형이 존재.
  - 개방 루프 모드에서는 테스트 데이터가 오프라인으로 생성되고, 입력 메시지 시퀀스는 사전 결정된 특정 시점에 테스트 대상 클러스터에게 보내지며, 그에 따른 클러스터의 반응이 관측되고 차후 평가를 위해 저장된다. 테스트 목표로는 기능 정확성 체크(시맨틱 통합 테스트), 태스크 및 컴포넌트 인터액션의 적시성 체크(예, 태스크 실행 시간, 트랜잭션 반응 시간), 예상되는 에러 상황(메시지 분실, 컴포넌트 분실)에서의 클러스터 동작 검증이 있다. 테스트 런을 실행하기 위해 구축되는 테스트 베드는 타겟 시스템과 동일하지만 환경과의 인터페이스가 테스트 드라이버 컴포넌트에 의해 대체된다는 점이 다르다.
  - 폐쇄 루프 모드에서는 테스트 대상 클러스터의 결과(반응)이 환경 모델로 주어지고, 환경 모델은 클러스터의 결과에 따른 환경의 반응을 동적으로 계산하며, 이것이 다시 테스트 대상 클러스터의 새로운 입력값으로 사용된다. 테스트 목표는 기본적으로 개방 루프 클러스터 테스트와 동일하지만 더 고차원적인 테스트에도 추가적인 중점을 둔다(예, 현실적인 입력 데이터로 수행되는 확장된 테스트 런, 클러스터가 실현하는 통제 알고리즘의 품질 평가, 최고 부하 시 성능 평가, 극한 상황이나 에러 상황에서의 견고성 평가). 폐쇄 루프 테스트의 실행은 애플리케이션에 종속적인 테스트 도구인 환경 시뮬레이션(environment simulation)의 개발을 요구하며, 따라서 테스트 베드에 놓인 애플리케이션 클러스터는 환경 시뮬레이션 소프트웨어를 실행하는 시뮬레이션 클러스터와 상호연결된다.
• 시스템 테스트(System test): 모든 클러스터에 대한 클러스터 테스트가 완료된 후에 시작 가능한 테스트. 테스트 목표는 폐쇄 루프 클러스터 테스트와 동일하지만 시스템 전체에 적용된다는 것이 차이점. 시스템 테스트는 대개 폐쇄 루프 모드에서 수행되며 테스트 베드 아키텍쳐도 폐쇄 루프 클러스터 테스트의 것과 유사하다.
• 필드 테스트(Field test): 이 최종 테스트 단계에서는 실제 환경에서 실제 주변장치들을 가지고 시스템을 테스트 한다. 고객 승인 테스트(customer acceptance test) 수행의 목적을 가짐