KR102348691B1 - 응용 프로그램의 실행 가능성 확인 방법 및 장치, 그리고 이를 구현하기 위한 프로그램이 기록된 기록매체 - Google Patents

응용 프로그램의 실행 가능성 확인 방법 및 장치, 그리고 이를 구현하기 위한 프로그램이 기록된 기록매체 Download PDF

Info

Publication number
KR102348691B1
KR102348691B1 KR1020200100016A KR20200100016A KR102348691B1 KR 102348691 B1 KR102348691 B1 KR 102348691B1 KR 1020200100016 A KR1020200100016 A KR 1020200100016A KR 20200100016 A KR20200100016 A KR 20200100016A KR 102348691 B1 KR102348691 B1 KR 102348691B1
Authority
KR
South Korea
Prior art keywords
application
application program
model
execution
feasibility
Prior art date
Application number
KR1020200100016A
Other languages
English (en)
Other versions
KR20210112989A (ko
Inventor
최윤자
김동우
Original Assignee
경북대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 경북대학교 산학협력단 filed Critical 경북대학교 산학협력단
Publication of KR20210112989A publication Critical patent/KR20210112989A/ko
Application granted granted Critical
Publication of KR102348691B1 publication Critical patent/KR102348691B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3636—Software debugging by tracing the execution of the program
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

응용 프로그램의 실행 가능성 확인 방법 및 장치, 그리고 이를 구현하기 위한 프로그램이 기록된 기록매체가 제공된다. 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 방법은, 응용 프로그램의 어플리케이션 모델 및 운영체제 모델을 통합하여 실행 시나리오 모델을 생성하는 단계; 상기 실행 시나리오 모델에서 태스크 실행 순서 및 문장 블록을 도출하는 단계; 상기 응용 프로그램의 실행에 따른 문맥 전환 위치를 주석첨가(annotate)하는 단계; 상기 태스크 실행 순서 및 문장 블록과, 상기 문맥 전환 위치를 기초로 상기 응용 프로그램의 실행 가능한 경로를 검증하는 단계; 및 상기 응용 프로그램의 실행 가능성을 확인하여 보고하는 단계를 포함한다.

Description

응용 프로그램의 실행 가능성 확인 방법 및 장치, 그리고 이를 구현하기 위한 프로그램이 기록된 기록매체{METHOD AND APPARATUS FOR CHECKING EXECUTABILITY OF APPLICATION PROGRAM, AND RECORDING MEDIA RECORDED PROGRAM REALIZING THE SAME}
본 발명은 응용 프로그램의 실행 가능성 확인 방법 및 장치, 그리고 이를 구현하기 위한 프로그램이 기록된 기록매체에 관한 것이다.
내장형 프로그램은 복수의 태스크가 번갈아 실행되며, 각 태스크의 실행 순서를 정확하게 파악하기 위해서는 운영 체제의 스케줄링 정보뿐만 아니라, 운영 체제의 구성요소인 리소스(resource), 이벤트(envet), 인터럽트(interrupt) 등의 행위를 모두 반영한 검증된 운영체제 모델이 있어야 한다.
운영체제 모델과 함께 프로그램으로부터 추출한 제어 로직 모델을 이용하여 검증, 시뮬레이션 등의 프로그램 분석 작업을 수행할 경우, 분석 결과로써 실행 시나리오를 보고한다. 이는 제어 로직만 고려한 결과이므로 실제 프로그램의 실행 가능성을 확인해야 한다.
그러나, 실제 실행 환경을 구성하기 위해서는 기기와 운영체제 코드가 준비되어 있어야 하며, 프로그램에 시나리오 확인을 위한 모니터링 코드를 추가하여 기기에 설치하고 실행하며, 눈으로 실행 결과를 확인하는 작업을 모두 거쳐야 하기 때문에 많은 수작업을 요구한다.
대한민국 등록특허 10-1548364호 (2015. 08. 24. 등록) 대한민국 공개특허 10-2018-0066437호 (2018.06.19. 공개) 대한민국 등록특허 10-0988395호 (2010.10.11. 등록)
본 발명은 상기 문제점을 해결하기 위한 것으로, 응용 프로그램의 실행 가능성을 실제 기기 상에서 사람이 수작업으로 확인하는 대신에 자동으로 진행하며, 추상화된 어플리케이션을 이용하여 검증되는 반례가 실제 프로그램 상에서 실행 가능한지 확인할 수 있는 응용 프로그램의 실행 가능성 확인 방법 및 장치, 그리고 이를 구현하기 위한 프로그램이 기록된 기록매체를 제공한다.
본 발명이 해결하고자 하는 과제들은 이상에서 언급한 과제들로 제한되지 않으며, 언급되지 않은 또 다른 과제들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.
상기 과제를 달성하기 위한 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 방법은, 응용 프로그램의 어플리케이션 모델 및 운영체제 모델을 통합하여 실행 시나리오 모델을 생성하는 단계; 상기 실행 시나리오 모델에서 태스크 실행 순서 및 문장 블록을 도출하는 단계; 상기 응용 프로그램의 실행에 따른 문맥 전환 위치를 주석첨가(annotate)하는 단계; 상기 태스크 실행 순서 및 문장 블록과, 상기 문맥 전환 위치를 기초로 상기 응용 프로그램의 실행 가능한 경로를 검증하는 단계; 및 상기 응용 프로그램의 실행 가능성을 확인하여 보고하는 단계를 포함한다.
또한, 상기 실행 시나리오 모델을 생성하는 단계는, 모델 검증 도구 NuSMV를 이용하여 반례를 생성하는 단계를 포함할 수 있다.
또한, 상기 반례를 생성하는 단계는, 상기 응용 프로그램의 태스크 스케줄링 정보 및 제어 흐름을 포함하는 상기 반례를 생성하는 단계를 포함할 수 있다.
또한, 상기 반례를 생성하는 단계는, API 호출 제약사항 준수 여부를 확인하여 상기 반례를 생성하는 단계를 포함할 수 있다.
또한, 상기 태스크 실행 순서 및 문장 블록을 도출하는 단계는, 상기 태스크 실행 순서에 따라 각 태스크를 순서대로 호출하는 테스트 드라이버를 구현하는 단계를 더 포함할 수 있다.
또한, 상기 태스크 실행 순서 및 문장 블록을 도출하는 단계는, API 호출을 상기 문장 블록으로 도출하는 단계를 포함할 수 있다.
또한, 상기 문장 블록의 API 호출을 상기 응용 프로그램의 API 호출과 비교하는 단계를 더 포함할 수 있다.
또한, 상기 문맥 전환 위치를 주석첨가(annotate)하는 단계는, API 호출을 통해 태스크 생성 및 종료, 리소스 해제, 이벤트 대기 및 발생 시 문맥 전환이 발생하는 단계를 포함할 수 있다.
또한, 상기 응용 프로그램의 실행 중에 상기 문맥 전환 위치를 만나면 프로그램 카운터를 저장하고, 문맥 전환 후 재실행될 경우에 상기 저장된 프로그램 카운터를 이용하여 실행 위치로 복귀하는 단계를 더 포함할 수 있다.
또한, 상기 실행 가능한 경로를 검증하는 단계는, 모델 검증 도구 CBMC를 이용하여 검증하는 단계를 포함할 수 있다.
그리고, 상기 실행 가능한 경로를 검증하는 단계는, 상기 응용 프로그램에서 반례와 동일한 순서로 API 호출을 수행하는 실행 경로의 존재 유무를 검증하는 단계를 포함할 수 있다.
상기 과제를 달성하기 위한 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 장치는, 응용 프로그램의 어플리케이션 모델 및 운영체제 모델을 통합하여 실행 시나리오 모델을 생성하는 모델 생성부; 상기 실행 시나리오 모델에서 태스크 실행 순서를 도출하며, 상기 태스크 실행 순서에 따라 각 태스크를 순서대로 호출하는 테스트 드라이버를 생성하는 드라이버부; 상기 실행 시나리오 모델에서 문장 블록을 도출하며, 상기 문장 블록의 API 호출을 상기 응용 프로그램의 API 호출과 비교하는 API 모니터를 생성하는 모니터링부; 상기 응용 프로그램의 실행에 따른 문맥 전환 위치를 주석첨가(annotate)하여 주석첨가된 어플리케이션을 생성하는 주석첨가부; 상기 테스트 드라이버, 상기 API 모니터, 상기 주석첨가된 어플리케이션을 이용하여 상기 응용 프로그램의 실행 가능한 경로를 검증하는 검증부; 및 상기 응용 프로그램의 실행 가능성을 확인하여 보고하는 보고부를 포함한다.
또한, 상기 모델 생성부는, 모델 검증 도구 NuSMV를 이용하여 반례를 생성할 수 있다.
또한, 상기 모델 생성부는, 상기 응용 프로그램의 태스크 스케줄링 정보 및 제어 흐름을 포함하는 상기 반례를 생성할 수 있다.
또한, 상기 모델 생성부는, API 호출 제약사항 준수 여부를 확인하여 상기 반례를 생성할 수 있다.
또한, 상기 드라이버부는, 반례에 나타난 태스크 실행 순서를 이용하여 상기 테스트 드라이버를 생성할 수 있다.
또한, 상기 모니터링부는, 상기 문장 블록의 API 호출을 상기 응용 프로그램의 API 호출과 비교하여 동일하지 않은 경우, 실행 가능한 경로의 검증 대상에서 제외할 수 있다.
또한, 상기 주석첨가부는, API 호출을 통해 태스크 생성 및 종료, 리소스 해제, 이벤트 대기 및 발생 시 문맥 전환이 발생할 수 있다.
또한, 상기 검증부는, 모델 검증 도구 CBMC를 이용하여 검증할 수 있다.
그리고, 상기 검증부는, 상기 응용 프로그램에서 반례와 동일한 순서로 API 호출을 수행하는 실행 경로의 존재 유무를 검증할 수 있다.
상술하여 설명한 상기 과제를 달성하기 위한 본 발명의 여러 실시예에 따른 응용 프로그램의 실행 가능성 확인 방법들을 구현하기 위한 프로그램이 기록된 컴퓨터로 판독 가능한 기록매체에 기록될 수 있다.
본 발명의 기타 구체적인 사항들은 상세한 설명 및 도면들에 포함되어 있다.
본 발명에 따르면, 응용 프로그램의 실행 가능성을 실제 기기 상에서 사람이 수작업으로 확인하는 대신에 자동으로 진행함으로써, 작업의 효율성을 높일 수 있다.
또한, 추상화된 어플리케이션을 이용하여 검증되는 반례가 실제 프로그램 상에서 실행 가능한지 확인함으로써, 오경보를 방지할 수 있다.
도 1은 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 방법의 순서를 도시한 도면이다.
도 2는 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 방법의 상세 순서를 도시한 도면이다.
도 3은 응용 프로그램의 일예를 도시한 도면이다.
도 4는 도 3의 태스크 실행 순서를 도시한 도면이다.
도 5는 태스크를 상태 기계(state machine)으로 변환화는 과정을 도시한 도면이다.
도 6은 테스트 드라이버(Test driver), 주석첨가된 어플리케이션(Annotated application), API 모니터(API monitor)의 일예를 도시한 도면이다.
도 7은 goto_pc_t1 함수의 일예를 도시한 도면이다.
도 8은 프로그램 카운터를 초기화하는 일예를 도시한 도면이다.
도 9는 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 장치의 구성을 도시한 도면이다.
이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 상세히 설명한다. 본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 것이며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하며, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
비록 제1, 제2 등이 다양한 소자, 구성요소 및/또는 섹션들을 서술하기 위해서 사용되나, 이들 소자, 구성요소 및/또는 섹션들은 이들 용어에 의해 제한되지 않음은 물론이다. 이들 용어들은 단지 하나의 소자, 구성요소 또는 섹션들을 다른 소자, 구성요소 또는 섹션들과 구별하기 위하여 사용하는 것이다. 따라서, 이하에서 언급되는 제1 소자, 제1 구성요소 또는 제1 섹션은 본 발명의 기술적 사상 내에서 제2 소자, 제2 구성요소 또는 제2 섹션일 수도 있음은 물론이다.
본 명세서에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다. 명세서에서 사용되는 "포함한다(comprises)" 및/또는 "이루어지다(made of)"는 언급된 구성요소, 단계, 동작 및/또는 소자는 하나 이상의 다른 구성요소, 단계, 동작 및/또는 소자의 존재 또는 추가를 배제하지 않는다.
다른 정의가 없다면, 본 명세서에서 사용되는 모든 용어(기술 및 과학적 용어를 포함)는 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 사용될 수 있을 것이다. 또 일반적으로 사용되는 사전에 정의되어 있는 용어들은 명백하게 특별히 정의되어 있지 않는 한 이상적으로 또는 과도하게 해석되지 않는다.
이하, 본 발명에 대하여 첨부된 도면에 따라 보다 상세히 설명한다.
도 1은 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 방법의 순서를 도시한 도면이다.
도 1을 참조하면, 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 방법은, 응용 프로그램의 어플리케이션 모델 및 운영체제 모델을 통합하여 실행 시나리오 모델을 생성하며(S110), 상기 실행 시나리오 모델에서 태스크 실행 순서 및 문장 블록을 도출하고(S120), 상기 응용 프로그램의 실행에 따른 문맥 전환 위치를 주석첨가(annotate)하고(S130), 상기 태스크 실행 순서 및 문장 블록과, 상기 문맥 전환 위치를 기초로 상기 응용 프로그램의 실행 가능한 경로를 검증하여(S140), 상기 응용 프로그램의 실행 가능성을 확인하고 보고한다(S150).
실행 시나리오 모델을 생성하는 경우(S110), 어플리케이션 모델은 응용 프로그램의 분기문을 추상화하여 구성할 수 있고, 운영체제 모델은 명세서를 분석하여 구성할 수 있다.
여기에서, 응용 프로그램은 일련의 태스크(task)로 구성된다. 각 태스크에는 고유한 우선 순위가 있으므로, 우선 순위가 높은 태스크가 먼저 스케줄링된다. 리소스를 점유하여 중요한 섹션에 액세스하는 경우, 우선 순위가 높은 태스크보다 우선 순위가 낮은 태스크를 실행할 수도 있다. 응용 프로그램은 운영 체제에서 제공하는 API 기능을 통해 기본 운영 체제와 상호 작용한다.
실행 시나리오 모델의 생성 시, 모델 검증 도구 NuSMV를 이용하여 반례(counterexample)를 생성할 수 있다. 모델 검증 도구 NuSMV(New Symbolic Model Verifier)는 모델 언어로 작성된 검증 대상을 논리식으로 만들고, 논리식이 참이 될 수 없다는 것을 증명함으로써 모델이 검증 속성을 만족하는지를 확인하는 검증 도구이다.
NuSMV의 입력 언어는 여러 개의 모듈로 구성되며, 각 모듈은 상태 기계(state machine)의 상태와 상태 전이를 정의한다. 모든 상태 기계의 상태 전이는 내부 클록 틱(clock tick)에 의해 동기화되어 전체 모듈에서 동시에 발생한다. NuSMV는 제공된 모델에 시제 논리 속성 검증을 적용하고, 속성 위반 시나리오가 있을 경우에 상태 기계의 상태 시퀀스(state sequence)를 반례로 보고한다. 여기에서, 반례는 응용 프로그램의 태스크 스케줄링 정보 및 제어 흐름을 포함할 수 있다.
반례를 생성하는 경우, API 호출 제약사항 준수 여부를 확인하여 상기 반례를 생성할 수 있다. 검증할 수 있는 API 호출 제약사항의 예로 “태스크가 이벤트 대기 API를 호출하여 이벤트를 기다릴 경우 이벤트 발생 API를 호출함으로써 언젠가는 이벤트를 전달해 주어야 한다”가 있다. API 호출 제약사항의 준수 또는 위반 여부는 발생한 API 호출 순서를 통해 식별할 수 있으며, 상기 제약사항의 경우 이벤트 발생 API 호출과 짝지어지지 않은 이벤트 대기 API 호출이 포함된 반례가 보고된다.
태스크 실행 순서 및 문장 블록을 도출하는 경우(S120), 태스크 실행 순서에 따라 각 태스크를 순서대로 호출하는 테스트 드라이버를 구현할 수 있으며, 또한 API 호출을 상기 문장 블록으로 도출할 수 있다.
테스트 드라이버는 시나리오 모델에 나타난 태스크 실행 순서에 따라 각 태스크를 순서대로 호출하며, 호출된 태스크들은 프로그램 카운터를 통해 실행 위치를 기억한다. 실행 시나리오 모델이 반례를 생성하는 경우, 반례에 나타난 태스크 실행 순서 정보가 테스트 드라이버를 구성한다.
문장 블록(statement block)은 일련의 명령문이다. 각 문장 블록은 단일 제어 스레드에서 실행할 수 있는 최대 문장 수로 구성된다. 각 문장 블록은 문맥 전환의 단위이며, 문장 블록이 실행된 후 제어 흐름(control flow)이 다른 태스크로 전환될 수 있다.
이러한 문장 블록은 API 호출을 상기 문장 블록으로 도출할 수 있다. 즉, 문장(statement)이 API 함수를 호출하는 간단한 문장일 수 있다. 문장 블록이 API 호출일 경우, 상기 문장 블록의 API 호출을 응용 프로그램의 API 호출과 비교할 수 있다.
응용 프로그램의 실행에 따른 문맥 전환 위치를 주석첨가(annotate)하는 경우(S130), API 호출을 통해 태스크 생성 및 종료, 리소스 해제, 이벤트 대기 및 발생 시 문맥 전환이 발생할 수 있다.
모든 태스크는 API를 통해 태스크 생성과 종료를 수행하게 된다. 리소스 할당 또는 해제 API와, 이벤트(event) 대기 또는 발생 API를 호출함으로써, 동기화를 수행한다. 운영 체제는 이들을 모두 고려하여 실행 태스크를 선정하므로, API 호출을 통해 태스크 생성, 태스크 종료, 리소스 해제, 이벤트 대기, 이벤트 발생 시 문맥 전환은 발생한다.
또한, 응용 프로그램의 실행 중에 문맥 전환 위치를 만나면 프로그램 카운터를 저장하고, 문맥 전환 후 재실행될 경우에 상기 저장된 프로그램 카운터를 이용하여 실행 위치로 복귀할 수 있다.
태스크 실행 순서 및 문장 블록과, 문맥 전환 위치를 기초로 상기 응용 프로그램의 실행 가능한 경로를 검증하는 경우(S140), 모델 검증 도구 CBMC를 이용하여 검증할 수 있다. 즉, 태스크 실행 순서 및 문장 블록과, 문맥 전환 위치를 CBMC(C Bounded Model Checker)에 입력하여 실행 가능한 경로를 검증하게 된다. 이러한 CBMC는 C언어로 작성된 프로그램을 위한 경로길이제한 모델 검증 도구이다. CBMC는 C 프로그램 내에 존재하는 assert 속성 위반, 버퍼 오버플로우, 포인터 안전성 등을 검증한다.
응용 프로그램의 실행 가능성을 확인하고 보고하는 경우(S150), 응용 프로그램에서 반례와 동일한 순서로 API 호출을 수행하는 실행 경로의 존재 유무를 검증할 수 있다. 예를 들어, 실행 경로가 존재할 경우, 실행 경로와 함께 assert 속성 위반이 보고되고, 실행 경로가 존재하지 않을 경우 assert 속성 준수가 보고될 수 있다.
이하에서는, 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 방법의 구체적인 과정을 살펴 보도록 한다.
도 2는 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 방법의 상세 순서를 도시한 도면이다. 또한, 도 3은 응용 프로그램의 일예를 도시한 도면이다. 또한, 도 4는 도 3의 태스크 실행 순서를 도시한 도면이다. 또한, 도 5는 태스크를 상태 기계(state machine)으로 변환화는 과정을 도시한 도면이다. 또한, 도 6은 테스트 드라이버(Test driver), 주석첨가된 어플리케이션(Annotated application), API 모니터(API monitor)의 일예를 도시한 도면이다. 또한, 도 7은 goto_pc_t1 함수의 일예를 도시한 도면이다. 그리고, 도 8은 프로그램 카운터를 초기화하는 일예를 도시한 도면이다.
도 2를 참조하면, 응용 프로그램의 속성을 확인하여(S102), 어플리케이션 모델을 생성한다(S104). 응용 프로그램은 멀티태스킹이 가능하며, 안전이 중요한 영역에서 주로 사용되는 센서, 액추에이터, 브레이크 페달, 엔진 등과 같은 소규모 임베디드 장치를 제어하도록 설계된 운영 체제에서 실행될 수 있다.
이러한 응용 프로그램의 일예로 도 3 및 도 4를 고려할 수 있다. 도 3 및 도 4에서, 응용 프로그램이 두 개의 태스크 t1과 t2로 구성된 멀티태스킹이 가능하며, t1은 시스템 형상에 따라 프로그램의 시작과 동시에 활성화되며 우선순위 값은 1을 가진다. 각 태스크의 실행 순서는 각 태스크가 호출하는 API를 통하여 결정되며 도 4와 같다. t1은 ActivateTask API 함수를 이용하여 우선순위가 높은 t2를 활성화하고 높은 우선순위의 t2는 t1을 점유하며 WaitEvent API를 호출함으로써 대기 상태에 돌입할 때에는 t1이 다시 실행된다. 다시 실행된 t1은 t2에게 이벤트를 보내주어 t2가 다시 실행되도록 하며 높은 우선순위의 t2가 먼저 종료되고 난 다음에 t1이 나머지 역할을 수행하고 프로그램이 종료된다.
어플리케이션 모델은 프로그램 코드를 변환하여 생성되며(S104), 응용 프로그램의 한 문장을 하나의 노드로 나타내고, 문장 실행 순서에 따라 간선을 연결한 제어흐름그래프(Control Flow Graph)로 나타낼 수 있다. 제어흐름그래프(CFG)의 인접한 두 노드에서 정의하는 할당문이 동시에 수행될 수 있는 경우(다음 노드가 먼저 수행되어도 결과에 영향을 미치지 않는 경우) 하나의 상태로 통합되며, API 호출 노드는 제거하고 이전 상태와 다음 상태를 상태 전이(state transition)로 연결하여 API 호출을 상태 전이에 표기할 수 있다. 효과적인 검증을 위해 분기 조건들을 추상화함으로써 검증 효율을 높이게 된다.
도 5를 참조하면, 좌측은 태스크 t1의 프로그램 코드를 나타내며, 가운데는 제어흐름 그래프를 나타내고, 우측은 상태 기계(state machine)로 변환한 모습을 나타낸다. 조건문(if)에 대응되는 2번 상태의 분기 조건은 추상화되어 3번 상태로 전이될 때 두 상태 전이 중 하나가 임의로 선택된다.
운영 체제 커널(OS Kernel)은 태스크(Tasks), 이벤트(Events), 리소스(Resources) 또는 알람(Alarms) 등 일련의 커널 객체로 구성된다. 운영 체제(OS)는 실행(RUN), 준비(RDY), 대기(WIT), 일시 중지(SUS)로 구성된 각 태스크의 내부 상태를 유지할 수 있다. 각 태스크의 내부 상태는 API 함수 호출을 통해 응용 프로그램의 요청에 의해 트리거되는 운영 체제 커널의 작업 관리 및 스케줄링 메커니즘에 따라 변경될 수 있다. 이러한 운영 체제는 우선 순위 기반 FIFO 스케줄링을 채택할 수 있다.
각 커널 객체의 동작을 매개 변수화된 상태 머신(state machine)으로 모델링하고, 운영 체제 모델을 시스템 구성에 의해 타입(types)과 넘버(numbers)가 결정되는 여러 커널 객체의 동기화된 병렬 구성으로 정의할 수 있다.
어플리케이션 모델의 생성(S104) 및 운영 체제 모델의 생성(S106) 후에, 어플리케이션 모델 및 운영 체제 모델을 통합하여 실행 시나리오 모델을 생성한다(S112). 모델 검증 도구 NuSMV를 이용하여 태스크 스케줄링 정보(task scheduling information)와 응용 프로그램의 제어 흐름(control flow)을 포함하는 반례 추적(counterexample trace)을 생성할 수 있다. 실행 가능한 경우, 반례는 진정한 경보(alarm)가 된다.
실행 시나리오 모델로부터 태스크 실행 순서를 추출하고(S122), API 호출을 추출할 수 있다(S124).
검증할 수 있는 API 호출 제약사항의 예로 “태스크가 이벤트 대기 API를 호출하여 이벤트를 기다릴 경우 이벤트 발생 API를 호출함으로써 언젠가는 이벤트를 전달해 주어야 한다”가 있다. API 호출 제약사항 준수/위반 여부는 발생한 API 호출 순서를 통해 식별할 수 있으며, 이 제약사항의 경우 이벤트 발생 API 호출과 짝지어지지 않은 이벤트 대기 API 호출이 포함된 반례가 보고된다.
다음의 표 1은 상기 도 3 및 도 4의 예제 응용 프로그램에 API 호출 제약사항 준수 여부를 검증한 결과 보고된 반례를 나타낸다. 각 행은 하나의 상태를 나타내며 첫 째 열부터 각 열은 상태 ID, 실행 태스크, t1과 t2의 태스크 상태, t1과 t2의 어플리케이션 모델 상태, 호출된 API와 매개변수를 나타낸다.
Figure 112020083888865-pat00001
본 반례는 상태 7번에서 t2가 WaitEvent를 호출하여 대기 상태에 진입한 이후에 이벤트를 전달받지 못하였으므로 앞서 소개한 API 호출 제약사항을 위반한다.
그러나, t2는 상태 2번과 6번에서 활성화되어 활성화될 때마다 상태 3번과 상태 7번에서 WaitEvent API를 호출하는 것으로 보고되었지만, t2가 두 번째 활성화되었을 때는 분기 조건으로 인해 WaitEvent API를 호출할 수 없으므로 보고된 반례는 오경보(false alarm)이다. 오경보는 추상화된 분기문으로 인해 프로그램에서 재현될 수 없는 API 호출 순서가 반례에 포함되었을 때 발생한다.
API 호출 제약사항 검증 결과 보고된 반례는 제약사항을 위반하는 API 호출 순서를 가지며 동일한 API 호출을 수행하는 실행 경로를 응용 프로그램에서 확인함으로써 오경보를 식별할 수 있다.
오경보 식별을 위해, 반례를 실제 환경에서 재현할 경우 운영 체제뿐만 아니라 플랫폼 환경이 갖추어져 있어야 한다. 그러나, 이러한 환경을 구성하는 것은 어렵고 복잡한 작업이며 개발 환경에서 준비되어 있지 않을 수 있다. 또한 수작업으로 오경보를 식별하는 것은 시간이 오래 소요되는 작업이며 프로그램의 크기가 커질수록 높아지는 복잡도를 모두 고려한 식별 작업은 불가능하다.
이에, 오경보를 식별하기 위하여 가상 환경을 이용할 수 있다. 가상 환경은 응용 프로그램이 작동하기 위한 플랫폼 환경과 태스크 실행 순서를 정의하는 테스트 드라이버로 구성될 수 있다.
플랫폼 환경은 플랫폼 의존 함수와 변수를 위한 환경이며, 검증 대상 응용 프로그램에는 여러 태스크가 번갈아 수행되기 위한 문맥 전환 정보가 삽입된다. 반례에 나타난 태스크 실행 순서 정보는 테스트 드라이버를 구성할 때 사용되며 테스트 드라이버는 태스크 실행 순서에 따라 각 태스크를 순서대로 호출한다(S126). 또한, API 모니터는 반례의 API 호출과 프로그램의 API 호출을 비교한다(S128).
플랫폼 환경을 정확하게 구성하기 위해서는 플랫폼의 행위를 정확히 파악해야 하며 프로그램이 작동해야 할 다양한 플랫폼이 모두 고려되어야 한다. 그러나, 플랫폼 환경을 정확히 구성하는 것 또한 수작업이 필요할 뿐 아니라 시간이 오래 걸리는 작업이다. 그러므로, 플랫폼 환경을 정확하게 구성하는 대신에 임의의 행위를 수행하는 플랫폼 환경을 정의하고 플랫폼 의존 함수와 변수가 임의의 값을 반환하도록 구성한다.
테스트 드라이버는 여러 태스크가 운영 체제의 스케줄링에 맞게 번갈아 수행할 수 있도록 해야 한다. 그러나, 운영 체제를 함께 검증에 사용하는 것은 검증 비용을 매우 증가하게 만드므로, 반례에 나타난 태스크 실행 순서를 이용하여 각 태스크를 순서대로 호출하는 테스트 드라이버를 구성하는 것이 바람직하다. 반례에 나타난 태스크 실행 순서는 운영 체제의 모든 스케줄링을 대신할 수는 없으나, 반례를 재현하기에는 충분하다.
도 6을 참조하면, 좌측의 Test driver(테스트 드라이버)는 trace 변수와 main 함수로 구성되어 있다. trace 변수는 반례에서 나온 정보를 기반으로 정의되며, trace 변수는 표 1에 나타난 태스크 실행 순서와 API 호출 실행 순서를 담는다. main 함수는 trace에 명시된 태스크 실행 순서에 따라 각 태스크를 순서대로 호출한다.
호출된 태스크들은 문맥 전환을 위해 프로그램 카운터(PC)의 삽입을 통해 실행 위치를 기억한다. 검증 대상 응용 프로그램의 실행 중 문맥 전환 위치를 만나면 현재 프로그램 카운터를 저장하고 문맥 전환 후 다시 실행될 경우에 저장된 정보를 이용해 실행 위치를 복귀한다. 또한 모든 지역 변수는 문맥 전환이 발생하더라도 값이 유지되도록 전역 변수로 선언하고, 태스크가 새로 생성될 때마다 지역 변수 값을 초기화한다.
우선순위 기반 FIFO 스케줄링을 지원하는 운영 체제의 경우, 태스크 생성/종료, 리소스 해제, 이벤트 대기/발생을 수행할 경우에만 문맥 전환이 발생할 수 있으며, 인터럽트는 없는 것으로 가정한다. 그러므로, 가능한 문맥 전환 위치는 API 호출문이 호출된 위치이며, 태스크의 API 호출문마다 문맥 전환 필요 여부를 확인하고 필요에 따라 문맥 전환을 수행하는 코드를 삽입한다(S132).
다시 도 6을 참조하면, 도 3의 예시적인 프로그램 코드에 문맥 전환 정보가 삽입된 모습(Annotated application)을 나타내며(S134), Task(t1) 및 Task(t2) 간 화살표는 태스크 사이에 발생하는 문맥 전환을 나타낸다.
태스크 실행순서에 따라 t1이 제일 먼저 실행되며 ActivateTask(t2)를 호출하고 위치 정보 1을 프로그램 카운터 pc[t1]에 저장한 후 return 문을 통해 제어를 테스트 드라이버에게 반환한다.
테스트 드라이버는 다음 실행할 태스크인 t2를 호출하며 t2는 WaitEvent(e1)을 호출하고 제어를 테스트 드라이버에게 반환한다.
테스트 드라이버는 다시 t1을 실행하며 t1은 goto_pc_t1 함수를 호출하여 기존 실행 위치를 복귀한다. 도 7에 태스크 t1의 goto_pc_t1의 일예가 도시되어 있다.
goto_pc_t1 함수는 프로그램 카운터 pc에 저장된 값을 이용하여 기존 실행 위치를 파악하고 goto 문을 이용해 실행 위치를 복귀한다.
코드 검증을 통해 모든 실행 가능한 경로를 식별한다(S142). 여기에서, 모델 검증 도구인 CBMC를 이용한다. 테스트 드라이버인 메인 함수가 반례에 나타난 모든 태스크를 수행한 후에 assert(false)를 삽입하여 반례가 모두 수행된 위치까지의 실행 경로존재 유무를 확인한다.
이때, 반례에 나타난 API 호출 순서와 동일한 실행 경로를 식별해야 하므로, API 모니터를 정의하여 태스크가 각 API를 호출할 때마다 assume 문을 이용하여 반례에 나타난 API 호출과 비교한다(S128). 도 6의 우측 하단에 ActivateTask API의 모니터의 예가 도시되어 있다.
코드 검증에서 모델 검증 도구인 CBMC는 assume 문의 조건이 만족되지 않는 실행경로를 대상에서 제외한다. 가상 환경에서 반례에 나타난 API 호출을 모두 수행하고 assert 문에 도달할 수 있는 실행 경로의 존재 여부를 CBMC를 이용하여 코드 검증한다(S142).
실행 경로가 존재할 경우, 실행 경로와 함께 assert 속성 위반을 보고할 것이며, 실행 경로가 존재하지 않을 경우, assert 속성 준수를 보고할 것이다(S152).
반례와 동일한 실행 경로를 찾지 못할 경우에는 재현 불가능함을 알 수 있으나, 반례와 동일한 실행 경로를 찾을 경우에는 플랫폼 행위가 실제 발생 가능한지 확인해야 한다.
여기에서, 코드 검증을 수행하는 모델 검증 도구인 CBMC가 최대한 가볍게 동작하도록 하여 식별 성능을 향상시킬 수 있다. 구체적으로, 태스크 재실행 여부에 따른 프로그램 카운터 초기화 방안, 테스트 드라이버의 루프 제거를 통한 정확성 향상 방안, 배열 초과 접근 방지를 통한 CBMC 성능 가속화 방안을 고려할 수 있다.
먼저, 태스크 재실행 가능 여부에 따라 프로그램 카운터를 초기화하여 검증 복잡도를 낮출 수 있다. 태스크의 프로그램 카운터는 태스크 종료 API 위치에서 초기화되며, 태스크 종료 이후 다음 행위가 존재하는 경우에만 프로그램 카운터 초기화가 필요하다.
예를 들어, 도 6의 테스트 드라이버에서 소개한 태스크 실행 순서에는 두 번의 태스크 t2 활성화가 포함되어 있으며, 네 번째 위치에서 태스크 t2가 종료되고 난 후 다시 종료되지 않는다. 이 경우 네 번째 위치에서 프로그램 카운터를 초기화하고 이후로는 초기화가 필요치 않다.
특히, 태스크 종료 API가 호출되었을 때, 프로그램 카운터를 초기화할 상한 인덱스를 정의하여 상한 인덱스 이후에는 프로그램 초기화가 일어나지 않도록 할 수 있다. 상한 인덱스는 각 태스크에서 호출된 API 호출 중 마지막 API 호출을 제외하고 가장 나중에 등장한 태스크 종료 API 위치로 한다. 마지막 API 호출이 태스크 종료일 경우에는 초기화가 필요하지 않기 때문이며, 태스크 종료 API 호출이 존재하지 않을 경우 초기화 상한 인덱스를 -1로 하여 항상 초기화되지 않도록 할 수 있다.
도 8은 상한 인덱스를 고려한 프로그램 카운터 초기화를 나타낸다. 태스크 t2가 인덱스 3 이전에 태스크 종료 API를 호출할 경우에는 프로그램 카운터가 초기화되며, 이후에 태스크 종료 API 호출 시에는 프로그램 카운터를 -1로 설정할 수 있다.
다음으로, 테스트 드라이버는 루프를 사용하지 않고 구성될 수 있다. CBMC의 루프 실행횟수 제한 값을 반례의 길이보다 적게 줄 경우 반례에 나타난 태스크들을 모두 실행할 수 없으므로, 부정확한 식별 결과가 보고될 것이다. 그러므로, 테스트 드라이버는 루프를 사용하는 대신에 정해진 횟수만큼 태스크 활성화를 할 수 있다.
도 6에서, 테스트 드라이버는 7회의 태스크 실행을 수행하므로, 반복문을 제거하고 태스크를 7회 호출하도록 드라이버를 변경할 수 있다.
마지막으로, 드라이버 생성기를 작성하는 프로그래머의 실수나 드라이버 생성기 자체의 오류로 인하여 프로그램 카운터 등의 배열 크기가 충분히 주어지지 않을 수 있다. 드라이버에서 사용하는 배열 자료형의 크기가 충분하지 않을 경우, CBMC를 이용한 검증 시간이 대거 낭비될 수 있다. CBMC의 경우 bounds-check 옵션을 제공하며 배열의 크기를 초과하는 접근 수행 시 사용자에게 이를 보고하여 수정할 수 있도록 도와준다.
이하에서는, 상술하여 설명한 방법의 효과를 구체적인 실험 결과를 통해 살펴 보도록 한다.
검증 대상 프로그램은 임베디드 운영체제의 적합성 테스트에 사용되는 테스트 프로그램과 차량전장용 창문 제어 프로그램이다. 테스트 프로그램에는 API 호출 안전성 검증 기법을 적용하였다.
API 호출 안전성 검증 기법은 운영 체제 모델과 어플리케이션 모델을 정의하고 모델 기반 검증을 통해 멀티태스크 프로그램의 API 호출 안전성을 검증한다. 어플리케이션 모델은 사용자 프로그램의 분기문을 추상화하여 구성되었으며, 운영 체제 모델은 명세서를 분석하여 정의하였다. 두 모델을 결합하여 NuSMV 모델 검증 도구로 API 호출 안전성이 검증된 경우 기존 프로그램도 안전함을 알 수 있으나 그렇지 않을 경우 API 호출 안전성을 위반하는 API 호출 순서가 있음을 반례와 함께 보고한다.
각 테스트 프로그램이 API 호출 제약사항 "태스크가 이벤트 대기 API를 호출하여 이벤트를 기다릴 경우 이벤트 발생 API를 호출함으로써 언젠가는 이벤트를 전달해 주어야 한다"를 준수하는지 확인하였다.
창문 제어 프로그램은 하나의 상태 기계(state machine)로 표현한 후 각 상태에 도달할 수 있는 시나리오가 있는지를 검증하였다. 검증 결과 반례가 보고될 경우, 본 발명에서 상술하여 설명한 오경보 식별 방법을 적용하였다.
오경보 식별 방법의 효과를 확인하기 위해 python 언어로 오경보 식별 과정 자동화 프로토타입을 구현하였으며, 모든 실험은 3.4-GHz Intel Xeon E5-1680 CPU와 128 GB RAM을 가진 Fedora Linux 기반 컴퓨터에서 CBMC 5.10과 함께 실행되었다. 반복문 실행횟수 제한(unwind)은 20으로 하였다.
먼저, 첫 번째 실험에서는 운영 체제를 위한 테스트 프로그램을 대상으로 API 호출 안전성 검증을 수행하였으며, 검증 결과 보고된 14건의 반례에 제안한 오경보 식별 방법을 적용하였다.
다음의 표 2는 검증 결과 및 오경보 여부 식별 결과를 나타낸다. 각 열은 프로그램 ID, 어플리케이션의 태스크 수와 코드 수, 모델 기반 API 호출 안전성 검증 시간, 보고된 반례의 길이를 나타낸다. 그리고, 여섯째 열과 일곱째 열은 성능 향상이 이루어지지 않았을 경우 오경보 식별 시간과 보고된 반례의 재현 가능 여부를 나타내고, 여덟째 열과 아홉째 열은 성능 향상이 이루어진 경우 오경보 식별 시간과 재현 가능 여부를 나타낸다.
Figure 112020083888865-pat00002
실험에 사용한 14개의 반례 중 4개는 프로그램에서 재현 가능함이 확인되었으나, 나머지 10개는 오경보 임이 확인되었다. 수작업으로 분석한 결과 10개의 오경보는 실행할 수 없는 분기에 위치한 API 호출을 수행하였기 때문에 발생하였다. 본 발명에서 제안한 방법을 적용하지 않을 경우 평균 89.205초의 오경보 식별 시간이 필요하였으며, 제안한 방법을 적용한 경우 평균 0.199초의 시간이 필요하였으므로 매우 효과적임을 알 수 있다.
성능 향상이 크게 이루어진 4, 13, 14번 프로그램은 많은 API 호출을 수행하거나 분기에 따라 다양한 API 호출이 가능한 태스크가 포함되어 있으며 반례에 이들이 종료되는 경우가 포함되어 있을 때 오랜 식별 시간이 필요함을 알 수 있었다. 이 프로그램들은 태스크 재실행 가능 여부에 따른 프로그램 카운터 초기화 방안에 큰 영향을 받는 것을 알 수 있었다.
다음으로, 두 번째 실험에서는 자동차의 창문 제어 소프트웨어를 대상으로 테스트 시나리오 추출을 수행하였으며, 모델 검증 결과 각 상태에 도달할 수 있는 반례를 획득하였다. 획득된 반례에 본 발명에서 제안한 방법을 적용하여 반례의 재현 가능 여부를 판별하였다.
표 3은 실험 결과 및 오경보 식별 결과를 나타내며 각 열은 상태 이름, 모델 기반 검증 시간, 보고된 반례의 길이, 오경보 식별 소요 시간과 반례의 재현 가능 여부를 나타낸다.
Figure 112020083888865-pat00003
추출된 8개의 반례 중 2개는 프로그램에서 재현 가능하였고 나머지는 재현 가능하지 않았으며 수작업으로 분석한 결과와 일치하였다. 오경보 식별 시간은 평균 17.95 초가 소요되었다.
모델 검증 보고된 반례를 대상으로 오경보 식별을 수행한 결과 73%의 높은 비율로 오경보가 발생하는 것을 확인하였으며, 본 발명에서 제안한 방법을 통해 빠른 시간 내에 오경보 여부를 확인할 수 있음을 확인할 수 있다.
도 9는 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 장치의 구성을 도시한 도면이다.
도 9를 참조하면, 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 장치(100)는, 모델 생성부(110), 드라이버부(120), 모니터링부(130), 주석첨가부(140), 검증부(150), 보고부(160)를 포함한다.
모델 생성부(110)는 응용 프로그램의 어플리케이션 모델 및 운영체제 모델을 통합하여 실행 시나리오 모델을 생성한다. 모델 생성부(110)가 어플리케이션 모델은 응용 프로그램의 분기문을 추상화하여 구성할 수 있고, 운영체제 모델은 명세서를 분석하여 구성할 수 있다.
이때, 모델 생성부(110)는 모델 검증 도구 NuSMV를 이용하여 반례를 생성할 수 있다. 모델 생성부(110)는 NuSMV를 사용하여 실행 시나리오 모델에 시제 논리 속성 검증을 적용하고, 속성 위반 시나리오가 있을 경우에 상태 기계의 상태 시퀀스(state sequence)를 반례로 보고한다.
여기에서, 모델 생성부(110)는 응용 프로그램의 태스크 스케줄링 정보 및 제어 흐름을 포함하는 반례를 생성할 수 있다.
또한, 모델 생성부(110)는 API 호출 제약사항 준수 여부를 확인하여 상기 반례를 생성할 수 있다. API 호출 제약사항의 준수 또는 위반 여부는 발생한 API 호출 순서를 통해 식별할 수 있다.
드라이버부(120)는 실행 시나리오 모델에서 태스크 실행 순서를 도출하며, 상기 태스크 실행 순서에 따라 각 태스크를 순서대로 호출하는 테스트 드라이버(Test driver)를 생성한다.
이때, 테스트 드라이버는 실행 시나리오 모델에 나타난 태스크 실행 순서에 따라 각 태스크를 순서대로 호출하며, 호출된 태스크들은 프로그램 카운터를 통해 실행 위치를 기억한다. 실행 시나리오 모델이 반례를 생성하는 경우, 반례에 나타난 태스크 실행 순서가 테스트 드라이버를 구성한다. 즉, 드라이버부(120)는 반례에 나타난 태스크 실행 순서를 이용하여 테스트 드라이버를 생성할 수 있다.
모니터링부(130)는 실행 시나리오 모델에서 문장 블록을 도출하며, 상기 문장 블록의 API 호출을 응용 프로그램의 API 호출과 비교하는 API 모니터를 생성한다. 여기에서, 문장 블록은 문맥 전환의 단위이며, 문장 블록이 실행된 후 제어 흐름(control flow)이 다른 태스크로 전환될 수 있고, 문장 블록이 API 함수를 호출하는 간단한 문장이 된다.
이때, API 모니터는 문장 블록의 API 호출을 응용 프로그램의 API 호출과 비교하여 동일하지 않은 경우, 실행 가능한 경로의 검증 대상에서 제외할 수 있다.
주석첨가부(140)는 응용 프로그램의 실행에 따른 문맥 전환 위치를 주석첨가(annotate)하여 주석첨가된 어플리케이션을 생성한다.
이때, API 호출을 통해 태스크 생성 및 종료, 리소스 해제, 이벤트 대기 및 발생 시 문맥 전환이 발생할 수 있다. 이는 모든 태스크는 API를 통해 태스크 생성과 종료를 수행하게 되며, 리소스 할당 또는 해제 API와, 이벤트(event) 대기 또는 발생 API를 호출함으로써, 동기화를 수행하고, 운영 체제는 이들을 모두 고려하여 실행 태스크를 선정하기 때문이다.
또한, 응용 프로그램의 실행 중에 문맥 전환 위치를 만나면 프로그램 카운터를 저장하고, 문맥 전환 후 재실행될 경우에 상기 저장된 프로그램 카운터를 이용하여 실행 위치로 복귀할 수 있다.
검증부(150)는 테스트 드라이버(Test driver), API 모니터(API monitor), 주석첨가된 어플리케이션(Annotated Application)을 이용하여 응용 프로그램의 실행 가능한 경로를 검증한다.
여기에서, 검증부(150)는 모델 검증 도구 CBMC를 이용하여 검증할 수 있다. 즉, 테스트 드라이버(Test driver), API 모니터(API monitor), 주석첨가된 어플리케이션(Annotated Application)를 CBMC(C Bounded Model Checker)에 입력하여 실행 가능한 경로를 검증할 수 있다. 특히, 검증부(150)는 CBMC를 사용하여 C 프로그램 내에 존재하는 assert 속성 위반 등을 검증할 수 있다.
또한, 검증부(150)는 응용 프로그램에서 반례와 동일한 순서로 API 호출을 수행하는 실행 경로의 존재 유무를 검증할 수 있다.
보고부(160)는 응용 프로그램의 실행 가능성을 확인하여 보고한다. 예를 들어, 실행 경로가 존재할 경우, 실행 경로와 함께 assert 속성 위반이 보고되고, 실행 경로가 존재하지 않을 경우 assert 속성 준수가 보고될 수 있다.
한편, 본 발명의 일 실시예에 따른 응용 프로그램의 실행 가능성 확인 방법 및 장치는 소프트웨어, 펌웨어, 하드웨어 중 적어도 하나에 의해 하나의 모듈로 구현 가능하며, 전술한 본 발명의 실시예들은 컴퓨터에서 실행될 수 있는 프로그램으로 작성 가능하고, 컴퓨터로 읽을 수 있는 기록매체를 이용하여 상기 프로그램을 동작시키는 범용 컴퓨터에서 구현될 수 있다. 상기 컴퓨터로 읽을 수 있는 기록매체는 롬(ROM), 플로피 디스크, 하드 디스크 등의 자기적 매체, CD, DVD 등의 광학적 매체이다. 또한, 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어 분산 방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
이상 첨부된 도면을 참조하여 본 발명의 실시예를 설명하였지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다.
100: 응용 프로그램의 실행 가능성 확인 장치
110: 모델 생성부
120: 드라이버부
130: 모니터링부
140: 주석첨가부
150: 검증부
160: 보고부

Claims (21)

  1. 모델 생성부에 의해 응용 프로그램의 어플리케이션 모델 및 운영체제 모델을 통합하여 실행 시나리오 모델을 생성하는 단계;
    드라이버부에 의해 상기 실행 시나리오 모델에서 태스크 실행 순서를 도출하는 단계;
    모니터링부에 의해 상기 실행 시나리오 모델에서 문장 블록을 도출하는 단계;
    주석첨가부에 의해 상기 응용 프로그램의 실행에 따른 문맥 전환 위치를 주석첨가(annotate)하는 단계;
    검증부에 의해 상기 태스크 실행 순서 및 상기 문장 블록과, 상기 문맥 전환 위치를 기초로 상기 응용 프로그램의 실행 가능한 경로를 검증하는 단계; 및
    보고부에 의해 상기 응용 프로그램의 실행 가능성을 확인하여 보고하는 단계를 포함하는, 응용 프로그램의 실행 가능성 확인 방법.
  2. 제 1항에 있어서,
    상기 실행 시나리오 모델을 생성하는 단계는,
    상기 모델 생성부에 의해 모델 검증 도구 NuSMV를 이용하여 반례를 생성하는 단계를 포함하는, 응용 프로그램의 실행 가능성 확인 방법.
  3. 제 2항에 있어서,
    상기 반례를 생성하는 단계는,
    상기 모델 생성부에 의해 상기 응용 프로그램의 태스크 스케줄링 정보 및 제어 흐름을 포함하는 상기 반례를 생성하는 단계를 포함하는, 응용 프로그램의 실행 가능성 확인 방법.
  4. 제 2항에 있어서,
    상기 반례를 생성하는 단계는,
    상기 모델 생성부에 의해 API 호출 제약사항 준수 여부를 확인하여 상기 반례를 생성하는 단계를 포함하는, 응용 프로그램의 실행 가능성 확인 방법.
  5. 제 1항에 있어서,
    상기 태스크 실행 순서를 도출하는 단계는,
    상기 드라이버부에 의해 상기 태스크 실행 순서에 따라 각 태스크를 순서대로 호출하는 테스트 드라이버를 구현하는 단계를 더 포함하는, 응용 프로그램의 실행 가능성 확인 방법.
  6. 제 1항에 있어서,
    상기 문장 블록을 도출하는 단계는,
    상기 모니터링부에 의해 API 호출을 상기 문장 블록으로 도출하는 단계를 포함하는, 응용 프로그램의 실행 가능성 확인 방법.
  7. 제 6항에 있어서,
    상기 모니터링부에 의해 상기 문장 블록의 API 호출을 상기 응용 프로그램의 API 호출과 비교하는 단계를 더 포함하는, 응용 프로그램의 실행 가능성 확인 방법.
  8. 제 1항에 있어서,
    상기 문맥 전환 위치를 주석첨가(annotate)하는 단계는,
    상기 주석첨가부에 의해 API 호출을 통해 태스크 생성 및 종료, 리소스 해제, 이벤트 대기 및 발생 시 문맥 전환이 발생하는 단계를 포함하는, 응용 프로그램의 실행 가능성 확인 방법.
  9. 제 1항에 있어서,
    상기 주석첨가부에 의해 상기 응용 프로그램의 실행 중에 상기 문맥 전환 위치를 만나면 프로그램 카운터를 저장하고, 문맥 전환 후 재실행될 경우에 상기 저장된 프로그램 카운터를 이용하여 실행 위치로 복귀하는 단계를 더 포함하는, 응용 프로그램의 실행 가능성 확인 방법.
  10. 제 1항에 있어서,
    상기 실행 가능한 경로를 검증하는 단계는,
    상기 검증부에 의해 모델 검증 도구 CBMC를 이용하여 검증하는 단계를 포함하는, 응용 프로그램의 실행 가능성 확인 방법.
  11. 제 10항에 있어서,
    상기 실행 가능한 경로를 검증하는 단계는,
    상기 검증부에 의해 상기 응용 프로그램에서 반례와 동일한 순서로 API 호출을 수행하는 실행 경로의 존재 유무를 검증하는 단계를 포함하는, 응용 프로그램의 실행 가능성 확인 방법.
  12. 응용 프로그램의 어플리케이션 모델 및 운영체제 모델을 통합하여 실행 시나리오 모델을 생성하는 모델 생성부;
    상기 실행 시나리오 모델에서 태스크 실행 순서를 도출하며, 상기 태스크 실행 순서에 따라 각 태스크를 순서대로 호출하는 테스트 드라이버를 생성하는 드라이버부;
    상기 실행 시나리오 모델에서 문장 블록을 도출하며, 상기 문장 블록의 API 호출을 상기 응용 프로그램의 API 호출과 비교하는 API 모니터를 생성하는 모니터링부;
    상기 응용 프로그램의 실행에 따른 문맥 전환 위치를 주석첨가(annotate)하여 주석첨가된 어플리케이션을 생성하는 주석첨가부;
    상기 테스트 드라이버, 상기 API 모니터, 상기 주석첨가된 어플리케이션을 이용하여 상기 응용 프로그램의 실행 가능한 경로를 검증하는 검증부; 및
    상기 응용 프로그램의 실행 가능성을 확인하여 보고하는 보고부를 포함하는, 응용 프로그램의 실행 가능성 확인 장치.
  13. 제 12항에 있어서,
    상기 모델 생성부는,
    모델 검증 도구 NuSMV를 이용하여 반례를 생성하는, 응용 프로그램의 실행 가능성 확인 장치.
  14. 제 13항에 있어서,
    상기 모델 생성부는,
    상기 응용 프로그램의 태스크 스케줄링 정보 및 제어 흐름을 포함하는 상기 반례를 생성하는, 응용 프로그램의 실행 가능성 확인 장치.
  15. 제 13항에 있어서,
    상기 모델 생성부는,
    API 호출 제약사항 준수 여부를 확인하여 상기 반례를 생성하는, 응용 프로그램의 실행 가능성 확인 장치.
  16. 제 12항에 있어서,
    상기 드라이버부는,
    반례에 나타난 태스크 실행 순서를 이용하여 상기 테스트 드라이버를 생성하는, 응용 프로그램의 실행 가능성 확인 장치.
  17. 제 12항에 있어서,
    상기 모니터링부는,
    상기 문장 블록의 API 호출을 상기 응용 프로그램의 API 호출과 비교하여 동일하지 않은 경우, 실행 가능한 경로의 검증 대상에서 제외하는, 응용 프로그램의 실행 가능성 확인 장치.
  18. 제 12항에 있어서,
    상기 주석첨가부는,
    API 호출을 통해 태스크 생성 및 종료, 리소스 해제, 이벤트 대기 및 발생 시 문맥 전환이 발생하는, 응용 프로그램의 실행 가능성 확인 장치.
  19. 제 12항에 있어서,
    상기 검증부는,
    모델 검증 도구 CBMC를 이용하여 검증하는, 응용 프로그램의 실행 가능성 확인 장치.
  20. 제 19항에 있어서,
    상기 검증부는,
    상기 응용 프로그램에서 반례와 동일한 순서로 API 호출을 수행하는 실행 경로의 존재 유무를 검증하는, 응용 프로그램의 실행 가능성 확인 장치.
  21. 제 1항 내지 제 11항 중 어느 한 항의 방법을 구현하기 위한 프로그램이 기록된 컴퓨터로 판독 가능한 비 일시적 기록매체.
KR1020200100016A 2020-03-06 2020-08-10 응용 프로그램의 실행 가능성 확인 방법 및 장치, 그리고 이를 구현하기 위한 프로그램이 기록된 기록매체 KR102348691B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020200028196 2020-03-06
KR20200028196 2020-03-06

Publications (2)

Publication Number Publication Date
KR20210112989A KR20210112989A (ko) 2021-09-15
KR102348691B1 true KR102348691B1 (ko) 2022-01-11

Family

ID=77793433

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020200100016A KR102348691B1 (ko) 2020-03-06 2020-08-10 응용 프로그램의 실행 가능성 확인 방법 및 장치, 그리고 이를 구현하기 위한 프로그램이 기록된 기록매체

Country Status (1)

Country Link
KR (1) KR102348691B1 (ko)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014016752A (ja) 2012-07-09 2014-01-30 Toyota Central R&D Labs Inc 検証装置、検証方法、検証プログラム
KR101701800B1 (ko) 2015-10-27 2017-02-02 경북대학교 산학협력단 차량 전장용 제어 소프트웨어를 위한 타스크 작동순서 가시화 방법, 이를 수행하기 위한 기록 매체 및 장치

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100988395B1 (ko) 2003-02-18 2010-10-18 마이크로소프트 코포레이션 태스크 스케줄링 방법, 태스크 스케줄링 지원 장치, 코프로세싱 스케줄러에 관련하여 사용하기 위한 코프로세서, 및 컴퓨터 판독가능 저장 매체
KR101439355B1 (ko) * 2012-11-13 2014-09-11 재단법인대구경북과학기술원 차량용 실시간 운영체제의 스케줄링 방법, 차량용 실시간 운영체제의 스케줄링 방법을 수행하는 프로세서를 포함하는 차량의 전자 제어 장치, 및 차량용 실시간 운영체제의 스케줄링 방법을 수행하는 프로그램이 기록된 컴퓨터 판독가능한 기록매체
KR101548364B1 (ko) 2014-10-22 2015-08-28 경북대학교 산학협력단 Api 호출 정당성의 자동검증 방법, 이를 수행하기 위한 기록 매체 및 장치
KR101926933B1 (ko) 2016-12-09 2018-12-07 경북대학교 산학협력단 C 언어 기반 내장형 소프트웨어 운영체제 모델링 방법, 이를 수행하기 위한 기록 매체 및 장치

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014016752A (ja) 2012-07-09 2014-01-30 Toyota Central R&D Labs Inc 検証装置、検証方法、検証プログラム
KR101701800B1 (ko) 2015-10-27 2017-02-02 경북대학교 산학협력단 차량 전장용 제어 소프트웨어를 위한 타스크 작동순서 가시화 방법, 이를 수행하기 위한 기록 매체 및 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
논문1(2018.04.09)

Also Published As

Publication number Publication date
KR20210112989A (ko) 2021-09-15

Similar Documents

Publication Publication Date Title
JP6607565B2 (ja) セーフティクリティカルソフトウェアのための統合された自動テストケース生成
CN108509336B (zh) 一种操作系统规范形式化验证与测试方法
US8726225B2 (en) Testing of a software system using instrumentation at a logging module
CN110633206A (zh) 用于基于等价类分析的基于自动化要求的测试用例生成的系统和方法
US9152389B2 (en) Trace generating unit, system, and program of the same
US10943041B2 (en) Electronic system level parallel simulation method with detection of conflicts of access to a shared memory
US10592703B1 (en) Method and system for processing verification tests for testing a design under test
Sun et al. A pre-order relation for exact schedulability test of sporadic tasks on multiprocessor Global Fixed-Priority scheduling
US20230342198A1 (en) Method for reproducible parallel simulation at electronic system level implemented by means of a multi-core discrete-event simulation computer system
JP2015219906A (ja) ソフトウェア確認方法およびプロセッサ
US20140278334A1 (en) Method to verify correctness of computer system software and hardware components and corresponding test environment
US11586976B2 (en) Method and apparatus for creating tests for execution in a storage environment
KR102348691B1 (ko) 응용 프로그램의 실행 가능성 확인 방법 및 장치, 그리고 이를 구현하기 위한 프로그램이 기록된 기록매체
KR101701800B1 (ko) 차량 전장용 제어 소프트웨어를 위한 타스크 작동순서 가시화 방법, 이를 수행하기 위한 기록 매체 및 장치
Vu et al. Verifying OSEK/VDX OS design using its formal specification
de Oliveira et al. Automata-based modeling of interrupts in the Linux PREEMPT RT kernel
Yatake et al. Model checking of OSEK/VDX OS design model based on environment modeling
US7346484B2 (en) Monitor manager that creates and executes state machine-based monitor instances in a digital simulation
Hofer et al. Gui savvy end-to-end testing with smart monkeys
Park et al. Property-based code slicing for efficient verification of osek/vdx operating systems
dos Santos et al. Runtime monitoring of behavioral properties in dynamically adaptive systems
Nhat-Hoa et al. Sspinja: Facilitating schedulers in model checking
KR102471537B1 (ko) 내장형 제어 프로그램의 검증 방법 및 그 장치
Gotovos Dynamic systematic testing of concurrent Erlang programs
CN112380108B (zh) 一种面向分区空间隔离的全自动测试方法

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant