실무자 관점에서 보는 Watchdog – Window 모드, Alive Monitoring, AUTOSAR WdgM 완벽 이해
Watchdog이란?
이전글
2025.12.13 - [자동차SW 기초] - 🚗 Watchdog이란? 자동차 소프트웨어에서 왜 꼭 필요할까?
🚗 Watchdog이란? 자동차 소프트웨어에서 왜 꼭 필요할까?
와치독이란?안녕하세요, 버그없는토마토입니다 🍅오늘은 자동차 소프트웨어 개발에서 아주 기본적이면서도 중요한 개념인 Watchdog(워치독)을 쉽게 설명해보겠습니다.실무자라면 많이 들어보셨
jungposco.com
2025.12.13 - [AUTOSAR 심화] - 🚨 Watchdog의 실무적 이해 – 내부 동작, 안전 메커니즘, AUTOSAR WdgM까지 완전 정리
🚨 Watchdog의 실무적 이해 – 내부 동작, 안전 메커니즘, AUTOSAR WdgM까지 완전 정리
와치독이란?안녕하세요, 버그없는토마토입니다 🍅지난 글에서는 Watchdog의 기초 개념을 다뤘다면,이번 글에서는 실무 개발자 관점에서 Watchdog이 어떻게 동작하고, 왜 안전 설계에서 핵심 역할을
jungposco.com
들어가며
오늘은 조금 어려운 얘기를 해볼까합니다..
저번 와치독 게시글에서 오늘의 주제를 다음 포스팅에 기재한다고 했었죠
근데 제가 글을 써내려가다 보니 너무 어려운 주제여서 망설였거든요
그래서 임시저장을 하고 보석함에 저장했단말이죠...
근데 이 주제를 원하는 구독자분이 있어서 다시 꺼내오게 되었습니다.
워치독
기능안전을 하게 될 경우 필수로 등장하는 키워드가 바로 워치독입니다.
그만큼 안전과 관련하여 밀접해 있을 뿐더러 없어서는 안될 존재죠.
마치 차량 내부에 숨어있는 에어백과 같다고 생각해요
우리 눈에 보이지 않지만, 그리고 굳이 찾지 않는다면 보이지 않아요
하지만 위험의 순간, 우리를 지켜주는건 바로 에어백이죠.
오늘의 워치독 관련 게시글은 심도 깊은 내용입니다.
기존 워치독 게시글을 통해 개념을 모두 다 잡았다는 가정 하에 써내려 갈거예요
그리고 적당히 아시는 분들을 위해서 또 예시를 가득~ 가득~ 담았어요
비유 가득 게시글로 최대한 어렵지 않도록 글을 써내려가 보겠습니다
당신의 차가 고속도로 100 km/h로 달리고 있어요.
갑자기...
엔진 ECU가 멈췄다?!
CPU는 무한 루프에 빠짐:
while(1) {
// 뭔가 잘못된 변수 접근
int* ptr = NULL;
*ptr = 123; // CRASH! 💥
}
→ ECU는 응답 없음
→ CAN 버스에 메시지 안 옴
→ 변속기 ECU도 혼란스러워함
→ 자동차는 위험 상황!컴퓨터가 멈췄을 경우에 어떻게 하나요?
컴퓨터 본체를 꾸욱 눌러서 껐다가 켜버리죠?
사실 그게 가장 빠르고 정확한 해결법입니다.
그럼 자동차가 내부에서 꼬여서 멈춰버린다면 어떻게 할까요?
사실 자동차도 똑같습니다
재부팅을 해서 다시 원 기능으로 돌아가게 해야죠.
그렇다면.....
누가 이걸 감지해서 재부팅할까요?
답은 Watchdog (WDG)이에요.
이 글에서는 실무자가 반드시 알아야 하는 Watchdog의 모든 것을 설명해보겠습니다.
📌 3분 요약
바쁜 당신을 위한 핵심 3줄:
⏰ Watchdog = "시스템이 살아있나?" 감시자(감시견의 역할)
🪟 Window 모드 = "정해진 시간에만 피드" (너무 빠르거나 늦으면 리셋)
✔️ Alive Monitoring = 각 타스크(TASK)가 "나 살아있어!" 보고시스템이 *행(hang)되는 것을 방지하는 핵심 메커니즘이에요.
* 행(hang) = "시스템이 멈춰서 응답하지 않는 상태"
여기서 피드라는 말이 자주 나올거예요
생소한 단어일 수 있어요 (인스타 피드는 아닐테니까요)단어 뜻부터 바로 잡고 가볼게요
피드 = "Watchdog을 만족시키기 위해 보내는 신호"
비유: 강아지에게 먹이 주기 🐕
Watchdog (감시견):
"배고파! 먹이를 줘! 아니면 물어뜯을 거야! 😡"
개발자 (시스템):
"자 여기 먹이야! (피드 신호 전송) 🥩"
Watchdog:
"좋아! 배부르다! 소화 다 되면(100ms 후) 다시 줘! 😊"
타이밍 다이어그램:
시간: 0ms ──────── 50ms ──────── 100ms
│ │ │
├──────────────┼────────────┼───────────
WDG: │ START │ Window │ Timeout!
│ │ 시작 │
Feed: │ │ ✓ 피드! │
│ │(75ms) │
│ │ │ ✓ 피드!
│ │ │(125ms)
│ │ │
결과: ✓ 배부름! ✓ 배부름! ✓ 정상!
피드 안 하면:
시간: 100ms ──────── 150ms
│ │
├──────────────┼───────────
WDG: │ Timeout! │ 리셋! 💥
Feed: │ ❌ 안 줌! │
결과: ❌ 배고파서 물어뜯음!
⏰ Watchdog이란?
정의
Watchdog (WDG) = 시스템 감시견
ECU가 정상 작동하는지 감시하는 하드웨어/소프트웨어 메커니즘이에요.
역할:
1️⃣ 타이머 모니터링
└─ "정해진 시간 내에 피드를 받았나?"
2️⃣ 생존 신호 감지
└─ "시스템이 응답하고 있나?"
3️⃣ 강제 리셋
└─ "응답 없으면 재부팅!"
비유: 의료용 모니터
심전도 기계처럼 시스템의 "생명 신호"를 감시
심박 신호가 없으면 경고 → 조치! : 삐이이이이이이이------------ (코드블루!! 코드블루!!)필요한 이유
현실의 위험:
1️⃣ CPU 무한 루프
while(1) { } // 탈출 못 함
→ WDG이 감지 → 재부팅! ✓
2️⃣ 센서 오류
센서값이 이상해서
논리가 꼬임
→ WDG이 감지 → 재부팅! ✓
3️⃣ 메모리 부족
→ 프로그램 크래시
→ WDG이 감지 → 재부팅! ✓
4️⃣ 정전/라이닝
갑자기 전원 끊김
→ 복구 불가
→ WDG이 감지 → 안전 상태로! ✓
결론:
WDG 없으면 → 자동차가 갑자기 멈춤 → 사고!
WDG 있으면 → 자동으로 재부팅 → 안전!🪟 Window 모드 (Watchdog의 핵심)
Window 모드란?
Window 모드 = "정해진 시간 '윈도우' 안에만 피드 허용"
일반적인 생각:
"타이머가 0이 되기 전에 피드하면 OK"
Window 모드:
"정해진 시간 범위 안에만 피드 허용"
예시:
Watchdog 타이머: 100ms
└─ Window 범위: 50ms ~ 100ms
피드 타이밍에 따른 결과:
❌ 30ms에 피드
→ "너무 빨라!" → 오류! 리셋!
✅ 75ms에 피드
→ "딱 좋아!" → OK!
❌ 105ms에 피드
→ "너무 늦어!" → 오류! 리셋!Window 모드의 이유
왜 "정해진 범위" 안에만 피드?
목적: 과도한 피드를 방지!
예시:
반복 루프가 너무 빨라서
10ms마다 피드한다고 하자.
초 단위 타임라인:
0ms: 피드 1 ✓
10ms: 피드 2 ✓
20ms: 피드 3 ✓
...
100ms: 피드 10 ✓
문제:
→ 이렇게 빨리 피드될 수 없다!
→ 정상 시스템도 이렇게 빠르지 않아!
→ "너무 빠른 피드 = 비정상!" 감지
해결책: Window 모드
"50ms~100ms 사이에만 피드"
→ 너무 빠른 피드 방지! ✓Window 모드 수식
Window 모드 조건:
WDG_MIN_TIME < 실제_피드_시간 < WDG_MAX_TIME
예:
WDG_MIN_TIME = 50ms
WDG_MAX_TIME = 100ms
실제 피드 시간이 75ms?
→ 50 < 75 < 100 ✓ OK!
실제 피드 시간이 30ms?
→ 50 < 30? ✗ FAIL! 리셋!
실제 피드 시간이 120ms?
→ 120 < 100? ✗ FAIL! 리셋!
결론: Window 안에만 피드 OK!📊 Watchdog 타이밍 시나리오
정상 시스템
시간: 0ms ───── 50ms ───── 100ms ───── 150ms
│ │ │ │
├─────────┼──────────┼───────────┤
WDG: │ START │ Window 시작 │Window 끝 │ Timeout!
│ │ │ │
Feeding:│ │ ✓ 피드! │ │
│ │(75ms) │ │
│ │ │ ✓ 피드! │
│ │ │(125ms) │
│ │ │ │
Result: ✓ 정상! ✓ 피드됨! ✓ 정상 작동!비정상 시스템 1: 피드 누락
시간: 0ms ───── 50ms ───── 100ms ───── 150ms
│ │ │ │
├─────────┼──────────┼───────────┤
WDG: │ START │ Window │ Window │ Timeout!
│ │ │ │
Feeding:│ │ ❌ │ │
│ │ │ ❌ │
│ │ │ │
Result: ❌ 리셋! (Watchdog timeout!)
→ 시스템 재부팅!비정상 시스템 2: 너무 빠른 피드
시간: 0ms ───── 50ms ───── 100ms ───── 150ms
│ │ │ │
├─────────┼──────────┼───────────┤
WDG: │ START │ Window │ Window │ Timeout!
│ │ 시작 │ │
Feeding:│ ✓ 피드! │ ❌ 또 피드? │ │
│(20ms) │(40ms) │ │
│ │ 너무 빨라!│ │
│ │ 리셋! │ │
│ │ │ │
Result: ❌ 리셋! (Watchdog error!)
→ 너무 빠른 피드 감지!✔️ Alive Monitoring (각 태스크의 생존 신호)
Alive Monitoring이란?
Alive = "살아있다"
Monitoring = "감시한다"
Alive Monitoring = "각 태스크가 정상 작동 중이다"를 감시
구조:
┌─────────────────────────────┐
│ Watchdog Manager (WdgM) │
│ (중앙 감시자) │
│ │
│ ┌─────────────────────────┐ │
│ │ Supervised Entity (SE) │ │
│ │ = 감시되는 대상 │ │
│ │ │ │
│ │ Task 1: ✔️ Alive 신호 │ │
│ │ Task 2: ✔️ Alive 신호 │ │
│ │ Task 3: ✔️ Alive 신호 │ │
│ │ ... │ │
│ └─────────────────────────┘ │
│ │
│ → 모두 OK? 피드! │
│ → 하나라도 응답 없음? 리셋! │
└─────────────────────────────┘실제 동작
[정상 작동]
엔진 컨트롤 태스크 (10ms 주기):
───────────────────────────────
0ms: 엔진 계산 완료 → Alive 신호 전송 ✔️
10ms: 엔진 계산 완료 → Alive 신호 전송 ✔️
20ms: 엔진 계산 완료 → Alive 신호 전송 ✔️
...
변속기 컨트롤 태스크 (20ms 주기):
───────────────────────────────
0ms: 변속 계산 완료 → Alive 신호 전송 ✔️
20ms: 변속 계산 완료 → Alive 신호 전송 ✔️
40ms: 변속 계산 완료 → Alive 신호 전송 ✔️
...
Watchdog Manager (50ms 체크):
───────────────────────────────
50ms: 모든 SE가 Alive? YES! → 피드! ✓
100ms: 모든 SE가 Alive? YES! → 피드! ✓
150ms: 모든 SE가 Alive? YES! → 피드! ✓
결과: 정상! ✓비정상 작동: 태스크 크래시
[엔진 ECU 크래시]
엔진 컨트롤 태스크:
───────────────────────────────
0ms: 엔진 계산 완료 → Alive 신호 ✔️
10ms: 엔진 계산 완료 → Alive 신호 ✔️
20ms: 크래시! 💥 (Null pointer 접근)
→ Alive 신호 못 보냄! ❌
30ms: 응답 없음 ❌
40ms: 응답 없음 ❌
Watchdog Manager (50ms 체크):
───────────────────────────────
50ms: 엔진 태스크 Alive? NO! ❌
→ 오류 감지!
→ WDG 피드 안 함!
→ Watchdog 타이머 계속 카운트...
100ms: Watchdog 타이머 만료!
→ 강제 리셋! 💥
시스템:
→ 재부팅
→ Bootloader 실행
→ 정상 상태 복구 ✓🔧 AUTOSAR WdgM (Watchdog Manager) 구조
WdgM의 계층
AUTOSAR의 Watchdog Manager:
┌─────────────────────────────────────┐
│ Application Layer (SWC) │
│ ├─ EngineControl_Runnable │
│ ├─ TransmissionControl_Runnable │
│ └─ ... 각 태스크들 │
└────────────┬────────────────────────┘
│ (Alive 신호)
┌────────────▼────────────────────────┐
│ WdgM (Watchdog Manager) - BSW │
│ ├─ Supervised Entity 관리 │
│ ├─ Checkpoint 관리 │
│ ├─ Window 모드 체크 │
│ └─ Watchdog 피딩 │
└────────────┬────────────────────────┘
│
┌────────────▼────────────────────────┐
│ Wdg (Watchdog Driver) │
│ └─ 하드웨어 Watchdog 제어 │
└─────────────────────────────────────┘WdgM의 핵심 개념
1️⃣ Supervised Entity (SE)
감시 대상 = Task/Runnable
예: EngineControl_Runnable
└─ 주기: 10ms
└─ Alive 신호: "나 정상 작동해!"
2️⃣ Checkpoint
SE 내의 생존 확인점
예: EngineControl_Runnable 내
├─ Checkpoint 1: 계산 시작
├─ Checkpoint 2: 계산 완료
└─ Checkpoint 3: 결과 저장
3️⃣ Alive Counter
SE가 얼마나 자주 보고했나?
예:
├─ 0ms: Counter = 1
├─ 10ms: Counter = 2
├─ 20ms: Counter = 3
└─ ...
4️⃣ Window 설정
최소/최대 피드 시간
예:
├─ Min: 40ms
├─ Max: 80ms
└─ "40~80ms 사이에만 피드"📈 실무 사례: 현대 SoNaTa
SoNaTa의 WdgM 구조
[Supervised Entities]
1️⃣ EngineControl_SE
├─ Task: 10ms 주기
├─ Checkpoints:
│ ├─ CP_EngineCalc_Start
│ ├─ CP_EngineCalc_Done
│ └─ CP_EngineOutput_Done
├─ Window: 5ms ~ 15ms
└─ Alive Counter: 0~100
2️⃣ TransmissionControl_SE
├─ Task: 20ms 주기
├─ Window: 10ms ~ 30ms
└─ Alive Counter: 0~100
3️⃣ BrakeControl_SE
├─ Task: 10ms 주기 (중요!)
├─ Window: 5ms ~ 15ms
├─ Alive Counter: 0~100
└─ Priority: High (제동은 최우선!)
4️⃣ DiagnosticMonitoring_SE
├─ Task: 100ms 주기
├─ Window: 50ms ~ 150ms
└─ Alive Counter: 0~100
[WdgM의 피드 로직]
50ms마다:
└─ 모든 SE 체크
├─ EngineControl? Checkpoint 도달했나? YES ✓
├─ TransmissionControl? Checkpoint? YES ✓
├─ BrakeControl? Checkpoint? YES ✓
└─ DiagnosticMonitoring? Checkpoint? YES ✓
→ 모두 OK? 피드! ✓
→ 하나라도 NO? 리셋! ❌개념을 이해하고 난다면 구조자체가 어렵지는 않아요
1개의 타겟 구조를 이해하고 난다면 나머지는 타스크 주기 설정만 변할뿐 같은 로직을 가지게 되거든요
타스크 주기와 그에 맞는 윈도우 설정을 생각해주시고, alive Cnt는 같습니다
그렇다면 각 task타이머에 맞춰 checkpoint가 도달했는가를 Callback받아서 비교해준다면 완성입니다.
풀어서 얘기하니까 어렵지 않죠?
💻 AUTOSAR WdgM 코드 예시
WdgM 설정 (ARXML)
<AUTOSAR>
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>WdgM</SHORT-NAME>
<ELEMENTS>
<!-- Supervised Entity: EngineControl -->
<SUPERVISED-ENTITY>
<SHORT-NAME>EngineControl_SE</SHORT-NAME>
<ENTITY-ID>1</ENTITY-ID>
<!-- Checkpoints -->
<CHECKPOINTS>
<CHECKPOINT>
<CHECKPOINT-ID>1</CHECKPOINT-ID>
<NAME>EngineCalc_Start</NAME>
</CHECKPOINT>
<CHECKPOINT>
<CHECKPOINT-ID>2</CHECKPOINT-ID>
<NAME>EngineCalc_Done</NAME>
</CHECKPOINT>
</CHECKPOINTS>
<!-- Alive Counter -->
<ALIVE-COUNTER>
<COUNTER-MAX>100</COUNTER-MAX>
<COUNTER-MIN>0</COUNTER-MIN>
</ALIVE-COUNTER>
</SUPERVISED-ENTITY>
<!-- Watchdog Mode: Normal -->
<WATCHDOG-MODE>
<MODE-ID>1</MODE-ID>
<NAME>NormalOperation</NAME>
<!-- Expiration Period -->
<EXPIRATION-TIME>5000</EXPIRATION-TIME> <!-- ms -->
<!-- SE Reference -->
<SE-TIMING>
<SE-ID>1</SE-ID>
<MIN-TIME>40</MIN-TIME> <!-- ms -->
<MAX-TIME>80</MAX-TIME> <!-- ms -->
</SE-TIMING>
</WATCHDOG-MODE>
</ELEMENTS>
</AR-PACKAGE>
</AR-PACKAGES>
</AUTOSAR>🎯 면접 예상 질문
Q1: "Watchdog이 뭐고, 왜 필요한가요?"
A: "Watchdog은 ECU가 정상 작동 중인지 감시하는 메커니즘입니다.
만약 CPU가 무한 루프에 빠지거나 크래시하면 Watchdog이 감지해서
자동으로 시스템을 재부팅하기 때문에 안전성이 극대화됩니다."
Q2: "Window 모드가 뭐죠?"
A: "정해진 시간 범위 안에서만 Watchdog을 피드하는 방식입니다.
예를 들어 50ms~100ms 사이에만 피드를 허용하면,
너무 빠르거나 늦은 피드는 오류로 인식해서 시스템을 리셋합니다.
이렇게 하면 과도한 피드를 방지할 수 있어요."
Q3: "Alive Monitoring이 뭐예요?"
A: "각 태스크/Runnable이 정상 작동 중임을 주기적으로 보고하는 방식입니다.
Watchdog Manager가 모든 태스크의 Checkpoint를 감시해서,
하나라도 응답이 없으면 시스템을 리셋합니다."
Q4: "WdgM의 역할은?" (BSW 개발자를 위한 질문이라고 생각해주세요)
A: "AUTOSAR의 Watchdog Manager로,
각 Supervised Entity의 Checkpoint를 감시하고,
Window 모드 체크를 수행하며,
모든 SE가 정상이면 Watchdog을 피드합니다."
Q5: "실무에서 Watchdog 설정은 어떻게 하나요?"
A: "각 Task의 주기와 안정성 요구사항에 따라 Window 범위를 설정합니다.
예를 들어 10ms 주기 Task는 5~15ms,
100ms 주기 Task는 50~150ms 같은 식으로 설정합니다.
그리고 모든 Task가 자신의 Checkpoint를 정확히 보고해야 합니다."경력직 면접 예상문제라고 생각해주세요
신입 면접 질문과는 꽤나 괴리감이 있을거라고 생각해요
사실 이 정도의 수준을 원하지도 갖고 있을리도 없을거예요
오늘 게시글의 타겟이 실무자이기 때문에 입문자에겐 미안해요..
📌 Watchdog의 핵심
| 항목 | 설명 |
|---|---|
| 정의 | 시스템 생존 신호 감시 |
| Window 모드 | 정해진 시간 범위 안에서만 피드 |
| Alive Monitoring | 각 태스크의 Checkpoint 감시 |
| WdgM | AUTOSAR의 Watchdog Manager |
| SE (Supervised Entity) | 감시 대상 = Task/Runnable |
| Checkpoint | SE 내의 생존 확인점 |
| 조치 | 응답 없으면 강제 리셋 |
| 안전성 | 시스템 행(hang) 방지 |
| 실무 | 매우 중요 (필수) |
마치며
Watchdog의 개념에서 한단계 더 들어가서 BSW 부분까지 알아봤어요
사실 app단 개발자라면 여기까지 알 필요는 없다고 생각해요
하지만 한번 읽어본 것과 아예 모르는 것은 다를거예요
'몰라'와 '들어봤어'는 접근 자체가 다르니까 말이죠
오늘 글이 이해 안간다고 속상해 하지 마세요
이해 안가는게 정상일거예요 아마..
3분 핵심만 보고 이해해도 됩니다
그 정도면 여러분도 이미 워치독에 대해서 얘기할 수 있는 지식이 생겼거든요
다음 게시물에서 뵐게요
'AUTOSAR 심화' 카테고리의 다른 글
| AUTOSAR Dem 완벽 이해: 오류 감지와 DTC 관리의 모든 것 (0) | 2025.12.18 |
|---|---|
| AUTOSAR NvM 완벽 이해: 메모리 관리의 모든 것 (0) | 2025.12.17 |
| AUTOSAR 통신 시스템: CAN 버스, 신호, COM 모듈의 관계 (0) | 2025.12.16 |
| SWC와 Runnable이란? : AUTOSAR 소프트웨어의 기본 단위 (6) | 2025.12.16 |
| 🚨 Watchdog의 실무적 이해 – 내부 동작, 안전 메커니즘, AUTOSAR WdgM까지 완전 정리 (0) | 2025.12.13 |
