1. 서론
초기 우주개발은 각국의 우주 기관에 의해 독립적으로 진행되었고, 독자적인 규격들 을 사용하였다. 상호 협력을 통해 우주 임무 운영을 하고, 상호 교차지원(cross support)을 할 경우 각자 운영하는 것에 비하여 자원의 유휴(Idle) 없이 효과적으로 운영할 수 있다. 이에 기관 간 협력의 필요성을 인식하여 1999년에 프랑스 파리에서 IOP(Inter-Operability Plenary) 회의가 개최되었고, 참여한 6개국 우주 기관은 interoperability를 달성하기 위한 framework에 합의하였다. IOP[1]는 IOAG(Interagency Operations Advisory Group)[2]을 신설하여 우주 기관 간의 interoperability와 관련한 문제들을 해결하도록 하였다. IOAG의 TOR(terms of reference)에는 IOAG의 목적에 대해 정의하고 있는데, 그 중에 상호 협력이 가능한 프로그램 및 이를 위한 임무운영시스템과 서비스를 식별하며 정리한 서비스 카탈로그를 관리하도록 되어 있다. IOAG는 CCSDS(consultative committee for space data systems)[3]와 SFCG(Space Frequency Coordination Group)[4]에서 생성된 표준, 합의, 그리고 기술성과 등의 결과물에 새롭게 추가되거나 보충해야 할 부분에 대한 Feedback을 전달하여 CCSDS와 SFCG에서 추후 Work plan에 반영되도록 한다.
국내의 위성 시스템 구축은 한국항공우주연구원(이하, 항우연)의 주도로 개발되어 왔다. 항우연의 위성 임무 운영 시스템에서는 CCSDS의 표준을 참고하여 개발해 왔으며, 이러한 표준이 지향하는 목표는 상호 기관 간의 interoperability의 완성을 위한 것임을 인식하여 IOAG의 서비스 카탈로그에서 정의한 기능 구현을 위한 정책 및 지원이 뒷받침되어야 하겠다. 본 기술동향서에서는 IOAG 서비스 카탈로그에 대해 기술하고 국내 우주산업에서 국제간 cross support를 통한 효율적인 위성임무운영 방안을 제시한다(Fig. 1).
2. IOAG Service Catalog
IOAG의 서비스 카탈로그는 우주기관 간의 Interoperability를 위한 대상 및 형태에 따라 서비스 카탈로그 #1[5], #2[6], #3[7]으로 구분되어 있다. Fig. 2[5–7]는 각 서비스 카탈로그별 운영 시나리오를 도식적으로 표현한 것이다. OSI7 단계에 따른 구분을 적용하면 IOAG Service Catalog#1는 데이터링크 레이어, #2는 네트워크 레이어, 그리고 #3는 애플리케이션 레이어 간의 규약(protocol)으로 상위 단계의 Catalog는 이전 단계의 규약 및 Catalog를 전제로 한다.
서비스 카탈로그 #1는 ABA 시나리오 상황에서의 정의이다. 우주 기관 A의 임무 운영을 위한 지상 관제 센터(control center)가 우주 기관 B의 안테나 등의 지상 추적 자원(ground tracking asset)을 통하여 우주 기관 A의 위성체(spacecraft) 운영을 하는 경우에 적용할 수 있다. 지상 센터와 지상 추적 자원 간 통신 및 연결은 ground link로 정의하고 지상 추적 자원과 위성체간에는 space link로 정의한다. 서비스 카탈로그 #2는 ABCBA라고 정의한다. Spacecraft가 orbiter와 lander로 분리되었고 각각의 기관들이 운영한다. Fig. 2(b)와 같이 Lander를 가지고 있는 기관 A와 Orbiter를 가지고 있는 기관 B가 C 기관의 지상 관제소를 활용해서 관제가 가능하도록 하는 규격이다. 이 경우 카탈로그 #1에서 보인 시나리오에서 A 기관의 위성체와 B 기관의 지상 추적 자원이 상호 교신이 되는 시간에 임무 운영을 하는 것과는 다르게 카탈로그 #2에서는 A 기관의 착륙선과 B 기관의 위성체, 그리고 C 기관의 지상 추적 자원이 일시적으로 통신이 되지 않는 경우에도 착륙선 임무 운영이 가능하도록 통신 지연을 허용하는 DTN(delay tolerant network) 기반으로 관련 카탈로그의 기능을 정의하고 있다. 카탈로그 #3은 서비스 카탈로그 #1과 2가 정의된 상태에서 기관 간의 cross support를 위한 내용이다. 임무 운영과 관련된 사항으로써 기관들 간의 임무 운영, FDS(flight dynamic systems), MPS(mission planning system) 등의 서비스를 상호 교류하는 개념이다.
카탈로그에서 정의한 기능에 대한 구현이 되면 해당 서비스를 사용하고자 하는 서비스 사용자(service user)와의 합의(agreement) 및 필요에 따라 서비스 제공자(service provider)의 역할을 수행한다. 마찬가지로, 우리의 위성 프로그램을 위해 필요한 서비스에 대해서는 각 국의 서비스 카탈로그를 검색한 후에 제공이 가능한 우주 기관의 합의에 의한 서비스를 제공받을 수 있다.
서비스 카탈로그 #1[5]은 데이터 링크 계층에서 정의되는 상호 지원 가능한 서비스로써 위성 명령 전송과 관련한 forward delivery service, 위성 상태 데이터 수신과 관련한 return data delivery service, 그리고 위성 궤도 분석 등을 위한 입력 데이터 생성과 관련한 radio metric service로 구분된다. 상기 서비스의 내부에는 핵심(core) 서비스와 확장(extended) 서비스로 구성되어 있으며 대부분 국제 표준 기구인 CCSDS에서의 표준 문서를 근거하고 있다. Core service는 IOAG를 구축하는 기관에서는 반드시 제공해야 하는 서비스이며 Extended service는 사용자와 제공자 간의 합의에 의한 서비스로 정의하고 있다. 각 서비스 그룹별 core 및 extended service는 아래와 같다.
서비스 카탈로그 #2에 해당되는 네트워크 계층에서 상호 지원 가능한 서비스는 데이터링크에서 구분한 상위서비스는 동일하나 내부적으로는 DTN 기반 서비스를 핵심 서비스로 하고 있으며, IP 기반 서비스는 확장 서비스로 정의하고 있다. 서비스 카탈로그 #2[6]도 총 세 개의 서비스 그룹(forward data delivery, return data delivery, time service) 및 core service / extended service를 제공한다. 각 그룹별 core 및 extended service는 아래와 같다.
-
Forward Data Delivery Services Group
-
Return Data Delivery Services Group
-
Time service: Time Synchronization Service
서비스 카탈로그 #2는 네트워크 레이어에서 정의되며, 심우주 통신 및 네트워킹을 위해 Node별 지연을 허용한 DTN 등이 핵심이다. CCSDS와 IETF(internet engineering task force) 등의 국제표준화협의체는 DTN 통신 프로토콜에 대한 국제표준화를 진행하고 있다. 특히, CCSDS는 연 2회 미팅을 통해서 표준화 이슈 관리 및 국제 우주 기관의 DTN 구현 시스템 간의 호환성 시험 등을 지원하고 있다.
Catalog#3[7]는 Catalog#1과 Catalog#2를 전제로 하며 기관 간의 교차 지원(cross support) 및 임무 운영(mission operations interoperability services, MOIS)을 하기 위한 개념이다. Catalog#3의 개념 및 예시는 Fig. 2(c)에 나타나 있다. 여기서, Agency B는 인공위성의 본체(BUS)에 대한 소유권을 가지고 있으며, 이에 대한 임무 운영 및 관제를 담당한다. 이 때, Agency A와 C는 payload에 대한 소유권을 가지고 있으며, 임무에 따른 활용을 하고자 한다. Agency B, C는 payload의 활용을 위한 mission request를 Agency A에 보내며, Agency A는 요구사항에 따른 임무를 수행하고 결과물을 B, C에 전달한다. 여기서 Agency A와 C는 MOIS의 서비스의 수요자(requester), agency B와 D는 서비스의 공급자(supplier)가 된다. 실시간 운영 외에도 mission planning이나 flight dynamics와 같은 service를 제공해 줄 수 있다. 그림에서 Agency B가 위성 운영을 위한 flight dynamics를 Agency D에 위탁하여 진행한다.
Fig. 2(c)에는 각각의 운용 기관이 서비스를 요청하고 받기 위한 service request, service response 등이 나타나 있다. IOAG SC#3에서는 응용소프트웨어에서의 교차지원을 위한 최소한의 서비스 목록 및 해당 서비스를 제공하기 위한 필요사항 등을 정의하며 다음과 같은 서비스 그룹이 있다.
-
원격 계측 데이터에 대해 규정한 Telemetry Services Group
-
원격 명령의 상호 이용을 위한 Command Services Group
-
원격 명령 이력 검색을 위한 Command History Distribution Service
-
데이터 이용을 위한 Data Access Services Group
-
임무 계획 상호 이용을 위한 Planning Services Group
-
궤도 결정 및 동역학 데이터 상호 이용을 위한 Navigation Services Group
-
기타 지원을 위한 Support Services Group
-
상기된 서비스 그룹에 공통적으로 적용되는 프레임에 대해 정의한 Interoperability Framework
3. 적용 방안
IOAG Service Catalog #1에 따른 국내 위성의 국제표준화 준용 및 활용 방안에 대해 고찰한다. 서비스의 구축을 위해서는 전략적으로 핵심 서비스를 우선으로 개발을 진행해야 할 것으로 판단하며 신규 개발 및 기존 개발된 COTS를 이용하는 방안에 대해 업무 범위, 기간, 비용측면으로 타당성을 검토하여 개발 전략을 결정하는 행위가 필요하다. 사프란社의 CortexTM 제품으로 상당 부분 구현이 되어 있으며, 국제 기관 간 서비스 교류를 위해 서비스 카탈로그를 고려한 검토가 필요하다.
정지궤도위성의 경우는 고정된 지상 추적 자원을 활용하지 않으나, 대부분의 저궤도 위성의 운영 또는 위성 발사 후 초기 운영 등에서는 위성의 예측 궤적에 따라 안테나 등 지상 추적 자원의 배치가 필요하게 된다. 이러한 위성 추적 자원을 국외에 직접 설치를 하는 경우에는 설치 및 유지보수 비용, 일정 등이 문제가 될 수 있다. 따라서, 직접 설치를 하는 것보다는 기존에 타 기관 또는 영리회사에서 보유하고 있는 위성 추적 자원을 활용하여 위성 운영을 수행하는 방안이 대두되고 있다. 이에 해당하는 서비스는 forward data delivery services, return data delivery services, 그리고 radio metric services로 구성하고 있으며, 내부적으로 운영 센터와 지상 추적 자원과의 접속(ground link) 및 지상 추적 자원과 위성과의 접속(space link)으로 구분하여 핵심과 확장 서비스로 정의하고 있다. 서비스별 소요 기술 등은 CCSDS 등의 표준 문서에 정의되어 있으므로 관련 서비스 개발 시에 참고할 수 있다. Ground link에 대해서는 SLE(space link extension) 기반의 접속 방식이 제공하며 안테나 등의 지상 추적 자원은 SLE 서비스 제공자, 운영 센터는 SLE 서비스 사용자의 역할을 각각 담당한다. 현재 진행 중인 한국형 달 궤도선에서는 SLE 접속을 통해 달궤도선 관제운영센터와 국내 심우주 지상 안테나 시스템 및 미국 NASA의 Deep Space Network간의 위성 명령 전송 및 위성 상태 데이터 수신 등에 적용할 예정이며 궤도선 발사 후에는 SLE 접속에 대한 기능 및 운영 검증을 수행할 예정이다. 한편, 지상 추적 자원과 위성과의 접속 방식은 기존의 전통적인 변복조 방식 외에 CFDP(CCSDS file delivery protocol) 방식을 고려하고 있으며, 또한 Delta DOR, PN Ranging 방식 등은 기존 다목적위성 프로그램에서 적용하지 않은 서비스이기 때문에 해당 서비스에 대한 구현 타당성을 판단할 필요가 있다.
IOAG Service Catalog #2에 따른 국제기관과의 상호 운용에 대해 고찰한다. 해당 서비스에 대한 정의 및 소요 기술에 대해서는 CCSDS의 표준 문서에 정리가 되어 있으며, 해당 서비스의 구현은 기존 개발된 COTS에 부가적으로 DTN의 소요 기술을 신규 개발하는 것이 필요하며, 따라서 전략적으로 prototype의 DTN 개발 및 비행 모델을 통한 검증 방안을 수립하는 것이 필요하다.
Extended 기술인 IP 통신은 기존에 국내에서도 많이 이용하고 있으나 CCSDS 규격에 따르는지 혹은 호환 가능한지 여부에 대해서는 추가 분석이 필요하다. SC#2를 적용하기 위해서는 DTN에 대한 확보가 필수적이다. DTN을 이용한 심우주 통신을 위해서는 시작단과 최종단과의 중간에 중계기(node)를 Spacecraft나 소행성 등에 설치해야 하며, 지연 허용을 위한 Data-storage가 필요하다. SC#2의 기술들은 지구궤도 밖의 통신에서 주목되고 있으며, 달-화성 탐사를 위해서는 필수적이다.
IOAG Service Catalog #3에 따른 국제기관과의 상호 운용에 대해 고찰한다. 우리의 위성 및 관제 시스템 개발은 IOAG에 따른 국제 호환성을 고려하지 않고 독립적으로 개발되었다. 국내의 위성 개수는 점진적으로 증가하고 있으며 2030년대에는 약 70대의 국가 위성을 운용할 계획에 있다. 국제 호환성을 고려한다면 다중 위성 운영에 있어 원격 명령이나 원격 계측의 송수신을 타국 기관의 자원을 이용하여 좀 더 효율적으로 운용할 수 있다. 마찬가지로, 우리가 가지고 있는 Flight dynamics나 Mission Planning 기술을 타국에 제공함으로써 국제사회에서 우리나라 우주기술의 위상을 더욱 높일 수 있다. IOAG Service Catalog #3에 있는 Service들은 각각에 대해 요구조건을 명확히 하고 있다. Service Group 및 Service에 대응되는 항목들을 세부과제 및 세부 기술로 하여 기술 전략을 고찰하고자 한다.
SC#3의 시나리오는 국내에서는 천리안 시리즈와 유사하다(Fig. 3). 천리안위성 1호의 BUS 및 임무 관제는 항공우주연구원에서 담당하며, 3개의 임무 탑제체(기상, 해양, 통신)는 각각 국가기상위성센터, 해양조사원, 한국전자통신연구원에서 각각 담당하고 있어서 상호 유기적인 연계가 이루어진다. 탑재체 운영 기관에서 항우연으로 임무요청(mission request)이 보내지고 해당 임무요청에 따라서 임무계획(mission scheduling) 및 명령 전송이 수행된다. BUS 운영을 위한 실시간 운영 및 비행역학(FDS) 등도 함께 수행이 된다.
항우연의 저궤도 위성에서의 FDS와 MPS는 개별 위성에 대한 모듈화, 다중위성 운영에 대한 통합화 등이 이루어졌다. 지상국에서 개별적으로 개발하는 것 또한 가능하다. IOAG Service Catalog #3의 요구사항을 고려한다면 국내의 FDS 및 MPS 서비스를 국제 기관에 제공하는 것 또한 가능해진다.
