제9부 규격·프로토콜·인터페이스
9.14 UTM·U-space·ATM 정보 교환: ASTM F3548·InterUSS·SWIM·FIXM·AIXM·지오존 데이터(ED-269·ED-318)
9.14.1 이 장에서 배우는 것 / 선수 지식 / 특히 중요한 독자
앞의 장들은 기체가 방송하는 신호(9.12)와 기체·지상국 사이의 메시지(9.5)를 다루었다. 이 장은 그 위층, 곧 지상의 서비스 제공자·당국·항공 교통 서비스 제공자가 비행 계획과 공역 정보를 서로 어떤 형식과 규칙으로 교환하는가를 다룬다. 이 층의 규격은 하나가 아니다. 유인 항공 교통 관리가 수십 년 쌓은 항공 정보 모델(AIXM·FIXM)과 SWIM 계열, 무인기 교통 관리를 위해 최근 만든 ASTM F3548과 InterUSS의 DSS, 그리고 지오존 데이터를 위한 EUROCAE ED-269와 ED-318이 각자의 역할로 병존하고, EU의 U-space 규정이 이를 한 체계로 접합하려 한다.
배우는 것:
- 정보의 세 종류와 세 층 — 공역 정보·운용 의도·비행 정보, 그리고 데이터 모델·서비스·기술 기반.
- ASTM F3548의 공개 OpenAPI — 25개 연산, 운용 의도·구독·제약, OVN과 키로 하는 낙관적 동시성 제어, 네 상태, 토큰 기반 인증.
- DSS의 공역 표현 — S2 13단계 셀로 정확한 부피를 버리는 설계와 그 비용(워크스루).
- EU U-space의 공통 정보 서비스 — 규정과 AMC·GM이 어떤 규격을 어떤 수치와 함께 지목하는가.
- ED-269에서 ED-318로 — 지오존 데이터 모델의 구조, 판의 이동, 국가 프로필의 차이.
- AIXM·FIXM·SWIM — 항공 정보 계열의 구조와 EUROCONTROL SWIM TI Yellow Profile의 판 변화.
- 세 가지 워크스루 — 셀 수와 후보 공간, 표현 변환(원·고도 기준·시간 규칙), 지연·가용성의 합성.
선수 지식: 0.8(공역과 비행 규칙), 2.13(감시), 9.1(규제·표준·규격의 관계와 판 관리), 8.12(UTM 보안)를 읽었다고 가정한다. UTM의 개념과 아키텍처는 14.22, U-space와 한국의 실증은 14.23, EU 규정의 조문별 해설은 17.12이 다룬다. 이 장은 그 설명을 반복하지 않고 정보 교환 규격의 구조와 수치에 집중한다.
특히 중요한 독자: UTM·USSP 소프트웨어 개발자는 9.14.3·9.14.4·9.14.8·9.14.9를, 당국·규제 담당자는 9.14.5·9.14.6·9.14.10을, 항공 정보·ATM 담당자는 9.14.7을, 인증·보안 담당자는 9.14.3.6·9.14.5.4·9.14.14를 먼저 읽는다.
기준 시점과 정직성. 2026년 11월 기준이다. 원문을 읽은 것: ASTM UTM 공개 OpenAPI(
astm-utm/Protocol저장소의utm.yaml, 3,918줄, 저장소 마지막 갱신 2024-01-09), InterUSS DSS 저장소의 문서(concepts.md, 배치 구조·풀링·크기 산정,pkg/geo/s2.go), S2 셀 통계표, EASA의 U-space 쉬운 접근 규칙(2024년 5월판, 157쪽 — 규정 2021/664와 AMC·GM(ED Decision 2022/022/R)을 묶은 비공식 편집본), EUROCONTROL-SPEC-170 SWIM TI Yellow Profile 1.1판(2020-07-05, 78쪽)과 2.0판(2025-07-14, 71쪽), FIXM Core 4.3.0 아카이브(Primer·릴리스 노트·XSD 26개), AIXM 사이트의 판 안내·Digital NOTAM 안내와 Donlon_2025 표본 공역 파일(AIXM 5.1.1), EUROCAE의 ED-318·ED-269 Change 1 공개 안내문, EUROCAE WG-105의 ED-269 갱신 발표 자료(FAA ATIEC 2023, 22쪽), 스위스 연방민간항공청(BAZL)의 지오존 데이터 모델 문서 2.0판(48쪽), FAA UTM 운용 개념 2.0판(2020-03-02, 80쪽). 읽지 못한 것: ASTM F3548-21과 F3411 본문(유료), EUROCAE ED-269·ED-318 본문(유료), EUROCONTROL SWIM Service Description 2.0판, ICAO Doc 10039·9965·10150(FIXM Primer가 인용한 범위만), AIXM·FIXM의 UML 전체, FAA SWIM 문서, EUR-Lex의 규정 정본(EASA 편집본으로 대체), 한국의 드론교통관리 기술 규격. 공개 OpenAPI 파일은 표준 본문과 같다고 확인하지 못했다. InterUSS의 README는 표준을 F3548-21로, 자기 저장소의 OpenAPI를 F3548-22로 적는데 이 판 표기의 관계는 해소하지 못했다(확인 필요). InterUSS 문서는 프로젝트 문서이며 표준 본문이 아니다. 읽지 못한 부분은(확인 필요)로 표시했다.
9.14.2 개념·직관 — 무엇을 어느 층에서 교환하는가
정보의 세 종류. ① 공역 정보는 어디에서 비행이 제한되거나 조건부인가를 말한다. 지오존처럼 몇 달에 한 번 바뀌는 것부터 임시 제한처럼 몇 초 안에 알려야 하는 것까지 변화 속도가 다르다. ② 운용 의도(operational intent)는 누가 언제 어느 4차원 부피를 사용하려는가를 말한다. 서로 경쟁하는 조직이 소유하고 자주 바뀌며 충돌 확인이 필요하다. ③ 비행 정보는 항공기별 계획·식별·위치이며, 유인 항공 교통 관리가 오래 다룬 영역이다.
세 층. 어떤 교환이든 ⓐ 데이터 모델(무엇을 어떤 구조와 부호로 표현하는가), ⓑ 서비스(조회·구독·갱신 같은 동작과 그 규칙), ⓒ 기술 기반(전송·인증·암호)으로 나눠 읽으면 규격 사이의 관계가 보인다. 이 장이 다루는 규격은 층마다 다르다.
| 층 | 항공 정보 계열(유인 ATM) | 무인기 교통 계열(UTM) | 지오존·공통 정보(U-space) |
|---|---|---|---|
| 데이터 모델 | AIXM(공역·절차), FIXM(비행·흐름) | OpenAPI의 Volume4D·운용 의도 | ED-269 8장 → ED-318 |
| 서비스 | SWIM 서비스 기술서 | DSS 참조·구독 + USS 간 세부 조회·통지 | UAS 구역 조회·갱신 배포(ED-269 9장 → ED-318) |
| 기술 기반 | SWIM TI Yellow Profile(AMQP 1.0·SOAP·TLS) | OAuth 2.0 토큰(JWT, RS256) | 규정 부속서 II·III |
두 계보의 접합. 항공 정보 계열은 ICAO·EUROCONTROL·FAA의 오랜 협업에서, 무인기 교통 계열은 웹 기술(JSON·OpenAPI·OAuth)에서 왔다. EU의 AMC는 한 규정 안에서 SWIM TI Yellow Profile, ASTM F3548, ED-269를 모두 지목한다(9.14.5). 접합부의 비용은 형식 자체가 아니라 변환 규칙, 곧 기하(호·원), 높이 기준(해발·타원체고), 시간(반복 규칙·명시 구간)에서 생긴다. 9.14.8이 실제 표본으로 그 비용을 계산한다.
9.14.3 ASTM F3548 — USS 사이의 상호운용
9.14.3.1 무엇을 정하는 표준인가
InterUSS의 설명에 따르면 ASTM F3548-21은 USS(UAS Service Supplier) 사이의 상호운용을 정의하며 다섯 서비스를 둔다. 전략적 충돌 탐지(SCD), 제약 관리, 제약 처리, 상황 인식을 위한 적합성 감시(CMSA), 운용 의도의 집계 적합성 감시(ACM)이다. ACM을 뺀 넷은 USS 사이의 조율이 필요하고 DSS(Discovery and Synchronization Service)가 이를 중개한다. 공개 OpenAPI의 인증 범위(scope) 다섯 개 가운데 utm.strategic_coordination·utm.constraint_management·utm.constraint_processing·utm.conformance_monitoring_sa가 이 넷에 대응하고, 다섯째 utm.availability_arbitration은 USS의 가용 상태를 정하는 역할이다. ACM에 대응하는 범위는 이 파일에서 찾지 못했다 (확인 필요).
DSS의 역할은 발견과 동기화로 제한된다. DSS는 운용 의도의 세부를 보관하지 않고, 개체의 참조(식별자·셀 범위·시간·세부를 가진 USS의 주소)와 구독만 보관한다. 세부는 해당 USS에게서 직접 읽는다. 변경 통지도 DSS가 보내지 않고 변경한 USS가 구독자 USS에게 보낸다(InterUSS concepts.md). 이 분업이 9.14.4의 설계 문제를 만든다.
9.14.3.2 API의 구조 — 25개 연산
공개 OpenAPI(utm.yaml)는 경로 항목마다 get·put·post·delete를 세면 연산 25개이다. DSS 서버가 18개, USS 서버가 7개이다.
| 묶음 | 서버 | 연산 | 용도 |
|---|---|---|---|
| 운용 의도 참조 | DSS | 질의·조회·생성·갱신·삭제(5) | 시간 창이 있는 4D 부피의 참조 |
| 제약 참조 | DSS | 질의·조회·생성·갱신·삭제(5) | 지오존·임시 제한 같은 제약의 참조 |
| 구독 | DSS | 질의·조회·생성·갱신·삭제(5) | 관심 부피의 변경 통지 신청 |
| 보고 | DSS | 1 | 다른 DSS의 문제 보고 |
| USS 가용성 | DSS | 설정·조회(2) | USS가 정상·정지인지의 중재 |
| 운용 의도 | USS 간 | 세부 조회·원격 측정 조회·세부 변경 통지(3) | 세부와 비적합 상태의 위치 |
| 제약 | USS 간 | 세부 조회·변경 통지(2) | 제약의 세부 |
| 보고·로그 | USS 간 | 보고·로그 세트 조회(2) | 문제 보고와 감사 자료 |
질의에 POST를 사용한다. 운용 의도·제약·구독의 질의 연산은 상태를 바꾸지 않지만 HTTP POST이다. 파일은 그 이유를 요청 본문이 필요한데 GET에서 본문을 요구하는 것은 비표준이고 일부 구조가 지원하지 않기 때문이라고 설명한다. 구현자가 캐시 정책에서 POST를 부작용 있는 연산으로 취급하면 오류가 된다.
9.14.3.3 운용 의도·OVN·키 — 낙관적 동시성
운용 의도의 참조는 식별자(UUID v4), 관리 USS, 버전, 상태, 시작·종료 시각, 세부를 가진 USS의 기본 URL, 구독 식별자를 포함한다. 세부(부피 목록, 비적합 때의 예상 이탈 부피, 우선순위)는 DSS에 없고 USS에만 있다. 서로 다른 USS가 같은 공역을 동시에 차지하지 않게 하는 장치가 OVN(opaque version number)과 키이다. OVN은 개체가 생성·변경될 때 DSS가 만들어 그 개체를 관리하는 USS에만 돌려주는 불투명한 토큰(16~128자)이다. 다른 USS는 OVN을 세부를 가진 USS에게서 읽어야 한다. 새 운용 의도를 Accepted나 Activated로 만들거나 바꾸려는 USS는 관련된 모든 개체의 OVN을 모은 키를 요청에 붙여야 한다. 키가 최신이 아니면 DSS는 409와 함께 누락된 운용 의도·제약의 목록을 돌려주고, USS는 세부를 다시 읽어 키를 고쳐 재시도한다. 읽은 뒤에야 갱신할 수 있다는 규칙이 중앙 잠금 없이 충돌을 막는다.
9.14.3.4 부피와 단위의 제약
공개 OpenAPI가 부피와 단위에 둔 제약은 변환 문제의 출처이다.
- 수평 형태. Volume3D는 원 또는 다각형 중 하나이다. 다각형은 꼭짓점 3개 이상이고 변은 꼭짓점 사이의 최단 경로이며 변이 교차하거나 꼭짓점이 중복되거나 마지막 꼭짓점이 첫 꼭짓점과 같으면 안 된다. 호나 타원은 없다.
- 높이. 값은 −8,000~100,000 m 범위, 기준은 WGS 84만, 단위는 미터만 허용한다. 파일은 AIXM·FIXM의
SFC가 AGL과 같다고 적으면서 UTM에는 허용하지 않는다고 한다. - 시간. RFC 3339 문자열이며 시간대는 Z이다. 부피마다 시작·종료가 명시되고 반복 규칙은 없다.
- 식별자. 개체는 UUID v4, 반지름은 미터만 허용한다.
9.14.3.5 상태·우선순위·가용성
운용 의도의 상태는 Accepted(공유됨, 아직 사용 안 함), Activated(사용 중), Nonconforming(항공기가 부피를 일시 벗어났으나 복구 예상), Contingent(복구 불가, 종료로만 이어짐)이다. 상태 사이의 허용 전이는 파일이 "표준 본문을 보라"고 하므로 이 책은 확인하지 못했다 (확인 필요). 우선순위는 정수이며 규제 당국이 정의한다. 낮은 우선순위는 높은 우선순위와 충돌을 만들 수 없고 높은 쪽은 만들 수 있으며, 같은 우선순위의 충돌 허용 여부는 규제가 정한다. USS 가용성은 Unknown·Normal·Down이다. Down인 USS는 Accepted·Activated 운용 의도를 만들거나 바꾸거나 삭제할 수 없다. 가용성을 정하는 권한은 별도 범위(availability_arbitration)로 분리된다. 비적합·비상 상태에서는 USS 간 원격 측정 조회 연산이 위치·속도를 돌려주며, 위치 정확도의 열거값은 수직이 ADS-B의 GVA 열거에, 수평이 NACp 열거에 UAS용 세밀한 값을 더한 것이다(2.13·9.12).
9.14.3.6 인증과 보안
접근 통제는 OAuth 2.0 클라이언트 자격 증명 방식이다. 권한 기관이 RS256으로 서명한 JWT를 발급하고 클레임은 iss·exp(발급 후 최대 1시간)·sub·scope·jti를 포함한다. 최소 권한 원칙에 따라 한 토큰에는 열거된 범위 가운데 하나만 부여하고, 토큰의 재사용을 막기 위해 aud 클레임에 접근할 URL의 정규화된 도메인 이름을 요구하며, 서버 발견은 RFC 8414를 따른다. 이 파일에서 메시지 본문의 서명이나 부인 방지 요구는 찾지 못했다(표준 본문은 확인 필요). 토큰 기반 통제는 요청의 신원을 확인하지만 USS 사이에 오간 세부가 변조되지 않았음을 사후에 증명하지는 않는다. 파일에는 감사용 로그 세트의 형식(교환 기록·계획 기록·사용자 알림 기록 등)이 정의되어 있어 사후 검증의 재료는 있다. UTM 보안의 위협과 요구는 8.12, 키 관리는 9.19가 다룬다.
9.14.3.7 FAA 운용 개념과의 관계
FAA의 UTM 운용 개념 2.0판(2020-03-02)은 USS 네트워크를 서로 연결되어 운용자를 대신해 정보를 교환하는 USS의 집합으로, 공유되는 틀(충돌 조정 방법과 운용 의도 전송 표준)을 가져야 한다고 서술한다. 보충 데이터 서비스 제공자(SDSP)는 지형·장애물·기상·감시·제약 정보를 제공하고, FIMS는 FAA 시스템과 UTM 참가자 사이의 데이터 교환 인터페이스이다. UVR(UAS 부피 예약)은 경찰·재난 대응 같은 임시 활동을 위해 USS 네트워크를 통해 전파된다. 같은 문서의 각주는 운용 부피의 생성·공유·사용 방식을 ASTM 같은 산업 기구가 표준화하는 중이라고 적는다. 공개 OpenAPI 파일에서 FIMS라는 이름은 찾지 못했다. 운용 개념의 역할 구조 가운데 USS 사이의 부분이 F3548로 표준화되었다고 읽을 수 있으나 FAA 쪽 인터페이스의 규격은 이 장이 확인하지 못했다 (확인 필요).
9.14.4 DSS의 공역 표현 — 정확한 부피를 버리는 설계
9.14.4.1 S2 셀과 요구 DSS0040
InterUSS 문서에 따르면 DSS는 개체를 DAR(DSS Airspace Representation)로 사상하는데, DAR은 고정 단계의 S2 셀이며 현재 구현은 13단계이다(pkg/geo/s2.go의 최소·최대 셀 단계가 모두 13이고, 다른 단계의 셀은 "현재 구현에서는 13단계여야 한다"는 오류가 된다). 정확한 범위는 요구 DSS0040에 따라 버린다. 그 결과 진짜 교차 판정은 DSS에서 할 수 없다. 두 개체가 교차하면 반드시 한 셀 이상을 공유하지만, 셀을 공유한다고 교차하는 것은 아니다. DSS는 관련 셀의 모든 개체를 돌려주므로 관심 영역과 완전히 떨어진 개체도 후보로 온다. 정확한 판정은 후보의 세부를 USS에게서 읽어 클라이언트가 한다. InterUSS 문서는 이 설계의 목적을 운영자와 소비자의 사생활을 보호하면서 USS 사이의 통신을 돕는 것으로 설명하고, UAS 운용의 세부가 DSS에 저장되거나 처리되지 않는다고 한다.
9.14.4.2 워크스루 — 셀 수와 후보 공간
S2 통계표는 13단계 셀의 면적을 최소 0.76 km², 최대 1.59 km², 평균 1.27 km²로 싣는다(전 지구 셀 수 약 4억 265만 개, 곧 $6\times 4^{13}=402{,}653{,}184$). 0단계 면적 85,011,012.19 km²를 $4^{13}$으로 나누면 평균 1.2668 km²이고 정사각형으로 근사한 한 변은 1,125.5 m이다. 한 변 $a$인 정사각형 부피를 이 격자 위에 임의로 놓으면 걸치는 셀 수의 기댓값은 다음과 같다.
$$E[n]=\left(1+\frac{a}{L}\right)^{2}$$
원(반지름 $r$)은 셀과의 민코프스키 합의 면적 $L^{2}+4Lr+\pi r^{2}$를 $L^{2}$로 나눈 $1+4\rho+\pi\rho^{2}$($\rho=r/L$)이다. 9.14-calc.py의 결과는 다음과 같다.
| 부피(정사각형 한 변) | 걸치는 셀(기댓값) | 경계를 걸칠 확률 | 후보 공간 ÷ 부피 면적 |
|---|---|---|---|
| 50 m | 1.09 | 8.7 % | 552.7배 |
| 200 m | 1.39 | 32.4 % | 43.9배 |
| 1 km | 3.57 | 98.8 % | 4.5배 |
| 5 km | 29.6 | 100 % | 1.50배 |
| 20 km | 352.3 | 100 % | 1.12배 |
반지름 3 km 원은 기대 34.0개 셀을, 반지름 18 km 원은 868.5개 셀을 걸친다. 면적만으로 센 셀 수(803.5개)보다 8.1 % 많다. 의미는 두 가지이다. 첫째 소형 기체의 짧은 운용은 DSS 조회에서 과도하게 넓게 읽힌다. 한 변 200 m 부피가 조회하는 공간은 부피의 약 44배이므로, 도시 밀집 지역에서는 실제로 교차하지 않는 이웃 운용 의도의 세부를 많이 읽게 된다. 둘째 큰 운용은 수백 개의 셀을 걸친다. 한 변 20 km의 고정익 운용은 기대 352개 셀을 조회하고 구독한다. 이 값은 셀을 정사각형으로 근사하고 부피의 위치가 격자와 무관하다고 가정한 것이며, 실제 셀의 면적은 0.76~1.59 km²로 위치마다 다르다.
9.14.4.3 풀과 생존성
한 DSS 지역(region)은 동기화된 하나 이상의 DSS 인스턴스이고, 지역에는 하나의 DAR이 있으며 InterUSS 구현은 이를 지역당 하나의 분산 데이터베이스(CockroachDB 또는 Yugabyte) 클러스터로 구현한다. 지역은 보통 항공 관할(대개 국경)과 일치하고 운영 풀 하나와 파트너 시험용 풀 하나가 있을 것으로 예상된다. 여러 조직이 인스턴스를 하나씩 운영하는 것이 기대 구성이며 성능상 권장 최대는 인스턴스 7개이다. 문서의 생존성 표는 조직 3곳이 각각 노드 2개를 가진 구성(복제 3)에서 한 조직의 전체 정지는 견디지만, 서로 다른 두 조직에서 노드가 동시에 정지하면 일부 범위를 잃을 수 있고 두 조직이 전체 정지하면 범위 손실이 확정된다고 정리한다.
단순한 모형으로 이 이득을 계산한다. 조직 3곳이 각각 독립적으로 확률 $a$로 가동하고 한 범위의 복제본이 조직마다 하나씩 있어 과반이 가동할 때 서비스한다고 가정하면 가용도는 $3a^{2}-2a^{3}$이다.
| 조직 1곳의 가용도 | 3곳 과반 가용도 | 연간 정지(단독) | 연간 정지(3곳) |
|---|---|---|---|
| 90 % | 97.2000 % | 876.0 h | 245.3 h |
| 99 % | 99.9702 % | 87.6 h | 2.61 h |
| 99.9 % | 99.9997 % | 8.8 h | 0.026 h |
복제 수와 조직 수를 같게 늘린다고 가정하면 99 % 조직 5곳은 99.999015 %(연 5.2분), 7곳은 99.999966 %(연 0.18분)이다. 이 모형은 조직의 고장이 독립이라고 가정한다. 같은 클라우드·같은 데이터베이스 소프트웨어·같은 인증서 체계를 공유하면 이 가정이 성립하지 않고, 문서의 표 자체가 유지보수 때 범위를 잃는 조합을 보여 준다. 숫자는 구조의 이득을 보이는 설명용이며 실제 가용도 예측이 아니다.
9.14.4.4 워크스루 — InterUSS 크기 산정의 재현
InterUSS의 크기 산정 문서(미국 규모의 수요 가정)를 입력 그대로 다시 계산했다.
| 항목 | 문서의 값 | 이 책의 재계산 |
|---|---|---|
| 초당 비행 | 약 18.6 | 18.61 |
| 비행당 질의 시간 | 0.54 s + 0.96 s = 1.5 s | 0.54 + 0.96 = 1.50 s |
| 공칭 병렬도 | 28 | 27.9 |
| 첨두 병렬도(비 3.5) | 98 | 97.7 |
| 필요 vCPU(연산 4개당 1) | 25 | 24.4 → 25 |
| 인스턴스당 vCPU(3개 중 1개 정지 허용) | 13 | 12.2 → 13 |
| 5일 치 저장 | 약 83 GB(기록 "100k") | 100 kB 가정 시 804 GB, 10 kB 가정 시 80.4 GB |
저장 공간만 맞지 않는다. 문서의 기록 크기 "100k"가 100 kB이면 8.04백만 비행에서 804 GB가 되고, 문서의 83 GB와 약 10배 차이가 난다. 10 kB로 보면 80.4 GB로 문서 값에 가깝다. 원인(표기 단위·일수·기록 크기)은 확인하지 못했다 (확인 필요). 이 표는 프로젝트의 산정 가정이며 실측이 아니다.
9.14.5 EU U-space의 정보 교환
9.14.5.1 공통 정보 서비스(CIS)
규정 2021/664 제5조(1)은 회원국이 U-space 공역마다 공통 정보 서비스의 일부로 다음 자료를 제공하게 한다. (a) U-space 공역의 수평·수직 한계, (b) 제3조(4)의 요구, (c) 인증된 U-space 서비스 제공자 목록(식별·연락처, 제공 서비스, 인증 한계), (d) 인접 U-space 공역, (e) U-space 공역에 관련된 UAS 지오존, (f) 정적·동적 공역 제한. 제5조(2)는 ATS 운영 자료와 동적 공역 재구성 자료를 포함시키고, 제5조(5)는 접근을 차별 없이 같은 품질·지연·보호 수준으로 제공하게 한다. 회원국은 단일 CIS 제공자를 독점으로 지정할 수 있고, 지정하면 그 제공자는 인증을 받아야 한다(제5조(6)·(7)).
AMC·GM은 구조를 두 가지로 설명한다. CIS의 정보는 회원국(공역 설계·제한), ATS 제공자(유인 교통 정보·동적 재구성), USSP(서비스 약관) 세 곳에서 나오고(GM1 제5조), 단일 CIS 제공자가 있으면 중앙형이고 없으면 각 제공자가 USSP에 직접 주는 분산형이다. 단일 CIS 제공자는 비행 허가 같은 운용상의 역할을 맡지 않는다(GM3 제5조).
9.14.5.2 AMC·GM이 지목하는 규격과 수치
| 대상 | AMC·GM | 지목한 규격 또는 수치 |
|---|---|---|
| 공역 정보의 형식 | AMC1 제5조(1) | ED-269 8장과 부록 2, 2020년 6월판 |
| 파일 형식 | GM1 제5조(1)(b) | ED-269가 정의한 JSON(RFC 7159) |
| 제한 정보의 적시성 | AMC1 제5조(1)(f) | 정적 제한 30초, 동적 제한 5초, 시간의 99 % 이상 |
| 교통 정보의 지연 | AMC1 제5조(2) | U-space 위험 평가가 정한 지연 미만, 99 % 이상 |
| CIS 저하의 통지 | GM1 제5조(7) | 30초 이내를 권고 |
| USSP 간 교환의 인터페이스 | AMC6 제7조(5) | SWIM TI Yellow Profile 1.1판(2020-07-05) 부속서 A, SWIM Service Description 2.0판(2022-03-15) |
| 정보 모델의 서술 | GM4 제7조(5) | UML 등 기술 중립 서술, 인코딩은 JSON 또는 ASTERIX 예시, 공통 개방 프로토콜(TCP 예시) |
| 비행 허가의 충돌 해결 | GM1 제10조(6) | ASTM F3548-21을 따를 수 있다 |
| 활성화 확인의 지연 | GM3 제10조(5) | 'without unjustified delay'의 해석으로, F3548-21이 활성화 확인을 95 %의 시간에 5초 이내로 요구한다고 EASA가 서술 |
| 네트워크 식별 인터페이스 | AMC4 제8조(1) | ASTM F3411-22A 부속서 4 |
| 높이 | AMC1·GM1 제8조(2)(c) | 시스템 간 교환은 WGS 84 타원체고, 해발 변환은 EGM2008 또는 최소 EGM96 |
세 가지를 읽어 둔다. 첫째 F3548은 "따를 수 있다"로만 지목되어 EU 규정에서 필수가 아니다. 규정이 필수로 요구하는 것은 "공통의 안전하고 상호운용 가능한 개방 통신 프로토콜"(제7조(5)(b), 부속서 II)이며 어느 규격인지는 AMC가 정한다. 둘째 수치(30초·5초·99 %)는 규정 본문이 아니라 AMC에 있고, 규정 본문 부속서 III은 표제에 지연을 포함하지만 본문 A·B 항목에는 수치 지연이 없다. 셋째 높이는 시스템 사이에서 타원체고로 교환하라고 권고한다. 기압 센서와 QNH로 계산한 해발과 GNSS로 계산한 해발은 비교할 수 없다는 이유이다.
9.14.5.3 비행 허가의 상태 이름
| 출처 | 상태 이름 |
|---|---|
| EASA AMC1·GM1 제10조(6) | Accepted · Activated · Withdrawn · Ended |
| ASTM 공개 OpenAPI | Accepted · Activated · Nonconforming · Contingent (삭제로 종료) |
앞 둘은 이름이 같고 뒤의 둘은 다르다. EU의 Withdrawn은 충돌·동적 제한·유인기 비상 같은 이유로 허가를 거두는 것이고(제10조(10)·AMC), 공개 OpenAPI에는 이에 해당하는 상태가 없고 Nonconforming·Contingent는 EU 목록에 없다. 이름의 차이가 의미의 차이인지는 표준 본문이 필요하다 (확인 필요). 구현자는 두 체계 사이의 사상표를 별도로 정의해야 한다.
9.14.5.4 부속서의 요구와 운용 의도의 페이로드
부속서 II는 공통 정보를 개방·안전·확장 가능·지속 가능한 기술로 온라인 제공하고 차별 없이 접근시키며 USSP와 ATS 제공자는 공통의 안전하고 상호운용 가능한 개방 통신 프로토콜을 사용하라고 한다. 부속서 III은 자료 품질(품질 유지, 변조 없음의 검증·확인 기법, 메타데이터 보존, 전송의 인증, 오류 보고·측정·시정) 5개 항목과 보호(보안 정책·암호화, 프로토콜 보호, 위험·취약점 식별, 보안 표준 준수, 내부자 위험 정책, 위협 탐지 강화) 6개 항목을 둔다. 표현은 8.11~8.13의 수준보다 높은 추상이고 암호 알고리즘이나 키 관리의 요구는 없다.
부속서 IV의 비행 허가 요청은 10개 항목(항공기 일련번호, 운용 방식, 비행 종류, 운용 범주와 등급, 4D 궤적, 식별 기술, 연결 방법, 체공 시간, C2 링크 상실 때의 비상 절차, 등록 번호)이다. 공개 OpenAPI의 USS 간 페이로드는 부피 목록과 우선순위·상태이며 이 목록의 대부분을 포함하지 않는다. 운용자와 USSP 사이의 요청 인터페이스는 이 파일의 범위가 아니다.
9.14.6 지오존 데이터 — ED-269에서 ED-318로
9.14.6.1 공개 OpenAPI에 옮겨진 ED-269 데이터 모델
공개 OpenAPI의 GeoZone 스키마(파일 주석이 "ED-269 compliant GeoZone representation"이라 적는다)는 속성 14개 가운데 5개가 필수이다. 필수는 식별자, 국가, 유형, 제한, 구역 당국이다. 운용 제약의 세부(ConstraintDetails)에 선택적으로 geozone을 포함할 수 있어, F3548의 제약 개체가 ED-269 지오존을 실어 나른다.
| 속성 | 의미 | 제약 |
|---|---|---|
identifier·country | 구역의 식별자·권한을 가진 국가 | 식별자 최대 7자, 국가는 ISO 3166-1 알파3. 합쳐 10자는 ARINC 424·AIXM의 공역 지정자 길이에 맞춘 것 |
restriction | 금지·허가 필요·조건부·제한 없음 | 값 목록이 이 파일에서는 CodeZoneType에 섞여 있다 |
restriction_conditions | 조건부 구역의 조건식 | 최대 10,000자. 항공기가 해석하는 코드 |
reason | 설정 이유(최대 9개) | AIR_TRAFFIC·SENSITIVE·PRIVACY·POPULATION·NATURE·NOISE·FOREIGN_TERRITORY·EMERGENCY·OTHER |
zone_authority | 허가·통지·정보를 담당하는 당국(1개 이상) | 사이트·전자우편·전화 중 하나 이상, 사전 통지 시간 interval_before(ISO 8601) |
message | 원격 조종사에게 보일 문구 | 최대 200자 |
region | 국가 안의 지역 | 0~65,535(16비트) |
조건식 언어. 조건부 구역은 "비행이 허용(또는 금지)된다, 만약 (특성1)=(값1) 그리고 …"의 형태의 식을 기계가 해석하도록 둔다. 특성(CHARTYPE)과 값(CHARVAL)의 목록은 국가가 정하고 공개 문서로 정의해야 한다. 예는 운용자 유형·운용 종류·승객 탑승 여부·사진 촬영 여부·소음 등급이다. 항공기에 정의되지 않은 특성이 식에 있으면 자동 지오펜싱은 조종사에게 알리거나 구역을 금지로 취급해야 한다(should)고 한다. 모르는 값을 안전한 쪽으로 처리하는 이 규칙은 2.6의 지오펜싱 설계와 직접 이어진다.
9.14.6.2 ED-318로의 이전
EUROCAE의 안내문에 따르면 ED-318(지오 구역과 U-space 자료 제공·교환 기술 규격, WG-105)은 ED-269의 8장(데이터 모델)과 9장(지오펜싱 정보 서비스 인터페이스)과 부록 2를 대체한다. 이유는 EU 규정이 지오존의 단일 디지털 형식을 요구하고 EASA의 AMC가 ED-269 8장을 지목했는데, 그 모델이 동적 공역 재구성 같은 지오펜싱 밖의 대상을 포괄하도록 발전해야 했기 때문이다. 발표 자료가 설명한 새 구조는 일반·자료 범위·자료 요구(자료 사슬과 품질)·개념 데이터 모델·정보 서비스를 통한 교환·부속 자료(논리 일관성 검사, 제한 조건, 서비스 예)이다(2023년 기준 계획이며 최종 구성은 확인하지 못했다 (확인 필요)). 정보 서비스는 두 기능, 곧 구역 정보의 동기 조회와 갱신의 비동기 배포를 가지며 비기능 요구로 무결성 보존·정보의 진본성(OAuth 2 방식 또는 동등)·감사 추적·피드백을 둔다. 제한 조건은 수치 제한(예: 최대 소음), 문자 제한(예: 기체 등급), 단순 제한(값 없이 존재만으로 요구, 예: 촬영 금지) 세 유형이다.
인용 판의 문제. 이 이전은 인용의 시간차를 보여 준다. EASA AMC는 ED-269 8장과 부록 2의 "2020년 6월판"을 지목하고(편집본 2024년 5월), EUROCAE의 ED-269 Change 1 안내문(2025년 1월)은 ED-269가 2020년 5월에 발행되었다고 적고, 8장·9장·부록 2를 삭제했다고 설명한다. ED-318의 발행월은 EUROCAE의 두 안내문에서 2024년 1월과 2월로 다르다. 곧 AMC가 지목한 장은 현행 ED-269의 개정판에서 없어졌고, 후속은 AMC가 인용하지 않는 ED-318이다. EASA가 AMC를 이후에 개정했는지는 확인하지 못했다 (확인 필요). 이 사례는 9.1.3·9.1.7의 "인용 판을 확인하라"는 규칙의 실제 사례이다. 접근성도 같다. ED-318은 유료이며 EUROCAE 안내문에는 비회원 125유로, ED-269 Change 1은 100유로로 표시된다(안내문 기준, 변동 가능).
9.14.6.3 스위스 국가 프로필이 보여 주는 변화
스위스 BAZL의 지오존 모델은 1.0판(2022-04-12, ED-269 기반), 2.0판(2025-03-19, ED-318 기반), 2026-06-29의 개정판으로 이어지며, 국가 프로필이므로 일부 요소를 생략한다(부록 7.5, 이 책은 읽지 못했다). 이 문서와 앞 절의 공개 OpenAPI를 나란히 두면 판 사이에서 바뀐 것이 보인다. 차이를 ED-318 자체의 것으로 단정할 수 없고 국가 프로필의 선택이 섞여 있다 (확인 필요).
| 항목 | ED-269 계열(공개 OpenAPI) | 스위스 프로필(ED-318 기반) |
|---|---|---|
| 유형 필드 | type(COMMON·CUSTOMIZED)과 restriction | type(USPACE·PROHIBITED·REQ_AUTHORIZATION·CONDITIONAL·NO_RESTRICTION)과 variant(COMMON) |
| 허가 필요 값의 철자 | REQ_AUTHORISATION | REQ_AUTHORIZATION |
| 이유 코드 | 9개(FOREIGN_TERRITORY·OTHER 포함) | 8개(DAR 추가, FOREIGN_TERRITORY·OTHER 없음) |
| 기하 | 규격 고유의 JSON 구조 | GeoJSON(RFC 7946)과 LayeredGeoJSON 확장, 원은 점과 반지름의 확장 |
| 고도 | 값·기준·단위 객체 | upper·lower와 기준·단위(미터만) |
철자 하나(S와 Z)와 필드 이름의 이동은 JSON 키 이름이 맞지 않으면 파서가 조용히 값을 놓치므로 적합성 시험이 필요한 이유이다(9.23). 스위스 모델은 내부 좌표를 국가 좌표계(EPSG:2056)로 두고 공개할 때 WGS 84와 GeoJSON으로 변환한다. 지오존의 국가 프로필이 나라마다 다르면 EU 단일 형식의 목표가 약해진다.
9.14.7 항공 정보 계열 — AIXM·FIXM·SWIM
9.14.7.1 AIXM
AIXM(항공 정보 교환 모델)은 항공 정보 업무(AIS)의 자료를 디지털로 제공하기 위한 모델이며 EUROCONTROL과 FAA가 공동으로 사이트를 관리한다. 범위에는 비행장·공역 구조·조직·지점·절차·경로·비행 제한이 있다. 판은 4.5(2005), 5.0(2008), 5.1(2010), 5.1.1(2016), 5.2(2025년 1월)이며, 5.0부터 UML 모델·GML 호환 XML 스키마·시간 개념을 구성 요소로 하고 시간 개념이 정적 자료와 동적 자료(디지털 NOTAM)를 함께 부호화하게 한다. 사이트에 따르면 AIP·장애물·공항 지도 자료와 디지털 NOTAM의 현행 부호화 규격은 5.1.1에 기반하고, 5.2는 계기 비행 절차 자료 개발에 사용되며 다음 정기 판(5.3)은 2030년 이전에는 나오지 않는다. 디지털 NOTAM의 동기로 사이트는 국제 NOTAM이 10년에 세 배로 늘어 연 100만 건에 가깝다고 적는다 (공개 주장치, 쪽의 작성 시점 미확인).
표본 공역 피처. Donlon_2025 표본 파일은 공역 피처 57개와 부피 70개를 가진다(피처당 1.23개 부피). 한 피처는 타임슬라이스(해석 BASELINE, 순번, 정정 번호, 유효 기간)를 갖고, 지오메트리는 부피별로 상한·하한과 그 기준(SFC·MSL 등)과 수평 투영(GML)을 가지며, 활성화 정보는 반복 시간표(시작·종료 일자, 요일, 시각, 일광절약 보정 여부)를 가진다. 이 구조는 9.14.8의 변환 계산에 사용한다.
9.14.7.2 FIXM
FIXM(비행 정보 교환 모델)은 비행과 흐름 정보를 전 지구적으로 표준화한 교환 모델이며 ICAO의 FF-ICE 개념과 GADSS/LADR의 비행 자료 교환을 위해 개발된다. Core 4.3.0은 2023-02-03에 배포되었고 FF-ICE 메시지 1.1.0(보정판 2024-04-30)과 미국 확장 4.4.0(2025-09-02)이 있다. Primer는 FIXM을 ICAO SWIM 개념(Doc 10039)의 정보 교환 모델 층에 속한다고 설명하며 AIXM·WXXM과 같은 계열이라 한다. 이 책이 센 Core 4.3.0 스키마는 XSD 26개, complexType 180, simpleType 122, 요소 선언 395이다(정규식 계수). Core의 GUFI(전 지구 고유 비행 식별자)는 UUID에 생성 시각·이름 공간 영역·이름 공간 식별자를 붙인 불변 식별자이다. Primer의 범위 문장에는 UAS의 운용 의도 교환이 없고, F3548의 공개 OpenAPI는 단위와 고도 기준을 FIXM·AIXM과 맞추었다고만 적는다.
9.14.7.3 SWIM과 TI Yellow Profile
SWIM(전 체계 정보 관리)에서 정보 교환 모델(AIXM·FIXM·WXXM) 아래의 기술 기반을 EUROCONTROL이 명세한 것이 SWIM TI Yellow Profile(EUROCONTROL-SPEC-170)이다. 1.1판(2020-07-05)은 서비스 인터페이스 바인딩 10개(WS Light, WS SOAP과 보안 3종, WS-N SOAP과 보안 3종, AMQP 메시징)와 네트워크 바인딩 4개(IPv4·IPv6 각각의 일반·보안 유니캐스트)를 정의하고, 적합하려면 서비스 바인딩 하나와 네트워크 바인딩 하나 이상을 구현해야 한다. 요구마다 식별자, 이행 수준(M=shall, R=should, O=may), 검증 방법(문서 검사·구성 검사·시연·시험·분석)이 있다.
| 항목 | 1.1판(2020-07-05) | 2.0판(2025-07-14) |
|---|---|---|
| 본문의 요구 식별자 수 | 104 | 107 |
| 인프라 능력 적합 목록(부속서 A.2) 행 수 | 57 | 31 |
| 필수(M)·권고(R)·선택(O) | 17·3·37 | 14·5·12 |
| TLS 요구(SWIM-TIYP-0008) | TLS 1.2(RFC 5246) | TLS 1.3(RFC 8446), TLS 1.2는 폐기 예정 |
| WS-N 바인딩 | 있음(4종) | 폐기 예정 표시 |
| 메시지 보안이 있는 AMQP | 없음 | 추가 |
AMQP 바인딩은 AMQP 1.0(ISO/IEC 19464:2014)과 TLS 위의 전송(amqps)을 필수로 한다. 1.1판의 목록에서 암호 키 수명 주기 관리·보안 패치·취약점 평가는 권고 이하(R·R·O)이고 감사 항목 대부분이 선택이다. 인프라 능력 57개 가운데 40개(권고 3과 선택 37)가 필수가 아니다. 2.0판은 보안 관련 사건의 감사를 필수로 올렸고(SWIM-TIYP-0114), 보안 패치·취약점 평가·서비스 거부 방어를 권고로 두었으며, 키 수명 주기 관리(SWIM-TIYP-0071)는 삭제로 기록한다. 곧 AMC가 지목한 1.1판에 적합하더라도 키 관리·패치·감사 같은 보안 능력은 권고·선택 수준이며 8.11~8.13의 요구와 같지 않다.
9.14.8 워크스루 — 표현 변환의 비용
AIXM 표본의 민간 통제 구역(CTR) 하나를 UTM·지오존 쪽 형식으로 옮기며 비용을 센다. 표본은 가상 국가 Donlon의 'AKVIN CTR'이다(중심 52.60166667 N, −32.92 E, 반지름 18 km, 수직 0~3,000 ft MSL, 등급 D, 매일 07:00~18:00 UTC에 활성이며 일광절약 보정이 있고 주석에 "(0600-1700)"이 함께 적혀 있다). 파일에서 이 피처는 10,613바이트(공백을 정리하면 7,287바이트)이다. 이 변환의 사상은 이 책의 예이며 규범적인 대응표가 아니다.
① 기하. AIXM의 중심점과 반지름의 원은 ASTM의 Volume3D의 원으로 그대로 옮겨진다(반지름 18,000 m). 호나 다각형이 필요한 형식(GeoJSON 기반의 지오존, 호를 가진 AIXM 구역)에서는 다각형으로 근사한다. 내접 다각형의 현이 원에서 벗어나는 최대량(화살 높이) $s$ 이하로 하려면 꼭짓점 수가 다음과 같다.
$$N=\left\lceil \frac{\pi}{\arccos(1-s/R)} \right\rceil$$
| 허용 화살 높이 | 100 m | 50 m | 10 m | 5 m | 1 m |
|---|---|---|---|---|---|
| 꼭짓점 수(R=18 km) | 30 | 43 | 95 | 134 | 299 |
표본이 밝힌 수평 정확도 5.0 m를 허용치로 보면 134각형이다. 금지 구역의 근사는 원을 포함하는 외접 방향으로 해야 안전한 쪽으로 어긋나고, 이 경우 오차의 크기는 같은 차수이다. 크기는 ASTM Volume4D 하나가 원이면 376바이트, 134각형이면 5,239바이트, 300각형이면 11,359바이트이다.
② 높이. 3,000 ft는 914.4 m이며 기준이 MSL이다. ASTM은 WGS 84 타원체고만 허용하므로 타원체고는 $h=H+N$($N$은 지오이드고)이다. 지오이드고가 −40·0·+40·+60 m인 곳에서 상한은 각각 874.4·914.4·954.4·974.4 m이고 하한 0 ft는 −40~+60 m로 바뀐다(값은 가정). 변환에 사용하는 지오이드 모델이 EGM96인가 EGM2008인가에 따라 같은 지점의 $N$이 달라지며 그 차이의 크기는 이 장이 확인하지 못했다 (확인 필요). 지오이드와 타원체의 관계는 4.1.3.4, 높이 기준 전반은 2.8.3.2에 있다. EU는 이 변환을 AMC로 명시한다(9.14.5.2).
③ 시간. AIXM의 시간표는 "매일 07:00~18:00 UTC, 일광절약 보정"의 한 줄 규칙이다. ASTM은 구간마다 시작·종료를 명시하므로 규칙을 전개해야 한다. 일광절약 보정이 있어 지역 시각 규칙을 알아야 UTC 구간이 맞다. 전개한 개수와 크기는 다음과 같다.
| 전개 기간 | Volume4D 개수 | 크기(원 기준) | AIXM 피처 대비 |
|---|---|---|---|
| 1일 | 1 | 376 B | 0.05배 |
| 7일 | 7 | 2,632 B | 0.36배 |
| 30일 | 30 | 11,280 B | 1.55배 |
| 90일 | 90 | 33,840 B | 4.6배 |
| 365일 | 365 | 137,240 B | 18.8배 |
④ 속성. 통제 구역의 속성(등급 D, 활성 시간)을 지오존의 제한 유형과 이유에 사상하면 허가 필요(REQ_AUTHORISATION)와 항공 교통(AIR_TRAFFIC)이 자연스럽지만, 허가를 맡는 당국의 연락처·사전 통지 시간 같은 필수 속성은 AIXM 표본 피처에 없어 별도로 채워야 한다. 이상의 계산이 주는 결론은 교환 규격이 같아도 기하·높이 기준·시간 표현의 합의가 없으면 변환이 오차의 원천이 된다는 것이다.
9.14.9 워크스루 — 지연과 가용성의 합성
① 종단 요구를 단계로 나누기. AMC는 동적 제한을 시간의 99 % 이상에서 5초 안에 제공하라고 한다. 당국·ATS 제공자 → CIS → USSP → 운용자의 표시 단말처럼 $k$개의 독립 단계가 직렬일 때, 종단에서 확률 $p$로 기한을 충족하려면 각 단계가 합집합 한계로 $1-(1-p)/k$ 이상이어야 한다.
| 종단 요구 | k=2 | k=3 | k=4 | k=6 |
|---|---|---|---|---|
| 95 % | 97.5 % | 98.33 % | 98.75 % | 99.17 % |
| 99 % | 99.5 % | 99.67 % | 99.75 % | 99.83 % |
종단 99 %를 4단계로 만족시키려면 각 단계가 99.75 % 이상이어야 한다. 단계별 기한을 따로 나누는 방식(지연 버짓)과 달리 확률 요구를 나누면 단계 수가 늘수록 각 단계의 요구가 엄격해진다. 한계는 보수적이며 단계가 독립이 아니면 달라진다.
② 가용도. 시간의 99 %는 연 87.6시간, 99.9 %는 8.76시간, 99.99 %는 0.88시간의 정지를 허용한다. 위 9.14.4.3의 풀 모형이 보인 대로 조직 3곳이 독립적으로 99 %이면 풀은 99.9702 %, 곧 연 2.6시간이다.
③ 키 충돌. 읽은 뒤 갱신까지의 시간 $\tau$ 동안 같은 셀에서 다른 갱신이 평균 $\lambda$로 도착한다면 키가 낡을 확률은 $1-e^{-\lambda\tau}$이고, 충돌 때 처음부터 다시 하는 재시도의 기대 시도 횟수는 $e^{\lambda\tau}$이다(포아송 도착·독립 재시도 가정).
| 도착률 | 읽기~갱신 | 키가 낡을 확률 | 성공까지 평균 시도 |
|---|---|---|---|
| 0.05 /s | 2 s | 9.5 % | 1.11 |
| 0.5 /s | 2 s | 63.2 % | 2.72 |
| 0.5 /s | 5 s | 91.8 % | 12.2 |
| 1.0 /s | 5 s | 99.3 % | 148 |
혼잡한 셀에서 읽기와 갱신 사이의 시간이 길면 재시도가 폭증한다. 구현은 읽기에서 갱신까지의 시간을 줄이는 것(계획 계산을 미리 하고 갱신 직전에 세부를 다시 읽는 순서)과 요청 제한(공개 OpenAPI는 429를 정의한다)에 대한 지수 후퇴를 함께 설계해야 한다. 실제 도착률은 이 장이 확인하지 못했다 (확인 필요).
9.14.10 판의 수명 — 이 장이 읽은 문서
9.1.7의 방법으로 이 장에서 판의 날짜를 확인한 문서의 간격이다(월까지만 알면 1일로 둔 값, ±1개월).
| 문서 | 간격 |
|---|---|
| SWIM TI Yellow Profile 1.0 → 1.1 | 2.6년 |
| SWIM TI Yellow Profile 1.1 → 2.0 | 5.0년 |
| ED-269(2020.5) → ED-318(2024.1) | 3.7년 |
| 스위스 지오존 모델 1.0(ED-269) → 2.0(ED-318) | 2.9년 |
| ED-318(2024.1) → 스위스 2.0 채택 | 1.2년 |
| AIXM 5.1.1(2016) → 5.2(2025.1) | 9.0년 |
| FAA UTM 운용 개념 1.0 → 2.0 | 1.8년 |
규정의 AMC는 한 시점의 판을 인용한다. 이 장의 AMC는 SWIM Yellow Profile 1.1판을 인용하나 2.0판이 2025년에 나왔고 TLS 요구가 바뀌었으며, ED-269의 해당 장은 삭제되었다. 규정이 인용한 판과 현행 판이 다를 때 어느 쪽에 적합해야 하는가는 당국과의 합의 사항이다(9.1.3). EASA 편집본이 이후에 갱신되었는지는 확인하지 못했다 (확인 필요).
9.14.11 설계 트레이드오프 — 정보 교환의 구조를 어떻게 택할 것인가
방식을 셋으로 펼친다.
① 연합형: DSS 풀과 USS 직접 교환(F3548 형). 조직마다 DSS 인스턴스를 하나씩 운영하고 운용 의도는 USS 사이에서 직접 교환한다. 장점은 단일 고장점과 단일 소유자가 없고, 경쟁하는 조직이 세부를 서로에게만 공개하며, 변경 속도가 높은 정보에 적합하다는 점이다. 단점은 풀 구성·인증서·운영 합의 비용, 셀 단위 과대 조회(9.14.4.2), 관리 USS만 삭제할 수 있고 Down인 USS는 삭제도 못 하므로 정지한 USS의 운용 의도가 공역을 계속 차지하는 구조적 문제이다(EASA GM1 제10조(6)(b)가 정지한 USSP의 승인된 비행 위에 계획하도록 하는 약정을 허용하는 것이 한 가지 대응이다). 규제 정합성은 규정이 이를 "따를 수 있다"로만 지목해 입증 방법으로 합의가 필요하다.
② 중앙형: 단일 CIS와 당국 주도 서비스. 회원국이 단일 CIS 제공자를 지정하고 USSP는 그 서비스를 소비한다. 장점은 단일 진실 원천, 인증과 감사의 단순함, 정적·동적 제한의 일관성이다. 단점은 단일 고장점(CIS 저하를 30초 안에 알리라는 권고가 이 위험을 반영한다), 운영자의 독점 위험, 변경 속도가 높은 운용 의도에는 병목이 될 가능성이다. 규정이 허용하는 구조이다.
③ SWIM·AIXM·FIXM 접합: ATM 계열의 서비스 지향. USSP와 ATS 제공자 사이의 교환을 SWIM의 서비스 기술과 기술 기반(AMQP 1.0·TLS)과 항공 정보 모델로 구성한다. 장점은 유인 교통 관리의 기존 자산·보증 방식과의 연속성이다. 단점은 모델의 크기와 복잡도(9.14.8의 크기 비교)와 SWIM 적합 비용, 무인기 운용 의도가 FIXM Core의 범위 밖이라는 점이다. EU는 USSP 간 교환의 기술 기반에 이를 지목한다(AMC6).
| 방식 | 장점 | 단점 | 누구에게 맞는가 |
|---|---|---|---|
| ① 연합형 | 중앙 소유자 없음·변경에 강건 | 풀 운영·과대 조회 | 다수의 경쟁 USS가 있는 대도시·국가 |
| ② 중앙형 | 단일 원천·감사 단순 | 단일 고장점·병목 | USS가 적거나 국가가 서비스를 직접 제공할 때 |
| ③ SWIM 접합 | ATM 자산과의 연속성 | 모델 크기·적합 비용 | ATS 제공자와의 정보 교환이 핵심인 접점 |
견해: 하나만 택하지 않고 정보의 변화 속도와 소유자에 따라 나누는 것이 근거가 가장 강하다. 정적·준정적 제한(지오존·제한 공역)은 당국이 소유하고 변화가 느리므로 ② 중앙형의 단일 원천이 맞고, 운용 의도는 경쟁 조직이 소유하고 변화가 빠르므로 ①이 맞으며, ATS 제공자와의 접점만 ③을 사용한다. 근거는 세 가지이다. 첫째 EU의 AMC가 CIS를 중앙형과 분산형 모두 허용하고 운용 의도 충돌 해결에는 F3548을 따를 수 있다고 하고 USSP 간 교환에 SWIM을 지목해 이미 이 분업을 전제한다. 둘째 9.14.4.3의 풀 모형이 보이듯 독립 소유자 3곳의 연합은 단독 운영보다 정지 시간을 크게 줄인다(독립 가정 아래). 셋째 9.14.9의 계산이 보이듯 종단 지연 요구는 단계 수가 늘수록 엄격해지므로 정보를 소유자별로 나눠 경로를 짧게 하는 것이 유리하다. 반대 견해로는 USS가 소수인 시장에서는 연합형의 풀 운영 비용이 이득을 넘으므로 ②로 단순하게 시작하라는 주장이 있고, 이 경우 변경 속도가 높은 운용 의도가 병목이 되는지를 시험으로 확인해야 한다.
9.14.12 세 축 비교
| 항목 | 군용 드론 | 민간 UAS | AAM(eVTOL) |
|---|---|---|---|
| 정보 교환의 주체 | 이 장의 범위 밖(제10~12부) | USSP·운용자·당국·ATS 제공자 | 위와 함께 비행장·버티포트 운영자, 유인 ATM과의 접점 |
| 공역·지오존 정보 | 별도 | 지오존(ED-269·ED-318)·UVR·CIS | 유인 공역과의 분리와 동적 공역 재구성(제4조, 원문 확인) |
| 운용 의도의 교환 | 별도 | F3548 계열의 USS 간 조율 | 같은 구조가 확장될지는 이 장에서 확인하지 못함 (확인 필요) |
| 핵심 규격의 접근성 | 별도 | 공개 OpenAPI·프로젝트 문서가 있으나 표준 본문은 유료 | ATM 계열(AIXM·FIXM·SWIM)은 공개 문서가 많고 EUROCAE·ASTM 본문은 유료 |
| 보증 수준 | 별도 | 비감항 지상 서비스. 자료 품질·보호 요구는 규정 부속서 III 수준 | 안전에 중대한 비행 서비스에 의존하는지는 이 장에서 확인하지 못함(8.12) (확인 필요) |
9.14.13 관련 규격·프로토콜
| 문서 | 발행 | 무엇을 정하나 | 상세 장 |
|---|---|---|---|
| ASTM F3548-21 | ASTM | USS 간 상호운용(전략 조정·제약·적합성 감시) — 본문 미열람(유료) | 이 장, 14.22 |
utm.yaml(ASTM UTM Protocol) | ASTM UTM 저장소 | DSS·USS 간 API 25개, GeoZone 스키마 — 원문 확인 | 이 장 |
| ASTM F3411-22A | ASTM | Remote ID와 ISA — AMC 인용 범위만 | 9.12 |
| InterUSS DSS 문서 | InterUSS(Linux Foundation) | DSS 구현·S2 13단계·풀·크기 산정 — 프로젝트 문서, 원문 확인 | 이 장 |
| 규정 (EU) 2021/664와 AMC·GM(ED Decision 2022/022/R) | EU·EASA | U-space, CIS, 비행 허가, 부속서 II~IV — EASA 편집본 원문 확인 | 17.12 |
| EUROCAE ED-269(2020) | EUROCAE | 지오펜싱 MOPS와 지오존 데이터 모델 — 본문 미열람, 구조는 공개 OpenAPI·발표 자료로 확인 | 2.6 |
| EUROCAE ED-318(2024) | EUROCAE | 지오 구역·U-space 자료 제공·교환 기술 규격 — 본문 미열람(유료) | 이 장 |
| EUROCONTROL-SPEC-170 SWIM TI Yellow Profile 1.1·2.0 | EUROCONTROL | SWIM 기술 기반의 바인딩·보안·모니터링 — 원문 확인 | 이 장 |
| EUROCONTROL SWIM Service Description 2.0(2022-03-15) | EUROCONTROL | 서비스 기술서 — 미열람 | 이 장 |
| AIXM 5.1.1·5.2 | EUROCONTROL·FAA | 항공 정보 교환 모델 — 사이트·표본 확인, UML 미열람 | 이 장 |
| FIXM Core 4.3.0 | FIXM CCB | 비행·흐름 정보 교환 모델 — Primer·XSD 원문 확인 | 이 장 |
| ICAO Doc 10039·9965 | ICAO | SWIM 개념·FF-ICE — FIXM Primer 인용 범위만 | 이 장 |
| FAA UTM 운용 개념 2.0 | FAA | USS 네트워크·SDSP·FIMS·UVR — 원문 확인 | 14.22, 17.6 |
| BAZL 지오존 데이터 모델 2.0 | 스위스 BAZL | ED-318 기반 국가 프로필 — 원문 확인 | 이 장 |
전체 지도는 A.6에 있다.
9.14.14 관련 규제·인증 요구와의 연결
- UTM 개념과 아키텍처(14.22). 이 장의 USS·DSS·운용 의도는 14.22의 개념을 규격 쪽에서 본 것이다.
- U-space와 한국의 실증(14.23), EU 규정(17.12), 새 비행 규칙(17.13). 이 장의 CIS·AMC 표가 규정의 조문별 해설의 입력이다.
- 항공정보·지오존·기상 서비스(14.21). 공역 정보의 제공 서비스는 그 장이 다룬다.
- FAA의 BVLOS·UTM·배송 운항(17.6), 비행 승인(18.6). 운용 의도와 승인의 접점.
- UTM 보안(8.12)과 보안 프로토콜(9.19). 토큰 기반 접근 통제의 한계와 키 관리.
- 지오펜싱(2.6), 경로 계획(7.2), 군집(7.9). 지오존 자료를 읽어 들이는 쪽과 운용 의도를 만드는 쪽.
- 감시·식별(2.13·9.12). 네트워크 식별과 위치 정확도 열거값.
- 규격의 세계(9.1)와 규격 읽기(9.23). 판 관리와 적합성 시험.
- 한국 표준(9.22). 국내 표준과 이 장의 국제 규격의 대응.
9.14.15 함정과 한계
| 오해 | 실제 | 더 볼 곳 |
|---|---|---|
| DSS가 충돌을 판정한다 | DSS는 셀 단위 후보만 돌려주고 정확한 판정은 USS가 세부를 읽어 한다 | 9.14.4.1 |
| F3548은 EU에서 필수이다 | AMC·GM은 "따를 수 있다"로 지목한다. 필수는 공통의 안전한 개방 프로토콜이다 | 9.14.5.2 |
| 공개 YAML이 곧 표준이다 | 본문(전이 규칙·요구)은 유료 표준에 있고 YAML과의 일치는 확인하지 못했다 | 9.14.3 |
| 규정이 인용한 판이 현행이다 | ED-269의 인용 장은 삭제되고 SWIM Yellow Profile은 2.0판이 나왔다 | 9.14.10 |
| 토큰 인증이면 변조를 막는다 | 신원 확인은 하지만 메시지 서명·부인 방지는 이 파일에서 찾지 못했다 | 9.14.3.6 |
| 높이는 어느 기준이든 같다 | ASTM은 WGS 84 타원체고뿐이고 AIXM은 MSL·SFC가 있어 지오이드 모델이 필요하다 | 9.14.8 |
| 같은 이름의 상태는 같은 뜻이다 | EU의 Withdrawn은 공개 OpenAPI에 없고 Nonconforming은 EU 목록에 없다 | 9.14.5.3 |
| 지오존 형식은 하나다 | 철자(REQ_AUTHORISATION·REQ_AUTHORIZATION)와 필드가 판·국가마다 다르다 | 9.14.6.3 |
| SWIM 적합이면 안전하다 | 1.1판의 키 관리·패치는 권고, 감사는 대부분 선택이다 | 9.14.7.3 |
| 문서의 크기 산정은 믿어도 된다 | 저장 용량이 10배 어긋나 재계산이 필요했다 | 9.14.4.4 |
미해결 문제. F3548의 상태 전이 표와 각 서비스의 성능 요구(5초·95 %의 근거), ED-318의 최종 데이터 모델과 AMC의 개정 여부, EU 정본과 EASA 편집본의 대조, SWIM Service Description의 내용, 한국 드론교통관리의 기술 규격, 유인기·eVTOL의 비행 계획이 UTM 계열 교환과 만나는 구조는 이 장의 자료로 답할 수 없다 (확인 필요). 이 장의 수치는 대부분 프로젝트 문서의 가정과 이 책의 모형이며 실측이 아니다.
9.14.16 체크포인트·연구 질문
체크포인트:
- DSS가 운용 의도의 세부를 보관하지 않는 이유와 그 결과(진짜 교차 판정 불가)를 설명하라.
- OVN과 키가 중앙 잠금 없이 충돌을 막는 방식을 서술하고, 409의 응답이 포함하는 정보를 적어라.
- 한 변 200 m 정사각형 부피가 13단계 S2 셀을 걸치는 기대 수와 후보 공간의 배수를 구하라(
9.14-calc.py). - 종단 99 %를 직렬 4단계로 만족시키려면 각 단계의 요구는 얼마인가? 독립이 아니면 무엇이 달라지는가?
- AMC가 지목한 ED-269 8장은 현재 어떤 상태인가? 이 사례에서 "인용 판을 확인하라"는 규칙을 설명하라.
- AIXM 시간표를 ASTM 부피로 전개하면 30일에 몇 개가 되는가? 일광절약 보정이 왜 문제인가?
- 지오존 변환에서 높이 기준 때문에 생기는 오차를 지오이드고 $N$으로 표현하라.
- 정적 제한·운용 의도·ATS 접점의 세 정보에 각각 어떤 교환 방식을 사용하겠는가? 근거와 반대 견해를 적어라.
연구 질문(25.7에 모은다):
- 운용 의도 교환에서 USS 정지(Down)가 다른 USS의 계획을 막는 구조를 어떻게 완화하는가.
- 셀 단위 표현의 과대 조회를 줄이면서 정확한 부피를 비공개로 두는 방법은 무엇인가.
- 지오존의 국가 프로필 사이의 의미 차이를 자동으로 검증하는 적합성 시험을 어떻게 설계하는가.
- 유인기·eVTOL의 비행 정보(FIXM)와 UTM의 운용 의도를 한 교환으로 합칠 수 있는가.
1차 출처(이 장):
- ASTM UTM Protocol,
utm.yaml(github.com/astm-utm/Protocol) — 공개 OpenAPI, 마지막 갱신 2024-01-09. - InterUSS DSS 저장소 문서(
concepts.md,docs/background/*,pkg/geo/s2.go)와 S2 셀 통계표(s2geometry.io). - EASA, Easy Access Rules for U-space (2024년 5월판, 157쪽) — 규정 (EU) 2021/664와 AMC·GM(ED Decision 2022/022/R). 비공식 편집본.
- EUROCONTROL, Specification for SWIM Technical Infrastructure (TI) Yellow Profile, EUROCONTROL-SPEC-170, 1.1판(2020-07-05)과 2.0판(2025-07-14).
- FIXM Core v4.3.0 아카이브(Primer, 릴리스 노트, 스키마)와 AIXM 사이트의 판 안내·Digital NOTAM 안내, Donlon_2025 표본.
- EUROCAE, ED-318 및 ED-269 Change 1 공개 안내문, WG-105의 ED-269 갱신 발표 자료(FAA ATIEC 2023).
- 스위스 BAZL, 지오존 데이터 모델 문서 2.0판.
- FAA, UAS Traffic Management Concept of Operations v2.0 (2020-03-02).
- ASTM F3548-21·F3411, EUROCAE ED-269·ED-318 본문, SWIM Service Description 2.0판, ICAO Doc 10039·9965, EUR-Lex의 규정 정본 — 읽지 못함
(확인 필요).
다음 장: 9.15 — 셀룰러·위성·항공 이동 통신 표준: 3GPP UAS·NTN·ISAC·LDACS·AeroMACS·위성 C2로 간다.