KR102102599B1 - 사물인터넷 디바이스의 제어 소프트웨어 검증 장치 및 그 방법 - Google Patents

Abstract

본 발명의 일 실시예에 따른 사물인터넷 디바이스의 제어 소프트웨어 검증 방법은 검증 대상 소프트웨어의 운영체제 모델을 생성하는 단계, 상기 검증 대상 소프트웨어에 대한 어플리케이션 모델을 생성하는 단계 및 상기 운영체제 모델과 상기 어플리케이션 모델을 포함하는 상호작용 모델을 생성하는 단계를 포함한다.

Description

사물인터넷 디바이스의 제어 소프트웨어 검증 장치 및 그 방법{APPARATUS FOR VERIFICATION OF IoT DEVICE CONTROL SOFTWARE AND VERIFICATION METHOD THEREOF}

본 발명은 사물인터넷 디바이스의 제어 소프트웨어 검증 장치 및 그 방법에 관한 것으로 보다 상세하게는 상호작용 모델을 이용하여 제어 소프트웨어를 검증하는 사물인터넷 디바이스의 제어 소프트웨어 검증 장치 및 그 방법에 관한 것이다.

센서 및 액추에이터와 같은 단순한 장치에서부터 자동차, 무인기 및 가전 제품과 같은 복잡한 기계에 이르기까지 일상 생활의 모든 것을 연결하는 사물인터넷 시스템 시대에서 각 디바이스 컨트롤러의 품질 보증의 중요성이 지속적으로 증가하고 있다.

이에 따라 안전성이 중요한 시스템을 대상으로 하여 임베디드 제어 소프트웨어의 검증에 관해 활발한 연구가 진행되고 있다. 시스템의 오류가 안전에 치명적 결과를 초래할 수 있는 점을 고려해보면 엄격하고 효과적인 검증 방법과 도구는 더할 나위 없이 중요하다고 할 수 있다. 중요한 점은 전체 사물인터넷 시스템의 올바른 동작은 해당 시스템을 구성하는 각 디바이스(contributing device)의 검증 없이는 보장 될 수 없다는 것이다.

사물인터넷 디바이스의 검증을 위해 여러 방법들이 제안되었다. 공식적인 모델링과 형식적 검증, 모델 기반 테스트 생성, 모델 기반 코드 생성 등으로 대표된다. 그럼에도 불구하고, 기존의 접근 방법은 다음과 같은 이유로 사물인터넷 디바이스의 제어 소프트웨어를 효과적으로 검증하기가 어렵다.

첫째, 일반적으로 소규모 제어 소프트웨어는 그 운영체제와 분리할 수 없는 것임에도 불구하고 해당 운영 체제를 일반적으로 고려하지 않는다.

둘째, 각 디바이스 컨트롤러의 모델 구축에는 도메인 및 모델링 전문가가 필요하며 셋째, 제어 소프트웨어에 대한 엄격하고 포괄적인 검증에는 해당 분야에서 공식적인 검증 기술과 전문가를 필요로 한다. 이 분야의 전문가는 실제로는 매우 드문 실정이며 사물인터넷 시스템에 포함될 수 있는 수백 가지 장치에 수동 모델링 및 검증을 적용하는 것은 많은 시간이 소요되고 비실용적이다.

본 발명은 전술한 문제점을 해결하기 위해 안출된 것으로서 사물 인터넷 디바이스의 제어 소프트웨어 운영체제를 고려하여 검증을 위한 모델을 자동으로 생성하는 검증 장치 및 그 방법을 제공하는데 목적이 있다.

본 발명의 일 실시예에 따른 사물인터넷 디바이스의 제어 소프트웨어 검증 방법은 검증 대상 소프트웨어의 운영체제 모델을 생성하는 단계, 상기 검증 대상 소프트웨어에 대한 어플리케이션 모델을 생성하는 단계 및 상기 운영체제 모델과 상기 어플리케이션 모델을 포함하는 상호작용 모델을 생성하는 단계를 포함한다.

상기 운영체제 모델을 생성하는 단계는 상기 검증 대상 소프트웨어의 구조에 따라 커널 변수, API 함수, 기본 동작, 알람 및 ISR(Interrupt Service Routine)에 관해 기 정의된 패턴을 이용하여 생성하는 것을 특징으로 한다.

상기 어플리케이션 모델을 생성하는 단계는 상기 검증 대상 소프트웨어를 복수의 노드로 구분하는 단계 및 상기 운영체제 모델의 API 함수 호출 여부를 상기 복수의 노드에 대해 각각 체크하는 단계를 포함하는 것을 특징으로 한다.

상기 상호작용 모델을 생성하는 단계는 상기 운영체제 모델과 상기 어플리케이션 모델의 상호작용 지점을 파악하는 단계 및 상기 상호작용 지점을 기준으로 상기 운영체제 모델과 상기 어플리케이션 모델을 하나의 모델에 삽입하는 단계를 포함하는 것을 특징으로 한다.

상기 하나의 모델에 삽입하는 단계는 상기 어플리케이션 모델을 상기 상호작용 지점을 기준으로 변환하여 삽입하며 상기 어플리케이션 모델에서 상기 운영체제 모델의 API 함수를 호출하지 않는 부분은 변환 없이 그대로 삽입하는 것을 특징으로 한다.

본 발명의 다른 실시예에 따른 사물인터넷 디바이스의 제어 소프트웨어 검증 장치는 검증 대상 소프트웨어의 운영체제 모델을 생성하는 운영체제 모델 생성부, 상기 검증 대상 소프트웨어에 대한 어플리케이션 모델을 생성하는 어플리케이션 모델 생성부, 상기 운영체제 모델과 상기 어플리케이션 모델을 포함하는 상호작용 모델을 생성하는 상호작용 모델 생성부 및 상기 상호작용 모델을 이용하여 상기 검증 대상 소프트웨어의 유효성을 검증하는 검증부를 포함한다.

상기 운영체제 모델 생성부는 상기 검증 대상 소프트웨어의 구조에 따라 커널 변수, API 함수, 기본 동작, 알람 및 ISR(Interrupt Service Routine)에 관해 기 정의된 패턴을 이용하여 생성한다.

상기 커널 변수는 우선순위 대기열, 작업의 정적 정보, 작업의 동적 정보, 자원 테이블 및 이벤트 테이블에 관한 정보 중 적어도 하나를 포함하는 것을 특징으로 한다.

상기 어플리케이션 모델 생성부는 상기 검증 대상 소프트웨어를 복수의 노드로 구분하고 상기 운영체제 모델의 API 함수 호출 여부를 상기 복수의 노드에 대해 각각 체크 후, 상기 API 함수를 호출하지 않는 노드는 하나의 노드로 병합하여 상기 어플리케이션 모델을 생성하는 것을 특징으로 한다.

상기 상호작용 모델 생성부는 상호작용 지점을 파악한 후 이를 기준으로 상기 운영체제 모델과 상기 어플리케이션 모델을 하나의 모델에 삽입하며 상기 하나의 모델에 삽입함에 있어서, 상기 운영체제 모델과 상기 어플리케이션 모델간 상호작용 지점을 기준으로 변환하여 삽입하고 상기 어플리케이션 모델에서 상기 운영체제 모델의 API 함수를 호출하지 않는 부분은 변환 없이 그대로 삽입하여 상기 상호작용 모델을 생성하는 것을 특징으로 한다.

상기 검증부는 상기 상호작용 모델과 상기 검증 대상 소프트웨어에서 예상되는 작업 실행 순서를 지정하는 속성 목록을 이용하여 유효성을 검증하는 것을 특징으로 한다.

본 발명은 운영체제 모델과 어플리케이션 모델을 자동으로 생성하여 상호작용 모델에 삽입함으로써 검증에 소요되는 시간이 감소된다.

또한 본 발명은 상호작용 모델을 통해 제어 소프트웨어와 운영체제간 상호작용도 함께 고려하므로 소프트웨어를 더 철저히 검증할 수 있다.

또한 본 발명은 어플리케이션 모델을 상호작용 모델에 삽입함에 있어 상호작용 지점을 기준으로 추상화 후 삽입하므로 검증에 소요되는 시간과 비용이 감소되고 검증의 정확도를 높일 수 있다.

도 1은 사물인터넷 디바이스의 제어 소프트웨어 구성을 설명하기 위한 도면이다.
도 2은 본 발명의 일 실시예에 따른 사물인터넷 디바이스의 제어 소프트웨어 검증 방법의 흐름도이다.
도 3은 본 발명의 일 실시예에 따른 상호작용 모델을 도시한 도면이다.
도 4는 본 발명의 일 실시예에 따른 어플리케이션 모델 생성을 설명하기 위한 도면이다.
도 5는 본 발명의 일 실시예에 따라 상호작용 모델 생성을 설명하기 위한 도면이다.
도 6는 본 발명의 다른 실시예에 따른 사물인터넷 디바이스의 제어 소프트웨어 검증 장치 구성을 도시한 도면이다.

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

각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용한다. 제 1, 제 2등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다.

예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제 1 구성요소는 제 2 구성요소로 명명될 수 있고, 유사하게 제 2 구성요소도 제 1 구성요소로 명명될 수 있다. "및/또는" 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미가 있다.

일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미가 있는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않아야 한다.

이하 첨부된 도면을 참조하여 본 발명의 일 실시예에 따른 사물인터넷 디바이스 제어 소프트웨어 검증 장치 및 그 방법을 상세하게 설명하기로 한다.

도 1은 사물인터넷 디바이스의 제어 소프트웨어 구성을 설명하기 위한 도면이다.

사물인터넷 디바이스의 제어 소프트웨어는 일반적으로 운영 체제 위에서 실행된다. 사물인터넷 디바이스가 일반적으로 요구하는 전형적인 서비스 세트는 작업 관리, 자원 관리, 이벤트 관리, 알람 관리, 인터럽트 처리 및 작업 스케줄링을 위한 서비스를 포함한다. Contiki, RIOT, FreeRTOS, Zephyr 및 Erika는 소규모 사물인터넷 디바이스에 특화된 대표적인 운영체제이다.

제어 소프트웨어의 생성에 있어 운영체제는 분리할 수 없는 요소이다.

도 1을 참조하면, 제어 소프트웨어는 그 구조(application configuration)에 따라 선택된 운영 체제 서비스의 하위 집합(P1)과 요구되는 서비스를 결정하는 어플리케이션 소스코드(P2)가 함께 컴파일되어 생성된다. 따라서 제어 소프트웨어의 유효성 검사는 운영 체제 서비스와 운영 체제와 응용 프로그램 간의 상호작용 방식을 고려해야 한다.

도 2는 본 발명의 일 실시예에 따른 사물인터넷 디바이스의 제어 소프트웨어 검증 방법의 흐름도이다.

도 2를 참조하면, 본 발명의 일 실시예에 따른 사물인터넷 디바이스의 제어 소프트웨어 검증 방법은 운영체제 모델 생성 단계(S100), 어플리케이션 모델 생성 단계(S200) 및 상호작용 모델 생성 단계(S300)를 포함한다.

S100 단계에서, 검증 대상 소프트웨어의 운영체제 모델을 생성한다. 상기 검증 대상 소프트웨어는 사물인터넷 디바이스의 제어 소프트웨어를 의미하나 이에 한정되지 않으며 소규모 제어 소프트웨어를 포함한다.

구체적으로 S100 단계에서 검증 대상 소프트웨어의 운영체제 구조에 따른 정형적 패턴을 기반으로 운영체제 모델을 생성한다.

상기 정형적 패턴에는 커널 변수(kernel variable), 기본적인 동작(basic operation), 기본 API 함수(Basic Application Programming Interface function), 알람(Alarm) 및 ISR(Interrupt Service Routine)에 관한 패턴을 포함한다.

상기 정형적 패턴은 가장 작은 운영체제(minimal OS)를 위한 서비스 패턴으로서 우선순위 기반 FIFO 스케쥴링(priority based First In First Out scheduling), 리소스 우선순위 상한 프로토콜(Resource Priority Ceiling Protocol)을 따른다. 우선순위 상한 프로토콜에서 각 자원에는 자원을 잠글 수 있는 모든 작업의 가장 높은 우선 순위와 동일한 우선 순위 상한이 지정된다.

작업(task)과 ISR의 정적동적 우선순위에 관한 정보를 유지하기 위해, 상기 정형적 패턴은 커널 변수(kernel variable)로서 다음과 같은 데이터 구조들을 포함한다.

1. 우선순위 대기열(A priority queue): 식별자와 우선순위를 포함하는 2차원의 배열로 정의될 수 있다.

2. 작업의 정적 구성(Static configuration of tasks): 작업의 정적 정보를 담은 배열로서 초기 작업 우선순위(initial task priority)와 불린 값들(Boolean values)로 구성된다. 상기 불린 값은 작업의 선점가능여부, 자동시작 여부 및 연장가능 여부를 나타낸다.

3. 동적 작업 정보(Dynamic task information): 동적 작업 정보를 담은 배열로서 현재 활성화 수(the number of current activation) 및 작업의 동적 우선 순위(dynamic priority of a task)를 포함한다.

4. 자원 테이블(Resource table): 자원을 사용하는 작업에 대해 자원을 매핑하는 2차원의 배열로 정의될 수 있다.

5. 이벤트 테이블(Event table): 어떤 작업이 설정되거나 대기하여야 하는 지에 관한 이벤트에 대해 작업을 매핑하는 2차원의 배열로 정의될 수 있다.

기본 동작(basic operations)은 모든 운영체제에서 공통적으로 사용되는 것으로서 우선순위 대기열(priority queue)을 사용하는 것을 말한다. 구체적으로 상기 우선순위 대기열에 작업을 넣거나, 작업의 정보를 상기 우선순위 대기열로부터 얻는 것을 포함한다.

운영체제는 어플리케이션 프로그램이 자신의 특정 작업을 수행할 수 있도록 하기 위해 API 함수 세트를 제공한다. 이러한 관점에서 운영체제는 기본 API함수의 세트로서 정의될 수 있으며, 운영체제 모델에서 기본 API함수는 인라인함수(inline function)로 모델링 되었다.

인라인 함수란 컴파일된 함수 코드가 프로그램 코드 안에 직접 삽입되는 것을 말한다. 일반 함수는 호출 시 해당 함수의 주소로 점프하였다가 함수가 종료되면 다시 원래의 자리로 돌아오게 된다. 빈번하게 사용되는 함수를 인라인 함수로 선언하는 경우 해당 함수의 주소를 찾아 점프할 필요가 없으므로 수행 속도 면에서 이점을 갖는다.

기본 API함수를 하기와 같이 표로 정리하였다.

API함수	용도(usage)
ActivateTask(t)	작업 t의 활성화 (Request for the activation of task t)
TerminateTask()	작업 종료 (Request for the termination of it-self)
ChainTask(t)	작업 t를 활성화 후 작업 종료 (Request for the activation of task t and the termination of itself)
GetResource(r)	자원 r 할당 (Request for an allocation of resource r)
ReleaseResource(r)	자원 r 반환 (Request for deallocation of resource r)
WaitEvent(e)	이벤트 e 대기 (Waiting for event e)
SetEvent(t,e)	작업 t에 대해 이벤트 e 설정 (Setting for an event e for task t)
Schedule()	리스케쥴링 (Request for rescheduling)

표 1에서 API 함수의 이름(Name of API function)은 운영체제마다 다를 수 있으나 사물인터넷 디바이스에 특화된 대부분의 운영체제는 다른 이름으로 동일한 기능을 제공한다. 따라서 GetResource 등과 같이 API 함수의 구체적인 이름은 그 기능을 지칭하기 위한 예시적인 것이다.알람(alarm)은 주기적으로 작업을 수행하거나 이벤트를 설정하는 데 사용되나 그 자신의 제어 로직(control logic on its own)은 포함하지 않는다. 자체 우선 순위가 없으며 스케줄러에 의해 예약되지 않으므로 작업을 수행하기 위해 우선 순위 대기열을 통과하지 않는다. 따라서 S100 단계에서는 운영체제 모델의 알람을 작업 매니저(task manager)나 스케줄러에 의해 관리되고 예약되어야 하는 작업의 일종이 아니라 독립적인 프로세스로서 모델링 한다.

알람이 운영체제의 시작과 함께 자동으로 실행되는 지 여부는 해당 운영체제 알람의 구조에 따른다. 해당 알람이 주기마다 수행하여야 하는 행동은 운영체제 모델을 생성하는 과정에서 수치화되며 그 구체적인 값은 검증 대상 소프트웨어의 운영체제 구조에 의해 결정된다.

ISR(Interrupt Service Routine)은 운영체제 모델 생성 시, 작업의 일종(a kind of task)으로 모델링된다. ISR과 작업은 유사한 특성을 공유하고 있다. 구체적으로 어플리케이션 로직(application logic)을 포함하고, 자체 우선순위를 가지며, 예약될 수 있다. ISR과 작업간 주요 차이점은 작업이 스케쥴러에 의해 결정된 작업 실행 순서에 따라 실행되는 반면, ISR은 외부 신호에 의해 실행된다는 점이다.

S100 단계를 통해 생성된 운영체제 모델에서, 작업과 ISR은 검증 대상 소프트웨어로부터 생성된 어플리케이션 모델에 속하는 것이므로 미리 정의되어 있지 않다.

S200 단계에서 검증 대상 소프트웨어로부터 어플리케이션 모델을 생성한다.

구체적으로 S200 단계에서 API 함수를 호출하지 않는 부분(code block)과 API 함수를 호출하는 부분을 파악하기 위해 제어 흐름 분석(Control Flow Graph analysis)을 수행한다.

제어 흐름 분석(Control Flow Graph analysis)을 통해 검증 대상 소프트웨어가 추상화된다. 상기 제어 흐름 분석은 검증 대상 소프트웨어를 복수의 노드로 나누는 단계 및 상기 복수의 노드 중 API 함수 호출 여부를 체크하는 단계를 포함한다.

상기 API 함수 호출 여부를 체크하는 단계는 구체적으로 상기 복수의 노드 중 API 함수 호출을 포함하지 않는 연속적인 노드들을 하나의 노드로 병합하여 코드 임베딩에 관한 주석을 추가하는 단계 및 상기 복수의 노드 중 API 함수 호출을 포함하는 노드는 상호작용 지점임을 의미하는 주석을 추가하는 단계를 포함한다.

병합된 하나의 노드는 코드 임베딩을 위한 유닛(the unit of code embedding), 즉 상호작용 모델에 삽입을 위한 한 단위로 주석처리 된다.

S300 단계에서 운영체제 모델과 어플리케이션 모델을 포함하는 상호작용 모델을 생성한다.

구체적으로 S300 단계는 검증 대상 소프트웨어(어플리케이션 모델)와 해당 운영체제(운영체제 모델)간 상호작용 지점을 파악하는 단계 및 상기 상호작용 지점을 기준으로 상기 운영체제 모델과 상기 어플리케이션 모델을 하나의 모델에 삽입하는 단계를 포함한다.

상호작용 지점이란 검증 대상 소프트웨어(어플리케이션 모델)가 자신의 운영체제(운영체제 모델) API함수를 호출하는 지점을 의미한다. 즉, 상기 검증 대상 소프트웨어에서 자신의 운영체제가 제공하는 API 함수를 호출하는 지점으로서 서비스의 요청을 보내고 그 요청에 따른 결과를 받는 지점을 의미한다.

상기 상호작용 지점을 파악하는 단계에서, 어플리케이션 모델이 생성될 때 API함수를 호출하는 노드와 그렇지 않은 (병합된)노드가 각각 주석처리 되어 있으므로 이를 이용하여 상호작용 지점을 파악한다.

상기 하나의 모델에 삽입하는 단계에서, 기 생성된 운영체제 모델과 어플리케이션 모델을 삽입한다. 구체적으로 기 파악된 상호작용 지점을 기준으로 운영체제 모델과 어플리케이션 모델을 삽입한다.

어플리케이션 모델의 경우, API함수를 호출하지 않는 노드는 문법적인 변환 없이 그대로 삽입하고, API함수를 호출하는 상호작용 지점의 노드는 상호작용 모델에서의 검증을 위해 필요한 형태로 변환하여 삽입한다.

상기와 같이 검증 대상 소프트웨어에 대하여 자동으로 생성된 상호작용 모델을 이용하여 검증 대상 소프트웨어의 유효성 검사를 수행하게 된다.

상기 유효성 검사와 관련, 주기적인 알람 및 인터럽트가 있을 때 검증 대상 소프트웨어가 어떻게 작동 하는지 확신하기 어려우며 시뮬레이션은 유효성을 확인하는 중요한 수단이나 포괄적이고 광범위하게 검증을 하기에는 부족하다.

검증 대상 소프트웨어의 동작을 보다 포괄적이며 자동으로 검증하기 위해 상기 검증 대상 소프트웨어에서 예상되는 작업 실행 순서를 지정하는 속성 목록(list of properties)을 이용한다. 구체적으로 생성된 상호작용 모델을 이용하여 상기 검사를 수행함에 있어, 해당 속성을 만족하는지 검증한다.

상기 속성 목록에서 일부 속성은 여러 응용 프로그램의 상호 배타성을 보장하는 속성이나 교착 상태 방지(deadlock-freeness)에 대한 속성과 같이 모든 제어 소프트웨어에서 공통적으로 사용된다. 또 다른 일부 속성은 각 제어 프로그램이 고유한 작업 실행 순서를 가지고 있으므로 검증 대상 소프트웨어에 따라 달라진다.

상기 속성 목록의 일 예(S1 내지 S6)를 아래와 같이 표 2에 정리하였다.

속성	내용
S1	Task1과 Task2는 동시에 실행되지 않음(Task1 and Task2 shall not run at the same time)
S2	실행중인 작업은 결국 종료됨(Running tasks shall terminate in the end)
S3	작업의 활성화 횟수는 지정된 최대 활성화 횟수를 초과하지 않음(The number of activation of a task shall not exceed the specified maximum number of activation count of the task)
S4	일단 작업이 활성화되면 그 제어는 메인 함수로 돌아가지 않음(Once tasks are activated, the control shall never return to the main function)
S5	Task 1은 항상 해당 ISR에서 처리하는 인터럽트를 트리거함(Task1 always triggers the interrupt handled by its corresponding ISR)
S6	ISR을 활성화하면 Task2를 활성화하는 주기적인 알람이 항상 트리거됨(Activation of the ISR always triggers the periodic alarm which activates Task2)

표 2를 참조하면, S1 내지 S3은 모든 제어 소프트웨어에서 만족되어야만 하는 공통적인 속성이다. S4 내지 S6은 특정 제어 소프트웨어에서 만족되어야 하는 속성이다. 표 2에 나열된 속성목록의 개수와 내용은 그 예시로서, 검증 대상 소프트웨어의 유효성 검증을 위해 다른 내용을 가지는 8개 이상 10개 이하의 속성 목록이 사용될 수 있다. 상기와 같이 본 발명의 일 실시예에 따른 사물인터넷 디바이스의 제어 소프트웨어 검증 방법에 의하면 운영체제 모델 어플리케이션 모델을 자동으로 생성하여 상호작용 모델에 삽입함으로써 검증에 소요되는 시간이 감소된다.

또한 상호작용 모델을 통해 제어 소프트웨어와 운영체제간 상호작용도 함께 고려하므로 소프트웨어를 더 철저히 검증할 수 있다.

또한 어플리케이션 모델을 상호작용 모델에 삽입함에 있어 상호작용 지점을 기준으로 추상화 후 삽입하므로 검증에 소요되는 시간과 비용이 감소되고 추상화 전 후 상호작용 동작이 유지되어 검증의 정확도를 높일 수 있다.

도 3은 본 발명의 일 실시예에 따른 상호작용 모델을 도시한 도면이다.

도 3을 참조하면, 상호작용 모델(M)에는 상호작용 지점(M12)과 API handler를 기준으로 어플리케이션 모델(M11)과 운영체제 모델(M2 부분)이 삽입되어 있다. 상호작용 모델(M)에서의 동작을 이하 구체적으로 설명한다.

상호작용 모델(M)은 어플리케이션 모델(M11)이 API 함수를 호출(API function call)하면 상호작용 지점(M12)을 통해 해당 서비스 요청과 대기에 관한 메시지를 M2에 전달한다(Request service & wait).

상기 메시지를 전달받은 API handler는 해당 API 함수를 M2에서 호출한다. API handler는 독립적인 프로세스로서 다른 프로세스(주로 어플리케이션 소프트웨어)로부터 요청 메시지를 받고 해당 요청에 상응하는 API함수가 실행되도록 호출한다.

M2에서 API handler가 호출한 API함수(API function)는 커널 변수와 관련된 동작(Kernel data operation)을 위해 그 데이터를 확인하여 조작한 후 해당 커널 변수에 따른 실행 결과를 API handler에 리턴한다.

API handler는 기 요청된 서비스의 결과를 M1의 상호작용 지점(M12)으로 전달한다(Result of service & resume).

상호작용 모델(M)은 M1에서 어플리케이션 모델이 상호작용 지점의 다음 부분으로서 어플리케이션 모델(M11)의 소스 코드 나머지 부분을 실행하도록 그 제어를 어플리케이션 모델에 넘긴다(Return of control).

도 4는 본 발명의 일 실시예에 따른 어플리케이션 모델 생성을 설명하기 위한 도면이다.

도 4를 참조하면, 검증 대상 제어 소프트웨어는 제어 흐름 분석(Control Flow Graph analysis)를 통해 복수의 노드로 구분되며 각 노드의 API함수 호출 여부가 파악된다. 검증 대상 제어 소프트웨어는 S에서 시작되어 E에서 종료된다.

J1 및 J2는 운영체제 모델의 API함수를 호출하지 않는다.

J2에는 복수의 노드가 포함되어 있으나 연속된 각 노드가 모두 API함수를 호출하지 않으므로 코드 임베딩을 위해 하나의 노드로 병합되었다. 검증 대상 소프트웨어의 유효성 검사를 할때 내부에 선언된 변수(a~c)의 구체적인 값은 중요하지 않고 어플리케이션 모델과 운영체제 모델의 상호작용, 즉 API함수 호출에 따른 동작이 중요하기 때문이다.

O1 내지 O3은 운영체제 모델의 API함수를 호출하는 상호작용 지점이다. O1은 자원 r1의 할당을 위한 함수를 호출하는 노드이다. O2는 할당된 자원 r1의 반환을 위한 함수를 호출하며 O3은 작업 종료를 위한 함수를 호출한다.

도 5는 본 발명의 일 실시예에 따라 상호작용 모델 생성을 설명하기 위한 도면이다.

도 5를 참조하면, 검증 대상 소프트웨어(S1)에 대해 어플리케이션 모델이 생성되어 상호작용 모델에 삽입된다(S2).

구체적으로 좌측의 소스코드에서 API함수를 호출하지 않는 연속되는 부분은 상호작용 모델에 삽입을 위한 하나의 노드로 병합된다. API함수를 호출하지 않는 노드가 병합되어 각각 X1과 X2과 되며, 병합된 노드는 문법적인 변환 없이 상호작용 모델에 그대로 삽입된다.

I1과 I2는 API함수를 호출하는 상호작용 지점이다. I1과 I2는 상호작용 모델에서 그 유효성 검증을 위해 필요한 형태로 변환되어 상호작용 모델에 삽입된다.

상기와 같이 검증 대상 소프트웨어를 API함수를 호출하는 부분과 그로부터 독립적인 부분을 구분하여 추상화 후에 상호작용 모델에 삽입하므로 본래 검증 대상 소프트웨어의 원본 코드(original code)는 거의 변경되지 않는다.

그에 따라 어플리케이션 모델 및 검증 결과에 대해 높은 가독성을 제공하며 유효성 검증 시 불필요한 실행 추적을 방지하게 되어 검증에 소요되는 시간과 비용을 절감한다. 또한 상호작용 동작이 추상화 전후에 유지되므로 검증 대상 소프트웨어의 속성을 좀 더 철저하게 검증할 수 있다.

도 6은 본 발명의 다른 실시예에 따른 사물인터넷 디바이스의 제어 소프트웨어 검증 장치 구성을 도시한 도면이다.

도 6을 참조하면, 본 발명의 다른 실시예에 따른 사물인터넷 디바이스의 제어 소프트웨어 검증 장치(400)는 운영체제 모델 생성부(410), 어플리케이션 모델 생성부(420), 상호작용 모델 생성부(430) 및 검증부(440)를 포함한다.

운영체제 모델 생성부(410)는 검증 대상 소프트웨어의 운영체제 모델을 생성한다. 구체적으로 운영체제 모델 생성부(410)는 검증 대상 소프트웨어의 운영체제 구조에 따른 정형적 패턴을 기반으로 운영체제 모델을 생성한다.

상기 정형적 패턴이란 커널 변수(kernel variable), 기본적인 동작(basic operation), 기본 API 함수(Basic Application Programming Interface function), 알람(Alarm) 및 ISR(Interrupt Service Routine)에 관한 패턴을 포함한다.

어플리케이션 모델 생성부(420)는 검증 대상 소프트웨어로부터 어플리케이션 모델을 생성한다.

구체적으로 어플리케이션 모델 생성부(420)는 API 함수를 호출하지 않는 부분(code block)과 API 함수를 호출하는 부분을 파악하기 위해 제어 흐름 분석(Control Flow Graph analysis)을 수행한다.

어플리케이션 모델 생성부(420)는 제어 흐름 분석(Control Flow Graph analysis)을 통해 검증 대상 소프트웨어를 추상화한다. 어플리케이션 모델 생성부(420)는 검증 대상 소프트웨어를 복수의 노드로 나눈 후 상기 복수의 노드 중 API 함수 호출 여부를 각각 체크한다. 어플리케이션 모델 생성부(420)는 상기 API 함수를 호출하지 않는 노드는 하나의 노드로 병합한다.

상호작용 모델 생성부(430)는 운영체제 모델과 어플리케이션 모델을 포함하는 상호작용 모델을 생성한다.

구체적으로 상호작용 모델 생성부(430)는 검증 대상 소프트웨어(어플리케이션 모델)와 해당 운영체제(운영체제 모델)간 상호작용 지점을 파악 후 상기 상호작용 지점을 기준으로 상기 운영체제 모델과 상기 어플리케이션 모델을 하나의 모델에 삽입한다.

검증부(440)는 상호작용 모델을 이용하여 검증 대상 소프트웨어의 유효성을 검증한다. 구체적으로 검증부(440)는 검증 대상 소프트웨어의 동작을 보다 포괄적이며 자동으로 검증하기 위해 상기 검증 대상 소프트웨어에서 예상되는 작업 실행 순서를 지정하는 속성 목록(list of properties)을 이용한다.

상기와 같이 본 발명의 다른 실시예에 따른 사물인터넷 디바이스의 제어 소프트웨어 검증 장치에 의하면 운영체제 모델 어플리케이션 모델을 자동으로 생성하여 상호작용 모델에 삽입함으로써 검증에 소요되는 시간이 감소된다.

또한 상호작용 모델을 통해 제어 소프트웨어와 운영체제간 상호작용도 함께 고려하므로 소프트웨어를 더 철저히 검증할 수 있다.

또한 어플리케이션 모델을 상호작용 모델에 삽입함에 있어 상호작용 지점을 기준으로 추상화 후 삽입하므로 검증에 소요되는 시간과 비용이 감소되고 추상화 전 후 상호작용 동작이 유지되어 검증의 정확도를 높일 수 있다.

본 발명은 특정 기능들 및 그의 관계들의 성능을 나타내는 방법 단계들의 목적을 가지고 위에서 설명되었다. 이러한 기능적 구성 요소들 및 방법 단계들의 경계들 및 순서는 설명의 편의를 위해 여기에서 임의로 정의되었다.

상기 특정 기능들 및 관계들이 적절히 수행되는 한 대안적인 경계들 및 순서들이 정의될 수 있다. 임의의 그러한 대안적인 경계들 및 순서들은 그러므로 상기 청구된 발명의 범위 및 사상 내에 있다.

추가로, 이러한 기능적 구성 요소들의 경계들은 설명의 편의를 위해 임의로 정의되었다. 어떠한 중요한 기능들이 적절히 수행되는 한 대안적인 경계들이 정의될 수 있다. 마찬가지로, 흐름도 블록들은 또한 어떠한 중요한 기능성을 나타내기 위해 여기에서 임의로 정의되었을 수 있다.

확장된 사용을 위해, 상기 흐름도 블록 경계들 및 순서는 정의되었을 수 있으며 여전히 어떠한 중요한 기능을 수행한다. 기능적 구성 요소들 및 흐름도 블록들 및 순서들 둘 다의 대안적인 정의들은 그러므로 청구된 본 발명의 범위 및 사상 내에 있다.

본 발명은 또한 하나 이상의 실시 예들의 용어로, 적어도 부분적으로 설명되었을 수 있다. 본 발명의 실시 예는 본 발명, 그 측면, 그 특징, 그 개념, 및/또는 그 예를 나타내기 위해 여기에서 사용된다. 본 발명을 구현하는 장치, 제조의 물건, 머신, 및/또는 프로세스의 물리적인 실시 예는 여기에 설명된 하나 이상의 실시 예들을 참조하여 설명된 하나 이상의 측면들, 특징들, 개념들, 예들 등을 포함할 수 있다.

더구나, 전체 도면에서, 실시 예들은 상기 동일한 또는 상이한 참조 번호들을 사용할 수 있는 상기 동일하게 또는 유사하게 명명된 기능들, 단계들, 모듈들 등을 통합할 수 있으며, 그와 같이, 상기 기능들, 단계들, 모듈들 등은 상기 동일한 또는 유사한 기능들, 단계들, 모듈들 등 또는 다른 것들일 수 있다.

이상과 같이 본 발명에서는 구체적인 구성 요소 등과 같은 특정 사항들과 한정된 실시 예 및 도면에 의해 설명되었으나 이는 본 발명의 보다 전반적인 이해를 돕기 위해서 제공된 것일 뿐, 본 발명은 상기의 실시 예에 한정되는 것은 아니며, 본 발명이 속하는 분야에서 통상적인 지식을 가진 자라면 이러한 기재로부터 다양한 수정 및 변형이 가능하다.

따라서, 본 발명의 사상은 설명된 실시 예에 국한되어 정해져서는 아니되며, 후술하는 특허청구범위뿐 아니라 이 특허청구범위와 균등하거나 등가적 변형이 있는 모든 것들은 본 발명 사상의 범주에 속한다고 할 것이다.

400 : 사물인터넷 디바이스의 제어 소프트웨어 검증장치
410 : 운영체제 모델 생성부
420 : 어플리케이션 모델 생성부
430 : 상호작용 모델 생성부
440 : 검증부

Claims (10)

1. 검증 대상 소프트웨어의 운영체제 모델을 생성하는 단계;
   상기 검증 대상 소프트웨어에 대한 어플리케이션 모델을 생성하는 단계; 및
   상기 운영체제 모델과 상기 어플리케이션 모델을 포함하는 상호작용 모델을 생성하는 단계;를 포함하고,
   상기 어플리케이션 모델을 생성하는 단계는,
   상기 검증 대상 소프트웨어를 복수의 노드로 구분하는 단계, 및
   상기 운영체제 모델의 API 함수 호출 여부를 상기 복수의 노드에 대해 각각 체크하는 단계,를 포함하고,
   상기 API 함수 호출 여부를 상기 복수의 노드에 대해 각각 체크하는 단계는,
   상기 복수의 노드 중 API 함수 호출을 포함하지 않는 연속적인 노드들을 하나의 노드로 병합하여 코드 임베딩에 관한 주석을 추가하는 단계, 및
   상기 복수의 노드 중 API 함수 호출을 포함하는 노드는 상호작용 지점임을 의미하는 주석을 추가하는 단계,를 포함하는 것을 특징으로 하는 사물인터넷 디바이스의 제어 소프트웨어 검증 방법.
2. 제1 항에 있어서,
   상기 운영체제 모델을 생성하는 단계는,
   상기 검증 대상 소프트웨어의 구조에 따라 커널 변수, API 함수, 기본 동작, 알람 및 ISR(Interrupt Service Routine)에 관해 기 정의된 패턴을 이용하여 생성하고,
   상기 커널 변수는 우선순위 대기열, 작업의 정적 구성, 동적 작업 정보, 자원 테이블, 이벤트 테이블에 관한 정보 중 적어도 하나를 포함하고,
   상기 API 함수는 상기 운영체제 모델에서 인라인 함수(inline function)로 모델링하는 것을 포함하고,
   상기 기본 동작은 상기 우선순위 대기열을 사용하여 작업의 정보를 얻는 것을 포함하고,
   상기 알람은 주기적으로 작업을 수행하거나 이벤트를 설정할 수 있는 것을 포함하고,
   상기 ISR(Interrupt Service Routine)은 작업의 일종으로 모델링하는 것을 포함하는 사물인터넷 디바이스의 제어 소프트웨어 검증 방법.
3. 삭제
4. 제1 항에 있어서,
   상기 상호작용 모델을 생성하는 단계는,
   상기 운영체제 모델과 상기 어플리케이션 모델의 상호작용 지점을 파악하는 단계; 및
   상기 상호작용 지점을 기준으로 상기 운영체제 모델과 상기 어플리케이션 모델을 하나의 모델에 삽입하는 단계를 포함하는 것을 특징으로 하는 사물인터넷 디바이스의 제어 소프트웨어 검증 방법.
5. 제4 항에 있어서,
   상기 하나의 모델에 삽입하는 단계는,
   상기 어플리케이션 모델을 상기 상호작용 지점을 기준으로 변환하여 삽입하며,
   상기 어플리케이션 모델에서 상기 운영체제 모델의 API 함수를 호출하지 않는 부분은 변환 없이 그대로 삽입하는 것을 특징으로 하는 사물인터넷 디바이스의 제어 소프트웨어 검증 방법.
6. 검증 대상 소프트웨어의 운영체제 모델을 생성하는 운영체제 모델 생성부;
   상기 검증 대상 소프트웨어에 대한 어플리케이션 모델을 생성하는 어플리케이션 모델 생성부;
   상기 운영체제 모델과 상기 어플리케이션 모델을 포함하는 상호작용 모델을 생성하는 상호작용 모델 생성부; 및
   상기 상호작용 모델을 이용하여 상기 검증 대상 소프트웨어의 유효성을 검증하는 검증부를 포함하고,
   상기 어플리케이션 모델 생성부는,
   상기 검증 대상 소프트웨어를 복수의 노드로 구분하고 상기 운영체제 모델의 API 함수 호출 여부를 상기 복수의 노드에 대해 각각 체크 후, API 함수를 호출하지 않는 노드는 하나의 노드로 병합하여 코드 임베딩에 관한 주석을 추가하고 API 함수를 호출하는 노드는 상호작용 지점임을 의미하는 주석을 추가하는 것을 특징으로 하는 사물인터넷 디바이스의 제어 소프트웨어 검증 장치.
7. 제6 항에 있어서,
   상기 운영체제 모델 생성부는
   상기 검증 대상 소프트웨어의 구조에 따라 커널 변수, API 함수, 기본 동작, 알람 및 ISR(Interrupt Service Routine)에 관해 기 정의된 패턴을 이용하여 생성하며
   상기 커널 변수는 우선순위 대기열, 작업의 정적 정보, 작업의 동적 정보, 자원 테이블 및 이벤트 테이블에 관한 정보 중 적어도 하나를 포함하고
   상기 API 함수는 상기 운영체제 모델에서 인라인 함수(inline function)로 모델링하는 것을 포함하고,
   상기 기본 동작은 상기 우선순위 대기열을 사용하여 작업의 정보를 얻는 것을 포함하고,
   상기 알람은 주기적으로 작업을 수행하거나 이벤트를 설정할 수 있는 것을 포함하고,
   상기 ISR(Interrupt Service Routine)은 작업의 일종으로 모델링하는 것을 포함하는 사물인터넷 디바이스의 제어 소프트웨어 검증 장치.
8. 삭제
9. 제6 항에 있어서,
   상기 상호작용 모델 생성부는
   상호작용 지점을 파악한 후 이를 기준으로 상기 운영체제 모델과 상기 어플리케이션 모델을 하나의 모델에 삽입하며,
   상기 하나의 모델에 삽입함에 있어서, 상기 운영체제 모델과 상기 어플리케이션 모델간 상호작용 지점을 기준으로 변환하여 삽입하고 상기 어플리케이션 모델에서 상기 운영체제 모델의 API 함수를 호출하지 않는 부분은 변환 없이 그대로 삽입하여
   상기 상호작용 모델을 생성하는 것을 특징으로 하는 사물인터넷 디바이스의 제어 소프트웨어 검증 장치.
10. 제6 항에 있어서,
    상기 검증부는
    상기 상호작용 모델과 상기 검증 대상 소프트웨어에서 예상되는 작업 실행 순서를 지정하는 속성 목록을 이용하여 유효성을 검증하는 것을 특징으로 하는 사물인터넷 디바이스의 제어 소프트웨어 검증장치.
    

Images