카테고리 보관물: RAMS

대기 방사능의 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

 

안전 무결성 수준의 사용, 잘못된 사용을 이해하기(1)


오래된 논문이기는 한데, functional safety의 기본을 이해하는데는 도움이 될 만한 내용이라고 생각됨.

Abstract

안전 시스템의 현대 표준들은 안전 무결성 수준(SIL)의 개념을 채용한다. 시스템의 증가는 구매자들이 공급자에게 그들이 SIL 개념(concept)을 사용하여 시스템이 개념을 적용하려 하였다는 것을 입증할 것을 기대한다. 그러나 표준들은 SIL에도 차이가 있으며 개념을 만족스럽게 설명하지도 않는다. 그 결과 종종 오해를 불러일으켜서 일관성 없고 부정확하면서 부적절하게 사용되는 결과를 초래하게 된다.

이 논문은 SIL개념 및 그 적용에 대해서 설명하며 어떻게 SIL이 3개의 안전 표준들로부터 파생된 것인지에 대한 사례를 제공한다. 그런 다음 어떻게 SIL 개념이 오해를 불러일으켜서 오해시킬 만큼 사용되는지를 보일 것이다. 그리고 SIL과 리스크 감내정도(risk-tolerability) 판단(decision) 사이의 관계에 대해 논의할 것이다.

1 Introduction

안전 무결성 수준의 개념은 안전 중요 시스템 분야에서 일반적이며 많은 표준들이 안전 중요 시스템의 설계와 개발에서 그 사용을 옹호한다. 하지만 다양한 표준들이 SIL을 다르게 사용할 뿐만 아니라 어떻게 그 개념이 파생되었고 적용되는지에 대해서는 알려주지 않는다. 그 결과 SIL은 잘못 이해되게 되었다. 반면 그 개념이 안전의 달성(achievement) 및 입증(demonstration)을 가능하도록(facilitate) 의도한 반면, 많은 경우에 오해와 실망을 유발하게 되었다.

더욱이, 비록 SIL의 파생과 적용이 복잡하기는 하고 오해될 수 있다고는 하지만 그것은 개념적으로 간단하며 쉽게 설명될 수 있다. 그 결과 SIL개념은 불완전하게 사용되고 종종 부정확하고 부적절하게 사용된다.

이 논문의 목적은 SIL개념을 설명하기 위한 것이다. 그것을 하기 위해, 이 논문은 일반적인 설명뿐만 아니라 SIL이 파생되고 3개의 최신 표준들에 따라 어떻게 적용되는지에 대해서 설명할 것이다.

이 논문의 further 목적은 SIL개념이 오해를 불러일으키는 방법에 대한 관심을 이끌어내고 어떻게 그것이 잘못 이해되고 잘못 사용되는가에 대한 것이다. SIL 개념은 tool이며 다른 tool과 같이 현명하게 사용하면 유용하지만 잘못 적용된다면 문제를 유발할 수 있다.

2 What are Safety Integrity Levels?

SIL개념은 지난 20년동안 시스템의 안전에 대한 상당한 노력이 투여된 곳에서부터 출현하게 되었다. 2가지 요인이 주요 영향으로 두드러졌다.

첫번째는 시스템은 안전하거나 안전하지 않을 수 있다는 식의 2진 속성을 가진 믿음으로부터 절대적인 안전과 어떤 재앙 사이의 연속체가 있고 연속체는 위험의 척도라는 이해로 이동한 것이다. 이것은 위험 분석을 안전 관련 시스템의 개발에서 중요 요소가 되도록 이끌었다.

두번째 중요 인자는 안전 분야에 있어서 소프트웨어(그리고 마이크로 프로세서와 같은 복잡한 하드웨어) 사용의 커다란 증가이다. 이것은 random및 systematic fault사이의 균형을 변화를 유발시켰다. 이전에는 안전은 reliability를 통해서 달성될 수 있을 것이라고 (종종 암묵적으로)가정하는 것이 일반적이었고 aggregation, 종종 fault tree, component의 random failure rate를 통해 시스템의 reliability에 대한 값을 낮춤으로써 safety가 달성되었다. 어떤 경우 failure rate는 component의 역사적인 사용으로부터 도출되고 그게 아닌 경우 estimate되어 결과의 정확성이 의심의 여지가 없었던 것이 아니다. 사실, 달성 가능한 가장 높은 정확도는 오로지 random failure를 고려하는 것에서부터 파생가능한데, 그 이유가 확률적 방법은 systematic fault의 분석(예를 들어서 명세 및 설계 오류에서의 systematic fault의 도입)에 대해서는 valid하지 않기 때문이다. 소프트웨어는 wear out이 일어나지 않고 모든 fault가 systematic하며 random failure의 고려에서 제약되는 방법에 의해 system의 reliability를 유도하는 가능성은 없다.

소프트웨어의 또 다른 특징은 그것의 고유한 복잡성이다. Fault가 존재하지 않음을 증명하는 것은 불가능하며 testing으로부터 reliability의 높은 confidence를 이끌어내는 것은 실용적이지 않은 긴 시간을 필요로 한다.

그래서 safety를 달성할 뿐만 아니라 입증하는 것이 필요한 개발자에게 많은 문제들이 닥치게 된다. 이런 문제들의 일부분은 다음의 질문과 간단한 토의를 통해 요약을 할 수 있다.

  • 어떻게 우리는 시스템의 안전 요구사항을 정의할 수 있을까? 요구사항들은 정량적이거나 정성적일 수 있는 위험 분석으로부터 도출될 것이다(may). 하지만 소프트웨어 failure는 random fault가 아니라 systematic에서 초래하기 때문에 failure의 확률이나 위험한 failure의 확률을 직접적으로 측정하는 것은 타당하지 않아서 정량적 위험 분석이 채택되어야 한다. 주어진 risk의 감소가 소프트웨어 안전 기능의 명세로 정의될 수는 있겠으나 그 기능의 감내할 수 있는 failure rate는 SIL로 정의될 수 있을 것이다(may). 사용상의 표준에 의존적으로 SIL은 failure rate의 수치 범위에 같거나 같지 않을지 모른다.
  • 소프트웨어의 개발에서의 엄격도가 커지면 비용의 증가를 수반하게 되는데 어떤 특별한 경우에 대한 적절한 엄격도의 수준을 어떻게 정의할 수 있을까? Risk 분석이 SIL을 이끌었다면 이것은 개발 프로세스의 엄격도를 정의하는데 사용된다. SIL이 높아질수록 엄격도는 높아지게 되고 다양한 SIL에 적합한 방법, 기술, 관리 프로세스를 식별하기 위해 표준에서 사용되는 표(방법)들이 많아지게 된다.
  • 만약 우리가 safety가 아니고 reliability를 직접적으로 계측할 수 있다면, 우리는 reliability 측량의 용어로 safety target을 정의할 수 있는가? 아래에서 논의되는 표준들의 2개에서 SIL은 failure rate로 정의되고 나머지 하나에서는 위험한(안전하지 않은) failure의 rate로 표현되고 모두가 reliability type의 measurement로 표현되어 있다.
  • 달성된 안전의 주장을 하기 위해 어떻게 기준을 정의할 것인가? SIL이 달성되어야 하는 안전의 수준을 정의하기 위해 사용된다면, SIL은 만들어지고 판단되어야 하는 달성된 안전에 대한 주장에 대한 기준이 되어야 한다. 그러나 소프트웨어의 예상되는 failure rate에 대한 수치값이 confidence로부터 도출될 수 없다면, 그와 같은 주장의 증명에 대한 증거 제시는 불가능할 것이다.

 

(paper) Software 기반의 시스템에 대한 dependability 평가


흥미로운 논문이다. 2005년에 나온 논문으로 소프트웨어에 대한 안전성 평가의 허구성(?)과 불가능성(?)에 대해 다룬 논문이다.

A-SMGCS의 Validation방법을 조사하다가 찾은 논문인데, CNS/ATM분야 뿐만 아니라, 일반 산업분야에서도 적용이 가능할 것으로 생각한다.

내용을 간단하게 정리한다.

20년 전에: Flight control software에 대해 1.0E-09의 고장 확률에 대한 목표

  • 달성할 수 있겠는가? 측정할 수 있겠는가?

 

어떤 Reliability 수준이 요구되는가?

  • civil aircraft flight control: 1.0E-09/h의 고장확률
  • railway signaling control: 1.0E-12/h의 고장확률
  • UK의 원전 primary protection system: 1.0E-3/h의 고장확률

 

왜 불확실한가?

  • 소프트웨어의 고장(failure)은 systematic하다 – 만약 소프트웨어가 어떤 환경에서 고장나면 그 소프트웨어는 항상 그 환경에서 고장난다. (별표 10개, 밑줄 쫙쫙, 하이라이트 반짝반짝)
  • 그런데 문제는 H/W고장, Human factor, emergent property등과 같이 불확실한 환경이 발생해서 고장이 난다는 점
  • ‘Systematic’이 ‘deterministic’을 함축하는 것이 아님

 

Software의 unreliability를 이끄는 요인

소프트웨어가 완벽하게 동작하지 않는 이유가 무엇인가? 그것은 결국 로직이다.

왜 올바르게 돌아가지 않는거지?

  • 참신성: 급진적이로 새로운 기능을 구현하기 위해 소프트웨어가 사용된다.
  • 어려움: 소프트웨어 설계자가 풀어야 하는 문제들은 본질적으로 어렵다.
  • 복잡함: 이런 추세는 불필요하게 설계 솔루션의 복잡함을 유발함.

 

그래서 얼마나 심각한가?

만약 우리가 실제 프로그램을 결함이 없도록 만들 수 없다면, 얼마나 많은 결함을 예상할 수 있을까?

  • 달성할 수 있는 결함 밀도는 얼마일까?
    • C130J 소프트웨어의 연구사례에서 kLoC당 1.4 safety critical fault가 나왔다.
  • 여기에서는 좋은 소식은 없다.

 

얼마나 많은 결함이 매우 믿을 수 없는 것을 의미하는 것이지?

반드시 그런 것 만은 아님!

  • windows의 신뢰성은 windows 95/98의 300 hours MTBF에서부터 3000 hours로  증가해 왔음
  • 항공기 및 자동차의 소프트웨어에 대한 운영 경험(operational experience)는 높매우 높은 신뢰성이 달성 가능함을 제안함

 

어떻게 소프트웨어가 그렇게 신뢰성이 있을 수가 있지?

왜냐면 많은 결함들이 사소한 것이라서

 

그러면 뭐가 문제인데?

문제가 있어?

  • 크고 복잡한 프로그램이 매우 신뢰성이 있을 수 있기 때문에 특정한 한개가 그럴 수 있을거라는 것을 의미하는 게 아니야
    • 과거에 성공적으로 신뢰성 있는 소프트웨어를 만들었다고 해도 신규 프로그램이 신뢰성이 있다고 할 수는 없겠지
    • 과거에 소프트웨어 엔지니어링 프로세스가 성공적이라고 하더라도 다음에도 그렇게 될 거라고 할 수는 없겠지
  • 그래서 소프트웨어가 얼마나 믿을만한지를 측정하다는 것이 필요하다는 것
  • 그리고 이러한 평가는 광범위한 real-life operational use전에 수행되어야 할 필요가 있다
    • 그 외에 위험 평가를 할 수 있겠나?

그래서 어떻게 dependability를 평가할 수 있지?

응 ?

 

직접적 평가: 운영 시험

  • 운영 시험을 기반한 통계적 방법만이 신뢰도의 직접적 평가 수단이다.
    • MTBF, reliability function, failure rate의 estimation, prediction을 허용한다.
  • 이를 위해서는
    • 운영적 사용을 통계적으로 대표할 수 있는 테스트 데이터를 생성해야 함을 의미하지
    • 오류를 탐지할 수 있는 테스트 오라클이 필요하지
  • 수용 가능한/수용 불가능한 결과를 내는 절차가 reliability의 estimate 및 predict에 사용된다.

 

신뢰도 성장 모델링

25년간 많은 연구가 있었지

 

그래서 어떤 주장을 하고 싶은건데?

시험을 통한 reliability growth 은 매우 설득력이 약하다는 것이 밝혀졌다.

  • 예를 들어 MTBF로 x시간을 주장하고 싶다면 테스트에서 10~100 * x 정도의 시험 횟수가 필요하다
  • 더 나쁜 소식은, 여기에는 강력한 law of diminishing returns operating이 있다.
    • 매우 작은 결함을 찾으려고 한다면, 그것을 찾기가 굉장히 어렵겠지?

 

그래서 우리가 무엇을 할 수 있지?

가용한 다른 정보들이 많이 있기는 해

  • ex. software engineering process의 quality
  • ex. static analysis로부터의 정보
  • ex. expert judgement

Dependability ‘case’

비공식적으로, dependability case는 가정과 증거를 기반으로 한 argument이다.

그리고 이것은 어느정도 수준의 confidence에서의 dependability claim를 지원한다.

 

그런데, SE의 증거는 약해

소프트웨어 엔지니어링 프로세스는 product dependability claim을 지원하는 용도로 많이 사용되지

그런데, 그것은 매우 약해

process와 product간의 인과 관계를 보일 수 있는 몇몇 증거들이 있어(fault count)

그런데, process->product-> product reliability의 인과관계를 보일 수 있는 증거들은 없어(failure rate)

‘case’를 위한 뜨는 표기방식: BBNs

  • 장점
    • 추론에 강력한 도움
  • 단점
    • 과도한 낙관적 추정
    • 불확실성에 대한 확률을 표현하는데 인간은 어리숙하

 

결론

아직 해결되지 않았다. 연구가 필요하다.