카테고리 보관물: Paper

안전 무결성 수준의 사용, 잘못된 사용을 이해하기(1)


오래된 논문이기는 한데, functional safety의 기본을 이해하는데는 도움이 될 만한 내용이라고 생각됨.

Abstract

안전 시스템의 현대 표준들은 안전 무결성 수준(SIL)의 개념을 채용한다. 시스템의 증가는 구매자들이 공급자에게 그들이 SIL 개념(concept)을 사용하여 시스템이 개념을 적용하려 하였다는 것을 입증할 것을 기대한다. 그러나 표준들은 SIL에도 차이가 있으며 개념을 만족스럽게 설명하지도 않는다. 그 결과 종종 오해를 불러일으켜서 일관성 없고 부정확하면서 부적절하게 사용되는 결과를 초래하게 된다.

이 논문은 SIL개념 및 그 적용에 대해서 설명하며 어떻게 SIL이 3개의 안전 표준들로부터 파생된 것인지에 대한 사례를 제공한다. 그런 다음 어떻게 SIL 개념이 오해를 불러일으켜서 오해시킬 만큼 사용되는지를 보일 것이다. 그리고 SIL과 리스크 감내정도(risk-tolerability) 판단(decision) 사이의 관계에 대해 논의할 것이다.

1 Introduction

안전 무결성 수준의 개념은 안전 중요 시스템 분야에서 일반적이며 많은 표준들이 안전 중요 시스템의 설계와 개발에서 그 사용을 옹호한다. 하지만 다양한 표준들이 SIL을 다르게 사용할 뿐만 아니라 어떻게 그 개념이 파생되었고 적용되는지에 대해서는 알려주지 않는다. 그 결과 SIL은 잘못 이해되게 되었다. 반면 그 개념이 안전의 달성(achievement) 및 입증(demonstration)을 가능하도록(facilitate) 의도한 반면, 많은 경우에 오해와 실망을 유발하게 되었다.

더욱이, 비록 SIL의 파생과 적용이 복잡하기는 하고 오해될 수 있다고는 하지만 그것은 개념적으로 간단하며 쉽게 설명될 수 있다. 그 결과 SIL개념은 불완전하게 사용되고 종종 부정확하고 부적절하게 사용된다.

이 논문의 목적은 SIL개념을 설명하기 위한 것이다. 그것을 하기 위해, 이 논문은 일반적인 설명뿐만 아니라 SIL이 파생되고 3개의 최신 표준들에 따라 어떻게 적용되는지에 대해서 설명할 것이다.

이 논문의 further 목적은 SIL개념이 오해를 불러일으키는 방법에 대한 관심을 이끌어내고 어떻게 그것이 잘못 이해되고 잘못 사용되는가에 대한 것이다. SIL 개념은 tool이며 다른 tool과 같이 현명하게 사용하면 유용하지만 잘못 적용된다면 문제를 유발할 수 있다.

2 What are Safety Integrity Levels?

SIL개념은 지난 20년동안 시스템의 안전에 대한 상당한 노력이 투여된 곳에서부터 출현하게 되었다. 2가지 요인이 주요 영향으로 두드러졌다.

첫번째는 시스템은 안전하거나 안전하지 않을 수 있다는 식의 2진 속성을 가진 믿음으로부터 절대적인 안전과 어떤 재앙 사이의 연속체가 있고 연속체는 위험의 척도라는 이해로 이동한 것이다. 이것은 위험 분석을 안전 관련 시스템의 개발에서 중요 요소가 되도록 이끌었다.

두번째 중요 인자는 안전 분야에 있어서 소프트웨어(그리고 마이크로 프로세서와 같은 복잡한 하드웨어) 사용의 커다란 증가이다. 이것은 random및 systematic fault사이의 균형을 변화를 유발시켰다. 이전에는 안전은 reliability를 통해서 달성될 수 있을 것이라고 (종종 암묵적으로)가정하는 것이 일반적이었고 aggregation, 종종 fault tree, component의 random failure rate를 통해 시스템의 reliability에 대한 값을 낮춤으로써 safety가 달성되었다. 어떤 경우 failure rate는 component의 역사적인 사용으로부터 도출되고 그게 아닌 경우 estimate되어 결과의 정확성이 의심의 여지가 없었던 것이 아니다. 사실, 달성 가능한 가장 높은 정확도는 오로지 random failure를 고려하는 것에서부터 파생가능한데, 그 이유가 확률적 방법은 systematic fault의 분석(예를 들어서 명세 및 설계 오류에서의 systematic fault의 도입)에 대해서는 valid하지 않기 때문이다. 소프트웨어는 wear out이 일어나지 않고 모든 fault가 systematic하며 random failure의 고려에서 제약되는 방법에 의해 system의 reliability를 유도하는 가능성은 없다.

소프트웨어의 또 다른 특징은 그것의 고유한 복잡성이다. Fault가 존재하지 않음을 증명하는 것은 불가능하며 testing으로부터 reliability의 높은 confidence를 이끌어내는 것은 실용적이지 않은 긴 시간을 필요로 한다.

그래서 safety를 달성할 뿐만 아니라 입증하는 것이 필요한 개발자에게 많은 문제들이 닥치게 된다. 이런 문제들의 일부분은 다음의 질문과 간단한 토의를 통해 요약을 할 수 있다.

  • 어떻게 우리는 시스템의 안전 요구사항을 정의할 수 있을까? 요구사항들은 정량적이거나 정성적일 수 있는 위험 분석으로부터 도출될 것이다(may). 하지만 소프트웨어 failure는 random fault가 아니라 systematic에서 초래하기 때문에 failure의 확률이나 위험한 failure의 확률을 직접적으로 측정하는 것은 타당하지 않아서 정량적 위험 분석이 채택되어야 한다. 주어진 risk의 감소가 소프트웨어 안전 기능의 명세로 정의될 수는 있겠으나 그 기능의 감내할 수 있는 failure rate는 SIL로 정의될 수 있을 것이다(may). 사용상의 표준에 의존적으로 SIL은 failure rate의 수치 범위에 같거나 같지 않을지 모른다.
  • 소프트웨어의 개발에서의 엄격도가 커지면 비용의 증가를 수반하게 되는데 어떤 특별한 경우에 대한 적절한 엄격도의 수준을 어떻게 정의할 수 있을까? Risk 분석이 SIL을 이끌었다면 이것은 개발 프로세스의 엄격도를 정의하는데 사용된다. SIL이 높아질수록 엄격도는 높아지게 되고 다양한 SIL에 적합한 방법, 기술, 관리 프로세스를 식별하기 위해 표준에서 사용되는 표(방법)들이 많아지게 된다.
  • 만약 우리가 safety가 아니고 reliability를 직접적으로 계측할 수 있다면, 우리는 reliability 측량의 용어로 safety target을 정의할 수 있는가? 아래에서 논의되는 표준들의 2개에서 SIL은 failure rate로 정의되고 나머지 하나에서는 위험한(안전하지 않은) failure의 rate로 표현되고 모두가 reliability type의 measurement로 표현되어 있다.
  • 달성된 안전의 주장을 하기 위해 어떻게 기준을 정의할 것인가? SIL이 달성되어야 하는 안전의 수준을 정의하기 위해 사용된다면, SIL은 만들어지고 판단되어야 하는 달성된 안전에 대한 주장에 대한 기준이 되어야 한다. 그러나 소프트웨어의 예상되는 failure rate에 대한 수치값이 confidence로부터 도출될 수 없다면, 그와 같은 주장의 증명에 대한 증거 제시는 불가능할 것이다.

 

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