mecㆍviewer v1.4 :: 13. 신현규_특허로 알아보는 위성비행소프트웨어 신기술.pdf

항공우주산업기술동향 15권 2호 (2017) pp. 142~151

http://library.kari.re.kr

에서 보실 수 있습니다.

기술동향

특허로 알아보는 위성비행소프트웨어 신기술

신현규*

New Technologies on Satellite Flight Software with

Patents

Shin, Hyun-Kyu*

ABSTRACT

Satellite flight software (FSW) takes a very essential role on conducting missions of a satellite.

Due to the restrictions of execution environments, FSW requires a very high level of safety and
reliability. To achieve this, various research has been performed. One of the research products is
patent which embodies new technologies in the field of FSW development and verification. This
paper introduces new technologies and trends of FSW with looking into 5 patents recently registered
such as Satellite Status Recorder, techniques on the verification facilities and software configuration
technology.

초 록

위성 본연의 임무 수행에 있어 필수적인 위성비행소프트웨어는 그 운용 환경의 특수성으로 인

하여 고도의 안전성과 신뢰성이 요구된다. 위성비행소프트웨어의 안전성과 신뢰성을 높이기 위
해 다양한 연구가 진행되어 왔는데, 그 산출물 중의 하나인 특허는 위성비행소프트웨어 개발에
필요한 새로운 기술을 담고 있다. 여기서는 위성상태기록장치, 검증환경 관련 기술, 소프트웨어
구성 기술 등 5가지 최신 특허를 통해 위성비행소프트웨어의 새로운 기술과 동향에 대해 알아본
다.

Key Words : FSW (위성비행소프트웨어), Patent (특허), Safety (안전성), Reliability (신뢰성),

Verification Facility (검증환경)

* 신현규, 한국항공우주연구원, 위성연구본부 위성비행소프트웨어팀

hkshin@kari.re.kr

신현규 / 항공우주산업기술동향 15/2 (2017) pp. 142~151

143

1. 서 론

위성비행소프트웨어(FSW: Satellite Flight

Software)는 위성에 탑재되어, 지상으로부터 전

송된 명령을 처리하고, 위성의 상태를 지상으

로 전송하며, 위성에 부여된 임무를 수행한다.

또한, 위성의 여러 상태를 모니터링하며, 이상

상황 발생 시 정해진 절차를 자동으로 실행하

여 위성을 최대한 안전한 상태로 유지하도록

한다.

이처럼 위성 본연의 임무 수행에 있어 없어

서는 안 되는 위성비행소프트웨어는 임무 및

임무 수행 환경의 특수성으로 고도의 안전성과

신뢰성이 요구된다. 일단 발사가 되면, 소프트

웨어의 기능을 변경하거나 문제점을 고치는 일

이 매우 어렵다. 물론, 발사 이후에도 소프트웨

어의 기능을 수정할 수 있는 On-Board

Re-programming 기능을 기본적으로 탑재하고

는 있으나, 이를 이용한 소프트웨어 수정은 매

우 제한적이며, 신중하게 접근하고 있다. 특히

위성의 안전과 관련된 분야는 더더욱 철저한

검증을 수행한 후에 위성으로 명령이 전송되는

데, 6개월이 넘는 지상 시험 및 검증을 거친

후에야 비로소 적용이 된 경우도 있었다.

이렇듯 위성비행소프트웨어에는 매우 높은

수준의 안전성과 신뢰성이 요구되는 만큼, 위

성비행소프트웨어의 안전성과 신뢰성을 높이기

위한 다양한 연구가 활발히 진행되고 있다. 여

기서는 최근 출원되고 등록된 위성비행소프트

웨어 관련 특허를 통해 어떠한 연구가 진행되

고 있는지 알아본다.

2. OVERVIEW

위성비행소프트웨어팀1)은 다목적 실용위성

및 정지궤도 복합위성, 차세대 중형위성, 달탐

1) 한국항공우주연구원 위성연구본부

사를 위한 시험궤도선에 이르는 다양한 위성

프로젝트에서 위성비행소프트웨어의 개발 및

검증 관련 업무를 수행하고 있다. 위성에 탑재

되는 위성비행소프트웨어의 직접적인 개발 뿐

아니라, 안전하고 신뢰성 높은 소프트웨어를 위

한 다양한 연구 및 검증 활동을 함께 수행하고

있다. 이러한 연구의 산출물로 새로운 소프트웨

어 아키텍처, 개발 및 검증 도구와 더불어 새로

운 기술에 대한 특허의 출원도 이루어 지는데,

현재까지 소프트웨어의 요구사항을 관리하거나,

검증 환경을 구축하는 방법 등 다수의 특허가

등록되었다. 여기서는 최근 등록된 특허 중, 위

성의 문제 발생 시 원인 분석에 도움을 줄 수

있는 위성 상태 기록 장치, 검증환경의 구축 및

활용에 사용될 수 있는 메모리 참조방안, 협업

검증 방안, 기존 검증 시스템의 재사용 방법,

위성의 생애주기에 있어 더 이상 수행할 필요

가 없어진 코드를 건너뛰게 함으로써 실행 시

간을 단축하고 하드웨어 오류에 의한 치명적

오작동을 막을 수 있는 자가 수정 소프트웨어

구성 방법 등 5개의 최신 특허를 살펴보고, 그

적용 효과에 대해 알아본다.

3. 위성 상태 기록 장치

특허 제 10-1735166호 ‘위성 상태를 기록하

는 장치 및 방법’은 위성의 문제 발생 시, 원

인 분석을 위한 자료를 제공하는 장치 및 방법

에 대한 것이다. 위성의 상태를 파악하고 정해

진 임무의 수행을 위한 위성비행소프트웨어는

운영 중 발생하는 문제에 대처하고 해당 원인

을 분석하기 위하여 위성의 상태 정보를 기록

하여 문제 발생 시 이를 활용한다.

다목적 실용위성의 경우, CODA (Contingency

Operation Data Area)를 이용하여 소프트웨어가

주기적으로 위성의 주요 상태 정보를 기록하고

소프트웨어가 문제를 인지할 경우, 시스템 리셋

이전에 해당 상태 정보를 기록한 후 시스템을

144

신현규 / 항공우주산업기술동향 15/2 (2017) pp. 142~151

초기화한다.

정지궤도복합위성의

경우에는

Context라는 이름으로 SRAM의 특정 영역을 상

태 저장을 위해 사용한다. 다목적 실용위성에서

의 CODA와 마찬가지로 위성의 주요 상태 정보

를 기록하고, Reconfiguration과 같은 위성의 상

태 변화가 있을 때 문제의 원인을 기록하고, 소

프트웨어에 의한 자동 복구 과정에 활용하고

있다.

이러한 방법으로 특정 메모리에 기록된 위성

의 상태 정보는 오류가 발생되기 직전 또는 직

후에 기록된 단편적인 기록으로, 문제 발생 원

인의 파악에 필요한 정보가 부족할 수 있다.

위성 상태 기록 장치는 위성 시스템의 문제

발생 시, 문제가 일어나기 이전의 일정 시간 동

안 위성 탑재 컴퓨터의 동작을 저장함으로써

보다 많은 정보를 제공하여 문제 분석 및 원인

파악을 용이하게 한다.

그림 1. 위성 상태 기록 장치 – 전체 구성도

위성 상태 기록 장치는 위성탑재컴퓨터 내의

Internal Bus에 Processor Unit과 Trace Buffer를

포함하는 Debug Support Unit (DSU), 그리고

Trace Buffer에 기록된 내용을 저장하는 Status

Recorder가 연결된 구조로 구성된다. Processor

Unit은 위성비행소프트웨어가 동작하는 일종의

CPU로써, Debug Interface를 통해 DSU와 연결

되어 있다.

위성 상태 기록 장치는 DSU가 시스템에서

일어나는 낮은 수준의 Operation을 파악할 수

있고, 이 내용이 Trace Buffer에 일정 기간 –

선입선출에 의해 이전 내용이 삭제됨 – 저장될

수 있다는 점에 착안하였다. CODA 또는

Context에 소프트웨어가 적는 정보는 소프트웨

어가 인지할 수 있는 결과에 대한 내용인 반면,

Trace Buffer에 기록되는 내용은 내부 버스

(Internal Bus)를 통해 전달되는 모든 명령 및

데이터 흐름을 파악할 수 있다는 점에서 문제

발생의 원인을 밝히는 데 효과적으로 쓰일 수

있다.

그림 2. AHB BUS에서의 DSU

DSU는 위의 그림과 같이 개발 단계에서

Debug Communication Link를 이용하여 위성비

행소프트웨어의 디버깅에 사용되는 것으로,

LEON2와 같이 Trace Buffer를 이용하여

Processor 및 Bus의 동작을 일정 부분 기록하

여 개발 및 디버깅에 활용하고 있다.

그림 3. Status Recorder 및 System Monitor

Status Recorder는 System Monitor 등의 위성

시스템의 상태를 감시하고, 문제가 발생할 경

우 시스템의 리셋 및 형상 변경을 유발하는 장

신현규 / 항공우주산업기술동향 15/2 (2017) pp. 142~151

145

치로부터 신호를 받아, Trace Buffer 에 임시로

저장되어 있는 동작 기록을 별도의 메모리 영

역(Safe Guard Memory)에 저장하고, 추후

Processor Unit에서 이를 활용할 수 있도록 한

다. System Monitor는 위성 시스템의 상태를

모니터링하고, 변경할 수 있는 장치로, 다목적

실용위성에서는 RU (Reconfiguration Unit), 정

지궤도복합위성의 경우, MRE (Monitoring and

Reconfiguration Electronics) 가 이에 해당한다.

본 발명 구성에서 System Monitor는 위성의 상

태 변화가 요구될 때, Status Recorder에게 기

록 저장 신호를 보내고, Status Recorder에서

기록에 대한 저장 작업이 종료되면, 시스템 변

경 절차를 계속 수행한다. Safe Guard Memory

는 탑재 컴퓨터의 리셋 및 형상 변경 시에도

해당 내용이 지워지지 않도록 별도의 전원을

공급받는 메모리로 Status Recorder에 의해

Trace Buffer의 복사본이 기록되며, I/O

Manager를 통해 기록된 내용이 Processor Unit

으로 전달되게 된다.

위성 상태 기록 장치는 개발과정에서 디버깅

의 용도로 사용되는 Trace Buffer를 위성의 실

제 운용 시에도 사용할 수 있도록 하고, 시스

템의 리셋 및 형상 변경 등의 이벤트 시, 별도

의 Safe Guard Memory에 시스템의 동작을 기

록하게 함으로써 시스템의 문제 발생 시, 문제

파악 및 원인 분석을 보다 효과적으로 수행할

수 있게 한다.

4. 메모리 참조 방안

특허 제 10-1541008호로 등록된 “소프트웨

어 검증 시스템 및 방법”은 위성비행소프트웨

어를 검증하기 위한 검증 시스템의 구축 시 활

용될 수 있는 기술로, 소프트웨어 내부의 상태

를 보다 쉽게 파악할 수 있도록 하여, 검증 및

디버깅을 효과적으로 수행할 수 있도록 한다.

기존의 검증 환경에서 위성비행소프트웨어는

위성 탑재 컴퓨터 및 이를 모사하는 시뮬레이

터 안에 내재된 일정의 블랙박스 (Black-Box)

형태로, 위성비행소프트웨어가 생성해내는 텔레

메트리(Telemetry)만을 이용하여 위성 및 위성

비행소프트웨어의 상태를 확인할 수 있었다.

또한, 위성으로부터 지상으로 전송되는 속도

의 한계로 인하여, 위성비행소프트웨어 내부의

모든 내용을 텔레메트리로 할당하기 어렵다. 따

라서 위성 운영에 필수적인 내용만을 텔레메트

리로 설정하며, 개발 및 지상 검증 과정에 있다

하더라도 이러한 제약사항은 존재하게 된다.

일반적으로 위성비행소프트웨어는 지상으로

부터 요청받은 특정 메모리 위치의 내용을 지

상으로 내려 보내주는 메모리 덤프 (Memory

Dump)기능을 포함하는 데, 기존의 검증 환경에

서는 이를 이용하여 메모리 덤프를 수행하고,

덤프 결과를 수작업으로 분석함으로써 소프트

웨어 내부의 상태를 파악할 수 있었다.

이러한 분석 방법은 검증 과정에 많은 시간

과 노력을 요구하게 되며, 검증에 쓰이는 테스

트 스크립트 작성 시, 메모리 분석 내용에 종속

적인 부분을 프로그래밍하기 어려운 단점이 있

다. 이 발명에서 다루는 메모리 참조 방안은 이

러한 문제를 해결하여 보다 효과적으로 위성비

행소프트웨어를 검증할 수 있도록 한다.

그림 4. 메모리 참조 방안 – 전체 구성도

테스트 스크립트 (Test Script) 지원부는 테스

트 엔진 (Test Engine)과 테스트 스크립트로 나

누어 볼 수 있다. 테스트 엔진은 테스트 스크

146

신현규 / 항공우주산업기술동향 15/2 (2017) pp. 142~151

립트를 이용하여 검증을 수행하는 과정에서 메

모리 참조 요청 (메모리 참조 요청 구문)을 인

지하게 되면 메모리 참조부에 해당 요청을 전

송한다.

그림 5. 테스트 스크립트에서 메모리 참조 비교

그림 5의 왼쪽은 기존의 방식에서, 텔레메트

리로 할당되어 있지 않은 소프트웨어의 상태

정보를 확인하기 위한 방법을 보여준다. 상태

정보를 얻기 위해서는 확인하려는 상태 정보에

대한 메모리 주소와 크기를 이용하여 메모리

덤프를 수행한다. 덤프 작업이 완료되기를 기

다린 후, 이를 수동으로 확인하고 사용자의 입

력을 받아 처리하도록 해야 한다. 그림 5의

오른쪽에서와 같이 메모리 참조 요청 구문을

지원하는 테스트 스크립트를 사용하는 경우에

는 보다 간략한 표현으로 처리가 가능하다. 지

정된 방식2)으로, 확인하고자 하는 소프트웨어

의 상태 정보를 테스트 스크립트에 표기한다.

테스트 엔진은 메모리 참조 엔진으로부터 해당

내용을 전송 받아 테스트 스크립트의 수행을

계속한다. 이렇게 사용자의 개입 없이 메모리

참조가 가능해지면 메모리 내용에 따라 자동으

로 분기를 처리할 수 있는 조건 판단문을 적용

할 수도 있다.

메모리 참조부는 테스트 엔진으로부터 메모리

참조에 대한 요청을 받아 이를 탑재컴퓨터 또

2) 예제에서는 소프트웨어 변수 앞에 ‘$’를 붙이는 방

법을 사용하였다.

는 시뮬레이터로 전송하고, 값을 획득하여 테

스트 엔진으로 전송한다. 테스트 엔진으로부터

의 메모리 참조 요청은 위성비행소프트웨어 내

의 메모리를 특정하는 여러 형태의 데이터를

포함할 수 있는데, 변수명, 참조명, 주소 등이

사용될 수 있다. 이러한 참조 방법들은 위성비

행소프트웨어 메모리 구성 정보에 의해 메모리

위치 및 데이터 타입 또는 할당 크기를 판단할

수 있다.

메모리 참조 엔진은 소프트웨어 검증 환경의

형상에 따라 2가지 방법으로 메모리를 참조할

수 있다. 실제 탑재컴퓨터 또는 일반 시뮬레이

터를 이용한 검증 환경은 지상 명령과 텔레메

트리만을 이용하여 검증을 진행하는 형상을 의

미한다. 이러한 형상의 경우에는 위성비행소프

트웨어에서 제공하는 메모리 덤프를 이용한다.

테스트 스크립트에 기록된 메모리 참조 요청은

덤프 명령(Dump Command) 및 이에 대한 해석

과정으로 자동 변환된다. 덤프 명령을 통하여,

요청된 메모리 참조에 해당하는 메모리 주소와

크기에 대한 메모리 덤프를 위성비행소프트웨

어로 전송하고, 덤프 해석기 (Dump Parser)는

위성비행소프트웨어가 생성한 덤프 데이터를

해석하여 그 결과를 메모리 참조 엔진에게 전

달한다.

제어 가능한 시뮬레이터는 기존의 검증 환경

과 비교하여 추가적으로 별도의 통신 라인을

갖는 환경을 의미한다. 지상 명령/텔레메트리가

위성비행소프트웨어의 동작에 관련되어 있는

반면, 별도의 통신 라인은 소프트웨어가 동작

하는 환경인 시뮬레이터 자체의 동작을 제어할

수 있다는 점에서 구별된다. 이 통신 라인을

통해 시뮬레이터 안에서 동작하고 있는 위성비

행소프트웨어와의 간섭 없이 시뮬레이터 자체

의 기능으로 위성비행소프트웨어가 동작하고

있는 메모리의 내용을 파악할 수 있다. 검증

환경이 제어 가능한 시뮬레이터로 구성된 경

우, 메모리 참조 엔진은 시뮬레이터 제어기

(Simulator Controller)를 통하여 메모리 참조 요

신현규 / 항공우주산업기술동향 15/2 (2017) pp. 142~151

147

청을 제어 가능한 시뮬레이터로 전송하고, 이

응답을 해석하여 메모리 참조 엔진으로 전달한

다.

이 발명에서 다루고 있는 메모리 참조 방안은

위성비행소프트웨어의 검증 과정에 필수적인

소프트웨어 내부 상태 파악을 기존의 텔레메트

리 기반 방식 및 메모리 덤프의 수동 방식에

의존하지 않고, 테스트 스크립트 내에 메모리

참조 요청 구문을 삽입하고, 이를 해석하여 탑

재 컴퓨터 및 시뮬레이터로부터 해당 내용을

획득하여, 테스트 스크립트의 수행에 활용할

수 있도록 함으로써 보다 효과적인 검증 활동

이 가능하다. 또한, 이를 통하여 테스트 스크립

트를 보다 간결하고 구조적으로 작성할 수 있

으며, 검증 활동에 수반되는 노력과 시간이 절

감된다. 이러한 접근법은 위성비행소프트웨어

의 검증 뿐 아니라 다른 분야의 검증 활동에서

도 같은 효과를 기대할 수 있을 것으로 판단된

다.

5. 협업 검증 방안

‘비행소프트웨어 검증시스템 및 이를 이용

한 비행소프트웨어 검증 방법’은 특허 제

10-1568092호로, 위성비행소프트웨어의 검증 활

동에 있어 다자간 협업을 지원하는 내용을 다

루고 있다.

위성비행소프트웨어의 개발에 수반되는 다양

한 검증활동에는 다양한 위성 명령을 전송하고,

해당 텔레메트리를 수신하며, 정상 동작 여부를

확인하는 과정이 포함된다. 위성의 상태 분석은

다양한 텔레메트리를 해석함으로써 가능해지며,

위성의 전반적인 상태, 소프트웨어의 구성, 각

탑재 전장품들의 세부 상태 등을 나타내는 정

보들로 구성되어 있다. 검증 환경은 이러한 텔

레메트리를 해석하고, 이를 사용자에게 적절한

방법으로 시현해 주어야 한다.

위성의 검증 과정에는 다양한 개발자, 검증

참여자들이 함께 작업을 하며, 각자의 분야가

다르기 때문에 검증을 위해 관심을 갖고 보고

자 하는 텔레메트리의 구성 역시 다르게 된다.

이 발명에서는 위성비행소프트웨어의 개발 및

검증 과정에서 다수의 사용자가 하나의 검증

과정을 공유하며 협업 할 수 있는 방법을 다루

고 있다.

그림 6. 협업 검증 방안 – 전체 구성도

협업을 위한 시스템은 그림 6에서와 같이 위

성비행소프트웨어가 동작할 수 있는 환경인 위

성탑재컴퓨터 또는 시뮬레이터와 위성 명령 및

텔레메트리를 주고받을 수 있는 게이트웨이

(Gateway), 게이트웨이를 이용하여 검증 활동

을 수행할 수 있는 검증 환경으로 구성된다.

전체 구성도에서 검증환경, 검증환경2는 동일

한 검증환경일 수 있으나, 각 검증환경에 포함

된 게이트웨이(게이트웨이(1), 게이트웨이(4))는

위성명령 및 텔레메트리를 재전송하는 역할과

이를 송수신 하는 역할에 있어 차이가 있다.

이러한 검증 환경은 기본적으로 위성탑재컴퓨

터 또는 시뮬레이터와의 연결을 통해 위성명령

을 생성, 전송하거나 전송된 텔레메트리를 해

석하고 시현하는 기능을 포함한다.

자체적인 텔레메트리 해석, 시현 기능을 동일

하게 가지고 있는 검증환경2는 별도의 위성탑

재 컴퓨터 또는 시뮬레이터와의 연결이 아닌

이미 위성 탑재컴퓨터 또는 시뮬레이터와 연결

되어 있는 검증 환경의 게이트웨이를 이용하여

위성 명령의 송신 및 텔레메트리 정보를 수신

하여 이를 해석, 시현한다.

148

신현규 / 항공우주산업기술동향 15/2 (2017) pp. 142~151

게이트웨이(1)은 검증환경2로부터 텔레메트리

재전송 요청을 받게 되면, 위성탑재컴퓨터 또

는 시뮬레이터로부터 전송되는 텔레메트리를

검증환경2로 재전송3)한다. 또한 검증환경이 다

른 검증환경으로부터 전송된 위성명령의 재전

송을 허가한 경우, 해당 검증환경은 이를 위성

탑재컴퓨터 또는 시뮬레이터로 전달한다. 각

검증환경은 위성 명령 및 텔레메트리의 재전송

여부를 사전에 설정할 수 있으며, 만약 이를

허가하지 않은 경우, 연결된 다른 검증환경의

재전송 요청은 수락되지 않는다. 각 검증 환경

은 다수의 검증환경으로부터의 재전송 요청을

수락할 수 있으며, 그림 7과 같은 다양한 구성

이 가능해진다.

그림 7. 다양한 계층구조로 구성

이러한 위성 명령 및 텔레메트리의 체인 구성

은 위성비행소프트웨어 및 위성의 검증 과정에

있어, 다수의 개발자가 하나의 검증 활동을 효

과적으로 수행할 수 있도록 한다. 각 검증환경

간 텔레메트리 재전송의 경우, 해석된 결과가

아닌 위성에서 전송되는 텔레메트리 데이터를

그대로 재전송함으로써, 네트워크를 통해 전달

되는 데이터의 양이 해석된 결과를 공유하는

형태보다 훨씬 적으며, 각 검증 환경이 동일한

해석, 시현 기능을 가지고 있으므로 모든 처리

3) 게이트웨이는 다른 게이트웨이로 데이터를 그대로

전달할 수 있으므로, 재전송 또는 전달이라는 표현
을 함께 사용한다.

를 중앙에서 집중해서 하는 것보다 효과적이

다. 위성 명령의 경우, 최종적으로 위성탑재컴

퓨터 또는 시뮬레이터와 연결되어 있는 검증환

경이 위성 명령의 재전송 수락여부를 결정할

수 있으므로, 검증 활동 및 진행 상황에 따라

다수의 개발자가 독립적으로 위성 명령을 보내

거나, 직접 연결된 검증환경만이 위성 명령을

처리할 수 있도록 하여 권한 설정에 따른 효과

적인 위성 명령 전송이 가능한 장점이 있다.

6. 검증 환경 Wrapper

앞에서 다룬 것처럼 위성비행소프트웨어의

검증에는 위성명령을 전송하고, 전송된 텔레메

트리를 해석할 수 있는 검증 환경이 요구된다.

특허 제 10-1526468호, ‘위성비행소프트웨어

검증시스템 및 위성비행소프트웨어 검증시스템

의 운영방법’은 새로운 위성의 초기 개발 단

계에서 기존에 개발된 검증환경을 사용할 수

있는 방안에 대하여 다루고 있다.

위성 명령 및 텔레메트리의 구조는 개발되는

위성에 따라 다르게 설계될 수 있으며, 이에 따

라 검증 환경 역시 해당 설계 내용을 반영하여

개발되어야 한다. 이는 위성 명령 및 텔레메트

리의 설계가 기존의 위성 개발 프로젝트와 다

를 경우, 이전에 개발된 검증 환경을 그대로 적

용할 수 없음을 의미한다. 따라서 새로운 위성

개발 프로젝트를 위해 기존에 구축된 검증 환

경을 수정하거나 새로 개발해야 하는데, 변경

사항의 적용 및 이에 대한 검증에는 많은 시간

이 소요될 뿐 아니라, 새롭게 개발하는 경우에

는 검증 환경의 구축이 위성 개발 일정에 큰

영향을 미치기도 한다.

이전 위성 개발 과정을 통해 그 유효성이 확

인된 검증 환경의 핵심 기능을 유지하면서 새

로운 위성의 명령 및 텔레메트리 구조를 지원

할 수 있으면, 위성 개발의 초기 단계에서 보다

빠른 개발과 검증이 가능하고, 위성 명령 및 텔

신현규 / 항공우주산업기술동향 15/2 (2017) pp. 142~151

149

레메트리의 설계 변경에도 효과적으로 대응할

수 있다.

그림 8. 검증 환경 Wrapper – 전체 구성도

기존 검증 환경을 적은 노력과 비용으로 새로

운 위성 개발에 사용할 수 있도록 하는 ‘검증

환경 Wrapper’는 그림 8과 같이 구성할 수

있다. 게이트웨이는 기존 검증환경과 위성명령

처리부 및 텔레메트리 처리부를 연결하는 장치

로 위성 명령 및 텔레메트리의 송수신을 관리

한다. 위성명령 처리부는 기존 검증환경에서

생성된 위성 명령을 새로운 위성의 명령 구조

에 맞도록 변환하여 전송한다. 이 변환에는 위

성명령프레임 (Command Frame), 패킷 세그먼

트 (Packet Segment), 전송 프레임 (Transfer

Frame)등 위성 명령을 이루는 각 계층에 대한

분석 및 재구성이 포함된다. 그림 9는 기존 검

증 환경이 생성한 CLTU4) 를 새로운 위성의

CLTU로 변환하는 과정을 보여준다. 텔레메트

리 처리부는 새로운 위성의 텔레메트리를 기존

검증환경에 맞도록 변경하여 게이트웨이로 전

송한다. 이때 위성명령처리부와 마찬가지로 텔

레메트리를 이루는 각 계층 구조에 따른 분석

및 재구성이 요구된다. 그림 10은 서로 다른

텔레메트리 프레임 구성을 갖는 경우의 변환

예이다. 위성명령 및 텔레메트리와 관련된 상

세 내용을 담고 있는 데이터베이스의 경우, 기

존검증환경은 새로운 위성에 맞게 설계된 위성

명령 및 텔레메트리 데이터베이스를 인식할 수

없으므로, 이를 기존검증환경에 맞게 변환한

4) Communications Link Transmission Unit

데이터베이스를 사용해야 한다. 그림 11은 데

이터베이스 변환의 예로 기존의 위성이 텔레메

트리 리스트 내에 상태 정보 해석 방법을 담고

있던 반면, 새 위성에서는 별도의 테이블을 이

용하여 상태 정보 리스트를 관리하는 경우를

타나내고 있다.

그림 9. 위성명령 처리부에서의 변환 예시

그림 10. 텔레메트리 처리부에서의 변환 예시

그림 11. 데이터베이스 변환 예시

검증 환경 Wrapper는 위성의 개발 초기 단계

에서 검증 환경이 구축되지 않았거나, 기능의

미비 등으로 인하여 겪게 되는 어려움을 기존

에 개발된 검증 환경을 적은 비용으로 재사용

할 수 있도록 한다. 또한, 기존 검증 환경과의

차이가 크지 않을 경우, 상당 부분의 검증 기

능을 그대로 활용할 수 있는 장점이 있다.

150

신현규 / 항공우주산업기술동향 15/2 (2017) pp. 142~151

7. Self-Modifying Software

위성의 임수 수행에 필수적인 위성비행소프

트웨어는 위성의 전 수명주기에 대해 대처할

수 있도록 구성되어 있다. 위성이 임무 궤도에

서 본연의 임무를 수행하기 위해서는 지상에서

발사체를 통해 우주로 옮겨진 후, 태양 전지판

의 및 안테나의 전개, 탑재체 초기화 등의 과정

등을 모두 거친 후에 정상 임무 모드로 진입하

게 된다.

위성비행소프트웨어는 이와 같은 일련의 과

정을 수행하기 위하여 탑재컴퓨터 및 위성 탑

재 전장품에 존재하는 신호 및 장치를 이용하

여 소프트웨어의 동작을 결정하고, 정해진 동작

을 수행하게 된다.

내장형 시스템 (Embedded System)의 특성

상, 위성비행소프트웨어는 정해진 주기에 따라

지속적으로 같은 내용을 수행하게 된다. 위성이

정상 임무 모드에 있더라도, 초기 모드 결정 등

에 사용되는 조건문은 더 이상 유효하지 않으

나, 동일 코드 수행에 따라 지속적으로 조건 비

교가 일어나게 되며, 이는 불필요한 수행시간

증가를 야기한다. 또한, 모드 판별에 사용되는

신호의 오작동이 있을 경우, 예상치 못한 결과

가 나타날 수도 있다.

특허 제 10-1733455호 ‘소프트웨어 실행 제

어 방법 및 장치’는 위성의 수명 주기에 따라

변화되는 모드에 대해 소프트웨어 코드 레벨에

서 적절히 대응함으로써, 더 이상 불필요한 조

건문 수행 등에 소요되는 수행 시간을 단축하

고, 잘못된 신호에 의한 위험 동작을 사전에 예

방하는 방법에 관한 것이다.

소프트웨어가 정해진 주기마다 그림 12의 (a)

와 같은 작업을 수행한다고 가정할 때, 이 발명

에서 제시하고 있는 방안을 적용하지 않으면

계속해서 같은 처리를 매번 반복해서 수행하게

된다. 본 발명을 적용할 경우, 위성의 수명 주

기에서 Mode 1이 끝나게 되어 더 이상　Mode

1을 수행할 필요가 없을 경우, (b)와 같이 Mode

그림 12. 자가 수정 방법 적용 예시

신현규 / 항공우주산업기술동향 15/2 (2017) pp. 142~151

151

1에 대한 내용을 건너뛰고 바로 Mode 2의 여부

를 묻는 부분부터 시작하게 한다. 이후 Mode의

변경에 대해 동일한 처리가 가능하며, 더 이상

Mode에 대한 고려 없이 정상 임무 (Normal

Operation)를 수행하는 경우에는, (c)와 같이

Mode 결정에 필요한 내용을 모두 실행하지 않

도록 변경할 수 있다.

이러한 동작은 위성탑재컴퓨터에 로드되어

현재 수행되고 있는 소프트웨어가 자신의 수행

코드 (Machine Instruction)을 변경함으로써 가

능하다. 위와 같이 필요 없는 코드를 수행하지

않도록 하기 위하여, 불필요한 코드 블록의 앞

부분을 해당 코드 블록이 끝나는 지점, 즉 다음

의 내용이 시작되는 곳으로 분기하도록 하는

수행 코드로 대치한다.

그림 13. 블록 분기 테이블

이러한 동작은 자가 수정 (Self modification)

이 필요한 부분과 자가 수정 시 분기할 대상

위치를 저장하고 있는 그림 13과 같은 테이블

을 이용하여 손쉽게 수행될 수 있다. 특정 모드

에 대한 수행이 끝난 경우, 위성 명령을 통해

테이블에 저장되어 있는 내용이 자가 수정되도

록 할 수 있다. 또한 소프트웨어 자체적으로도

자가 수정을 활성화 할 수 있는데, 소프트웨어

에 특정 모드가 끝나면 블록 분기 테이블의 특

정 인덱스를 이용하여 자가 수정하는 기능을

구현해 놓거나 RTCS (Relative-Timed Command

Sequence)와 같은 일련의 순차 명령 집합에 해

당 내용을 포함할 수 있다.

이러한 자가 수정 기능은 더 이상 수행이 불

필요한 코드 블록을 건너뛰게 함으로써, 수행

시간을 단축하고, 위성의 초기 생애 주기에 수

행되는 일련의 작업이 하드웨어 오류에 의해

오작동되는 상황을 미연에 방지함으로써, 보다

안전한 소프트웨어를 구현하는 것이 가능하다.

8. 결론

위성 본연의 임무 수행에 있어서 매우 중요

한 역할을 하는 위성비행소프트웨어는 그 운용

환경의 특수성으로 인하여, 매우 높은 안전성과

신뢰성이 요구된다. 이러한 위성비행소프트웨어

의 안전성과 신뢰성을 높이기 위하여, 앞에서

알아본 것과 같이 탑재 컴퓨터의 구성, 위성비

행소프트웨어 내의 실행 구조, 지상 검증 환경

등 개발 및 검증 분야 전반에 걸쳐 다양한 연

구가 활발히 진행되고 있다. 이러한 연구 결과

가 우리 위성의 성공적인 개발 및 운영에 기여

함과 더불어 다른 산업 분야에도 적극적으로

활용될 수 있기를 기대해본다.

참고문헌

1. 특허 제 10-1735166호, “위성 상태를 기록
하는 장치 및 방법”

2. 특허 제 10-1541008호, “소프트웨어 검증
시스템 및 방법”

3. 특허 제 10-1568092호, “비행소프트웨어 검
증시스템 및 이를 이용한 비행소프트웨어 검증
방법”

4. 특허 제 10-1526468호, “위성비행소프트웨
어 검증시스템 및 위성비행소프트웨어 검증시
스템의 운영방법”

5. 특허 제 10-1733455호, “소프트웨어 실행
제어 방법 및 장치”