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

Solving the software safety paradox


소프트웨어의 safety를 보장하기 위해서 구현되어야 하는 기능들을 기술한 article이다. 아주 오래된 기사이기는 하지만, 아직도 이런 내용을 모르는 엔지니어들도 상당수 있으리라 생각하기 때문에 여전히 유용한 정보라고 생각한다. 출처는 아래와 같다.

http://www.eetindia.co.in/ARTICLES/1998DEC/PDF/EEIOL_1998DEC02_EMS_TA.pdf?SOURCES=DOWNLOAD

best practice라고 생각되는 것들을 정리하면 아래와 같다.

  • CPU self-test
  • Guarding against illegal jumps
  • ROM tests
  • Watchdog timers
  • Redundant storage and cross checks of critical variables
  • Stack checks
  • Program checks

 

CPU self-test

부팅시에 CPU의 명령어들이 정상적인 행동을 수행하는지를 판단하는 code를 assembly로 작성한다. 문제가 있으면 부팅 실패로 halt상태로 종료.

Guarding against illegal jumps

사용하지 않는 메모리 영역에 대해 의도적으로 exception이 발생할 수 있는 machine code를 삽입하라는 건데, 이 정도로 illegal jump를 모두 막을 수 있을지는 모르겠으나, 매우 간단하게 어느정도의 문제를 해결할 수 이는 방법이라고는 생각함.

개발자가 의도적으로 illegal jump를 하도록 하는 code를 만들지 않도록 강제하고 code verification하는 방법도 고려해 볼 수 있겠고, control flow monitoring하는 방법을 고려해 볼 수 있겠다.

ROM tests

부팅시에 메모리를 테스트한다. checksum이나 CRC 시험을 한다. 만약 오류가 있으면 ROM의 데이터를 신뢰할 수 없으므로 그대로 멈춰라~(halt)

Watchdog timers

watchdog timer는 여러가지 bad practice가 있으므로 주의 깊게 사용을 해야 하고, 관련 문헌을 더 찾아봐야 한다. 내가 여기 블로그에 포스팅 한 것 중에 watchdog카테고리의 글들을 참조하기 바람(https://iso26262fs.wordpress.com/2014/12/30/proper-watchdog-timer-use/)

Stack checks

on-line으로 지속적인 관찰을 통해 stack이 overflow되고 있는지를 확인해봐라. 대개 RTOS에서 지원되는 기능이기는 한데, RTOS없이도 구현하는 것은 문제가 없음. stack이 overflow되면 어떻게 처리할까?에 대한 내용은 없는데 application specific한 문제라고 생각함. 영원히 halt하는 것이 좋을지 아니면 reset하는 것이 좋을지는 좀 따져봐야 할 듯.

Program checks

CPU의 연산결과를 못믿겠다면? 검산을 하면 된다. 초등학교때 배운 것처럼 검산은 연산 과정을 반대로 수행하는 것이라고 생각할 수 있다.

1+1+1 = 3이란 결과가 나왔다면, 3에서 시작해서 -1-1-1을 수행해서 0이 나오는지를 확인하는 과정.

모든 연산을 이렇게 수행하면 overhead도 상당할 것이고 선택적으로 수행을 해야 할 것으로 생각된다. ASIL B이하 혹은 ASIL C이하에서는 고려하지 않아도 되지 않을까?

ASIL D라고 하더라도 모든 연산을 저렇게 하다가는 deadline에 miss할 수 밖에 없을 것 같다.

 

  1. Neumann, Peter G. Computer Related Risks . Reading, MA: Addison Wesley, 1995, Chapter 2.8.1, p. 66.
  2. Santic, John S., “Watchdog Timer Techniques,” Embedded Systems Programming , April 1995, p. 58.
  3. Lowell, Augustus P., “The Care and Feeding of Watchdogs,” Embedded Systems Programming , April 1992, p. 38.
  4. Blum, Manuel and Sampath Kannan, “Designing Programs that Check Their Work,” Journal of the Association for Computing Machinery , January 1995, p. 269.

Proper watchdog timer use


안전한 시스템을 설계하기 위해서는 watchdog의 사용은 반드시 필요하다. 안전한 설계를 위해서는 반드시 고려되어야 하며, 안전분석이라고 하는 것이 이런 사항들을 고려하여 inspection하는 것을 포함한다고 볼 수 있다.

출처는 아래와 같다. 잘못된 번역이 있을 수 있다.

http://betterembsw.blogspot.kr/2014/05/proper-watchdog-timer-use.html

 

watchdog timer는 임베디드 시스템의 reliability를 보증하는 것을 돕기 위한 일반적인 방법이다. 하지만 그 방법은 적절하게 사용을 할 경우에만 동작한다. 효과적인 watchdog timer는 시스템의 어떠한 주기적인 task의 실패가 watchdog timer의 reset을 유발해야 할 것을 요구한다.

결과: 적절하지 않은 watchdog timer의 사용은 소프트웨어 task의 죽음 및 소프트웨어 task 오버런이 탐지되지 않는 잘못된 결과를 유발할 수 있으며 데드라인을 miss하거나 부분적 소프트웨어 failure를 유발할 수 있다.

허용되는 practices:

 

  • 만약 여러 개의 주기적인 task들이 시스템 안에 있다면 각각의 모든 task들은 자기자신이 살아있음을 보증하기 위해서 watchdog이 kick되도록 직접적인 contribute를 해야 한다.
  • 하드웨어 timer 인터럽트를 사용하여 직접적으로 watchdog을 kick하는 것은 나쁜 practice이다. (ISR이 현재 살아있는 모든 task들에 대해 기록한다면 예외가 될 수 있다.)
  • task health monitoring하는 task를 가장 낮은 우선순위에 두는 것 역시 나쁜 practice이다. 이런 접근법은 높은 우선순위의 task의 detect를 실패한다.
  • watchdog timeout 주기는 현실적인 가장 작은 값으로 설정되어야 한다. 시스템은 watchdog timeout값의 전체 주기에 대해 task의 어떤 조합이 죽을지라도 safe를 유지해야 한다.
  • watchdog tier가 reset하는 매 시간은 전체적인 operational system의 testing동안 발생하며 그 행위는 기록 되고 조사되어야 한다.

토의

간단하게 말해서, watchdog timer는 미리 정해진 어떠한 값에서 0이 될때까지 count down하는 counter로 생각될 수 있다. 만약 watchdog이 실제로 0이 되면, watchdog은 system reset이 발생한 어떤 문제도 고칠 것이라는 믿음으로 system을 reset한다. 그러한 reset을 방지하는 것은 watchdog을 주기적으로 본래의 미리 정해진 값으로 되돌리는 설정을 하는 “kicking” 을 할 것을 요구한다. 그리고 이러한 행위는 reset을 방지한다. 이 idea는 소프트웨어가 hardware watchdog으로 인해 system이 여전히 살아있고 reset을 방지한다는 것을 확신하게 된다. 이 idea는 10대 애들이 매 주기적인 시간마다 전화해서 모든 것이 올바르게 돌아간다는 것을 이야기 할 것을 요청하는 것과는 같지 않다.

Watchdog timer arrangement.

watchdog이 system 을 kick하면 reset은 가장 흔한 행동이다. 비록 restart를 시도하기 전에 유지보수 조정을 위해 기다리는 것이 더 나을 것으로 보이는 경우에 시스템의 영구적인 shutdown이 더 나을 수 있다고 하더라도 말이다.

watchdog timer로부터의 예상되는 장점을 얻기 위해서는 적절한 방법으로 watchdog timer를 사용해야 한다. 예를 들어 무조건적으로 watchdog을 kicking하는 hardware interrupt timer가 tigger하도록 하는 것은 특별히 좋지 않은 practice인데, 그 이유는 그것은 hardware timer ISR이 올바르게 동작하는 것을 제외하고 software task의 어떤 것도 올바르게 동작하는 것을 알려주지 않기 때문이다. (분석에 의해 당신의 10대 어린애에게 컴퓨터를 자동으로 셋업해서 사전에 저장된 소리로 “I’m ok” 메시지를 매우 토요일 밤에 집에 전화하는 것은 그녀가 실제로 그 날에 OK인지를 알려주는 것이 아니다.

여러 개의 task를 가지고 있는 system에 대해서 각각의 그리고 모든 task는 watchdog이 kick되도록 해야 한다. 단지 하나의 task로부터 듣는 것은 충분하지 않다. 모든 task들은 kick된 watchdog에 대해 일종의 unanimous “vote”를 가져야 할 필요가 있다. 동시에,  특별히 나쁜 practice는 하나의 task혹은 ISR가 watchdog의 kick을 통해 동작하고 있다는 것을 보고하는 것이고 이것이 다른 task들이 올바르게 동작하는 것을 의미하도록 하는 것이다. (분석적으로 다시 말하자면 3명의 애들 중에 하나의 목소리를 듣는 것이 나머지 두 명이 괜찮은지를 알 수 있는 건가?) 예를 들면 watchdog는 “interrupt routine으로부터 kick되어서는 안 된다” (MISRA report 3, p 38), 그리고 일반적으로 timer service ISR을 사용하여 watchdog을 kick하는 것은 나쁜 practice이다.

연관된 나쁜 practice는 낮은 task가 동작하고 있을 때를 가정하는 것인데, 이것은 다른 모든 task들이 동작함을 의미한다. 높은 우선순위의 task는 어떤 이유로든 죽을 수 있고 실제로 낮은 우선순위의 task가 동작하도록 더 많은 시간이 부여될 수 있다. 그러므로 만약 낮은 우선순위가 watchdog을 kick하거나 ISR이 kick하도록 flag를 set한다고 한다면 이 방법은 다른 task들이 시기 적절하게 주기적인 방식으로 동작하는 것을 실패한다면 탐지하는 것을 실패할 것이다.

CPU부하를 모니터링하는 것은 watchdog timer의 대체재가 아니다. task는 그들의 deadline을 miss할 수 있는데, 심지어 CPU부하가 70~80%인 경우에도 발생할 수 있는데 갑작스러운 순간적 부하로 인해 시스템 동작의 정상적인 환경에서도 발생할 수 있다. 그런 이유로 CPU의 부하 혹은 간접적 health check를 분석하는 것을 수행하는 것을 모니터링하고 계산식이 문제라는 것을 표시하지 않으면 기본적으로 주기적인 watchdog을 kick하는 것도 bad practice이다. (이것은 ISR의 내부로부터의 watchdog을 kick하는 변종버전이다.)

시스템 소프트웨어는 시간에 대한 workload를 측정하는 책임을 져서는 안된다. 그것은 watchdog의 일이다. 모니터 되는 소프트웨어는 watchdog이 progress를 만들고 있다면 kick를 해야 한다. progress가 충분히 빠른지를 결정하는 것은 watchdog 매커니즘에 달린 일이다. 그러므로 어떠한 조건적인 kick은 단순히 liveness(task들이 실제로 수행되었다)에 기반되어 수행되어야 하며, 시스템 부하(task가 아마도 수행되고 있다고 생각한다)에 기반해서는 안 된다.

multi-tasking system에서 watchdog timer를 kick하는 한가지 방법이 아래 그림에 표시되었다:

이 watchdog 접근의 핵심 속성은 다음과 같다: (1) 모든 task들은 watchdog timer를 kick하기 위해서 살아있어야 한다. 만약 하나의 task가 죽는다면 watchdog timer는 time out될 것이고 system을 reset한다. (2) task들은 그들 자신의 시간 혹은 그들의 CPU 부하를 추적을 유지하지 않으며, 무엇이 살아있는지의 여부에 대해 watchdog timer에게 거짓말을 하는 소프트웨어 fault혹은 execution defect를 가지는 것을 불가능하게 만든다. CPU의 소프트웨어 정책 자체를 만들고 watchdog이 kick하는 것을 기다리도록 shut down하는 대신 이 소프트웨어는 단순히 언제 그들이 수행을 종료했는지에 대해 tasks report를 가지며 watchdog timer가 적절한 정책적인 일을 하게 한다. 보다 복잡한 버전의 code들은 관련된 시스템에 의존적일 수 있다; 이것은 좋은 watchdog의 교실 사례이다. task w가 어디에서 수행되는지는 스케줄링 정책과 얼마나 watchdog timer interval이 tight하는가에 따라 의존적이다. 하지만 낮은 우선순위의task에서 watchdog을 동작시키는 것이 일반적이다.

watchdog시스템의 timing을 setting하는 것은 또한 중요하다. 만약 목표가 task가 적어도 매 5msec마다 수행되어야 하는 것을 보장하기 위해서라면 watchdog timer를 800msec에 setting하는 것은 task가 795msec늦을 때까지 문제를 당신에게 알려주지 않는다. watchdog timer는 가장 느린 task의 period와 가급적 가깝게 set해야 한다. execution variation과 scheduling jitter를 고려한 약간의 extra time(margin)을 고려하라. (=slowest period + margin)

만약 watchdog timer set이 시험 도중 나타났다면 그 현상을 조사해야 한다. 만약 허용할 수 있는 실시간 스케줄링 정책이 사용되었다면 watchdog timer reset은 system failure가 발생하지 않았다면 나타나서는 안 된다. 그러므로 각각의 watchdog timer가 reset 기록으로 근본 원인을 찾아내는 것은 safety critical design의 본질적인 부분이다. 예를 들어, 자동차 문맥에서 어떤 watchdog timer event 기록이 유지보수를 위한 목적으로 vehicle에 저장될 수 있다. 유지 보수 동안, 기술자의 컴퓨터는 이벤트 기록을 수집하고 자동차 제조사에게 인터넷을 통해서 전달해야 한다.

Watchdog timer가 모든 문제를 탐지하지 못하는 반면, 좋은 watchdog timer 구현은 안전한 임베디드 제어 시스템을 만드는 기본이 된다. 안전이 중요한 시스템에서 허용가능한 watchdog timer를 포함하는 것을 누락하는 것은 과실이 있는 설계이다.

References:

  • Addy, E., A case study on isolation of safety-critical software, Proc. Conf Computer Assurance, pp. 75-83, 1991.
  • Ball, Embedded Microprocessor Systems: Real World Design, Newnes, 2002.
  • Brown, D., “Solving the software safety paradox,” Embedded System Programming, December 1998, pp. 44-52.
  • Ganssle, J., The Art of Designing Embedded Systems, Newnes, 2000.
  • IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems (E/E/PE, or E/E/PES), International Electrotechnical Commission, 1998.
  • Lantrip, D. & Bruner, L., General purpose watchdog timer component for a multitasking system, Embedded Systems Programming, April 1997, pp. 42-54.
  • MISRA, Report 1: Diagnostics and Integrated Vehicle Systems, February 1995.
  • MISRA, Report 3: Noise, EMC and Real-Time, February 1995.
  • MISRA, Report 4: Software in Control Systems, February 1995.
  • NASA-GB-8719.13, NASA Software Safety Guidebook, NASA Technical Standard, March 31, 2004.
  • Smith, Digital control of industrial processes, ACM Computing Surveys, Sept. 1970, pp. 211-241.
  • Storey, N., Safety Critical Computer Systems, Addison-Wesley, 1996.

ISO26262, DO-178C, DO-278A