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

One thought on “Solving the software safety paradox”

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