• 한국정보처리학회:학술대회논문집
• /
• 한국정보처리학회 2013년도 추계학술발표대회
• /
• pp.1070-1073
• /
• 2013

위성 비행 소프트웨어의 개발 과정에는 소프트웨어의 신뢰성을 향상하기 위한 다양한 검증 활동이 이루어진다. 이러한 검증 활동에는 효율적으로 설계된 검증 환경이 필수적이다. 위성 비행 소프트웨어 개발 전반에 검증 환경을 효과적으로 적용하기 위해서는 사용 가능한 검증 환경이 보다 빠르게 구현되어야 한다. 검증 환경은 개념적으로 궤도 상의 위성과 통신하는 지상 시스템의 역할을 기본으로 하고 있으므로 Command 송신과 Telemetry 수신을 위성 비행소프트웨어와의 상호 작용으로 정의할 수 있다. 따라서 위성 비행소프트웨어의 동작을 Command와 Telemetry 관점에서 모델링하고 이를 모사하는 시스템을 이용함으로써 위성 개발 초기부터 위성 비행 소프트웨어 검증 환경 구현에 사용할 수 있고, 또한 위성 개발 과정에서 발생하는 다양한 변경 사항을 보다 효과적으로 반영할 수 있다. 본 논문에서는 위성 비행 소프트웨어의 검증 환경 구현을 위한 Command Telemetry Simulator의 설계 및 그 구현에 대하여 소개한다.

• 한국정보처리학회:학술대회논문집
• /
• 한국정보처리학회 2011년도 추계학술발표대회
• /
• pp.76-79
• /
• 2011

천리안 위성은 우리나라 최초의 정지궤도 복합 지구관측 위성으로 기상관측, 해양관측과 통신서비스 임무를 수행하는 중대형위성으로 2011년 6월 27일에 성공적으로 발사되어 약 6개월간의 시험운영기간을 거쳐 현재는 실시간 서비스를 제공하고 있다. 천리안 위성은 한국항공우주연구원(KARI) 총괄 주관하에 2003년 9월 개발을 시작으로 프랑스의 EADS-Astrium과 공동 개발되었다. 천리안 위성은 이미 EADS-Astrium에 의해 통신 위성 본체 플랫폼으로 우주 인증된 Eurostar3000(이하 E3000) 플랫폼을 근간으로 제작되었다. 본 논문에서는 천리안 위성 플랫폼 탑재컴퓨터에 탑재되어 위성체 전반을 운영하는 비행소프트웨어의 구성 및 기능에 대해 기술한다. 또한 기존의 EADS-Astrium사의 E3000 비행소프트웨어 생산라인을 바탕으로 천리안 위성 비행소프트웨어를 개발하기 위한 개발 절차 형상을 소개한다. 본 논문에서 기술한 재생산을 위한 개발 절차에 대한 접근 방법은 위성 임베디드 소프트웨어 시스템과 같은 mission critical 시스템이면서 이미 검증된 소프트웨어를 재사용하고 사용자의 요구사항을 만족시키기 위해 일부 기능을 변경 및 추가 개발하여 통합된 소프트웨어를 생산해야하는 소프트웨어 개발체계의 실질적인 한 예를 보여주고 있다.

• 한국정보처리학회:학술대회논문집
• /
• 한국정보처리학회 2012년도 추계학술발표대회
• /
• pp.844-847
• /
• 2012

인공위성의 개발은 오랜 기간에 걸쳐 다양한 분야의 전문가들에 의해 개발된 결과물들이 통합되어 완성될 수 있다. 위성개발과 같이 많은 개발자가 공동으로 작업하여 하나의 결과물을 생산하는 경우 개발과정에서 방대한 양의 문서작업이 수반된다. 특히 비행소프트웨어와 같이 서로 다른 개발자에 의해 작성된 코드들이 하나의 이미지로 통합되어 빌드될 경우 발생하는 문제점들을 해결하고 요구되는 기능들을 디버깅하기 위해서는 개발과정 및 소스코드에 대한 문서들이 필수적이다. 이러한 소프트웨어 설계에 대한 문서는 그 양이 방대하고 소스코드와의 연계성이 필요하기 때문에 소스코드를 작성한 각 개발자들이 직접 수작업으로 문서를 작성하였다. 예를 들면, 기존의 위성비행소프트웨어 개발과정에서는 이러한 문서들 중 전체 위성비행소프트웨어의 단위 코드별 입출력, 수행기능 등의 상세 설계 내용을 기록하는 SDD(Software Design Description)는 개발자가 작성한 코드를 기반으로 수작업을 통하여 작성되었다. 이러한 작성방식은 작성자의 입력오류가 발생할 수도 있으며 소프트웨어 개발과 별도로 수작업이 요구되어 문서작성에 소요되는 시간적 손해가 발생하게 된다. 유럽에서는 이러한 문제점을 보완하기 위하여 C, C++, C#, JAVA, VHDL 등 다양한 언어를 사용하는 소프트웨어 개발에 적용 가능한 자동적 문서작성 도구인 Doxygen을 설계 및 개발문서 작성에 활용하고 있다. Doxygen은 PDF, HTML, Latex, RTF 등 다양한 출력 포맷도 지원한다. 본 논문에서는 Doxygen을 활용하여 위성비행소프트웨어 개발문서의 작성 시 소요시간을 단축하고 소스코드로부터 해당 설계 내용을 추출하여 자동적으로 문서를 작성할 수 있는 방안에 대하여 소개한다.

• 천문학회보
• /
• 제37권2호
• /
• pp.158.1-158.1
• /
• 2012

위성비행소프트웨어는 위성의 하드웨어와 임무 탑재체 및 서브시스템이 통합되어 궤도상에서 위성임무를 수행할 수 있도록 원격명령 및 측정데이터의 처리, 자세 및 궤도제어, 열제어, 전력제어 등의 기능을 수행한다. 위성비행소프트웨어의 개발과 같이 규모가 큰 소프트웨어는 여러 개발자가 참여해야 하고 각각의 개발자들이 작성 코드를 통합하여 빌드하고 문제 발생 시 대처하기 위하여 세부적인 설계 및 개발내용을 단계별로 문서화하는 작업이 수반되어야 한다. 기존의 위성비행소프트웨어 개발과정에서는 이러한 문서들 중 전체 위성비행소프트웨어의 단위 코드별 입출력, 수행기능 등의 상세 설계 내용을 기록하는 SDD(Software Design Description)는 개발자가 작성한 코드를 기반으로 수작업을 통하여 작성되었다. 이러한 작성방식은 작성자의 입력오류가 발생할 수도 있으며 소프트웨어 개발과 별도로 수작업이 요구되어 문서작성에 소요되는 시간적 손해가 발생하게 된다. 유럽에서는 이러한 문제점을 보완하기 위하여 C, C++, C#, JAVA, VHDL 등 다양한 언어를 사용하는 소프트웨어 개발에 적용 가능한 자동적 문서작성 도구인 Doxygen이 널리 활용되고 있다. Doxygen은 PDF, HTML, Latex, RTF 등 다양한 출력 포맷도 지원한다. 본 논문에서는 Doxygen을 활용하여 위성비행소프트웨어 개발문서의 작성 시 소요시간을 단축하고 소스코드로부터 해당 설계 내용을 추출하여 자동적으로 문서를 작성할 수 있는 방안에 대하여 소개한다.

• 한국정보처리학회:학술대회논문집
• /
• 한국정보처리학회 2010년도 추계학술발표대회
• /
• pp.921-924
• /
• 2010

정지궤도 위성을 제외한 대부분의 저궤도 위성 및 심우주 관측용 위성은 임무를 수행하면서 하루동안에도 제한된 시간동안만 지상국과의 통신이 가능하다. 따라서 위성 운영에 고수준의 자율적 제어기능이 요구된다. OBCP(On-Board Control Procedures)는 별도로 개발된 언어로 작성한 작은 용량의 스크립트 프로그램을 통해 위성을 제어하는 기능을 제공한다. 이러한 방법을 통해 지상관제 시에 위성의 임무수행동안 수행되어야 하는 다양하고 복잡한 운영 시퀀스를 용이하게 준비하고 업로드할 수 있다. OBCP는 위성비행소프트웨어와는 분리된 별도의 서브시스템으로 수행되기 때문에 새로운 위성운영 프로시져의 생성을 위해 위성비행소프트웨어의 수정, 재검증, 코드업로드 등의 절차가 요구되지 않으며 지상에서 개발 및 검증시험을 완벽하게 수행할 수 있다. 본 논문에서는 기존의 저궤도 관측위성에서 사용되었던 위성의 자율적 제어 시퀀스 기능과 OBCP의 기능을 비교하여 설명하고, 실제 Herschel and Plank 위성에 활용된 예를 통해 OBCP의 개념 및 설계 방안에 대하여 소개한다.

• 항공우주기술
• /
• 제11권1호
• /
• pp.49-56
• /
• 2012

위성의 기본적인 상태를 모니터링하며 자세 제어 및 위성 고유의 임무를 수행하는 위성비행소프트웨어는 운용 환경 및 그 특수성으로 인하여 매우 높은 수준의 신뢰성이 요구된다. 이를 위하여 개발 과정에서 다양한 활동이 이루어지게 된다. 실제 하드웨어 또는 하드웨어를 모사하는 시뮬레이터를 통해 위성비행소프트웨어를 동작시키고 지상 명령의 전송, Telemetry의 수신을 통한 검증의 경우, 매우 다양한 지원환경이 요구된다. 위성비행소프트웨어팀에서는 이러한 검증 활동을 보다 효과적으로 수행하고 이를 통해 소프트웨어의 신뢰성을 향상하고, 다양한 위성 개발에 공통으로 사용될 수 있는 위성 비행 소프트웨어 통합 검증 시스템을 구축하고 있다. 본 논문에서는 위성비행소프트웨어의 효과적인 검증을 위한 통합 검증 시스템의 설계 및 구축 방안에 대하여 소개한다.

• 천문학회보
• /
• 제37권2호
• /
• pp.226.1-226.1
• /
• 2012

위성에 탑재되어 위성의 상태를 모니터링하며, 지상으로부터 명령을 받아 위성 본연의 임무 수행이 가능하게 하는 위성비행소프트웨어는 그 개발단계에서 다양한 검증활동이 이루어진다. 설계 검증 및 리뷰, 인스펙션을 거쳐 소스 코드로 구현된 후, 단위 시험을 통해 가장 낮은 수준의 검증을 거치게 된다. 이러한 단위 시험은 개별 함수에 대해 입력에 따른 해당 출력 및 동작 여부를 검사하게 된다. 단위 시험이 하나의 함수에 대한 시험 항목이라는 점은 검증대상의 스코프가 좁다는 장점이 있으나, 다른 모듈과 연동되었을 경우에 발생할 수 있는 다양한 경우를 고려하여 테스트 케이스를 작성해야 하는 어려움이 있다. 이러한 문제점을 해결하기 위하여 단위 시험과 함께, 연관된 함수가 이미 구현되어 있는 경우, Stubbing을 하기보다는 직접 해당 함수를 사용하며, 또한 동등한 수준의 개별 함수들을 주어진 시나리오에 따라 동작하는 Compound Test를 활용, 그 결과를 확인하는 방법을 도입하였다. 이를 이용하면 단위 시험에서는 검증하기 어려운 상황별 시나리오에 따른 검증 활동을 수행할 수 있고, 또한 전체 위성비행소프트웨어를 빌드할 필요없이 테스트의 대상이 되는 함수만을 이용, 나머지 부분은 기존의 방식을 그대로 적용할 수 있어, 위성비행소프트웨어의 안전성 및 신뢰성을 보다 향상시킬 수 있다.

• 항공우주기술
• /
• 제10권1호
• /
• pp.141-148
• /
• 2011

저궤도 관측위성에는 버스 히터, 탑재체 히터, 배터리 내부 히터 등 다양한 히터들이 각각의 해당 영역에 대한 열제어를 위해 존재한다. 이러한 히터들의 제어는 서미스터에 의해 수행되거나 비행소프트웨어에 의해 제어될 수 있다. 각 히터들은 설치된 위치, 텔레메트리로 전송하기 위한 분류, 사용되는 서브시스템 등에 따라서 여러 형태의 그룹으로 나눌 수 있으며, 비행소프트웨어에서는 히터제어를 위한 정보들을 다양한 배열에 저장하는데 각 히터마다 고유의 인덱스를 부여하여 구분하는 방법을 사용할 수 있다. 각 히터들이 분류하는 방식에 따라 서로 다른 그룹에 속하기도 하고 비행소프트웨어 로직에서 사용되는 히터정보가 어느 히터, 또는 어느 그룹의 정보인지를 판별하는데 어려움이 있을 수 있다. 본 문서에서는 저궤도 관측위성의 일반적인 히터 제어를 위한 비행소프트웨어의 설계에 대해 기술하고, 히터들의 그룹 및 배열의 활용과 특별한 관리가 필요한 히터들의 제어방식에 대하여 설명한다.

• 한국우주과학회:학술대회논문집(한국우주과학회보)
• /
• 한국우주과학회 2003년도 한국우주과학회보 제12권2호
• /
• pp.58-58
• /
• 2003

과학위성 1호의 컴퓨터 시스템은 지상국 명령 및 데이터 처리, 위성 자세 제어, 위성체 운용, 상태 감시, 탑재체 운용, 배터리의 충방전 제어 등을 담당하며, 우리별 3호 위성을 통하여 검증된 컴퓨터 시스템을 기반으로 개발되었다 과학위성 1호의 컴퓨터 시스템은 탑재 컴퓨터(On-board Computer)와 비행 소프트웨어(Flight Software)로 구성된다. 과학위성 1호의 탑재 컴퓨터는 우리별 3호의 탑재 컴퓨터에 비하여 FPGA를 사용함으로써 크기 및 무게의 소형화를 추구하였고, 네트워크 제어기를 내장함으로써 통신 성능의 개선을 이루었다. 그리고 EEPROM을 장착하여 위성 운용 기간 도중에 발생할 수 있는 소프트웨어의 변경에도 대응하였다 과학위성 1호의 비행 소프트웨어는 우리별 3호의 비행 소프트웨어를 기반으로 하여 과학위성 1호의 명령 및 데이터 처리 시스템과 임무에 적합하도록 개발되었다.

• 한국위성정보통신학회논문지
• /
• 제12권3호
• /
• pp.93-97
• /
• 2017

위성의 임무 수행 도중에 발생하는 소프트웨어 버그는 치명적인 문제점을 야기하여 위성 전체의 임무 실패를 초래할 수도 있다. 이를 막기 위해 개발단계부터 수많은 테스트와 검증을 수행하여 비행소프트웨어가 높은 신뢰도를 지니도록 만들어 준다 [1]. 하지만 위성이 발사 후 궤도에 올라갔을 때 하드웨어 측면에서의 문제, 혹은 미 발견 버그 등의 예상치 못한 문제들이 발견될 수도 있다. 이 경우 비행소프트웨어를 궤도 상에서 수정해야만 위성이 지속적으로 임무를 수행할 수 있다. 본 논문에서는 저궤도 위성의 reprogramming capability를 확인하고 reprogramming 절차에 대해 알아보고 검증한다.