2015 년도 한국철도학회 춘계학술대회 논문집 KSR2015S264

철도차량용 소프트웨어 소스코드 검증방안 연구

A Study on Software Source Code Verification Methods used for the Railway Vehicles 강치용†, 조치환, 공명상, 강찬용

Chi-Yong Kang†, Chi-Hwan Cho, Myung-Sang Kong, Chan-Yong Kang

Abstract The software used for railway vehicle control is generally embedded in microprocessor-based system. Considering that target device on which the software to be installed and its intended function, performance, size, price, etc., suitable microprocessor should be selected and then relevant hardware/software will be installed for its use. When developing software for embedded system, we should consider that it has limited resource unlike general purpose computer. Particularly, embedded software development has potential risks due to the fact that its development environment is not corresponds to its actual execution environment. This paper will introduce some source code verification methods to get rid of potential risks and to improve software quality of railway vehicle. Keywords : Railway vehicle software, Embedded, Source code verification 초 록 철도차량 제어를 위한 소프트웨어는 마이크로프로세서 기반의 임베디드 시스템 형태로 탑재된다. 제어 대상 장치에 따라 알맞은 기능, 성능, 크기, 가격 등을 가진 마이크로프로세서를 선택하여야 하며, 이에 맞는 하드웨어와 소프트웨어를 개발, 설치하여 사용한다. 일반적인 범용 시스템과 달리 임베디드 시스템은 가용 리소스가 다소 한정되어 있어 소프트웨어 설계 시에 고려할 점이 많고, 특히 소프트웨어 개발환경과 실행환경이 다르다는 점에서 잠재적인 오류를 내포하기 쉽다. 본 논문에서는 철도차량에 탑재되는 소프트웨어의 잠재적인 품질을 향상시키기 위한 몇 가지 소스코드 검증 방안을 소개한다.

주요어 : 철도차량 소프트웨어, 임베디드, 소스코드 검증

1. 서 론

전통적인 철도차량용 소프트웨어들은 그 기능들이 매우 단순하고 간결한 구조를 지녔었다.

이 소프트웨어들은 오랜 기간 변경 없이 사용되며 그 자체로 안정성 및 신뢰성을 입증해왔

다. 시대가 흘러 국내외 철도차량 고객사들은 점점 더 다양한 편의/안전기능들을 제공하는

철도차량을 구입하기를 원하게 되었고, 제작사에서는 이 기능들을 주로 소프트웨어적으로

구현하여 하드웨어 대비 높은 공간 효율과 확장성을 확보하고 있다.

이처럼 철도차량에서 소프트웨어가 차지하는 비중은 점점 증가하는 반면, 철도차량 소프

트웨어 개발의 현주소는 소프트웨어 공학적 개발 프로세스 적용보다는 납기를 맞추기 위한

코드 생성과 기능시험 중심의 기존 개발 방식을 고수하는 경우가 많아, 소프트웨어 고장이

자주 발생하고 있다. 하드웨어와 달리 눈에 보이지 않는다는 점에서 고장을 분석하기도, 예

측하기도 어려운 소프트웨어는 개발 프로세스에 초점을 맞추어야만 그 품질의 향상이 가능

하다. 소스코드 검증은 소프트웨어 개발 프로세스간 품질보증 활동 중 가장 직관적인 품질

향상 방법 중 하나이며, 크게 정적분석 기법과 동적분석 기법으로 구분한다.

† 교신저자: 현대로템 응용기술연구팀(cdragon@hyundai-rotem.co.kr)

2. 본 론

2.1 정적분석 기법 (Static Analysis)

소스코드 정적분석은 프로그램을 실행하지 않고 예상되는 소프트웨어적 결함을 찾아내는 것

으로, 소스코드에 내재한 논리적 오류나 비효율을 찾아내는 기법이다. 설계서와 소스코드간

추적성 분석을 위한 동료검토 등의 수작업을 포함하여, 프로그램에 대한 이해가 있는 사람이

상용 툴의 도움을 받아 분석하는 방법 등을 의미한다. 철도차량 소프트웨어는 일반적으로 코

드를 문법이나 구문 기반으로 분석하는 Syntactic Analysis 와 의미 기반으로 분석하는

Semantic Analysis 두 가지 기법을 활용하는데, 이 절에서는 상용 툴을 활용한 기법을 위주로

설명하고자 한다.

2.1.1 문법 기반 분석 (Syntactic Analysis)

컴파일 에러를 일으키는 일반적인 문법 오류들은

컴파일러에서 검출되므로 논외로 하고, 이 절에서는

코딩표준(Coding Standard)에 대해서 언급한다. 코딩

표준은 특정 산업 영역에 적합한 소스코드를 작성할

수 있도록 개발언어별로 제정된 표준 문서이다. 국내

철도차량 소프트웨어는 대부분 C언어로 개발되므로

Motor Industry Software Reliability Association에

서 2004년 제정한 Fig. 1의 MISRA-C 코딩표준이 주로

통용되고 있으며, 이는 121개의 필수 규칙과 20개의

권고 규칙으로 구성되어 있다. MISRA-C는 자동차 산

업을 위해 작성된 모델이지만 현재 철도차량 외에도

우주/항공, 의료장비, 국방 등 광범위하게 적용되고

있는 가이드라인이다.

Fig. 2는 MISRA-C:2004 규칙 중 한가지 예이다. 이

규칙은 전체 소스코드 내 도달 불가능한 코드가 없어

야 함을 명시하고 있다. 이러한 코드는 그 자체로 아

무 의미도 갖지 않으며 프로그램 실행 시 어떠한 영

향도 미치지 않을 것이다. 하지만 일부 프로그램에서는 실행 중 외부 입력을 통해 도달 불가

능한 코드에 접근하는 경우도 있으므로, 문법만으로는 실행 중 결함을 정확히 판단할 수 없다

는 점을 알 수 있다.

Fig. 1 MISRA-C:2004

Fig. 2 An example of MISRA-C:2004 rule

코딩표준 준수 여부는 시판되는 툴의 도움을 받아 검증할 수 있다. 다양한 종류의 정적분석

툴이 존재하는데, 이 툴들은 사용되지 않는 변수나 코드, 정의되지 않은 변수의 사용, 묵시적

인 형 변환 등 코딩표준에서 정의하는 주요 규칙들을 검증할 뿐만 아니라 모듈 사이즈, 주석

률, 코드 순환복잡도(Cyclomatic Complexity) 등의 다양한 품질지표(Metric)를 수집하여 개발

자에게 제공함으로써 정량적인 소스코드 품질 측정을 돕는다.

2.1.2 의미 기반 분석 (Semantic Analysis)

문법분석이 코드의 겉모습이나 패턴만 보고 결함을 검출하는 방식이라면, 의미 기반 분석은

프로그램의 실행 흐름과 각 프로그램 구문의 의미를 이해하여 실행 중 프로그램 상태를 예측

하는 기술이다. 철도차량 소프트웨어 안전성 규격인 KS C IEC 62279에서도 안전기능을 수행하

는 소프트웨어에 대해서 자료 흐름 분석(Data Flow Analysis) 및 제어 흐름 분석(Control

Flow Analysis)을 수행하도록 요구하고 있으며, 문법분석과 마찬가지로 이를 위해 시판되는

상용 툴들이 존재한다.

Fig. 3은 시판되는 정적분석 툴들을 이용하여 나타낸 소프트웨어의 제어 흐름도(예시)이다.

정적분석 툴은 소스코드의 각 모듈과 함수를 분석하여 제어의 흐름을 읽어내고 이를 도식화하

여 보여준다. 의미 기반 분석 툴의 특징은 프로그램의 실행 중 상태를 예측하는 것으로, 문법

상으로는 이상이 없음에도 변수의 흐름에 따라 결함을 야기할 수 있는 경우를 찾아내는 것이

다. 개발자는 이 툴들을 이용해 널 포인터 역참조(Null pointer dereference)나 메모리 누수

(Leak), 배열 참조오류(Buffer Over/Underrun) 등의 예상되는 메모리 문제들을 확인할 수 있

다.

Fig. 3 Examples of control flow chart

철도차량은 하위 장치(Subsystem)의 규모에 따라 각각 별도의 임베디드 시스템이 탑재된다.

이 임베디드 시스템들은 우리가 일반적으로 사용하는 PC처럼 범용이 아닌, 특정 목적만을 위

해 탑재되는 것이므로 충분한 메모리를 가지고 있지 않다. 메모리가 할당 후 지속적으로 회수

되지 않는 경우 프로그램이 비정상적으로 종료하게 되므로, 개발자들은 소프트웨어 개발 시

메모리 누수를 충분히 고려해야 한다. 의미 기반 분석 툴은 이 같은 메모리 누수를 개발자에

게 경고해주며, 프로그램의 크기가 커질수록 그 진가를 발휘한다.

2.2 동적분석 기법 (Dynamic Analysis)

동적분석은 정적분석과 달리 프로그램을 실행하며 결함을 찾아내는 방법이다. 의미 기반의

정적분석은 입력 값의 범위를 추상화하여 결과를 예상하는 방식이지만, 동적분석은 특정 값을

입력하여 산출되는 결과를 확인하는 것이므로 검출된 결함이 항상 정확하다는 장점이 있다.

동적분석에 있어서 가장 중요한 것은 테스트 케이스를 만드는 것이다. 테스트 케이스란 시험

을 수행하기 위한 상황(Condition), 이벤트(Event), 입출력 값 등을 포함하는 데이터를 말하

며, 요구 명세를 정확히 반영하고 있는 테스트 케이스 집합을 만들어 내는 것이 동적분석의

핵심이다.

동적분석에서는 ‘테스트 커버리지’라는 단어가 등장한다. 구문(Statement), 분기(Branch),

MC/DC(Modified Condition/Decision Coverage) 등의 커버리지가 존재하는데, 각 경우에 따른

테스트가 얼마나 충분히 수행되었는지를 말해주는 척도이다. 철도차량 분야에서는 KS C IEC

62279 규격을 통해 안전기능을 수행하는 장치에 한해 커버리지를 측정하여 기록하게 되어있으

며, 더 높은 안전등급이 요구되는 장치일수록 더 까다로운 기준의 커버리지 분석을 요구한다.

프로그램이 수행 가능한 모든 조건/분기를 테스트하는 것은 사실상 불가능하므로 대부분 툴

을 사용하여 테스트케이스 일부를 자동 생성하는 방법을 이용한다. 자동 생성이 불가능한 테

스트케이스는 개발자/테스터가 수동으로 입력해주어야 하는데, 이 때가 테스팅 단계 중 가장

많은 시간과 노력이 필요한 부분이자 많은 개발자들이 동적분석을 어려워하는 이유 중 하나이

다. 이를 개선하기 위해 현재도 효과적인 테스트케이스 자동 생성법에 대한 다방면의 연구가

활발히 진행 중이나, 이러한 툴들은 상당히 고가이므로 국내 철도업계에는 적용이 쉽지 않은

것이 현실이다.

2.3 철도차량 소스코드 검증의 한계

임베디드 시스템 개발의 가장 큰 특징은 개발환경(호스트 시스템)과 실행환경(타겟 시스템)

이 다르다는 것이다. 따라서 임베디드 소프트웨어 개발을 위한 툴체인이 존재하고, 소스코드

검증 툴도 이 타겟 시스템과 툴체인의 특성을 고려하여 커스터마이징(Customizing) 하여야 한

다.

소스코드 정적분석 툴은 프로그램 실행 없이 요약 도메인(Abstract Domain)을 토대로 분석

을 수행하므로 필연적인 오탐(False Positive, 결함이 아님에도 결함으로 판단하는 것)이 존

재한다. 가장 기본적인 예로, 특정 기능 구현을 위해 개발자가 의도적으로 무한(지연)루프를

삽입하였다고 하자. 이 루프는 어떤 외부입력을 받아 조건에 맞는 경우 탈출하도록 설계되어

있다. 하지만 코드 자체만으로는 탈출을 예상할 수 없으므로 결함으로 판단하게 된다. 이러한

오탐은 개발자의 툴에 대한 신뢰도를 떨어뜨리고, 그들로 하여금 학습효과를 일으켜 분석의

질이 나빠질 수 있다.

다른 예로 특정 타겟 시스템/크로스컴파일러 특성에 따른 문제도 있다. 임베디드 환경에서

는 처리 속도 향상을 위해 비트 단위 연산(Bitwise Operation)을 자주 사용하는데, 컴파일러

에 따라 변수의 첫 비트를 부호로 사용하지 않는 경우가 있다. 툴에서 이러한 컴파일러의 특

성을 온전히 반영하지 못하는 경우 잘못된 형변환으로 판단하는 경우가 생기게 된다.

철도차량에는 장치별로 다양한 형태의 임베디드 시스템이 탑재되므로 이러한 커스터마이징

오류는 정적분석 툴 선택 시 오탐율과 함께 반드시 고려할 사항 중 하나이다.

Fig. 4 Definition of false positive and false negative

동적분석 툴은 프로그램 실행환경에서 동작하므로 일단 검출된 결함은 항상 정확하고 오탐

이 존재하지 않으나, 미탐(False Negative, 결함이 있음에도 발견하지 못하는 것)이 존재한다

(Fig. 4 에서 오탐과 미탐의 개념을 비교해 볼 수 있다). 위에서 언급했던 것처럼 어떤 커버

리지를 적용하냐에 따라 분석의 심도가 달라지는데, 심도가 깊어질수록 기하급수적으로 증가

하는 실행 경로의 수가 필연적인 미탐을 야기하게 된다. 높은 미탐율은 물론 분석의 신뢰성을

떨어뜨리는 것이지만, 여기서 중요한 점은, 무조건 높은 커버리지를 지향하기보다는 프로그램

이 정확하게 요구사항을 반영하고 있는지를 확인할 수 있는 양질의 테스트 케이스를 개발하는

것이며, 동시에 이에 필요한 공수를 최소화 하는 것이다. 따라서 국내 철도차량용 소프트웨어

개발 절차에서는 요구사항 정의 단계부터 미리 테스트 케이스를 개발하도록 하여 요구사항의

시험 누락을 방지하고 있고, 동적분석을 실시하는 경우 테스트의 효율성을 극대화 할 수 있다.

3. 결 론

소스코드 검증에 있어서 오탐/미탐율이 낮고 우수한 성능을 가진 검증 툴을 선택하는 것도

중요한 일이지만, 가장 중요한 것은 소프트웨어 개발자로서의 책임감이다. 특히 소프트웨어

개발자들은 자신이 개발한 소프트웨어를 시험할 때 자신이 원하는 기능의 동작(요구사항 구

현)만을 생각하며 시험해서는 안 된다. 소프트웨어는 결함이 표면적/직관적으로 드러나지 않

는다는 특성 때문에 기능 동작 확인 위주의 시험만 실시해보고 지나치기 쉽고, 이 경우 잠재

적 위험들이 여전히 존재하게 된다.

지속되는 국내 철도차량 소프트웨어 개발 인력부족과 소프트웨어 품질에 대한 인식 부족은

개발자로서의 책임감과 사명감을 떨어뜨려 소프트웨어의 품질을 저하시킨다. 세계적인 소프트

웨어 강국으로서, 이제는 소프트웨어 테스팅의 중요성을 깨닫고 장차 고품질의 경쟁력 있는

철도차량을 개발하는 나라가 되기를 바라면서 이 논고를 마친다.

참고문헌

[1] 정인상 (2013) Software Engineering : Automated Test Data Generation for Dynamic Branch

Coverage, 정보처리학회논문지, 2권 7호, pp.451-460.

[2] Sanjeev Sahrawat (2013) Combined testing approach with static and dynamic techniques, International

Journal of Computer Trends and Technology, Vol.4 No.7, pp.2014~2016.

[3] The Motor Industry Software Reliability Association (2004) MISRA-C:2004 Guidelines for the use of

the C language in critical systems.

[4] KS C IEC 62279 (2004) 철도용 전기설비의 통신 및 신호 처리 시스템과 제어 및 보호시스

템에 관한 소프트웨어.

[5] BS EN 50128 (2011) Railway applications-communication, signaling and processing systems-

Software for railway control and protection systems.