임베디드 워치독 설계: 멈춘 태스크를 감지하고 안전하게 복구하는 방법

현장 장비가 응답하지 않을 때 전원을 껐다 켜면 다시 동작하는 경우가 있습니다. 워치독은 이런 장애의 복구 수단이지만 설정을 켜는 것만으로 제품의 정상 동작이 보장되지는 않습니다. 핵심은 정상 동작의 판단 기준, 장애 감지 시간, 재시작 후 출력 상태를 함께 정의하는 것입니다. 아래 내용은 일반적인 설계 예시이며 특정 고객 장비의 시험 결과가 아닙니다.

1. 주기적인 갱신만으로는 업무 정지를 알 수 없습니다

타이머 인터럽트에서 워치독을 무조건 갱신하면 인터럽트는 실행되지만 센서 처리 태스크가 교착 상태에 빠진 상황을 놓칠 수 있습니다. LED 점멸이나 CPU 사용률도 업무 완료의 증거는 아닙니다. 센서 읽기 결과 처리, 제어 연산 완료, 통신 상태 머신의 유효한 전이처럼 실제 기능과 연결된 진행 지점을 정해야 합니다.

STM32U5 IWDG는 주 클럭과 독립된 LSI를 사용하며, 제한 시간 안에 카운터를 갱신하지 않으면 리셋을 발생시킵니다. 감시 대상 업무의 정상 여부는 애플리케이션이 판단해야 합니다. 저전력·윈도우·디버그 동작은 MCU와 옵션 설정에 맞춰 확인합니다. ST 공식 IWDG 설명

2. 필수 태스크의 진행 상태를 모아서 판단합니다

각 필수 태스크가 작업을 마친 뒤 완료 카운터와 마지막 진행 시각을 갱신하고, 감시 태스크가 각자의 허용 시간을 확인하는 구조를 고려할 수 있습니다. 모든 필수 조건이 충족될 때만 하드웨어 워치독을 갱신합니다. 과거에 한 번 설정한 정상 플래그를 재사용하지 않도록 새로운 진행인지 구분해야 합니다.

• 센서: 읽기 시도와 결과 처리가 끝났는지 확인합니다. 단선 오류를 정상적으로 처리한 상태와 드라이버가 무한 대기하는 상태를 구분합니다.

• 제어: 입력 검증과 출력 결정의 완료를 확인합니다. 반복문에 진입했다는 이유만으로 정상 표시하지 않습니다.

• 통신: 서버 연결 성공만을 요구하지 않습니다. 연결 실패 뒤 제한된 재시도와 대기 상태로 전환하는 것도 정상적인 진행입니다.

공유 카운터는 원자적 접근이나 짧은 임계 구역으로 일관되게 읽습니다. 시간 비교에는 단조 증가 시간 기준과 카운터 래핑 처리를 적용하고, 감시 코드 자체가 잠긴 뮤텍스를 무한히 기다리지 않게 합니다.

ESP-IDF는 특정 태스크와 작업 단위인 user를 TWDT 감시에 등록하는 API를 제공합니다. 기본 Idle 태스크 감시만으로 모든 업무의 교착 상태를 검출한다고 가정하면 안 됩니다. 타임아웃 뒤 경고만 출력할지, panic과 리셋으로 이어질지는 설정을 확인해야 합니다. Espressif 공식 Watchdogs 문서

3. 타임아웃은 정상 지연과 허용 장애 시간 사이에서 정합니다

타임아웃이 너무 짧으면 정상적인 플래시 작업이나 통신 지연에도 재부팅하고, 너무 길면 멈춘 상태가 오래 유지됩니다. 정상 동작의 최악 지연, 스케줄링 지터, 워치독 클럭 오차를 고려하면서 고객이 허용하는 장애 대응 시간을 만족해야 합니다.

계산 예시: 태스크의 무진행을 300ms 뒤 판정하고 감시 주기가 50ms라면 갱신 중단 결정까지 최악 350ms가 걸릴 수 있습니다. 이후 하드웨어 워치독의 실제 최대 잔여 시간을 500ms, 재부팅과 초기화를 200ms로 가정하면 보수적인 복구 시간 예산은 350 + 500 + 200 = 1,050ms입니다. 이 값은 설명용 가정이며 권장 설정이나 측정 결과가 아닙니다. 통신 재접속 시간이 필요하면 별도로 더해야 합니다.

이 예시에서 100ms 이내 출력 차단이 필요하다면 MCU 재부팅만으로 요구를 만족할 수 없습니다. 더 빠른 독립 차단 경로와 하드웨어 인터록을 검토해야 합니다. ST 문서에서 설명하듯 LSI 편차는 실제 타임아웃에 영향을 주므로 명목값 하나로 상한을 확정하지 않습니다.

4. 재부팅 뒤 출력 상태와 반복 장애를 설계합니다

리셋 중 GPIO 상태, 외부 드라이버 enable의 풀업·풀다운, 부트로더와 초기화 중 순간적인 출력 활성화를 확인합니다. 안전 상태가 항상 전원 OFF인 것은 아니므로 장비에 맞춰 정의해야 합니다. 워치독은 기능안전 설계나 인증을 대신하지 않습니다.

기동 시 리셋 원인을 가능한 한 일찍 읽고 펌웨어 버전과 최소 진단 정보를 남기는 정책을 마련합니다. 반복 재부팅 시에는 자동 운전 재개를 제한하거나 점검 모드로 전환하는 조건을 둡니다. 플래시 로그는 쓰기 수명과 전원 차단 중 데이터 손상도 고려합니다. MCU 리셋만으로 외부 모뎀이나 센서가 복구되지 않는 경우에는 주변장치 리셋·전원 제어 범위를 별도로 검토해야 합니다.

5. 장애 주입으로 복구 경로를 확인합니다

다음은 개발 단계의 검증 목록이며 시험 완료를 의미하지 않습니다.

• 필수 태스크 하나의 완료 보고를 멈추고 다른 태스크가 정상이어도 장애가 검출되는지 확인합니다.

• 서버 단절과 통신 지연을 넣어 정상적인 재시도가 불필요한 전체 리셋으로 이어지지 않는지 확인합니다.

• 센서 무응답 시 드라이버 대기 경로가 제한 시간 내 종료되는지 확인합니다.

• 플래시 지우기·펌웨어 업데이트·저전력 진입과 복귀 중 감시 정책을 확인합니다.

• 리셋 신호, 출력 enable, 실제 부하를 함께 측정해 장애 발생부터 안전 상태 도달까지 기록합니다.

• 디버거를 분리한 양산 설정에서도 시험합니다. 디버그 중 워치독 정지 설정이 결과를 바꿀 수 있습니다.

개발 의뢰 전에 정하면 좋은 세 가지

첫째, 멈추면 안 되는 기능과 허용 중단 시간을 정합니다. 둘째, 통신 단절·센서 오류·태스크 정지를 다른 장애로 정의합니다. 셋째, 자동 복구를 허용하는 조건과 작업자 확인이 필요한 조건을 구분합니다. 그래야 하드웨어 리셋 경로, 펌웨어 감시 구조, 검증 항목을 같은 기준으로 설계할 수 있습니다.

참고 문서

• STMicroelectronics — STM32U5 HAL IWDG How to Use: 독립 클럭, 갱신, 클럭 편차와 디버그 동작. 링크의 HAL2 베타 문서는 개념 확인용이며 실제 구현은 사용 MCU의 레퍼런스 매뉴얼과 적용 HAL 버전을 기준으로 합니다.

• Espressif — ESP32 ESP-IDF Watchdogs: IWDT·TWDT 감시 범위, 태스크/user 등록, 타임아웃 동작과 JTAG 주의사항. ESP32 및 해당 ESP-IDF 버전 범위의 설명입니다.

공식 문서 확인일: 2026-11-01. 대표 이미지는 워치독과 태스크 감시를 표현한 개념 일러스트이며 실제 납품 보드나 검증 회로도가 아닙니다.