← 목록으로

leo-satellite-operations-scheduling-and-commanding.md

“LEO 위성”은 Low Earth Orbit Satellite, 즉 저궤도 위성을 의미합니다.

1. 정의

2. 특징

① 지연시간(Latency)이 낮음

② 고속·고품질 통신 가능

③ 수명은 비교적 짧음

④ 다수 위성 군집(Consetllation) 필요

3. LEO vs 다른 궤도 비교

구분 LEO MEO GEO
고도 ~2,000km 이하 2,000~35,786km 35,786km
지연시간 낮음 중간 높음
위성 수 많음 필요 중간 3~4기면 전지구 커버
대표 사례 Starlink GPS 기상위성

4. 주요 활용 분야

네. 위성 궤도 구분은 기본적으로 “고도(altitude)” 기준입니다.

다만, 고도만이 전부는 아니고 궤도 특성(주기, 지구 자전과의 관계, 경사각 등)도 함께 고려됩니다.

1. 고도 기준 1차 분류

■ LEO (Low Earth Orbit)

■ MEO (Medium Earth Orbit)

■ GEO (Geostationary Earth Orbit)

2. 왜 고도로 나누는가?

고도가 바뀌면 다음이 달라집니다:

즉, 고도는 위성의 물리적·경제적 특성을 결정하는 핵심 변수입니다.

3. 하지만 고도만이 기준은 아님

예를 들어:

즉,

LEO/MEO/GEO는 고도 중심 분류

SSO/극궤도 등은 궤도 기하학적 특성 중심 분류

한 줄 정리:

> “LEO냐 GEO냐”는 고도 기준이고,

> “극궤도냐 태양동기궤도냐”는 궤도 형태 기준입니다.

고도 외에도 위성 궤도는 여러 물리적·운용적 기준으로 분류합니다. 체계적으로 정리해 드리겠습니다.

1. 궤도 기하학(형태) 기준

■ 원궤도 (Circular Orbit)

■ 타원궤도 (Elliptical Orbit)

2. 궤도 경사각(Inclination) 기준

■ 적도궤도 (Equatorial Orbit)

■ 경사궤도 (Inclined Orbit)

■ 극궤도 (Polar Orbit)

3. 태양과의 관계 기준

■ 태양동기궤도 (SSO)

4. 지구 자전과의 관계 기준

■ 정지궤도 (Geostationary Orbit)

■ 동기궤도 (Geosynchronous Orbit)

5. 임무 목적 기준

■ 통신 위성

■ 항법 위성

■ 지구관측

■ 정찰/군사

6. 특수 궤도

■ Molniya 궤도

■ Tundra 궤도

■ 라그랑주점 궤도 (L1, L2 등)

정리 구조

분류 기준 예시
고도 LEO / MEO / GEO
이심률 원궤도 / 타원궤도
경사각 적도 / 극궤도
태양 동기 SSO
자전 동기 GEO / GSO
중력 균형점 Lagrange

실무적으로는 보통

“고도 + 경사각 + 이심률 + 임무목적”

이 4가지를 조합해 궤도를 정의합니다.

네 — 지상국(Ground Station)이 위성으로 여러 개의 촬영 계획(이미징 태스크)을 동시에/연속적으로 업링크하는 것은 _단일 명령만 보내는 게 아니라_, 운영 소프트웨어와 스케줄링 시스템을 통해 다수의 촬영계획을 관리·전송하는 구조로 이뤄집니다. 자세히 정리하면 다음과 같습니다:

1) 위성 운용 스케줄과 계획 데이터

위성 임무운영센터(Mission Operations Center, MOC)에서는 각 타겟에 대한 촬영요청을 임무계획(Tasking Plan) 으로 정리합니다. 이 계획은 다음 요소들을 포함합니다:

즉, 단순한 단일 커맨드가 아니라 복수의 계획이 스케줄링 알고리즘을 통해 최적화된 형태로 조합됩니다. (link.springer.com)

2) Schedule(스케줄) + Visibility 고려

지상국은 위성과의 접촉 가시창(visibility window) 정보를 궤도 예측으로 계산합니다. 이 정보를 이용해 어떤 명령을 언제 업링크할지 스케줄링합니다.

즉, 여러 개 계획은 단순 나열이 아니라 실행 가능 시간순으로 스케줄링 → 업링크 됩니다. (nasa.gov)

3) 업링크 방식

지상국에 의해 위성으로 보내는 업링크 명령은 아래처럼 구성됩니다:

Batch Command Upload (배치 업로드)

Sequenced Command Sets (순차 명령)

Priority / Conflict Resolution

이는 GEO나 LEO 모두 기본 구조는 동일하지만 가시창과 통신 창구 시간이 짧은 LEO에서는 배치 업링크가 더 중요합니다. (nasa.gov)

4) 예 - 실제 운영 사례

프랑스 CNES의 Pléiades 지상국 사례를 보면:

이처럼 지상국은 임무계획 전체(Tasking Plan) 을 위성에 전송하고, 위성은 이를 *스케줄에 따라 순차적으로 수행*합니다. (en.wikipedia.org)

5) 정리

단계 내용
임무계획 수립 여러 촬영 요청을 통합하여 전체 계획 생성 (Springer)
스케줄 최적화 가시창/연산 제약/우선순위 기반 최적 스케줄링 (nasa.gov)
업링크 배치 upload + 순차 실행 커맨드 세트 업링크
위성 실행 onboard scheduler가 시간/조건 따라 촬영 수행

부가

좋습니다. 위에서 제시한 4가지를 순서대로, 기술 수준으로 설명하겠습니다.

1. Onboard Scheduler (위성 내부 스케줄러)

지상에서 여러 촬영계획을 업링크하면, 위성 내부에는 이를 실행하는 온보드 임무 스케줄러(Onboard Mission Scheduler)가 있습니다.

구조

업링크 데이터는 보통 다음 형태로 저장됩니다:

동작 방식

① 위성 OBC(Onboard Computer)가 시간 기준으로 큐(queue)를 관리

② 현재 시각과 일치하는 태스크를 실행

③ 실행 전 리소스 확인

④ 조건 충족 시 촬영 실행

즉, 지상에서 "A, B, C 촬영하라"를 보내도

위성은 내부적으로 시간·자원·상태 조건을 검증 후 실행합니다.

2. 우선순위 / 긴급 관측 처리 로직

실제 상업 지구관측 위성은 하루 수백~수천 개의 요청을 받습니다.

우선순위 계층 예시

처리 방식

(1) 지상에서 재스케줄링 후 재업링크

가장 일반적

(2) Onboard Replanning 기능

고급 위성은 제한적 자율 재계획 가능

예:

특히 LEO는 하루 여러 패스가 있으므로

다음 패스에서 전체 계획을 수정하여 다시 업로드하는 방식이 보편적입니다.

3. 지상국 자동화 / ML 기반 스케줄링

대형 사업자(Planet, Maxar 등)는 수작업이 아닙니다.

스케줄링 문제는 본질적으로

> NP-hard combinatorial optimization 문제

제약 조건:

사용 기법

최근에는

까지 포함됩니다.

4. 명령 전송 프로토콜 (CCSDS)

대부분의 위성은 CCSDS 표준을 따릅니다.

기본 구조

(1) Telecommand (TC)

지상 → 위성

구성:

(2) Telemetry (TM)

위성 → 지상

보안

전송 계층

LEO 소형 위성은 보통 S-band uplink 사용.

핵심 요약

질문으로 돌아가서:

> 여러 촬영계획을 묶어서 보내느냐?

정확한 답:

좋습니다. 제시한 4개 항목을 실제 운용 관점에서 순서대로, 예시 포함 설명하겠습니다.

1. 실제 촬영계획 데이터 포맷 예시

촬영계획은 단순 “사진 찍어라”가 아닙니다. 보통 Observation Request → Scheduled Task → Telecommand Packet 단계로 변환됩니다.

(1) 지상 임무계획 단계 (논리 포맷 예)

Observation_ID: 20260310-001
Target_Lat: 37.5665
Target_Lon: 126.9780
Start_Time_UTC: 2026-03-10T03:15:20Z
End_Time_UTC: 2026-03-10T03:15:45Z
Off_Nadir_Angle: 18 deg
Imaging_Mode: Panchromatic
Priority: P1
Cloud_Threshold: 20%

(2) 위성용 실행 스케줄 테이블 예

Time (UTC) Command Parameter
03:14:55 Slew_Start Target Vector
03:15:18 Camera_On Mode=Panchro
03:15:45 Camera_Off —
03:16:00 Data_Tag Obs_ID

(3) 실제 업링크 패킷 (CCSDS TC)

구성:

즉, 지상에서 여러 촬영을 시간태그 기반 명령열(Time-tagged command stack) 로 만들어 한 번의 패스 동안 업로드합니다.

2. 하루 운용 시나리오 예 (LEO 지구관측 위성)

가정:

하루 흐름

00:00 UTC

02:00 UTC

03:10 UTC (첫 패스)

궤도 중

다음 패스

핵심:

LEO는 가시창이 짧기 때문에

→ 보통 다음 몇 orbit 분량을 미리 업로드

3. LEO 군집에서 Crosslink 사용하는 경우

Starlink, 군집 정찰위성 등은 위성 간 ISL (Inter-Satellite Link)을 사용합니다.

구조

지상국 → 위성 A 업링크

위성 A → 위성 B/C로 crosslink 전파

이 경우:

군사 시스템은 이 구조를 선호합니다.

4. 완전 자율 위성 (Autonomous Mission Planning)

최근 연구 및 일부 실전 적용 사례.

특징

위성이 스스로:

필요 기술

장점

LEO 상업위성은 아직 완전 자율보다는 지상 중심 재계획 방식이 일반적입니다.

전체 정리

단계 주체
촬영요청 수집 지상
최적 스케줄링 지상 자동화 시스템
배치 업링크 지상국
실행 위성 onboard scheduler
수정/긴급 대응 다음 패스에서 재업로드
군집 최적화 Crosslink 활용 가능

좋습니다. 제시한 4개 항목을 순서대로, 운용 현실 기준으로 설명하겠습니다.

1. Maxar vs Planet 운용 구조 비교

두 회사는 같은 지구관측(EO) 사업자지만 아키텍처와 스케줄링 철학이 다릅니다.

Maxar (WorldView 계열)

특징

운용 구조

스케줄링

Planet (Dove / SkySat)

특징

운용 구조

스케줄링

핵심 차이

구분 Maxar Planet
전략 고정밀 타겟팅 고빈도 커버리지
위성 수 적음 많음
기동 적극적 최소화
최적화 단위 위성 단위 군집 단위

2. 군용 정찰위성은 어떻게 다른가

군용은 상업과 구조가 다릅니다.

주요 차이점

① 우선순위

② 보안

③ 자율성

④ 통신

⑤ 촬영 방식

상업 위성은 “고객 서비스” 중심

군용은 “임무 달성” 중심입니다.

3. 위성 1기가 하루에 실제 몇 장 촬영하나

LEO 지구관측 위성 (광학 기준):

대략적 수치

단, “사진 수”는 정의에 따라 다름:

예시:

제약 요소:

4. 전력·자세기동 제약 계산 예시

간단한 현실 모델로 설명합니다.

가정

(1) 자세기동 시간

기동 각속도 제한:

예: 0.5 deg/s

Off-nadir 20° 기동 필요하면

20° / 0.5°/s = 40초

가속/감속 포함하면 약 60초 소요

→ 촬영 간 최소 간격 발생

(2) 전력 예

카메라 소비전력: 500W

플랫폼 평균: 300W

촬영 중 총 800W

10분 촬영 시:

800W × (10/60)h = 133 Wh

배터리 1500Wh라면

이론상 10회 이상 가능

하지만:

→ 실제 usable budget는 훨씬 낮음

전체 구조 요약

촬영은 단순히 “찍는다”가 아니라:

  1. 궤도상 가시창 계산
  2. 태양각 조건 확인
  3. 기동 가능 여부 계산
  4. 전력/저장 여유 확인
  5. 스케줄 큐 삽입
  6. 패스 중 배치 업링크
  7. 위성 onboard 실행

이 모든 것이 자동화 시스템에서 동작합니다.

좋습니다. 요청하신 4개 항목을 이론 수준이 아니라 실제 운용/엔지니어링 관점에서 순서대로 설명하겠습니다.

1. 실제 MILP 수식 구조 (촬영 스케줄링 문제)

지구관측 촬영 스케줄링은 전형적인 Mixed Integer Linear Programming (MILP) 문제입니다.

의사결정 변수

$$ x_{i,j} = \begin{cases} 1 & \text{위성 } i \text{가 타겟 } j \text{를 촬영하면} \ 0 & \text{아니면} \end{cases} $$

목적함수 (예시)

최대 이익 또는 우선순위 가중합 최대화:

$$ \max \sum_{i}\sum_{j} P_j \cdot x_{i,j} $$

제약 조건

(1) 가시성 제약

타겟 j는 위성 i의 가시창 내에 있어야 함:

$$ x_{i,j} \le V_{i,j} $$

(V\_{i,j} = 1)일 때만 가능

(2) 시간 충돌 제약

두 촬영 간 최소 기동 시간 필요:

$$ t_k - t_j \ge T_{slew} $$

(3) 전력 제약

$$ \sum P_{op} \cdot x_{i,j} \le P_{available} $$

(4) 저장 용량 제약

$$ \sum D_j \cdot x_{i,j} \le M_{available} $$

현실

→ Exact MILP는 계산시간 과다

→ Heuristic + Rolling Horizon 방식 사용

2. 궤도역학 기반 촬영 가능 시간 계산

촬영 가능 여부는 단순 위치가 아니라 Line-of-Sight 기하학 문제입니다.

(1) 기본 조건

위성 위치 벡터 ( \vec{r_s} )

지상 타겟 벡터 ( \vec{r_t} )

LOS 조건:

$$ (\vec{r_t} - \vec{r_s}) \cdot \vec{r_s} > 0 $$

즉, 지평선 위에 있어야 함.

(2) Off-nadir 제약

카메라 최대 기울기 각:

$$ \theta = \cos^{-1}\left( \frac{(\vec{r_s} \cdot \vec{r_t})}{|r_s||r_t|} \right) $$
$$ \theta \le \theta_{max} $$

(3) 태양 고도 조건 (광학 위성)

$$ \alpha_{sun} \ge 10^\circ \sim 20^\circ $$

너무 낮으면 그림자 과다

너무 높으면 반사/노출 문제

결과

촬영 가능 시간은 보통:

3. SAR 위성은 어떻게 다른가

SAR은 완전히 다른 제약 구조를 가집니다.

장점

주요 제약

(1) 전력

SAR 송신기 수 kW급

→ 촬영 횟수 제한

(2) 안테나 길이 방향

위성 진행 방향으로 일정 시간 비추어야 함

→ Strip 길이 중요

(3) 데이터량

광학보다 훨씬 큼

→ 저장/다운링크 제약 심각

스케줄링 차이

광학:

SAR:

4. GEO 정찰이 드문 이유

이론적으로 가능하지만 현실적 제약 큼.

① 해상도 문제

지상 해상도:

$$ GSD \propto \frac{H}{D} $$

H: 고도

D: 광학계 구경

GEO는 36,000 km

LEO는 600 km

→ 약 60배 거리 차이

→ 같은 해상도 얻으려면 망원경 직경이 60배 필요

현실적으로 불가능

② 신호대잡음비 감소

거리²에 비례하여 광량 감소

③ 대기 왜곡 영향 큼

관측 경로 길어짐

④ 비용

GEO 대형 광학 시스템은 수십 톤급

그래서 GEO는

에 적합

고해상도 정찰은 LEO가 유리

전체 흐름 요약

촬영 스케줄링은:

  1. 궤도 기반 가시창 계산
  2. 기하학적 제약 필터링
  3. MILP/휴리스틱 최적화
  4. 전력·메모리·기동 제약 반영
  5. 배치 업링크
  6. 온보드 실행

좋습니다. 이번에는 운용·설계 관점에서 실제 엔지니어링 레벨로 순서대로 설명하겠습니다.

1. 실제 수치 넣어서 하루 스케줄 시뮬레이션 예시

가정 조건

① 한 orbit당 촬영 가능 시간

지상 목표 가시 구간: 평균 8~10분

실제 촬영 가능한 순수 시간: 약 6분

촬영 1건당 필요 시간:

≈ 100초

→ 6분(360초) 동안 약 3건

② 하루 총 촬영 가능 건수

15 orbit × 3건 = 약 45건

하지만:

→ 현실적으로 30~40건/day

③ 데이터량 계산

1건당 8 GB 가정

40건 × 8GB = 320GB

→ 저장/다운링크 충분

④ 전력 검증

촬영 시 800W

20초 촬영 → 약 4.4 Wh

40건 → 약 176 Wh

→ 전력은 제약이 아님

(실제로는 SAR이 더 빡빡)

2. LEO 군집 최적화 알고리즘 구조

군집에서는 “위성 단위”가 아니라 “fleet 단위” 최적화가 핵심입니다.

단계 구조

Step 1: Global Task Pool 생성

Step 2: Visibility Matrix 생성

$$ V_{i,j,t} $$

i=위성, j=타겟, t=시간

Step 3: 1차 할당 (Assignment)

Hungarian Algorithm 또는 MILP로

각 타겟을 “가장 비용 낮은 위성”에 배정

비용 함수 예:

$$ Cost = \alpha \cdot Slew + \beta \cdot Energy + \gamma \cdot CloudRisk $$

Step 4: Local Sequencing

각 위성별 내부 순서 최적화

→ Traveling Salesman Problem 변형

Step 5: Rolling Re-Optimization

매 orbit마다 재계산

(구름/긴급요청 반영)

핵심

군집은 redundancy가 있기 때문에

“어느 위성이 찍느냐”가 중요

3. 구름 예측은 어떻게 반영하나

광학 위성의 가장 큰 불확실성.

① 외부 기상모델 사용

격자 단위로 Cloud Probability 획득

② 스케줄링 반영 방식

타겟 j에 대해:

$$ Expected_Value_j = P_j \times (1 - CloudProbability_j) $$

목적함수에 직접 반영

③ 실전 전략

④ 고급 시스템

일부는 onboard AI로:

4. 위성 설계 시 임무 역산 과정

실제 위성 설계는 “찍고 싶은 양”에서 시작합니다.

Step 1: 시장 요구 정의

예:

Step 2: 궤도 설계

Step 3: 광학계 직경 결정

GSD 공식:

$$ GSD = \frac{H \cdot p}{f} $$

H: 고도

p: 픽셀크기

f: 초점거리

→ 해상도 맞추기 위해 f 계산

→ 구경 D 결정

Step 4: 기동 성능 역산

필요 촬영 건수 →

필요 평균 slew rate 계산 →

반작용휠 토크 요구치 산출

Step 5: 전력 시스템 설계

총 daily energy budget 계산 →

태양전지판 면적 산출

Step 6: 저장/통신 설계

촬영 데이터량 →

SSD 용량 →

X-band 다운링크 속도 →

지상국 수 결정

핵심 설계 철학

임무 요구사항 → 궤도 → 광학 → ADCS → 전력 → 통신 → 질량 → 발사체

완전히 연쇄적입니다.

전체 큰 그림

지상에서 여러 촬영계획을 묶어 업링크하는 행위는

이 거대한 시스템 최적화의 “마지막 단계”일 뿐입니다.

실제 핵심은:

이 모든 것이 통합되어 하루 스케줄이 만들어집니다.

알겠습니다. “지상국에서 업링크 커맨드를 보낼 때 여러 촬영계획을 묶어서 보내냐?”에 대해 운용 흐름대로(차례대로) 답할게요.

1) 촬영요청이 여러 건 들어온다

2) 지상 임무계획 시스템이 “여러 요청”을 스케줄로 만든다

3) 그 스케줄을 “명령 시퀀스(커맨드 묶음)”로 컴파일한다

여기서 “묶는다”의 의미는 보통 두 가지 중 하나(또는 혼합)입니다.

4) 지상국 패스(가시창) 때 “배치 업링크(Batch Upload)” 한다

5) 위성은 온보드에서 저장하고, 스케줄대로 실행한다

6) 변경/긴급요청이 생기면 “다음 패스에서 재업로드(부분 업데이트)” 한다

결론(질문에 대한 한 줄 답)

네, 보통 여러 촬영계획을 “시간태그된 명령 시퀀스/배치”로 묶어서 업링크합니다. 특히 LEO는 패스가 짧아서 배치 업링크가 표준 운영에 가깝습니다.

원하시는 “묶는 단위”가 (1) 촬영 N건을 하나의 파일로? (2) 하나의 TC 패킷에 N건을? (3) 패스당 N건을? 중 어떤 의미인지에 따라 더 정확히 파고들 수 있어요.

지금 질문은 보통 (3)+(1) 의미로 이해하는 게 가장 자연스럽습니다.

좋습니다. 질문을 명확히 재정의하면:

> “지상에서 최종적으로 위성에 업로드되는 Telecommand의 파라미터 구조는 실제로 어떤 필드들로 구성되는가?”

아래는 실제 지구관측 위성(광학 기준)에서 일반적으로 사용되는 커맨드 파라미터 구조를, CCSDS 기반 TC 프레임 관점과 임무 레벨 관점으로 나누어 정리한 사례 조사입니다.

1. 최상위 구조: CCSDS Telecommand 프레임

대부분 위성은 CCSDS TC Packet 구조를 따릅니다.

기본 프레임 구조

(1) Primary Header

(2) Secondary Header (미션 정의)

(3) Application Data Field ← 핵심

여기에 실제 “촬영 커맨드 파라미터”가 들어갑니다.

(4) Error Control

2. 실제 촬영 커맨드 파라미터 구성 사례 (광학 EO 위성)

촬영은 보통 단일 “Shoot” 커맨드가 아니라 Attitude + Payload + Data Handling의 조합입니다.

(A) Slew / Pointing Command 파라미터

파라미터 설명 예시
Target_Latitude 목표 위도 37.5665°
Target_Longitude 목표 경도 126.9780°
Target_Altitude 목표 고도 0 m
Pointing_Mode Earth-fixed / inertial Earth-fixed
Off_Nadir_Angle 카메라 기울기 18°
Slew_Start_Time 기동 시작 시각 03:14:55 UTC
Max_Slew_Rate 제한 각속도 0.5°/s
Quaternion / Euler 목표 자세 벡터 q0,q1,q2,q3

고급 위성은 좌표 대신 목표 자세 Quaternion을 직접 넣기도 합니다.

(B) Imaging Payload Command 파라미터

파라미터 설명 예시
Imaging_Mode Pan / MS / SWIR 등 Panchromatic
Integration_Time 노출 시간 0.8 ms
Gain 센서 게인 Level 3
Binning_Mode 픽셀 binning 2x2
Line_Count 촬영 라인 수 12000
Strip_Length km 단위 25 km
Compression_Mode Lossless/Lossy CCSDS Lossless
Image_ID 촬영 식별자 20260310-001

(C) Data Handling 파라미터

파라미터 설명
Storage_Partition 저장 위치
Downlink_Priority 전송 우선순위
Encryption_Key_ID 데이터 암호 키
Auto_Delete_Flag 전송 후 삭제 여부

3. Time-Tagged Command Sequence 구조

실제 운영에서는 “단일 촬영 커맨드”보다는 아래처럼 묶여 있습니다.

[Time: T1] Slew_Start (Quaternion Q1)
[Time: T2] Fine_Pointing_Enable
[Time: T3] Payload_Power_On
[Time: T4] Imaging_Start (Mode=Pan, Exposure=0.8ms)
[Time: T5] Imaging_Stop
[Time: T6] Payload_Power_Off
[Time: T7] Return_To_Nadir

이 전체 블록이 하나의 “Stored Command Sequence”로 업로드되기도 합니다.

4. SAR 위성의 촬영 커맨드 파라미터 예시

SAR은 구조가 다릅니다.

파라미터 설명
Radar_Mode Stripmap / Spotlight
Pulse_Repetition_Frequency (PRF)
Transmit_Power
Chirp_Bandwidth
Incidence_Angle
Look_Direction (Left/Right)
Swath_Width
Polarization (HH, HV 등)

SAR은 kW급 송신기 제어 때문에 전력/열 파라미터가 매우 중요합니다.

5. 실제 산업 문헌에서 확인되는 공통 특징

CNES, ESA, NASA 문서 기준 공통점:

  1. 명령은 APID별로 분리
  2. 모든 커맨드는 Time-tag 가능
  3. 대부분의 수치 파라미터는 스케일링된 정수 (예: milli-degree 단위)
  4. 좌표 대신 onboard 계산 효율을 위해 자세 벡터 직접 전달하는 경우 많음
  5. 커맨드에는 항상 Execution Verification Mode 포함

6. 파라미터 수준 요약 (광학 EO 기준)

최종적으로 위성에 업로드되는 촬영 관련 커맨드는 대략 다음 4개 계층 파라미터로 구성됩니다:

① 시간 정보

② 자세 목표 정보 (좌표 또는 quaternion)

③ 센서 설정값 (노출, 모드, 압축 등)

④ 데이터 관리 설정

7. 중요한 현실적 포인트

→ 위성 내부에서 세부 커맨드로 분해

결론

최종 업로드 커맨드는 보통 다음 필드 그룹으로 구성됩니다:

즉, “촬영해라”는 단일 명령이 아니라

자세·센서·데이터 관리까지 포함된 구조화된 파라미터 세트입니다.

좋습니다. 요청하신 4가지를 차례대로, 구조적으로 설명하겠습니다.

1. 실제 CCSDS 패킷 바이너리 필드 예시

아래는 CCSDS Telecommand (TC) Space Packet의 표준 구조입니다.

(1) Primary Header (6 bytes)

필드 비트수 설명
Version 3 보통 000
Type 1 1 = TC
Sec Header Flag 1 Secondary header 존재 여부
APID 11 명령 대상 서브시스템 ID
Seq Flags 2 단일/시퀀스
Seq Count 14 패킷 카운터
Packet Length 16 데이터 길이

(2) Secondary Header (Mission Defined)

예시 구조:

필드 크기 설명
Time Tag 4~8 byte 실행 시간
Command Code 1~2 byte 명령 식별자
Ack Flags 1 byte 수신/시작/완료 확인

(3) Application Data Field

예: Imaging_Start 커맨드

필드 타입 예
Mode uint8 0x01 (Pan)
Exposure uint16 800 (0.8ms)
Gain uint8 3
Line Count uint16 12000
Compression uint8 0x02

(4) Error Control

실제 전송은

[Primary Header][Secondary Header][App Data][CRC]

이진 프레임으로 RF 업링크됩니다.

2. 소형위성(6U/12U)의 단순화된 커맨드 구조

CubeSat 계열은 복잡성이 훨씬 낮습니다.

특징

예시: 단일 촬영 커맨드

CMD_ID = 0x21
PARAM_1 = Latitude (float32)
PARAM_2 = Longitude (float32)
PARAM_3 = Duration (uint16)

즉,

“좌표 + 촬영시간”만 보내고

자세계산은 onboard에서 수행.

Stored Sequence 기능 없음인 경우

3. Stored Sequence vs Real-Time Command 차이

Stored Sequence

지상에서 여러 커맨드를 묶어 업로드

예:

SEQ_ID 12:
T+0  Slew
T+60 Camera_On
T+80 Camera_Off
T+90 Store_Data

장점

단점

Real-Time Command

패스 중 즉시 명령

예:

장점

단점

현실

상업 EO 위성 → Stored Sequence 기반

시험/초기 위성 → Real-time 위주

4. 군용 정찰위성의 보안 필드 구조

공개자료 기준 일반적 구조 설명입니다.

추가 보안 계층

① Command Authentication Field

② Rolling Key ID

③ Anti-Replay Counter

④ Dual-Authorization Flag

암호화 구조

Encrypted Payload {
   Time Tag
   Command Code
   Parameters
}
+ Authentication Tag

RF 계층에서도 링크 암호화 추가 가능.

전체 정리

실제 위성 업로드 커맨드는 다음 레벨로 나뉩니다:

  1. 전송 프레임 구조 (CCSDS 등)
  2. 임무 명령 파라미터 구조
  3. 실행 방식 (Stored vs Real-time)
  4. 보안/인증 계층

핵심 결론

최종 업로드 커맨드는 단순 좌표 몇 개가 아니라:

까지 포함된 계층적 구조의 바이너리 패킷 세트입니다.

더 깊게 들어가면:

좋습니다. 요청하신 4가지를 차례대로, 시스템 내부 동작 관점에서 설명하겠습니다.

1. APID 분할 구조 실제 사례

APID (Application Process ID)는 어떤 서브시스템이 이 명령을 처리할지를 구분하는 식별자입니다.

목적

예시 APID 구성 (지구관측 위성 가정)

APID 대상 서브시스템
0x01 OBC (공통 명령)
0x10 ADCS (자세제어)
0x20 Payload Camera
0x30 Mass Memory
0x40 Telemetry/Comms
0x50 Power Subsystem

촬영 시 실제 흐름

촬영 하나를 수행하려면:

  1. ADCS APID로 Slew 명령
  2. Payload APID로 Camera On
  3. Memory APID로 저장 설정

즉, 하나의 촬영은 여러 APID 패킷들의 조합입니다.

Stored Sequence에서의 APID 처리

Stored Sequence 내부에 여러 APID 명령이 포함될 수 있습니다.

예:

[APID 0x10] Slew to Q1
[APID 0x20] Start Imaging
[APID 0x30] Allocate Memory

위성 내부 라우터가 APID 기준으로 분배합니다.

2. 위성 내부 소프트웨어 아키텍처 (OBC Task 구조)

대부분 RTOS 기반 구조입니다 (VxWorks, RTEMS 등).

일반적 구조

OBC
 ├── Telecommand Handler Task
 ├── Time Manager Task
 ├── ADCS Control Task
 ├── Payload Control Task
 ├── Data Handling Task
 ├── Power Management Task
 └── FDIR Task

Telecommand 처리 흐름

  1. RF 수신
  2. Frame decode
  3. CRC 검사
  4. 암호 인증
  5. APID 분류
  6. 각 Task 큐에 삽입

Task 간 통신

우선순위

RTOS에서는:

즉, 안전이 항상 최우선입니다.

3. Time-Tag 처리 메커니즘

Time-tag 명령은 즉시 실행이 아닙니다.

Time-tag 처리 흐름

  1. TC 수신
  2. Secondary header에서 실행시간 추출
  3. Time-tag Queue에 저장
  4. System clock와 비교
  5. 실행 시점 도달 시 해당 APID task로 전달

시간 기준

정밀도

문제 상황

→ Time Manager가 검증

4. Onboard Fault 발생 시 커맨드 무효화 로직

위성은 항상 안전 우선입니다.

FDIR (Fault Detection, Isolation, Recovery)

주요 감시 대상

Fault 발생 시 처리 단계

1단계: 경고

2단계: Abort

3단계: Safe Mode 진입

Time-tag 명령 처리

Fault 상태일 경우:

예시

반작용휠 과속 시:

전체 시스템 흐름 요약

지상에서 업로드된 커맨드는:

  1. APID로 분류
  2. RTOS Task로 전달
  3. Time-tag 큐에서 대기
  4. 실행 시 리소스/상태 검증
  5. Fault 발생 시 FDIR 개입
  6. 필요 시 Safe Mode 전환

핵심 이해 포인트

위성은 “명령을 그대로 실행하는 장치”가 아니라

이 통합된 임베디드 분산 제어 시스템입니다.

더 깊게 들어가면:

좋습니다. 요청하신 4가지를 차례대로, 엔지니어링 수준으로 설명하겠습니다.

1. Reaction Wheel Saturation 처리

문제 정의

반작용휠은 각운동량을 저장하여 자세를 제어합니다.

$$ H_{wheel} = I_w \cdot \omega_w $$

외란 토크(공기저항, 중력구배 등)가 지속되면 휠 속도가 점점 증가합니다.

$$ H_{total} = \sum H_{wheel} $$

휠 속도가 최대 RPM에 도달하면 → Saturation 발생

Saturation 위험

해결 방법: Momentum Dumping

(1) 자기토커(Magnetorquer) 사용 (LEO)

지구 자기장과 상호작용:

$$ \vec{T} = \vec{m} \times \vec{B} $$

휠 속도를 줄이면서 각운동량을 외부로 방출

(2) Thruster 사용 (고급 위성)

미세 추력기로 각운동량 제거

운용 전략

2. Onboard Autonomy Level 분류

위성 자율성은 보통 4단계로 구분합니다.

Level 0 - 완전 지상 제어

Level 1 - 제한적 자율

Level 2 - 임무 재계획 가능

Level 3 - 고급 자율

상업 EO 위성은 대체로 Level 1~2 수준

심우주 탐사는 Level 3 이상 필요

3. CCSDS PUS 표준과 ECSS 구조

유럽계 위성은 CCSDS 위에 PUS (Packet Utilization Standard)를 사용합니다.

PUS 개념

CCSDS는 “전송 포맷”

PUS는 “서비스 의미 정의”

주요 PUS 서비스 타입

Service Type 기능
1 Telecommand Verification
3 Housekeeping
5 Event Reporting
9 Time Management
11 Onboard Scheduling
17 Test

예: 촬영 스케줄은 Service 11 사용 가능

ECSS (유럽 표준)

4. 위성 소프트웨어 V&V 구조 (검증·검증)

위성 SW는 항공우주 수준 품질 요구

단계

(1) Unit Test

모듈 단위 시험

(2) Integration Test

Task 간 통합 시험

(3) Hardware-in-the-Loop (HIL)

실제 ADCS 센서/액추에이터 연결

(4) FlatSat Test

비행모델과 동일 구성 테스트

(5) Thermal Vacuum Test

우주 환경 모사

독립 검증 (IV&V)

FDIR 검증

전체 통합 관점

지상에서 묶어 업로드된 촬영 명령은:

  1. APID로 분배
  2. RTOS Task 실행
  3. Time-tag 스케줄 관리
  4. ADCS가 기동 수행
  5. Reaction wheel saturation 관리
  6. FDIR가 안전 보장
  7. 모든 SW는 V&V 완료 상태

즉, 단순 명령 전달이 아니라

항공우주급 실시간 분산 제어 시스템입니다.

더 깊게 가면: