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

 

(paper) 항공분야의 복잡 시스템에 대한 안전 분석 방법들(2)

목차

• 논문에 대한 결론(개인적인 의견)
• 도입 – TLS(Target level of safety)에 대한 올바른 이해

 

2.1 안전평가의 주요 방법들과 그 방법들의 단점

1. Safety Case 접근법
2. 규범적(prescriptive) 접근법
3. Bow-tie 모델
4. 위의 방법들의 단점

 

1) Safety Case 접근법

Safety Case는  증거에 의해 뒷받침되는 구조화된 논거(argument)로서 특별한 운영 환경에서 특정 어플리케이션에 대해 시스템이 받아들일 수 있을 정도로 안전하다는 것을 입증하는 것이 목적이다. 기본적으로  safety case는 시스템의 개념적인 설계가 안전한지를 입증하기 위한 논리적 구조를 반들어서 시스템과 시스템 환경에 대한 증거의 set에 의해 뒷받침된다. 이를 위해 Goal Structuring Notation(GSN)이라는 표기법을 사용하는데, 이것도 Safety case를 위한 방법 중의 하나일 뿐이다.

Safety case는  compliance assurance나 certificate issuance에 대한 반복 가능한 정의된 프로세스가 없을 때 혹은 정밀 조사중인 시스템에 대한 표준이 없을때 규제 당국이 받아들일 수 있는 수단으로 사용된다.

–> 정리하면, 관련 표준이 없을 때 Safety Case를 사용하여 시스템의 안전성을 논리적으로 구조화하고 이를 증거하는 자료를 통해 규제 당국으로부터 안전하다고 인정받기 위한 수단으로 사용된다는 얘기고, 표준이 있음 굳이 이것을 쓰지 않는단 얘기로 들림.

2) 규범적 접근법

이미 존재하는 시스템의 본질과 유사한 시스템을 개발한다고 가정을 한다면, 시스템의 기능에 대한 어떠한 가정을 근거로 compliance의 수단을 표준화하는 것이 가능하다. 예를 들어 avionics 소프트웨어 개발 프로세스는 DO-178C에 부합해야 하고 이것은 verification, validation, documentation을 고도로 표준화시킨다. fly-by-wire의 고안으로 인해 avionics 기능의 원칙은 중요하게 변경되지 않았다. 그래서 criticality level에 대한 공통된 분류를 할 수 있으며, 하드웨어에 관해서는 DO-254개발 표준이 compliance의 수단으로 요구된다. 이러한 표준들은 FAR 감항 규제에 상호보완적이며 performance parameterization, test criteria 등의 compliance를 요구한다. 이런 접근법은 규제에 대해 적합한지를 검증할 수 있는 평가 활동을 제공하는 official examiner에 의존한다.

이런 산업에서의 규범적인 안전 평가 접근법은 언제나 피평가자들에게 정량적 safety verification을 제시할 것을 요구한다.  규범적 접근법들은 분할 후 정복 접근법을 장려하기 때문에 시스템을 기능과 컴포넌트로 쪼개서 basic failure event를 식별하고 어디에서 이러한 이벤트들이 hazard를 촉발하고 어떤 결과로 hazard가 발생할 수 있는지를 확인하는 것이 쉽다고들 한다. (그런데 실제 그런가? ㅎ)

매우 중요한 것은 basic failure event의 발생 확률을 정량화하고 이런 확률이 중간 이벤트의 확률과 최종 결과의 확률에 어떤 영향을 미치는지에 대한 이해는 규제당국이 기각해서는 안되는 compliance의 기회를 제공하기는 한다.

–> (개인적 생각) 표준 방법에서 divide and conquer로만 해결하려고 하다보니 basic failure event를 정확하게 식별해야 하고, 그 event에 대한 probability를 알아야 하는데, 항상 알 수 있는 노릇도 아니고,

FTA의 정량적 분석에 관해서, ARP 4754a, 4761를 강의한 SAE강사도 그런 이야기를 하더라. 공식적인 답변은 아니겠으나.. 이런 식이었다.

"뭐 그 수치가 그렇게 정확할 것이라고 생각하지는 않겠으나, 
그렇다고 없는 건 곤란하다.."

그렇담 어쩌란 말인가? (대충철저하게 때우란 건가? ㅋㅋㅋ)

일종의 합법적으로 혹은 기술적으로 받아들여지는 요식행위(?)라도 되는 것을 인정한 셈인가? 마치 회계상의 어떤 기술적 방법에 대해 어떻게 보면 분식행위라고 여겨질 수도 있는 것에 대해 이건 예외~ 라고 하듯이 말이다.

흥미로운 얘기이다.

그러니까, 이 부분에 대해서 100% 장담할 수 없으니까, 오른쪽 발목을 건다거나 왼손을 건다거나 하는 무모한 일은 하면 안될 것이다. 장담은 금물.

 

3) bow-tie model

Bow-tie 모델의 사례는 그림 1에서 표현한 바와 같다. link는 hazard의 원인(FTA를 사용하여 모델링이 된다)이 되고 hazard의 결과(Event Tree Analysis(ETA)를 사용하여 모델링이 된다)가 된다. 그림 1의 pivotal event는 hazard라는 것과 정확하게 일치한다. 이 pivotal event는 일반적으로 main system이나 subsystem의 hazard에 대응된다. FT/ET pair는 각각의 hazard에 대해서 구축되며 값은 FT의 각각의 인과 요인의 발생확률에 할당되고 ET의 branch에 의해 표현되는 outcome mitigation의 success/failure 확률에 할당된다.

–> (개인적 생각) pivotal event에서 decomposition을 하게 되면 FTA가 되고, 여기서 break down된 event에 확률을 할당해 줘야 하는데, 이 부분이 TLS에서의 할당과 유사한 측면이 있으며, 이 부분이 굉장히 ad-hoc한 측면이 있을 수 있음. ETA의 경우에는 event별로 발생확률을 그래도 나름 정량화시켜서 표현할 수는 있겠으나, 다양한 환경적 요소들을 충분히 반영하지 못하게 만드는 문제가 있을 수 있음.

 

Figure 1. A generic example of Bow-tie model (논문에서 발췌함)

 

4) 주요한 방법들의 문제점

1. Safety case는 그럴듯해 보이는 거짓된 말일 수 있다. (의도적으로 속이진 않을 수 있겠으나).

귀납론의 문제는 black swan. black swan이 터지기 전까진 모든 swan은 white가 진리였음. 이것도 유사한 것이다. 그 말이 사실처럼 들리고 논리적이라고 생각이 될 수 있으나, 어디까지나 그 당시에 그렇게 생각되는 것일 뿐. 진실은 저 넘어에 있다.

1. 규범적 방법은 practice oriented된 방법인데, 이게 100%보증할 수 있는 게 아님.

• 복잡 시스템은 exhaustive testing이 불가능
• bow-tie model은 또한 거짓된 이야기에 속아넘어갈 수 있음

bow tie모델의 취약점

• 모든 hazard가 완벽한가? 누락된 게 없는가?
• 모든 hazard의 상호 의존관계를 정량화 할 수 있는가?
• 여러 이벤트들이 hazard들의 원인이 될 때 무엇이 공통원인이고 각 이벤트들의 hazard로의 기여도를 어떻게 알 수 있는가?

–> 아.. 이런 질문 들어오면 답없다. 그냥 무조건 항복이다.

 

 

3. 복잡 시스템을 위한 비 표준 안전 분석방법들

1. Multi-Agent Dynamic Risk Models(MA-DRM)
2. STAMP(Systems-Theoretic Accident Model and Processes)

 

–> (개인적 의견) MA-DRM은 A-SMGCS프로젝트를 하면서 알게 된 EMMA프로젝트에서 안전성 평가를 수행하기 위해서 사용하는 접근법이다. 기존의 전통적 방법들을 사용해서 안전성 평가를 한 결과 Eurocontrol에서 굉장히 우스꽝스러운 A-SMGCS의 안전성 평가결과를 만들게 되었고… 과거의 방법이 그다지 효용가치가 없다는 것을 알게 되어서 만들게 된 방법이다. 이제 A-SMGCS할 것도 아니니까 더 이상 알고 싶지는 않고.. socio-technical system에서 여러 이해관계자들의 복잡한 상호작용을 고려해야 하는 안전평가 모델로서, 다양한 평가자(무려 심리학자까지도 참여한다)를 참여시켜서 수학적 모델을 만들었다. (그런데, 그 수학 모델은 어떻게 검증을 ??) 그리고 prototype을 만들어서 그 모델을 검증을 한다. (그렇다면 제품 검증은 어떻게??)

그래서, 유럽에선 A-SMGCS를 20년 넘게 개발하고 있고, 인증이라는 제도에 대한 개념이 아직 성숙되지 않았다고 판단하고 있는데, 자랑스러운 대한민국에서는 5년내 세계선도하는 제품을 만들겠다고 R&D를 했다가 인증이 안될 것 같다고 drop을 시켜버린…

 

(paper) 항공분야의 복잡 시스템을 위한 안전분석 방법들(1)

SAFETY ANALYSIS METHODS FOR COMPLEX SYSTEMS IN AVIATION

항공분야에서 사용되는 안전 평가 방법들에 대한 설명을 비교한 논문이다.

일단 이 page에서는 TLS의 허무맹랑함(?)에 대해서 기술한 부분만을 정리한다.

 

• Avionics시스템과 관련된 표준들은 ARP4754A
• CNS/ATM시스템과 관련된 표준들은 DO-278A

ARP4754는 어떤 인증 프로세스에서 기반해야 하는지에 대한 전체적인 원칙들을 나열하였고, 시스템 개발 프로세스는 safety goal을 보장하기 위해서 존재해야 한다고 정의하고 있다. 이러한 표준들은 bottom up방식으로 항공 표준에서 기원하였고 나중에 규제기관에서 채택하였다. (규제기관에서 규정하여 아래로 확산된 방식이 아닌 산업에서 표준화하여 규제기관에서 채택했다는 의미에서 bottom up)

규제기관들은 운영 수준(operation level)에서 어떻게 양적 TLS(quantitative Target level of safety)를 수립(establish)할지에 대해 기술하지 않는다. [operation level이라는 것이 ISO26262관점에서는 vehicle level 혹은 concept level의 의미가 됨]

왜냐면 이것은 risk acceptance를 기반으로 한 사회적 결정(societal decision)이고 일반적으로 ICAO나 FAA, Eurocontrol과 같은 정부 기관에 의해 정의되기 때문이다.

실제로, 규제기관에서는 혼합된 방식의 양적 및 질적 요구사항을 사용한다. ICAO Doc 9859는 안전 관리를 양적 TLS로 정의하지 않는다.  거기에는 다음과 같이 적혀 있다.

“양적 안전 성능 목표가 설정되면 양적인 방식으로 달성된 안전 목표를 측정하거나 예측할 수 있어야만 한다. 양적 데이터의 사용은 결정을 명확하게 하는데 도움이 되며 가능하다면 사용되어야 한다.(should – shall이 아님)”

“whenever quantitative safety performance targets are set, it must be possible to measure, or estimate, the achieved level of safety in quantitative terms. Use of quantitative data helps clarify most decisions and should be used where available”.

air traffic에서의 충돌 risk에 대한 특별한 측면에서 봤을 때, ICAO의 Annex 11은 충돌 확률에 대해 양적 TLS를 수립하였다. 이 TLS는 역사적 통계를 기반으로 하고 부분적으로 “희망하는” 목표치를 기반으로 한다.

For the specific aspect of collision risk in air traffic, ICAO’s Annex 11 [4] establishes a quantitative TLS for the collision probability. It is known that this TLS is partly based on historical statistics, partly on a “desirable” target.

게다가 그것은 충돌 위험을 3가의 공간적 차원(lateral, longitudinal, vertical) 으로 동등하게 분할하여 각 차원당 5.0E-09를 도출한다.이런 동등하고 독립적인 분할은 가정사항이지만 합리적으로 타당한지를 따져서 한 것은 아니다.

 

소결론

TLS라는 것이 하나의 우리가 나아갈 방향이고 이상향이며, 우리가 추구해야 할 목표이지. 그것이 현실은 아니다. 그리고, 그 이상향을 추구하는 전략 수립(decomposition of TLS, or apportionment of target level of safety)시 그것이 타당하다고 볼 만한 근거가 있는 것은 아니다. engineering적으로 평가할 때, 평가하기가 곤란한 측면이 있다는 얘기고, 이걸로 비전문가가 “인증”운운하며 뭐라고 얘기하면 정말 클난다.

사람잡는데는 선무당만한게 없다.