Tag Archives: system design

대기 방사능의 Single event effect를 조정하기 위한 시스템 설계 최적화


SEE(Single Event Effect)에 대비한 시스템 설계 및 소프트웨어 구현 방법에 대한 글이다.

SEE란?

표준(IEC 62396-3)에서는 single particle(cosmic rays, solar energetic particles, energetic neutrons and protons)의 영향에 대한 component의 반응이라고 정의되어 있다.

대기중의 방사성 에너지가 digital device에 주입되면, digital device는 energy에 반응하여 여러가지 fault들을 가질 수 있게 된다.

시스템 safety관점에서는 fault는 두 가지로 분류할 수 있다.

  • hard – 영향을 받은 LRU(item 혹은 하나의 sub-system정도)의 영구적인 failure가 되도록 하는 fault
  • soft – 시스템의 기능이나 redundancy의 손실 없이 복구될 수도 있는 fault

Reliability는 hard fault failure rate의 합으로 결정되며, Availability는 hard fault와 soft fault의 합으로 결정된다.

외부 방사능에 의해 component의 영향 – hard error, soft error, firm error, latch-up, burnout, upset, functional interrupt

 

hard fault는 방사능에 의해 component가 실제적인 손상이 발생하여 fault가 영구화된 상황을 의미하고, soft fault는 방사능에 의해 일시적으로 발생할 수 있는 fault이며, 이 soft fault가 digital hardware(counter, register, memory 등)의 issue가 된다.

설계상에서 방사능의 영향을 감소(Mitigation)시키는 방법

가장 좋은 것은 방사능에 대한 시험을 통과한 chip을 사면 된다. 젤 비싼 chip으로. 그 부분이 현실적으로 적용하기 곤란한 상황이라면(또한 고객이 굳이 요구하지 않는다면..) 다른 방법을 생각해 볼 수 있다.

시스템을 개발할 때, 3가지 수준에서 SEE를 고려할 수 있다.

  • 시스템 아키텍처 단계(system level)
  • 시스템 아키텍처 내의 개별 전자 장치의 고려 단계(item or sub-system level)
  • 전자 장치의 컴포넌트의 고려 단계(component level)

 

mitigation 방법 요약

hard fault soft fault
system architecture redundancy redundancy, monitoring
electronic equipment redundancy 별도로 표시함.
electronic component/device 우주방사능 시험에 통과된 소자 error detection, correction 기능이 있는 소자
redundant computing element

 

soft fault의 electronic equipment의 mitigation 방법

equipment level에서 손상된 데이터 혹은 에러를 탐지하면 시스템 요구사항에 따라 여러가지 복구 방법이 있을 수 있음. 에러 탐지시 관련 데이터는 다음과 같이 처리될 수 있다.

  1. faulty로 표시한다.
  2. 그 데이터는 선택적으로 무시한다.
  3. 손상되지 않은 redundant module로 switching을 한다.
  4. 데이터는 삭제하고 좋은 data로부터 영향받은 프로세스를 재초기화한다.

(p.s) ISO 26262 표준 관점에서는 recovery에 대해 recommend를 하지 않은 것으로 봐서 자동차 분야에서는 이 정도까지 Tight하게 요구하지 않는건가? 라고 생각하기는 하지만, detection & correction은 해야 하고, 필요하다면 recovery를 해야 할 수도 있을 것이다.

 

SEE를 위한 소프트웨어 설계시 고려사항

  1. parity, CRC, hamming code, reed-solomon code, convolutional code
  2. watchdog timer, voting
  3. 보호되지 않은 캐시 메모리의 사용을 최소화
  4. 주기적으로 캐시를 flushing
  5. voting을 위해 중요 값을 triple version으로 저장
  6. 보호 매커니즘이 없는 RAM을 사용하지 않는다. (좋은 RAM을 고른다)
  7. stack과 heap사용을 최소화한다(동적으로 변경하는 메모리 공간은 소프트웨어에서 보호하기 어려움)
  8. stack, heap overrun 보호, language에 내장된 protection mechanism사용(ada에서의 variable range check)
  9. 민감도가 높은(criticality가 높은, 그러니까 문제되면 심각해질 수 있는) 변수의 사용의 최소화
  10. 주기적으로 중요 영역의 checksum의 수행
  11. 저장하기 전에 영구적으로 저장되는 공간의 checksum
  12. transient error를 극복하기 위해 계산을 반복수행
  13. 상수는 ROM영역에, 만약 RAM에 넣어야 한다면 주기적으로 ROM에서 복사하기
  14. critical decision/calculation에 사용되는 데이터에 대해서는 RAM 영역이 정확하다고 믿지 말자
  15. 매 frame마다 하드웨어 latch에 output discrete쓰기
  16. logic에서 counting을 할 때 ==를 쓰지 않고 >= 나 <=로 하기
    • 1부터 30까지 counting을 한다고 했을 때, 메모리 오류가 발생해서 30이라는 숫자에 exact matching되지 않을지도 모름. 그러면 무한 루프에 빠지게 됨
  17. 소프트웨어에 초기화되는 디바이스의 설정 상태를 지속적으로 점검
  18. input data를 filter
  19. BITE나 BIT가 failure를 탐지하면 failure를 confirm하기 위해 재 실행
  20. bi directional I/O를 사용할 때에는 configuration에 대한 re-assert
  21.  CPU의 설정을 위해 register를 사용할 때, re-assert
  22. 포인터는 range check

 

Advertisements

Toyota Case: Single Bit Flip That Killed


출처: EETimes

 

Bar라고 하는 애들이 도대체 도요타에게 무슨 짓을 저지른 것일까? 저렇게 시험해서 온전하게 돌아가는 제품이 있을까? IMF때 금리올리고 회사 다 망하게 놔두고 국유화하지 말라고 한 그들이 정작 자기네들 문제생겼을때는 금리내리고 회사 국유화시키고 … 한 것처럼 그렇게 하면 망하는 것을 다른 나라에게 요구하는 것인가? 생각이 들기도 한다.

미국내 제품을 대상으로 시험해도 과연 통과할까? …


Task X death
Now that the experts’ testimony and findings have been made public through the Oklahoma trial, let’s get into details. What defects were found in Toyota’s electronic throttle control systems?

Barr said that the 2005 Camry L4 source code and in-vehicle tests by the experts confirmed that some critical variables are not protected from corruption, and sources of memory corruption are present. He believes that Toyota’s engineers sought to protect numerous variables against software- and hardware-cause corruptions, but they failed to mirror several key critical variables, and they made no hardware protection available against bit flips.

Stack overflow and software bugs led to memory corruption, he said. And it turns out that the crux of the issue was these memory corruptions, which acted “like ricocheting bullets.”

중요변수에 대한 FMEA를 하는 것이 필요하다는 의미이다. 하면 품질관점에서 좋아지긴 하겠지, 근데 그 기준이라는 것이 상당히 결정하기 어려운 문제인데, 위의 문구만 보면 Detailed design수준의 FMEA가 필요한 것처럼 보인다.

Stack overflow및 memory corruption에 대한 대비책을 위해서 protection을 hw level 뿐만 아니라 sw level에서 해야 한다.

 

Barr explains the issue this way:

Memory corruption as little as one bit flip can cause a task to die. This can happen by hardware single-event upsets — i.e., bit flip — or via one of the many software bugs, such as buffer overflows and race conditions, we identified in the code.

There are tens of millions of combinations of untested task death, any of which could happen in any possible vehicle/software state. Too many to test them all. But vehicle tests we have done in 2005 and 2008 Camrys show that even just the death of Task X by itself can cause loss of throttle control by the driver — even as combustion continues to power the engine. In a nutshell, the fail safes Toyota did install have gaps in them and are inadequate to detect all of the ways UA can occur via software.

메모리 bit flip에 의해서 task가 die에 이르는 문제는 아주 심각한 문제인데, mcu에서 이런 문제를 해결하기 위한 설계가 필요할 뿐만 아니라 OS에서도 cover해줘야 한다. 그런데, …. 이건 정말 맘먹고 털려고 작정해서 턴게 아닌가? 이런 생각이 든다. 아직까지 그와 같은 엄격한 수준의 상세화가 표준화되지도 않았는데, 과연 누가 저렇게까지 설계를 했을까 생각이 들기도 한다.. 그런데 누군가는 그렇게 했을지도 모르지..

Just to clarify, the “tasks” are equivalent to apps running on smartphones or PCs. All software malfunctions from time to time — we often have to reboot our machines. The 2005 Camry L4 has a set of dozens of apps (or tasks). Because they are all meant to be running always, the death of one could have dire consequences.

When asked if the whole case for unintended acceleration could be pinned on the task X death, Barr replied, “The task X death in combination with other task deaths.” There are dozens of tasks and 16 million different ways those tasks can die. The experts group was able to demonstrate at least one way for the software to cause unintended acceleration, but there are so many other ways that could have happened.

Barr also said more than half the dozens of tasks’ deaths studied by the experts in their experiments “were not detected by any fail safe.”