KR101789288B1 - 계층적 실시간 스케줄링 시스템의 정형 검증 장치 및 방법 - Google Patents

Abstract

스케줄러가 계층적으로 존재하는 실시간 시스템에 있어서, 정형 명세 생성부 및 정형 검증 수행부를 포함하는 정형 검증 방법 및 이를 이용한 정형 검증 장치가 개시된다. 정형 검증 장치는 상기 시스템의 요구 사항을 입력받는 입력부, 상기 요구 사항 수신하고, 타임드 오토마타(Timed Automata) 기반의 정형 기법을 이용하여 정형 명세를 생성하는 정형 명세 생성부, 및 상기 정형 명세를 모델 검사(Model Checking) 도구를 이용하여 검증을 수행하는 정형 검증 수행부를 포함하되, 상기 정형 명세 생성부는 상기 시스템의 최상위 스케줄러의 모델을 명세하는 최상위 스케줄러 모델 생성부, 상기 시스템의 적어도 하나 이상의 하위 스케줄러 모델을 명세하는 하위 스케줄러 모델 생성부, 및 상기 시스템의 적어도 하나 이상의 태스크를 명세하는 태스크 모델 생성부를 포함한다.

Description

계층적 실시간 스케줄링 시스템의 정형 검증 장치 및 방법{APPRATUS AND METHOD FOR PERFORMING FORMAL VERIFICATION FOR HIERARCHICAL SCHEDULING OF REAL-TIME SYSTEMS}

본 발명의 개념에 따른 실시 예는 스케줄러가 계층적으로 존재하는 실시간 시스템의 정형 검증 장치 및 방법에 관한 것으로, 특히 타임드 오토마타(Timed Automata)를 기반으로 제작된 프레임워크에 최상위 스케줄러, 하위 스케줄러 및 태스크의 요구사항을 입력하여 시스템 전체를 정형 명세할 수 있고, 모델 검사(Model Checking) 방식으로 시스템을 보다 직관적이고 보다 정확하게 정형 검증을 수행할 수 있는 정형 검증 장치 및 방법에 관한 것이다.

본 특허는 실시간 시스템에 가상화 기술이 적용되어 스케줄러가 계층적으로 존재할 때, 항상 스케줄링 가능한지 확인할 수 있도록 시스템을 쉽게 정형 명세할 수 있는 프레임워크 및 이를 이용한 시스템 정형 검증 기술을 제시하고 있다.

실시간 시스템은 실시간 태스크들이 운영되는 시스템으로, 실시간 태스크는 주기와 실행 시간을 가진다. 실시간 태스크가 주기 중 실행 시간만큼 스케줄을 받지 못하는 경우를 스케줄링 실패라고 하며, 이 경우 시스템 동작이 멈출 수 있다. 실시간 시스템 중에는 안전 필수 시스템, 임무 필수 시스템과 같이 시스템 동작에 문제가 발생할 경우 인명 피해, 재산 피해가 발생할 수 있다. 따라서 반드시 스케줄링이 항상 가능한지 확인할 필요가 있다. 항상 스케줄링이 가능하다는 것은 시스템 내 모든 실시간 태스크가 주어진 주기 마다 실행을 완료할 수 있다는 것을 의미한다.

특히 여러 스케줄러가 계층을 이루는 계층적 실시간 시스템은 태스크들의 요구사항을 기반으로 스케줄링이 항상 가능한지 직관적으로 판단하기 복잡하고, 문제 발생 시 무엇이 문제인지 확인하기 어렵다. 따라서, 계층적 실시간 시스템에 있어서 스케줄링 가능 여부 및 스케줄링이 가능하지 않은 경우 어떤 부분이 문제인지를 직관적으로 확인할 수 있는 정형 검증 방법 및 이를 이용한 장치가 필요하다.

Carnevali, L., Pinzuti, A., Vicario, E. "Compositional verification for hierarchical scheduling of real-time systems." IEEE Trans. Softw. Eng. 39(5), 638-657 (2013) R.B. Dodd, "Coloured Petri Net Modelling of a Generic Avionics Mission Computer," technical report, Australian Govt., Dept. of Defence, Defence Science and Technology Organisation, Apr. 2006. Anna Philippou, Insup Lee, and Oleg Sokolsky, "PADS: An Approach to Modeling Resource Demand and Supply for the Formal Analysis of Hierarchical Scheduling", Theoretical Computer Science 413(1), 2-20. January 2012. L. T. X. Phan, J. Lee, A. Easwaran, V. Ramaswamy, S. Chen, I. Lee, and O. Sokolsky, "CARTS: a tool for compositional analysis of real-time systems," SIGBED Rev., vol. 8, no. 1, pp. 62?63, Mar. 2011.

본 발명이 이루고자 하는 기술적인 과제는 계층적 스케줄링 시스템 전체를 명세할 수 있는 프레임워크 및 이를 이용하여 명세된 시스템 전체를 검증하고 시스템이 항상 스케줄링이 가능한지 여부를 판단할 수 있는 정형 검증 장치 및 방법을 제공하는 것이다.

또한, 본 발명이 이루고자 하는 기술적인 과제는 서로 같은 스케줄러에서 스케줄링 되거나, 서로 다른 스케줄러에서 스케줄링 되는 태스크들 간 공유자원과 의존성을 직관적으로 명세할 수 있는 프레임워크 및 이를 이용한 정형 검증 장치 및 방법을 제공하는 것이다.

본 발명의 실시 예에 따른 계층적 실시간 스케줄링 시스템의 정형 검증 장치는 상기 시스템의 요구 사항을 입력받는 입력부, 상기 요구 사항 수신하고, 타임드 오토마타(Timed Automata) 기반의 정형 기법을 이용하여 정형 명세를 생성하는 정형 명세 생성부, 및 상기 정형 명세를 모델 검사(Model Checking) 도구를 이용하여 검증을 수행하는 정형 검증 수행부를 포함하되, 상기 정형 명세 생성부는 상기 시스템의 최상위 스케줄러의 모델을 명세하는 최상위 스케줄러 모델 생성부, 상기 시스템의 적어도 하나 이상의 하위 스케줄러 모델을 명세하는 하위 스케줄러 모델 생성부, 및 상기 시스템의 적어도 하나 이상의 태스크를 명세하는 태스크 모델 생성부를 포함하고, 상기 하위 스케줄러는 다른 하위 스케줄러 또는 상기 최상위 스케줄러의 하위 계층의 스케줄러이다.

본 발명의 실시 예에 따른 정형적 스케줄링 분석 장치 및 방법은 프레임워크를 사용해 시간 요구사항 입력으로 시스템 전체를 정형 명세할 수 있고, 명세한 시스템이 스케줄링 실패 없이 시스템 구현이 가능한지 정형 검증하여 설계 단계에서 확인할 수 있다.

또한, 본 발명의 실시 예에 따른 정형적 스케줄링 분석 장치 및 방법은 정형 검증 결과 스케줄링 실패를 확인한 경우 어느 시점, 어떤 경로에서 태스크가 문제가 되는지 확인할 수 있다.

또한, 본 발명의 실시 예에 따른 정형 검증 장치 및 방법은 공유자원, 의존성으로 인한 우선순위 역전 문제가 발생하는지 확인할 수 있는 효과가 있다.

본 발명의 상세한 설명에서 인용되는 도면을 보다 충분히 이해하기 위하여 각 도면의 상세한 설명이 제공된다.
도 1은 본 발명의 일 실시예에 따른 계층적 실시간 스케줄링 시스템의 정형 검증 장치의 기능 블럭도이다.
도 2는 본 발명의 일 실시예에 따른 정형 검증 장치의 아키텍쳐를 설명하는 도면이다.
도 3은 본 발명의 일 실시예에 따른 계층적 실시간 스케줄링 시스템의 정형 검증 방법의 흐름도이다.
도 4는 본 발명의 일 실시예에 따른 최상위 스케줄러 모델을 수도 코드로 도시한 도면이다.
도 5는 본 발명의 일 실시예에 따른 최상위 스케줄러 모델을 타임드 오토마타 형식으로 도시한 도면이다.
도 6은 본 발명의 일 실시예에 따른 하위 스케줄러 모델을 수도 코드로 도시한 도면이다.
도 7은 본 발명의 일 실시예에 따른 하위 스케줄러 모델을 타임드 오토마타 형식으로 도시한 도면이다.
도 8은 본 발명의 일 실시예에 따른 태스크 모델을 수도 코드로 도시한 도면이다.
도 9는 본 발명의 일 실시예에 따른 태스크 모델을 타임드 오토마타 형식으로 도시한 도면이다.

본 명세서에 개시되어 있는 본 발명의 개념에 따른 실시 예들에 대해서 특정한 구조적 또는 기능적 설명은 단지 본 발명의 개념에 따른 실시 예들을 설명하기 위한 목적으로 예시된 것으로서, 본 발명의 개념에 따른 실시 예들은 다양한 형태들로 실시될 수 있으며 본 명세서에 설명된 실시 예들에 한정되지 않는다.

본 발명의 개념에 따른 실시 예들은 다양한 변경들을 가할 수 있고 여러 가지 형태들을 가질 수 있으므로 실시 예들을 도면에 예시하고 본 명세서에서 상세하게 설명하고자 한다. 그러나, 이는 본 발명의 개념에 따른 실시 예들을 특정한 개시 형태들에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물, 또는 대체물을 포함한다.

제1 또는 제2 등의 용어는 다양한 구성 요소들을 설명하는데 사용될 수 있지만, 상기 구성 요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성 요소를 다른 구성 요소로부터 구별하는 목적으로만, 예컨대 본 발명의 개념에 따른 권리 범위로부터 벗어나지 않은 채, 제1 구성 요소는 제2 구성 요소로 명명될 수 있고 유사하게 제2 구성 요소는 제1 구성 요소로도 명명될 수 있다.

본 명세서에서 사용한 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로서, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함하다" 또는 "가지다" 등의 용어는 본 명세서에 기재된 특징, 숫자, 단계, 동작, 구성 요소, 부분품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성 요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가진다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미를 갖는 것으로 해석되어야 하며, 본 명세서에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하, 본 명세서에 첨부된 도면들을 참조하여 본 발명의 실시 예들을 상세히 설명한다.

우선, 본 발명에서 이용하는 정형 기법(formal methods)들을 설명한다.

본 발명에서 사용되는 정형 기법은 수리 논리적 언어를 사용해 시스템을 명세하고 수학적으로 검증하는 방법으로, 안전 필수, 임무 필수, 보안 필수 시스템의 안전성(Safety), 신뢰성(Reliability), 보안성(Security) 확보 여부를 확인하는데 주로 사용하게 된다.

본 발명에서는 타임드 오토마타(Timed Automata)를 기반으로 제작된 프레임워크에 스케줄러와 태스크의 요구사항을 입력해 시스템을 명세하고, 정형 기법 중 하나인 모델 검사(Model Checking) 방식으로 검증한다. 모델 검사 방식으로 검증할 경우, 스케줄링 실패가 발생하면 어떤 태스크가 어느 시점에서 실행을 완료하지 못하는지 확인할 수 있어 요구사항의 문제점을 확인하기 유용하다.

또한, 본 발명에서는 본 발명의 일 실시예에서는 리얼타임 시스템의 검증을 위해서 Uppsala University 와 Aalborg University에서 공동으로 개발한 모델 체킹 도구인 UPPAAL을 이용한다. 많은 정형기법 도구들은 시간을 표현하기 위해서 이산적 시간을 사용하지만 UPPAAL은 연속적인 실시간을 표현하기 때문에 실시간 프로그램의 시간 요구사항을 명세하고 검증하기 적합하다. 이와는 달리, UPPAAL 외에도 프로세스 알제브라 기반의 정형 기법을 이용할 수도 있다.

UPPAAL은 시스템을 정형 명세하는데 있어 UPPAAL의 타임드 오토마타(timed automata)를 사용한다. 시작 로케이션(location) 1개와 일반 로케이션 여럿으로 상태를 나타내며, 상태 사이 이동은 엣지(edge)로 표현한다. 엣지를 통한 로케이션 사이 이동은 엣지의 가드(guard)의 불(boolean) 식이 참이고, 출발 로케이션, 도착 로케이션, 엣지의 시간 조건을 만족할 때 이루어질 수 있다. 동기화를 위해서는 채널(channel)을 이용한다.

상기 정형 명세를 검증하기 위하여 시스템이 만족해야 하는 요구사항을 명세하여야 하며, 본 발명에서는 검증 속성 명세를 위해 Temporal Logic을 이용한다. 구체적으로, 타임드 오토마타(timed automata)를 이용해 작성된 시스템을 모델 검사하기 위하여 TCTL(timed CTL)이용하여 속성을 명세한다. UPPAAL의 엔진은 자동으로 모든 실행 경로의 모든 상태를 탐색하면서, TCTL로 작성된 시스템에서 확인하고자 하는 속성을 만족하는지 확인한다. 만약 속성을 만족하지 못하는 경우, 만족하지 못한 경우(반례, counter example)를 보여줌으로써 모델이 어떠한 상황에서 명세된 속성을 만족하지 않는지를 확인할 수 있다.

이하, 도 1 내지 도 2를 참조하여, 본 발명의 일 실시예에 따라 의료데이터를 암호화하고 의료데이터 소유자가 데이터의 접근 권한을 제어할 수 있는 의료 데이터 관리 시스템에 대해 상술한다.

도 1은 본 발명의 일 실시예에 따른 정형 검증 장치(100)의 기능 블럭도이고, 도 2는 본 발명의 일 실시예에 따른 정형 검증 장치의 아키텍쳐를 설명하는 도면이다. 도 1을 참조하면, 정형 검증 장치(100)는 입력부(110), 정형명세 생성부(120), 정형검증 수행부(130), 저장부(180), 및 제어부(190)을 포함한다.

본 명세서에서 사용되는 '-부'라 함은 본 발명의 기술적 사상을 수행하기 위한 하드웨어 및 상기 하드웨어를 구동하기 위한 소프트웨어의 기능적, 구조적 결합을 의미할 수 있다. 예컨대, 상기 '-부'는 소정의 코드와 상기 소정의 코드가 수행되기 위한 하드웨어 리소스의 논리적인 단위를 의미할 수 있으며, 반드시 물리적으로 연결된 코드를 의미하거나 한 종류의 하드웨어를 의미하는 것은 아니다.

입력부(110)는 제어부(190)의 제어 하에, 계층적 스케줄링 시스템 요구사항 수신하여 정형명세 생성부(120)에 전달한다. 입력부(110)는 전체 시스템을 명세하기 위해 최상위 스케줄러(P), 하위 스케줄러(V), 태스크(T)의 요구사항을 입력받는다. 입력받는 정보는 아래와 같다.

P = (S, W)

V = (S, W, Pe, E, Pr)

T = (Pe, E, D, O, Pr, R, Dep)

최상위 스케줄러(P)는 스케줄링 정책(S)과 워크로드(W) 정보를 입력받는다. 최상위 스케줄러의 개수는 1개이며, 워크로드(W)는 가상 스케줄러(V)와 태스크(T)의 부분집합이다. 스케줄링 정책(S)은 모듈화되어 있어 쉽게 설정이 가능하며, 본 발명의 일 실시예에 따른 프레임워크에 입력하는 스케줄링 정책(S)은 RM(Rate Monotonic), EDF(Earliest Deadline First) 또는 선점형 FP(preemptive Fixed Priority) 중 어느 하나일 수 있다. 그 밖에도 사용자가 다른 스케줄링 정책을 별도로 정의하여 사용할 수도 있다.

하위 스케줄러(V)는 최상위 스케줄러(P)의 관점에서는 태스크(T)와 같은 성격을 지니고, 태스크(T) 관점에서는 최상위 스케줄러(P)의 성격을 가지기 때문에, 최상위 스케줄러(P)의 정보와 태스크(T)의 정보를 모두 입력받는다. 따라서 입력되는 요구사항 정보는 스케줄링 정책(S)과 워크로드(W) 뿐 아니라 주기(Pe), 주기 중 필요한 실행 시간(E), 우선순위(Pr)를 포함한다. 하위 스케줄러(V)의 개수는 하나 이상일 수 있다.

태스크(T)는 주기(Pe), 주기 중 필요한 실행 시간(E), 데드라인(D), 시작 오프셋(O), 우선순위(Pr), 공유자원(R), 의존성(Dep) 정보를 입력받는다. 이때, 공유자원(R) 및 의존성(Dep) 정보가 존재하지 않는 경우, 생략 가능하다.

워크로드(W)에 속한 실시간 태스크(T)가 자원을 요구하면, 해당 스케줄러의 큐에 태스크(T)가 삽입되며, 스케줄러는 자신의 스케줄링 정책에 따라 자신의 큐를 정렬한다. 최상위 스케줄러(P)와 하위 스케줄러(V)의 워크로드(W)에는 자신 이외의 하위 스케줄러(V) 및 태스크(T)들이 속할 수 있다. 이를 통해 적어도 2 레벨 이상의 계층적 스케줄링 시스템을 명세할 수 있다.

즉, 입력되는 요구 사항은 최상위 스케줄러의 스케줄링 정책과 최상위 스케줄러의 워크로드 정보를 포함하는 최상위 스케줄러 요구 사항. 하위 스케줄러의 스케줄링 정책과 하위 스케줄러의 워크로드 정보를 포함하는 스케줄러로서의 역할과 관련된 제1 하위 스케줄러 요구 사항, 하위 스케줄러의 주기, 하위 스케줄러의 주기 중 필요한 실행 시간, 하위 스케줄러의 우선순위, 하위 스케줄러의 공유자원, 및 하위 스케줄러의 의존성을 포함하는 태스크로서의 역할과 관련된 제2 하위 스케줄러 요구 사항, 그리고 태스크의 주기, 태스크의 데드라인, 태스크의 시작 오프셋 및 태스크의 우선순위를 포함하는 태스크 요구 사항을 포함한다.

표 1은 실시간 시스템 요구사항을 입력한 예시적인 표이다. 구체적으로, 시간적 속성이 중요한 항공기의 실시간 소프트웨어 요구사항을 나타낸 표이며, 총 5개의 하위 스케줄러(V) 및 총 15개의 태스크(T)를 포함한다.

P = ( RM, V1, V2, V3, V4, V5)
V1=	(EDF,T1,T2,T3,T4,10, 3, 0)	3.8 Weapon release	T1	=(10,1,5,0,0)
		3.3 Radar tracking	T2	=(40,2,40,1,0)
		3.5 Target tracking	T3	=(40,4,40,12,0)
		3.5 Target sweetening	T4	=(40,2,40,20,0)
V2=	(EDF,T5,T6,T7,T8,10,4,0)	3.1 3.14 HOTAS bomb button	T5	=(40,1,40,0,0)
		3.11 MPD tactical dispaly	T6	=(50,7,50,1,0)
		3.9 HUD display	T7	=(50,5,50,2,0)
		3.1 Aircraft flight data	T8	=(50,7,50,16,0)
V3=	(EDF,T9,T10, 10,1,0)	3.2 Steering	T9	=(80,5,80,2,0)
		3.16 Thereat response display	T10	=(100,1,100,15,0)
V4=	(EDF,T11,T12,10,1,0)	3.7 Weapon trajectory	T11	=(100,6,100,3,0)
		3.6 AUTO/CCIP toggle	T12	=(200,1,200,10,0)
V5=	(EDF,T13,T14,T15, 10,1,0)	3.16 Poll RWR	T13	=(200,2,200,10,0)
		3.7 Reinitiate trajectory	T14	=(400,5,400,3,0)
		3.17 Periodic BIT	T15	=(1000,4,1000,2,0)

상기 표 1의 정보를 본 발명에 따른 프레임워크에 입력하면 정형 명세 생성부(120)는 자동으로 최상위 스케줄러 모델, 하위 스케줄러 모델, 및 태스크 모델이 생성하여 전체 시스템 명세를 생성하고, 나아가 정형 검증 수행부(130)는 전체 시스템을 검증할 수 있다.

정형 명세 생성부(120)는 최상위 모델 생성부(121), 하위 모델 생성부(123), 및 태스크 모델 생성부(125)를 포함한다.

최상위 모델 생성부(121)는 제어부(190)의 제어 하에, 상기 요구사항을 바탕으로 최상위 스케줄러 모델을 생성한다. 최상위 스케줄러 모델은 하위 스케줄러 또는 태스크로부터 요청이 들어오면 스케줄링하여 자원을 제공한다.

하위 모델 생성부(123)는 제어부(190)의 제어 하에, 상기 요구사항을 바탕으로 하위 스케줄러(가상 스케줄러) 모델을 생성한다. 하위 스케줄러는 다른 하위 스케줄러 또는 최상위 스케줄러의 하위 레벨일 수 있으며, 다른 하위 스케줄러 또는 태스크의 상위 레벨일 수 있다. 즉, 자원 요청을 수신하여 자원을 제공하는 역할 및 자원을 요청하고 자원을 받아 실행하는 역할을 모두 수행한다.

태스크 모델 생성부(125)는 제어부(190)의 제어 하에, 상기 요구사항을 바탕으로 태스크 모델을 생성한다. 태스크는 시작 오프셋 시간 이후부터 첫 주기를 시작하며, 그 이후부터는 한 주기 종료 시 바로 다음 주기를 시작한다. 매 주기 시작마다 의존성이 있는 태스크 상태와 공유자원 상태를 확인하여, 의존 태스크가 실행을 완료했고, 공유자원이 사용 가능하다면 스케줄러에 스케줄을 요청한다.

정형 검증 수행부(130)는 제어부(190)의 제어 하에 모델 체킹 기법을 이용하여 정형 명세 생성부(120)에 의하여 명세한 시스템을 검증한다. 검증을 위해서 정형 명세 언어 TCTL(Timed Computational Temporal Logic)로 스케줄링 실패가 없었는지 확인한다.

본 발명의 일 실시예에 따른 정형 검증 장치는 실시간 계층적 시스템의 요구사항을 입력으로 받아 항상 스케줄링이 가능한지 결과를 출력하는 장치로서, 입력 받은 요구사항에 따라 장치 내부에서 시스템 동작을 명세하고, 모델 검사 방식으로 스케줄링이 항상 가능한지, 가능하지 않다면 어떤 태스크가 어느 시점에서 실행을 완료하지 못하는지 알려준다. 즉, 사용자가 요구 사항만 입력하면 본 발명에 따른 프레임워크를 이용하여 자동으로 정형 명세 및 검증이 가능하다.

본 발명의 일 실시예에 따른 정형 검증 장치가 이용하는 프레임워크에 있어서, 프레임워크의 입출력 및 프레임워크 내 각 모델의 관계는 도 2와 같다. 즉, 장치 내부에서 시스템 동작은 최상위 스케줄러 모델, 하위 스케줄러 모델, 및 태스크를 입력 정보에 맞춰 설정하는 것으로 명세할 수 있고, 스케줄링 가능성은 명세된 전체 시스템을 모델 검사하여 확인할 수 있다.

이하, 도 3 내지 도 9를 참조하여, 본 발명의 일 실시예에 따른 정형적 스케쥴링 분석 장치를 이용한 정형적 스케쥴링 분석 방법에 대하여 자세히 살펴보도록 한다.

도 3은 도 1에 도시한 정형적 스케쥴링 분석 장치를 이용한 정형적 스케줄링 분석 방법을 설명하기 위한 흐름도이다. 앞서 설명한 내용과 중복되는 설명은 생략하기로 한다.

먼저, 정형적 스케쥴링 분석 장치는 계층적 스케줄링 시스템의 요구사항을 수신한다(S100). 구체적으로 정형적 스케쥴링 분석 장치는 전체 시스템을 명세하기 위해 최상위 스케줄러(P), 하위 스케줄러(V), 태스크(T)의 요구사항을 입력받는다. 최상위 스케줄러(P)는 스케줄링 정책(S)과 워크로드(W) 정보를 수신하고, 하위 스케줄러(V)는 스케줄링 정책(S)과 워크로드(W) 뿐 아니라 주기(Pe), 주기 중 필요한 실행 시간(E), 우선순위(Pr) 정보를 수신한다. 또한, 태스크(T)는 주기(Pe), 주기 중 필요한 실행 시간(E), 데드라인(D), 시작 오프셋(O), 우선순위(Pr), 공유자원(R), 의존성(Dep) 정보를 수신한다. 이때, 공유자원(R) 및 의존성(Dep) 정보가 존재하지 않는 경우, 생략 가능하다.

다음, 정형적 스케쥴링 분석 장치는 입력된 요구 사항을 바탕으로 정형 명세를 생성한다(S200).

정형 명세를 생성하는 단계(S200)는 크게 최상위 스케줄러 모델 생성 단계(S210), 하위 스케줄러 모델 생성 단계(S230), 및 태스크 모델 생성 단계(S250)로 구분되며, 각 단계는 병렬적으로 수행될 수 있다. 즉, 프레임워크에 입력된 시스템 요구 사항 정보에 맞는 최상위 스케줄러 모델, 하위 스케줄러 모델, 태스크 모델이 자동으로 생성된다(S200).

구체적으로, 정형적 스케쥴링 분석 장치는 입력된 요구 사항을 바탕으로 최상위 스케줄러 모델을 생성한다(S210). 도 4는 본 발명의 일 실시예에 따른 최상위 스케줄러의 동작을 명세한 모델의 수도코드이다. 도 4를 참고하면, 최상위 스케줄러는 스케줄링 요청하는 새로운 워크로드 원소가 있을 때마다, 스케줄링을 요청했으나 아직 실행 완료하지 못한 워크로드 원소들 중에서 자신의 스케줄링 정책에 따라 가장 우선 스케줄 되어야 할 원소를 선택해 물리 자원을 할당한다. 또한 현재 자원이 할당된 워크로드 원소의 실행이 완료할 경우에도 스케줄링 대기 중인 원소가 존재하면 스케줄링 정책에 따라 원소를 선택해 물리 자원을 할당한다.

도 5는 본 발명의 일 실시예에 따른 최상위 스케줄러 모델을 타임드 오토마타 형식으로 도시한 도면이다. 표 2는 도 5의 이해를 돕기 위하여 UPPAL 모델의 언어를 나타낸 표이다.

UPPAL 언어		내용
시간 변수	pTime	주기 시간을 측정하기 위한 시간 변수
	eTime	실행 시간을 측정하기 위한 시간 변수
스케줄링 확인 변수	err	어떤 태스크든 데드라인 까지 실행을 완료하지 못해 error 상태가 되면 true가 됨
채널(channel)	?	수신
	!	송신
	in[id]	id의 스케줄러로 스케줄링 요청
	do_scheduling[id]	새 요청을 포함한 스케줄링을 위해 실행 중 워크로드 원소의 실행을 멈춤
	sch[policy]	policy의 스케줄링 알고리즘에 따라 스케줄 요청한 워크로드 원소들을 정렬하도록 요청
	sch_fin[policy]	policy에 따른 정렬 완료
	serv[id]	id에 자원 할당
	finish[id]	id의 실행 완료
조건(guard)	empty()	현재 자원을 요청 중인 워크로드 원소가 없으면 true, 있으면 false
	running[id]	현재 실제 물리자원을 할당 받은 상태면 true, 못 받은 상태면 false
	CS_check()	공유자원을 사용할 수 있는 상태면 true, 사용 못하는 상태면 false
	dependency()	의존하는 태스크들의 실행이 모두 완료된 상태면 true, 아니면 false

또한, 정형적 스케쥴링 분석 장치는 입력된 요구 사항을 바탕으로 하위 스케줄러 모델을 생성한다(S230). 도 6은 하위 스케줄러의 동작을 명세한 모델의 수도코드이고, 도 7은 본 발명의 일 실시예에 따른 하위 스케줄러 모델을 타임드 오토마타 형식으로 도시한 도면이다.

도 6 내지 도 7을 참고하면, 하위 스케줄러는 자신의 주기 중 실행시간이 남아있고, 아이들(idle) 상태일 때 새로운 스케줄 요청이 들어오면 자신의 상위 스케줄러에 자원을 요청한다. 자신의 상위 스케줄러로부터 자원을 할당받으면 최상위 스케줄러와 같은 방식으로 스케줄을 요청한 원소(태스크 또는 하위 스케줄러의 하위 스케줄러)를 스케줄링한다. 주기 중 실행시간을 다 소모하면 스케줄 요청 중인 원소가 존재해도 아이들(idle) 상태에서 주기가 종료할 때까지 기다린다. 만약 실행시간을 모두 소모하기 전에 주기가 종료하면, 주기 중 실행시간을 모두 소모하지 않더라도 더 이상 스케줄링을 요청하는 워크로드 원소가 없으면 아이들(idle) 상태에서 기다리며, 할당받은 자원을 반납한다. 하위 스케줄러의 실행시간은 태스크와 달리 하위 스케줄러가 실제 물리 자원을 사용할 수 있는 최대 시간을 의미하는 것으로, 실행시간을 모두 소모하지 않고 주기가 종료했어도 스케줄링 실패가 아니다.

종래의 COMPOSITIONAL approach 기법 - 예를 들어, CARTS(Compositional Analysis od Real-Time Systems) - 의 경우, 사실상 스케줄링이 가능한 경우(예를 들어, 하위 스케줄러가 실행시간을 모두 소모하지 않고 주기가 종료된 경우), 스케줄링이 불가능하다는 결론을 내릴 수 있다. 반면, 본 발명에 따른 정형적 스케줄링 분석 방법의 경우, 하위 스케줄러가 실행시간을 모두 소모하지 않고 주기가 종료한 경우에도 상기 하위 스케줄러에 스케줄링을 요청하는 워크로드 원소가 존재하지 않는다면 스케줄링 가능한 것으로 판단하며, 따라서 스케줄링 가능 여부에 대한 판단의 정확성을 높일 수 있다.

또한, 정형적 스케쥴링 분석 장치는 입력된 요구 사항을 바탕으로 태스크 모델을 생성한다(S250). 도 8은 태스크의 동작을 명세한 모델의 수도코드이고, 도 9는 본 발명의 일 실시예에 따른 태스크 모델을 타임드 오토마타 형식으로 도시한 도면이다.

도 8 내지 도 9를 참고하면, 태스크는 시작 오프셋 시간 이후부터 첫 주기를 시작하며, 그 이후부터는 한 주기 종료 시 바로 다음 주기를 시작한다. 매 주기 시작마다 의존성이 있는 태스크 상태와 공유자원 상태를 확인해, 의존 태스크가 실행을 완료했고, 공유자원이 사용 가능하다면 스케줄러에 스케줄을 요청한다. 스케줄러로부터 할당받을 때 의존 태스크와 공유자원 상태를 한 번 더 확인해, 스케줄을 기다리는 동안 상태 변화가 있었는지 확인한다. 만약 의존 태스크나 공유자원 둘 중 하나라도 상태가 변화하면 자원 사용을 양보(yield)한다. 본 발명의 일 실시예에 따라 태스크 모델을 생성함으로써 공유자원 또는 의존성으로 인한 우선순위 역전 문제 발생 여부를 직관적으로 확인 가능하다. 태스크는 반드시 주기 중 실행시간만큼 할당받아야 실행 완료 상태가 되며, 주기 중 실행을 완료하지 못하면, 스케줄링에 실패하게 된다.

다음, 생성된 정형 명세를 이용하여, 모델 검사 방식으로 정형 검증을 수행한다(S300). 검증을 위해서 정형 명세 언어 TCTL(Timed TCL)로 스케줄링 실패가 없었는지 확인한다. 스케줄링 실패 여부를 확인하기 위한 검증 속성 명세는 아래와 같다.

A[] not err

따라서, 명세한 시스템이 스케줄링 실패 없이 시스템 구현이 가능한지 정형 검증하여 설계 단계에서 확인할 수 있으며, 정형 검증 결과 스케줄링 실패를 확인한 경우 어느 시점 및 어떤 경로에서 태스크가 문제가 되는지 확인할 수 있다.

상술한 스케줄러가 계층적으로 존재하는 실시간 시스템을 정형 검증하는 방법은 컴퓨터에서 실행될 수 있는 프로그램으로 작성가능하고, 컴퓨터로 읽을 수 있는 기록매체를 이용하여 상기 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다. 구체적으로, 계층적 실시간 스케줄링 시스템의 정형 검증 프로그램은 정형 검증 대상인 상기 시스템의 요구 사항을 수신하고, 타임드 오토마타(Timed Automata) 기반의 정형 기법을 이용하여 정형 명세를 생성하는 정형 명세 명령어 세트, 상기 정형 명세를 모델 검사(Model Checking) 도구를 이용하여 검증을 수행하는 정형 검증 명령어 세트를 포함한다.

이때, 상기 정형 명세 명령어 세트는 상기 시스템의 최상위 스케줄러의 모델을 명세하는 최상위 스케줄러 모델 생성 명령어 세트, 상기 시스템의 적어도 하나 이상의 하위 스케줄러 모델을 명세하는 하위 스케줄러 모델 생성 명령어 세트, 및 상기 시스템의 적어도 하나 이상의 태스크를 명세하는 태스크 모델 생성 명령어 세트를 포함한다. 이때, 상기 하위 스케줄러는 다른 하위 스케줄러 또는 상기 최상위 스케줄러의 하위 계층의 스케줄러일 수 있다.

상기 정형 검증 프로그램은 상기 기록매체에 저장되며, 상기 기록매체는 마그네틱 저장매체(예를 들면, 롬, 플로피 디스크, 하드디스크 등), 광학적 판독 매체(예를 들면, 시디롬, 디브이디 등)와 같은 저장매체를 포함한다. 또한, 상기 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어 분산방식으로 컴퓨터가 읽을 수 있는 명령어 세트가 저장되고 실행될 수 있다.

본 발명에서 개시된 블록도들은 본 발명의 원리들을 구현하기 위한 회로를 개념적으로 표현한 형태라고 당업자에게 해석될 수 있을 것이다. 유사하게, 임의의 흐름 차트, 흐름도, 상태 전이도, 의사코드 등은 컴퓨터 판독가능 매체에서 실질적으로 표현되어, 컴퓨터 또는 프로세서가 명시적으로 도시되든지 아니든지 간에 이러한 컴퓨터 또는 프로세서에 의해 실행될 수 있는 다양한 프로세스를 나타낸다는 것이 당업자에게 인식될 것이다.

본 발명은 도면에 도시된 실시 예를 참고로 설명되었으나 이는 예시적인 것에 불과하며, 본 기술 분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시 예가 가능하다는 점을 이해할 것이다. 따라서, 본 발명의 진정한 기술적 보호 범위는 첨부된 등록청구범위의 기술적 사상에 의해 정해져야 할 것이다.

100 : 정형 검증 장치
110 : 입력부 120 : 정형명세 생성부
130 : 정형검증 수행부 180 : 저장부
190 : 제어부

Claims (9)

1. 스케줄러가 계층적으로 존재하는 실시간 시스템에 있어서,
   상기 시스템의 요구 사항을 입력받는 입력부;
   상기 요구 사항 수신하고, 타임드 오토마타(Timed Automata) 기반의 정형 기법을 이용하여 상기 시스템에서 문제가 되는 부분을 직관적으로 확인할 수 있는 정형 명세를 생성하는 정형 명세 생성부; 및
   상기 정형 명세를 모델 검사(Model Checking) 도구를 이용하여 검증을 수행하는 정형 검증 수행부;를 포함하되,
   상기 정형 명세 생성부는 상기 시스템의 최상위 스케줄러의 모델을 명세하는 최상위 스케줄러 모델 생성부, 상기 시스템의 적어도 하나 이상의 하위 스케줄러 모델을 명세하는 하위 스케줄러 모델 생성부, 및 상기 시스템의 적어도 하나 이상의 태스크를 명세하는 태스크 모델 생성부를 포함하고,
   상기 요구 사항은
   상기 최상위 스케줄러의 스케줄링 정책과 상기 최상위 스케줄러의 워크로드 정보를 포함하는 최상위 스케줄러 요구 사항,
   상기 하위 스케줄러의 스케줄링 정책과 상기 하위 스케줄러의 워크로드 정보를 포함하는 제1 하위 스케줄러 요구 사항,
   상기 하위 스케줄러의 주기, 상기 하위 스케줄러의 주기 중 필요한 실행 시간, 및 상기 하위 스케줄러의 우선순위를 포함하는 제2 하위 스케줄러 요구 사항, 및
   상기 태스크의 주기, 상기 태스크의 데드라인, 상기 태스크의 시작 오프셋, 상기 태스크의 우선순위, 및 의존성 정보를 포함하는 태스크 요구 사항을 포함하며,
   상기 하위 스케줄러는 다른 하위 스케줄러 또는 상기 최상위 스케줄러의 하위 계층의 스케줄러이며,
   상기 하위 스케줄러가 실행 시간을 모두 소모하지 않고 주기가 종료한 경우에도 상기 하위 스케줄러에 스케줄링을 요청하는 워크로드가 존재하지 않는다면 스케줄링 가능한 것으로 판단하고,
   상기 의존성 정보는 상기 태스크가 의존하는 의존 태스크를 나타내며,
   상기 의존 태스크의 실행이 완료되지 않은 경우 상기 태스크에 대한 스케줄링은 요청되지 않는,
   정형 검증 장치.
   
2. 삭제
3. 제1항에 있어서,
   상기 모델 검사(Model Checking) 도구는 UPPAAL인 것을 특징으로 하는,
   정형 검증 장치.
   
4. 제1항에 있어서,
   상기 정형 검증 수행부는 TCTL(timed CTL)을 이용하여 모델 검사를 수행하기 위한 검증 속성을 명세하는 것을 특징으로 하는,
   정형 검증 장치.
   
5. 입력부, 정형 명세 생성부, 및 정형 검증 수행부를 포함하는 정형 검증 장치를 이용하여 스케줄러가 계층적으로 존재하는 실시간 시스템의 정형 검증을 수행하는 방법에 있어서,
   상기 입력부가 상기 시스템의 요구 사항을 입력받는 요구 사항 입력 단계;
   상기 정형 명세 생성부가 상기 요구 사항 수신하고, 타임드 오토마타(Timed Automata) 기반의 정형 기법을 이용하여 상기 시스템에서 문제가 되는 부분을 직관적으로 확인할 수 있는 정형 명세를 생성하는 정형 명세 생성 단계; 및
   상기 정형 검증 수행부가 상기 정형 명세를 모델 검사(Model Checking) 도구를 이용하여 검증을 수행하는 정형 검증 수행 단계;를 포함하되,
   상기 정형 명세 생성 단계는 상기 시스템의 최상위 스케줄러의 모델을 명세하는 최상위 스케줄러 모델 생성 과정, 상기 시스템의 적어도 하나 이상의 하위 스케줄러 모델을 명세하는 하위 스케줄러 모델 생성 과정, 및 상기 시스템의 적어도 하나 이상의 태스크를 명세하는 태스크 모델 생성 과정을 포함하고,
   상기 요구 사항은
   상기 최상위 스케줄러의 스케줄링 정책과 상기 최상위 스케줄러의 워크로드 정보를 포함하는 최상위 스케줄러 요구 사항,
   상기 하위 스케줄러의 스케줄링 정책과 상기 하위 스케줄러의 워크로드 정보를 포함하는 제1 하위 스케줄러 요구 사항,
   상기 하위 스케줄러의 주기, 상기 하위 스케줄러의 주기 중 필요한 실행 시간, 및 상기 하위 스케줄러의 우선순위를 포함하는 제2 하위 스케줄러 요구 사항, 및
   상기 태스크의 주기, 상기 태스크의 데드라인, 상기 태스크의 시작 오프셋, 상기 태스크의 우선순위, 및 의존성 정보를 포함하는 태스크 요구 사항을 포함하며,
   상기 하위 스케줄러는 다른 하위 스케줄러 또는 상기 최상위 스케줄러의 하위 계층의 스케줄러이며,
   상기 하위 스케줄러가 실행 시간을 모두 소모하지 않고 주기가 종료한 경우에도 상기 하위 스케줄러에 스케줄링을 요청하는 워크로드가 존재하지 않는다면 스케줄링 가능한 것으로 판단하고,
   상기 의존성 정보는 상기 태스크가 의존하는 의존 태스크를 나타내며,
   상기 의존 태스크의 실행이 완료되지 않은 경우 상기 태스크에 대한 스케줄링은 요청되지 않는,
   정형 검증 방법.
   
6. 삭제
7. 제5항에 있어서,
   상기 모델 검사(Model Checking) 도구는 UPPAAL인 것을 특징으로 하는,
   정형 검증 방법.
   
8. 제5항에 있어서,
   상기 정형 검증 수행 단계는 TCTL(timed CTL)을 이용하여 모델 검사를 수행하기 위한 검증 속성을 명세하는 단계를 더 포함하는 것을 특징으로 하는,
   정형 검증 방법.
   
9. 기록매체에 저장되는 계층적 실시간 스케줄링 시스템의 정형 검증 프로그램으로서, 상기 프로그램은 컴퓨팅 시스템에서 실행되는
   정형 검증 대상인 상기 계층적 실시간 스케줄링 시스템의 요구 사항을 수신하고, 타임드 오토마타(Timed Automata) 기반의 정형 기법을 이용하여 상기 시스템에서 문제가 되는 부분을 직관적으로 확인할 수 있는 정형 명세를 생성하는 정형 명세 명령어 세트, 및
   상기 정형 명세를 모델 검사(Model Checking) 도구를 이용하여 검증을 수행하는 정형 검증 명령어 세트를 포함하되,
   상기 정형 명세 명령어 세트는,
   상기 계층적 실시간 스케줄링 시스템의 최상위 스케줄러의 모델을 명세하는 최상위 스케줄러 모델 생성 명령어 세트,
   상기 계층적 실시간 스케줄링 시스템의 적어도 하나 이상의 하위 스케줄러 모델을 명세하는 하위 스케줄러 모델 생성 명령어 세트, 및
   상기 계층적 실시간 스케줄링 시스템의 적어도 하나 이상의 태스크를 명세하는 태스크 모델 생성 명령어 세트를 포함하고,
   상기 요구 사항은
   상기 최상위 스케줄러의 스케줄링 정책과 상기 최상위 스케줄러의 워크로드 정보를 포함하는 최상위 스케줄러 요구 사항,
   상기 하위 스케줄러의 스케줄링 정책과 상기 하위 스케줄러의 워크로드 정보를 포함하는 제1 하위 스케줄러 요구 사항,
   상기 하위 스케줄러의 주기, 상기 하위 스케줄러의 주기 중 필요한 실행 시간, 및 상기 하위 스케줄러의 우선순위를 포함하는 제2 하위 스케줄러 요구 사항, 및
   상기 태스크의 주기, 상기 태스크의 데드라인, 상기 태스크의 시작 오프셋, 상기 태스크의 우선순위, 및 의존성 정보를 포함하는 태스크 요구 사항을 포함하며,
   상기 하위 스케줄러는 다른 하위 스케줄러 또는 상기 최상위 스케줄러의 하위 계층의 스케줄러이며,
   상기 하위 스케줄러가 실행 시간을 모두 소모하지 않고 주기가 종료한 경우에도 상기 하위 스케줄러에 스케줄링을 요청하는 워크로드가 존재하지 않는다면 스케줄링 가능한 것으로 판단하고,
   상기 의존성 정보는 상기 태스크가 의존하는 의존 태스크를 나타내며,
   상기 의존 태스크의 실행이 완료되지 않은 경우 상기 태스크에 대한 스케줄링은 요청되지 않는,
   계층적 실시간 스케줄링 시스템의 정형 검증 프로그램.

Images