mecㆍviewer v1.4 :: [위성] 04_정지궤도 위성의 열제어소프트웨어 설계 및 구현

항공우주산업기술동향 16권 1호 (2018) pp. 63~72

http://library.kari.re.kr

에서 보실 수 있습니다.

기술동향

정지궤도 위성의 열제어 소프트웨어 설계 및 구현

신현규*1)2)

Design and Implementation of Thermal Control

Software for Geo-Stationary Satellite

Shin, Hyun-Kyu*

ABSTRACT

The space environment is very severe especially on thermal condition. Thermal control takes very

essential part of a satellite system for accomplishing own missions. Thermal control system can be
implemented in various way and thermal control software performs fine thermal control on thermal
control areas across the satellite. Design and implementation of thermal control software depends on
thermal condition and mission of the satellite. This paper introduces design and implementation of
thermal control software for geo-stationary satellite with recent research trends.

초 록

위성이 운용되는 우주는 열적으로 매우 혹독한 환경이며, 위성의 임무 수행을 위해서는 열제

어가 필수적이다. 위성의 열제어는 다양한 방법으로 수행될 수 있으며, 열제어 소프트웨어는 위
성 전반에 걸친 열제어 영역에 대해 정밀한 열제어를 수행한다. 열제어 소프트웨어는 위성이 동
작하는 열환경 및 임무에 따라 다르게 설계된다. 여기서는 정지궤도 위성의 열제어를 위한 열제
어 소프트웨어의 설계와 구현 및 최신 연구 동향에 대해 소개한다.

Key Words : Thermal Control System (열제어 시스템), Thermal Control Software (열제어 소프

트웨어), Geo-stationary Satellite (정지궤도 위성)

* 신현규, 한국항공우주연구원, 위성연구본부, 위성본체개발부

hkshin@kari.re.kr

신현규 / 항공우주산업기술동향 16/1 (2018) pp. 63~72

1. 서 론

현대인의 생활에 있어 인공위성은 매우 중요

한 역할을 하고 있다. 자동차의 내비게이션은

GPS 위성으로부터 받은 신호를 이용하여 정확

한 위치와 속도를 결정하고, 이를 바탕으로 길

안내를 한다. 우리가 매일 접하는 날씨 예보

역시 인공위성의 덕을 톡톡히 본다. 그 외에도

위성 방송, 지구 환경 감시 및 연구 등 다양한

분야에 인공위성이 활용되고 있다.

이러한 인공위성이 동작하는 우주는 매우 혹

독한 환경이다. 인공위성이 태양빛을 직접 바

라볼 땐 매우 높은 온도로 뜨거워졌다가, 태양

이 지구에 가려지게 되면 매우 낮은 온도까지

떨어지게 된다. 우주는 10억 분의 1 기압보다

낮은 거의 진공 상태이기 때문에 열대류가 발

생하지 않는다. 특정 부품이 뜨거워지게 되면,

시간이 지나며 주변 공기를 통해 퍼지면서 식

어야 하지만, 우주는 그렇지 못한 환경이다. 반

대로 태양빛을 받지 못하는 경우 위성 내부의

온도가 너무 낮아져 고장이 발생할 수도 있다

[1].

이러한 우주 환경을 견디고, 위성 본연의 임

무를 수행하기 위해 인공위성에는 열제어를 위

한 다양한 장치 및 방법이 적용된다. 열전달을

위한 히트파이프(Heat Pipe), 열 방출을 위한

방열판, 열전달을 차단하기 위한 다층박막단열

재(MLI: Multi-Layer Insulator) 그리고 열을 가

하기 위한 히터 등이 있다. 다른 열제어 장치

가 수동적인 동작 메커니즘을 갖는데 반해, 히

터는 능동적으로 열을 제어할 수 있다. 즉, 장

치의 온도가 정해진 온도보다 낮을 경우 히터

를 켜고, 일정 온도보다 높게 되면 히터를 끄

는 동작을 통해 온도 제어를 수행할 수 있다.

이러한 히터의 동작은 써모스탯(Thermostat)

등 하드웨어에 의해 제어하는 방법과 열제어를

위한 소프트웨어가 히터의 동작을 제어하는 방

법이 있다. 소프트웨어의 의한 방법은 하드웨

어에 의한 제어에 비해 몇 가지 장점을 갖는데

가장 큰 장점은 설정 온도의 변경 및 보다 정

밀한 제어가 가능하다는 것이다. 하드웨어는

목표 온도가 인공위성 발사 전에 하드웨어 설

정에 의해 고정되지만, 소프트웨어는 위성의

임무 기간 중 언제든지 설정 온도를 변경할 수

있다. 이는 위성의 생애 주기에 있어 다양한

목표 온도를 설정할 수 있고, 위성 탑재 장치

의 작동 여부 및 임무 특성 등에 따라 능동적

으로 히터를 제어할 수 있다는 장점이 있다

인공위성에 탑재되는 열제어 소프트웨어는

위성이 작동하는 열환경 및 임무에 따라 다르

게 설계된다. 본 논문에서는 정지궤도 위성의

열제어를 위한 열제어 소프트웨어의 설계와 구

현, 최신 연구 동향을 소개한다.

2. 열제어 소프트웨어

히터를 이용하여 열제어를 수행하기 위해서

는 먼저 열제어를 수행할 영역에 대한 온도를

알아야 한다. 이를 위해 위성의 곳곳에는 온도

측정을 위한 센서가 부착되어 있다. 온도 측정

에 사용되는 센서는 일반적으로 AD590과 써미

스터(Thermistor)가 주로 사용된다. AD590은 센

서의 출력값이 온도와 양의 상관관계가 있는

반면, 써미스터는 두 값이 반비례 관계에 있다.

AD590은 그림 1 과 같이 값이 선형적으로 변

화하며, 써미스터는 비선형적인 특징을 갖는다.

그림 2 AD590 Calibration Curve

신현규 / 항공우주산업기술동향 16/1 (2018) pp. 63~72

하나의 열제어 영역에는 여러 개의 센서가

할당될 수 있으며, 각 센서로부터 입력된 온도

정보는 정해진 방법에 따라 해당 영역의 열제

어를 위한 대표 온도의 계산에 사용된다.

대표 온도가 계산되면, 소프트웨어는 히터

제어 주기에 따라 각각의 히터를 제어한다. 히

터 제어의 기본 방법은 대표 온도가 히터 제어

를 위한 상한 온도(Upper Limit)보다 높으면 히

터를 끄고, 하한 온도 (Lower Limit)보다 낮으

면 히터를 켜는 동작을 수행하는 것이다. 일반

적으로 히터 제어를 위한 명령을 보내기 전에

현재 히터의 상태를 먼저 파악해서, 명령을 보

내야 할 필요가 있을 때에만 보내도록 한다.

그림 2는 열제어 소프트웨어의 전체적인 흐

름을 나타낸다. 앞서 기술한 바와 같이 열제어

를 위한 센서와 히터가 위성의 곳곳에 배치된

다. 아날로그 데이터 획득 장치 (Analog Data

Acquisition Unit)에 의해 센서 데이터가 입력되

고, 전력 제어 장치 (Power Control Unit)는 소

프트웨어 명령에 따라 히터의 On/Off를 수행한

다. 열제어 소프트웨어는 위성의 생애 주기 및

상태에 따라 여러 모드로 구분될 수 있으며,

모드에 따라 히터 제어를 위한 상한/하한 온도

가 달리 설정되는 것이 일반적이다. 이를 위해

그림 2의 상단에서와 같이 모드별로 히터에 대

한 설정 온도가 테이블의 형태(KPD Table1))로

저장된다. 이 값은 사전에 정의되며, 필요에 따

라서는 발사 후에도 변경이 가능하다. 지상 명

령 및 저장 명령에 의해 열제어 소프트웨어의

모드가 변경되면, KPD Table에서 해당 모드에

대한 값을, 실제 히터 제어를 위한 테이블

(Working Copy)로 복사하여, 히터 제어에 사용

한다.

1) Key Parameter Table. 소프트웨어의 동작에 필수

적인  데이터  값으로,  운영  과정에서  지상  명령에
의해  변경될  수  있는  값들을  별도로  저장하고  있는
테이블을  지칭.

그림 3 열제어 소프트웨어의 전체적인 흐름

신현규 / 항공우주산업기술동향 16/1 (2018) pp. 63~72

3. Thermal Control Loop

저궤도 위성의 경우, 요구사항에 따라 처리

방식에 차이가 있기는 하지만, 일반적으로 하

나의 열제어 영역에는 하나의 히터가 활성화되

어 열제어를 수행한다. 하드웨어 고장 등의 예

외 상황에 대처하기 위해 기본 히터(Primary

Heater) 와 예비 히터(Redundant Heater)를 별

도로 배치하더라도, 특정 시점에서는 하나의

히터만 실제 열제어에 사용한다. [2]

그러나 정지궤도 위성은 그림 3과 같이 여러

개의 히터를 하나의 열제어 영역에 사용하는

제어 개념을 갖는다.

그림 4 정지궤도 위성의 히터 제어 개념

그림 3은 Heater 1, Heater 2, Heater 3 의 3

개 히터로 구성된 예를 보여준다. 각 히터는

서로 다른 상한과 하한을 설정 값으로 갖으며,

이 값들은 필요에 따라 오버랩(Overwrap)될 수

있다. 그림은 Heater 1의 하한 온도는 Heater

2의 상한 온도보다 낮고, Heater 2와 Heater 3

의 설정 값들도 영역이 서로 겹쳐짐을 보여준

다. 주변 환경에 의해 온도가 떨어지기 시작해

서 Heater 1의 하한보다 내려가게 되면 Heater

1이 켜지게 된다. Heater 1의 동작으로도 온도

가 크게 상승하지 않고 다시 내려가서 Heater

2의 하한 온도보다 낮게 되면 Heater 2가 켜진

다. 온도가 더 내려가게 되면 같은 방법으로

Heater 3가 켜지게 된다. 이 경우, 하나의 열제

어 영역에 배치된 Heater 1~3가 모두 켜지는

상태이다. 켜진 히터들에 의해서 온도가 올라

가게 되면, 설정 값에 따라 순차적으로 개별

히터가 꺼지면서 온도를 제어하게 된다.

이렇게 하나의 열제어 영역에 여러 개의 히

터를 배치하고, 서로 다른 온도 범위를 갖도록

하면, 온도가 내려가는 정도에 따라 꼭 필요한

히터만을 켜고 끌 수 있기 때문에 전력의 측면

에서 유리한 장점이 있다.

이러한 열제어 처리 방식은 천리안 2A호의

경우 40개2)가 넘는 TCL (Thermal Control

Loop)을 가지며, 이 TCL에 의해 제어되는 히터

는 60개3)가 넘는다.

4. 소프트웨어 설계 및 구현

4.1 TCL 반영

정지궤도 위성의 TCL은 위성의 전력 측면

뿐 아니라, 하나의 제어 영역에 여러 히터를

서로 다른 온도 범위로 제어 할 수 있다는 점

에서 단일 히터 제어에 비해 열제어 측면에서

도 유리하다. 그러나 이러한 TCL 개념은 기존

저궤도 위성의 열제어 소프트웨어에 비해 소프

트웨어의 설계 및 구현을 복잡하게 한다.

TCL의 기본 개념은 온도가 내려갈 때 순차

적으로 여분의 히터를 켜주고, 온도가 올라갈

때는 역순으로 꺼주는 것이다. 개별 히터는

TCL 내에서 Level 1, Level 2 와 같은 형태로

지칭될 수 있고, 온도가 내려가면서 Level 1이,

더 내려가면 Level 2가 켜지는 방식이다. 그런

데 이와 같이 하나의 TCL 내에 존재하는 다른

히터의 상태를 고려하게 되면, 소프트웨어의

복잡성은 증가할 수 밖에 없다.

정지궤도 위성의 열제어 소프트웨어에서는

이러한 복잡성을 TCL과 히터를 서로 분리하고,

2) Propulsion 관련된 TCL 제외

3) Propulsion 관련된 Heater 제외

신현규 / 항공우주산업기술동향 16/1 (2018) pp. 63~72

TCL과 히터의 관계를 별도로 정의함으로써 해

결하였다. 하나의 TCL에서 온도 제어를 위한

대표 온도는 하나이고, 이에 따라 순차적으로

히터가 켜지고 꺼지게 된다. 이를 개별 히터의

입장에서 보면 저궤도 위성의 경우에서와 같이

자신이 속한 TCL의 대표온도가 자신의 대표온

도라고 판단하여 제어를 할 수 있다. 즉, TCL

에 함께 구성되어 있는 다른 히터의 상태와 관

계없이 자신이 가지고 있는 상한/하한 온도 값

에 따라 히터를 독립적으로 켜고 끌 수 있다는

것이다. 그림 4와 같이 2개의 TCL이 각각 3개

의 히터를 갖는다고 하면, 표 1과 같이 TCL

Heater Mapping Table을 이용하여, 각 TCL에

연관된 히터의 번호를 기록한다. 각 히터는 개

별적으로 히터 제어를 위한 상한/하한에 대한

설정값을 갖는다.

그림 5 TCL과 히터

TCL

번호

Level

표 1 TCL- Heater Mapping Table

4.2 센서 데이터 처리

개별 히터를 제어하기 위해서는 히터가 속한

TCL의 대표 온도를 알아야 한다. 하나의 TCL

에는 다수의 센서가 포함될 수 있고, 천리안 2

호 위성에서는 최대 8개4)의 센서를 동시에 처

리할 수 있다.

센서 데이터는 다양한 장치로부터 입력될 수

있는데, 천리안 2호 위성의 경우, 열제어 소프

트웨어를 위한 온도 센서 입력으로 총 3가지의

입력 채널(장치)을 갖는다. 각 채널에 따라 측

정된 신호값으로부터 실제 온도를 얻는

Calibration Curve5)가 다르고, 외부 입력을 처

리하는 소프트웨어6) 내에서의 메모리 위치가

상이하므로 이에 대한 처리도 필수적이다.

이를 위하여 각 센서의 정보는 다음과 같은

내용을 포함하도록 설계하였다.

 센서 번호
 입력 채널 종류
 메모리 위치

각각의 TCL은 자신의 대표 온도를 계산하기

위해 센서 정보를 사용해야 하는데, 이때 사용

되는 센서는 TCL 정보 테이블에 센서 번호로

표시된다. 앞에서 설명한 TCL 1과 TCL 2에 각

각 4개와 5개의 센서가 사용된다고 하면, 다음

과 같이 매핑 관계를 정의할 수 있다.

그림 5에서와 같이 TCL 1에 센서가 1번에서

4번까지, TCL 2에 5번에서 9번까지 할당되어

있다고 하면, 이 정보는 표 2에서와 같이 표현

될 수 있다.

4) Propulsion을 구성하는 TCL의 경우는 하나의 TCL

에 최대 12개의 온도 센서를 할당할 수 있다.

5) 장치에서 얻어진 원본 데이터 (Raw Data)를 전압,

전류, 온도와 같은 엔지니어링 데이터로 변환하기
위한 변환식.

6) 입력 장치에 따라 담당하는 소프트웨어 컴포넌트가

다르다. 예) UART, 1553B 등

신현규 / 항공우주산업기술동향 16/1 (2018) pp. 63~72

그림 6 TCL과 센서

TCL 번호

Sensors

Voting

1,2,3,4

AVG

5,6,7,8,9

MIN

표 2 TCL - Sensor Mapping Table

하나의 TCL에는 여러 개의 센서가 사용되는

데, 대표 온도는 하나가 선택 또는 계산된다.

이때 여러 센서들의 값 중에서 대표 온도를 추

출하는 방법은 여러 가지가 있을 수 있으며,

표에서와 같이 AVG와 MIN 방법7)이 일반적으

로 사용된다.

 AVG : 각 센서들의 평균값을 대표 온도로

설정

 MIN : 각 센서들 중에서 가장 낮은 값을

대표 온도로 설정

AVG와 MIN 방법 모두 센서의 값 중에서 최

고 온도와 최저 온도는 제외한 후, AVG 또는

MIN 방식이 적용된다.

7) Propulsion TCL에서는 TMR이라는 방법을 사용한

다.

4.3 시분할 스케줄링

열제어 소프트웨어는 다른 소프트웨어 컴포

턴트에 비해 처리 주기가 긴 편이다. 저궤도

위성의 경우, 8초 또는 16초를 주기로 하여 센

서 데이터 처리, 히터 제어가 이루어진다. 천리

안 2호 위성의 경우, 10초 주기로 열제어 소프

트웨어가 동작하도록 요구되었다. 저궤도 위성

의 경우에는 모든 센서와 히터를 한 번에 처리

한다. 즉, 동작 주기에 따라 한 번 열제어 소프

트웨어가 구동되면, 이후 8초까지는 센서 데이

터 처리와 히터 제어가 이루어지지 않는다. 그

러나 천리안 2호의 경우, 소프트웨어가 처리해

야할 센서와 히터의 수가 저궤도 위성에 비해

상당히 많기 때문에 이와 같은 방법을 적용하

기 어렵다. 크게 두 가지의 이유를 들 수 있는

데, 첫째 센서 데이터 처리에 드는 시간이 저

궤도에 비해 오래 걸린다. 저궤도 위성에서는

AD590을 많이 사용한다. 앞에서 설명한 바와

같이 AD590은 입력 채널을 통해 얻은 값과 엔

지니어링 데이터인 온도가 선형 함수로 표시될

수 있다. 선형 함수를 이용한 계산은 센서 처

리에 많은 시간을 요구하지 않는다. 그러나 천

리안 2호 위성은 모두 써미스터를 사용한다.

비선형 데이터 추이를 갖는 입력 값으로부터

온도 정보를 얻기 위해서는 Calibration Curve

에 맞게 계산해야 하며, 이는 온도 값 계산에

훨씬 더 많은 시간이 걸리게 된다. 두 번째로

히터 제어를 위한 명령 처리와 관련하여 통신

에 사용되는 명령 대기열이 부족해지는 현상을

막기 위함이다. 통신 인터페이스는 인터페이스

의 종류 및 특징에 따라 한 번에 처리할 수 있

는 메시지의 수가 정해지고, 정해진 방식대로

처리되도록 하기 위하여 메시지에 대한 명령

대기열을 두고 있다. 만약 저궤도 위성에서와

같이 모든 TCL을 한 번에 처리하게 되면, 한순

간에 명령 대기열이 포화되어 더 이상 히터 제

어 명령을 받지 못하는 상황이 발생할 수 도

있다. 물론, 명령 대기열에 보내지지 못한 히터

신현규 / 항공우주산업기술동향 16/1 (2018) pp. 63~72

명령의 경우, 다음 처리 시점 (10초 뒤)에 소프

트웨어에 의해 다시 명령이 시도되므로, 최종

적으로 히터 제어 명령이 수행되지 않는 상황8)

이 발생하지는 않는다. 그러나 이 경우 히터의

제어가 조금 늦게 이루어지므로, 원래 의도한

온도 범위보다 더 넓게 제어될 수 있다. 따라

서 가급적 명령 대기열이 가득 차는 상황은 피

하는 것이 좋다.

이러한 이유로 천리안 2호 위성에서는 TCL

의 처리에 시분할 스케줄링을 도입하였다. 소

프트웨어는 마이너 사이클(100 msec)을 기준으

로 동작하고, 1초에는 10개의 마이너 사이클이

존재한다. 열제어 소프트웨어의 처리 주기가

10초이므로, 모두 100개의 마이너 사이클이 있

고, 한 마이너 사이클에 하나의 TCL 만 처리하

면, 각 마이너 사이클 당 처리 시간 및 명령

대기열에 최대로 추가될 수 있는 명령의 수가

특정 값으로 제한되게 된다.9)

그림 6은 TCL의 시분할 처리 예시를 보여준

다. 홀수 번째 마이너 사이클에서 TCL을 순차

적으로 수행하고 있으며, 10초를 주기로 같은

TCL이 수행되는 것을 볼 수 있다. 이러한 시분

할 처리는 다양한 형태로 구현 가능하며, 천리

안 2호 위성에서는 짝수 번째는 Propulsion

TCL이, 홀수 번째 마이너 사이클은 TCS TCL

이 동작하게 된다.

그림 7 시분할 처리 예시

8) Starvation. 명령을 보냈으나 해당 명령이 처리되지

않는 상황

9) 한 마이너 사이클에 보내지는 명령의 최대수는 하

나의 TCL에 포함된 히터의 수로 제한되게 된다.

5. 열제어 시뮬레이터

천리안 2호 위성은 기존 저궤도 위성에 비해

훨씬 많은 센서와 히터를 포함하고, 센서와 히

터는 TCL을 통해 서로 연관된다. 만약 센서와

히터의 정보가 잘못되면 열제어가 정상적으로

수행될 수 없다. 개발 및 검증과정에서 정보의

오류를 줄이고, 효율적으로 열제어 소프트웨어

를 개발/검증하기 위하여, 열제어 시뮬레이터를

개발, 적용하였다.

5.1 TCLDL

TCLDL (Thermal Control Loop Description

Language) 은 열제어 소프트웨어에서 TCL과

관련된 정보를 표현하기 위해 새롭게 설계된

표현 방식이다. 센서 정보, 히터 정보 및 이들

과 TCL 사이의 상관 관계, 시뮬레이션을 위한

환경 설정 정보 등을 포함한다. TCLDL에는 그

림 7과 같이 센서 이름, 히터 이름, 히터 제어

명령이 EDI DB에 기록되어 있는 축약 이름

(Mnemonic, 니모닉)으로 표현된다.

그림 8 TCLDL 예시

신현규 / 항공우주산업기술동향 16/1 (2018) pp. 63~72

TCLDL로 표현된 정보는 EDI DB와 연동하

여, 열제어 소프트웨어의 동작에 필요한 TCL

Table 파일을 자동으로 생성하며, 열제어 시뮬

레이터는 이 TCLDL을 이용하여 시뮬레이션 및

검증을 수행한다. 이러한 방법을 통해 열제어

소프트웨어의 개발 및 검증에 일관된 방식을

적용함으로써, 개발자의 실수를 줄이고, 개발과

검증의 효율성을 향상시킨다.

5.2 비행소프트웨어 시뮬레이터와 연동

천리안 2호 위성의 비행소프트웨어 개발 및

검증에는 STB (Software Test Bench)와 더불어

GK2 FSS (Flight Software Simulator, 비행소프

트웨어 시뮬레이터)가 사용되었다. GK2 FSS는

천리안 2호 위성의 탑재컴퓨터인 GMU 및 주변

장치를 모사하여, 위성비행소프트웨어가 수정

없이 수행될 수 있도록 한다. GK2 FSS의 도입

은 소프트웨어의 개발, 검증 비용을 획기적으

로 낮추었으며, 실제 하드웨어에 비해 보다 다

양한 테스트가 가능하여 소프트웨어의 신뢰성

향상에 크게 이바지하였다. [3][4]

열제어 시뮬레이터는 이러한 GK2 FSS와 연

동하여 동작하도록 설계, 구현되었다. 그림 8과

같이 GK2 FSS는 탑재소프트웨어의 의해서 생

성된 히터 제어 명령과 시간 정보 (On-board

Time)을 열제어 시뮬레이터로 전달한다. 열제

어 시뮬레이터가 히터 제어 명령을 수신하면,

해당 히터의 상태를 변경하고, 이를 다시 GK2

FSS로 전달한다. 또한 TCLDL에는 히터의

On/Off 시 어떤 센서의 정보를 어떻게 변경할

것인지10)에 대한 내용이 기록되어 있다. 히터

의 상태에 따라 연관된 센서의 온도 정보를 업

데이트하고, 이 정보를 GK2 FSS로 보내어 열

제어 소프트웨어가 온도 변화를 감지하도록 설

계되었다.

10) 시간이 흐름에 따라 센서가 나타내는 온도를 어느

정도로 높일 것인지, 낮출 것인지를 정의하고 있다.

그림 9 GK2FSS와 연동

5.3 외부 환경 모사

저궤도 위성의 경우, 하나의 열제어 영역에

하나의 히터만 동작하므로, 시뮬레이션이 용이

하나, 천리안 2호의 경우 하나의 TCL 내에 여

러 개의 히터가 동시에 동작할 수 있기 때문에

단순히 히터가 켜지면 온도를 높이고, 꺼지면

낮추는 방법을 그대로 적용하기 어렵다. 이를

위해 TCLDL 내의 Thermistor-Heater Mapping

구문을 통해 히터의 On/Off 상태가 연관된 써

미스터의 온도 정보를 어떻게 업데이트 하는지

기술한다. 이와 함께 열제어 시뮬레이터는 위

성의 전반적인 열적 상태를 온도 변화에 적용

하는 방법을 제공한다. 외부에서 열이 유입되

어 전체적으로 온도가 오르거나, 외부로 열을

빼앗겨 온도가 내려가는 상황을 TCLDL의 수정

없이 시뮬레이션 과정에서 모사할 수 있다.

5.4 시뮬레이션 및 검증

구현된 열제어 소프트웨어가 정상적으로 동

작하고, 주어진 요구 사항에 부합되는지를 검

증하기 위하여 열제어 시뮬레이터를 이용한 시

험을 수행하였다.

TCLDL에 정의된 센서, 히터 및 TCL 정보를

바탕으로 열제어 소프트웨어에 사용될 TCL 테

이블이 자동으로 생성된다. 이 테이블을 포함

하는 열제어 소프트웨어를 빌드하여 GK2 FSS

에서 동작시키면, 열제어 시뮬레이터는 전달받

은 히터 제어 명령을 수행하며, 센서 및 히터

상태 정보를 업데이트한다.

신현규 / 항공우주산업기술동향 16/1 (2018) pp. 63~72

시뮬레이션 하고자 하는 TCL은 TCLDL의

Simulation TCL 구문을 통해 지정할 수 있는데,

TCLDL의 다른 부분을 수정할 필요 없이 실제

시뮬레이션을 수행할 TCL의 번호를 지정함으

로써 TCL에 대한 시뮬레이션을 수행할 수 있

다.

그림 9는 많은 수의 TCL을 동시에 시뮬레이

션하는 모습을 보여준다. 일반적으로 지상 시

험에서는 위성 개발 후반기에 수행하는 열진공

시험을 제외하고는 열제어 소프트웨어의 검증

을 전체적으로 수행하기 어렵다. ETB11)와 같은

환경에서는 정해진 수의 센서와 히터를 이용하

여 한정된 수의 열제어 영역 (TCL 등)에 대한

시험을 수행하기 때문에, 위성이 운영되는 환

경에서의 전반적인 모습을 검증하기 어렵다.

열제어 시뮬레이터는 소프트웨어적으로 센서와

히터를 모델링하고, 한 번에 수행 가능한 TCL

의 수에 대한 제약없이 전체 TCL에 대한 시험

을 수행할 수 있다. 이를 통해 열제어 소프트

웨어가 정해진 스케줄링에 따라 각각의 TCL을

처리하고, 센서 정보 처리 및 히터 제어가 정

상적으로 수행되는 지를 검증할 수 있다.

11) Electrical Test Bed

6. 결론

한국항공우주연구원은 2018년 4~5월에 걸쳐

천리안 2A호 위성의 열진공 시험을 성공적으로

수행하였다. 이 시험을 통해 그동안 개발된 천

리안 2A호 위성이 우주 환경에서 주어진 요구

조건을 충족함을 확인하였으며, 열제어 소프트

웨어 측면에서도 요구 사항을 만족하고 있음을

검증하였다. 이러한 열제어 소프트웨어는 기존

의 저궤도 위성에 비해 많은 수의 센서와 히터

를 처리하며, 독특한 제어 요구 사항을 갖는

등 보다 높은 복잡도를 가진다. 열제어 소프트

웨어를 효과적으로 개발하고 검증하기 위해 센

서와 히터, TCL 사이의 관계를 재정립하고, 시

분할 처리를 도입하였으며, 개발과 검증에 일

관성을 부여하기 위해 TCLDL을 고안하고, 적

용하였다. 열제어 소프트웨어의 시뮬레이션과

검증을 위해 위성비행소프트웨어 시뮬레이터와

연동되는 열제어 시뮬레이터를 개발, 적용하였

다.

이를 통하여 저궤도 위성과는 다른 요구사항

을 갖는 정지궤도 위성의 열제어 소프트웨어를

효과적으로 개발하였으며, 그 유효성을 검증하

였다.

그림 10 시뮬레이션 화면 예시

신현규 / 항공우주산업기술동향 16/1 (2018) pp. 63~72

앞으로 추가적인 연구를 통해, 보다 다양한

시나리오를 효과적으로 검증할 수 있는 기법과

함께, 위성의 열해석 모델 및 3D 모델과 열제

어 시뮬레이터를 연동하여 보다 실질적인 시뮬

레이션을 수행하고, 검증 결과를 시각적으로

보다 쉽게 확인할 수 있는 방법을 개발하고자

한다.

참고문헌

1. https://blog.kari.re.kr/ , 한국항공우주연구원

블로그, “독방에 인공위성이 갇힌다?”

2. 이재승 외, “저궤도 관측위성의 히터제어를

위한 위성비행소프트웨어의 설계”, 항공우

주기술, 제 10권, 제 1호, 2011년, pp.141-148

3. 최종욱 외, “위성 탑재소프트웨어 개발을

위한 프로세서 에뮬레이터 및 위성 시뮬레

이터 개발 현황”, 한국항공우주학회 학술발

표회, 2015년, pp.775-782

4. 신현규 외, “위성비행소프트웨어 통합검증

환경의 설계 및 구축”, 항공우주기술, 제

11권, 제 1호, 2012년, pp.49-56