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.
Advertisements

“Proper watchdog timer use”에 대한 1개의 생각

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중