통신 프로토콜 설계

• 센서 데이터를 담아 나르는 메시지 규격을 직접 설계하는 방법 — 기존 표준(UART·CAN 등)이 "전선 위의 규칙"이라면 그 위에 얹는 계층
• 자작 센서 보드·커스텀 장치와 통신할 때 반드시 필요한 기술
• 출제 포인트: 프레임 구조(시작–ID–길이–데이터–체크섬), 오류 검출 수단의 강도 비교, 엔디안, 폴링 vs 스트리밍, 대역폭 계산

메시지 프레임의 표준 해부도 (시험 단골)

바이트 스트림에서 "어디부터 어디까지가 한 메시지인지"를 구분하는 구조:

수신기는 "시작 바이트 탐색 → 길이만큼 수신 → 체크섬 검증 → 파싱"의 상태 기계로 구현된다 (→ 로봇센서 드라이버 구현).

오류 검출의 강도 사다리 (시험 단골)

• 패리티 비트: 1의 개수의 홀짝 — 1비트 오류만 검출, 2비트 오류는 놓침 (가장 약함)
• 체크섬(Checksum): 바이트 합 — 간단하지만 상쇄되는 오류 조합을 놓칠 수 있음
• CRC(순환 중복 검사): 다항식 나눗셈 기반 — 연속(버스트) 오류까지 강력 검출, 산업 표준 (CAN·이더넷 내장) — 가장 강함
• 검출 강도: 패리티 < 체크섬 < CRC. 오류 "정정"까지 하려면 ECC 계열이 필요하지만 센서 통신은 보통 검출 + 폐기/재요청으로 충분

데이터 인코딩의 결정 사항

• 바이너리 vs ASCII(텍스트): 바이너리는 작고 빠름(같은 값을 적은 바이트로), ASCII는 사람이 읽기 쉬움(디버깅 용이) — 대역 제한 환경은 바이너리가 정석
• 엔디안(Endianness) (시험 포인트): 다바이트 값의 바이트 순서 — 리틀 엔디안(하위 바이트 먼저) vs 빅 엔디안(상위 바이트 먼저, '네트워크 바이트 순서'). 양측이 다르면 0x1234가 0x3412로 읽힌다 — 프로토콜 문서에 반드시 명시
• 스케일링(고정소수점): 실수 25.37 ℃를 정수 2537(×100)로 보내고 수신 측이 나눔 — 부동소수점 없이 소수 표현, 대역 절약
• 부호(signed/unsigned)·단위(단위계 명시)도 문서화 대상

통신 방식의 설계

• 폴링(Polling, 요청–응답): 마스터가 물을 때만 답함 — 흐름 통제 쉬움, 왕복 지연·오버헤드
• 스트리밍(주기 송신): 센서가 정해진 주기로 계속 송신 — 지연 최소, 수신 측이 소화해야 함
• 이벤트 구동: 값이 변할 때·문턱 초과 시만 송신 — 대역 절약, "무소식 = 정상인지 고장인지" 모호 → 하트비트(주기적 생존 신호) 병행 (시험 포인트)
• 타임아웃·재시도: 응답 없음의 처리 규칙, 시퀀스 번호로 손실·중복 감지

대역폭 예산 계산 (계산 단골)

메시지 크기 × 전송 주기가 링크 용량 안에 들어야 한다.

• 예: 20바이트 메시지를 100 Hz로 → 20 × 100 = 2,000 B/s = 16 kbps (스타트·스톱 비트 등 오버헤드 별도)
• UART 115200 bps 링크라면 실효 대역의 일부만 사용 — 여유(마진)를 남기는 것이 원칙. 꽉 채우면 지터·손실이 생긴다

프로토콜의 문서화와 진화

• 프로토콜 명세서 = 센서판 ICD (→ 로봇 시스템 통합 설계): 프레임 구조, 필드 정의(단위·스케일·엔디안), 시퀀스, 오류 처리 규칙
• 버전 필드와 예약(Reserved) 필드: 미래 확장을 위해 미리 확보 — 버전 불일치 감지로 구버전 장치와의 혼선 방지
• 설계 검증: 프로토콜 시뮬레이터·패킷 캡처로 문서와 구현의 일치 확인 (→ 로봇 시스템 평가절차)

메시지 프레임 구조

flowchart LR
    SOF["시작 바이트
0xAA 0x55"] --> ID["ID/주소"] --> LEN["길이"] --> PAY["데이터
(측정값·스케일링)"] --> CRC["체크섬/CRC"]

수신 파서의 상태 기계

flowchart LR
    W["시작 바이트 대기"] -- SOF 발견 --> H["헤더(ID·길이) 수신"] --> D["길이만큼 데이터 수신"] --> C{"체크섬 일치?"}
    C -- 예 --> P["파싱·발행"] --> W
    C -- 아니오 --> X["프레임 폐기·오류 계수"] --> W

1. 센서 메시지 프레임에서 수신 측이 "데이터부를 어디까지 읽어야 하는지" 알게 해 주는 필드는?

① 시작 바이트 ② 길이(Length) 필드 ③ 체크섬 ④ 예약 필드

2. 오류 검출 능력이 강한 순서로 옳게 나열한 것은?

① 패리티 > 체크섬 > CRC ② CRC > 체크섬 > 패리티 ③ 체크섬 > CRC > 패리티 ④ 세 방식 모두 동일하다

3. 16비트 값 0x1234를 리틀 엔디안으로 전송할 때 바이트 순서는?

① 0x12, 0x34 ② 0x34, 0x12 ③ 0x21, 0x43 ④ 0x43, 0x21

4. 이벤트 구동(값 변화 시에만 송신) 방식의 센서에서 하트비트를 병행하는 이유는?

① 대역폭을 더 쓰기 위해 ② 값이 오래 안 변할 때 "정상 침묵"과 "고장 침묵"을 구별하기 위해 ③ 체크섬을 대신하기 위해 ④ 엔디안을 통일하기 위해

5. 50바이트 메시지를 200 Hz로 전송하는 센서의 데이터율은? (오버헤드 무시)

① 1 kB/s ② 4 kB/s ③ 10 kB/s ④ 100 kB/s

• 로봇센서 인터페이스 — 프로토콜이 달리는 물리적 길
• 로봇 구성 요소 간 통신 프로토콜 — 표준 프로토콜·오류 검출의 기초
• 로봇센서 드라이버 구현 — 프레임 파서의 구현
• 로봇 시스템 통합 설계 — ICD와 인터페이스 합의
• 로봇과 IoT디바이스 연동 — 상위 네트워크 프로토콜과의 연결
• _MOC 지능소프트웨어