위성에 명령을 보냈는데 실행됐을까? 전송·접수·실행 확인의 차이

앞선 글에서는 위성에서 받은 온도와 전압 같은 상태값을 읽을 때, 값의 크기뿐 아니라 기준 시각과 유효성도 함께 살펴야 한다고 설명하였다. 상태를 파악한 뒤에는 필요한 동작을 위성에 요청할 수 있다. 그런데 지상에서 명령을 보냈다는 기록만으로 위성이 그 동작을 수행했다고 말할 수 있을까?

명령을 전송한 것, 위성이 명령을 받아들인 것, 그리고 실제 동작이 끝난 것은 서로 다른 사실이다. 지상국의 화면에서 ‘전송 완료’를 확인했더라도, 위성 쪽에서 명령을 해석하고 실행했다는 증거가 따로 필요할 수 있다. 이번 글에서는 이 확인 과정을 일반적인 원리로 살펴본다. 임무마다 설계와 운용 규칙은 다르며, 아래의 단계와 예시는 특정 위성의 실제 절차를 설명하는 것이 아니다.

한줄 요약
지상에서 명령을 송신했다는 기록은 위성의 접수나 실행을 자동으로 증명하지 않는다. 명령의 전달·접수·실행 보고와 실행 뒤 상태 텔레메트리를 구분해 확인해야 결과를 더 정확하게 판단할 수 있다.

전송 버튼을 눌렀다는 사실은 어디까지 알려줄까

지상 관제 시스템에서 명령을 준비하고 송신하면 시스템에는 보통 요청 내용과 처리 상태가 기록된다. 이 기록은 지상에서 어떤 명령을 언제, 어떤 경로로 보내려 했는지 확인하는 데 중요하다. 하지만 송신 장비가 데이터를 내보냈다는 사실과 위성이 그 데이터를 정상적으로 수신했다는 사실은 같지 않다. 무선 구간에는 신호 품질 저하나 일시적인 간섭이 생길 수 있고, 위성이 지상국의 가시권을 벗어나면 실시간 교신 자체가 불가능하다.

ESA가 소개하는 TT&C는 위성 상태를 내려보내는 텔레메트리, 위치를 확인하는 추적, 지상에서 위성으로 보내는 명령을 포괄한다. 각각이 같은 무선 연결을 활용할 수 있어도 맡은 역할은 구분된다. 지상에서 명령 패킷을 송신한 뒤, 우주 구간의 수신과 위성 내부 처리, 되돌아오는 확인 정보를 따로 다루는 이유가 여기에 있다.

편지를 우체통에 넣은 것만으로 받는 사람이 읽고 요청을 처리했다고 확신할 수 없는 것과 비슷하다. 다만 우주 통신에서는 ‘받았다’는 확인도 하나의 보고 자료로 다뤄야 한다. 그 확인이 어떤 단계까지 의미하는지 정의가 있어야 한다.

명령은 위성에 도착한 뒤에도 확인할 단계가 남는다

ECSS의 텔레메트리·텔레커맨드 패킷 표준은 우주선 하위 시스템과 탑재체를 원격으로 감시하고 제어하기 위한 명령 패킷과 보고용 텔레메트리 패킷을 다룬다. 이 표준은 가능한 운용 서비스를 하나의 메뉴처럼 제시하고, 실제 임무는 필요한 서비스와 기능 수준을 골라 적용하도록 설명한다. 따라서 모든 위성이 똑같은 확인 메시지나 화면 상태를 사용한다고 일반화해서는 안 된다.

개념적으로는 먼저 지상 시스템이 명령을 구성하고, 송신을 요청한다. 다음으로 위성의 통신 장치가 데이터를 받았는지, 명령 처리 기능이 해당 요청을 받아들였는지 확인하는 단계가 올 수 있다. 명령이 접수되어도 실행 예정 시각을 기다리는 경우가 있고, 실행 조건이나 현재 상태가 맞지 않아 거부될 수도 있다. 실행이 시작된 뒤에도 완료 보고가 도착하기 전까지는 결과가 진행 중일 수 있다.

여기서 ‘접수’는 ‘실행 완료’와 구별해야 한다. 위성이 명령의 형식과 조건을 확인해 처리 대상으로 등록했다는 뜻일 수 있지만, 명령에 담긴 동작이 끝났다는 뜻은 아니다. ECSS 용어집은 실행 검증 보고가 요청의 시작·진행·완료 단계에서 성공 또는 실패한 실행을 보고할 수 있다고 정의한다. 이처럼 실행 과정도 하나의 순간이 아니라 단계가 있는 일로 표현된다.

기록의 상태 이름보다 확인 범위를 먼저 본다

관제 화면에는 ‘전송’, ‘수신’, ‘접수’, ‘실행’, ‘완료’처럼 짧은 상태명이 표시될 수 있다. 상태명이 명확해 보여도 해당 임무에서 그 말이 어떤 이벤트를 가리키는지 확인하지 않으면 오해할 수 있다. 예를 들어 네트워크 장비가 다음 구간으로 패킷을 넘긴 것을 ‘전달’로 표시하는 경우와 위성 응용 기능이 명령을 접수한 것을 같은 의미로 읽어서는 안 된다.

명령의 단계마다 확인할 질문을 나누면 기록을 읽기 쉬워진다. 지상 송신 이력은 어떤 요청을 언제 내보냈는지 알려준다. 통신 수신 확인은 우주 구간에서 데이터를 받았는지를 좁혀 준다. 접수 응답은 명령 처리 기능이 이를 인식했는지 보여줄 수 있다. 실행 보고는 명령 처리 과정이 어디까지 왔는지 알려준다. 임무에 따라 이런 응답이 모두 제공되는 것은 아니며, 보고의 이름과 의미는 인터페이스 정의서와 운용 설계에 따라 달라진다.

확인 단계	알려주는 내용	그 자체로 단정할 수 없는 것
지상 송신 기록	지상에서 명령 전송을 요청하거나 수행한 이력	위성에서 정상 수신·접수·실행했는지
수신·접수 응답	정의된 통신 또는 명령 처리 단계의 확인	요청한 동작이 끝났거나 의도한 상태가 되었는지
실행 보고	실행 시작·진행·완료 등 처리 결과	모든 관련 장치가 기대한 물리 상태인지
상태 텔레메트리	명령 전후 위성 상태 항목의 관측값	상태 변화의 원인이 그 명령 하나뿐인지

실행 완료 보고와 실제 상태값도 서로 다른 증거다

작업 완료 보고가 도착했다면 중요한 확인이 이루어진 것이다. 그래도 그 보고가 뜻하는 범위를 살펴야 한다. 소프트웨어가 명령을 실행 루틴까지 전달했다는 의미일 수 있고, 특정 기능이 완료되었다는 의미일 수 있다. 그 기능이 연결된 장치의 물리적 상태까지 원하는 대로 바뀌었다는 사실을 별도 텔레메트리로 확인해야 하는 임무도 있다.

가령 지상에서 안테나 방향을 변경하도록 요청했다고 가정해 보자. 명령 처리 기능이 요청을 접수하고 실행을 마쳤다는 보고를 돌려줄 수 있다. 이후 자세 센서나 구동 장치 상태가 예상한 방향과 일치하는지 확인하면, 명령 처리 결과와 장치 상태를 함께 검토하게 된다. 이 사례는 원리를 설명하기 위한 가상 예시이며, 실제 위성의 명령 형식이나 확인 절차를 나타내지 않는다.

반대로 텔레메트리 값이 기대한 상태를 보여도 그것만으로 어떤 명령이 원인이었다고 단정하기는 어렵다. 다른 제어 동작이나 자동 운용 기능이 같은 상태를 만들었을 수 있기 때문이다. 시간표시, 명령 식별 정보, 운용 모드, 관련 센서값을 한 흐름으로 살펴야 원인과 결과를 연결할 수 있다. 이전 글에서 상태값의 시각과 유효성을 강조한 것도 이 때문이다.

교신이 끊긴 동안 명령을 저장해 두기도 한다

저궤도 위성은 한 지상국과 계속 연결되어 있지 않다. 위성이 지상국의 가시권에 있는 동안 명령을 올리고, 접촉이 끝난 뒤에는 다음 교신까지 기다릴 수 있다. 일부 임무는 나중에 실행할 시각을 지정한 명령을 위성에 저장해 두기도 한다. ESA의 MetOp 운용 설명은 가시권에서 직접 전송해 실행하는 명령과, 보이지 않는 동안 실행하도록 위성에 저장하는 시각 지정 명령을 소개한다.

이런 방식에서는 송신 시각과 실행 시각이 다를 수 있다. 지상에서 예약 명령을 올린 시점에 접수 응답이 왔다고 해서, 예약된 동작이 이미 실행된 것은 아니다. 나중에 명령이 실행될 조건이 맞았는지, 실행 결과가 보고되었는지, 상태값이 기대와 맞는지를 각각 확인해야 한다. 화면에 최근에 도착한 응답이 실제로는 앞선 교신 구간에서 발생한 기록일 수도 있으므로 생성 시각과 수신 시각도 구분할 필요가 있다.

통신이 잠시 두절되었을 때도 마찬가지다. 확인 응답이 보이지 않는다고 해서 명령이 반드시 실패했다고 단정할 수는 없다. 응답이 아직 돌아오지 않았거나, 위성이 다음 교신을 기다리고 있을 수 있다. 반대로 응답이 없는데 같은 동작을 곧바로 다시 보내면, 첫 명령이 실행되었을 때 중복 동작이 생길 위험도 있다. 재전송과 중복 처리는 명령의 성격과 임무 규칙을 보고 결정해야 한다.

한 번 더 보내기 전에 명령 식별과 이력을 확인한다

명령은 단순한 문장이 아니라 정해진 대상과 매개변수, 실행 조건을 가진 요청이다. 같은 명령을 두 번 수행해도 문제가 없는지, 반복 수행이 위험한지에 따라 재전송 판단은 달라진다. 상태 확인을 요청하는 명령과 장치의 설정을 바꾸는 명령을 같은 방식으로 다룰 수 없는 이유다.

운용 기록에는 명령을 구분하는 식별 정보, 송신 시각, 적용 대상, 응답 상태와 후속 텔레메트리의 시각이 서로 맞물려야 한다. 명령 하나가 여러 하위 기능으로 전달될 수 있다면 어느 단계의 응답인지도 분명해야 한다. 그래야 ‘아직 확인되지 않음’, ‘접수되었으나 실행 대기’, ‘실행 실패’, ‘완료 보고 수신’ 같은 서로 다른 상태를 혼동하지 않는다.

이 원칙은 위성에만 해당하지 않는다. 여러 정보체계가 연결된 환경에서도 요청을 전달한 기록, 상대 시스템이 수신한 기록, 실제 업무가 끝난 기록은 구분될 필요가 있다. 데이터가 오가는 경로가 길어질수록 각 응답이 무엇을 보증하는지 정의하는 일이 중요해진다. 신뢰할 만한 화면은 모든 것을 초록색으로 표시하는 화면이 아니라, 확인된 사실과 아직 확인되지 않은 범위를 나누어 보여주는 화면이다.

짧은 생각
정보체계에서는 요청을 보냈다는 사실이 처리 결과처럼 보이는 순간이 있다. 하지만 지상에서 작성한 기록과 상대 시스템이 돌려준 응답, 실제 상태 변화는 각각 다른 위치에서 만들어진 증거다. 화면을 설계할 때 이 차이를 감추지 않고 보여주는 것이 오히려 운용자의 판단을 돕는다.

확인할 수 있는 범위를 정확히 남기는 일

위성 명령의 결과를 이해하려면 송신 이력만 보는 것으로는 부족하다. 임무에서 정의한 수신·접수 응답이 무엇을 뜻하는지, 실행 보고가 어느 단계까지 보증하는지, 이후 상태 텔레메트리가 어떤 시각의 값을 담고 있는지 이어서 살펴야 한다. 표준은 공통으로 참고할 구조와 서비스를 제시하지만, 실제 운용은 위성의 설계와 임무 요구에 맞게 정해진다.

위성은 지상 명령을 받아 실행하고 상태를 되돌려 보낸다. 다음 글에서는 여러 명령을 예약하거나 순서대로 실행할 때, 실행 조건과 결과를 어떻게 관리하는지 한 번 더 살펴본다. 이 주제를 마무리한 뒤에는 군사 정보체계로 시야를 넓혀 전술데이터링크가 여러 센서와 부대의 정보를 어떻게 공유하는지 이어가려 한다.

함께 읽으면 좋은 글

위성에서 온 상태값의 시각과 유효성을 먼저 이해하면, 명령 실행 뒤 돌아오는 텔레메트리도 더 정확하게 읽을 수 있다.

위성 관제 화면의 빨간 숫자, 정말 고장일까? 텔레메트리와 데이터 신선도

 

참고자료

• ECSS — ECSS-E-ST-70-41C: Telemetry and telecommand packet utilization: 우주선 감시·제어를 위한 텔레커맨드 요청 패킷과 텔레메트리 보고 패킷의 표준 범위 및 임무별 적용.
• ECSS Glossary — Execution verification report: 명령 실행의 시작·진행·완료 단계와 성공·실패 보고의 정의.
• European Space Agency — MetOp Operations: 가시권에서 즉시 전송하는 명령과 나중에 실행하도록 위성에 저장하는 시각 지정 명령 사례.
• European Space Agency — TT&C Systems and Techniques: 텔레메트리·추적·명령의 기본 역할.