Need a watchdog for improved system fault tolerance?


Watchdog관련 글을 근래 들어 많이 올리는 것 같다. 과거에 비해 watchdog의 개념이 많이 upgrade되었고, 새로운 기술들이 많이 나왔기 때문에 소개해야 할 필요가 있다. Embedded system개발을 하지 않은지 오래되어서 그런지 다시 보려니까 반갑다..

 

글의 출처는 아래와 같다.

http://www.eetimes.com/document.asp?doc_id=1272141&print=yes

워치독 타이머는 알려지지 않은 상태에서 안전한 상태가 되도록 하는 가장 좋은 방법이다. 이렇게 워치독 타이머는 중요하기 때문에 워치독은 주의깊게 설계를 해야 한다, 그래서 제어가 안되는 코드에 의한 operation의 변경을 줄여야만 한다.

워치독과 관련된 새로운 방법

1) refreshing a watchdog
2) write protection mechanism
3) early detection of code runaway
4) quick self-test of the watchdog

 

watchdog의 기본적 매커니즘

1) watchdog timer가 count down을 한다. (predefined value를 설정한다.)
2) task들이 주기적으로 동작하면서 watchdog을 kick한다.
3) 만약 task가 runaway상태가 되면 프로그램 흐름이 망가지고 refresh routine(kicking the watchdog)이 수행되지 않게 되어 watchdog의 timer가 expire되게 되며 그 결과 watchdog은 reset을 MCU에 보냄으로써 MCU는 reset된다.

watchdog과 관련된 하나의 중요한 요구사항은 watchdog이 runway code로부터의 effect로부터 아무런 영향을 받아서는 안된다. 만약 runaway code가 우발적으로 watchdog을 disable시키면 system이 recover할 수 있는 방법을 상실하게 된다.

Designing Good Watchdog

다음의 항목들은 설계 가이드라인으로 정리해 둘 필요가 있다. 그리고 아래 항목은 안전분석을 수행하기 위해서는 기본적으로 알아두어야 할 내용이기도 하다. (물론 scope을 어떻게 하느냐에 따라서 몰라도 되는 내용일 수 있지만!)

  • watchdog timer의 폭은 시스템의 가능한 clock 소스에 대한 모든 범위의 timeout을 cover해야 한다.
  • watchdog timer는 관찰중인 시스템의 clock source와는 무관한 clock로 실행해야 한다. 아마도 watchdog을 위한 전용 clock source가 있어야만 한다, 이를 테면 RC oscillator와 같은. 이것은 어떤 이유로든 clock이 죽어서 시스템이 동작하지 못하는 경우라도 watchdog timer는 여전히 timeout되어 시스템을 reset할 수 있어야 한다.
  • watchdog이 system에 reset을 보내는 방법은 그 자체로 fault tolerant 해야 한다.
  • watchdog의 레지스터 비트에 대한 중요한 제어 및 설정은 쓰기 보호를 가지고 있어서 그들이 한번 설정되면  실수로 수정될 수 없도록 해야 한다.
  • watchdog을 refreshing하는 방법은 runaway code가 실수로 watchdog을 refresh할 수 있는 기회를 최소화시킬 수 있도록 해야 한다. 만약 runaway code가 희박한 기회로 watchdog을 refresh한다면, watchdog는 code가 runaway한 것을 모르거나 한참이 지난 후에 알게 될 것이다.
  • code가 runaway한 것에 대한 watchdog의 반응은 즉각적이어야 한다. 만약 watchdog이 시스템을 reset하는데 시간이 오래 걸린다면 unknown상태에 있는 시스템이 안전이 중요한 어플리케이션에서 큰 손상을 야기할 수 있다. 이전의 로봇 팔의 사례를 생각해 볼 때, 로봇 팔이 halt되는데 걸리는 시간이 길어질 수록 환자의 생명에 대한 더 큰 risk가 발생한다.
  • watchdog의 적절한 operation은 test할 수 있어야 하며 부트 이후 올바르게 동작하고 있다는 것에 대해 확신할 수 있어야 한다. 그 시험은 현실적이지 않은 오랜 시간이 되어서는 안된다.
  • watchdog은 watchdog timeout을 유발하는 fault의 진단을 쉽게 할 수 있어야 한다.

 

Robust Watchdog

  • Better, more unique, timed refresh scheme.
  • Timed password style access to control and configuration registers.
  • Detection of runaway code footprints, before actual timeout.
  • Faster but at the same time fault tolerant response to timeouts.
  • Fast test of the watchdog.

 

The Width of the Watchdog Timer

아래 그림에서 timeout period에 대해 cover할 수 있는 input clock frequencies와 timeout counter의 필요한 bit를 나타내고 있다.

Independent Clock Source

robust watchdog은 두 clock 입력중에서 switching하는 표준 옵션을 구현한다. 하나는 전용 clock source(on chip RC oscillator)이고 다른 하나는 시스템 clock이다.

 

Write Protection

kick하는 방식이 단순하면 runaway상태에서도 우연치 않게 kick할 수 있으므로 한번 kick하고 일정 시간 지난 후에 다시 kick을 해야지만 refresh되도록 하는 방식으로 write protection을 구현할 수 있다. 이 방법에서 발생할 수 있는 문제점은 두 번 kick하는 interval을 너무 길게 가져가면 runaway code가 소가 뒷걸음질 하듯이 kick을 할 수도 있다.

Robust watchdog은 두 번 kick하는 사이의 시간 차이의 제한을 가할 수 있다. 그 제한은 CPU가 2번째 값을 위한  명령어를 fetch하고 execution하는데 필요한 시간과 같다.  만약 첫번째 kick 실행 이후 runaway가 발생하면 두번째 kick을 수행할 시간이 없다.

만약 두 value를 kick하는 시간 간격이 bus clock cycle보다 살짝 더 크다면 watchdog은 exception을 보내고 시스템을 reset을 한다.

Unique Refresh Scheme

write of a sequence of two values in a particular order

1) 첫번째 값은 쓰고 두번째 값이 정해진 시간 이내에 들어오지 않으면 – exception을 보내고 system을 reset함

2) 첫번째 값을 쓰고 두번째 값을 쓰면 – refresh

3) 첫번째 값도 못쓰면 – reset

 

Windowed Refresh

refresh하는 주기가 일정하게 이루어질 것이기 때문에 runaway가 엉뚱한 시점에 kick을 하는 것을 방지하도록 하는 대책이 될 수 있음. period t마다 kick을 한다고 가정했을 때 t+-delta x기간동안만 kick을 허용하도록 함.

Fast Response to Code Runaway

reset을 해야 되는 경우 즉시 reset을 할 수 있어야 한다. 시스템이 죽었다가 살아나야 하는 경우 clock이 느리면 정상 상태로 되돌아오는 시간이 좀 오래 필요할 수 있다. 또는 boot하는데 시간이 필요할 수 있다. robust watchdog에서는 backup circuit이 있어서  단 한번의 reset이 아닌 consecutive timeout of timer가 있어서 다른 reset 시그널을 보내줄 수 있다. (한번의 reset시그널이 아니라 consecutive reset을 지원하는 watchdog이 필요하다. )

(ref: multi-stage에 대한 알기 쉬운 그림은 : http://en.m.wikipedia.org/wiki/File:Watchdog3stage.gif
그림에 대한 설명이 있는 위치: http://en.m.wikipedia.org/wiki/Watchdog_timer)

 

Testing the Watchdog in Reduced Time

IEC 60730및 다른 안전 표준에서는 안전 기능을 감시하는 어떠한 기능도 시험이 되어야 하고 그 시험은 fault tolerant해야 한다. watchdog을 시험하기 위해서 main timer와 그와 연관된 비교 및 reset logic이 시험이 되어야 한다. 대부분의 현재 구현된 watchdog은 단순한 timer의 overflow시험만 수행했다. 32bit timer의 1khz의 clock으로 수행되는 timer는 4×106의 시간이 있어야 overflow가 발생하게 되어 시험하는데 적합한 시간은 아니다. robust watchdog을 시험하기 위해서 timer를 constituent byte-wide stage로 나누고 독립적으로 수행을 시키고 실제의 timeout값의 대응되는 값에 대한 timeout에 대해 시험한다. 그림 5의 다음의 그림은 splitting 개념을 설명한다. 아래 그림의 예에서는 timer의 byte stage 3에 대한 시험을 보여주고 있다.

각각의 stage는 8bit 동기화 카운터이고 overflow signal을 생성하는 combinational logic이 붙어있다. overflow signal은 N+1번째 stage를 활성화시키도록 동작한다. test mode에서 개별 byte가 시험되도록 선택되었을 때(이를 테면 N이라고 할 때), 0에서 N-1의 byte는 0xFF로 load를 하고 N은 clock source를 run off하는 것을 허용한다. 그렇게 함으로써 N-1 stage의 overflow가 즉시 생성되고 stage N의 counter를 활성화시킨다. N번째 stage가 수행되고 timeout value register의 N번째 byte와 비교한다. N이 시험되는 이런 방법은 N과 preceding stage와의 link도 시험이 된다. 다른 stage의 어떤 것(N-2, N-3, N+1, N+2)도 byte N의 시험에 있을 때 활성화되지 않는다. 이런 비활성화된 stage들(counter의 most significant stage를 예외로 하고)은 oxFF로 load된다. 1KHz clock인 경우 각각의 test, 하나의 시험 이후 다른 시험을 수행하는데는 32bit timeout value를 모두 1로 만드는 값인 0xFFFFFFFF로 하는데에는 4x 256ms (~103ms) 시간이 걸린다. 실제 걸리는 시간은 실제의 셋팅하는 timeout 값에 의존적이다.

 

 

 

 

 

 

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s