# 소프트웨어 업데이트와 펌웨어 관리

#### GNSS 수신기 소프트웨어 업데이트의 중요성

GNSS 수신기의 소프트웨어는 衛星信號를 수신하고 처리하는 핵심 알고리즘과 제어 로직을 포함한다. 이러한 소프트웨어는 초기 배포 시점에는 특정한 위성 궤도 파라미터, 신호 특성, 오류 보정 알고리즘 등을 기준으로 작성되지만, 실제 운영 과정에서 다양한 환경 변화와 시스템 요구 사항이 발생한다. 예를 들어 위성별 신호 변조 방식의 개선, 새로운 보정 모형 도입, 추가 보안 기능 반영 등이 꾸준히 요구된다. 이때 소프트웨어 업데이트를 통해 각종 개선 사항을 효율적으로 적용해야 한다.

업데이트를 통해 수신기의 추정 정확도를 높이거나, 궤도 데이터 처리 방식의 최적화가 가능하다. 소프트웨어 내부에서는 위치 해석을 위한 필터링(예: 칼만필터나 확장 칼만필터)이 동작하며, 이 필터의 상태벡터 $\mathbf{x}$와 오차 공분산 행렬 $\mathbf{P}$을 주기적으로 갱신한다. 이러한 필터링 알고리즘을 업데이트하여 위성 배열 또는 임의의 장애(멀티패스, 전리층 지연 등)에 대응할 수 있다.

또한 주파수 관리와 스펙트럼 관찰 기능 등도 소프트웨어 레벨에서 구현되는 경우가 많기에, 업데이트 시점에 새로운 주파수 대역을 지원하거나 기존 알고리즘의 성능 향상을 도모할 수 있다. 이러한 변화를 적기에 반영하지 않으면 실제 사용자 측면에서 측위 정확도나 신호 신뢰성 문제가 생길 수 있다. 따라서 제조사나 운영 기관은 업데이트 주기 $T\_{u}$를 사전에 정의하고, 이를 기반으로 지속적인 개선 작업을 수행한다.

#### 펌웨어 구조와 특징

GNSS 수신기 펌웨어는 하드웨어와 소프트웨어 중간 계층으로서, 내부 처리에 필요한 마이크로컨트롤러나 DSP(Digital Signal Processor)의 레지스터 제어, 메모리 관리, 전력 관리 등 저수준 작업을 담당한다. 즉, 운영체제(또는 RTOS) 위에서 동작하며, GNSS 신호 처리 흐름을 실시간으로 제어한다.

펌웨어 구조는 일반적으로 부트로더(bootloader), 코어 펌웨어(core firmware), 어플리케이션 펌웨어(application firmware) 등의 계층으로 나누어 볼 수 있다. 부트로더는 전원을 인가받은 직후 가장 먼저 실행되어 시스템 초기화, 메모리 확인, 업데이트 모드 진입 등을 수행하고, 코어 펌웨어는 신호 처리에 필요한 필수 기능(예: ADC 제어, 내부 타이머 관리)을 담당한다. 최종적으로 어플리케이션 펌웨어는 사용자 기능(측정 데이터 산출, 메시지 포맷 처리, 통신 인터페이스 제어 등)을 구현한다.

GNSS 펌웨어에서는 수신 신호의 동기화, 주파수 변환, 디지털 필터링, 역확산(De-spreading) 등 신호 처리 절차가 매우 중요한 역할을 한다. 이를 위한 내부 변수를 생각해보면, 다음과 같은 변수가 존재할 수 있다:

$$
\mathbf{\Phi} = \begin{bmatrix} \phi\_1 \ \phi\_2 \ \vdots \ \phi\_n \end{bmatrix}
$$

여기서 $\mathbf{\Phi}$는 각 채널별 위상 정보를 담는 벡터로, 펌웨어는 실시간으로 위상($\phi\_i$)을 추적하여 신호를 복조한다. 채널 수에 따라 $n$이 달라지며, 필요한 메모리 할당이나 처리 속도도 달라진다. 이러한 저수준 과정을 수행하는 펌웨어는 하드웨어 레벨과 맞물려 있으므로, 업데이트 시 시스템 중단을 최소화하기 위해 부트로더가 중요한 역할을 한다.

#### 업데이트 프로세스와 버전 관리

펌웨어 및 소프트웨어 업데이트는 일반적으로 다음 단계를 거쳐 이루어진다:

1. 업데이트 파일(예: 바이너리 이미지)의 확보
2. 무결성 검증(Checksum, 디지털 서명 등)
3. 업데이트 모드 진입(부트로더 동작)
4. 이전 버전 백업(롤백 안전장치)
5. 새로운 펌웨어 또는 소프트웨어 기록
6. 검증 및 재부팅

제조사나 운영 기관은 버전 관리를 위해 소프트웨어 버전 번호와 펌웨어 버전 번호를 각각 부여한다. 예를 들어 소프트웨어는 v2.3.1 형태로, 펌웨어는 F1.05 형태로 명명할 수 있으며, 서로 다른 개발 파트에서 빌드된 결과물이 통합될 때 충돌이 없도록 사전에 조율해야 한다.

버전 충돌 방지를 위해 보통 형상관리도구(예: Git, SVN)를 활용한다. 소스 코드 수준에서 신호 처리 루틴의 변경, 알고리즘 수정 등에 대한 로그를 남기며, 컴파일 후 생성되는 펌웨어 이미지와 소프트웨어 실행 파일도 동일한 태그(tag) 또는 리비전(revision)을 기록한다. 이를 통해 특정 버전에 문제가 발생했을 때, 신속하게 원인 분석과 복원이 가능하다.

#### 업데이트 전략 및 유의사항

GNSS 시스템은 상시 운용이 요구되므로, 업데이트 시에도 측위 서비스가 장시간 중단되지 않도록 세심한 전략 수립이 필수적이다. 통상적으로 업데이트는 운영 환경에서 다음과 같은 요건을 고려하여 계획된다.

1. **운용 중단 시간 최소화**
   * 중요 응용(항공, 해상, 군사 등)에서는 백업 시스템을 두거나 이중화된 하드웨어를 이용해 서비스 중단을 최소화한다.
   * 업데이트 전에 임시 저장 장치나 보조 메모리에 신규 펌웨어 이미지를 로드해 놓고, 재부팅 시 즉시 교체하도록 설계하기도 한다.
2. **위험 분산**
   * 동시에 여러 수신기를 업데이트할 경우, 장애 발생 시 전부 중단될 위험이 있다. 이를 방지하기 위해 시간차를 두고 단계적으로 업데이트를 진행하거나, 운영 노드 간 버전을 다르게 유지하여 장애 시 롤백할 수 있도록 설계한다.
3. **자동 업데이트 vs. 수동 업데이트**
   * 연결성이 좋은 환경(예: 상시 인터넷 연결)에서는 자동 업데이트를 활용해 안정적으로 유지보수가 가능하지만, 만약 오작동이 발생하면 되돌리기 어려울 수 있다. 따라서 임계 시스템에는 주로 관리자가 직접 검증 후 업데이트하는 수동 업데이트 방식을 채택한다.
4. **하드웨어 자원 확인**
   * 펌웨어 업데이트 시, 새로운 기능 혹은 알고리즘이 기존 하드웨어 사양을 초과하는지 확인해야 한다. 예를 들어 메모리(MCU 내부 SRAM, Flash 등)의 부족이나, 추가된 DSP 처리 블록의 연산량 과부하 등이 발생할 수 있다.
   * 특히 코드 메모리 사용량이 전체 가용량 $C\_{\text{max}}$에 근접하면 추가 기능을 위한 공간이 모자랄 수 있으므로, 다음 조건을 사전에 점검한다.

$$
\mathbf{M}*{\text{code}} \leq C*{\text{max}}
$$

여기서 $\mathbf{M}\_{\text{code}}$는 최신 소프트웨어 및 펌웨어가 필요한 총 코드 메모리 용량을 의미한다.

#### 보안 및 무결성 보장

GNSS 수신기의 소프트웨어와 펌웨어는 위성신호를 직접 해석하므로, 보안 취약점이 있을 경우 악의적 신호 위조나 스푸핑(spoofing)에 노출될 수 있다. 특히 업데이트 파일 자체가 변조되면 시스템을 정상적으로 운용하기 어려워지므로, 강력한 보안 체계를 갖추어야 한다.

1. **무결성 검증**
   * 업데이트 파일을 다운로드하거나 전달받은 후, Hash(SHA-256 등)를 통해 변조 여부를 사전에 확인한다.
   * 디지털 서명 기법(RSA, ECC 등)을 활용하여 인증 기관에서 서명한 업데이트 파일만 설치하도록 제한함으로써 공급망 공격(supply chain attack)을 예방한다.
2. **암호화 전송**
   * 네트워크를 통해 업데이트 파일을 전송할 경우, TLS(Transport Layer Security) 또는 양자내성암호(Post-Quantum Cryptography) 등을 적용해 전송 구간에서의 중간 공격(man-in-the-middle)을 방지한다.
   * 내부망(사설 네트워크)이라 하더라도, 무결성 훼손 가능성을 배제할 수 없으므로 암호화 채널 설정이 중요하다.
3. **권한 분리와 접근 제어**
   * 펌웨어 업데이트 기능은 관리자 권한에서만 실행되도록 하고, 일반 사용자는 접근할 수 없도록 제어한다.
   * GNSS 수신기의 내부 부트로더 메뉴에도 암호나 보안 토큰을 요구하여, 임의로 부트로더 모드에 진입하지 못하도록 설정한다.

#### 실시간 운영 고려사항

GNSS 수신기에서는 실시간 성능(시간 동기, 트래킹 루프 유지 등)이 매우 중요하다. 업데이트 시점에 신호 추적이 중단되거나 관측 데이터가 유실되면, 정밀도에 악영향이 불가피하다. 이를 최소화하기 위한 방안을 살펴보면 다음과 같다.

1. **실시간 태스크 우선순위 조정**
   * 업데이트 과정에서 부하가 일시적으로 증가할 수 있다. 이를 대비하여 트래킹 루프, 측정 데이터 산출 등의 태스크를 높은 우선순위로 할당하고, 업데이트 관련 태스크는 상대적으로 낮은 우선순위로 배정한다.
   * RTOS(Real-Time Operating System) 환경에서 스케줄링 정책(RR, FIFO 등)과 태스크의 우선순위 설계를 신중히 진행한다.
2. **부분 업데이트(partial update)**
   * 펌웨어 일부 모듈만 교체하여 나머지 모듈은 기존 상태를 유지하는 방안을 적용할 수 있다. 예를 들어 부트로더 영역은 그대로 두고, 어플리케이션 펌웨어만 교체한다.
   * 최신 펌웨어의 일부 기능만 임시로 비활성화하여, 완전한 전환은 야간이나 트래픽이 적은 시간대에 수행하기도 한다.
3. **이중화 및 장애 대응**
   * 미션 크리티컬한 시스템에서는 2세트 이상의 수신기를 동시에 운용하고, 한쪽에서 업데이트가 진행되는 동안 나머지 한쪽에서 정상 서비스를 제공한다.
   * 만일 업데이트 실패 시, 자동으로 롤백(rollback)을 수행하도록 부트로더가 설계되어 있으면, 서비스 연속성을 쉽게 확보할 수 있다.

#### 예시 업데이트 흐름도

아래는 mermaid를 활용한 간단한 업데이트 흐름도이다.

{% @mermaid/diagram content="flowchart TB
A\[업데이트 파일 수신] --> B{무결성 검사}
B --정상--> C\[부트로더 진입]
B --실패--> D\[오류 처리 및 종료]
C --> E\[이전 버전 백업]
E --> F\[펌웨어 기록]
F --> G\[재부팅 및 검증]
G --성공--> H\[서비스 정상화]
G --실패--> I\[롤백 수행]" %}

위 흐름도에서 무결성 검사를 통과해야만 업데이트 프로세스가 진행되며, 실패 시에는 즉시 오류를 보고하고 종료한다. 펌웨어 기록 전에는 이전 버전을 백업하여, 새 버전에 문제가 있을 경우 언제든 원상태로 되돌릴 수 있게 설계한다.

#### 사전 검증과 시뮬레이션

소프트웨어 및 펌웨어를 배포하기 전, 통상적으로 실환경과 유사한 테스트베드나 시뮬레이터에서 충분한 검증 과정을 거친다. GNSS 운영 환경은 물리적 실험이 제한적인 경우가 많으므로, 시뮬레이터를 통해 위성 궤도, 전파 전파 모델(전리층, 대류권), 멀티패스 등을 가상으로 구현하고 주요 기능(Tracking, Acquisition, Navigation 데이터 처리 등)을 점검한다.

* **하드웨어 인더 루프(HIL, Hardware in the Loop) 테스트**
  * 실제 GNSS 수신기 하드웨어와 소프트웨어를 시험 장치에 연결해, 위성 신호 생성기(시뮬레이터)에서 가상의 신호를 입력받아 테스트한다.
  * 이때 스푸핑, 간섭 등 예외 상황도 재현하여 업데이트된 펌웨어 또는 소프트웨어가 해당 상황을 정상적으로 처리하는지 확인한다.
* **일정 지연 환경 테스트**
  * 지상국과 수신기간 업데이트 데이터를 주고받는 과정에서 네트워크 지연(시간 지연, 패킷 손실 등)이 발생할 수 있다.
  * 이를 테스트 장비에서 모사하여, 업데이트 프로세스가 중단되지 않고 복구 메커니즘이 적절히 동작하는지 살펴본다.
* **성능 지표 검증**
  * 업데이트 전후로 위치 정확도, 신호 추적률, 시간 동기 오차 등을 측정하여 차이를 비교한다.
  * 예시로, 측정된 위치 오차(2D RMSE)를 $e\_{\text{pos}}$라 할 때, 다음과 같은 경계값 $e\_{\text{th}}$ 이내인지 점검한다.

$$
e\_{\text{pos}} \leq e\_{\text{th}}
$$

* 여기서 $e\_{\text{th}}$는 시스템 운영 사양에서 요구하는 최대 허용 위치 오차이다.

#### 장애 발생 시 로그 분석

업데이트 이후 예기치 못한 장애나 성능 저하가 발생할 수 있으므로, 고급 로그(logging)와 진단 기능을 마련해두어야 한다.

* 로그 포맷 표준화
  * 측정 시점, 이벤트 타입, 내부 변수 상태 등을 일관된 포맷으로 기록하여, 문제 발생 시 신속한 추적이 가능하도록 한다.
* リアルタイム 로그 vs. 저장 로그
  * 실시간 로그는 현재 상태를 모니터링하여 즉각적인 대응을 가능케 하고, 저장 로그는 후속 분석(오프라인 분석)에 활용된다.
* 로그 레벨 및 필터링
  * DEBUG, INFO, WARN, ERROR 등의 레벨로 분류해 중요도에 따라 로그를 구분한다. 일반 사용자 환경에서는 WARN 및 ERROR 위주로 기록하고, 내부 개발 환경에서는 DEBUG까지 활성화하여 세부 분석이 가능하도록 한다.

업데이트 과정에서 혹은 업데이트 직후에 발생하는 장애를 효과적으로 분석하기 위해, 펌웨어나 소프트웨어 내부 변수(상태벡터 $\mathbf{x}$, 공분산 행렬 $\mathbf{P}$, 트래킹 루프 파라미터 등)에 대한 로그도 남겨야 한다. 이러한 변수 정보를 통해 필터가 정상 작동했는지, 수신기가 예상치 못한 파라미터 범위로 빠지지 않았는지 등을 진단할 수 있다.

#### 다양한 운영 시나리오별 테스트

GNSS 수신기 소프트웨어와 펌웨어는 국내외 다양한 지역, 운용 모드(고정국, 이동 플랫폼 등), 위성 조합(GPS, GLONASS, Galileo, BeiDou 등) 등 복합적인 환경에서 운영될 수 있다. 따라서 다음과 같은 시나리오별 테스트가 권장된다.

1. **단일 위성군 테스트**
   * GPS만 사용하는 환경에서 업데이트 후 성능 검증
   * GLONASS, Galileo, BeiDou 등으로 각각 분리 운영하여 특정 위성 신호 처리 루틴이 적절히 업데이트 되었는지 확인
2. **멀티 GNSS 통합 테스트**
   * GPS + GLONASS + Galileo 등 다중 위성군이 함께 사용되는 환경에서, 호환성과 상호운용성 검증
   * 위성 궤도 정보가 부분적으로 누락되거나, 한 위성군에서 신호 이상이 발생했을 때 시스템이 어떻게 대처하는지 확인
3. **정지형 vs. 이동형 시나리오**
   * 지상에 고정된 상태(기준국 등)에서의 업데이트 성능과, 차량 또는 항공기처럼 고속 이동하는 환경에서의 업데이트 성능 비교
   * 이동 시나리오에서는 도플러 주파수 변화 폭이 커지므로, 업데이트된 추적 루프 알고리즘이 해당 상황을 제대로 처리하는지가 중요하다.
4. **주변 간섭 시나리오**
   * 전파 간섭이 심하거나 전력선 노이즈가 많은 환경, 건물 밀집 지역(도시 캐니언) 등 극단적 상황에서의 운영 안정성 테스트
   * 다중경로(multipath) 환경이 심한 지역에서의 성능 차이를 측정하며, 업데이트된 소프트웨어 또는 펌웨어가 개선된 보정 알고리즘을 적용했는지 검증

#### 표준 및 규정 준수

GNSS 수신기와 관련된 일부 산업(항공, 선박, 철도 등)에서는 특정 안전 표준을 준수해야 한다. 예를 들어 항공 분야에서는 DO-178C(소프트웨어), DO-254(하드웨어) 등의 표준을 적용할 수 있다. 이때 업데이트 프로세스 역시 표준에 맞추어 문서화 및 검증 절차를 거쳐야 한다.

* **형상관리 요건**
  * 업데이트 시 발생하는 모든 변경 사항(코드 수정, 알고리즘 변경, 릴리스 노트 등)을 추적 가능하게 문서화한다.
  * 유관 표준(예: ISO 9001, DO-178C 등)이 요구하는 형상 식별, 베이스라인 관리, 승인 절차 등을 엄격히 준수한다.
* **테스트 커버리지 요건**
  * 표준에 따라 소스 코드의 실행 경로, 분기 등에 대한 테스트 커버리지(Statement Coverage, Branch Coverage 등)를 요구할 수 있다.
  * 업데이트 전후로 회귀 테스트(Regression Test)를 수행하여 기존 기능이 예기치 않게 훼손되지 않았음을 보증한다.
* **안전무결성 수준(SIL, DAL 등)**
  * 철도나 항공 분야에서는 안전무결성 수준(예: SIL-4, DAL A/B/C/D)을 요구하곤 한다. 이에 맞춰 업데이트 설계 및 검증 로직을 구성하고, 장애 발생 위험을 정량화한다.
  * 예를 들어, 특정 신호 처리 모듈이 업데이트 후에 고장 발생률 $\lambda$가 추가로 증가하는지, 시스템 전체 신뢰도 목표 $R\_{\text{sys}}$를 충족하는지 계산한다.

#### 개발-운영(DevOps) 연계

GNSS 수신기 소프트웨어와 펌웨어를 빈번히 업데이트하는 환경에서는, 개발(Development)과 운영(Operations)을 통합하여 자동화 도구와 프로세스를 활용하는 DevOps 방식을 고려할 수 있다. 이는 업데이트 주기를 단축하고, 문제 발생 시 신속 대응할 수 있도록 지원한다.

1. **지속적 통합(Continuous Integration, CI)**
   * 각 개발자가 변경한 코드(알고리즘 수정, 버그 패치 등)를 커밋할 때마다 자동으로 빌드와 테스트를 실행한다.
   * 빌드 시에는 GNSS 신호 처리 라이브러리, 임베디드 툴체인 등을 사용하고, 테스트 단계에서 시뮬레이션(가상 신호 환경)이나 유닛 테스트, 정적 분석 등을 수행한다.
2. **지속적 배포(Continuous Deployment, CD)**
   * CI 과정을 거쳐 통과한 빌드 결과물을 자동으로 운영 환경(실제 GNSS 수신기, 지상국 등)에 배포할 수 있다.
   * 다만 안전 임계치가 높은 GNSS 애플리케이션에서는, 자동 배포 대신 중간에 운영 검증 단계를 거쳐 ‘승인된’ 업데이트만 실제 장비에 배포하기도 한다.
3. **빨리 실패(Fail Fast) 원칙**
   * GNSS 신호 처리 알고리즘은 복잡도가 높으므로, 작은 버그가 실제 필드에서 치명적 오류를 일으킬 수 있다.
   * DevOps 환경에서 빠르게 오류를 발견하고 즉시 수정할 수 있는 체계를 갖추면, 사용자 영향이 최소화된다.

#### 업데이트 기록 및 릴리스 노트

소프트웨어와 펌웨어를 업데이트할 때마다, 변경 이력과 사용자에게 영향을 주는 주요 사항을 기록한 릴리스 노트를 제공해야 한다. 이는 운영자가 버전별 특징을 인지하고, 문제 발생 시 특정 버전으로 롤백하거나 참조할 수 있도록 돕는다.

* **변경 내용 요약**
  * 업데이트에 포함된 기능 추가, 성능 개선, 버그 수정 사항 등을 간단히 리스트업한다.
  * 예: “v2.3.1에서는 GLONASS 신호 동기화 알고리즘을 개선했으며, RTCM 메시지 파싱 과정에서 발생하던 메모리 누수 문제를 해결함.”
* **사양 변경 안내**
  * 사용자가 업데이트 후 하드웨어나 소프트웨어 설정을 변경해야 하는 경우(예: 구성 파일, 메모리 맵 수정 등), 이를 명확히 기술한다.
  * GNSS 수신기가 지원하는 채널 수나 보정모델 형식(RTCM, SBAS 등)이 달라지는 경우, 업그레이드 전후 호환성을 충분히 설명해야 한다.
* **테스트 결과 요약**
  * 내부 시뮬레이션, 현장 테스트에서 측정된 주요 성능 지표(위치 정확도, 추적 루프 안정도, CPU 사용률 등)를 공개할 수 있다.
  * 다만 보안이나 기밀 이슈로 인해 상세 데이터는 제한적으로 제공될 수 있다.

#### 자동화 툴 및 원격 업데이트

현대 GNSS 운용 시스템은 원격으로 수신기를 제어하고 모니터링하는 기능을 갖추는 경우가 많다. 이에 따라 소프트웨어와 펌웨어 역시 원격에서 자동화된 방식으로 업데이트하는 시스템이 활용된다.

1. **OTA(Over-The-Air) 업데이트**
   * 이동체 차량 또는 드론 등에 탑재된 GNSS 수신기를 무선 네트워크(LTE, 5G, 위성통신 등)를 통해 원격 업데이트하는 방안이다.
   * 전력 제약이나 통신 대역폭 제약이 있으므로, 업데이트 파일 크기를 최소화하기 위해 바이너리 패치(delta patch) 기술을 사용할 수 있다.
2. **스케줄링 및 분산 업데이트**
   * 다수의 GNSS 수신기를 동시에 업데이트하면 네트워크 트래픽이 폭주하거나, 장애 발생 시 광범위하게 영향을 줄 수 있다.
   * 중앙 집중식 관리 서버에서 업데이트 스케줄(시간 창, 순차 배포)을 설정하고, 상태를 모니터링하며 문제가 발생하면 즉시 중단 또는 롤백을 수행한다.
3. **자동 복구 로직**
   * 업데이트 도중 전원 공급이 중단되거나 파일이 손상되는 상황을 대비해, 펌웨어의 부트로더 구역에 자동 복구 로직을 내장한다.
   * 예: 업데이트 이미지가 불완전한 경우, 기존 버전으로 자동 부팅하는 롤백 로직을 수행하도록 한다.

#### 라이프사이클 관리

GNSS 수신기 소프트웨어와 펌웨어는 제품 기획, 개발, 배포, 운용, 폐기(엔드 오브 라이프, EOL)에 이르는 전체 라이프사이클 동안 유지보수 전략을 수립해야 한다.

* **장기 지원(LTS) 버전 운영**
  * 군용 혹은 항공용처럼 승인 절차가 까다롭고 한 번 인증받으면 장기간 사용해야 하는 경우, 장기 지원(LTS) 버전을 운영한다.
  * 중간중간 보안 패치나 중요 버그 수정만 반영하고, 나머지 새로운 기능 업데이트는 제한한다.
* **EOL(End of Life) 관리**
  * 하드웨어 부품 단종, RTOS나 라이브러리 지원 종료 등이 발생하면, 더 이상 업데이트가 어려워진다.
  * 이 시점에는 최신 GNSS 수신기로 교체하거나 소프트웨어 업그레이드 경로를 마련해야 한다.
  * EOL 전후로는 관련 고객에게 사전 안내를 제공하고, 교체 또는 유지보수 계약 방안을 협의한다.
* **지속 모니터링 및 결함 관리**
  * 배포된 소프트웨어 및 펌웨어의 결함(Bug) 보고나 개선 요청을 실시간으로 수집하여, 추적 관리 시스템(issue tracker)을 통해 우선순위를 매긴다.
  * GNSS 위성 시스템의 글로벌 동향(신규 위성 런치, 신호 변조 개선 등)에 맞춰 대응이 필요한 경우, 업데이트 로드맵에 반영한다.