태그 보관물: STAMP

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

 

Safety-driven MBSE methodology


제목: 안전 주도형 모델 기반 시스템 공학 방법론

Overview

2007년에 나온 논문으로 Specification에 대한 방법론을 기술한 것이다.

외부 행성 탐사 미션에 대한 안전 주도 설계 방법론의 적용을 보면서 참조문헌으로 찾은 논문이다.

Safety-driven model based system engineering methodology의 part 1, part 2가 있는데, 그 문헌에서 하나의 project에 대해서 나름 자세하게 내용을 기술하였다.

아래 그림은 seamless하도록 specification을 하기 위해 각 contents에 대한 traceability graph를 그린 것이다. 아래 그림에서 빨간색으로 표시한 것은 논문의 내용과는 다르게 필자의 임의로 수정한 것.

보면 알겠지만, ISO26262나 ARP4754a의 내용과 약간 유사하다고 볼 수 있다.

traceability

각 step에 대한 상세한 설명은 참조보고서에 기술되어 있다.

Part 1에서는 step-by-step으로 기술하였고, Part 2에서는 9 step을 다 완료하고 각 step에서 나온 결과물을 재구성하고 조합하여 정리한 버전으로 기술되어 있는데, 문서의 흐름이 step과는 맞지 않아서 첨엔 읽는데 혼동이 있었다.

또 하나의 흥미로웠던 점은 보고서에서 나온 방식대로 specification을 하게 된다면, 굳이 doors나 관리도구를 사용하기보다는 text-editor정도로도 충분하지 않을까 하는 생각을 갖게 되었다.

xml schema를 정의해서 위의 그림에 대한 field를 정의해서 coding하듯이 specification을 하는 것도 방법이 될 수 있겠다고 생각이 들었다. 그렇다면 text기반이기 때문에 변경이력 관리도 굉장히 편할 수 있을 것이고..

 

Model based Systems Engineering 방법론 설명

Step 1~Step 9를 정의하였으며, 각 단계에서 수행한 결과를 간단하게 기술하였다. Systems engineering에 대한 기본적인 지식이 있다는 가정하에 자세한 설명은 하지 않으므로, 내용이 잘 이해가 되지 않거나 자세히 알고 싶다면 원문을 참조바람.

 

Step 1: Identify Mission Goals, Requirements and Constraints

vehicle level에서의 목표, 요구사항, 제약사항을 식별하는 단계임. Step 1에서 수행한 결과물의 예제는 아래와 같음. 아래의 G1, G2, G3는 일종의 ID로서 해당 spec의 property(goal)을 의미하기도 하며, 도구에 의해 추적 관리가 가능하게 될 것임. 그리고 SV는 State variable의 약자로 거의 대부분의 Spec마다 붙어 있음. 쉽게 말하면 일종의 ‘소프트웨어의 변수’로 이해하면 될 듯.

  • G1. Characterize the presence of a subsurface ocean on an icy moon of an outer planet (Clark, 2007). (↑ACC4ACC5), (→HLR3, HLR4), (↓SV-81)
  • G2. Characterize the three-dimensional configuration of the icy crust of the icy moon of an outer planet, including possible zones of liquid (Clark, 2007). (↑ACC4, ACC5), (→HLR1, HLR2, HLR3)
  • G3. Map organic and inorganic surface compositions of the icy moon of an outer planet, especially as related to astrobiology (Clark, 2007). (↑ACC4, ACC5), (→HLR2, HLR3)
  • G4. Characterize surface features of the icy moon of an outer planet and identify candidate sites for future exploration (Clark, 2007). (↑ACC4, ACC5), (→HLR1, HLR2, HLR3)

 

  • HLR3. The mission shall image TBD% of the surface of the icy moon of the outer planet in spectra other than visual and infrared, to a resolution of TBD. (←G1, G2, G3, G4, G6), (→S/C-G1, S/C-G2, S/C-R1, S/C-R2),(↓2.1, SV-1, SV-101, SV-102)
    Rationale: The other bands of the spectrum provide insights into the chemical composition of the icy moon

여기서 화살표의 의미가 추적 관계에 의한 연결 방향으로 생각이 되는데, 첫번째 그림에서 필자의 임의로 수정을 한 부분이 있어서 큰 의미를 둘 필요는 없다고 생각이 됨.

 

Step 2: Define System Accidents or Unacceptable Losses

시스템과 관련된 사고를 정의한다.

 

  • ACC1. Humans and/or human assets on earth are killed/damaged. (↓PC1, H5, SV-77, SV-78, SV-79)
  • ACC2. Humans and/or human assets off of the earth are killed/damaged. (↓PC1, H6, SV-77, SV-78, SV-79)
  • ACC3. Organisms on any of the moons of the outer planet (if they exist) are killed or mutated by biological agents of Earth Origin. (↓H4)
  • ACC4. The scientific data corresponding to the mission goals are not collected. (↓G1, G2, G3, G4, G5, G6, G7, H1, SV-80)
  • ACC5. The scientific data corresponding to the mission goals is rendered unusable (i.e., deleted and/or corrupted) before it can be fully investigated. (↓G1, G2, G3, G4, G5, G6, G7, H2, H3, SV-80)

 

Step 3: Define High-level Hazards

상위 수준에서의 위험요인을 정의한다.

 

  • H1. Inability of Mission to collect data. (↑ACC4), (↓SV-85)
  • H2. Inability of Mission to return collected data. (↑ACC5), (↓SV-86)
  • H3. Inability of Mission scientific investigators to use returned data. (↑ACC5), (↓SV-7, SV-88)

 

Step 4: Define High-level Safety-related Constraints

상위 수준의 안전 관련 제약사항을 정의한다.

  • H1. Inability of Mission to collect data. (↑ACC4), (↓SV-85)
    • SC1. The mission must have the necessary functionality for data acquisition at the required times. (←H1), (→MOC-G1, MOC-G2, MOC-G3, MOC-G4), (↓2.1, 2.2, 2.4, SV-85)
  • H2. Inability of Mission to return collected data. (↑ACC5), (↓SV-86)
    • SC2. The mission must be able to return data at the required times. (←H2), →MOC-G1, MOC-G2, MOC-G3, MOC-G4), (↓2.1, 2.3, 2.4, 2.5, SV-86)
  • H3. Inability of Mission scientific investigators to use returned data. (↑ACC5), (↓SV-87, SV-88)
    • SC3. Mission scientific investigators must be able to use the data from the mission at the required times. (←H3), (↓2.1, 2.3, 2.4, 2.5, SV-87, SV-88), (→MOC-G1, MOC-G2, MOC-G3, MOC-G4)

 

Step 5: Identify Environment and Customer Constraints

skip

Step 6: Perform High-level Functional Decomposition

상위 수준의 기능에 대해 decomposition을 하면서 grouping을 수행한다. Design structure matrix도구를 사용한다. 시스템 수준에서의 여러가지 기능을 sub-system으로 allocation하기 위한 단계라고 볼 수 있다. 설계 원칙인 loosely coupling, tightly cohesion을 최대한 준수하기 위한 방법론이다. 아직 여기까지는 safety관점의 아키텍처 평가는 수행하지 않았다.

DSM에 대한 내용은 다음의 링크를 참조(Design Structure Matrix 활용)
DSM을 통해 수행한 결과 다양한 function들을 그룹화하여 4개의 sub-system으로 정리를 했다.

dsm

 

Step 7: Design High-level System Control Structure

sub-system을 정의하고 각 요소간의 구조를 정의한다. 시스템 아키텍처 수준의 활동이라고 볼 수 있음

moc

 

Step 8: Perform Preliminary Hazard Analysis

ARP4754a의 시스템 예비 안전 평가와 유사하다. DSM및 Control structure를 작성한 것을 가지고 hazard를 고려하여 시스템 설계가 적절한지의 여부를 평가한다. 이 작업을 하다가 DSM 및 control structure의 단계로 다시 돌아가서 수정 작업을 할 수도 있다.

pha

 

Step 9: Define System Element Specifications

각각의 sub-system에 대해 기술한다. 여기서부터는 DO-254 혹은 DO-178C의 단계(혹은 ISO26262-6의 단계)에 해당한다.

Step 9의 내용은 Generating requirements for complex embedded system using State Analysis를 참고

 

결론

  • Specification이 비교적 seamless하게 정의되어 있다.
  • Specification단계를 절차화하여 이해하기 쉽다. (그런데 생각해보니 ARP4754나 ISO26262도 마찬가지 인거 같기도 한데.. 이 논문이 좀 더 step이 명확하다.)
  • 사례가 있어서 specification 내용을 보고 배우기 좋다.
  • 수준별 specification의 scope의 혼란이 많지 않을 것으로 생각된다.

 

보다 자세한 설명이 필요하다면 원문을 참고하거나 댓글로 문의사항을 남겨주기 바랍니다.

(paper) 외부 행성 탐사 미션에 대한 안전 주도 설계 방법론의 적용


우리나라의 우주 산업도 언젠간 이런 level까지 올라갈 수 있기를 기대한다. domain은 우주이지만, 실제 내용은 Specification, safety engineering에 대한 내용이다.

(핵심 내용) 주요 기술 4개의 integration

  1. Intent Specification, a framework for organizing system development & operational information in a hierarchical structure
  2. 사고의 인과관계를 STAMP model로 제시
  3. STAMP기반 위험원 분석(STPA)
  4. State Analysis, 모델 기반 시스템 엔지니어링 접근법

논문에서 하고 싶은 말이 얼마나 많았던지 24페이지인데, 개인적으로는 사실 100페이지로도 부족할 것 같다. 24페이지로 상당히 압축을 잘 한 것 같다. (그래서 참조문헌을 다 뒤져봐야 내용을 온전히 이해할 것 같은 심오함은 약점)

Intent Specification

Intent spec hierarchy

출처: Brandon D. Owen 2007

각 Level에 대한 설명은 아래와 같은데, 본 논문에서는 Level 0~3에 대하여 focus를 맞추고 있음

Level 0: a project management view and insight into the relationship between the plans and project development

Level 1: the customer view and assists system engineers and customers in agreeing on what should be built and whether that has been accomplished. It includes system goals, highlevel requirements, design constraints, hazards, environmental assumptions, and system limitations.

Level 2: (System Design) the structure and content needed for engineers to reason about the system in terms of the physical principles and laws upon which the system design is based. It documents the basic system-level design decisions made to satisfy the requirements and constraints at Level 1.

Level 3: (Blackbox Behavior level) enhances reasoning about the logical design of the system as a whole and the interaction among the components as well as the functional state without distractions from implementation issues. This level acts as an unambiguous interface between systems engineering and component engineering to assist in communication and review of component blackbox behavioral requirements and to reason about the combined behavior of individual components using informal review,
formal analysis, and simulation. The models at this level are formal and can be both executed and subjected to formal analysis (for example, completeness and consistency
analyses).

Level 4,5: provide the information necessary to reason about individual component design and implementation issues.

Level 6: provides a view of the operational system

 

STAMP와 STPA를 기반으로 한 안전 주도 설계 방법

Step 1: Identify Mission Goals, Requirements, and Constraints.
Products: Level 1 intent specification of mission goals and constraints

Step 2: Define System Accidents or Unacceptable Losses.
Products: Level 0 intent specification documenting the accidents.

Step 3: Define High-level Hazards.
Products: Level 1 intent specification documenting high-level hazards.

Step 4: Define High-level Safety-Related Constraints.
Products: Level 1 intent specification documenting safety constraints.

Step 5: Identify Environment and Customer Constraints.
Products: Level 1 intent specification of environmental constraints and environmental
assumptions, customer-derived system design constraints, and customer programmatic constraints.

Step 6: Perform High-level Functional Decomposition.
Products: Level 1 intent specification documenting the functional decomposition.

Step 7: Design High-level System Control Structure.
Products: Level 1 intent specification documenting the high-level control structure.

Step 8: Perform Preliminary Hazard Analysis using STPA and Create Hazard Log.
Products: Level 1 intent specification documenting STPA hazard analysis.

Step 9: Define System Element Specifications.
Products:
• Level 1 intent specification documenting goals, requirements, design constraints, and safety constraints for each subsystem or functional element (including subsystems and/or functional elements defined both before Step 9 and during the iterative
sub-steps of Step 9).
• Level 2 intent specification documenting design decisions made to implement the requirements and constraints in Level 1.
• Level 3 intent specification documenting the formal design of the control system.

Step 10: Perform Validation Tests.
Products: Test results.

Step 11: Generate Designs and Software Code.
Products: Design specifications and software code

 

위의 방법론을 이용하여 Specification 사례가 있는데, seamless하다는 느낌을 받는다. 굉장히 논리적이고 설득력이 있어보인다. (이 정도까지 해야 하는가? 라는 생각이 살짝 들기도 하지만 훌륭하다. )

시스템 Level에서의 Goal, Requirement, Constraint를 만들고, 이를 바탕으로 design decision을 만들고, 이것을 바탕으로 functional model을 만들고, DSM(design structure matrix)방법으로 design을 하고, State analysis를 하는 방식으로 굉장히 깔끔하게 흘러간다.

 

굉장한 Spec덕후가 아닌가 싶음…full paper를 보고 싶은데.. 1000페이지 되어도 좋으니 말이다.

Spec 논문 오랜만이다. 대학원 때 이후로 첨이니…