이 장에서 다룰 내용
- UART, RS-485, CAN, Ethernet의 용도 차이
- 통신 IC와 절연 설계
- 종단저항, Bias, Shield, GND
- 장비 내부 프로토콜 설계
- 통신 오류와 복구 정책
8.1 통신 방식 선택 기준
통신 방식은 속도만 보고 고르면 안 된다. 거리, 노드 수, 노이즈 환경, 실시간성, 배선 비용, 상위 장비와의 호환성을 함께 봐야 한다. 장비 내부 Debug에는 UART가 간단하고, 모듈 간 장거리 통신에는 RS-485가 많이 쓰이며, 분산 제어와 메시지 기반 통신에는 CAN이 유리하다. 대용량 데이터나 상위 시스템 연결에는 Ethernet이 적합하다.
EFEM 내부 Loadport나 Pre-Aligner 보드는 상위 EFEM Controller와 연결되어 명령과 상태를 주고받는다. 단순 명령/상태 교환이면 RS-485로 충분할 수 있고, 여러 모듈을 네트워크로 묶거나 진단 데이터를 많이 주고받아야 하면 Ethernet이 유리하다. Motor Driver나 다른 제어 모듈과 연결할 때는 CAN이 좋은 선택이 될 수 있다.
선정표에는 다음 항목을 넣는다.
| 방식 | 장점 | 주의할 점 | 적합한 용도 |
|---|---|---|---|
| UART | 단순, Debug에 유리 | 짧은 거리, Point-to-point 중심 | Console, 내부 모듈 |
| RS-485 | 장거리, 차동, 다중 노드 | 방향 제어, Bias, Termination 필요 | 장비 내부 모듈 통신 |
| CAN | 메시지 기반, 충돌 중재 | 프로토콜 설계 필요 | 모터, 분산 제어 |
| Ethernet | 고속, 상위 시스템 연결 | PHY, Magnetics, Stack 부담 | Controller, Gateway |
8.2 UART와 Debug Console
UART는 가장 단순한 직렬 통신이다. 개발 중 로그 출력, Command Console, 생산 검사에 매우 유용하다. MCU의 Bootloader 진입이나 Firmware Update에도 사용할 수 있다.
UART를 외부 커넥터로 뺄 때는 전압 레벨을 확인해야 한다. MCU UART는 보통 3.3V TTL이고, PC의 RS-232와는 전기적 레벨이 다르다. USB-UART Converter를 사용할 것인지, RS-232 Driver를 넣을 것인지, 내부 Debug용으로만 둘 것인지 정해야 한다.
Debug Console은 편하지만 제품에서는 신중해야 한다. 현장에서 잘못된 명령을 입력하면 장비가 위험해질 수 있으므로 Log 출력과 제어 명령을 구분하고, 생산 모드와 서비스 모드에서 권한을 다르게 두는 것이 좋다.
8.3 RS-485 설계
RS-485는 차동 신호를 사용해 노이즈에 강하고 비교적 긴 거리 통신에 적합하다. EFEM 내부의 Loadport, Pre-Aligner, I/O Module 연결처럼 여러 모듈을 묶는 데 자주 쓰인다. Half-duplex 구조에서는 송신과 수신 방향 제어가 필요하므로 MCU GPIO로 DE/RE Pin을 제어한다.
RS-485 설계에서 중요한 것은 Termination과 Bias다. Bus 양 끝에는 보통 120ohm 종단저항을 두고, Idle 상태가 안정되도록 Bias 저항을 사용한다. 모든 노드에 종단저항을 넣으면 Bus 부하가 커질 수 있으므로 실제 배선 구조를 기준으로 종단 위치를 정해야 한다.
외부 케이블로 나가는 RS-485는 ESD 보호와 절연을 검토한다. GND 차이가 큰 장비 간 연결에서는 절연 RS-485가 안정적이다. Shield Cable을 사용할 경우 Shield를 Chassis에 어떻게 연결할지도 정해야 한다.
8.4 CAN 설계
CAN은 여러 노드가 같은 Bus를 공유하면서 메시지 ID 기반으로 통신하는 방식이다. 충돌 중재와 오류 검출 기능이 있어 분산 제어에 유리하다. Motor Driver, I/O Module, Sensor Module처럼 여러 장치가 동시에 상태를 주고받는 구조에서 사용할 수 있다.
CAN Bus도 차동 신호이므로 종단저항이 필요하다. Bus 양 끝에 120ohm을 배치하고 Stub 길이를 짧게 유지한다. 통신 속도가 높을수록 배선 구조에 민감하다.
CAN 프로토콜을 설계할 때는 Message ID, 주기 메시지, 이벤트 메시지, Heartbeat, Error Frame 처리, Node ID 설정 방식을 정해야 한다. 단순히 CAN Transceiver를 넣는 것으로 끝나지 않고 시스템 통신 규칙을 함께 설계해야 한다.
8.5 Ethernet 설계
Ethernet은 상위 Controller, PC, 네트워크 장비와 연결하기 좋다. 진단 데이터, Log, Firmware Update, Web Interface 같은 기능을 넣기 쉽다. 하지만 PHY, Magnetics, RJ45, ESD 보호, Clock, Impedance Matching, Software Stack이 필요해 설계 부담이 커진다.
Ethernet PHY Layout은 데이터시트 권장 사항을 따라야 한다. Differential Pair 길이와 임피던스, Magnetics 위치, Chassis GND와 Shield 처리, ESD 보호 위치가 중요하다. RJ45가 외부에 노출되는 경우 정전기와 Surge를 고려한다.
소프트웨어 측면에서는 TCP/IP Stack, DHCP, 고정 IP, 통신 끊김 처리, 보안, Firmware Update 정책을 정해야 한다. 산업용 장비에서는 네트워크 설정이 현장 유지보수 이슈가 되므로 IP 설정과 진단 화면 또는 명령을 준비하는 것이 좋다.
8.6 장비용 프로토콜과 오류 처리
장비용 통신은 데이터 송수신보다 상태 관리가 중요하다. 상위 Controller가 명령을 보내고 보드가 응답하는 구조라면 Command ID, Sequence Number, Checksum 또는 CRC, Timeout, Retry, Error Code를 정의해야 한다.
Heartbeat는 통신 연결 상태를 확인하는 데 유용하다. 일정 시간 동안 Heartbeat가 없으면 보드는 통신 끊김으로 판단하고 안전 출력 상태로 전환할 수 있다. 단, 모든 통신 끊김을 즉시 정지로 처리할지, 현재 동작을 완료한 뒤 정지할지는 장비 위험도에 따라 정해야 한다.
프로토콜 문서에는 정상 명령뿐 아니라 오류 상황을 적어야 한다. 잘못된 Checksum, 지원하지 않는 Command, Busy 상태에서 들어온 명령, Sensor Error 상태에서 Run 명령이 들어온 경우를 정의한다. 이 정의가 없으면 펌웨어마다 임의로 처리해 장비 동작이 불안정해진다.
체크리스트
- 통신 거리, 속도, 노드 수, 노이즈 환경을 기준으로 방식을 선택했는가?
- RS-485와 CAN의 Termination, Bias, Shield 정책이 정의되었는가?
- Ethernet PHY Layout과 ESD 보호 위치를 데이터시트 기준으로 검토했는가?
- 통신 끊김과 재연결 상태를 펌웨어에서 정의했는가?
- Heartbeat, Timeout, Retry, Error Code가 프로토콜 문서에 포함되었는가?
- 현장에서 로그로 통신 오류를 추적할 수 있는가?