하드웨어와 소프트웨어가 조합된 내장형 시스템이 복잡해지면서, 내장형 시스템에 탑재되는 내장형 소프트웨어 테스트가 중요하게 인식되고 있다. 특히, 원자력 발전소와 같이 안전 등급이 높은 시스템에 들어가는 소프트웨어 테스트는 필수적이다. 내장형 시스템 테스트의 경우 하드웨어와 소프트웨어의 상호작용에 의해 발생하는 오류를 발견하기 위한 효과적인 테스트 기법이 필요하다. 본 논문에서는, 하드웨어와 소프트웨어 사이의 상호작용에 의해 생성되는 오류를 발견하기 위하여, 오류 삽입 기법을 이용한 테스트 데이타 선정 기법을 제안하고, 이 기법을 Digital Plant Protection System에 적용하였으며, 실험을 통해 제안한 기법의 우수성을 분석한다.
하드웨어와 소프트웨어가 조합된 내장형 시스템이 복잡해지면서, 내장형 시스템에 탑재되는 내장형 소프트웨어 테스트가 중요하게 인식되고 있다. 특히, 원자력 발전소와 같이 안전 등급이 높은 시스템에 들어가는 소프트웨어 테스트는 필수적이다. 내장형 시스템 테스트의 경우 하드웨어와 소프트웨어의 상호작용에 의해 발생하는 오류를 발견하기 위한 효과적인 테스트 기법이 필요하다. 본 논문에서는, 하드웨어와 소프트웨어 사이의 상호작용에 의해 생성되는 오류를 발견하기 위하여, 오류 삽입 기법을 이용한 테스트 데이타 선정 기법을 제안하고, 이 기법을 Digital Plant Protection System에 적용하였으며, 실험을 통해 제안한 기법의 우수성을 분석한다.
As an Embedded system combining hardware and software gets more complicated, the importance of the embedded software test increases. Especially, it is mandatory to test the embedded software in the system which has high safety level. In embedded system, it is necessary to develop a test technique to...
As an Embedded system combining hardware and software gets more complicated, the importance of the embedded software test increases. Especially, it is mandatory to test the embedded software in the system which has high safety level. In embedded system, it is necessary to develop a test technique to detect faults in interaction between hardware and software. In this paper, we propose a test data selection technique using a fault injection technique for the faults in interaction between hardware and software in embedded system and we apply our technique to the Digital Plant Protection System and analyze effectiveness of the proposed technique through experiments.
As an Embedded system combining hardware and software gets more complicated, the importance of the embedded software test increases. Especially, it is mandatory to test the embedded software in the system which has high safety level. In embedded system, it is necessary to develop a test technique to detect faults in interaction between hardware and software. In this paper, we propose a test data selection technique using a fault injection technique for the faults in interaction between hardware and software in embedded system and we apply our technique to the Digital Plant Protection System and analyze effectiveness of the proposed technique through experiments.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
본 논문에서는 내장형 시스템의 하드웨어와 소프트웨어의 상호작용을 테스트하기 위하여 오류 삽입 기법 [4-15]을 이용한 테스트 데이타 선정 기법을 제안한다. 오류 삽입 기법은 하드웨어나 소프트웨어의 특정 위치에 오류를 삽입하여 대상 시스템이 어떻게 동작하는지를 관찰하는 기법이다.
목적에서 사용된다. 첫번째 목적은 하드웨어 오류삽입 기법과 마찬가지로 대상 소프트웨어에 인위적으로 오류를 삽입함으로써 대상 소프트웨어의 동작을 관찰하기 위함이다. 두번째 목적은 대상 프로그램에 오류를 삽입함으로써, 원래의 프로그램과 오류가 삽입 된 프로그램의 결과 값을 차별화 하는 입력 데이타를 테스트 데이타로 선정 하는 방식을 통해, 대상 프로그램에 존재하는 오류를 발견할 수 있는 테스트 데이타를 선정하기 위함이다.
첫번째 목적은 하드웨어 오류삽입 기법과 마찬가지로 대상 소프트웨어에 인위적으로 오류를 삽입함으로써 대상 소프트웨어의 동작을 관찰하기 위함이다. 두번째 목적은 대상 프로그램에 오류를 삽입함으로써, 원래의 프로그램과 오류가 삽입 된 프로그램의 결과 값을 차별화 하는 입력 데이타를 테스트 데이타로 선정 하는 방식을 통해, 대상 프로그램에 존재하는 오류를 발견할 수 있는 테스트 데이타를 선정하기 위함이다.
본 논문에서는 내장형 시스템의 하드웨어와 소프트웨어 인터렉션으로 인해 생길 수 있는 오류를 발견할 수 있는 테스트 데이타를 선정함을 목적으로 한다. 프로그램 S의 테스트데이타 집합 T는 다음과 같이 프로그램 S의 출력과 R의 출력을 다르게 하는 입력 데이타로 정의한다.
본 기법은 내장형 시스템의 하드웨어와 소프트웨어사 이의 상호작용에 의한 오류를 발견할 수 있는 테스트데이타를 선정함을 목적으로 하며, 5절에서 제안한 기법의 우수성을 실험결과를 토대로 기술한다.
제안 방법
제안하는 테스트 데이타 선정 기법은 요구 명세 단계로부터 내장형 시스템의 동작을 소프트웨어 프로그램으로 시뮬레이트하고, 하드웨어 오류를 소프트웨어 오류 화하여 시뮬레이트 된 프로그램이 삽입함으로써, 하드웨어와 소프트웨어의 상호작용에 의한 오류를 발견할 가능성이 높은 테스트 데이타를 선정한다.
대상 시스템에 존재하는 하드웨어 오류를 파악하고, 이 하드웨어 오류를 소프트웨어 오류로 전환한 후, 대상 시스템의 동작을 시뮬레이트 한 프로그램에 소프트웨어 오류로 전환된 하드웨어 오류를 삽입하는 방식의 오류 삽입 기법을 활용한다. 즉, 내장형 시스템의 상호작용 오류 발견을 위하여, 하드웨어 오류 삽입 기법에서 사용되는 하드웨어 오류를 파악하고, 파악한 하드웨어 오류를 소프트웨어 오류로 전환한 후 대상 프로그램에 삽입함으로써, 대상 프로그램의 동작을 관찰하고 테스트 데이타를 선정하는 방식의 소프트웨어 오류 삽입 기법을 활용한다,
대상 시스템에 존재하는 하드웨어 오류를 파악하고, 이 하드웨어 오류를 소프트웨어 오류로 전환한 후, 대상 시스템의 동작을 시뮬레이트 한 프로그램에 소프트웨어 오류로 전환된 하드웨어 오류를 삽입하는 방식의 오류 삽입 기법을 활용한다. 즉, 내장형 시스템의 상호작용 오류 발견을 위하여, 하드웨어 오류 삽입 기법에서 사용되는 하드웨어 오류를 파악하고, 파악한 하드웨어 오류를 소프트웨어 오류로 전환한 후 대상 프로그램에 삽입함으로써, 대상 프로그램의 동작을 관찰하고 테스트 데이타를 선정하는 방식의 소프트웨어 오류 삽입 기법을 활용한다,
하드웨어 오류 삽입 기법[4-15]에 사용되는 하드웨어 오류들을 파악함으로써, 대상 시스템에 존재 할 수 있는 하드웨어 오류를 파악하였다. 하드웨어 오류 삽입 기법은 이미 만들어진 하드웨어가 제대로 동작하는지를 보기 위해 대상 하드웨어에 인위적으로 오류를 삽입함으로써 대상 하드웨어의 행동을 관찰하는 기법이다.
크게 두 단계로 구성한다. 첫 번째 단계는 내장형 시스템을 분석하는 단계로 하드웨어 모듈 및 소프트웨어 모듈을 분석하여, 하드웨어 모듈과 그 모듈의 입, 출력 정보를 표현하기 위한 HBD(Hardware Block Diagram)를 작성하고, HBD를 구성하는 하드웨어 모듈에 기능을 나타내는 소프트웨어 모듈을 표현한 HSBD (Hardware Software Block Diagram)을 작성한다. 두 번째 단계는 내장형 시스템 테스트를 위한 테스트 데이타 선정 단계로 HSBD의 동작을 시뮬레이트 하는 내장형 소프트웨어 프로그램 S를 작성하고, 하드웨어 오류 f들을 소프트웨어 오류로 전환하여 프로그램 S에 내장한 프로그램 P들을 활용하여 테스트 데이타를 생성한다.
첫 번째 단계는 내장형 시스템을 분석하는 단계로 하드웨어 모듈 및 소프트웨어 모듈을 분석하여, 하드웨어 모듈과 그 모듈의 입, 출력 정보를 표현하기 위한 HBD(Hardware Block Diagram)를 작성하고, HBD를 구성하는 하드웨어 모듈에 기능을 나타내는 소프트웨어 모듈을 표현한 HSBD (Hardware Software Block Diagram)을 작성한다. 두 번째 단계는 내장형 시스템 테스트를 위한 테스트 데이타 선정 단계로 HSBD의 동작을 시뮬레이트 하는 내장형 소프트웨어 프로그램 S를 작성하고, 하드웨어 오류 f들을 소프트웨어 오류로 전환하여 프로그램 S에 내장한 프로그램 P들을 활용하여 테스트 데이타를 생성한다.
내장형 시스템의 분석단계는 그림 2와 같이 내장형 시스템의 요구사항을 분석하여 하드웨어 블톡 다이어그램 (Hardware Block Diagram: HBD)을 작성하는 HBD 작성 단계와 HBD에 소프트에어 모듈을 표현하는 하드웨어 소프트웨어 블록 다이어그램(Hardware Software Block Diagram: HSBD)을 작성하는 단계로 구분한다.
본 논문에서는 내장형 시스템의 하드웨어와 소프트웨어의 상호작용 부분에 오류를 임의로 삽입하는 방식에 따라 테스트 데이타를 선정하는 것을 제안하며, 이때 하드웨어 오류에 영향을 받는 S의 마지막 위치의 변수가 오류 삽입 위치(FIT)가 된다. 예를 들면, 표 1에서 보는 바와 같이 Open 오류, Bridging 오류, Bit-flip 오류, Stuck-at 0 오류, StMk-at 1 오류의 경우 오류가 어느 위치에 어떻게 영향을 미치는지 알 수 있기 때문에, 이러한 오류들이 S에 미치는 영향을 예상할 수 있다.
예를 들면, 표 1에서 보는 바와 같이 Open 오류, Bridging 오류, Bit-flip 오류, Stuck-at 0 오류, StMk-at 1 오류의 경우 오류가 어느 위치에 어떻게 영향을 미치는지 알 수 있기 때문에, 이러한 오류들이 S에 미치는 영향을 예상할 수 있다. 따라서 Open 오류, Bridging 오류, Bit-flip 오류, Stuck- at 0 오류, Stuck-at 1 오류에 의해 영향을 받는 S의 마지막 위치 변수를 FIT로 선정한다. Spurious current 오류, Power surge 오류의 경우에는 전체 시스템에 영향을 미치는 오류이기 때문에, S의 최종 출력 변수를 FIT 로 선정한다.
프로그램 S에 표 2에서 파악한 48개의 FIT를 위에서 설명한 코드 패치 방법을 이용하여 소프트웨어 오류로 변환하여 프로그램 갈8개의 P了들을 생성한다. 그림 5는 HSBD의 동작을 시뮬레이트 한 S의 일부와, Spurious current 오류를 S에 삽입한 생성한 Pf48의 일부를 나타내며, f48에 해당하는'digital[i], trip_initiation”은 0 또는 1의 값을 가지는 신호로, 그림 5의 P”용의 이탤릭체로 표시 한 , <digital[i].
본 논문에서 제안한 기법은 내장형 시스템의 하드웨어와 소프트웨어의 상호작용에 의한 오류를 발견하기 위한 테스트 데이타를 선정하는 것으로, 기존의 테스트기법과 비교하여 제안한 기법의 우수성을 보이기 위하여 기법을 100% 커버(cover)하는 테스트 데이타 개수와 오류 발견 비율을 비교하였다.
Expi, ExP2, Exp3, Exp4, Exp5에 대한 실험 수행 데이타는 표 4에서 보는 바와 같이 Si에 있는 상호 작용오류, 기존의 기법과 제안한 기법에 의해 생성된 테스트데이타 개수, 기존 기법과 제안한 기법에서 오류를 발견한 테스트 데이타 수, 그들의 오류 발견 비율을 기술하였다.
오류가 없는 프로그램 S에 상호 작용 오류를 인위적으로 삽입하여 작성한, Si, S2, S3, S4> S5 를 대상으로 오류 발견 비율을 측정하였으며, 기존 기법에 의한 오류발견 비율과 제안한 기법의 오류 발견 비율을 표 4의 소괄호와 그림 7의 막대그래프를 통해 나타내었다. 오류발견 비율을 다음과 같이 정의한다.
본 논문에서는 DPPS 채널 A의 하드웨어와 소프트웨어 모듈을 분석하여 HSBD를 작성하고 이를 토대로 DPPS 채널 A의 동작을 C 프로그래밍 언어로 시뮬레이트 한 코드 S를 작성하였으며, 하드웨어 오류를 소프트웨어 오류로 전환하여 프로그램 已들을 생성하고, S와 円들의 출력을 다르게 하는 입력 데이타를 DPPS 채널 A의 하드웨어와 소프트웨어의 상호작용에 의한 오류를 발견하는 테스트 데이타로 정의하였다.
내장형 시스템의 하드웨어와 소프트웨어의 상호작용에 의한 오류 발견을 위하여 하드웨어 오류를 소프트웨어 오류로 변환하여 프로그램 S에 삽입하여 프로그램 Pf를 생성하도록 한다. 이를 위하여 먼저 하드웨어 오류의 종류를 분류할 필요가 있다.
제안한 테스트 기법의 효율성을 분석하기 위하여 DPPS 채널 A의 동작을 시뮬레이트 한 프로그램들을 실험 대상으로 하여, 기존의 화이트박스 테스트 기법에 비해 테스트 데이타의 개수와 오류 발견 비율에 대한 분석을 하였다. 제안한 기법에 의해 생성되는 테스트 데이타의 개수는 기존 테스트 기법에 의한 테스트 데이타의 개수보다 적은 수의 테스트 데이타 개수가 필요하였으며, 이 적은 수의 테스트 데이타로도 기존 테스트 기법보다 높은 오류 발견 비율을 얻을 수 있었다.
대상 데이터
실험 대상은 4절에서 예를 들어 기술한 DPPS 채널 A를 각각 다른 5 사람이 시뮬레이트 한 C 프로그램 Si, S2, S3, S4, S5을 대상으로 5개의 실험, Expi, Exp2) Exp3, Exp4, EXP5를 수행하였다. 오류가 없는 DPPS 채널 A에 대한 C 프로그램을 S라고 할 때, 각 프로그램S:는 표 4에서처럼 각각 다른 상호작용 오류를 갖도록 하였으며, 각 실험 Expi(14u5)에 대하여 수행한 실험 절차는 아래의 세 단계를 거친다.
이론/모형
본 논문에서는 내장형 시스템의 상호작용 오류 발견을 위하여, 다음과 같이 오류 삽입 기법을 활용한다. 대상 시스템에 존재하는 하드웨어 오류를 파악하고, 이 하드웨어 오류를 소프트웨어 오류로 전환한 후, 대상 시스템의 동작을 시뮬레이트 한 프로그램에 소프트웨어 오류로 전환된 하드웨어 오류를 삽입하는 방식의 오류 삽입 기법을 활용한다.
테스트 데이타를 구한다. 본 실험에서는 화이트 박스 테스트 데이타 생성 도구인 ATAC(Automatic Test Analysis for 0118, 19, 20, 21]을 이용하여, allnode, decision, c-use, p~use, all-use 기준(Criteria) 을 만족하는 테스트 데이타 집합 T&를 생성하였다.
성능/효과
표 2는 표 1의 하드웨어 오류 분류 체계에 따라 DPPS 채널 A에서 발생 가능한 하드웨어 오류를 식별한 것으로, Open 오류, Bridging 오류, Bit-flip 오류, Stuck-at 0 오류, Stuck-at 1 오류, Spurious current 오류, Power surge가 있으며, 각 오류가 발생할 하드웨어의 위치와, 이 오류들이 소프트웨어로 삽입될 때, 삽입되는 오류 삽입 위치를 파악한 표로, Stuck-at 0와 Spurious current 오류 대한 예를 보여주며, DPPS 채널 A의 경우 총 48개의 FIT가 파악되었다.
그러므로 Expi의 경우 기존의 방법에 의해 구한 테스트 데이타는 23개이나, 제안한 기법에 의해 생성된 테스트 데이타는 평균 개로, 제안한 기법이 기존의 기법에 비해 적은 테스트 데이타가 소요됨을 알 수 있다. ExP1 과 마찬가지로 Expz, Exps, EXP4, EXP5에 대한 평균 테스트 데이타의 개수는 3.
ExP1 과 마찬가지로 Expz, Exps, EXP4, EXP5에 대한 평균 테스트 데이타의 개수는 3.80, 3.87, 3.82, 3.94로 제안한 기법에 의해 생성되는 테스트 데이타가 기존의 기법에 비해 상당히 적음을 알 수 있으며, 각 실험 별로, 기존기법과 제안한 기법의 평균 테스트 데이타의 수를 그림 6의 막대 그래프를 통해 나타내었다.
26이다. 제안한 기법의 경우, 생성된 총 테스트 데이타 203개 중 155개의 데이타가오류를 발견하였으므로, 이때의 오류 발견 비율은 0.76 이다. Expi과 마찬가지로 EXP2, EXP3, EXP4, EXP5에 대한 오류 감지율도 0.
76 이다. Expi과 마찬가지로 EXP2, EXP3, EXP4, EXP5에 대한 오류 감지율도 0.80, 0.69, 0.81, 0.기로, 각 실험별오류 발견 비율은 그림 7의 막대 그래프로 나타내었으며, 이를 통해 제안한 기법이 기존 기법에 비해 높은 오류 발견 비율이 높음을 알 수 있었다.
5.1 절의 테스트 데이타의 개수 비교와 5.2절의 오류발견 비율 비교를 통해, 본 논문에서 제안하는 기법이 기존의 테스트 기법에 비해 적은 수의 테스트 데이타를 생성하였으며, 이 적은 수의 테스트 데이타로도, 기존기법에 비해 오류 발견 비율이 높음을 알 수 있었으며, 따라서 제안한 기법이 하드웨어와 소프트웨어의 상호작용에 의한 오류를 발견할 수 있는 효과적언 테스트 기법임을 분석하였다.
본 논문에서 사례로 든 원전 보호계통 시스템인 DPPS와같이 위험도가 높은 시스템을 테스트를 한다는 것은 비용도 많이 들고, 위험도 높기 때문에 내장형 시스템의 하드웨어와 소프트웨어의 상호작용 의해 발생되는 오류를 발견하기 위한 효과적인 테스트 기법이 필요하였다.
하였다. 제안한 기법에 의해 생성되는 테스트 데이타의 개수는 기존 테스트 기법에 의한 테스트 데이타의 개수보다 적은 수의 테스트 데이타 개수가 필요하였으며, 이 적은 수의 테스트 데이타로도 기존 테스트 기법보다 높은 오류 발견 비율을 얻을 수 있었다.
표 4에서 보는 바와 같이 Exp】의 경우, 기존 기법을 100% 커버하는 테스트 데이타 T&의 개수는 23개이며, Si과 &로부터 생성한 모든 已들을 차별화하는 데이타 즉, 제안한 기법을 100% 커버하는 데이타를 분석하면 다음과 같다. 2개의 테스트데이타로 제안한 기법을 100% 커버하는 경우는 10가지, 3개의 테스트 데이타로 제안한 기법을 100% 커버하는 경우는 56가지, 4개의 테스트 데이타로 제안한 기법을 100% 커버하는 경우는 97 가지, 5개의 테스트 데이타로제안한 기법을 100% 커버하는 경우는 36 가지, 6개의 테스트 데이타로 제안한 기법을 100% 커버하는 경우는2가지로, 제안한 기법을 100% 커버하는 평균 테스트 데이타 수는 3.74 개다.
후속연구
향후에는 본 논문에서 제시한 기법을 도구로 구현하고, 실제 내장형 시스템의 하드웨어 소프트웨어의 상호작용 의한 오류를 발견하기 위한 테스트 데이타를 자동생성할 수 있도록 할 예정이다. 또한 본 논문에서는 제안한 기법을 DPPS 채널 A에만 적용하여 사례 연구 및 실험을 수행하였으나, 완성된 도구를 다양한 내장형 시스템에 적용하고, 다양한 실험을 수행하여 본 기법의 우수성을 나타낼 예정이다.
수 있도록 할 예정이다. 또한 본 논문에서는 제안한 기법을 DPPS 채널 A에만 적용하여 사례 연구 및 실험을 수행하였으나, 완성된 도구를 다양한 내장형 시스템에 적용하고, 다양한 실험을 수행하여 본 기법의 우수성을 나타낼 예정이다.
참고문헌 (23)
E. A. Lee, What's Ahead for Embedded Software?, IEEE Computer, pp 18-26, September, 2000
E. A. Lee, 'Computing for embedded systems,' proceeding of IEEE Instrumentation and Measurement Technology Conference, Budapest, Hungary, May, 2001
Mattias O'Nils and Axel Jantsch, 'Communication in Hardware/Software Embedded Systems-A Taxonomy and Problem Formulation,' in Proceeding of 15th NORCHIP Conference, November, 1997
M.Hsueh, Fault Injection Techniques and Tools, Computer, Apr, 1997, pp75-82
J.V. Carreira, Xeption : A technique for the Experimental Evaluation of Dependability in modem computers, IEEE Transaction on Software Engineering. VOL 23, No.2, Feb, 1998
Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press, 1995
UCN 3&4 Final Safety Analysis Report, Volume 11, Korea Electric Power Corporations
J.R. Horgan and S. London, 'ATAC : A data flow coverage testing tool for C,' in Proceedings of Symposium on Assessment of Quality Software Development Tools, pp2-10, New Orleans, LA, May, 1992
M.R. Lyu, J.R. Horgan and S. London, 'A coverage analysis tool for the effectiveness of software testing,' in Proceeding of International Symposium on Software Reliability Engineering, 1993
Li, N., Malaiya, Y. K., Denton J, 'Estimating the Number of Defects: A Simple and Intuitive Approach,' in Proceeding of 7th International Symposium on Software Reliability Engineering, 1998
Burr, Kevin and Young, William, 'Combinatorial Test Techniques: Table-Based Automation, Test Generation, and Test Coverage,' in Proceeding of International Conference on Software Testing, Analysis, and Review. San Diego, CA, October, 1998
Richard A. DeMillo, Richard J. Lipton, and Frederick G. Sayward, Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34-41, April 1978
M. E. Delamaro, J. C. Maldonado, and A. P. Mathur., 'Integration Testing Using Interface Mutation,' In Proceedings of International Symposium on Software Reliability Engineering (ISSRE '96), pages 112--121, April 1996
이 논문을 인용한 문헌
저자의 다른 논문 :
활용도 분석정보
상세보기
다운로드
내보내기
활용도 Top5 논문
해당 논문의 주제분야에서 활용도가 높은 상위 5개 콘텐츠를 보여줍니다. 더보기 버튼을 클릭하시면 더 많은 관련자료를 살펴볼 수 있습니다.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.