제9부 규격·프로토콜·인터페이스

9.4 기체 내부 버스·네트워크: CAN·DroneCAN·Cyphal·ARINC 429·MIL-STD-1553·ARINC 664·TSN

9.4.1 이 장에서 배우는 것 / 선수 지식 / 특히 중요한 독자

기체 안에서 비행 제어 컴퓨터는 센서, 작동기, 전원, 임무 컴퓨터와 버스로 연결된다. 버스 규격은 누가 언제 송신하는지, 한 번에 얼마를 보내는지, 한 노드가 고장 나면 나머지가 어떻게 되는지를 정한다. 2.9.5는 이 선택을 구조의 성질로 비교했다. 이 장은 그 표의 규격을 열어 프레임·타이밍·분할의 실제 수치를 계산하고, 각 규격이 제공하지 않는 것(특히 송신자 인증)을 밝힌다.

배우는 것:

• CAN과 CAN FD — 프레임의 비트 수, 비트 스터핑, 중재, 비트 타이밍과 최대 버스 길이, 오류 가둠(Bosch CAN 2.0 원문).
• DroneCAN과 Cyphal — 29비트 식별자, 꼬리 바이트, 다중 프레임 분할과 CRC, 두 규격이 같은 버스에 공존하지 못하는 이유(공개 사양서 원문).
• ARINC 429 — 단방향 32비트 워드, 속도, 갱신 주기와 시차(2차 출처).
• MIL-STD-1553 — 맨체스터 II 변조, 20비트 워드, 메시지 형식, 응답 시간, 종단과 처리량(원문, 버스 기술 표준으로만).
• ARINC 664 Part 7(AFDX)과 TSN — 가상 링크의 BAG·Lmax와 지터 한계, 시간 인지 정형과 보호 대역, 항공 프로파일 IEEE 802.1DP(2차 출처).
• 네 가지 계산 — CAN 버스 부하와 최악 응답 시간, 최대 버스 길이, 전송 분할 오버헤드, 1553·AFDX·TSN의 시간 수치.

선수 지식: 2.9(항공전자 구조와 버스 비교), 2.5(고장 허용 설계), 9.1(규격의 세계와 원문 접근성의 층)을 읽었다고 가정한다. MAVLink는 9.5이, ROS 2·DDS는 9.6이, 개방형 체계 구조는 9.11이 다룬다.

특히 중요한 독자: 엔지니어는 9.4.3~9.4.9와 9.4.12를, 인증 담당자는 9.4.10·9.4.15를, 정책·법무 담당자는 9.4.10과 9.4.16을, 사업 담당자는 9.4.11(비교)과 9.4.12(선택)를 먼저 읽는다.

기준 시점과 정직성. 2026년 11월 기준이다. 원문을 읽은 것: Bosch CAN Specification 2.0(1991-09, Part A의 소개·비트 타이밍, Part B의 기본 개념·프레임·코딩·오류·고장 가둠·발진기 허용 오차), DroneCAN 사양서(웹판 1·2·3·4.1·4.4·5·8장과 DSDL 정의 파일, 2025-08-26 생성본), Cyphal 사양 v1.0(2025-05-16 개정, 4.2·4.3의 개요·헤더·MTU·5.3.13·6.4.1), MIL-STD-1553C(2018-02-28)와 MIL-STD-1553B(1978-09-21)(둘 다 DLA ASSIST에서 내려받은 공개 승인 사본이며, 1553B는 스캔 문자 인식본이어서 값이 일치하는 조항만 대조했다), IEEE 802.1 TSN 작업반 페이지와 IEEE SA의 802.1DP 표준 페이지·안내문(본문이 아닌 개요). 2차 출처로 읽은 것: CAN FD(Bosch의 Hartwich, iCC 2012. Bosch CAN FD 사양서 본문은 내려받지 못했다), CAN 응답 시간 분석(Davis 등 2007의 저자 발표 자료. 논문 본문은 내려받지 못했다), ARINC 429(AIM의 튜토리얼 2010과 프로그래머 안내서), ARINC 664 Part 7(AIM 교육 자료 2010과 Universidad de Cantabria의 응답 시간 분석 논문), TSN의 동작(Stüber 등의 서베이 arXiv 2211.10954). 읽지 못한 것: ISO 11898-1·-2, ARINC 429·664·825의 본문, SAE AS15531, IEEE 802.1Q·802.1AS·802.1DP의 본문(유료이거나 열람 절차가 필요하다). 읽지 못한 부분은 (확인 필요), 2차 출처는 (2차 출처)로 표시했다. 제조사 제원은 사용하지 않았다. 이 장은 군 체계의 운용·무기·작전을 다루지 않는다.

9.4.2 개념·직관 — 버스는 누가 언제 말하는지를 정하는 약속이다

버스마다 송신을 시작하는 권한을 다르게 둔다. 이 권한이 지연의 상한, 단일 고장점, 배선 수를 결정한다. 이 장의 규격은 네 가지 방식으로 나뉜다.

세 축에서 요구가 다르다. 소형 UAS는 질량·비용·배선 단순성이 앞서서 CAN 계열(DroneCAN 등)이 ESC·센서 연결에 사용된다(2.9.5의 표). AAM은 인증과 다중화가 앞서서 결정성이 입증되는 방식이 필요하다. 군용 기체의 버스 선택은 이 장의 범위 밖이며 규격 지도는 9.2·9.3에 있다. 실제 기체의 버스 구성은 제조사별로 비공개인 경우가 많아서, 이 장은 구성이 아니라 규격의 성질을 비교한다.

9.4.3 CAN과 CAN FD — 원문의 구조

9.4.3.1 프레임과 비트 수

CAN은 버스가 비어 있으면 어느 노드든 송신을 시작할 수 있다(다중 마스터). 둘 이상이 동시에 시작하면 식별자의 비트별 중재가 충돌을 해결한다. 송신 노드는 자기가 보낸 비트를 버스에서 다시 읽고, 열성(1)을 보냈는데 지배(0)가 읽히면 중재에서 졌으므로 즉시 물러난다(Bosch Part B p.39). 식별자는 목적지가 아니라 데이터의 의미를 이름 짓고, 모든 노드가 필터링으로 수신 여부를 정한다(p.38). 식별자 값이 작을수록 우선순위가 높다.

표준 프레임은 식별자 11비트, 확장 프레임은 29비트이다(p.42). 데이터 프레임의 비트 수는 아래와 같다(Part B 3.2.1, p.42~48). SOF는 프레임 시작, RTR은 원격 송신 요청, IDE는 식별자 확장, DLC는 데이터 길이 코드, ACK는 수신 확인, EOF는 프레임 끝이다.

비트 스터핑은 같은 값이 연속 5비트이면 반대 값 한 비트를 끼우며, SOF부터 CRC 순서열까지에만 적용한다(Part B 6절, p.58). 스터핑 구간의 길이가 $L$이면 최악의 스터프 비트 수는 $\lfloor (L-1)/4 \rfloor$이므로 프레임의 최대 길이는 다음과 같다.

$$N_{\text{std}} = 47 + 8n + \left\lfloor \frac{33 + 8n}{4} \right\rfloor, \qquad N_{\text{ext}} = 67 + 8n + \left\lfloor \frac{53 + 8n}{4} \right\rfloor$$

1 Mbit/s에서 표준 8바이트 프레임의 페이로드 비율은 $64/111 = 57.7\ \%$, 최악 $64/135 = 47.4\ \%$이다. 오류 검출은 모니터링, CRC, 비트 스터핑, 프레임 검사로 이루어지며 원문은 무작위 오류 5개까지, 길이 15 미만의 연집 오류를 검출한다고 밝힌다(p.39). 검출되지 않은 오류 확률은 메시지 오류율의 $4.7\times10^{-11}$배 미만이다(p.40). 오류를 검출한 노드는 오류 프레임을 보내 모든 노드가 프레임을 폐기하게 하고 자동으로 재전송한다. 오류 검출에서 다음 메시지 시작까지는 최대 31비트 시간이다(p.40). 원문은 오류 수동 수신 노드가 오류 프레임을 마치려면 버스가 최소 3비트 시간 쉬어야 할 수 있으므로 버스를 100 %로 적재하면 안 된다고 적는다(p.50).

9.4.3.2 비트 타이밍과 최대 버스 길이

한 비트는 SYNC_SEG(1 양자), PROP_SEG, PHASE_SEG1, PHASE_SEG2로 나뉘고 표본 시점은 PHASE_SEG1의 끝이다(Part A 8절, p.27~28). PROP_SEG는 버스 전파 시간, 입력 비교기 지연, 출력 드라이버 지연 합의 두 배이다(p.28). 결론은 비트율이 높을수록 버스가 짧아야 한다는 것이다. 원문의 PROP_SEG 범위는 1~8 양자이며, ISO 11898-1은 8 양자를 넘는 범위를 허용하고 Bosch의 CAN FD 구현은 PHASE_SEG2를 16 양자, PROP_SEG와 PHASE_SEG1의 합을 64 양자까지 설정하게 했다(Hartwich 5절) (ISO 본문 미열람).

가정: 비트당 16 양자, 표본 시점 87.5 %, PHASE_SEG1 1 양자, 케이블 5 ns/m(DroneCAN 사양서 8장의 가정), 트랜시버 지연 합 $t_x$는 150 ns 또는 255 ns(ISO 11898-5 트랜시버 루프 지연의 상한으로 Hartwich가 적은 값).

$$\text{PROP\_SEG} = (0.875 \times 16 - 2)\,t_q \ \ge\ 2\,(L v + t_x) \ \Rightarrow\ L_{\max} = \frac{\text{PROP\_SEG} - 2 t_x}{2 v}$$

계산은 사양서 값과 같은 크기를 주며, 1 Mbit/s에서는 트랜시버 지연 하나로 길이가 두 배 가까이 달라진다. 표의 사양서 값은 트랜시버 지연을 포함하지 않는 가정이다. 같은 표는 최대 스텁 길이를 0.3 m로 적는다. 발진기 허용 오차는 세라믹 공진자가 125 kbit/s까지이고 그 이상은 수정 발진기가 필요하다(Part B p.64).

9.4.3.3 오류 가둠 — 고장 난 노드를 스스로 끊는다

모든 노드는 송신 오류 계수(TEC)와 수신 오류 계수(REC)를 두고, 송신 중 오류 프레임을 보내면 TEC를 8 올리고 성공하면 1 내린다. 계수가 128 이상이면 오류 수동(활성 오류 플래그를 보내지 못함), TEC가 256 이상이면 버스 오프(버스에 영향을 줄 수 없음)이며, 11개의 연속 열성 비트가 128번 관측되면 복귀할 수 있다(Part B 8절, p.61~63). 원문은 이를 일시적 교란과 영구 고장을 구분해 고장 노드를 스스로 끊는 장치로 설명한다(p.36, p.40). 이 장치는 오류 프레임을 일으키는 노드를 대상으로 하며, 유효한 프레임을 계속 보내는 오작동 노드(예: 최고 우선순위 식별자를 반복 송신)는 오류가 아니므로 가둘 수 없다 (이 책의 해석).

9.4.3.4 CAN FD — 같은 중재, 빠른 데이터 구간

CAN FD는 중재 구간의 비트율을 유지하고 BRS 비트 이후 데이터 구간만 빠른 비트율로 전송하며, DLC 9~15를 12·16·20·24·32·48·64바이트로 재정의한다(Hartwich 3절). 새 비트는 EDL, BRS, ESI이다. CRC는 Hamming 거리 6을 유지하려고 17비트(데이터 16바이트 이하)와 21비트(그 초과) 다항식으로 바뀌며, CRC 순서열에는 고정 위치의 스터프 비트가 들어가 22비트와 27비트가 된다(4절의 규칙에서 센 값). 트랜시버 루프 지연이 데이터 구간 비트보다 길 수 있어 송신 노드는 지연 보상(TDC)으로 표본 시점을 늦춘다(6절). 1M/4M 구성(가정)의 프레임 시간은 다음과 같다(스터핑 없음, 인터미션 포함).

이 값은 Bosch 사양(2012)에 따른 계산이며 ISO 11898-1:2015의 CAN FD는 CRC 필드 구성이 달라 두 방식이 상호 운용되지 않는다고 알려져 있다 (2차 지식, ISO 본문 미열람, 확인 필요). 실제 노드는 ISO 방식인지 확인해야 한다.

9.4.4 워크스루 I — 소형 멀티콥터 버스의 부하와 최악 응답 시간

CAN 메시지는 우선순위로 경쟁하고 프레임은 중간에 선점되지 않으므로 응답 시간을 계산할 수 있다. 결론은 최고 우선순위 메시지의 지연은 부하가 아니라 차단 시간이 정하고, 낮은 우선순위의 지연은 부하와 비트율에 따라 커진다는 것이다. 분석은 Tindell의 방법을 바로잡은 Davis 등(2007)의 수정판이다(저자 발표 자료에서 식을 읽었다). 원래 분석은 첫 인스턴스의 응답 시간만 구해, 한 인스턴스의 비선점 전송 때문에 다음 인스턴스가 추가 간섭을 받는 경우를 놓쳐 응답 시간을 낙관적으로 계산했다. 수정판은 메시지 $m$의 바쁜 구간 길이 $t_m$과 인스턴스 $q$의 시작 지연 $w_m(q)$를 구한다.

$$t_m = B_m + \sum_{k \in hp(m) \cup m} \left\lceil \frac{t_m + J_k}{T_k} \right\rceil C_k, \qquad R_m = \max_{q} \left( J_m + w_m(q) - q\,T_m + C_m \right)$$

$$w_m(q) = B_m + q\,C_m + \sum_{k \in hp(m)} \left\lceil \frac{w_m(q) + J_k + \tau_{\text{bit}}}{T_k} \right\rceil C_k$$

$B_m$는 낮은 우선순위 프레임 하나의 최대 길이(차단), $C_k$는 프레임 시간, $T_k$는 주기, $J_k$는 큐잉 지터이다. 이 장은 다중 프레임 전송(프레임들이 동시에 큐에 들어가 순서대로 나감)에 맞게 마지막 프레임의 시작 전에 같은 전송의 앞 프레임 시간을 더해 확장했다 (이 책의 확장).

가정(설명을 위한 값): 29비트 식별자, 우선순위 순서는 표의 위쪽이 높고, 지터 0, 최악 스터핑, 오류 없음. 전송 크기는 DroneCAN DSDL 정의의 비트를 센 값이다(RawCommand 4모터 $14\times4=56$ 비트, ESC 상태 110비트, Fix2 공분산 6개 496비트, BatteryInfo 모델명 20자 344비트, NodeStatus 56비트).

읽는 법: ESC 명령의 최악 응답 320 µs는 이미 전송 중인 낮은 우선순위 프레임 하나(160비트)와 자기 프레임(160비트)의 합이며 부하와 무관하다. 비트율을 절반으로 줄이면 부하가 두 배가 되어 낮은 우선순위의 응답 시간은 두 배를 넘고, 500 kbit/s에서 250 kbit/s로 내리면 최저 우선순위 메시지가 12.2 ms에서 37.7 ms로 3.1배가 된다. 오류 하나는 최대 31비트의 복구와 재전송 프레임(8 B 확장 160비트)을 더해 191비트, 곧 1 Mbit/s에서 191 µs, 500 kbit/s에서 382 µs를 추가한다. IMU 메시지(RawIMU 정의, 공분산 없음, 376비트)를 클래식 CAN으로 1 kHz 송신하면 7프레임이 필요해 한 대만으로 스터핑 없이 91.7 %, 최악 112.0 %이다. 고속 센서는 클래식 CAN 버스 하나에 맞지 않는다.

9.4.5 DroneCAN과 Cyphal — 전송 계층

9.4.5.1 DroneCAN

DroneCAN은 항공·로봇용 경량 프로토콜이며 사양서는 노드 ID가 있는 마스터 없는 대등 네트워크, 방송 메시지와 서비스 호출의 두 방식, 데이터 구조 기술 언어(DSDL)로 정의한 데이터 구조를 규정한다(1~3장). 사양서 라이선스 문구는 내용이 UAVCAN 개발팀의 선행 작업에 기반한다고 밝히며, DSDL 저장소에는 uavcan 표준 이름 공간과 ardupilot, ESC 제조사의 이름 공간이 있다(공개 저장소 목록). 전송 계층(4.1장)의 요점은 다음과 같다. 괄호의 장 번호는 DroneCAN 사양서의 장이다.

• CAN 2.0B(29비트) 프레임만 사용한다. 식별자는 우선순위 5비트, 메시지 형식 ID 16비트, 서비스 여부 1비트, 발신 노드 7비트이다(그림). 노드 ID는 1~127이며 126·127은 디버깅 도구용이다(5장).
• 데이터 필드의 마지막 바이트가 꼬리 바이트(시작·끝·토글 각 1비트, 전송 ID 5비트)이다. 클래식 CAN의 프레임당 페이로드는 7바이트이다.
• 페이로드가 넘치면 다중 프레임 전송이며 CRC-16-CCITT-FALSE(2바이트)를 첫 프레임 앞에 붙이고, 마지막 프레임을 제외한 모든 프레임은 데이터 필드를 가득 채운다. 전송을 1초 안에 마치지 못하면 중단한다.
• NodeStatus는 모든 노드가 주기적으로 송신하며 주기 상한은 1,000 ms, 3,000 ms 동안 없으면 오프라인이다(DSDL 341).
• 이중화 인터페이스는 모든 송신을 모든 인터페이스로 동시에 보내고 최대 3개이다(4.1장, 8장). 권장 비트율은 1,000·500·250·125 kbit/s이며 표본 시점은 87.5 %, 최대 스텁은 0.3 m이다(8장).
• 커넥터는 D-Sub, M8, JST GH 4극이며 버스 전원은 24 V 3 A 또는 5 V 1 A이다(8장).
• CAN FD 변형(4.4장)은 프레임 64바이트, 꼬리 배열 최적화 미사용, DLC 양자화를 따르며 공칭 1 Mbit/s에 데이터 구간 1·2·4·5·8 Mbit/s를 사용한다.
• 사양서에는 UDP(4.2장)와 MAVLink(4.3장) 전송 계층 장도 있으나 읽지 않았다 (확인 필요).

9.4.5.2 Cyphal

Cyphal 사양 v1.0(2025-05-16)은 CAN FD를 주 전송으로 정의한다(4.2). 괄호의 절 번호는 Cyphal 사양서의 절이다. 표준 이름 공간은 uavcan을 유지한다. 식별자는 우선순위 3비트(8단계: 예외·즉시·빠름·높음·보통·낮음·느림·선택), 주제 ID 13비트, 노드 ID 7비트이고 서비스에는 서비스 ID 9비트와 수신 노드가 있다(표 4.2·4.3). 단일 프레임 페이로드는 클래식 7바이트, CAN FD 최대 63바이트이다(표 4.1). 다중 프레임이면 페이로드 뒤에 0 채움과 CRC-16/CCITT-FALSE를 끝에 붙이고(4.2.2), CAN FD는 DLC 간격에 맞춰 0으로 채운다. Cyphal/CAN은 CAN 2.0B 프레임을 사용하지 않는 다른 CAN 프로토콜과만 같은 버스에 공존한다(4.2.1)고 밝히므로 2.0B를 사용하는 DroneCAN과는 공존하지 못한다.

Cyphal/UDP(4.3, 실험적)는 IP 멀티캐스트만 사용하고 UDP 데이터그램 하나가 전송 프레임 하나이다. 헤더는 24바이트, 모든 전송에 CRC-32C 4바이트가 붙으며 노드 ID는 16비트이다. MTU를 508바이트 이상으로 권고하므로 단일 프레임 페이로드가 480바이트($508-24-4$)이다(4.3.5). Cyphal/serial(4.4)도 실험적이다. 사양서는 정보 보안과 보안 관련 사항이 이 사양의 범위 밖이라고 밝힌다(5.3.13의 각주 133).

DroneCAN과 Cyphal/CAN을 비교하면 같은 CAN 2.0B 위에서 식별자 배치, 우선순위 단계(32 대 8), 단일 프레임 토글 비트(0 대 1), CRC 위치(앞 대 뒤)가 모두 다르다. 두 사양서 어디에도 상호 호환의 주장이 없으며 이 책의 비교로는 서로 해석할 수 없다. Cyphal의 계보는 uavcan 이름 공간과 저작권 표기(2015~2025)에서 추정하며 확인하지 못했다 (추정).

9.4.6 워크스루 II — 전송 분할의 오버헤드

DroneCAN·Cyphal은 큰 구조를 자동으로 프레임으로 나누므로 응용은 프레임을 의식하지 않는다. 그러나 분할은 시간과 대역으로 돌아온다. 아래는 DroneCAN DSDL 정의에서 비트를 센 크기와 분할 결과이다. 마지막 필드인 가변 배열(RawCommand, BatteryInfo의 모델명, RawIMU의 공분산)은 길이 필드를 생략하는 꼬리 배열 최적화를 적용해 센 값이다. 이 최적화는 배열이 마지막 필드이고 항목이 8비트 이상일 때만 가능하다(사양서 3장). Fix2의 공분산은 마지막이 아니므로 길이 필드 6비트를 더했다. CAN FD 열은 같은 바이트 수를 Cyphal/CAN의 CAN FD 규칙(63 B 단일 프레임)으로 보낸 가상 비교이다. DroneCAN의 CAN FD 변형은 꼬리 배열 최적화를 사용하지 않고(4.4장) Cyphal의 직렬화도 다르므로 실제 크기는 달라진다 (확인 필요).

도해의 값에서 읽는 것은 세 가지이다. 첫째, 클래식 CAN의 유효 페이로드 속도는 7 B(427.5 kbit/s)에서 8 B(278.3 kbit/s)로 한 바이트 차이로 35 % 떨어진다. 8 B부터 CRC 2 B와 프레임이 하나 더 생기기 때문이다. 둘째, GNSS 해 62 B는 클래식에서 10프레임, 1,262 µs이고 CAN FD에서는 한 프레임, 184.25 µs이다. 셋째, CAN FD도 63 B에서 64 B로 넘어가면 프레임이 둘이 되어 2.74 Mbit/s에서 2.07 Mbit/s로 떨어진다. 메시지 크기는 프레임 경계를 기준으로 설계해야 한다. Cyphal/UDP로 같은 62 B를 보내면 전선 위에서 156 B이고 100 Mbit/s에서 12.48 µs이다(UDP 8 B·IPv4 20 B·이더넷 38 B와 헤더 24 B·CRC 4 B를 포함한 계산).

9.4.7 ARINC 429 — 단방향 워드 버스 (2차 출처)

ARINC 429(Mark 33 DITS)는 상용 항공기의 LRU(교체 가능 장치) 사이에서 디지털 데이터를 보내는 규격이며, 송신기 하나가 같은 선쌍에 연결된 수신기 1~20개로 계속 송신하는 단방향 방송 버스이다. 수신기는 응답하지 않고 양방향이 필요하면 선쌍을 하나 더 둔다. 속도는 저속 12.5 kbit/s(허용 12~14.5 kbit/s)와 고속 100 kbit/s(±1 %)이며 한 선에 섞을 수 없다. 신호는 양극성 영 복귀(RZ)이고 송신 전압은 HIGH $+10\pm1$ V, NULL $0\pm0.5$ V, LOW $-10\pm1$ V이다. 케이블은 78 Ω 차폐 꼬임선이고 최대 길이는 규정하지 않으며 대부분 150 ft 이하로 설계한다(AIM 튜토리얼 2010, AIM 프로그래머 안내서 1장).

워드 사이에 최소 4비트 시간의 0 V 간격이 있어 별도 클록이 필요 없다. 규격은 오류 정정이 없고 검출(패리티)만 있다. 워드 시간과 갱신 주기는 다음과 같다(가정은 간격을 최소값으로 한 연속 송신).

송신기가 레이블 40개를 20 ms 주기(50 Hz)로 순서대로 보내면 한 주기에 14.40 ms, 곧 72 %를 차지하고 첫 레이블과 마지막 레이블 사이에 14.04 ms의 시차가 생긴다. 저속에서는 20 ms 안에 6개($6\times2.88=17.28$ ms)까지만 들어간다. 레이블별 최소·최대 송신 주기는 규격 부속서가 정하므로 이 장은 읽지 못했고 (확인 필요), 판은 확인해야 한다(9.1.7).

9.4.8 MIL-STD-1553 — 명령·응답 버스 (원문, 버스 기술 표준으로만)

1553은 버스 컨트롤러(BC)만 송신을 시작하는 비동기 명령·응답 반이중 버스이다(4.2). BC가 아닌 단말은 원격 단말(RT)이며 BC의 명령에 응답한다(3.15). 괄호의 조항 번호는 MIL-STD-1553C의 것이다. 모든 메시지는 명령 워드, 데이터 워드, 상태 워드 세 종류로 구성된다. 변조는 맨체스터 II 양위상 레벨이며 비트율은 1.0 Mbit/s ±0.1 %이다(4.3.3.2~4.3.3.3). 워드는 16비트에 동기 파형 3비트 시간과 홀수 패리티를 더한 20비트 시간(20 µs)이다(4.3.3.4). 동기 파형은 일부러 맨체스터 규칙을 위반해 데이터와 구별한다(4.3.3.5.1.1).

메시지 형식은 BC→RT, RT→BC, RT→RT와 모드 명령, 선택적 방송이다(4.3.3.6). 메시지 사이 간격은 최소 4.0 µs, RT 응답은 4.0~12.0 µs, 응답 없음 판정은 14.0 µs 이상이다(4.3.3.7~4.3.3.9). 단말은 800 µs를 넘는 연속 송신을 막는 하드웨어 시한을 갖는다(4.4.1.3). 최대 RT는 31개(주소 0~30)이다. 전기 규격은 70~85 Ω 차폐 꼬임 케이블(30 pF/ft 이하), 양 끝 종단 저항 Zo ±2 %, 변압기 결합 스텁 20 ft 이하(권고, 1:1.41, 격리 저항 $0.75 Z_0$), 직접 결합 스텁 1 ft 이하(55 Ω), 단말 출력 18~27 V 피크 대 피크이다(4.5.1~4.5.2). 이중화는 두 버스 중 하나만 활성인 이중 대기이고 버스 사이 격리는 45 dB 이상이다(4.6). 사양은 구현이 STANAG 3838이라고 밝힌다(6.5). 1553C는 표지에서 1553B를 대체한다고 밝히며, 두 판에서 대조한 값(1.0 Mbit/s, 4.0·12.0·14.0 µs, 800 µs, 30 pF/ft, $0.75 Z_0$, 1:1.41, 32워드)은 같았다. 사본 제공자의 안내문은 기능 변경이 없는 문서 개정이라고 한다 (2차 출처).

워드 20 µs와 응답 시간으로 메시지 시간을 계산한다. 가정: 응답 시간 4~12 µs, 메시지 간격 4 µs.

20 ms 소프레임에는 32워드 BC→RT 메시지가 최대 28개 들어간다. RT 10개가 8워드를 송신·수신하는 메시지를 50 Hz로 주고받으면 4.32 ms, 곧 21.6 %이다. 부록 A.1.3은 대역폭 400 Hz 이하의 신호가 버스에 적합하고 영상·음성·고속 병렬 신호는 제외하라고 한다. 오류 검출은 패리티뿐이며 사양은 실제 시스템에서 검출되지 않은 비트 오류율 $10^{-12}$를 기대한다고 밝히고 더 높은 무결성이 필요하면 신호 쪽에서 부호화하라고 권한다(A.1.4). 방송은 닫힌 루프 제어가 없는 형식이어서 가급적 사용하지 말라고 한다(A.1.6).

9.4.9 ARINC 664 Part 7(AFDX)과 TSN — 이더넷의 결정성

9.4.9.1 AFDX — 가상 링크로 대역을 예약한다

AFDX는 ARINC 664 Part 7을 구현한 전이중 스위치 이더넷이며 UDP·IP를 사용하고 100 Mbit/s(10 Mbit/s도 있음)로 동작한다(AIM 2010, 2차 출처). 핵심은 가상 링크(VL)이다. VL은 한 종단에서 하나 이상의 종단으로 가는 단방향 논리 연결이고 목적지 MAC 주소의 하위 16비트가 VL 식별자이다. VL마다 두 변수가 정해진다. BAG는 프레임 사이 최소 간격이며 $2^n$ ms($n=0\sim7$, 1~128 ms), Lmax는 최대 이더넷 프레임 길이(64~1518 B)이다. 종단이 BAG에 맞춰 송신을 정형하고, 스위치가 BAG와 프레임 크기를 감시한다. 두 독립 네트워크(A·B)에 같은 프레임을 동시에 보내고 수신 종단은 순서 번호로 먼저 도착한 유효 프레임을 채택한다(AIM).

VL 하나의 최대 대역은 $(L_{\max}+20)\times8/\text{BAG}$이다. 최소 프레임 84 B는 6.72 µs, 최대 프레임 1538 B는 123.04 µs이다(Gutiérrez 등). 종단 출력 지터는 ARINC 664 Part 7이 아래 두 식으로 제한한다(Gutiérrez 등이 인용한 식).

$$\text{MaxJitter} \le 40\ \mu\text{s} + \frac{\sum_{i}(20 + L_{\max,i})\times 8}{N_{bw}}, \qquad \text{MaxJitter} \le 500\ \mu\text{s}$$

BAG 8 ms인 메시지가 종단에서 겪는 지연의 허용 상한은 $\text{BAG}+\text{MaxJitter}+L_T=8+0.5+0.15=8.65$ ms이다(종단 기술 지연 $L_T\le150$ µs). 이 상한은 규격의 허용치이지 측정값이 아니다. 큐잉 포트는 8 KB 이상을 관리하고 샘플링 포트는 새 메시지가 이전 메시지를 대체한다(ARINC 653 포트). 스위치는 저장 후 전달이므로 홉마다 해당 프레임의 전송 시간(최대 123.04 µs)이 더해진다.

9.4.9.2 TSN — 표준 이더넷에 시간 보장을 더한다

TSN은 IEEE 802.1 TSN 작업반의 표준 묶음이다(작업반 페이지). 구성은 다음과 같다. 802.1AS는 시간 동기(홉 7개 이내에서 1 µs 미만, 서베이)이고, 802.1Qav의 신용 기반 정형기(CBS)는 AVB 프로파일에서 7홉 이내 클래스 A 2 ms를 보장한다. 802.1Qbv의 시간 인지 정형기(TAS)는 포트마다 8개 큐의 게이트를 게이트 제어 목록으로 주기적으로 열고 닫는다. 802.1Qbu의 프레임 선점은 급행 프레임이 선점 가능 프레임을 끊게 한다. 802.1Qci는 스트림별 필터링·감시, 802.1CB의 FRER는 프레임 복제·제거로 이중화한다. Qbv·Qbu·Qci·Qch는 802.1Q-2018에 통합되었고 AVB 시기의 Qav·Qat도 802.1Q-2018의 일부이며, 현재 기준판은 802.1Q-2022이다(작업반 페이지). IEEE 802.1DP-2025 / SAE AS 6675는 항공 탑재 이더넷의 TSN 프로파일로 2025-11-07에 발행되었고 상태는 유효 표준이다(IEEE SA). 본문은 열람하지 못했다 (확인 필요).

TAS에서 프레임은 게이트가 닫히기 전에 끝날 수 있을 때만 송신되므로 창 앞에 최대 프레임 시간의 보호 대역이 생긴다. TSN 최대 프레임은 IFG·프리앰블을 포함해 1542 B이고, 프레임 선점을 사용하면 선점할 수 없는 최대 길이가 123 B(최소 조각 64 B에서 체크 시퀀스 4 B를 뺀 60 B + 63 B)여서 보호 대역을 123 B 시간으로 줄일 수 있다(Stüber 등). 시간 구동(TT) 프레임은 주기적으로 송신하는 실시간 스트림의 프레임이다. 주기 1 ms, 128 B TT 프레임 10개, 창 하나(가정)로 계산한다. 비실시간 몫은 주기에서 TT 창과 보호 대역을 뺀 비율이다.

9.4.10 보안·안전 한계 — 인증이 없는 버스 (8.11~8.13 연결)

원문이 규정하는 것과 규정하지 않는 것을 구분해야 한다. Bosch CAN 2.0이 "security"와 "safety"라고 부르는 것은 전송 오류에 대한 보호이며(Part A p.4, Part B p.39) 사이버 보안이 아니다.

결론은 버스에 연결되는 것 자체가 신뢰이다. 버스에 물리적으로 연결된 노드(침해된 센서, 정비 도구)는 DroneCAN의 재시작·펌웨어 갱신 서비스와 CAN의 우선순위 점유를 이용할 수 있다. 설계는 버스 게이트웨이의 서비스 허용 목록, 갱신 서비스의 서명 검증(8.13.5의 SP 800-193 틀), 비행 제어 경로와 임무 경로의 분리(8.11.6)로 보완해야 한다. 안전 측면은 단일 고장점 분석이 필요하다. AFDX 스위치의 감시는 오작동 노드가 다른 VL의 대역을 침범하는 것을 막지만 CAN에는 대응하는 장치가 없다 (이 책의 해석). 공통 종단·전원·배선은 이중 버스에서도 공통 원인 고장이다(2.5).

9.4.11 규격 비교 — 속도와 용도

9.4.12 설계 트레이드오프 — 버스의 선택

1. ① 단일 CAN 계열 버스(DroneCAN 또는 Cyphal/CAN)로 센서·ESC·전원을 연결한다. 장점은 배선과 질량이 최소이고 노드 추가가 쉬우며 대등 구조여서 마스터 고장이 없다는 점이다. 단점은 대역이 제한되어 고속 센서를 싣지 못하고(RawIMU 한 대를 1 kHz로 보내면 91.7 %), 낮은 우선순위의 최악 응답이 부하와 함께 늘며, 인증이 없다는 점이다. 비인증 소형 UAS에 맞는다.
2. ② 이중 CAN 버스로 비행 제어 경로를 분리한다. 장점은 한 버스의 단락·종단 고장을 견디고(DroneCAN은 모든 송신을 모든 인터페이스로 동시 송신), 중요 장치와 비중요 장치를 우선·예비 버스로 나눌 수 있다는 점이다. 단점은 노드마다 커넥터가 둘이고 공통 전원·배선 침해는 막지 못한다는 점이다. 인증을 목표로 하는 중형 UAS·AAM의 초기 설계에 맞는다.
3. ③ 이더넷 코어(AFDX 또는 TSN)에 CAN 말단을 붙인다. 장점은 영상·임무 데이터와 제어 데이터를 하나의 인프라에서 보장 대역으로 다루고, TSN은 항공 프로파일(802.1DP)이 생겼다는 점이다. 단점은 스위치가 새 단일 고장점이고 구성 검증(스케줄 합성, 지터 한계)이 무거우며 소형 UAS의 질량·전력에 맞지 않는다는 점이다. 대형 UAS와 AAM에 맞는다.

견해: 소형 UAS는 ①로 시작하되 고속 센서(IMU, 영상)는 버스에서 분리하고, 인증 대상 기체는 ②를 기본으로 하며 임무 데이터가 늘면 ③을 코어로 둔다. 근거는 계산이다. RawIMU 한 대를 1 kHz로 보내면 클래식 CAN의 91.7 %를 차지하고(9.4.4), 1 Mbit/s 클래식 CAN의 62 B 메시지는 1,262 µs이다. 반면 802.1DP는 2025-11-07 발행으로 이력이 짧고 본문을 읽지 못했다. 이것은 이 책의 견해이며, 선택은 인증 기관이 요구하는 입증 방법(8.8·8.4)과 공급망에 따른다.

9.4.13 세 축 비교

9.4.14 관련 규격·프로토콜

전체 지도는 A.6에 있다. 문서의 판과 접근성의 층은 9.1이 다룬다.

9.4.15 관련 규제·인증 요구와의 연결

• 고장 조건과 다중화(2.5·8.4). 버스의 단일 고장점(종단, 커넥터, 공통 전원, 스위치)은 안전성 평가의 입력이다.
• 소프트웨어·하드웨어 보증(8.8). 버스 컨트롤러와 FPGA는 DO-254 등의 대상이 될 수 있으며 적용은 개발 보증 수준에 따른다 (확인 필요).
• 환경·전자기 적합성(8.9·8.10). 버스 케이블의 차폐·종단·스텁은 EMC 시험에서 실패하는 대표 지점이다. 1553은 배선·케이블의 EMC에 MIL-STD-464를 적용하라고 한다(4.5.1.5.3).
• 보안(8.11·8.12·8.13). 버스 위의 갱신·재시작 서비스는 감항 보안 위협 분석의 대상이고 제품 보안의 갱신 신뢰 루트가 필요하다.
• 체계 통합과 형상 관리(8.3·8.22). 메시지 집합(ID, 주기, 크기)이 인터페이스 제어 문서의 핵심이며 변경은 응답 시간 분석을 다시 요구한다.
• 비행데이터 기록(8.23). 버스 트래픽 로그는 사고 조사의 근거이며 1553의 버스 모니터가 예이다(4.4.4).
• 규격 문서의 사용(9.1·9.23). 판 확인과 적합성 시험은 두 장이 다룬다.

9.4.16 함정과 한계

미해결 문제. CAN FD의 ISO 방식과 Bosch 방식의 차이, ARINC 429·664·825와 802.1DP의 본문 요구, 인증 기관이 TSN·CAN 계열 버스를 입증하는 방법, 이중 CAN의 공통 원인 고장 분석, 버스 인증(서명)을 DroneCAN·Cyphal에 도입하는 설계는 이 장의 자료로 답할 수 없다 (확인 필요).

9.4.17 체크포인트·연구 질문

체크포인트:

1. 표준 프레임 데이터 8 B의 스터핑 없음과 최악 비트 수를 구하고 1 Mbit/s에서 페이로드 비율을 계산하라.
2. 500 kbit/s, 표본 시점 87.5 %, 비트당 16 양자, 트랜시버 지연 150 ns, 케이블 5 ns/m에서 최대 버스 길이를 구하라.
3. 9.4.4의 표에서 ESC 명령의 최악 응답 시간이 부하에 거의 무관한 이유를 차단 시간으로 설명하라.
4. DroneCAN으로 14 B와 62 B를 보낼 때 클래식 CAN의 프레임 수와 CAN FD(Cyphal)의 프레임 수를 구하라.
5. 1553에서 32워드 BC→RT 메시지의 시간 범위와 20 ms 소프레임에 들어가는 최대 개수를 구하라.
6. AFDX 종단에서 $L_{\max}=500$ B인 VL을 최대 몇 개 둘 수 있는가(한도 500 µs)?
7. 100 Mbit/s TSN에서 선점이 있을 때와 없을 때의 보호 대역과 비실시간 몫을 비교하라.

연구 질문(25.7에 모은다):

• DroneCAN·Cyphal에 송신자 인증과 서명된 갱신을 도입하려면 CAN의 8·64바이트 제약 안에서 어떤 설계가 가능한가.
• 소형 UAS의 메시지 집합에 대해 응답 시간 분석과 시험 측정은 얼마나 일치하는가.
• IEEE 802.1DP / SAE AS 6675 프로파일은 인증 기관이 요구하는 입증 방법과 어떻게 연결되는가.
• 클래식 CAN 버스 하나로 보낼 수 없는 IMU 1 kHz 전송을 CAN FD와 이더넷 중 무엇으로 해결하는 것이 질량·전력·인증 면에서 유리한가.

1차 출처(이 장):

• Robert Bosch GmbH, CAN Specification Version 2.0 (1991-09) — Part A 1·8절, Part B 2·3·6·7·8·9절(p.36~64). 공개 사본(esd.cs.ucr.edu).
• F. Hartwich(Bosch), CAN with Flexible Data-Rate, iCC 2012, CAN in Automation — 2차 출처.
• DroneCAN 사양서(dronecan.github.io/Specification, 2025-08-26 생성본)의 1·2·3·4.1·4.4·5·8장과 DSDL 저장소(github.com/DroneCAN/DSDL)의 정의 파일.
• OpenCyphal, Cyphal Specification v1.0 (2025-05-16 개정) — 4.2, 4.3(개요·헤더·MTU), 5.3.13, 6.4.1. 공개.
• MIL-STD-1553C (2018-02-28), MIL-STD-1553B (1978-09-21) — DLA ASSIST 공개 승인 사본(Distribution A).
• R. Davis, A. Burns, R. Bril, J. Lukkien, CAN Schedulability Analysis: Refuted, Revisited and Revised, Real-Time Systems 35(3), 2007 — 저자 발표 자료(University of York)로만 읽음(2차 출처).
• AIM, ARINC 429 Tutorial v2.1 (2010)와 ARINC 429 Programmer's Guide V9.8.0 — 2차 출처.
• AIM, AFDX Workshop (2010-03)과 J. J. Gutiérrez, J. C. Palencia, M. González Harbour, Response time analysis in AFDX networks, Universidad de Cantabria — 2차 출처.
• IEEE 802.1 TSN Task Group 페이지(1.ieee802.org/tsn), IEEE SA의 802.1DP 표준 페이지와 TSN for Aerospace 안내문(2026), T. Stüber 외, A Survey of Scheduling Algorithms for the Time-Aware Shaper in TSN, arXiv:2211.10954v2 (2023-03-27).
• ISO 11898, ARINC 429·664·825, SAE AS15531, IEEE 802.1Q·802.1DP 본문 — 읽지 못함 (확인 필요).

다음 장: 9.5 — MAVLink: 메시지 구조·마이크로서비스·서명과 보안 한계로 간다. 이 장이 기체 안의 물리 버스와 전송 계층을 다루었다면, 9.5은 기체와 지상국 사이에서 가장 널리 사용되는 메시지 프로토콜의 구조와 서명의 한계를 본다.