카테고리 보관물: ARP 4761

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


목차

 

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별로 발생확률을 그래도 나름 정량화시켜서 표현할 수는 있겠으나, 다양한 환경적 요소들을 충분히 반영하지 못하게 만드는 문제가 있을 수 있음.

 

bow-tieFigure 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) 항공분야의 복잡 시스템에 대한 안전 분석 방법들(0)


출처: safety analysis methods for complex systems in aviation

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

 

논문에 대한 개인적 의견:

현재의 기술로는 부족한 점들이 많다. 표준으로 정의한 것들(ARP 4754a/ARP4761)을 따른다고 과연 safety를 달성할 수 있을지에 대하여 회의적인 시각을 갖게 되었다.

산업적인 측면에서 봤을때는 고객이 해달라는 대로 해줄거고, 그게 보통은 표준에서 요구하는대로 수행하는 것일 게다. 그런데, 문제는 고객도 safety에 대해 잘 알지 못하고, 공급자도 safety에 대해서 잘 모르기는 마찬가지이다.

개인적인 의견은, safety는 고객이 알고 있어야 하고 validation을 해야 한다. supplier입장에서는 safety를 vehicle level에서 바라보기에는 한계를 가지고 있기 때문이다.

프로세스와 기술적 방법이 문제가 아니다. 그거야 오히려 비교적 쉽다. 문제는 그걸 따른다고 safety가 달성되는 관계가 아니라는 것이 문제이다.

그렇다고 비표준 방법인 안전분석법을 supplier가 수행한다면? 아마도 고객의 입에서는 이런 이야기가 나올것이다.

‘당신이 뭔데 그런 듣도보도 못한 방법을 쓰느냐?’

그리고 supplier의 경영진들 또한 이러한 말을 할 것이다.

‘고객이 시키지도 않는데, 그렇게까지 굳이 해야겠니?’

Safety에 대한 산업측에서의 적용은 그래서 굉장히 애매하면서도 일부 이해되지 않지만 그냥 하라는 대로 하는 형태(best practice)로 될 가능성이 높다고 본다.

나중에 사고가 나면 누가 잘못한 것인지 blame게임을 하게 될거고… 악순환은 반복될 것이다.

그래도 언젠간 나아지겠지..

(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

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

 

결론

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