제9부 규격·프로토콜·인터페이스
9.23 적합성·상호운용성 시험과 규격 문서 읽는 법
9.23.1 이 장에서 배우는 것 / 선수 지식 / 특히 중요한 독자
제9부는 규격 문서가 무엇을 정하는지를 장마다 읽었다. 이 장은 그 읽기 자체를 정리한다. 규격 문서를 어떤 순서로 읽고, 어떤 낱말이 얼마나 강한 요구인지 가려내며, 요구가 시험으로 입증되는 길이 어떻게 이어지는가를 다룬다. 9.1이 문서의 종류와 구속력을 구분했다면 이 장은 문서 안을 읽는 법과 문서가 시험으로 이어지는 방식이다. 제9부 앞 장들(9.4~9.21)에서 읽은 문서를 사례로 사용하고, 이 장의 수치는 그 문서들에서 센 값이다.
배우는 것:
- 입증을 뜻하는 네 낱말 — 적합성·상호운용성·성능·인증의 차이.
- 규범 어휘 — shall·should·may와 이행 수준(M·R·O), 표준 기구마다 다른 표기, 이 책이 읽은 세 문서의 분포.
- 요구 문장의 해부 — 문장에서 읽히는 것과 시험 계획이 채워야 하는 것.
- 요구 번호와 추적성 — InterUSS의 시험 도구가 요구 번호를 시험 단계에 연결하는 방식과 F3548-21의 요구 번호 구조.
- 적합성과 상호운용성 시험 — IETF의 두 독립 구현 기준, SWIM의 검증 방법 다섯 가지, 자동 시험 도구의 철학.
- 두 가지 계산 — 신뢰도 요구를 시험으로 입증하는 데 필요한 시행 수, 상호운용 시험 행렬의 크기.
- 규격 읽기 체크리스트 — 판·범위·규범성·인용·유도 근거까지.
선수 지식: 9.1(규격의 세계와 판 관리), 9.14(정보 교환 규격), 9.15(통신 표준)을 읽었다고 가정한다. 인증의 입증 방법은 20.6, 환경·EMC 시험은 8.9·8.10이 다룬다.
특히 중요한 독자: 시험·품질 담당자는 9.23.5~9.23.8을, 인증·규제 담당자는 9.23.3·9.23.9·9.23.10을, 엔지니어는 9.23.4·9.23.6·9.23.7을, 정책 담당자는 9.23.2·9.23.9를 먼저 읽는다.
기준 시점과 정직성. 2026년 11월 기준이다. 원문을 읽은 것: IETF RFC 2119(9.1에서 읽음)·RFC 8174(2017-05)·RFC 6410(2011-10), RFC 2026(훑어봄), 3GPP TS 23.256 V19.5.0의 머리말(조동사 정의)과 TS 22.125 V19.2.0(9.15), EUROCONTROL SWIM TI Yellow Profile 1.1판(2020-07-05)·2.0판(2025-07-14)의 요구 구조와 부속서 A(9.14), ICAO Annex 10 제3권 제13장(LDACS) 제안 개정안(9.15), InterUSS
monitoring저장소의uss_qualifier문서(README, automated_testing, scenarios·suites·reports·requirements 폴더의 문서와 F3548-21·F3411-22a 요구 집합). 읽지 못한 것: ISO/IEC Directives 제2부(자동 접근 제한 403 — 우회하지 않았다), ISO/IEC 17000·17025·17065·Guide 2(유료), ETSI 작성 규칙(404), ASTM의 Form and Style, RTCA·EUROCAE의 문서 작성 규정, ICAO Annex의 서문, 각 표준의 본문(F3548·F3411·DO-362A 등). 이 장의 구분 가운데 이 장이 읽은 문서로 뒷받침되지 않는 것은 이 책의 정리라고 표시했다. 읽지 못한 부분은(확인 필요)로 표시했다.
9.23.2 개념·직관 — 입증을 뜻하는 네 낱말
한국어 문서에서 "인증"은 맥락에 따라 네 가지를 뜻한다. 이 장이 읽은 문서에서 구분이 나타나는 방식을 표로 정리한다. 마지막 열은 이 장이 읽은 근거이다.
| 낱말 | 묻는 것 | 시험의 대상 | 읽은 근거 |
|---|---|---|---|
| 적합성(conformance) | 구현이 문서의 요구를 만족하는가 | 구현 하나, 요구 번호별 | SWIM의 구현 수준 M·R·O와 검증 방법, uss_qualifier의 요구 집합 |
| 상호운용성(interoperability) | 서로 다른 구현이 함께 동작하는가 | 구현 둘 이상의 쌍·집합 | RFC 6410의 "두 독립 구현", uss_qualifier의 "여러 USS의 상호운용" |
| 성능(performance) | 수치 요구를 만족하는가 | 지연·신뢰도·정확도의 분포 | TS 22.125의 KPI 표, 각 요구의 백분위 |
| 인증(certification) | 당국·제3자가 만족을 확인했는가 | 입증 방법과 적합성 매트릭스 | 9.1·20.6 |
적합성은 필요 조건이지만 충분하지 않다. 서로 적합한 두 구현이 상호운용에 실패할 수 있다(요구가 선택 항목을 다르게 구현했거나 해석이 갈릴 때). 반대로 상호운용이 되어도 요구를 만족한다는 보장은 없다. RFC 6410은 이를 한 문장으로 말한다. 과거 IETF는 서로 다른 코드 기반의 두 구현 사이의 상호운용 보고서를 단계로 요구했으나, 2011년 개정은 이를 널리 배포된 여러 독립 구현의 운영 경험으로 대체했다.
9.23.3 규범 어휘 — shall은 얼마나 강한가
9.23.3.1 기구마다 다른 표기
| 문서 | 규범 표기 | 읽은 근거 |
|---|---|---|
| IETF(RFC 2119·8174) | MUST·SHOULD·MAY. RFC 8174는 대문자일 때만 정의된 뜻을 가진다고 명확히 했다 | RFC 8174 1절 |
| 3GPP(TS 머리말) | shall·shall not(규범), should·should not(권고), may·need not(허용). "must"는 규범 문맥에서 쓰지 않는다 | TS 23.256 머리말 |
| EUROCONTROL SWIM TI | shall=필수(M), should=권고(R), may=선택(O). 요구마다 이행 수준 표와 검증 방법이 있다 | Yellow Profile 1.5절·부속서 A |
| ICAO Annex(제안문) | 표준은 "shall", 권고 방식은 "Recommendation.—"으로 시작하는 문장, 그 밖은 "Note.—" | Annex 10 제13장 제안문 |
| EASA·FAA 지침(AMC·GM·AC) | 수용 가능한 방법일 뿐 법적 효력이 없다 | 9.1.2 |
대소문자가 뜻을 가른다. RFC 8174가 존재하는 이유는 RFC 2119가 키워드가 "자주 대문자로 표기된다"고만 해서 소문자 "must"와 "should"의 해석이 갈렸기 때문이다. 3GPP는 반대로 소문자 shall을 규범으로 정의한다. 같은 낱말도 문서의 머리말이 정의한 방식으로만 읽어야 한다.
9.23.3.2 워크스루 I — 규범 동사의 분포
이 책이 읽은 세 문서에서 규범 문장의 동사를 정규식으로 센 값이다(9.23-calc.py, 근사).
| 문서 | 규범 문장 | shall | should | may | 기타 |
|---|---|---|---|---|---|
| 3GPP TS 22.125 V19.2.0 | 68 | 63(92.6 %) | 3(4.4 %) | 1(1.5 %) | 1 |
| SWIM TI Yellow Profile 1.1 | 105 | 54(51.4 %) | 3(2.9 %) | 44(41.9 %) | 4 |
| Annex 10 제13장 LDACS 제안문 | 74 | 70(94.6 %) | 4(5.4 %) | 0 | 0 |
TS 22.125는 [R-…] 항목 71개 가운데 void 3개를 뺀 68개이다. 3GPP와 ICAO 제안문은 거의 모두 shall이지만 SWIM은 42 %가 may이다. SWIM의 표는 요구 문장을 모두 규범 목록에 올리고 이행 수준(필수·권고·선택)을 따로 정해서이다. 곧 shall의 개수가 아니라 이행 수준과 적용 조건을 읽어야 한다. 1.1판 부속서 A.2(인프라 능력) 57개 중 필수는 17개(29.8 %)이고 선택이 37개이다(9.14.7.3). 수치를 가진 요구는 더 적다. TS 22.125의 68개 가운데 단위가 있는 수치(ms·m·km/h·바이트·%)를 포함한 문장은 9개(13.2 %) 이고, 나머지는 능력의 존재를 요구한다. 수치는 표 7.1-1·7.2-1 같은 별도 표에 있다. LDACS 제안문의 99개 번호 조항 중 규범 문장 74개를 뺀 25개는 절 제목이거나 정규식이 분류하지 못한 항목이다(구분하지 않았다).
9.23.4 요구 문장의 해부
TS 22.125의 R-5.2.2-011은 "3GPP 시스템은 종단 지연 100 ms 이하로 메시지를 전송할 수 있는 직접 UAV 간 방송 전송 서비스를 지원해야 한다"이다. 시험 계획을 세우려면 문장이 주지 않는 속성을 정해야 한다.
| 속성 | 질문 | 이 문장에서 | 같은 사양의 보완 |
|---|---|---|---|
| 백분위 | 시간의 몇 %에서 100 ms 이하인가 | 없음 | 표 7.2-1은 신뢰도를 "요구 지연 안의 응용 계층 성공 확률"로 정의(NOTE). Stage 2(TS 23.256 표 6.2.4.1-1)의 PQI 65·62가 지연 버짓 100 ms에 패킷 오류율 10⁻²를 둔다(대응은 이 책의 추정) |
| 측정 지점 | 어디에서 어디까지의 지연인가 | "종단"이라고만 함 | 표의 크기는 응용 계층, 헤더·보안 부하 제외(NOTE) |
| 부하 조건 | 몇 대가 방송할 때인가 | 다른 항목이 크기 50~1,500 B·초당 10개·범위 600 m·속도 320 km/h를 정함 | 송신자 수는 정하지 않음 |
| 시험 방법 | 실측인가 시뮬레이션인가 | 없음 | 없음 |
반대의 사례가 SWIM TI Yellow Profile이다. 각 요구는 식별자·제목·진술·설명·검증의 다섯 항목 표로 작성되고, 검증은 문서 검사, 구성 검사, 시연, 시험, 분석 다섯 방법 중에서 고른다(1.5절). 곧 요구 단위에서 입증 방법이 정해져 있다. 이는 인증의 입증 방법(시험·해석·검사·시연, 20.6)과 같은 분류이다. 3GPP의 Stage 1 사양은 서비스 요구를 정하고, 백분위는 Stage 2의 QoS 표(9.23.9.2)에서 일부 채워지며, 시험 방법은 Stage 3 사양과 별도의 적합성 시험 사양이 정한다(이 장은 그 시험 사양을 읽지 않았다 (확인 필요)).
9.23.5 요구 번호와 추적성 — 시험 도구는 번호를 따라간다
9.23.5.1 uss_qualifier의 구조
InterUSS의 uss_qualifier는 요구에 대한 적합성과 여러 USS·USSP의 상호운용성을 자동 시험으로 측정하는 도구이다(README). 구조는 다음과 같다.
| 층 | 역할 |
|---|---|
| 시험 시나리오 | 시험 실행의 핵심 단위. 시험 사례 → 시험 단계 → 검사로 나뉜다 |
| 시험 모음(suite) | 시나리오의 정적 "재생 목록". 동적 생성은 행동 생성기가 한다 |
| 시험 구성 | 무엇을 어떻게 시험할지 정한 입력. 보통 참가자 전체가 하나의 구성을 공유한다 |
| 시험 자원 | 참가자 시스템의 위치와 시험 행동의 능력 |
| 보고서 | 요구별로 검사를 묶은 "시험된 요구" 산출물 등 |
철학. 문서는 자동 시험을 "수동 점검의 자동화"로 정의한다. 시나리오 문서만 보고 사람이 수동으로 같은 시험을 수행할 수 있어야 하고, 자동 시험 인터페이스는 시험 감독이 수동에서 지시했을 내용을 그대로 자동화한다. 또 목표는 "완전"이 아니라 "충분" 이다. 시험의 집합은 부정을 증명할 수 없으므로 객관적으로 완전할 수 없고, 허용 가능한 신뢰 수준에서 요구 적합을 성립시키는 활동의 집합을 지향한다.
9.23.5.2 요구 번호의 규모
도구의 요구 파일은 표준의 요구 번호(식별자)를 열거한다(본문은 표준에 있고 이 장은 번호만 읽었다).
| 집합 | 번호 수 | 내용 |
|---|---|---|
| ASTM F3548-21 전체 | 162 | 공통 13, 운용 의도 생성·수정 8, 전략적 충돌 탐지 24, 집계 적합성 감시 3, 상황 인식용 적합성 감시 23, 제약 관리 20, 제약 처리 7, 로깅 11, DSS 53 |
| 전략적 충돌 탐지 서비스 집합 | 54 | 자동 검증 45(83.3 %), 수동 검증 9 |
| ASTM F3411-22a | 158 | Remote ID 서비스 제공자·표시 제공자·DSS·시험 환경 요구 |
전략적 충돌 탐지 집합의 54개는 F3548-21 전체의 33.3 % 이다. 수동 검증 9개는 공통 요구(GEN)·운용 의도 생성(OPIN)·집계 적합성 감시(ACM)의 일부로, 사람이 확인해야 하는 요구이다. 요구 번호는 일련번호가 아니라 OPIN0005·DSS0210,1a처럼 영역 접두어와 하위 번호를 가진다. 번호 하나가 표준의 어느 단위(문단·항목)에 대응하는지는 표준 본문에서 확인해야 한다 (확인 필요).
9.23.5.3 시험된 요구 보고서와 판정
산출물은 참가자별로 요구마다 검사들을 묶어 보여 준다. 요구 목록은 구성에서 명시하지 않으면 시나리오가 측정할 수 있었던 모든 요구가 기본이다. 요구 하나의 상태는 그 요구에 연결된 검사 결과로 다섯 가지 중 하나가 된다.
| 요구의 상태 | 뜻 | 검사의 조건 |
|---|---|---|
| 실패 | 하나 이상의 요구에 부적합일 가능성이 높다 | 중간 이상 심각도의 실패 검사가 허용된 발견에 없는 것이 하나 이상 |
| 발견 | 부적합은 탐지되지 않았으나 중요한 발견이 있고 완전히 성공한 검사가 없다 | 통과 검사 없음, 낮은 심각도의 발견이 하나 이상 |
| 통과(발견 있음) | 부적합이 없고 적합을 확인한 검사가 있으나 중요한 발견이 있다 | 통과 검사 하나 이상과 낮은 심각도의 발견 하나 이상 |
| 통과 | 적합을 측정한 검사가 하나 이상이고 부적합이 탐지되지 않았다 | 통과 검사 하나 이상, 발견 없음 |
| 시험 안 됨 | 요구에 연결된 검사가 긍정도 부정도 만들지 못했다 | 통과·실패 검사 모두 없음 |
검사의 심각도는 네 단계이다. 낮음은 요구를 위반하지 않았으나 개선에 유용한 발견, 중간은 요구를 위반했으나 시나리오는 계속할 수 있는 경우, 높음은 시나리오가 정리 후 종료해야 하는 경우, 치명적은 시험 실행 전체를 멈춰야 하는 경우이다. 참가자의 최상위 판정은 이 다섯 상태를 요약해 정한다(compute_overall_status, 이 장은 그 규칙의 세부를 읽지 않았다 (확인 필요)). 측정하지 못한 요구가 "시험 안 됨"으로 드러나므로 시험 계획의 약점은 실패보다 시험 안 됨의 개수로 보인다. 이 구조는 인증의 적합성 매트릭스(20.6)와 같은 목적이다.
9.23.6 적합성과 상호운용성을 어떻게 시험하는가
세 가지 방식이 이 장이 읽은 문서에서 나타난다.
| 방식 | 입증의 근거 | 읽은 문서 | 강점 | 한계 |
|---|---|---|---|---|
| 요구별 검증 방법 선택 | 요구마다 문서 검사·구성 검사·시연·시험·분석 가운데 하나 | SWIM TI Yellow Profile | 입증 방법이 요구에 붙어 있다 | 시험 절차 자체는 별도 |
| 자동 시험 도구와 공유 구성 | 시나리오의 검사가 요구 번호에 연결되고 모든 참가자가 같은 구성으로 시험 | uss_qualifier | 반복·회귀 시험, "시험 안 됨" 가시화 | 시나리오 개발과 시험 환경 비용 |
| 배포 경험 | 서로 다른 코드 기반의 둘 이상의 구현이 널리 배포되어 운영 | RFC 6410 | 실제 환경의 증거 | 시간이 걸리고 사전 입증이 아니다 |
SWIM TI Yellow Profile은 적합 선언의 단위도 정한다. 부속서 A.1은 서비스 인터페이스 바인딩 하나와 네트워크 인터페이스 바인딩 하나 이상을 구현해야 적합이라고 하고, 인프라 능력은 요구별 이행 수준(M·R·O)과 조건부(Conditional) 표지로 나눈다(9.14.7.3). 곧 적합은 문서 전체에 대한 예·아니오가 아니라 선택한 바인딩과 이행 수준의 조합에 대한 진술이다. RFC 6410이 Internet Standard에 요구하는 기준은 넷이다. (1) 널리 배포되고 운영 경험이 있는 둘 이상의 독립 구현, (2) 새 구현이 배포된 구현과 상호운용에 실패하게 만드는 정오표가 없을 것, (3) 구현 복잡도를 크게 높이는 미사용 기능이 없을 것, (4) 통제된 기술이 필요하면 라이선스 절차의 독립적 성공 사례 둘. 상호운용성의 증거에서 정오표가 없다는 조건이 들어 있다는 점이 항공 표준의 판 관리(9.1.7)와 이어진다. 상호운용 보고서는 더 이상 요구되지 않지만 시험 전통은 유효하다고 문서는 적는다.
9.23.7 워크스루 II — 신뢰도 요구를 시험으로 입증하는 데 필요한 시행 수
TS 22.125 표 7.2-1은 C2 메시지에 99.9 %(인프라 접근은 99 %와 99.99 %)의 신뢰도를 요구한다(9.15.3.3). 이를 시험으로 입증하려면 독립 시행 몇 번이 필요한가를 계산한다. 실패 확률이 $q=1-R$보다 크다면 시험에서 실패가 $k$건 이하로 나올 확률이 $1-C$ 이하가 되는 최소 시행 수이다. 실패를 허용하지 않으면 $n\ge\ln(1-C)/\ln R$이다.
| 요구 신뢰도 | 무실패 | 실패 1건 허용 | 실패 3건 허용 |
|---|---|---|---|
| 99 % | 299 | 473 | 773 |
| 99.9 % | 2,995 | 4,742 | 7,752 |
| 99.99 % | 29,956 | 47,437 | 77,535 |
| 99.999 % | 299,572 | 474,385 | 775,364 |
신뢰도 95 %의 값이다. 요구가 10배 엄격해지면 필요한 시행도 10배가 된다. 99.9 %의 무실패 2,995회는 25 Hz 스틱 조종 메시지로 2.0분이지만, 1 Hz 경유점 조종 메시지로는 49.9분이다. 99.99 %(29,956회)는 25 Hz에서 20.0분, 1 Hz에서 8.3시간이다. 실패를 허용하면 시행이 늘지만 1건 허용은 약 1.6배(99.9 %에서 4,742회)이다. 이 계산은 시행의 독립을 가정한다. 연속 손실이나 기상·간섭 같은 상관이 있으면 더 많은 시행과 조건의 층화(고도·거리·부하)가 필요하다. 99.999 %의 무실패 299,572회는 25 Hz에서 3.3시간, 1 Hz에서 83.2시간이다. 시간 자체는 감당할 수 있으나 고도·거리·부하 같은 조건 층마다 반복하면 곱으로 늘어나므로, 입증을 시험·분석과 설계 보증(8.4의 확률 목표)으로 나누는 이유가 된다.
9.23.8 워크스루 III — 상호운용 시험 행렬의 크기
서로 다른 구현 $n$개의 쌍은 $n(n-1)/2$개이다. 구현이 3개이면 3쌍, 10개이면 45쌍, 20개이면 190쌍이다. 모든 구현이 판을 $v$개 지원하고 같은 판끼리만 시험하면 쌍의 수에 $v$를 곱해 구현 10개·판 2개이면 90, 구현 20개·판 3개이면 570이다. 판 사이의 하위 호환까지 시험하면 더 늘어난다. 이 증가가 UTM에서 공유 시험 구성(InterUSS의 방식: 참가자 전체가 하나의 구성에 대해 시험)을 택하는 이유이다. 쌍마다 시험하는 대신 모든 USS가 같은 시험 환경에서 같은 시나리오로 시험받으면 참가자 수에 선형으로 늘어난다. 9.14.4.3이 읽은 DSS 풀 문서도 운영 풀과 별도로 파트너 시험용 풀을 둘 것으로 예상한다.
9.23.9 규격 읽기 — 인용·추적·체크리스트
9.23.9.1 인용을 읽는 법
규격은 다른 문서를 인용하고, 인용이 날짜가 있는가 없는가가 어느 판을 따르는지를 정한다. 3GPP 사양의 참조 절은 이를 정의한다. 특정 참조(발행 날짜·판·버전으로 식별)는 이후 개정이 적용되지 않고, 비특정 참조는 같은 릴리스의 최신 판이 적용된다(TS 33.256의 2절). 같은 사양의 참조 목록에서 TS 23.256은 날짜 없이 인용되므로 같은 릴리스의 최신 판을 뜻한다. 반대로 EASA의 AMC는 "SWIM TI Yellow Profile 1.1판, 2020년 7월 5일 발행"처럼 판과 날짜를 특정해 인용한다(9.14.5.2). 이 차이가 9.14에서 본 문제(AMC가 지목한 1.1판과 2025년 2.0판)를 만든다.
| 인용 방식 | 읽은 예 | 결과 |
|---|---|---|
| 날짜 없음 | 3GPP TS 33.256의 TS 23.256 인용 | 같은 릴리스의 최신 판을 따름 |
| 판·날짜 특정 | EASA AMC의 SWIM 1.1판, ED-269 "2020년 6월판" | 이후 판이 나와도 인용 판이 기준이며 개정판 적용은 당국과 합의 |
| 미국 규칙 | OMB A-119(9.1.3): 규정에서 표준 인용에 발행 날짜를 포함 | 같음 |
9.23.9.2 한 요구의 추적 — R-5.2.2-011
요구 하나를 사양군에서 따라가 보면 층마다 무엇이 있고 없는지가 보인다(이 장이 읽은 범위).
| 층 | 문서·조항 | 내용 |
|---|---|---|
| 요구(Stage 1) | TS 22.125 R-5.2.2-011 | 직접 UAV 간 방송이 종단 지연 100 ms 이하(shall) |
| 구조(Stage 2) | TS 23.256 5.5(방송 Remote ID)·5.6(DAA)·6장(A2X) | 방송 Remote ID와 DAA를 A2X 방송 모드로 수행하는 구조 |
| QoS 매핑(Stage 2) | TS 23.256 표 6.2.4.1-1 | PQI 65(방송 DAA)·62(방송 Remote ID, 낮은 지연): 지연 버짓 100 ms, 패킷 오류율 10⁻² |
| 보안 | TS 33.256 5.6.3.2 | 방송 모드 A2X 직접 통신을 보호하는 요구는 없다 |
| 무선·프로토콜(Stage 3) | 이 장은 읽지 않음 | 지연 100 ms를 만족하는 무선 사양 (확인 필요) |
| 적합성 시험 | 이 장은 읽지 않음 | 시험 방법·판정 기준 (확인 필요) |
요구 문장의 수치(100 ms)는 Stage 2의 PQI 표에 지연 버짓으로 되풀이되고 패킷 오류율(10⁻², 곧 99 %)이 더해진다. Stage 1의 C2 KPI도 같은 방식으로 이어진다(직접 스틱 조종 40 ms·99.9 %는 PQI 43의 40 ms·10⁻³). 보안 사양은 같은 방송에 보호 요구를 두지 않는다. 이 사슬에서 마지막 두 층이 비어 있다는 사실이 규격 읽기의 결과이다. 이 추적은 앞에서 읽은 Stage 1만으로는 백분위를 알 수 없고 Stage 2까지 읽어야 채워진다는 것도 보여 준다. 어느 층에서 요구가 수치에서 절차로, 절차에서 시험으로 이어지는지를 추적할 수 있어야 시험 계획이 가능하다.
9.23.9.3 체크리스트
이 책의 사례를 모아 만든 절차이다. 순서는 문서를 받자마자 확인할 것에서 깊이 읽을 것으로 간다.
| 단계 | 확인할 것 | 이 책의 사례 |
|---|---|---|
| ① 판과 날짜 | 어느 판·날짜인가, 규정이 인용한 판인가 | AMC가 지목한 SWIM 1.1판 대 2.0판의 TLS 요구, ED-269 8장의 삭제(9.14.10) |
| ② 접근성 | 본문을 읽었는가, 요약만 읽었는가 | 이 책의 (원문 확인)·(확인 필요) 표지(9.1.6) |
| ③ 범위와 적용 | 누구의 어떤 구성에 적용되는가 | TS 22.125는 서비스 요구이지 감항 입증 기준이 아님(9.15.3) |
| ④ 규범과 참고 | 규범 조항과 Note·부속서(참고)를 구분 | LDACS 제안문의 "Note.—"와 "Recommendation.—"(9.15.6) |
| ⑤ 규범 어휘 | 문서가 정의한 shall·should·may | 9.23.3 |
| ⑥ 이행 수준·조건 | 필수·권고·선택, 조건부 | SWIM 부속서 A의 M·R·O와 Conditional |
| ⑦ 요구 번호 | 번호가 있고 추적되는가 | F3548-21의 요구 번호 162개(9.23.5) |
| ⑧ 입증 방법 | 요구마다 검증 방법이 있는가 | SWIM의 다섯 방법 대 3GPP Stage 1의 부재 |
| ⑨ 수치의 유도 | 수치가 어떻게 나왔는지 재계산 | LDACS 간섭 한계가 3 dB 다름(9.15.6.3), 도플러 24 ppm과 자전(9.15.4.2) |
| ⑩ 오류와 변경 | 정오표·변경 이력·문서 사이의 불일치 | InterUSS 크기 산정 저장 용량의 10배 차이(9.14.4.4), 상태 이름 불일치(9.14.5.3) |
체크리스트의 ⑨가 가장 자주 건너뛰어진다. 규격의 수치는 대개 유도 과정이 부속 문서(매뉴얼·보고서)에 있어서 본문만 읽으면 가정이 보이지 않는다. 이 책의 여러 장이 표준의 수치를 처음부터 다시 계산한 것은 이 단계를 실천한 것이다.
9.23.10 설계 트레이드오프 — 시험을 어떻게 설계할 것인가
방식을 셋으로 펼친다.
① 문서 검사·분석 중심. 구현을 문서로 입증한다(구성 검사·분석). 장점은 비용이 낮고 안전·감항 요구의 확률 목표(8.4)에 맞는다. 단점은 상호운용 같은 동적 성질을 놓친다.
② 수동 시연·시험 중심. 사람이 시나리오를 수행한다. 장점은 새 규격에 빠르게 적용되고 시나리오의 의미가 분명하다. 단점은 반복이 어렵고 횟수가 많은 신뢰도 입증(9.23.7)에 맞지 않는다.
③ 자동 시험 도구와 공유 구성. 요구 번호에 연결된 자동 시나리오와 시험 구성을 참가자가 공유한다. 장점은 회귀 시험·시험 안 됨의 가시화·참가자 수에 선형인 비용이다. 단점은 시나리오 개발과 시험 환경 비용, 시험 인터페이스를 시험 대상이 구현해야 한다는 점이다.
| 방식 | 장점 | 단점 | 누구에게 맞는가 |
|---|---|---|---|
| ① 문서·분석 | 저비용·확률 목표 | 동적 성질 누락 | 감항 요구, 설계 단계 |
| ② 수동 시험 | 빠른 적용·의미 분명 | 반복·대량 시행 어려움 | 새 규격의 초기 검증 |
| ③ 자동 시험 | 회귀·추적성·선형 비용 | 개발·환경 비용 | 다수 참가자가 상호운용해야 하는 생태계(UTM) |
견해: 요구의 성격에 따라 섞는 것이 근거가 가장 강하다. 수치·확률 요구(KPI·고장 확률)는 분석과 설계 보증으로 입증하고 시험은 입증을 보강하는 표본으로 사용한다(2,995회와 299,572회의 차이). 상호운용 요구는 쌍의 수가 늘어나는 구조(9.23.8)이므로 공유 구성의 자동 시험이 유리하다. 새 규격은 수동 시험으로 시나리오의 의미를 확정한 뒤 자동화한다. 근거는 세 가지이다. 첫째 SWIM이 이미 요구마다 검증 방법을 정해 이 혼합을 규격에 넣었다. 둘째 uss_qualifier는 수동 점검의 자동화를 철학으로 삼아 두 단계를 한 흐름으로 둔다. 셋째 신뢰도 요구가 10배 엄격해질 때마다 시행이 10배가 되고 조건을 층화하면 곱으로 늘어난다는 점을 계산이 보인다. 반대 견해로는 자동 시험은 시나리오가 만든 세계만 시험하므로 현장의 다양성을 놓친다는 주장이 있고, 이를 보완하려면 운영 경험(RFC 6410의 방식)과 조합해야 한다.
9.23.11 세 축 비교
| 항목 | 군용 드론 | 민간 UAS | AAM(eVTOL) |
|---|---|---|---|
| 시험·적합성 체계 | 이 장의 범위 밖(제10~12부, 9.2·9.3) | 제조사 시험·표준기구 적합 시험·당국의 운항 승인 | 형식증명의 입증 방법과 인정된 표준(20.5·20.6) |
| 상호운용 시험 | 별도 | UTM·Remote ID는 InterUSS 도구, 오픈소스는 제조사 간 시험 | 공역·ATM과의 접점(9.14)과 여러 조직의 인터페이스 |
| 입증 수준의 요구 | 별도 | 대개 비례적이며 신뢰도 입증은 표본 | 확률 목표(8.4)와 설계 보증 중심 |
| 문서 접근성 | 별도 | 공개 도구·문서가 많음 | 유료 표준이 핵심 |
9.23.12 관련 규격·프로토콜
| 문서 | 발행 | 무엇을 정하나 | 상세 장 |
|---|---|---|---|
| RFC 2119(1997-03)·RFC 8174(2017-05) | IETF | MUST·SHOULD·MAY와 대문자 규칙(원문 확인) | 이 장, 9.1 |
| RFC 6410(2011-10), RFC 2026 | IETF | 표준 단계의 성숙도와 상호운용 기준(원문 확인) | 이 장 |
| 3GPP TS 머리말의 조동사 정의 | 3GPP | shall·should·may(TS 23.256에서 확인) | 이 장, 9.15 |
| SWIM TI Yellow Profile 1.1·2.0(EUROCONTROL-SPEC-170) | EUROCONTROL | 요구 구조·이행 수준·검증 방법(원문 확인) | 이 장, 9.14 |
InterUSS uss_qualifier 문서 | InterUSS | 요구 번호·시나리오·시험된 요구 보고서(원문 확인) | 이 장, 9.14 |
| ISO/IEC Directives 제2부, ISO/IEC 17000·17025·17065 | ISO·IEC | 표준 작성 규칙, 적합성 평가 용어·시험소·인증 기관 요구 — 미열람 | 9.1 |
| ETSI 작성 규칙, ASTM Form and Style | ETSI·ASTM | 기구별 표기 규칙 — 미열람 | — |
전체 지도는 A.6에 있다.
9.23.13 관련 규제·인증 요구와의 연결
- 적합성 입증(20.6), 인증기준(20.5), 기술표준품(20.4). 이 장의 검증 방법 분류와 요구 추적이 입증 방법과 적합성 매트릭스의 구조와 같다.
- 환경·EMC 시험(8.9·8.10), 통신 시험(3.20). 시험 설비와 방법.
- 소프트웨어·하드웨어 보증(8.8). 시험의 독립성과 도구 자격.
- 정보 교환(9.14)과 통신 표준(9.15). 이 장의 사례의 출처.
- 규격의 세계(9.1). 판 관리와 합의 표준.
- 요구공학(8.1). 요구의 속성(검증 가능성)과 추적성.
9.23.14 함정과 한계
| 오해 | 실제 | 더 볼 곳 |
|---|---|---|
| shall이 많으면 의무가 많다 | SWIM은 42 %가 may이고 이행 수준 표가 강도를 정한다 | 9.23.3.2 |
| 소문자 must·should도 규범이다 | IETF는 대문자만, 3GPP는 소문자 shall을 규범으로 정의하므로 머리말을 읽는다 | 9.23.3.1 |
| 요구 문장에 시험 조건이 있다 | 백분위·측정 지점·부하·방법이 대개 없다 | 9.23.4 |
| 적합하면 상호운용된다 | 선택 항목·해석 차이로 실패할 수 있다 | 9.23.2 |
| 신뢰도는 시험 횟수만 채우면 된다 | 무실패 29,956회(99.99 %)·299,572회(99.999 %)를 조건 층마다 반복해야 하므로 분석·설계 보증과 나눈다 | 9.23.7 |
| 상호운용 시험은 쌍마다 하면 된다 | 쌍과 판에 비례해 늘고 공유 구성이 선형으로 줄인다 | 9.23.8 |
| 시험이 통과하면 요구가 입증된다 | "시험 안 됨"인 요구가 따로 있고 시험은 완전할 수 없다 | 9.23.5.3 |
| 문서의 수치는 믿어도 된다 | 유도 과정을 다시 계산하면 어긋나는 사례가 있다 | 9.23.9 |
미해결 문제. 3GPP Stage 3·적합성 시험 사양의 구조, ISO/IEC 17000 계열의 용어 정의와 이 장의 구분의 대응, ETSI·ASTM·RTCA의 작성 규칙, F3548의 요구 본문, 항공 표준의 정오표 관리 제도, 시험 시나리오의 충분성을 정량화하는 방법은 이 장의 자료로 답할 수 없다 (확인 필요).
9.23.15 체크포인트·연구 질문
체크포인트:
- 적합성·상호운용성·성능·인증의 차이를 한 문장씩 적고 서로 적합한 두 구현이 상호운용에 실패하는 경우를 하나 들어라.
- RFC 8174가 RFC 2119에 더한 규칙과 3GPP의 소문자 shall의 차이를 설명하라.
- TS 22.125의 규범 문장 68개에서 shall·should·may의 비율과 수치를 가진 문장의 비율을 구하라(
9.23-calc.py). - R-5.2.2-011에서 시험 계획이 채워야 하는 속성 네 가지를 적어라.
- F3548-21의 요구 번호 162개 중 전략적 충돌 탐지 집합의 비율과 자동 검증의 비율을 구하라.
- 신뢰도 99.9 %를 95 %의 신뢰도로 무실패 입증하는 데 필요한 시행 수와 25 Hz에서 걸리는 시간을 구하라.
- 구현 12개가 판 2개를 지원할 때 같은 판 조합의 시험 쌍 수를 구하라.
- 규격 읽기 체크리스트의 ⑨(수치의 유도)를 이 책의 사례로 설명하라.
연구 질문(25.7에 모은다):
- 시험 시나리오의 충분성을 요구 번호의 "시험 안 됨" 비율 이상으로 정량화할 수 있는가.
- 3GPP의 서비스 요구(Stage 1)를 적합성 시험 사양까지 추적하는 체계를 어떻게 공개할 수 있는가.
- 항공 표준의 정오표를 상호운용 기준에 넣는 제도는 어떤 모습이어야 하는가.
- 신뢰도 요구를 시험·분석·운영 경험의 세 근거로 나눠 입증하는 비율은 어떻게 정하는가.
1차 출처(이 장):
- IETF, RFC 2119(BCP 14, 1997-03, 9.1에서 읽음), RFC 8174(BCP 14, 2017-05), RFC 6410(BCP 9, 2011-10), RFC 2026.
- 3GPP TS 23.256 V19.5.0 머리말, TS 22.125 V19.2.0.
- EUROCONTROL, Specification for SWIM Technical Infrastructure (TI) Yellow Profile, EUROCONTROL-SPEC-170, 1.1판·2.0판.
- ICAO, Annex 10 제3권 제13장(LDACS) 제안 개정안 텍스트(제안문이며 채택 본문이 아니다).
- InterUSS,
monitoring저장소의uss_qualifier문서(github.com/interuss/monitoring). - ISO/IEC Directives 제2부(403), ISO/IEC 17000·17025·17065, ETSI 작성 규칙(404), ASTM Form and Style, 각 표준의 본문 — 읽지 못함
(확인 필요).
다음 장: 제9부는 이 장으로 끝난다. 목차의 다음은 제10부 군용 드론 I(10.1~10.22)로 군사 중심 장이므로 건너뛴다(BK-08). 이어지는 비군사 부는 사용자의 지시에 따른다.