이 장에서 다룰 내용
- 산업용 제어보드 개발 흐름
- Rev1 설계와 초기 검증
- 현장 문제 분석
- Rev2 개선 설계
- 양산 전 검증과 고객 대응
- EFEM Loadport와 Pre-Aligner 제어보드
- 24V 산업용 I/O 및 RS-485 통신보드
- Jetson과 MCU를 결합한 Gateway 보드
15.1 사례의 배경
예를 들어 반도체 또는 자동화 장비 안에 들어가는 제어보드를 개발한다고 가정하자. 이 보드는 24V 입력을 받아 내부 5V와 3.3V를 만들고, NPN/PNP 센서 입력을 읽으며, Solenoid와 Lamp를 구동하고, RS-485로 상위 제어기와 통신한다. 펌웨어는 장비 상태를 관리하고 Error Code를 저장하며, 현장에서 업데이트 가능해야 한다.
Rev1에서는 기능 구현에 집중한다. 센서 입력이 읽히는지, 출력이 동작하는지, 통신이 되는지 확인한다. 하지만 실제 장비에 넣으면 전원 기동 시 Reset이 흔들리거나, 모터 동작 순간 RS-485 오류가 발생하거나, 외부 케이블을 꽂는 순간 MCU가 Reset되는 문제가 드러날 수 있다.
15.2 Rev1에서 자주 발생하는 문제
- 전원 입력 보호가 부족해 현장 전원 변동에 취약함
- Reset 회로가 단순해 기동 조건이 불안정함
- 외부 I/O 보호회로가 부족해 ESD에 취약함
- 통신 GND와 장비 GND 정책이 불명확함
- 펌웨어 로그가 부족해 현장 오류를 추적하기 어려움
- 생산 검사 포인트가 부족해 양산 불량을 빠르게 잡기 어려움
15.3 Rev2 개선 방향
Rev2에서는 기능 추가보다 구조 안정화가 중요하다. 전원 입력 보호를 강화하고, Power Good 기반 Reset을 넣으며, 외부 I/O에는 TVS와 필터를 추가한다. RS-485에는 절연 또는 Bias/Termination을 명확히 적용하고, 펌웨어에는 Error Log, Watchdog, 통신 Timeout, 복구 상태를 넣는다.
15.4 제품화 관점의 판단
좋은 Embedded Board는 개발실에서 한 번 동작한 보드가 아니라, 생산 라인에서 반복 검사 가능하고 고객 현장에서 원인 추적 가능한 보드다. 따라서 회로, 펌웨어, 생산 검사, 문서화가 함께 준비되어야 제품화가 가능하다.
15.6 사례 1: 24V 산업용 I/O 보드
개발 목적
24V 산업용 I/O 보드는 장비의 센서 입력과 구동 출력을 MCU가 안전하게 처리할 수 있도록 연결하는 보드다. 장비 안에서 사용되는 NPN/PNP 센서, Limit Sensor, Door Sensor, Vacuum Switch, Lamp, Relay, Solenoid는 MCU의 3.3V GPIO와 직접 연결할 수 없다. 따라서 외부 장비 신호와 MCU 사이에 보호, 변환, 필터, 구동 회로가 필요했다.
주요 구조
- DC 24V 입력과 내부 Logic 전원 생성
- 24V Digital Input 보호 및 Level 변환
- Solenoid, Relay, Lamp 구동용 출력 Driver
- Reset 중 출력 Off를 유지하기 위한 Pull-down과 Enable 구조
- 외부 커넥터 근처의 TVS와 필터
- 주요 전원과 I/O 측정을 위한 Test Point
개발 과정에서 확인한 문제
초기 기능 시험에서는 입력과 출력이 정상 동작했지만 실제 장비 Harness와 연결하면 센서 입력이 순간적으로 흔들리거나, Solenoid가 꺼지는 순간 MCU가 Reset되는 문제가 발생할 수 있었다. 원인은 단순한 펌웨어 오류가 아니라 고전류 출력의 Return Path, 역기전력, 입력 필터 시간, Logic 전원과 부하 전원의 연결 구조에 있었다.
개선 내용
입력에는 신호 특성에 맞는 RC Filter와 펌웨어 Debounce를 적용하고, 출력에는 Flyback 보호와 안전한 초기 상태를 추가한다. Logic 전원과 부하 전원 경로를 분리하고, 고전류 출력 GND가 MCU 기준 GND를 흔들지 않도록 Layout을 개선한다. 생산 검사에서는 Jig가 입력 신호를 순서대로 넣고 출력 Driver를 Dummy Load로 검사할 수 있게 한다.
실전 교훈
산업용 I/O 보드에서 중요한 것은 GPIO 개수가 아니라 외부 배선의 고장과 노이즈를 MCU 영역까지 들어오지 않게 막는 것이다.
15.7 사례 2: RS-485 기반 다중 노드 제어보드
개발 목적
장비 내부의 여러 모듈을 하나의 상위 Controller에서 관리하기 위해 RS-485 기반 통신보드를 구성했다. Loadport, Pre-Aligner, I/O Module, Sensor Module처럼 물리적으로 떨어진 모듈이 명령과 상태를 주고받을 때 RS-485는 배선과 비용 측면에서 실용적이다.
주요 구조
- MCU UART와 RS-485 Transceiver 연결
- Half-duplex 송수신 방향 제어
- Bus 양 끝의 Termination
- Idle 상태를 안정시키기 위한 Bias
- 외부 케이블 보호용 TVS
- 통신 환경에 따른 절연 검토
- Node ID와 Firmware Version 관리
개발 과정에서 확인한 문제
개발실의 짧은 케이블에서는 정상 동작했지만 실제 장비의 긴 Harness와 여러 노드가 연결되면 간헐적인 CRC Error와 Timeout이 나타날 수 있었다. 모든 보드에 종단저항이 들어가 Bus 부하가 커지거나, DE 신호를 너무 빨리 끄면서 마지막 Byte가 잘리는 문제도 발생할 수 있었다. 통신 오류를 단순히 재전송으로 가리면 장비 상태가 늦게 갱신되어 다른 문제로 이어졌다.
개선 내용
실제 Bus 구조를 기준으로 종단 위치를 정하고, Bias와 Shield 연결 정책을 문서화한다. Logic Analyzer로 UART TX와 DE 신호를 동시에 측정해 방향 전환 시간을 조정한다. 프로토콜에는 Sequence Number, CRC, Timeout, Retry, Heartbeat, Node Error 상태를 포함한다. 일정 시간 통신이 끊기면 출력이 안전 상태로 이동하도록 한다.
실전 교훈
RS-485 문제는 통신 IC 하나의 문제가 아니라 배선 구조, 종단저항, 방향 제어, 프로토콜 복구 정책이 함께 만드는 시스템 문제다.
15.8 사례 3: EFEM Loadport 제어보드
개발 목적
Loadport 제어보드는 EFEM에서 FOUP를 감지하고, Clamp와 Docking 상태를 확인하며, Door 동작과 Mapping 관련 신호를 상위 EFEM Controller와 연결하는 역할을 한다. 보드는 단순 출력 제어기가 아니라 여러 인터락 조건을 확인해 잘못된 순서의 동작을 막는 모듈 컨트롤러로 동작한다.
주요 입력과 출력
- FOUP 감지와 안착 상태 입력
- Door Open/Close 상태 입력
- Clamp와 Docking 상태 입력
- Mapping Sensor 및 관련 상태 입력
- Clamp, Door, Lamp, Buzzer 등 구동 출력
- 상위 EFEM Controller와의 통신
제어 구조
Loadport 동작은 IDLE, FOUP_CHECK, CLAMP, DOCK, DOOR_OPEN, MAPPING, READY, ERROR와 같은 상태로 나누어 관리할 수 있다. 각 상태에서는 필요한 센서 조건과 허용 출력이 다르다. 예를 들어 FOUP가 정상적으로 감지되지 않으면 Clamp 또는 Door 동작으로 넘어가지 않아야 한다.
통신이 끊겼을 때 현재 동작을 즉시 정지할지, 안전한 단계까지 완료한 뒤 정지할지도 정의해야 한다. Door와 Clamp 관련 출력은 펌웨어가 Reset되거나 통신이 끊겼을 때 임의로 유지되지 않도록 안전 상태를 설계한다.
검증 항목
- FOUP 유무와 센서 조합별 상태 판단
- Door, Clamp, Docking 동작 순서
- 인터락 Open 상태에서 출력 차단
- 통신 Timeout과 복구
- 전원 재인가 후 초기 상태
- 센서 단선 또는 비정상 조합 처리
- 생산 Jig를 이용한 입력과 출력 검사
실전 교훈
Loadport 보드의 품질은 출력이 움직이는가보다 잘못된 센서 조합과 잘못된 동작 순서를 얼마나 확실히 막는가로 판단해야 한다.
15.9 사례 4: EFEM Pre-Aligner 제어보드
개발 목적
Pre-Aligner 제어보드는 Wafer를 Chuck에 고정하고 회전시키며, Wafer의 중심과 Notch 또는 Edge 위치를 검출할 수 있도록 장비 동작을 관리한다. 이 보드는 Motor, Vacuum, Sensor, Edge 검출 모듈, 상위 EFEM Controller 사이의 상태를 연결한다.
주요 입력과 출력
- Wafer 존재 감지
- Chuck Vacuum 상태
- 회전축 Home Sensor
- Motor Driver Alarm과 Ready 상태
- Edge 또는 Notch 검출 결과
- Motor Driver Enable
- Vacuum Valve
- Illumination 또는 Sensor Power 제어
제어 구조
Pre-Aligner 동작은 WAFER_CHECK, VACUUM_ON, HOME, ROTATE, EDGE_SEARCH, ALIGN_COMPLETE, ERROR 같은 상태로 나눌 수 있다. Wafer가 감지되지 않거나 Vacuum이 충분하지 않으면 회전 동작을 시작해서는 안 된다. Motor Alarm이 발생하면 즉시 Enable을 해제하고 Error 상태와 입력 상태를 기록해야 한다.
Edge 또는 Notch 검출 기능을 별도의 FPGA나 Sensor Module이 담당하는 경우 MCU 보드는 검출 결과를 받아 전체 Sequence를 관리한다. Jetson이나 Vision PC가 위치 계산을 담당하더라도 Vacuum, Motor Enable, Interlock 같은 실시간 안전 조건은 MCU 보드가 직접 관리하는 구조가 안정적이다.
검증 항목
- Wafer 없음, Vacuum 실패 상태에서 회전 금지
- Home Sensor와 Motor Alarm 입력 처리
- Edge Sensor 또는 검출 모듈 통신
- 정렬 동작 중 Timeout 처리
- 상위 Controller 통신 끊김 시 안전 정지
- 반복 정렬 동작에서 상태 복구
- Motor 동작 중 전원과 통신 노이즈 측정
실전 교훈
Pre-Aligner 제어보드는 정렬 알고리즘만큼 Wafer를 안전하게 고정하고 회전 동작의 시작과 정지를 확실히 관리하는 구조가 중요하다.
15.10 사례 5: STM32 기반 장비 컨트롤러
개발 목적
STM32 기반 장비 컨트롤러는 센서 입력, 출력 제어, 통신, Error 관리, Firmware Update를 하나의 MCU 보드에서 처리하기 위해 개발한다. STM32 계열 MCU는 Timer, ADC, UART, SPI, I2C, CAN, Ethernet 등 장비 제어에 필요한 주변장치를 폭넓게 제공하므로 산업용 제어보드에 적용하기 좋다.
펌웨어 구조
펌웨어는 INIT, READY, RUN, STOP, ERROR, RECOVERY 상태를 중심으로 구성한다. Timer Interrupt는 주기 Tick을 만들고, UART와 RS-485 수신은 Ring Buffer에 저장하며, 실제 Command 처리와 상태 전이는 Main Loop에서 수행한다.
Bootloader는 Firmware Version과 CRC를 확인하고, 현장 통신을 이용해 업데이트할 수 있도록 구성한다. Application은 Reset Cause, Error Code, 통신 Timeout, 주요 입력 상태를 로그로 남긴다.
개발 과정에서 확인한 문제
기능이 늘어날수록 Main Loop 안에 조건문이 쌓이고, 특정 Error 상태에서 출력이 복구되지 않거나 통신 명령 순서에 따라 상태가 꼬이는 문제가 생길 수 있었다. Interrupt에서 너무 많은 일을 처리하면 통신과 주기 제어가 흔들릴 수 있었다.
개선 내용
Command와 Sensor 변화를 Event로 변환하고, 상태별 처리표를 작성한다. Error Code에 발생 조건, 출력 조치, 복구 조건을 연결한다. Watchdog은 단순히 주기적으로 갱신하지 않고 주요 Task와 상태 머신이 정상 실행된 경우에만 갱신하도록 한다.
실전 교훈
장비용 MCU 펌웨어는 코드 줄 수보다 상태와 책임 경계가 명확한지가 더 중요하다.
15.11 사례 6: Jetson과 MCU를 결합한 Gateway 보드 구조
개발 목적
영상 처리, AI 추론, 네트워크, 데이터 저장 기능이 필요한 장비에서는 Jetson Orin Nano 같은 Linux 기반 보드가 유용하다. 그러나 Jetson이 센서 입력, 인터락, Solenoid, Motor Enable까지 모두 직접 관리하도록 하면 부팅 시간과 운영체제 상태에 따라 장비 안전성이 영향을 받을 수 있다.
이 구조에서는 Jetson과 MCU 보드의 역할을 나눈다. Jetson은 영상 처리, AI 판단, UI, 네트워크, 데이터 저장을 담당하고, MCU 보드는 실시간 I/O, 안전 출력, Watchdog, 전원 상태, 상위·하위 통신을 담당한다.
주요 구조
- Jetson과 MCU 사이의 Ethernet, UART, CAN 또는 RS-485 통신
- MCU의 Jetson 전원 상태 감시
- Jetson Application Heartbeat 감시
- Jetson 재부팅 중 장비 출력 안전 상태 유지
- Camera와 Vision 결과를 장비 상태 머신에 전달
- OS와 MCU Firmware Version 관리
개발 과정에서 확인할 문제
Linux Application이 멈추거나 Jetson이 재부팅될 때 MCU가 이를 어떻게 판단할지 정해야 한다. 단순 통신 끊김만으로 즉시 모든 동작을 멈출지, 현재 기계 동작을 안전하게 완료한 뒤 정지할지도 정의해야 한다. 갑작스러운 전원 차단으로 파일시스템이 손상될 가능성도 고려해야 한다.
개선 방향
MCU는 Jetson Heartbeat를 감시하고 일정 시간 응답이 없으면 안전 상태로 전환한다. Jetson은 MCU의 상태와 Error Code를 읽어 상위 시스템에 전달한다. 전원 차단 전 안전 종료 신호를 보내거나 Read-only 파일시스템, 로그 저장 정책을 적용한다.
실전 교훈
고성능 Linux 보드를 추가하더라도 장비의 마지막 안전 책임은 실시간 제어가 가능한 MCU 보드에 남겨두는 것이 좋다.
15.12 여러 보드에서 반복된 공통 개선 항목
지금까지 개발한 보드는 적용 장비와 기능이 달랐지만 Rev 개선 항목은 반복되는 경향이 있었다.
| 구분 | Rev1에서 나타나기 쉬운 문제 | 개선 방향 |
|---|---|---|
| 전원 | 부하 동작 시 Reset, Ripple 증가 | 전원 경로 분리, Bulk Capacitor, Reset IC |
| 입력 | 센서 노이즈, 순간 오검출 | 보호회로, RC Filter, Debounce |
| 출력 | Reset 중 출력 켜짐, 역기전력 | Pull-down, Enable Gate, Flyback 보호 |
| 통신 | 간헐적 Timeout, CRC Error | Termination, Bias, Shield, 로그 |
| 펌웨어 | 상태 꼬임, 복구 불가 | State Machine, Error Code, Recovery |
| 생산 | 검사 누락, 불량 추적 어려움 | Test Point, Jig, Serial Number |
| 현장 대응 | 재현 어려움 | Reset Cause, Event Log, Diagnostic Command |
공통점은 기능을 더 넣어서 해결되는 문제가 많지 않았다는 점이다. 대부분은 책임 경계를 명확히 하고, 보호와 측정을 추가하고, Error 상태와 복구 조건을 문서화하면서 해결되었다.
15장 체크리스트
- Rev1 문제를 기능 문제와 구조 문제로 구분했는가?
- Rev2 개선 항목이 회로, Layout, 펌웨어, 검사로 나뉘어 있는가?
- 고객 현장 문제를 로그와 Error Code로 추적할 수 있는가?
- 양산 전 검사 지그와 테스트 펌웨어가 준비되었는가?
- Loadport와 Pre-Aligner의 안전 조건과 상태 전이를 구분했는가?
- Jetson과 MCU의 역할 분담 및 Heartbeat 정책을 정의했는가?
- 새 보드 개발 후 실전 사례 기록 템플릿을 작성했는가?