카테고리 보관물: Paper

(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적으로 평가할 때, 평가하기가 곤란한 측면이 있다는 얘기고, 이걸로 비전문가가 “인증”운운하며 뭐라고 얘기하면 정말 클난다.

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

 

 

(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 논문 오랜만이다. 대학원 때 이후로 첨이니…

 

제 3자 평가가 할 수 있는 것과 없는 것


다음의 논문을 읽다가 문득 든 생각이다.

Security Process Capability Model Based on ISO/IEC 15504 Conformant Enterprise SPICE

SPICE기반으로 보안 프로세스 역량 성숙모델을 개발한 논문이다.

다음과 같이 프로세스를 만들었다. 훌륭하다.

PRIM.RISK.1. Security Vulnerabilities

Purpose Outcomes
To identify, analyze and report information security vulnerabilities of an artifact to be protected 1) Information security vulnerability analysis strategy is developed and maintained;
2) Vulnerabilities are identified;
3) Vulnerabilities are analyzed;
4) Dependent vulnerabilities are derived;
5) Information security vulnerabilities are reported.
Base Practices
PRIM.RISK.1.BP.1: Develop and maintain information security vulnerability analysis strategy. [Outcome: 1]

PRIM.RISK.1.BP.2: Identify vulnerabilities. [Outcome: 2]

PRIM.RISK.1.BP.3: Analyze vulnerabilities. [Outcome: 3]

PRIM.RISK.1.BP.4: Derive vulnerabilities. [Outcome: 4]

PRIM.RISK.1.BP.5: Report information security vulnerabilities of an artifact. [Outcome: 5]

 

문제는 저렇게 한건 좋은데, 그래서 security를 달성했다는 것을 검증하는 입장에서는 어떻게 확인할 수 있을까? 저렇게 하라는 대로만 하면 되는건가?

 

사람은 누구나 옷을 입는다. 정상적이지 않은 일부의 사람들이 공원에서 홀랑 벗고 돌아다니다가 경찰에 붙잡히기도 하지만..

옷을 잘 입기 위한 프로세스를 만든다고 치자.. 목적은 멋쟁이가 되기 위한 것일 것이다. 그래도 그런 절차가 목적을 달성해주지는 못할 것이다. 그렇게 해도 패션 테러리스트들에게 있어서 달라지는 것은 없을 것이라 본다.

위의 논문에서도 만든건 좋고 훌륭하다. 그 자체에 대해 뭐라고 하고 싶은건 아니다. 다만 그 행위가 과연 충분히 달성되었는지를 어떻게 입증할 것인지에 대해서는 답을 줄 수가 없다.

제 3자 평가라고 하는 것이 그것이 safety가 되었건 security가 되었건 제 3자가 product에 대한 기본적인 지식이 별로 없는 사람들이 safety/security의 충분성을 평가하기가 쉬울까?

제 3자 평가자라고 하더라도 사람마다 평가 기준이 각기 다를 것이고, 그것을 specification하는 것은 굉장히 어려울 것이다. 그리고 그렇게 하는 순간, 그것을 비웃으면서 우회할 수 있는 수많은 방법들이 생겨나게 될 것이다.

여러모로 굉장히 어려운 일이다. 이런점에서 제3자가 security나 safety에 대해 평가한다는 것은 일정정도 한계를 가질 수 밖에 없고, 그들이 아무리 평가를 한다고 해도 완전하게 할 수는 없다.

하지만 관리적인 차원의 활동은 좀 얘기가 달라질 수 있다. management측면의 프로세스 활동에 대해서는 엄격한 기준과 잣대를 표준화시킬 수 있다.

 

패션 테러리스트들에게 패션 리더가 되기 위해서는 무엇이 필요할까? 프로세스가 필요하다고 생각하는가? 우스운 일일 것이다. 감각을 갖춘 best practice를 보면 될까? 조금은 나아질 것이다. 그렇다고 없던 감각이 생겨나진 않지 않을까? 여전히 어설프고 이상한 복장이 되지 않을까?

패션리더가 되었다는 것을 평가를 제 3자 평가자가 한다고 하면, 그런 sense에 대해 객관적이고 표준화시킬 수 있는 지표라는 것이 존재할 수 있을까? 제 3자 평가라는 것이 가능하기나 한건가? AI가 바둑도 정복하고 스타크래프트도 정복하려고 하는 마당에 언젠가는 정량화 시킬 수는 있을거라고 생각하는데, 현재로서의 ‘나’는 아직 답을 모르겠다.

safety나 security도 이와 유사하지 않을까 하는것이 개인적 생각이다. 최신 자료 계속 리서치하고, best practice를 계속 따라하는 수 밖에 없다. 그것이 패션 테러리스트들의 슬픈 숙명이다.