자율주행 셔틀: FSM 제어와 시스템 진단

인천공항 공식 홈페이지 https://www.airport.kr/ap_ko/6697/subview.do

01. 개요

참여 기간과 역할

2024년 11월부터 2025년 4월까지 웨어러블에이아이에서 차량 시스템 엔지니어로 근무하며 인천국제공항 제2여객터미널 자율주행 셔틀 도입 및 시범 운행 프로젝트에 참여했습니다.

담당 범위

차량 2D 라이다 디버깅 툴, 차량의 상태 머신(FSM)과 Watchdog Fail-safe 모듈을 개발했습니다.

02. 주행 시나리오 기반 FSM

승객 탑승, 대기, 주행, 비상 상황 등 공항 셔틀 운행 시나리오를 기반으로 차량의 상태와 transition 조건들을 정의해. C++ / ROS2 기반 최상위 제어 로직을 구현했습니다.

상태별 책임과 전이 조건을 분리한 FSM 설계
모든 운행 상태에서 즉시 비상 정지로 전환할 수 있는 전역 상태 전이 구성
안전 조건을 충족한 뒤 운행 흐름으로 복귀할 수 있는 양방향 비상 정지 구조 설계

Why?

SLAM, Vision, Object Recognition 등 여러 모듈의 역할을 묶고 효율적으로 작동하게 해 줄 커맨드 센터가 필요.
승객이 운행 중 갑자기 내리거나, 앞을 가로막는 등, 발생할 수 있는 비상 상황에서 위험을 최소화
시나리오에서 파생될 수 있는 일들을 시스템적으로 제한해 예측할 수 있는 운행 보장

How?

센서들의 데이터만으로 어떻게 차량에서 일어나는 일들을 정의해야 하는가?
- 예 : 좌석 센서가 작동한 것 만으로도 승객이 탑승한 것을 보장할 수 있는가?
거대하고 복잡해질 수 있는 상태와 전이 조건들을 어떻게 관리해야 하는가?

Solution

State와 Transition을 각각 클래스로 분리하고, 센서 데이터가 정의된 조건을 충족하면 ROS2 이벤트를 발행했으며, FSM은 현재 State에서 해당 Transition이 허용되는지 검사한 뒤 상태를 변경하도록 구성했음.
비상 정지를 모든 운행 상태에서 진입할 수 있는 전역 상태로 두고, 위험 해소와 제어 권한 재확보 조건을 모두 충족한 뒤에만 운행 상태로 복귀하도록 했음.

03. Watchdog Fail-safe

차량 모든 모듈과 센서들의 heartbeat를 감시하고, 이상 상태를 차량 정지까지 연결하는 Watchdog Fail-safe 모듈 구현

Why?

각 모듈들은 서로 다른 시점에 언제든 고장 날 수 있어, 사고를 미연에 방지하기 위해 모든 모듈들의 정상 상태가 보장되어야 했음
Timeout이 너무 짧으면 순간적인 통신 지연에도 정지하고 너무 길면 실제 장애 이후에도 운행 명령이 유지될 수 있었음
동선 상 벽에 닿지 않을 초음파 등 운행해도 괜찮은 센서들 구분도 필요했음

How?

Heartbeat 누락과 모듈이 직접 보고한 warning / error를 어떤 기준으로 장애로 판단할지 고민했음.
감지한 장애를 log로만 남기지 않고 하드웨어 제어 권한 회수와 비상 정지까지 어떻게 연결할지?

Solution

각 모듈의 heartbeat 수신 결과를 Sliding Window algorithm으로 확인해 일시적인 누락과 연속 장애를 구분하고, warning / error 상태와 함께 생존 여부를 판정.
장애물 근접 warning이나 module error가 발생하면 하드웨어 제어 권한을 회수하고 FSM을 비상 정지로 전환.
Timeout과 연속 누락 기준의 측정 조건 및 수치가 남아 있지 않아 정지 응답 시간은 성과로 주장하지 않음.

04. 센서 데이터 처리 및 네트워크 통신

32kHz 샘플링 주파수와 600RPM 사양의 2D LiDAR Raw Data를 visualize, 명령, 모니터링 가능한 비동기 QT 툴 개발

프로토콜 문서 기반으로 소켓 통신을 통해 LiDAR 패킷 송/수신
RViz보다 빠른 개별 visualize 및 고유 패킷 명령 가능

05. 설계 과정에서 고민한 점들

프로젝트를 회고하며 실제 구현 범위에서 중요했던 판단 기준을 다음과 같이 정리했습니다.

수신한 센서 데이터를 언제 신뢰할 것인가

UDP는 전송 지연이 짧은 대신 패킷의 도착과 순서를 보장하지 않습니다. 따라서 데이터를 받았다는 사실과 제어에 사용할 수 있다는 판단을 분리해야 했습니다. 패킷 길이와 헤더, 측정 범위, 시간 정보의 유효성을 확인하고, 오래되거나 불완전한 프레임이 인지 계층으로 전파되지 않도록 수신, 해석, 사용 단계를 나누는 방향을 검토했습니다.

비상 정지를 예외가 아닌 운행 상태로 다루기

상태마다 비상 정지 전이를 반복해서 넣으면 빠진 경로가 생기기 쉽습니다. 모든 상태에서 하나의 전역 비상 정지 상태로 진입하게 하고, 정지 원인이 해소됐다는 이유만으로 이전 명령을 다시 실행하지 않도록 복귀 조건과 제어 권한 재확보 조건을 분명히 두는 것이 중요했습니다.

빠른 장애 감지와 잘못된 정지 사이의 균형 잡기

생존 신호 제한 시간이 너무 짧으면 순간적인 통신 지연에도 차량이 멈추고, 너무 길면 실제 장애 이후에도 운행 명령이 유지될 수 있습니다. 모듈의 중요도, 연속 누락 횟수, 마지막 정상 메시지의 시각, 경고 단계를 함께 보고 정지 여부를 결정하는 기준이 필요했습니다.

일부 모듈의 고장을 차량 전체 안전으로 연결하기

SLAM, 인지, 센서 모듈은 서로 다른 시점에 고장 날 수 있습니다. 중앙 제어 계층은 현재 어떤 기능을 신뢰할 수 있는지 판단하고, 안전에 필요한 입력 하나라도 유효하지 않으면 하드웨어 제어 권한을 회수해야 합니다. 진단 메시지를 기록하는 데서 끝내지 않고 실제 정지 동작까지 이어지는 흐름을 설계한 이유입니다.

06. 프로젝트를 마치며

안정적인 차량 제어를 위해서는 정상 운행 절차뿐 아니라, 센서나 통신 입력을 신뢰하기 어려운 상황에서의 대응 방식까지 명확히 정의해야 합니다.

센서 데이터의 유효성, 상태 전이 조건, 분산 모듈의 고장 범위를 함께 살피고, 문제가 차량 전체로 전파되기 전에 안전 상태로 전환하는 기준들을 세웠습니다.

이 경험은 실시간 시스템을 개발할 때 기능 구현에 앞서 어떤 입력을 신뢰할지, 어느 계층에서 실패를 차단할지, 어떤 조건에서 제어 권한을 돌려줄지를 먼저 설계하는 기준이 되었습니다.