카테고리 보관물: Integration Process

(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을 시켜버린…

 

시스템 및 소프트웨어 요구사항 관리 방법?


휴가중에 최근 어떤 분이 다음과 같은 문의를 해주셨다.

“어떤 경우 시스템 요구사항과 소프트웨어 요구사항이 겹치는 것 같다. ”

이 부분은 어느정도 사실이다. 그리고 좋은 현상이다. 다만 시스템의 scope와 소프트웨어의 scope간의 경계를 어떻게 정할 것인지에 대해서 약간은 명확하지 않아서 어려움을 겪고 계신 것이라고 생각한다.

요구사항을 작성하려면 그게 sys일지 sw일지에 대해서 생각해 보지 말고, 일단 interface가 어떤 형태일지 생각해보자. interface가 작성하고자 하는 요구사항의 scope가 된다. 꼭 sys로 작성하고 sw로 한번 더 작성해야 한다고 생각할 필요는 없다. 장난감을 만드는 경우라면 굳이 분리하는 것이 의미가 없을 수도 있고, 거대한 것을 만드는 경우라면 분리를 해야만 관리가 용이할 것이다.

그리고 interface를 정의했으면, 그 interface를 가지고 검증을 한다고 생각을 하라. 우리의 신체를 예를 들어서 설명하자면, 췌장에 염증이 있는지 없는지를 확인하기 위해서 배를 갈라서 뱃속을 뒤적거리면서 정상인지 확인할 수 있는 방법이 있다.

소프트웨어에 인터페이스가 정의되어 있지 않으면 췌장 검사하듯이 소프트웨어의 배를 갈라야 할 것이다.  무슨 이야기를 하고 싶은거냐면, 저렇게 하면 안된다는 얘기를 하고 싶은거다. 머리가 좀 아프면 두개골을 열어보고 어디 문제 있는지 확인할건가? 그런 생각을 가지고 있는 사람은 별로 없을 것이다.

결국 요구사항을 정의할 때 검증 가능성에 대해서 생각을 해 봐야 한다는 의미가 된다. 그게 가능할지의 여부는 정의한 interface에 의해 결정이 된다. 또한 어떤 장비를 사용하느냐에 따라서 관찰 가능성의 범위가 달라질 수 있다. 디버그 장비를 이용해서 trace를 이용하거나 디버그 장비를 이용해서 오실로스코프를 이용해서 검증할 수도 있겠다. 혹은 대상 시스템의 출력 인터페이스를 이용해서 관측한 결과를 가지고 검증할 수도 있다.

어떻게 하더라도 상관은 없다. 불편하게 검증하고 싶으면 불편한 거고, 편리하게 검증하고 싶으면 편리한 것이고 개인적인 취향일 수도 있으니까.

여기까지 제대로 따라왔다면 interface가 정의되었고, 대상의 boundary가 정의된 것이기 때문에 작성하고자 하는 scope가 결정된것이다. 여기서 requirement라는 것을 작성한다고 하면 interface및 boundary를 감안해서 정의를 하도록 가급적 노력해야 한다.

물론 모든 경우에 적용할 수 있는 그런 법칙같은 것은 없다고 생각해야 하겠으나, 일반적으로 적용 가능한 법칙은 다음과 같다.

interface를 INPUT_SET, OUTPUT_SET으로 정의를 하고, INPUT_SET은 입력 interface의 집합, OUTPUT_SET은 출력 interface의 집합으로 정의를 하자면,

요구사항의 집합인 REQUIREMENT_SET은 다음과 같이 정의를 할 수 있다.
OUTPUT_SET = function of (State, INPUT_SET)

다만, 시스템 범위의 비기능 요구사항들이 저런 방식으로 정의가 가능한지는 확실치는 않고, 기능적 요구사항은 저렇게 정의할 수 있다. Simulink나 stateflow를 떠올려보면 쉽게 상상이 될 것이다. state machine의 수학적 정의가 저렇게 된다.

여기서 이 글을 쓰게 된 동기인 요구사항 겹침 문제로 돌아가보자.

sys간 요구사항과 sw간 요구사항은 겹친다. 겹칠 수 있다. 그것이 자연스러운 것이고 정상적이다. 그런데, 장난감을 만드는 것이 아니라면 sys요구사항이 sw요구사항을 전부 포함하거나 sys요구사항 및 설계에서 sw요구사항 및 설계를 포함한다면 그것은 바람직하지는 않은 것 같다.

그럼 정확하게 어떻게 분리를 시킬 것인가?

sys의 기능적 요구사항 중 일부분(REQ_SYS_FUNC1)이 sw로 구현한다면 REQ_SYS_FUNC1은 시스템 요구사항이면서도 sw요구사항이 될 수 있다.

여기서 한 단계 더 나아가자면, sys로부터 할당받은 sw 요구사항은 보다 상세화시킬 수 있다.

여기서 좀 다른 얘기로 들릴 수 있지만, sw요구사항을 작성한다는 것은 기술 문서를 작성하는 것이다. 기술 문서를 작성하기 위해서는 문서 작성 교육을 받아야 한다. 주제를 잡고, 개요를 짜서 문서의 뼈대를 만들고, 스타일을 적용해서 두괄식으로 할지 미괄식으로 할지….

sys로부터 할당받은 sw요구사항을 어떻게 상세화 시킬 것인가? 이 부분은 그 주제로 어떻게 기술문서를 작성하도록 하느냐와 유사하다. 그리고 그것은 분명히 sys 수준과는 차이가 있어야 한다. 어떻게 하냐고 묻는다면 그것은 위에서 이야기 했던 것들을 고려하고 기술문서 작성을 위한 고민을 해봐야 한다.

아무래도 무슨 말인지는 대충 알겠는데, 그래서 어떻게 하라는지 좀 이해가 잘 안될 것이다. 그렇다면 이제부터 고민해보시길 !

Examples of conflicts with engineers in review meeting and solutions (산출물 검토시 엔지니어와의 갈등 사례 및 해결방법)


한글 버전은 아래로. korean version is below.

When I work as a consultant, I do a lot of different things. The original scope did not have to do this, but when I saw my customers are drowning I have no choice but to save them.

Anyway … If you review the output, you will be in a fate that can not help but posing a problem with the contents expressed inevitably. Then, when the situation that is really common comes up a lot of questions like “Why can not you do this?”

There is a problem like this, and it is good to express it this way. I’m talking about it, but most engineers are a little annoyed at the time. It means that you have to do again what you did.

In general, engineers are awkward in writing technical documentation. But do not you think it’s annoying because you have to write a document? I understand too. But is any alternatives? This is important in the company, and the company trust you to do that important thing.

Most of the time I asked from my customers was to show them examples. And finally, I will work with the customers.

Again, the conflicts often arise in the review meetings, and inevitably there will be conflicts with the engineers who identify their products with oneself.

At this time, I change my role as a certification assessor. At this point, I should be able to explain what he can accept. If that does not work, the consultant can be seen as an incompetent consultant who does not know well.

It is important as a consultant to pass this part well.

Consultant should not only provide DO-178C solutions but also provide judgments as a certification assessor. Obviously, this is not easy, but in order to do this in this area, you have to have this.

컨설턴트로 일하다보면, 진짜 별의별 일을 다 한다. 원래 scope에는 하기로 한 일은 아니었으나 고객이 허우적 거리고 있는데 나 몰라라하고 발뺌하고 있을 수도 없다. 계약 전에는 자기는 수영 전문가이고 1시간 자유 이용권에 해당하는 비용만 지불하겠다고 떼를 써서 그런가보다 하고 계약을 했는데, 입수 후 10분도 안돼 맥주병처럼 되어버린 상황이다.

어쨌건..산출물에 대해 검토를 하다보면 필연적으로 표현된 내용에 문제를 제기할 수 밖에 없는 운명에 놓이게 되고, 이 부분에 대해 지적질을 할 수 밖에 없다. 그때 정말 흔하게 나오는 상황이 “왜 이렇게 하면 안되는 것이냐?”라는 식의 질문을 많이 하게 된다.

그때 이런 저런 문제가 있고, 이런식으로 표현을 하는게 좋다. 는 식으로 이야기를 하게 되는데, 그 때 대부분의 엔지니어는 좀 많이 짜증이 나는가보다. 자기가 한 일을 다시 해야 하게 되는 것을 의미하기 때문이다.

일반적으로 엔지니어들은 기술문서작성에 서투르다. 국어를 못하니까 이과로 온 것이고(나또한 그러하다.) 그런데, 회사와서 국어하라니까 좀 짜증나지 않겠는가? 나도 이해 한다. 하지만 어쩌겠는가? 회사에서 이게 중요한 일이고, 그 중요한 일을 당신을 믿고 맡긴 것인데..대부분 이때 example을 보여달라고 요청을 하기도 한다. 그러다가 결국 컨설턴트와 공동 작업을 하게 되는 결론을…ㅎㅎ

다시 원래대로 돌아가서, 검토 회의에서 이런 갈등이 자주 발생하게 되고 자신이 만든 산출물을 자기와 동일시 여기는 엔지니어들에 대해서는 필연적으로 갈등이 생길 수 밖에 없다.

이때는 마치 인증 평가자의 입장으로 전환하게 된다. 그리고 DO-178C 요구사항에 대한 부적합 사항을 제시하게 된다. 이 때 엔지니어가 받아들일 수 있도록 설명을 해 줄 수 있어야 된다. 만약 그게 잘 안되면, 그 엔지니어에게 컨설턴트는 ‘잘 알지도 못하는 무능한 컨설턴트’로 비춰질 수 있다.

이 부분을 잘 넘기는게 컨설턴트로서 중요하다.

DO-178C에 대한 솔루션을 제공함과 동시에 인증 평가자로서의 판단력도 동시에 가지고 있어야 한다. 당연히 쉽지 않은 일이지만, 이 분야에서 이런 일을 하려면 이정도는 갖춰야 한다.