PSU / 운항 지원
어떤 비행을
어떤 조건에서 수용할까.
운항자가 제출한 계획을 확인하고, PSU 역할로 내린 모의 결정과 운영 조건 검토 결과를 기록합니다. 계획 간 시간·경로 충돌과 제한 공역, 패드 가용성을 함께 다룹니다.
비행계획모의 수락·반려교통·자원 검토
UAM PSU · 운항통제 시스템
계획한 비행을,
보이는 운항으로.
계획 접수와 PSU 모의 검토, 패드 예약부터
모의기체의 비행과 관측 감시까지.
한 편의 UAM 운항을 연결하는 시스템입니다.
한강을 배경으로 개발한 개인 LAB
Java · ROS 2 · PX4 · Gazebo · Cesium
UAM OPS / HAN RIVER실제 구현 화면 ↗
계획과 관측
같은 비행으로 연결
같은 비행으로 연결
✦PX4 SITL → Cesium
모의기체 관측 표출
모의기체 관측 표출
2026.10.18 실제 화면 캡처 · 실시간 운영 화면이 아닙니다.
EXPLORE THE SYSTEM ↓
계획→검토·자원→실행→감시·기록
HAN RIVER / LOCAL SIMULATION01 / THE SYSTEM무엇을 위해 개발했나
PSU의 운항 지원과
운항통제를 하나의 흐름으로.
계획이 수락됐다는 사실만으로 기체를 출발시킬 수는 없습니다. 공역·기상·패드의 현재 조건을 확인하고, 실제 기체가 계획대로 움직이는지 계속 살펴야 합니다. 이 시스템은 그 판단에 필요한 업무와 데이터를 연결합니다.
어떤 비행을
FLIGHT OPERATIONS / 운항통제
출발할 수 있는가,
지금 어떻게 비행하는가.
시설 사용 허가와 실행 위임, 출발 시각을 확인한 뒤 PX4 모의기체에 연결합니다. 수신한 위치와 고도를 지도에 표시하고, 자료 품질과 운항 상태를 확인합니다.
위임·출발기체 연계감시·이력
PSU는 이 LAB에서 계획 검토와 운항 지원을 맡도록 구성한 역할입니다. 실제 기관의 운항 허가·안전 인증이나 상용 PSU 서비스와는 구분합니다.
역할 구분의 참고 자료 [1] FAA UAM ConOps §4.3 · [4] 비행자료·감시자료 처리
02 / PRODUCT TOUR구현한 화면과 기능
설명보다 먼저,
화면을 살펴보세요.
직접 구현한 업무 화면입니다.
화면을 선택하고 이미지를 누르면
세부 내용을 크게 볼 수 있습니다.
ACTUAL PROJECT SCREEN
한강 운항 모니터링
비행계획과 시설 정보, 수신한 관측 자료를 한강 지도에서 함께 보고, 선택한 비행의 위치와 상태를 확인합니다.
- 계획 선과 실제 관측 항적 구분
- 선택 기체의 위치·고도·방향 확인
- 자료 출처와 상세 표본으로 이동
실제 PX4 관측을 다루는 LAB 화면 · 2026.10.18 캡처
03 / FLIGHT LIFECYCLE한 편의 운항을 처리하는 방식
계획을 작성한 순간부터,
비행을 마친 뒤까지.
01 / 05PLAN BUILDER
LAB-ALAB-B
화면은 실제 캡처 / 아래 경로는 운항 흐름 설명용 도식
시각을 포함한 비행계획
기체와 출·도착 시설을 고르고, 각 FIX의 위도·경도·고도·시각을 입력합니다. 초안에 GUFI를 발급하고 FF-ICE/FIXM XML을 검사해 접수합니다.
모의 결정과 운항 검토
PSU 화면에서 수락·반려와 사유를 기록합니다. 공역과 기상, 계획 간 충돌은 별도로 검토하며, 검토한 조건의 버전도 남깁니다.
출발지와 도착지의 자원
패드를 독립 자원으로 보고 시간창을 예약합니다. 예약·물리 점유·시설 허가를 구분하고, 도착 자원이 부족하면 출발지에만 새 예약이 남지 않도록 처리합니다.
위임한 계획을 모의비행으로
명시적으로 실행을 요청하면 PX4·Gazebo를 준비하고 출발 시각과 조건을 재확인합니다. Python 어댑터가 시간별 목표를 보내고 기체의 관측 위치를 받습니다.
관측·종료·이력까지 연결
관측을 ROS 2·CAT021 경로로 수신·저장하고 지도에 표시합니다. 정상 종료 때 착륙·시동 해제·실행 정리를 확인해 예약을 반환하고, 판단과 관측 이력은 보존합니다.
04 / SEE IT IN MOTION구현·실험 시연
기체가 움직이면,
화면도 이어집니다.
새로 촬영한 Gazebo 모의비행과
같은 실행의 관측·운항 화면입니다.
기존 기록 재생 영상도 함께 볼 수 있습니다.
LIVE SIMULATION RECORDING
기체의 움직임부터 운항 화면까지
단일 PX4의 이륙·경로 이동·착륙을 Gazebo 카메라로 새로 촬영했습니다. 같은 실행의 ROS 2 관측 기록과 운항 화면을 함께 보여줍니다. 기체 영상은 8배속, 운항 화면은 별도 구간의 2배속 편집입니다. 기체의 움직임을 확인하도록 격자를 추가한 8 m급 저고도 모형 시험이며, 실제 항공기 운항이나 1,000ft 시나리오를 뜻하지 않습니다.
영상 원본 ↓05 / DESIGN DECISIONS설계와 기술을 선택한 근거
운항에서 생긴 질문을,
설계의 기준으로.
목표는 단일 PC에서 한 편의 모의 운항을 끝까지 연결하고, 판단과 데이터의 근거를 확인하는 것이었습니다. 이 목표에 맞춰 무엇을 분리하고 어떤 도구를 쓸지 정했습니다.
단일 기체의 전체 흐름상태 변경의 책임원 관측의 추적실패 뒤의 복구
01 / OPERATIONAL STATE
계획 수락과 출발을
왜 나눴는가
계획을 수락한 뒤 패드가 닫히거나 기상이 바뀌면, 이전 결정을 그대로 출발 허가로 사용할 수 없습니다.
- 단순하게 묶을 경우
- 하나의 승인 상태에 검토·예약·허가·출발을 담으면 어떤 판단을 철회해야 하는지 모호해집니다.
- 선택과 이유
- PSU 모의 결정·운항 검토·예약·시설 허가·위임·출발을 분리했습니다. 조건 변경 시 영향을 받는 위임을 무효화하고, 출발 시점에 다시 검사하기 위해서입니다.
구현에서 확인한 근거
도착 패드 폐쇄 시 예약을 거절하고 출발지에만 예약이 남지 않는지 확인했습니다. 합성 WIND를 해제해도 철회한 위임은 자동으로 복원되지 않았습니다.
역할·자원 개념 [1] ↗설계 판단·시험 기록 ↗02 / PLAN & OBSERVATION
예정 경로와 관측을
왜 따로 다뤘는가
계획상 지나야 할 좌표가 화면에 움직인다는 사실만으로 기체가 그곳을 비행했다고 판단할 수는 없습니다.
- 구분하지 않을 경우
- 보간한 목표 위치와 실제 기체 위치, 늦게 도착한 관측과 현재 상태를 혼동할 수 있습니다.
- 선택과 이유
- 제어 목표는 계획에서 계산하고 관측은 PX4 추정 위치에서 받았습니다. GUFI·실행 ID·표본 번호로 비행·실행·측정을 구분해 어느 경계에서 값이 달라졌는지 추적하도록 했습니다.
구현에서 확인한 근거
30분간 실행하며 얻은 8,279개 표본을 원 관측·ROS·CAT021 원문·DB 값으로 대조했습니다. 선택 표본의 원천·변환·수신·저장을 화면에서 나란히 볼 수 있습니다.
표본 추적 화면 ↑처리 역할의 사후 대조 [4] ↗03 / EXCHANGE FORMAT
표준 형식과 실행 정보를
왜 나눠 담았는가
비행계획과 감시자료의 각 항목이 무엇을 뜻하는지 확인하려면, 프로젝트 내부 필드와 대조할 기준이 필요했습니다.
- 임의 필드에 모두 담을 경우
- 계획·관측·실행 식별자의 의미가 섞이고, 어떤 항목이 규격에 속하는지 설명하기 어려워집니다.
- 선택과 이유
- 계획은 FF-ICE/FIXM의 제한 프로필과 공식 XSD로 검사하고, 감시자료는 CAT021에서 선택한 항목에 맞춰 해석했습니다. GUFI·실행 ID·모형 고도는 별도 봉투에 두어 규격 필드의 의미를 바꾸지 않았습니다.
구현에서 확인한 근거
제출 XML 원문과 CAT021 바이트를 보존해 파싱 결과와 대조합니다. 모형 기준면의 높이를 WGS-84 타원체 높이로 바꿔 설명하지 않았습니다.
계획 구조·스키마 [2] ↗감시 항목·좌표 정의 [3] ↗04 / DELIVERY & RECOVERY
MQ 도입 전에 왜
outbox·ACK를 만들었는가
기체는 계속 움직이는데 Java 서버가 내려가자 위치 표본 198개가 DB에 저장되지 않았습니다. 송신 완료와 저장 완료는 달랐습니다.
- 브로커를 먼저 둘 경우
- 전달을 맡길 수 있지만 별도 운영 구성도 생깁니다. 첫 단계에서는 단일 기체의 위치 표본이 생성된 뒤 저장되기까지를 직접 검증하는 데 범위를 맞췄습니다.
- 선택과 이유
- SQLite outbox에 먼저 보관하고 Java의 DB commit 뒤 ACK를 받도록 했습니다. 미확인 표본은 재전송하고 식별자·본문으로 중복과 충돌을 구분합니다. 대신 재시도·오류 격리·중복 처리를 직접 관리해야 했습니다.
구현에서 확인한 근거
누락된 198개를 복구하고 재전송 뒤 저장 건수가 늘지 않는지 확인했습니다. 이는 해당 시험의 복구 근거이며 exactly-once 전달 보장으로 일반화하지 않습니다.
ACK·재전송·중복 비교 근거 ↗복구 시험 기록 ↓TOOLS FOLLOW THE REQUIREMENTS
도구도 같은 기준으로 골랐습니다.
선택한 도구필요했던 일과 선택 이유선택에 따른 조건
Java · Spring Boot
계획·검토·예약·버전·이력을 한 업무 서비스에서 처리하고, 여러 상태 변경을 트랜잭션 경계 안에서 관리하기 위해 사용했습니다.
기체 제어 주기와 업무 처리는 분리하고 Python 어댑터와 명시적 실행 계약으로 연결했습니다.
H2 파일 DB · Flyway
단일 PC에서 별도 DB 서버 없이 반복 실행하고, 재시작 뒤 데이터와 스키마 변경 이력을 함께 확인하려고 선택했습니다.
이 구성에서의 저장·재시작을 검증했습니다. 다른 DB보다 빠르다는 비교 결과를 선택 근거로 삼지 않았습니다.
Python · ROS 2
모의기체를 실행하고 관측을 수집하는 데 사용했습니다. 발행과 별도 구독·변환 사이의 경계를 기록하도록 역할을 나눴습니다.
기체 명령은 MAVLink 경로입니다. ROS 2는 관측 전달 경계에 쓰며 PX4 DDS 명령 경로로 설명하지 않습니다.
PX4 SITL · Gazebo
예정 좌표를 단순히 재생하는 데 그치지 않고, 모의기체가 만든 추정 위치와 동작을 받아 계획·관측·종료 상태를 대조하려고 선택했습니다.
모의 센서·월드 기준의 시험입니다. 영상에는 실제 모의비행 기록과 합성 교통을 구분해 표시합니다.
React · TypeScript · Cesium
계획·검토 양식과 지리 좌표·고도 표출을 연결하고, 지도에서는 최소 정보를 보고, 비행을 선택하면 세부 정보와 근거를 확인하도록 구성했습니다.
계획선과 관측 항적, 자료 출처를 따로 표시하고 모형 고도의 기준을 함께 설명합니다.
Windows + WSL2
사용하던 PC와 Linux 기반 ROS 2·Gazebo·PX4 실행 환경을 함께 쓰기 위한 선택입니다.
Java도 WSL2에서 실행하는 로컬 LAB입니다. 네트워크·시계·프로세스 종료 경계는 별도 검수 대상으로 다뤘습니다.
선택 이유는 기존 블로그의 ‘세 가지 문제와 설계 판단’, ‘도구와 실행 환경을 고른 이유’ 및 실제 구현 문서와 대조했습니다. 위 비교는 이 LAB의 목표·제약에 따른 판단이며 언어·DB·브로커 간 성능 우열을 측정한 결과가 아닙니다. 선택 이유를 정리한 공개 기록 ↗
06 / CONNECTED BY DESIGN화면 아래의 연결 구조
계획은 기체로.
관측은 화면으로.
업무 처리와 기체 연계를 나누고,
같은 비행·실행·관측을 따라
요청과 결과가 이어지도록 구성했습니다.
01 / WORKSPACE
업무·감시 화면
React · TypeScript
Cesium 2D / 3D
02 / OPERATIONS
운항 서비스
Java · Spring Boot
계획·자원·실행 · H2
03 / ADAPTER
기체·관측 연계
Python · ROS 2
SQLite outbox · CAT021
04 / SIMULATOR
모의기체·환경
PX4 SITL · Gazebo
MAVLink 목표·관측
COMMAND / 실행 요청
웹의 요청을 Java에서 검토하고, 실행 계약과 시각 조건을 확인하는 단계를 거친 뒤 Python 어댑터가 PX4에 목표를 보냅니다.
FF-ICE / FIXM시각을 포함한 비행계획의 제한 프로필
GUFI · 실행 ID · 표본 번호비행·실행·관측을 구분하는 식별자
CAT021 부분집합 + 별도 봉투위치 원문과 실행 메타데이터를 분리
FROM A DOT TO ITS ORIGIN
지도 위 한 점에도
확인할 근거가 있습니다.
위치가 보인다는 것과 그 위치를 믿을 수 있다는 것은 다릅니다. 선택한 표본의 출처·시각·변환·수신 원문·DB 값을 나란히 확인할 수 있게 만들었습니다.
출처를 보존원 관측과 변환값을 구분하고 같은 표본으로 대조
불확실성 표시지연·누락·고도 기준 부족은 UNKNOWN
저장 확인 후 완료outbox에 먼저 보관하고 DB commit ACK 확인
GUFI·보조 고도는 CAT021 밖의 메타데이터입니다.
07 / IMPLEMENTED SCOPE현재 구현과 확인한 범위
실제 모의비행으로
연결을 확인했습니다.
아래는 서로 다른 기존 실행의 결과입니다.
표본 수는 항공기 수나 시험 횟수가 아닙니다.
위치 표본의 관측·ROS·DB 원문 대조
누락 표본 복구·동일 표본 중복 저장 방지
단일 PX4 순차 시험·독립 ULog 대조
전체 표본 전달·착륙·시동 해제·예약 반환
각 수치의 검증 방법과 기록은 프로젝트 시험 근거 ↓에서 확인할 수 있습니다.
구현한 기능 +
현재 구현
제한 FF-ICE 계획 접수, PSU 모의 결정, 운영 조건 검토, 패드 예약·허가, 단일 PX4 연계, 관측 저장·표출·추적, 회랑 감시와 전략·전술 자문, 복구·재전송.
영상·모형·성능 수치의 해석 +
대표 영상은 2026년 10월 19일 새로 녹화한 단일 PX4 모의비행입니다. 다른 화면·영상은 기존 프로젝트 자료입니다. 비정상 시연은 저고도 단일 PX4 실행 기록의 압축 재생입니다. 복행·대체 이동은 시험용 Offboard 동작이며 Java 자문 API와 자동 연결된 명령 기능이 아닙니다.
1,000ft는 모형 기준면 가정의 정상 시나리오 목표입니다. 10월 19일에는 저고도에서 일정을 20배로 압축해 재검수했습니다. 640개 전체 전달을 확인했고, 관측→ACK 지연은 p95 0.850초·p99 3.189초였습니다. p99가 목표를 넘어 지연 판정은 REVIEW입니다. 서로 다른 시험·계측 경계의 직접 비교는 하지 않습니다.
08 / SOURCES & EVIDENCE출처와 검증 근거
FROM REFERENCES TO IMPLEMENTATION
설계에 참고한 자료와,
구현으로 확인한 근거.
공개 문헌에서 역할과 데이터 구조를 참고하고, 실제 동작은 개인 LAB의 화면·관측·시험 기록으로 확인했습니다. 각 자료가 설명하는 범위와 이 프로젝트에 적용한 내용을 함께 적었습니다.
PSU와 운항자, 버티포트의 역할
FAA UAM ConOps v2.0 §4.3.2·§4.3.4·§4.3.7은 운항자·PSU·버티포트의 역할과 운항 의도·자원 가용성의 관계를 설명합니다.
프로젝트 연결계획 검토, 패드 가용성, 운항자 실행 요청을 서로 다른 업무로 구성했습니다.
FAA UAM ConOps v2.0 · §4.3 ↗비행계획의 구조와 메시지
FIXM Core 4.3.0과 FF-ICE Message 1.1.0의 스키마·공식 설명서를 계획 교환 구조의 기준으로 사용했습니다.
프로젝트 연결제한 FFP 프로필의 XML/XSD 검사, GUFI 식별, 시간별 FIX 입력과 제출 원문 보존에 적용했습니다.
FIXM 공식 사용자 설명서 ↗Core 4.3 / Message 1.1 스키마 ZIP ↗감시 원문과 좌표의 해석
EUROCONTROL ASTERIX CAT021 ed2.7의 데이터 항목과 부호화 정의를 참고했습니다. WGS-84 위치 항목은 §5.2.18·§5.2.19에서 확인할 수 있습니다.
프로젝트 연결선택한 CAT021 부분집합의 송수신 원문과 DB 값을 대조했습니다. GUFI·실행 ID·보조 고도는 별도 봉투의 메타데이터입니다.
CAT021 ed2.7 · 위치 항목 ↗계획 처리와 관측 처리의 구분
EUROCONTROL FDPS Guidance v1.0(2024)와 ARTAS 공식 기능 설명은 구현을 마친 뒤 대조한 참고 자료입니다.
프로젝트 연결비행계획 처리와 기체 관측 처리를 나누고, 같은 비행으로 연결해 계획과 실제 움직임을 비교했습니다.
FDPS Guidance v1.0 ↗ARTAS 공개 기능 설명 ↗모의기체와 실행 환경
실행 환경과 같은 PX4 v1.17의 Gazebo Simulation 문서를 기준으로 모의비행과 기체 연계를 구성했습니다.
프로젝트 연결Python의 목표 위치 전달, PX4 관측 수집, 착륙·시동 해제 확인을 실제 모의기체 기록과 대조했습니다.
PX4 v1.17 · Gazebo Simulation ↗비정상 상황의 시험 관점
K-UAM ConOps 1.5 §5-2의 경미한 비정상상황·우발상황·비상상황 구분과 착륙복행 용어를 대조했습니다. NASA HDV 시험 시나리오와 FAA UAM ConOps §6.1의 자원 확인 흐름도 참고했습니다.
이 LAB의 통신두절 시험에서는 지상관제 연결 확인 신호만 중단했습니다. 제어명령 두절과 감시정보 수신두절도 별도 조건으로 시험해 기체 제어와 감시정보 전달을 구분했습니다.
프로젝트 연결공식 운용개념의 상황 구분을 참고하고, 화면과 영상의 설명은 실제 모의시험 조건에 맞췄습니다.
K-UAM ConOps 1.5 · §5-2 / 인쇄 42–44쪽 ↗NASA HDV · AIAA SciTech 2024 ↗FAA UAM ConOps · §6.1 ↗문헌은 설계·대조의 참고 자료이며, 아래 수치는 이 프로젝트의 자체 시험 결과입니다. 한국 UAM 공통 의무 규격이나 ARTAS 코드·알고리즘을 적용했다는 의미로 사용하지 않았습니다.
PROJECT TEST RECORDS
수치 뒤의 검증 방법
10월 19일 · 대표 영상827개 표본
같은 실행의 Gazebo 녹화 영상과 관측 자료·ROS 2 기록·DB ACK를 대조했습니다. 착륙·시동 해제는 확인했고 자동 정리는 제한 시간을 초과했습니다. 이후 프로세스 종료를 별도 확인했으며 전체 실행 PASS로 표시하지 않습니다.
영상 실행 근거 ↗공개 기록에는 개발 의도·시험 결과·참고 문헌과 각 영상의 재생 유형이 정리돼 있습니다. 화면과 시험은 2026년 10월의 개인 LAB 기록이며 실제 운항 허가·안전 인증을 의미하지 않습니다.