[ RTOS ] 08. RTOS 환경에서 워치독 활용하기

RTOS 환경에서 워치독 사용하기

현업 골칫거리 중 하나인 WDT에 대해서 알아보려고 합니다.

먼저 그 중요성에 대해서 알아보겠습니다.

우주 환경에 장기간 노출 된 상태에서 센서와 우주선 구성 요소를 테스트하는 NASA 위성 인 Clementine 은 1994 년 1 월 25 일에 발사되었습니다. 몇 줄의 감시 코드가 부족하여 1994 년 5 월 7 일에 임무를 잃었습니다.

클레멘 타인은 달 궤도를 떠나 그녀의 다음 목표 인 지구 근처의 소행성 Geographos로 향했을 때 약 2 개월 연속 달지도를 수행했습니다. 그러나 곧 Clementine의 온보드 컴퓨터 중 하나에서 오작동이 발생하여 NASA가 우주선 작동을 효과적으로 차단하고 추진기 중 하나가 제어되지 않은 상태로 발사되도록했습니다.

NASA는 시스템을 다시 작동 시키려고 20 분을 보냈지 만 소용이 없었습니다. 하드웨어 재설정 명령이 마침내 Clementine을 다시 온라인 상태로 만들었지 만 너무 늦었습니다. 그녀는 이미 연료를 모두 사용했고 임무를 취소해야했습니다.
그 후 Clementine의 소프트웨어를 담당하는 개발 팀은 그들이 구현 한 소프트웨어 타임 아웃이 불충분하다는 것이 분명해 졌을 때 하드웨어를 감시할 수 있는 WatchDog Timer를 사용하기를 원했습니다.

어떻게 WatchDog이 도움이 되었을까?

워치 독은 마이크로 컨트롤러에 직접 통합되거나 마이크로 컨트롤러에 외부 적으로 연결되는 하드웨어입니다. 주요 목적은 시스템이 중단되었거나 부적절하게 실행되고 있다고 안전하게 가정 할 수있을 때 오류 처리 (일반적으로 하드웨어 재설정)를 수행하는 것입니다.

워치 독의 주요 구성 요소는 초기에 특정 값으로 구성되고 이후에 0으로 카운트 다운되는 카운터입니다. 소프트웨어는 0에 도달하지 않도록이 카운터를 초기 값으로 자주 다시 설정해야합니다. 그렇지 않으면 오작동으로 간주되며 일반적으로 CPU가 재설정됩니다. 이것은 다른 모든 것이 실패했을 때만 취하는 옵션 인 최후의 수단에 대한 감시자를 제안합니다. 클레멘 타인의 경우도 마찬가지였습니다.

WatchDog 사용방법

그러나 워치 독 타이머를 올바르게 사용하는 것은 카운터를 다시 시작하는 것만 큼 간단하지 않습니다 (이 프로세스는 워치 독을 "feeding"또는 "kick"한다고 함). 시스템에서 워치 독 타이머를 실행하는 경우 개발자는 오작동하는 시스템이 되돌릴 수없는 악의적인 작업을 수행하기 전에 워치 독이 개입 할 수 있도록 워치 독의 시간 초과 기간을 신중하게 선택해야합니다.

특히 RTOS를 사용하지 않는 간단한 애플리케이션에서 개발자는 일반적으로 메인 루프에서 워치 독을 공급합니다. 이 접근 방식은 적절한 초기 카운터 값을 구성하기만 하면 되며, 이는 전체 메인 루프의 최악의 경우 실행 시간을 적어도 하나의 타이머 주기로 초과하는 값을 선택하는 것만 큼 간단 할 수 있습니다. 이것은 종종 상당히 강력한 접근 방식입니다. 일부 시스템은 즉각적인 복구가 필요하지만 다른 시스템은 무기한 중단되지 않도록하기 만하면됩니다. 그러면 작업이 확실히 완료됩니다.

멀티 태스킹(RTOS) 환경

그러나보다 복잡한 시스템, 특히 멀티 태스킹 시스템에서는 다양한 스레드가 다양한 경우와 다양한 이유로 잠재적으로 중단 될 수 있습니다. 잠재적인 네트워크 통신을 기다리는 스레드와 같이 일부 스레드는 오랫동안 실행되지 않는 것이 좋습니다. 워치 독에 주기적으로 공급하는 깨끗한 방법은 각각의 개별 프로세스가 양호한 상태인지 확인하는 동시에 다음과 같은 것을 적절히 체크하는 것이 시스템 개발자에게 중요한 과제가되었습니다.

• OS가 제대로 실행되고 있는지 여부
• 우선 순위가 높은 작업이 CPU를 모두 소모하여 우선 순위가 낮은 작업이 전혀 실행되는 것을 방지하는지 여부
• 하나 또는 여러 작업의 실행을 방해하는 교착 상태가 발생했는지 여부
• 작업 루틴이 적절하고 전체적으로 실행되고 있는지 여부

또한 개발자는 전용 WatchDog 작업이든 모니터링되는 작업에 대한 특정 수정이든 소스 코드에 수행 된 모든 수정이 작게 이루어져야하며 침입을 최소화하고 효율성을 높이기 위해 소스 코드를 최적화 해야합니다.

RTOS에서 WatchDog 사용하기

따라서 임베디드 전문가에게는 아래 두 가지를 모두 허용하는 포괄적 인 API 기능 세트가 필요하다는 것이 분명해집니다.

• 기본 embOS 감시 모듈을 사용하여 작업, 타이머 및 ISR을 개별적으로 등록하고
• 원하는 상황에서 의도한 감시 조건을 유연하게 테스트 할 수있는 가능성.

결론

실제 시스템에서는 MICOM에 의해서 reset되거나 WDT에 의해서 reset 되는 경우에 어디까지 진행되었고, 어떤 이유로 reset 될 수 밖에 없었는지 파악하기 어렵습니다.

따라서, 디버깅용 WDT를 설정하여 MICOM 등이 reset되기 전에 ISR 루틴을 호출하게 해 몇몇 정보를 출력하고 재부팅하게 해야 합니다.

필자가 겪은 많은 System Reset의 이유 중 대부분은 WDT KICK Handler와 동일한 Handler에서 많은 실시간 처리를 하는 경우, WDT KICK Handler의 처리가 밀리면서 WDT KICK을 처리하지 못해 카운트가 0이 되어 종료되는 것이었습니다. 혹은 반복적으로 돌아가는 while문에서 메모리 누수가 발생하여 시스템이 비정상 종료가 될 수도 있을겁니다. 따라서 이러한 것들과 관련된 로직을 면밀히 분석하고 고쳐나가다보면 WDT에 의한 비정상 시스템 종료 문제를 해결할 수 있을 것입니다.