큐브위성의 시스템 설계 및 제작을 위한 시스템 공학

큐브위성을 활용하여 수행하고 하는 임무의 목적이 시스템 개발을 위한 기술적 요구사항으로 잘 정의되었는지를 확인하기 위해 시행되는 회의이다. 일반적으로 이 검토회의에서는 임무의 정의와 목적이 시스템의 구성과 개발에 필요한 요구사항으로 잘 반영되어 있는지를 검토한다.

임무의 정의와 요구사항을 바탕으로 작성된 시스템 기초 설계서를 검토, 수정, 확정하기 위해 시스템 수준의 설계가 진행된 시점에서 시스템 요구 조건을 만족하는지를 확인하는 검토회의이다. 위성 개발 프로세스를 체계적·단계적으로 점검 및 관리하기 위해서 위성 시스템, 본체, 탑재체, 지상국 등의 시스템 기본설계에 대한 검토한다.

위성 버스 및 임무 탑재체에 대한 예비설계 결과물이 상세설계에 진입해도 되는지 보증하고 기술된 성능 요구사항이 비용, 성능, 위험 및 기타 제약사항에 부합하는지를 검토하는 기술 검토회의이다. 이 검토회의에서는 시스템 전체의 예비설계를 평가하게 되며, 위성체를 구성하는 서브시스템과 탑재체의 각 형상 항목 성능 규격(기능 기준선)에 대해 평가한다.

임무 수행을 위해 설계된 위성체가 제작, 시연, 시험 단계로 진입해도 되는지를 보증하고 기술된 성능 요구사항에 부합하는지를 확인하는 기술 검토회의이다. 이 검토회의에서는 서브시스템과 탑재체 최종 설계와 완성도를 평가하며 위성체 전체 형상 항목의 제작 규격(제작 기준선)에 대해 평가한다.

위성체를 구성하는 서브시스템과 탑재체에 대한 공식적인 시험평가(통합 기능 시험, 환경시험 등을 모두 포괄)를 착수할 준비가 되어 있는지 확인하기 위한 것으로 시험목적, 시험방법 및 절차, 시험항목 및 기준, 시험범위 및 안전성을 평가하기 위해 수행한다. 또한, 시험에 필요한 시설 및 장비, 인력 등의 자원이 계획된 시험을 수행하기 위해 적절하게 식별되어 있는지를 확인한다.

제작된 위성체 요구사항에 대한 검증 및 입증 확인, 통합 및 환경시험 결과 보고, 임무 수행 운영 지침, 지상국 운영 지침을 점검하고 위성의 발사장 선적 및 운송 계획 및 절차, 발사장 운영 계획 등을 검토하는 회의이다.

Pre-Phase A와 Phase A 단계는 임무의 개념설계를 수행하는 단계로 임무 목적과 임무 요구사항을 결정하고 임무 해석을 통해 임무 설계를 수행한다. Phase B는 예비설계 단계로 Phase A에서 결정된 임무 설계를 바탕으로 시스템의 요구 조건을 정립하고 탑재체와 버스 서브 시스템(구조계, 열 제어계, 전력계, 통신계 등)의 예비설계를 수행하며, 주로 검사, 해석 시험 등의 방법을 통해 예비설계에 대한 검증을 수행한다. 특히, 큐브위성의 임무 탑재체는 상용 기성품을 주로 사용하는 서브 시스템과 달리 직접 제작하는 경우가 상당수이므로 개발 시제품(breadboard model, BM 혹은 prototype model)의 제작과 시험을 통해 예비 설계된 탑재체의 임무 실현 가능성을 판단하고, 개발 모델(developing model, DM)로 발전시켜 상세 설계 결과에 반영하는 것이 바람직하다. 세 번째 단계인 Phase C는 상세설계 단계로 사실상 위성의 모든 설계를 마무리하는 단계이다. 이 단계에서는 임무 요구사항과 시스템 요구사항을 바탕으로 모든 서브 시스템의 요구사항이 정립이 완료되고, 위성의 운용 시나리오와 상세한 운용 모드 설계도 거의 마무리되어야 한다. Phase D는 상세설계 내용을 토대로 시스템을 제작·통합·테스트(assembly, integration and test, AIT)하는 단계로 엔지니어링 모델(engineering model, EM)을 제작하고 서브시스템과 임무 탑재체에 대한 기능, 성능 검증을 수행한다. 또한, 비행 모델(flight model, FM)과 동일한 인증 모델(qualification model, QM)을 제작하고 발사/우주 환경시험을 수행하며 상세 설계 단계에서 수행하였던 해석과 비교하여 최종 비행 모델 개발의 발사 및 궤도 운영 적합성을 확인하게 된다. 다만, 큐브위성 개발과정의 특성상 짧은 개발 기간과 예산의 한계로 인해 엔지니어링 모델과 인증 모델을 제작하지 못하는 경우, 비행 모델을 이용하여 발사/우주 환경시험을 바로 수행할 수도 있다. 다만, 이러한 경우 발사/우주 환경시험의 최대 극한 조건이 적용된 인증(qualification) 시험조건으로 시험을 진행하되 시험 시간을 기준이 완화된 수락(acceptance) 조건을 적용하여 진행하여야 한다. 또한, 엔지니어링 모델과 인증 모델이 결합된 형태로도 제작이 가능하며 엔지니어링-인증 모델(engineering-qualification model, EQM)의 발사/우주환경시험은 인증시험 조건을 사용한다.

시스템공학의 기술 프로세스의 핵심 중 하나는 위성체를 구성하는 버스와 탑재체의 설계 프로세스를 거쳐 조립 통합 과정 전반에 할당된 시스템과 서브시스템 레벨의 요구사항에 대한 검증이다. 요구사항에 대한 일반적인 검증 방법으로는 검사-분석-시연-시험이 대표적이다. 검사는 육안 점검이나 관련 기록(data sheet, 제조사에서 제공하는 시험 보고서 등)의 점검을 통해 검증하는 방식으로서, 주로 대상물의 외형, 치수, 마감 상태 등의 형상 특성이나 발사 및 우주환경시험 기록 등을 확인하는 방식이다. 분석은 해석이나 실험 결과를 바탕으로 검증하는 전통적인 방식으로서, 해석 모델이나 실험 결과의 상사성이 물리적으로 타당해야 한다. 분석을 통해 검증할 경우에는 모델링의 부정확성이나 실험 조건의 오차 요인을 감안하여, 검증 여유분을 충분히 두어야 한다. 시연은 BM과 같은 시험 장비나 DM, EM과 같은 위성 개발 모델을 이용하여 실제 하드웨어나 소프트웨어의 기능적 성능이나 운용 특성을 검증하는 방식이다. 시험은 일반적으로 비용, 안전, 용이성, 일정 등의 측면에서 어려움이 없는 경우 일반적으로 사용되는 검증방식으로, 요구사항에 부합하는 환경조건에서 대상물의 성능을 직접 측정하는 방법이다. Table 1에는 시스템공학의 기술 프로세스에서 사용되는 검증 방법을 정리한 것이다.

이해를 돕기 위해서 일례로 시스템공학의 기술 프로세스를 살펴보도록 하자. 가령 스스로 발광하는 큐브위성을 이용해서 지상에서 망원경으로 관측하는 과학(교육) 임무를 설계한다고 가정해 보자. 첫 번째 Phase인 개념설계 단계에서 우선 수행해야 할 일은 스스로 발광하는 광원을 어떻게 구현하느냐와 얼마나 밝은 광원을 사용하면, 지상에서 망원경으로 관측 가능 한가의 문제를 과학적 분석 등을 통해 결정하는 것이다. 연구팀의 의사결정 과정을 통해 큐브위성에 LED(light emitting diode)를 광원으로 하는 임무 탑재체를 설계·개발하기로 결정했고, 분석 결과 LED 광원의 밝기가 절대등급으로 10등급 이하일 때 지상에서 망원경으로 관측 가능하다는 결론에 도달했다면, 이러한 내용이 임무 요구사항에 반영되어야 한다. Table 2는 앞서 언급한 내용을 정리한 임무 요구사항의 예이다.

앞서 설명한 바와 같이 시스템공학 기술 프로세스의 주안점은 임무목적을 달성하기 위해서 위성을 구성하는 탑재체, 각각의 서브시스템 등을 유기적으로 통합 관리하고, 제한된 자원(예산, 인력, 개발 인프라, 일정 등)을 최대한 활용하여 요구사항에 부합하는 위성 설계를 수행하고 Top Down 방식으로 제작·검증·확인하고자 하는 종합적인 공학적 활동이다. 따라서 Table 2에 정리된 임무 요구사항을 근거로 Phase A 말기부터 Phase B 사이에서 수행되어야 시스템 공학적 기술 프로세스는 하위 레벨인 시스템의 요구사항으로 고도화하는 작업이다. Table 2에서 MR-01은 위성의 개발과 동시에 자연적으로 모든 개발 팀에게 주어지는 임무 요구사항의 예이며, MR-02는 연구팀의 임무 개념설계의 결과로 도출된 임무 요구사항이다.

MR-01의 임무 요구사항으로부터 여러 개의 시스템 요구사항이 파생될 수 있지만, Table 3에 제시된 것과 같이 가장 대표적인 사항은 발사체의 발사 규정에 부합하도록 위성 시스템을 구성하고 이를 구속할 수 있는 요구사항을 도출하는 일이다. 결국 임무 요구사항 MR-01로부터 개발 초기 시스템의 설계를 구속할 수 있는 SYS-SS-07과 같은 시스템 요구사항을 전체 시스템에 할당할 수 있다. 그리고 이렇게 할당된 시스템 요구사항은 시스템 요구사항 검토회 의(SRR)와 시스템 설계 검토회의(SDR)를 통해 요구사항의 만족 여부를 검토하게 되며, Table 3에 제시된 바와 같이 제품의 사양서 등의 검토(inspection, I)를 통해 적합성(compliance) 여부를 검증할 수 있다.

MR-02는 MR-01과 다르게 임무 탑재체의 기능과 관련된 임무 요구사항으로 MR-01과 마찬가지로 여러 개의 시스템 요구사항으로 분기될 수 있다. 이는 임무 요구사항 MR-02가 LED 탑재체의 광원의 밝기와 관련되어 있어 탑재체에 공급되어야 할 전력량(EPS 및 배터리의 선정 등)을 비롯하여 광원 발열부의 최적 수동 열 제어를 위해 탑재체 형상에 직접적으로 영향을 미칠 수 있기 때문이다. 하지만, 여기서는 전력량에만 한정 지어 시스템 요구사항 도출한 예를 살펴보자. 우선 MR-02의 핵심 요구 조건인 절대등급의 밝기는 위성과 지상 관측

점과의 거리에 따라 달라질 수 있으므로, 지상 관측점과 위성 사이의 앙각(elevation angle)에 따라서 달라지는 거리가 설계 과정에 충분히 반영되어야 한다.

Fig. 2는 지상 관측점과 위성 사이의 앙각에 따라 달라지는 위성-관측점 간의 거리를 도시한 결과이다. 그림에 도시된 결과로부터 앙각이 30도 이상의 경우(관측점과 위성 간 최대 거리가 900 km 이내인 조건)만 임무를 수행하도록 시나리오 설계를 하였다면, 이론적 해석을 통해 앙각의 변화에 따라 지상 관측점에서 계산된 LED 광원의 밝기가 절대등급 기준 10등급 이하를 유지하기 위해서는 최소 20 W의 전력이 안정적으로 공급되어야 하는 것을 확인할 수 있다(Fig. 3). 이 해석 결과를 바탕으로 임무 요구사항 MR-02에 구속되는 시스템 요구사항 SYS-SS-55를 도출할 수 있고 도출 타당성은 시스템 요구사항 검토회의를 통해 점검해야 한다.

Fig. 2. Calculated distance between ground observation point and satellite as a function of elevation change.

Download Original Figure

Fig. 3. Calculated power required to meet system requirements with elevation angle.

Download Original Figure

앞서 기술한 바와 같이 MR-02와 SYS-SS-55는 시스템 기능과 관련되어 있는 요구사항이다. 따라서 시스템 설계 검토회의 통해 MR-02와 SYS-SS-55의 요구 조건에서 제시하고 있는 기능 구현 여부를 검증하여야 한다. 통상 요구사항에 제시된 기능 만족 여부를 판단하기 위해 사용되는 검증 방법은 앞서 기술한 바와 같이 시험(test)이다. 따라서 시험을 통해 요구사항에서 제시되고 있는 기능의 만족 여부를 검증하기로 의사결정이 이루어진 경우, 개발 초기 단계(~Phase A) 임을 감안하여, Fig. 4에 제시된 바와 같이 LED 탑재체의 BM을 제작하여 기능 적합성을 판단할 수 있다.

Fig. 4. Example of configuration of an LED payload BM. LED, light emitting diode; BM, breadboard model.

Download Original Figure

Fig. 5는 Fig. 4에 제시된 LED 탑재체 BM의 실제 구동 시 실시간으로 측정된 전력을 도시한 결과이다. 그림에 도시된 PWM(pulse width modulation)을 적용하여 LED 드라이버를 구동시키면 LED의 on-off 제어는 물론 공급되는 전력을 약 20 W로 안정적으로 유지할 수 있 는 것을 확인할 수 있다. 앞서 기술된 일련의 설계 과정과 검증 결과를 바탕으로 시스템 설계 검토회의에서 GO 판정을 내리게 되면 다음 단계인 Phase B(예비설계)로 진입할 수 있다. 이렇듯 시스템 설계 요구사항에서 제시된 기능을 충족시키게 되면 Phase A 개념 설계 단계의 시스템 기능 기준선에 부합되는 것이며, 이때 BM 시스템의 구성이나 구동 방식, 전기적 인터페이스 등은 형상관리를 위해 문서화되어야 하고 추후 변경해야 하는 경우, 반드시 관리자의 승인을 얻어야 한다.

Fig. 5. Measurement of the supply power of the LED payload. LED, light emitting diode.

Download Original Figure

Table 2와 Table 3에 제시한 임무와 시스템 요구사항은 예시이므로, 실제 시스템 요구사항 검토회의와 시스템 설계 검토회의에서는 전체 임무와 시스템 기능을 정의하기 위해 도출된 요구사항에 대해서 만족 여부를 검증하고 시스템의 형상관리를 위해 기능 기준선을 할당한 뒤 다음 단계로 진입하여야 한다. 예비설계(Phase B)와 상세설계(Phase C) 단계에서도 앞서 기술 내용을 서브시스템 레벨로 확장하여 요구사항을 도출하고 동일한 검증 과정을 반복하게 된다. 다만, 예비설계와 상세설계 단계에서 기능적 측면의 시스템 형상관리를 위해 할당되는 기준선은 각각 할당 기준선과 제품 기준선으로 명명하게 된다. 상세설계에서 제시된 요구사항의 검증이 완료되면 마지막 단계인 위성 시스템의 조립·통합·시험 단계(Phase D)에 진입하게 된다. 이 단계 진입 직후 시험 준비 검토회의(TRR)를 수행하여 통합 시험 및 발사/우주환경시험에 대한 준비도를 점검한 뒤, 최종 조립된 상태에서 위성 전체 시스템의 기능과 성능을 확인(validation)하는 절차를 거치게 된다. 최종 확인된 위성 시스템의 기능과 성능이 임무 목적에 부합되면 선적전 검토회의(PSR)을 통해 그 내용과 결과를 최종 검토하게 된다.

시스템공학의 활동 중 기술 관리 프로세스는 통합 사업 관리, 요구사항 관리, 위험 관리, 형상관리 등을 수행하는 것을 의미한다. 먼저 통합 사업 관리는 전체 사업 관리 및 진행을 위해 개발 단계별 목적에 맞는 기술 검토회의 및 시험준비 검토회의(TRR), 선적전 검토회의(PSR) 등의 주요 회의를 준비하고 원활하게 수행할 수 있도록 지원한 것이다. 아울러 단계별 요구사항과 시스템 기능의 기준선, 검증 결과 등을 체계적으로 정리하여 기술문서를 생산하고 관리하는 것을 목적으로 한다. 형상관리는 시스템 개발의 전주기 동안 요구되는 설계/운용 조건에 맞도록 해당 제품의 성능, 기능 및 물리적 특성이 일관성 있게 유지되도록 관리하며 변경을 통제하고 형상 현황을 개발 단계에 따라 기능 기준선(SRR/SDR), 할당 기준선(PDR), 제품 기준선(CDR)을 설정하여 체계적으로 관리하는 것을 의미한다. 위험관리는 시스템 개발의 전주기 동안 위험 요소의 조기 식별과 적절한 완화 계획을 수립하고 적용함으로써 사업의 일정, 비용, 성능 등 사업에 부정적 영향을 미칠 수 있는 위험을 수용 가능한 수준으로 최소화하는 것으로써 위험 관리 계획 → 위험 식별 → 위험 분석 → 위험 대응 → 위험 감시의 순으로 대응할 수 있는 관리 체계를 통해 구현될 수 있어야 한다[2]. 아울러 Table 4에는 각 단계별 검토회의와 생산 문서를 요약한 것이다.