수신기 장애 발생 시 처리 프로세스
수신기 장애의 분류
GNSS 수신기 장애는 크게 하드웨어적 문제와 소프트웨어적 문제로 구분될 수 있다. 하드웨어적 문제는 전원 공급 장치(Power Supply), 안테나 연결부 혹은 내부 회로 문제 등 물리적 결함에서 기인한다. 소프트웨어적 문제는 펌웨어(내장 소프트웨어)의 이상 동작, 내부 버퍼 초과, 위성 신호 처리 알고리즘의 오류 등에서 비롯된다.
하드웨어적 장애 예시
수신기 본체 내 전압 레귤레이터 고장
안테나 포트 손상으로 인한 신호 감쇄
온도 변화에 따른 내부 부품 노이즈 증가
소프트웨어적 장애 예시
내부 펌웨어 버그로 인한 주기적 재부팅
교정 알고리즘 파라미터 설정 오류
데이터 로깅 모듈의 메모리 부족
장애 유형을 명확히 분류하는 것은 신속한 문제 해결에 중요하다. 실제 운영 환경에서 장애가 발생하면 가장 먼저 원인을 하드웨어적 장애인지 소프트웨어적 장애인지 빠르게 판단해야 한다.
장애 진단 절차
장애를 진단하기 위해서는 신호 수신 상태, 내부 상태 지표, 입출력 데이터 등을 모니터링하여 문제가 발생한 지점을 구체적으로 확인해야 한다. 일반적으로 다음 단계를 거쳐 원인을 규명한다.
기초 점검
전원 장치 및 케이블 연결 상태 점검
안테나 포트와 케이블 물리적 손상 여부 확인
동작 온도 범위 내 운용 여부 확인
신호 레벨 확인
수신 신호 세기의 급격한 변화 모니터링
통계적으로 특정 위성만 잡히지 않는 패턴 확인
내부 잡음 지표(Noise Figure 등) 분석
소프트웨어 로그 분석
펌웨어에서 제공하는 이벤트 로그 또는 오류 코드 조회
수신기 재부팅 주기, 메모리 상태 등 소프트웨어 지표 점검
장애 발생 시점 전후로 수신기 내부 추정치가 비정상적으로 변하는지 확인
측정 정보 잔차(Residual) 분석 수신기에서 산출하는 측정치(예: 코드 측정치, 위상 측정치)를 이용해 시스템이 정상 동작하는지 여부를 확인한다. 측정 모델을 간단히 표현하면 다음과 같다.
zk=Hkxk+vk여기서
$\mathbf{z}_k$는 $k$번째 시간에서의 관측 벡터 (예: 코드 측정치)
$\mathbf{H}_k$는 측정 모델 행렬
$\mathbf{x}_k$는 상태 벡터 (예: 위성-수신기 간 거리, 시계 오차 등)
$\mathbf{v}_k$는 관측 노이즈 벡터
예상되는 관측치 $\mathbf{\hat{z}}_k$는 다음과 같이 추정할 수 있다.
z^k=Hkx^k수신기에 장애가 없고 정상 동작한다면 잔차(residual) $\mathbf{r}_k = \mathbf{z}_k - \mathbf{\hat{z}}_k$가 통계적으로 작은 값을 유지한다. 장애 발생 시 특정 관측치가 정상 범위를 벗어나 $\mathbf{r}_k$가 급격히 커지므로, 이를 통해 장애 발생 여부와 대략적인 원인을 가늠할 수 있다.
장애 유형 세분화
하드웨어적 원인 가능성 → 안테나, 전원부, 내부 회로 요소 정밀 검사
소프트웨어적 원인 가능성 → 펌웨어 재설치, 버전 롤백, 내부 변수 검증
장애 처리 프로세스 흐름도 예시
아래는 수신기 장애를 전반적으로 점검하고 처리해 나가는 대표적인 흐름을 다이어그램으로 표현한 예시이다.
장애 진단 데이터 확보 전략
장애 발생 시, 진단을 위한 초기 데이터를 충분히 확보하는 것은 매우 중요하다. 수신기의 내부 로깅(logging) 기능을 통해 장애 발생 시점 전후로 어떠한 이벤트가 발생했는지 기록된 로그를 살펴보며, 외부에 별도의 모니터링 시스템이 있다면 동일 시간대에 관측된 정보를 함께 비교한다. 이를 위해 다음과 같은 데이터를 확보하는 전략을 세운다.
Raw 측정 데이터 수집
코드 측정치(코드 도달 거리)
위상 측정치(반송파 도달 거리)
Doppler 측정치
신호 세기 지표(C/N0) 이 데이터들은 수신기의 내부 추정 과정에서 가장 기초적으로 사용되므로, 반드시 장애 발생 전후 시점의 Raw 데이터를 확보해야 한다. 일반적으로 $RINEX$ (Receiver Independent Exchange Format) 형태로 저장하거나, 수신기 제조사의 고유 포맷으로 저장되는 파일을 분석할 수 있다.
펌웨어 이벤트 로그
재부팅 기록, 메모리 에러 기록, 내부 변수 범위 초과 등의 이벤트
RTCM(또는 기타 교정 메시지) 송수신 상태 로그
운용자 명령(설정 변경 등)에 대한 이력 펌웨어 이벤트 로그를 통해 최근에 업데이트된 설정값, 장애 발생 시점 전후로 버퍼 오버플로(buffer overflow)나 메모리 부족 현상이 있었는지 등을 확인할 수 있다.
내부 상태 추정치 기록 수신기는 내부적으로 $\mathbf{x}_k$(위성 간 상대위치, 수신기 시계 오차, 전리층 및 대류권 오차 보정치 등)를 주기적으로 추정한다. 실제 운용 중에는 Kalman Filter 등의 추정 알고리즘이 쓰이는 경우가 많다. 다음과 같이 상태 추정 알고리즘을 모델링할 수 있다.
xk+1=Φkxk+wk$\mathbf{\Phi}_k$는 상태 전이(state transition) 행렬
$\mathbf{w}_k$는 공정 잡음(process noise)
이때 수신기는 내부 알고리즘으로 $\mathbf{\hat{x}}_{k+1}$를 추정하게 되는데, 장애가 발생하면 특정 상태 변수의 추정치가 급격히 변하거나 수렴하지 않는 모습을 보일 수 있다.
외부 모니터링 시스템 데이터
동일 사이트에 설치된 다른 GNSS 수신기의 측정값 비교
인접 기상 관측소의 기상 정보(온도, 습도, 기압 등)
전리층 모니터링 시스템에서 제공하는 전리층 지수(TEC 등) 외부 데이터와의 비교를 통해 해당 장애가 국지적 현상(예: 특정 장비만의 문제)인지, 아니면 일시적인 환경 영향(예: 강력한 전리층 교란)에 의한 것인지 구분할 수 있다.
고급 진단 기법
일반적인 로깅 및 모니터링만으로 장애 원인을 파악하기 어렵다면, 다음과 같은 추가 기법을 활용할 수 있다.
스펙트럼 분석 GNSS 주파수 대역에서 주파수 스펙트럼을 실시간으로 관측하면, 불규칙한 스파이크(spike)나 스푸핑(spoofing) 시그널 등이 있는지 확인할 수 있다.
알고리즘 레벨 시뮬레이션 실제 시스템과 동일한 알고리즘을 소프트웨어 시뮬레이터에서 재현하여, 동일한 입력 데이터(측정치)를 넣었을 때 어디서 보정이 실패하거나 수렴이 깨지는지 비교 분석한다.
하드웨어 루프백(Loop-back) 테스트 수신기 안테나 단자를 특수 장치로 루프백하여, 내부 RF 전송 경로와 디지털 신호 처리부가 정상 동작하는지 검사한다.
장애 복구 및 후속 조치
장애 원인이 어느 정도 특정되었다면, 다음 단계로 복구 절차를 수행한다.
설정 파일 초기화 펌웨어 설정이 잘못되어 있을 경우, 제조사에서 권장하는 공장 초기 설정(default configuration)으로 복구 후 동작을 확인한다.
펌웨어 롤백 혹은 업데이트 기존 펌웨어 버전에서 이미 알려진 버그가 있을 수 있으므로, 상위 버전으로 업데이트하거나 안전한 이전 버전으로 롤백하여 재시험한다.
물리적 부품 점검 및 교체
안테나, 케이블, 커넥터, 전원부 등을 순차적으로 교체 후 테스트
내부 레귤레이터 또는 발진기(Oscillator) 교체
장애 발생 상황 재현 테스트 복구 조치 후, 동일 조건(온도, 전원, 배치 환경)에서 문제가 재현되는지 시험해 본다. 재현이 되지 않는다면 운용 환경에 복귀 가능성을 검토한다.
중첩 장애 관리
운용 현장에서는 단일 장애뿐 아니라 여러 가지 장애가 동시에 발생할 가능성도 고려해야 한다. 예를 들어, 안테나 케이블 단선에 따른 수신 신호 감쇄와 동시에 펌웨어 버그로 인해 재부팅 현상이 병행될 수 있다. 이러한 중첩 장애를 다루기 위해서는 장애 간 선후 관계와 상호 연관성을 파악해야 한다.
선후 관계 분석
먼저 발생한 장애로 인해 후속 장애가 유발되었는지 살펴본다.
여러 장애가 동시다발적으로 발생해도 우선순위를 부여하여 가장 긴급·핵심적인 문제부터 접근한다.
장애 격리(Fault Isolation)
장애 후보 원인을 순차적으로 제거하면서, 최소 영향 인자로 좁혀 간다.
예를 들어 케이블 문제를 임시로 해결(예비 케이블 교체)한 다음에도 펌웨어 관련 에러가 지속된다면, 두 장애가 독립적이었거나 복합적으로 동작했다고 볼 수 있다.
증분적 복구(Incremental Recovery)
한 가지 결함을 해결한 후 시스템을 부분적으로 다시 작동시켜 원인이 제거되었는지 확인한다.
장애가 여럿일 경우, 하나의 결함을 수정할 때마다 로그 및 상태를 점검하여 새로운 문제가 잔존하는지 탐색한다.
다중 수신기 비교 분석
여러 대의 GNSS 수신기를 같은 장소 또는 인접 지역에 설치하고 있다면, 비교 분석을 통해 장애를 빠르고 정확하게 진단할 수 있다.
주변 수신기와 데이터 비교
동일 시간대, 동일 위성 집합에 대해 수신 성능(추적 위성 수, C/N0 등)을 대조한다.
특정 수신기에만 문제 현상이 보이면, 해당 수신기에 국한된 하드웨어 또는 펌웨어 문제일 가능성이 크다.
공통 하드웨어 요소 점검
여러 수신기가 하나의 스플리터(Splitter), 증폭기(Amplifier), 혹은 공용 전원 장치를 공유한다면, 공통 장치에 문제가 있는지 확인한다.
공통 요소에서 이상이 발견되면 장애가 다른 수신기에도 영향을 줄 수 있다.
상대적 위치에 따른 환경 영향 분석
장애가 특정 지점에서만 발생하고, 지근거리(수 m 단위) 다른 지점에는 문제가 없다면 전파 차폐나 간섭원이 해당 지점 근처에 존재하는지 검사한다.
건물, 전력선, 무선국 등의 간섭 요인을 고려한다.
RAIM 기반 장애 검출
GNSS 수신기는 $RAIM$ (Receiver Autonomous Integrity Monitoring) 기법을 통해 독립적으로 측정 이상치를 검출할 수 있다. RAIM은 복수의 위성 측정치 간 일관성을 검사하여, 하나의 위성 신호 또는 내부 수신기 오류로 인해 잘못된 위치가 계산되는 상황을 방지한다.
과잉 관측(Over-determined) 시스템
필요한 최소 위성 수보다 더 많은 위성이 관측될 때, 각 위성의 측정치가 다른 위성들과 통계적으로 일치하는지 검증한다.
RAIM에서는 측정치의 잔차(residual) 분포를 통해 수신기 내부 또는 위성 신호의 이상을 탐지한다.
Fault Detection and Exclusion (FDE)
특정 위성 신호 혹은 내부 관측치가 오류로 판정되면, 이를 제외하고 재계산한다.
RAIM 과정에서 잔차가 과도하게 큰 관측을 찾아 배제함으로써, 위치 오차가 허용 한계를 넘어서는 상황을 방지한다.
장애 검출 시나리오 예시
내부 수신기 장애로 모든 위성의 측정치가 동시다발적으로 오차가 커지는 경우 → RAIM 잔차가 전반적으로 커져 보정 불가 상태로 판정
특정 주파수 대역만 간섭을 받는 경우 → 일부 위성에서만 잔차가 급격히 증가
수신기 내 안전 장치(Watchdog Timer) 활용
일부 GNSS 수신기는 내부 Watchdog Timer를 통해 소프트웨어가 비정상 동작에 빠졌을 때 자동으로 재부팅하거나 오류를 보고한다.
Watchdog Timer 설정
시스템이 정상 루틴을 일정 주기 내에 수행하지 못하면 강제로 재부팅한다.
장애 상황에서 무한 루프나 메모리 오버플로가 발생해도 수신기가 완전히 교착되지 않도록 돕는다.
Watchdog Timer 이벤트 로그 확인
강제 재부팅이 발생할 때마다 로그가 기록된다면, 소프트웨어가 어느 시점에 멈췄는지 확인할 수 있다.
Watchdog Timer가 자주 작동한다면, 펌웨어 루틴이 비효율적이거나 메모리 누수가 있을 가능성이 있다.
정상 동작과 재부팅 사이 임계값 조정
지나치게 짧은 Timer 간격은 일시적 부하에도 재부팅을 일으킬 수 있으므로, 장애 탐지율과 오탐(false alarm) 간 균형점을 찾는다.
펌웨어 상태, 시스템 부하 등을 고려하여 알맞은 재부팅 임계값을 설정한다.
원격 진단 및 업데이트
원거리에서 GNSS 수신기를 운용하는 경우, 현장 방문 없이 장애 진단과 복구를 수행할 수 있는 체계를 갖추면 효율적이다.
원격 접근(Remote Access)
네트워크를 통해 SSH, Telnet, 혹은 제조사가 제공하는 전용 프로토콜로 접근
내부 로그, 펌웨어 버전, 설정 파일 등을 즉시 확인 가능
원격 펌웨어 업데이트
이상이 펌웨어 버그로 추정될 때, 직접 방문하지 않고도 최신 버전으로 업그레이드하거나 이전 버전으로 롤백
원격 업데이트 시, 전송 오류나 전원 차단으로 인한 설치 실패를 방지하기 위해 이중 안전 장치(dual-bank firmware 등)를 적용하기도 한다.
실시간 모니터링 대시보드
수신기의 핵심 지표(C/N0, 추적 위성 수, CPU 사용량, 메모리 사용량 등)를 실시간으로 중앙서버에서 모니터링
일정 임계값을 초과할 경우 자동 알림을 발송하여 긴급 대응
수신기 장애 사례별 체크리스트
현장에서 자주 접하는 대표적인 장애 시나리오를 유형별로 정리하면, 장애 발생 시 보다 체계적이고 신속하게 대응할 수 있다. 체크리스트 형태로 작성해 두면 현장에서 바로 확인하며 점검 가능하다.
전원 불안정
전원 공급 장치(AC/DC 컨버터 등) 출력 전압 정상 범위 여부
예비 전원(UPS, 배터리) 상태 점검
내부 레귤레이터나 퓨즈 손상 여부
안테나·케이블 이상
커넥터 접촉 불량 (부식, 이물질)
케이블 절단 혹은 극심한 손실 (임피던스 mismatch, 물 유입)
안테나 LNA(저잡음 증폭기) 전원 공급 유무
펌웨어 오류·설정 불일치
최근 펌웨어 업데이트 이력 확인
주요 파라미터(위성 시스템 선택, SBAS 설정, 데이터 속도 등) 확인
내부 메모리나 버퍼가 가득 찬 상태(로그 삭제나 주기 조절 필요성)
신호 간섭 및 스푸핑 의심
GNSS 주파수 대역에서 예상치 못한 강한 전파 신호 관측
여러 위성의 C/N0가 동시에 급락하거나 비정상적으로 치솟음
인접 통신 장비(무선국, 레이더 등) 동작 시간과의 상관성
위성 가시성 저하
인공구조물(건물, 교각 등)에 의한 그림자영역(Shadowing) 증가
작업 차량, 임시 장비 등으로 인해 일시적으로 안테나 가림 발생
위성 궤도 구성(Geometry)이 특정 시간대에 취약해지는지 확인
예방 정비(Preventive Maintenance)
장애 발생을 최소화하기 위해서는 정기적인 예방 정비가 필수적이다. 예방 정비 항목은 아래와 같이 구체화할 수 있다.
정기 점검 주기 및 로그 분석
수신기 로그 데이터를 주기적으로 수집·분석하여, 평소보다 잔차 $\mathbf{r}_k$가 커지는 추세가 감지되는지 확인
온도, 습도, 전원 상태 등을 실시간 모니터링하여 정상 범위 초과 시 경보 발행
안테나·케이블 관리
야외 설치 시 방수, 방진, 내식(부식 방지) 검사를 정기적으로 수행
케이블, 커넥터 절연 저항 및 임피던스 측정
소형 설치 환경이라면 케이블 장력이나 꺾임(Sharp bend)에 의한 손상 여부를 확인
펌웨어 업데이트 정책
안정성 검증을 거치지 않은 최신 버전 펌웨어의 무리한 도입은 지양
제조사에서 권장하는 버전 릴리스 노트를 꼼꼼히 검토하여, 새로운 버그가 보고되었는지 확인
환경 영향 대비
천재지변(낙뢰, 홍수 등)에 대비한 접지(grounding) 및 낙뢰 보호 장치 설치
전자파 환경이 까다로운 지역에서는 별도의 차폐(Shielding) 대책 검토
겨울철 결빙 문제(안테나 표면 빙결 등) 대비 방열(heater) 시스템 점검
장애 발생 후 문서화 및 보고
장애가 발생하고 복구가 완료되면, 이를 체계적으로 문서화하여 향후 유사 사례 방지와 노하우 축적에 활용해야 한다.
장애 발생 이력 기록
발생 일시, 장애 지속 시간, 복구 완료 시점
환경 정보(기상 상태, 주변 공사·장비 동작 여부 등)
내부 로그·데이터 분석 결과
조치 내역 및 결과
현장에서 수행한 하드웨어 교체 또는 소프트웨어 업데이트 내역
복구 후 상태(정상화 여부, 추가 시험 결과)
차후 보완이 필요한 부분(예: 추가 정비 계획, 부품 교체 주기 재설정)
기록 표준화
장애 유형 코드, 우선순위 분류, 장애 원인 분류 체계 마련
운영팀 간 신속 공유를 위해 웹 기반 보고 시스템이나 그룹웨어를 사용
제조사 및 관련 기관(예: 위성 운영 기관)에 보고할 필요가 있는지 판단
장애 대응 훈련과 시뮬레이션
운용 인력 간 장애 대응 훈련을 주기적으로 실시함으로써, 장애 상황 발생 시 신속 대응 역량을 높일 수 있다.
시뮬레이션 기반 가상 장애 발생
테스트베드나 시뮬레이터를 이용해 특정 펌웨어 오류, 하드웨어 단선, 전파 간섭 등을 가정한 시나리오 수행
모의 장애 상황에서 로그 확인, 구성품 교체, 펌웨어 재설치 등 실제 프로세스와 동일하게 진행
역할 분담 및 대응 체계 확인
장애 보고, 초동 조치, 원인 분석, 복구, 보고 체계까지 단계별 책임자와 담당 부서를 명확히 구분
문제 발생 시 혼선이 없도록 프로세스 플로우차트를 비상 매뉴얼에 포함
데이터 보존 및 재현
장애 발생 순간의 로우 데이터(측정치, 로그, 스펙트럼 분석 자료 등)를 별도 서버나 스토리지에 안전하게 저장
이후 재현 실험이나 타 기관(제조사, 연구소) 협업 시 제공할 수 있도록 준비
중장기적인 장애 예방 및 시스템 신뢰도 향상 방안
운용 환경이 복잡해짐에 따라 GNSS 수신기 장애를 완벽하게 방지하기란 쉽지 않다. 그러나 여러 관점에서 중장기적인 예방 대책을 마련하면 장애 발생 확률과 피해 규모를 크게 줄일 수 있다.
다중 GNSS 및 다중 주파수 활용
GPS, GLONASS, Galileo, BeiDou 등 여러 위성항법시스템을 동시에 추적하는 다중 GNSS 수신기를 사용하면 신호 가시성이 증가해 장애에 대한 회복력(resilience)이 높아진다.
다중 주파수(L1, L2, L5 등)를 지원하는 수신기는 전파 간섭이 특정 대역에 집중되더라도 다른 대역으로 신호를 확보할 수 있다.
이중화(Redundancy) 구성
핵심적인 GNSS 수신기는 동일 모델 혹은 상호 호환 모델로 2대 이상을 병렬 운용하여, 한 대가 장애를 일으켜도 다른 한 대가 정상 운영될 수 있도록 설계한다.
전원부, 안테나, 케이블 등도 이중화 또는 예비(Backup) 시스템을 구축해 단일 고장점(Single Point of Failure)을 최소화한다.
협대역 보정 신호 및 보조기술(BDS, SBAS, GBAS 등) 적용
SBAS(위성기반 보정 시스템)나 GBAS(지상기반 보정 시스템)를 병행 활용하면 일반 GNSS 단독 모드 대비 장애 감지 및 정밀도 확보 능력이 향상된다.
위성항법에만 의존하지 않고 관성항법이나 지상 무선 측위 등 다른 기술과 결합하는 하이브리드 방식도 고려한다.
환경 간섭원 정기 점검
GNSS 주파수 대역 근처에서 발생 가능한 전자파 간섭원의 스펙트럼 범위를 분석·기록하여, 주기적으로 비교(Baseline)한다.
신규 시설(예: 5G 기지국, 레이더 등)이 주변에 설치될 때, 해당 시설이 GNSS에 간섭을 일으키지 않는지 사전 협의 및 시험을 거친다.
수신기 성능 지표 검증(V&V, Verification & Validation)
제품 도입 전에 제조사 제공 사양(Tracking Sensitivity, Multipath Rejection, Time to First Fix 등)을 검증한다.
온도, 습도, 충격(Shock) 등 운용 환경을 고려한 인증(예: MIL-STD, IP등급 등)을 확인하여, 실제 환경에서 안정적으로 동작 가능한지 확인한다.
책임 소재 및 장애 대응 협력 체계
GNSS 수신기 장애가 발생했을 때는 단순히 수신기 제조사나 운영자의 문제로 끝나지 않고, 주변 환경이나 위성 시스템 자체 문제까지 다양하게 연관될 수 있다. 신속하고 올바른 원인 규명을 위해서는 명확한 책임 소재와 협력 체계를 수립해야 한다.
제조사와의 유지보수 계약
장애 발생 시 원격 진단 지원, 긴급 교체 부품 제공, 현장 엔지니어 파견 등의 지원 범위와 절차를 사전에 계약서로 명시한다.
펌웨어 업데이트나 기능 개선이 필요한 경우, 제조사와 협의하여 안정성을 검증한 후 단계적으로 적용한다.
인프라 운영 기관 간 협력
공항, 항만, 철도, 도로 분야 등 다양한 GNSS 활용 기관이 서로 관측 정보를 공유하고, 전리층·간섭 정보 등을 교차 검증할 수 있는 체계를 갖춘다.
국가 차원의 GNSS 관측망(CORS, Continuously Operating Reference Station)을 운영하는 기관과 협력해, 장애가 특정 수신기에 국한된 문제인지 전역적 문제인지 식별 가능하도록 한다.
보험 및 법적 대응
GNSS 수신기에 의존도가 높은 업무(예: 무인기 운용, 항공 착륙 보조 등)에서는 장애로 인한 재산·인명 피해가 발생할 수 있으므로, 관련 보험 가입과 법적 책임 범위를 명확히 한다.
장애 보고서와 로그 기록 등을 체계적으로 관리해, 문제가 발생할 경우 객관적 증거로 활용한다.
미래 기술 동향 및 장애 대응 전망
GNSS 기술은 초정밀화, 초고신뢰화, 다중화 추세로 발전 중이며, 이에 따라 장애 발생 시 처리 프로세스 역시 고도화되고 있다.
AI·빅데이터 기반 예측 정비(Predictive Maintenance)
대규모 GNSS 수신기 네트워크를 운영하는 경우, 로그 데이터와 운영 기록을 머신러닝·딥러닝 기법으로 분석하여 장애 징후를 사전에 발견한다.
특정 이상 패턴(예: 잔차 증가, CPU 부하 급등 등)이 축적되면 자동으로 경고를 발령하고, 운영자가 사전에 대응하도록 한다.
클라우드 기반 GNSS 처리
일부 GNSS 솔루션은 로컬 수신기에서 최소한의 측정치만 전송하고, 나머지 측정 분석·보정 계산을 클라우드 서버에서 수행한다.
클라우드 연산 자원을 이용하면, 장애 상황 분석 및 대규모 시뮬레이션을 유연하게 수행할 수 있으나, 네트워크 안정성 확보가 필수적이다.
양자센서 등 신기술 적용 가능성
향후 GNSS 이외에 양자 센서나 초정밀 시계(Optical Clock) 기술이 상용화되면, 위성 신호 자체가 일시적으로 취약해지는 상황에서도 위치·시각 정보를 보완할 수 있는 길이 열릴 것이다.
다만, 이러한 신기술 도입 시에도 GNSS와의 상호운용성, 장애 분석 프로세스 정립이 동시에 진행되어야 한다.
Last updated