satellite imagery transmission and processing flow

<br><br>

카테고리: guide | 읽기시간: 7분 | 원문: 다운로드



위성이 촬영한 영상이 지상에서 최종 이미지 파일(예: GeoTIFF, NITF 등)로 생성되기까지의 전체 흐름을 탑재체 → 통신 → 지상국 → 영상처리 → 파일 생성 순으로 계층적으로 정리



1. 위성 탑재체 내부 (On-Board Segment)

1.1. 영상 획득 (Image Acquisition)

광자 → 센서 → 전하 → 전압 신호

1.2. 아날로그 → 디지털 변환 (A/D Conversion)

Pixel DN = 0 ~ 4095 (12bit 예시)

이 단계에서 이미 “디지털 영상 데이터”가 됨.

1.3. 온보드 영상 처리 (선택적)

위성 설계에 따라 다음 처리가 수행될 수 있음:

1.4. 패킷화 (CCSDS Packetization)

영상 데이터는 그대로 보내지 않음.

다음 구조로 변환됨:

[Source Packet]
 ↓
[TM Transfer Frame]
 ↓
[CADU]

1.4.1. Source Packet

1.4.2. TM Transfer Frame

1.4.3. CADU (Channel Access Data Unit)

구조:

| ASM | TM Frame | RS Parity |

2.1. 채널 코딩 & 변조

변조 방식 예:

CADU → 변조 → RF 신호

3. 지상국 수신 (Ground Station Front-End)

3.1. RF 수신

지상국 구성:

Tracking Antenna
 ↓
LNA
 ↓
Down Converter
 ↓
Demodulator

3.2. 채널 복호 (Channel Decoding)

복조 후 처리:

출력:

복구된 CADU

4. 지상 데이터 처리 (Ground Data Processing)

4.1. 프레임 동기 및 CADU 분해

CADU → TM Frame → Source Packet

4.2. 영상 데이터 재조립

4.3. 압축 해제 (필요 시)

온보드 압축이 있었다면:

5. 영상 처리 (Level 0 → Level 1 → Level 2)

이 단계가 “이미지 파일 생성”의 핵심.

5.1. Level 0 (Raw)

5.2. Level 1 (Radiometric / Geometric Correction)

5.2.1. 수행 작업:

  1. Dark signal 제거
  2. Gain 보정
  3. Line alignment
  4. Geometric correction
  5. RPC 생성

출력:

5.3. Level 2 (정사보정)

출력:

6. 최종 이미지 파일 생성

이제 실제 파일 포맷으로 생성됨.

대표 포맷:

포맷 특징
GeoTIFF GIS 표준
NITF 군사용
JPEG2000 압축
HDF5 다중밴드

파일 내부 포함 정보:

7. 전체 흐름 요약 다이어그램

[위성 촬영]
 ↓
ADC
 ↓
온보드 처리
 ↓
Source Packet
 ↓
TM Frame
 ↓
CADU
 ↓
변조/RF 송신
 ↓
지상국 수신
 ↓
복조/복호
 ↓
CADU 분해
 ↓
Packet 재조립
 ↓
영상 복원
 ↓
보정(Level1/2)
 ↓
GeoTIFF 등 파일 생성

8. 핵심 포인트 정리

구분 핵심
우주 구간 CADU 단위 전송
지상 수신 오류정정 + 프레임 복원
데이터 처리 Packet 재조립
영상 처리 보정 및 정사영상 생성
최종 산출물 GeoTIFF 등 파일


위성 영상 생성 체계는 CADU 기반 전송과 지상 복원·보정을 거쳐 최종 산출물(GeoTIFF/NITF)로 완성된다.



1. CCSDS 계층 구조 상세 설명

CCSDS는 우주 통신 표준 프로토콜 스택입니다.

OSI 모델과 유사하게 계층 구조를 가집니다.

1.1. Physical Layer

출력: Raw bitstream

1.2. Channel Coding Layer

전송 오류 보정 목적.

출력: 오류정정된 CADU

1.3. Synchronization & Channel Coding Sublayer

1.3.1. CADU 구조:

| ASM | TM Transfer Frame | RS Parity |

1.4.1. TM Transfer Frame

프레임 단위 전송 관리.

1.5. Space Packet Layer

1.5.1. Source Packet

여기서부터 “실제 데이터” 의미가 명확해짐.

1.6. Application Layer

1.6.1. 계층 흐름 요약

Application Data
 ↓
Source Packet
 ↓
TM Frame
 ↓
CADU
 ↓
Channel Coding
 ↓
Modulation
 ↓
RF

2. 위성 영상 Level 정의 (0 ~ 4)

위성 영상은 처리 단계에 따라 Level이 구분됩니다.

2.1. Level 0 (Raw Data)

엔지니어링/재처리용

2.2. Level 1A

2.3. Level 1B

일반 분석 시작 가능

2.4. Level 2 (Ortho)

GIS 사용 가능

2.5. Level 3 / 4 (고급 산출물)

3. LEO 실시간 수신 vs 저장 후 다운로드 차이

LEO 위성은 가시 시간(pass)이 짧습니다 (약 5~12분).

촬영과 동시에 지상으로 송신

3.1.1. 특징:

3.1.2. 장점:

3.1.3. 단점:

3.2. On-board Recording 후 Dump

위성 내부 Solid State Recorder (SSR)에 저장 후

지상국 통과 시 다운로드

3.2.1. 특징:

3.2.2. 장점:

3.2.3. 단점:

3.3. 비교

항목 실시간 저장 후 다운로드
지연 낮음 있음
링크 요구 지속적 통과 시만
시스템 복잡도 낮음 높음

실제 운용은 대부분 혼합 방식 사용.

4. 영상 데이터 레이트 계산 예시

실제 시스템 설계 시 가장 중요한 계산입니다.

4.1. 가정

4.2. 한 라인 픽셀 수

20 km / 1 m = 20,000 pixel

4.3. 1 line 데이터량

20,000 pixel × 12 bit × 4 band
= 960,000 bit
≈ 0.96 Mbit

4.4. 초당 데이터율

0.96 Mbit × 10,000 line/sec
= 9,600 Mbit/sec
= 9.6 Gbps

4.5. 압축 적용 (예: 4:1)

9.6 Gbps / 4 = 2.4 Gbps

4.6. 채널 코딩 오버헤드 (약 20%)

2.4 Gbps × 1.2 ≈ 2.88 Gbps

실제 RF Downlink 요구 속도 ≈ 3 Gbps

5. 최종 핵심 정리

  1. CCSDS는 계층형 구조이며 CADU는 채널 계층 단위
  2. 영상 Level은 보정 정도에 따라 구분
  3. LEO는 실시간/저장 후 다운로드 혼합 운용
  4. 고해상도 영상은 수 Gbps급 링크 필요


영상 레벨 체계와 수신 운용 방식의 차이를 바탕으로 실제 링크 요구 데이터율을 산정할 수 있다.



링크 예산은 위성에서 송신한 신호가 지상 수신기에 도달했을 때 SNR이 충분한지를 계산하는 절차입니다.

1.1. 기본 방정식

수신 전력:

$$ P_r = P_t + G_t + G_r - L_s - L_{atm} - L_{other} $$

(dB 단위)

1.2. 주요 항목

1.2.1. 송신 전력 (P_t)

1.2.2. 송신 안테나 이득 (G_t)

1.2.3. 경로 손실 (L_s) (Free Space Path Loss)

$$ L_s = 92.45 + 20\log f(GHz) + 20\log R(km) $$

예시:

→ 약 165 ~ 170 dB

1.2.4. 수신 안테나 이득 (G_r)

1.3. 수신 전력 계산 예시

$$ P_r = 43 + 35 + 50 - 168 - 2 $$

≈ -42 dBm

1.4. Noise Power

$$ N = kTB $$

dB 형태:

$$ N(dBm) = -228.6 + 10\log T + 10\log B $$

예:

→ 약 -82 dBm

1.5. SNR

$$ SNR = P_r - N $$

≈ 40 dB

→ 실제로는 시스템 손실 포함해 더 낮아짐.

1.5.1. 목표

SNR이 변조 방식 + 코딩 방식이 요구하는 값 이상이어야 함.

2. LDPC 적용 시 Eb/N0 요구치

LDPC는 고성능 Forward Error Correction(FEC) 코드입니다.

2.1. Eb/N0 정의

$$ Eb/N0 = \frac{SNR}{Spectral Efficiency} $$

단위: dB

2.2. 변조별 요구 Eb/N0 (대략값)

변조 LDPC 적용 시 필요 Eb/N0
QPSK 1 ~ 2 dB
8PSK 4 ~ 6 dB
16APSK 7 ~ 9 dB

2.3. 왜 LDPC가 중요한가?

과거:

현재:

동일 전력으로 더 높은 데이터율 가능

또는 같은 데이터율에서 송신 전력 감소 가능

2.4. 시스템 설계 흐름

  1. 목표 데이터율 설정
  2. 변조 방식 선택
  3. 코딩률 선택 (예: 1/2, 3/4)
  4. 요구 Eb/N0 계산
  5. Link Budget로 달성 가능 여부 판단

3. SSR (Solid State Recorder) 용량 산정

LEO 위성은 촬영 데이터를 내부 저장 후 dump합니다.

3.1. 기본 공식

$$ 필요용량 = 데이터율 × 촬영시간 $$

3.2. 예시

데이터율 = 2.5 Gbps

촬영 시간 = 600초 (10분)

$$ 2.5 × 10^9 × 600 = 1.5 × 10^{12} bit $$

= 1.5 Tb

≈ 187.5 GB

3.3. 하루 촬영 5회라면?

$$ 187.5 × 5 = 937.5 GB $$

→ 최소 1 TB 이상 필요

3.4. 실제 설계 시 고려사항

3.5. 설계 조건

$$ Downlink rate × 가시시간 ≥ 저장된 총 데이터 $$

이 조건 만족 못하면 데이터 backlog 발생

4. 상용 위성 사례 비교

4.1. PlanetScope

전략: 다수 위성 + 낮은 해상도

4.2. WorldView-3

전략: 고해상도 + 고속 링크

4.3. ICEYE (SAR)

전략: 원시데이터 일부 압축/처리

4.4. 최신 추세

5. 종합 구조

Imaging Data Rate
 ↓
SSR 저장
 ↓
LDPC 코딩
 ↓
X-band Downlink
 ↓
지상국 수신
 ↓
Eb/N0 만족 여부 판단
 ↓
파일 생성

6. 핵심 요약

  1. Link Budget는 SNR 확보 계산
  2. LDPC는 Eb/N0를 크게 낮춰주는 핵심 기술
  3. SSR 용량은 촬영량과 dump 능력의 함수
  4. 상용 위성은 해상도와 링크 전략이 다름
×preview