a study of dynamic coverage achievement for flight control...

항공우주시스템공학회 2017년도 추계학술대회 2017 SASE Fall Conference

1. 서 론

항공기 운용에 있어서 항공기 비행제어 시스템의

비행 안전성과 신뢰성이 가장 중요하다. 이 비행제어

시스템에서 발생되는 사소한 오류 하나라도 확인되고

조치되지 않는다면 조종사의 생명과 항공기의 신뢰성

에 치명적인 요소가 될 수 있다. 비행제어 시스템의

안전성과 신뢰성 확보를 위해 요구사항을 제대로 구현

하였는지 검증하기 위해 단계별 시험을 수행해야 하

며, 소프트웨어 개발자에 의해 소프트웨어 신뢰성 시

험이 첫 번째로 수행되게 된다. 소프트웨어 신뢰성 시

험 중에서도 동적 시험을 통해서 비행제어 비행운용프

로그램 소프트웨어(Operational Flight Program, 이하

OFP) 개발 언어인 C언어의 동작이 개발자가 의도한대

로 동작하는지 검증하게 된다. 이 동적시험은 테스트

가 가능한 최소 단위로 나누어진 소프트웨어 내에서

결함을 찾고 그 기능을 검증하는 것으로 단위시험이라

고 칭하기도 한다. 소프트웨어에 발생하는 오류를 개

발 초기에 찾아내어 소프트웨어 신뢰성 검증뿐 아니라

시스템 단계에서 오류 발생에 따른 금전적인 손실, 시

간 낭비 등의 문제를 최소화하기 위해 반드시 필요하

다. 동적 시험을 통하여 시험 커버리지를 산출하는데

이는 소프트웨어 요구사항을 기반으로 작성한 시험 케

이스들을 통하여 소프트웨어가 얼마만큼 커버리지 목

표를 만족하는지를 보여주는 척도라고 할 수 있다. 동

적 시험의 커버리지 기준으로는 문장 커버리지, 분기

커버리지 , MC/DC (Modified Condition/Decision

Coverage) 등이 널리 사용된다. 방사청 무기체계

소프트웨어 개발 및 관리 매뉴얼에 동적 시험 (문장,

분기, MC/DC)의 코드 커버리지를 100% 달성하여야

한다는 수치적 달성기준에 대한 내용이 개정 본에 반

비행제어 소프트웨어동적시험 커버리지 달성방안 연구

이지은1,†· 신선영2· 장순용2

1한국항공우주산업(주)

A Study of Dynamic Coverage Achievementfor Flight Control Software

Jieun Lee1,†, Sunyoung Shin2 and Soon Ryoung Jang2 KFX Flight Control System Integration Team

2Aircraft Research & Development Division, Korea Aerospace Industries, LTD.

Abstract : 비행제어 비행운용프로그램(Operational Flight Program)으로 개발되는 소프트웨어는 안전중시(Safety-Critical) 소프트웨어이다. 비행제어에 관한 모든 소프트웨어는 동적시험에서 커버리지 기준을 달성하여, 소프트웨어 무결점 입증 및 방사청의 무기체계 소프트웨어 신뢰성 시험 기준을 만족하여야 한다. 본 논문은 동적시험 커버리지 목표를 달성하지 못하여 엔지니어링 분석을 수행하였던 Legacy Code coverage 예외코드를 분석하고 예외처리 기법에 대해 논의하고자 한다. 이 연구를 통해 향후 차기 항공기 개발 사업에 비행제어 소프트웨어 동적시험 커버리지를 확보하여 항공기 신뢰성과 안전성을 확보하여 개발에 도움이 될 것으로 기대된다.

Key Words : Dynamic Coverage, Operational Flight Program (OFP), Safety-Critical, Flight Control System

†교신저자 ( Corresponding Author )E-mail: [email protected] Ⓒ The Society for Aerospace System

TA8-2

56


영되어 더욱 동적시험 커버리지의 중요성이 부각되었

다. 하지만 동적시험 커버리지 목표를 만족하지 못하

는 Legacy code가 존재하며, 이러한 코드에 대하여

개발자들이 분석하는데 어려움이 있다.

본 논문은 동적 커버리지의 대략적인 소개와 방사청

무기체계 소프트웨어 개발 및 관리 매뉴얼 분석 내용

을 소개한다. 그리고 OFP 소스코드 개발 시, 동적 커

버리지 목표를 만족하지 못한 Legacy Code들의 원인

분석과 해결방안을 도출하여 향후 차기 항공기 개발

사업에 비행제어 소프트웨어 동적시험 커버리지를 확

보하는데 도움이 되고자 한다.

2. 본 론

소프트웨어가 동작할 수 있는 다양한 경우의 수를 확

인함으로써 소프트웨어가 일으킬 수 있는 결함을 식별

하기 위하여 소프트웨어 신뢰성 시험은 반드시 해야

한다. 소프트웨어 신뢰성 시험은 동적시험과 정적시험

으로 구분된다.

2.1 소프트웨어 신뢰성 시험 정적시험은 소스코드를 분석하고 실행하는 일반적인

방법론을 사용하여 코드 품질에 대한 접근 방식이 동

적 시험과는 다른 기술 범주이다. 이는 소프트웨어를

실행하지 않은 상태에서 코딩규칙이나 실행시간오류

(Runtime Error)를 검출한다.

반면 동적시험은 소프트웨어 시스템이 다양한 입력 데

이터에 어떻게 반응하는지 나타낸다. 이것은 실제로

소프트웨어를 실행하고 출력 또는 예상된 결과가 예상

대로 수행되는지를 확인하여 수행된다.

2.2 코드 커버리지 코드 커버리지는 소프트웨어의 시험에 있어 얼마나

시험이 충분한가를 나타내는 지표라고 할 수 있으며,

소프트웨어 시험에 있어 필수적이다. 이러한 코드 커

버리지의 측정은 다양한 방법이 있다. 가장 일반적으

로는 3가지로 문장 커버리지, 분기 커버리지,

MC/DC(Modified Condition/Decision Coverage)를

많이 사용한다.

측정 기준 커버리지 충족 조건

문장 실행 가능한 코드 라인의 실행 여부

를 테스트

분기코드 상의 분기조건이 가능한 결정

들을 완벽하게 테스트

MC/DC분기가 되는 조건 안의 서브조건의

진리까지 테스트

Table 1 Coverage measurement criteria

특히 위의 측정 기준 중에, 분기 커버리지는 코드 내

분기문의 참과 거짓 경로가 모두 수행되었는지 판단하

는 방법이다. 즉, 분기 커버리지의 해당 조건이 참이

되는 경우 거짓이 되는 경우가 적어도 한번씩은 실행

이 되는지를 확인한다. 비행제어 OFP의 특성 상 여러

가지 의사결정 조건들을 if문으로 표현하는 경우가 많

기 때문에 주로 분기 커버리지를 통해 코드 커버리지

를 측정한다. 하지만 Lazy Evaluation을 일으키는 복

잡한 Boolean 연산식에서는 한계가 있기 때문에

MC/DC로 주로 검증한다.

MC/DC는 DO-178B A레벨 인증에서 요구하고 있으

며, 대부분의 소프트웨어 분야의 표준에서도 최고 레

벨의 커버리지 요구사항으로 사용되고 있다. MC/DC는

각 서브조건이 전체결과에 독립적으로 영향을 미치는

조합을 찾아 테스트 되어 특정 서브조건에 의해 결과

가 변경되는 경우를 모두 찾아 Lazy Evaluation도 발

생하지 않는다.

2.3 방사청 무기체계 소프트웨어 개발 및 관리 매뉴얼 분석방사청의 무기체계 소프트웨어 개발 및 관리 매뉴얼

에 따라 내장형 소프트웨어가 포함된 무기체계 개발

시 내장형 소프트웨어 분류체계를 적용하고 관리를 할

수 있어야 한다.

특히, 소프트웨어 코딩 및 단위시험부분에서 새로 개

정된 동적시험 종류 기준은 결함의 발생빈도, 영향성

및 제어가능성을 평가한 후 IEC 61508-7에 근거하여

수준별로 코드 커버리지 시험종류 (문장, 분기,

MC/DC)를 설정하고 이에 대한 코드 커버리지 100%

를 달성하여야 한다고 명시되어 있다.

또한 동적시험 환경 및 방법에 있어 ‘소프트웨어를 실

57


제 하드웨어(Target)에 탑재한 상태에서 소프트웨어

통합시험 절차서에 기술된 시험절차를 이용하여 요구

사항 기반으로 소프트웨어 코드 커버리지를 점검하는

것’이라고 명시하는 것으로 개정본에 반영되었다.

2.4 단위시험 수행과정동적 커버리지를 얻기 위한 단위 시험(Unit test)는 프

로그램의 기본 단위인 CSC단위인 모듈을 테스트하는

것이다. 이러한 단위 시험은 Informal Test이며,

Open-Loop, Non Real-Time, Single 채널인 환경에

서 수행된다. 이는 실제 하드웨어와 동일하게 묘사하

는 C40 Simulator인 Code Composer를 사용하여 수

행된다. 단위 시험의 전체적인 과정은 아래의 그림과

같다. 간략하게 설명하자면, INPUTS파일에 분기의 참

과 거짓 경로가 모두 수행될 수 있는 각각의 값들과

그 값을 넣었을 경우의 예상되는 값들을 정해준다. 그

런 후, Unit Test에서 실제로 수행 결과 값과 예상 값

을 비교하여 커버리지를 산출한다.

(1) Test Procedure 작성

우선, 단위시험을 하기 이전에 어떤 기능을 수행하기

위한 시험인지에 대한 정의와 그 기능을 시험하기 위

해서 생성해야 할 test case와 예상되는 값들을 미리

Word 파일 형식으로 간략하게 작성한다.

(2) Test Case File 작성

앞서 작성한 Test Procedure을 기반으로 하여 test

case를 엑셀 파일로 작성한다. 이 Test Case File은

크게 5부분으로 구성되어져있다. 시험할 코드와 관련

이 있는 header파일을 정의, input값 정의, output초

기화, 함수 호출, expected 값 부분으로 순서대로 작

성하며, 이 Exel파일은 Make Test프로그램을 통해서

INPUTS.C, MAIN.C, OUTPUTS.C파일을 생성한다.

(3) Code composer 환경에서 테스트해보고자 하는

소스파일의 컴파일 결과인 어셈블리어 명령어를 기반

으로 분기 지점을 잡아내는 BP.gel 파일을 사용하여

분기 커버리지를 측정하고, Actual값과 expected 값

을 비교한다.

(4) 이 테스트의 결과는 log파일로 남겨지게 된다.

2.5 동적 커버리지 만족하지 못하는 Legacy Code 분석 및 해결방안Legacy 소스코드를 기준으로 하여 동적 커버리지를

100% 만족하지 못하는 코드는 약 7% 정도 차지하였

다. 이 코드들이 동적 커버리지를 만족하지 못하는 이

유를 위해 아래와 같은 절차로 분석해보았다.

1. 수행했던 test case와 소스 환경을 셋업한 후, Unit

Figure. 3 Code composer environment

Figure. 1 Test Procedure

Figure. 2 Test Case File

58


Test를 수행한다 (Compiler Optimization Level 1

– Local) 우선적으로, log파일에서 Summary of

Branchpoint analysis result를 참고하여 missing

point들을 살펴본다.

2. Compiler의 최적화로 인한 missing인지를 알아보

기 위해서 Optimization Level을 Disable로 변경해

서 다시 Unit Test를 수행한다.

3. 그 후에도 남은 missing point들은 asm과 각 test

case마다 변화하는 변수의 값들을 비교하여 코드가

제대로 작동하는지에 대해 확인 및 예외원인을 분

석한다.

예외 코드 원인 개수

1 Mechanization 최적화 6

2 중첩된 IF 7

3 FOR Loop 5

4 Test size가 너무 큼 2

5 SWITCH 2

6 Assembly line 초과 1

7 Hardware failure simulation 불가능 1

8Compiler 항상 false값을 내보냄

(Disable시, 해결 가능)8

Table 2 Cause of Non - 100% coverage code

분석 결과, 위의 표와 같이 여러 가지 원인들이 있지

만, 예외 코드 원인에서 중첩된 IF, FOR Loop, Text

size가 너무 큰 경우, SWITCH문과 같은 내용들은

Compiler의 특성 때문에 발생하는 것을 확인해볼 수

있었다. 이렇게 커버리지를 만족하지 못하는 Legacy

Code가 발생하면, 개발자들은 앞서 말했던 방법을 통

해서 원인을 분석하고 그 원인에 대한 history를 남겨

야 한다. 하지만 이 경우 핸드코드에 대한 신뢰성 시

험에 대한 인력과 시간 자원이 들며 특히 성숙도가 높

지 않은 개발자들에게는 항공기 신뢰성이 달려있는 문

제이기에 더욱 신중하고 어렵기에 앞서 발생했던 케이

스 연구를 통하여 어떠한 문제가 발생되었고 어떻게

해결될 수 있었는지에 대해서 Compiler의 특성으로

인해 중첩된 IF문 중 일부가 Missing되는 코드로 간략

히 기술하고자 한다.

TEJUMP라는 코드에서 Missing Condition이 발생하

였다. 위의 log정보를 통하여 Missing되는 분기를 찾

을 수 있었다.

표시된 주소값을 따라가보니 아래와 같은 else if문이

missing되었고, Optimization Level을 Disable로 변경

해서도 똑같은 결과가 나왔다.

이전의 예외코드 분석원인 중 중첩된 if문으로

Compiler가 분기들을 최적화해버린 것이 아닌지 확인

하기 위해서 else if 안의 if문이 제대로 작동하는지를

알아보았다.

아래의 표와 같이 AI_Actual_Value의 값을 변화 시켜,

if((TAT_N57DegC <= AI_Actual_Value) &&

Figure. 4 Unit Test Result

Figure. 5 Summary of Dynamic Analysis Results

Figure. 6 Missing Branchpoint

Figure. 7 Test case Deduction

59


(AI_Actual_Value <= TAT_30DegC))의 조건문이 잘

실행되고 있는지 조건문 안의 CaseHtr_Inhibit의 flag

값을 보고 확인해보았다. 그 결과 코드에는 이상이 없

음을 확인하여 문제를 해결할 수 있었다.

Legacy Code 중 동적시험 커버리지를 만족하지 못하

는 원인과 그 해결방안에 대해서 충분히 연구함으로써

다음에 커버리지를 만족하지 못하는 코드들의 검증에

대한 인적, 시간적 비용을 크게 절감할 수 있다. 이러

한 이점을 통해서 더욱 안정적이며, 신뢰성 있는 비행

제어 OFP를 구현하는데 있어 큰 도움이 되어 줄 것이

다.

4. 결 론

비행제어 OFP는 Safety-Critical 소프트웨어이다. 따

라서 무결성 입증 및 방사청의 무기체계 소프트웨어

신뢰성 시험 기준을 만족시켜야 한다. 특히 비행제어

에 관한 유닛 시험은 동적시험의 일반적인 시험대상인

High Level Language에서만 분석하는 것이 아니라

Low Level Language인 어셈블리어를 기준으로 시험

하여 신뢰도 면에서 더 높다.

본 논문에서는 소프트웨어 커버리지의 종류와 그 중

동적 커버리지의 기준 및 이와 관련된 소프트웨어 관

리지침 분석을 살펴보았고 OFP의 신뢰성을 입증하기

위해 동적시험 커버리지 100%를 만족해야하지만 이

목표를 달성하지 못한 Legacy Code들의 원인을 분석

하고 그에 따른 해결 방법에 대해서 살펴보았다.

Legacy Code중 동적 커버리지 100%를 만족하지 못

하는 코드들의 분석을 통해 대부분의 원인이

Compiler의 특성 때문이라는 것을 확인할 수 있었다.

하지만 개발자가 이에 대해 완벽하게 숙지하고 코딩하

기 어렵기 때문에 본 연구를 통해 커버리지를 만족하

지 못하는 원인에 대한 분류와 해결방안을 제시함으로

써 코드의 신뢰성 시험을 수행하는 많은 개발자들이

새로운 코드에 있어 커버리지를 만족하지 못할 경우

그 원인을 분석하는데 소요되는 인력 및 시간의 비용

절감에 기여 할 수 있으리라 기대된다. 또한 이러한

사례를 바탕으로 개발자의 개발 능력 및 시험 성숙도

를 높여 나가고자 한다.

참 고 문 헌

[1] Code Composer Studio User’s Guide (Rev.B), Feb.

2000

[2] TMS320C3x/C4x Assembly Language Tools User’s

Guide. Jun. 1998

[3] 신선영, “비행제어 OFP Unit Test Tool 개발 및 적

용”, 항공우주무기체계발전세미나, 2008

[4] Kelly J. Hayhurst, “A practical approach to MCDC”,

NASA Langley Research Center, IEEE 2001

[5] Paul Ammann, “Coverage Criteria for Logic

Expressions”, ISSRE’03, IEEE2003M. DeWalt,

MCDC, a blistering love/hate relation ship, FAA

National Software Conference, Long Beach, CA,

USA, April 6-9, 1999

[6] 박무혁, “항공용 소프트웨어 개발 및 인증 기술동

향”, 항공우주산업기술동향 5권 1호 2007

[7] RTCA, Inc., December 13, 2000, RTCA/DO248A,

Second Annual Report for Clarification of DO-178B

“Software considerations in Airborne Systems and

Equipment Certification”, Washington, D.C.

[8] James A. Jones, “Test-Suite Reduction and

Prioritization for MC/DC Coverage”, IEEE

AI_Actual_Value CaseHtr_Inhibit

0x0000 Inhibit (0x1)

0xEBF2 Not_Inhibit (0x0)

0xEBF3 Inhibit (0x1)

0x8000 Not_Inhibit (0x0)

0x7FFF Inhibit (0x1)

Table 3 TEJUMP Test case

60

a study of dynamic coverage achievement for flight control...

Documents