카테고리 보관물: 61508

안전 무결성 수준의 사용, 잘못된 사용을 이해하기(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) 항공분야의 복잡 시스템에 대한 안전 분석 방법들(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을 시켜버린…

 

상태 분석을 활용한 복잡한 임베디드 시스템에 대한 요구사항 생성하기


Motivation

시스템 엔지니어가 작성한 소프트웨어 요구사항과 소프트웨어 엔지니어가 작성한 코드상의 차이가 크다.

소프트웨어 엔지니어는 요구사항을 코드로 번역하여 시스템 엔지니어가 의도한 시스템의 행동에 부합하다는 기대를 해야만 한다.

해결 방법: State analysis방법을 사용하여 명시적으로 표현한다.

원문 – Generating requirements for complex embedded systems using state analysis

Introduction

State analysis방법론은 다음의 3가지 기본적 원칙을 주장(assert)한다.

  • control은 system operation의 모든 측면을 포함한다. system under control의 모델을 통해 이해될 수 있음
  • system under control의 모델은 명시적으로 식별되고 시스템 엔지니어들 사이의 합의된 것들을 보장하는 방식이어야 함
  • 소프트웨어 설계 및 운영에 영향을 미치는 모델링 방식은 직접적이고 최소한의 번역(translation)을 해야 한다.

State based control architecture

시스템 model을 구현한 소프트웨어는 크게 4가지의 block으로 이루어져 있다.

  • State estimation – System under control에 대해 관찰하고 계측을 통해 시스템의 상태를 예측하는 모듈
  • Hardware Adapter – System under control을 관찰하거나 자극을 주거나 하는 모듈
  • State control – State knowledge를 토대로 시스템의 goal을 달성하기 위해 system under control을 제어하기 위한 방법을 결정하는 모듈
  • State knowledge – State estimation정보로부터 state transition을 시키고 시스템의 상태값을 변경시키는 모듈

 

state based control architecture

State의 정의

시스템의 상태와 그 상태에 대한 우리의 지식이 같은 것이 아니다. 실제로의 상태는 매우 복잡하지만 우리의 인식상에서는 유용한 것들만 추려서 의도에 맞도록 추상화를 시킬 수 있는데, 우리는 이러한 추상화를 “상태 변수”라고 부른다. 시스템의 알려진 상태는 관심 시점(time)에서의 그것의 상태변수의 값이다.

The state of a system and our knowledge of that state are not the same thing. The real state may be arbitrarily complex, but our knowledge of it is generally captured in simpler abstractions that we find useful and sufficient to characterize the system state for our purposes. We call these abstractions “state variables”.
The known state of a system is the value of its state variables at the time of interest.

상태 변수의 사례로는 다음과 같은 것들이 있을 수 있다.

• device operating modes and health;
• resource levels (e.g., propellant; volatile and nonvolatile memory);
• temperatures and pressures;
• environmental states (e.g., motions of celestial bodies and solar flux);
• static states about which we may want to refine our knowledge (e.g., dry mass of a spacecraft);
• parameters (e.g., instrument scale factors and biases, structural alignments, and sensor noise levels); and
• states of data collections, including the conditions under which the data was collected, the subject of the data, or any other information pertinent to decisions about its treatment.

 

Modeling process

  1. Identify needs—define the high-level objectives for controlling the system.
  2. Identify state variables that capture what needs to be controlled to meet the objectives, and define their representation.
  3. Define state models for the identified state variables—these may uncover additional state variables that affect the identified state variables.
  4. Identify measurements needed to estimate the state variables, and define their representation.
  5. Define measurement models for the identified measurements—these may uncover additional state variables.
  6. Identify commands needed to control the state variables, and define their representation.
  7. Define command models for the identified commands—these may uncover additional state variables.
  8. Repeat steps 2–7 on all newly discovered state variables, until every state variable and effect we care about is accounted for.
  9. Return to step 1, this time to identify supporting objectives suggested by affecting states (a process called ‘goal elaboration’, described later), and proceed with additional iterations of the process until the scope of the mission has been covered.

 

Example

논문 참조, skip

 

Control system을 설계하기 위해 모델을 활용하기

Goals

State analysis에서 goal은 time interval에 대한 상태 변수의 값의 기록에 대한 제약사항이다. 좀 쉽게 표현한다면 시스템이 수행되는 동안 반드시 만족되어야 하는 속성 정도로 표현할 수 있겠다. 예를 들면 카메라의 온도가 x와 y온도 사이에 반드시 있어야 한다는 것이 있을 수 있겠다.

Goal은 상태 변수의 값에 대한 이력에 대해 성공/실패를 판정할 수 있는 기준이 될 수 있다. (위의 사례에서 예를 들면 만약 카메라의 온도가 x-10일 경우 (해당 속성이 만족되어야 하는 시점에서) 위의 속성은 시스템에 부합하지 못함을 의미한다.

결국, 이 Goal이라고 하는 것은 model checking에서 검증되어야 하는 시스템에 대한 검증 속성으로도 볼 수 있다. Formal verification이 이렇게 연결이 될 수 있는 것이다. 결국 Goal을 식별한다는 말의 의미는 검증할 시스템이 만족되어야 하는 시스템의 속성을 추출하는 과정이라고 볼 수 있다. 

goal의 사례들

  1. Camera temperature is between 10 and 20 ◦C from 2:00 pm to 3:00 pm (control goal that specifies a constraint on state value, to be maintained by controller).
  2. Camera temperature is transitioning to be between 10 and 20 ◦C by 2:00 pm (transitional control goal that achieves the appropriate precondition for goal #1).
  3. Camera temperature standard deviation is less than 0.5 ◦C from 1:00 pm until 5:00 pm (knowledge goal that specifies a constraint on quality of state knowledge, to be maintained by estimator).
  4. Camera temperature mean value, plus or minus 3-sigma, is in the range 10–20 ◦C [10<= mean −3 sigma <= mean + 3 sigma <=20], from 2:00 pm to 3:00 pm (inseparably-combined control and knowledge goal, specifying constraints on both state value and quality of knowledge).
  5. Camera temperature measurement data collection state contains at least one measurement less than 10s old, from 1:00 pm until 5:00 pm (data goal, specifying a constraint on the state of a data collection).

 

goal의 정교화

시스템의 모델로부터 goal을 100% 추출하는 것은 한계가 있다. 그래서 goal을 정교화하는 작업이 별도로 필요한데, 본 논문에서는 정교화작업을 위한 4개의 규칙을 정의하였다.

  1. A goal on a state variable may elaborate into concurrent control goals on directly affecting state variables.
  2. A control goal on a state variable elaborates to a concurrent knowledge goal on the same state variable (or they may be specified jointly in a single control and knowledge goal).
  3. A knowledge goal on a state variable may elaborate to concurrent knowledge goals on its affecting and affected state variables.
  4. Any goal can elaborate into preceding goals (typically on the same state variable). For example, a “maintenance” goal on a state variable may elaborate to a preceding transitional goal on the same state variable.

 

Goal을 정교화하는 방법의 사례

아래의 예는 1개의 goal로 부터 5개의 추가적인 goal을 식별하는 사례를 나타내주고 있다.

goal elaboration example

결론

  • 시스템 모델을 소프트웨어로 구현하기 위한 architecture framework을 제시함
  • State variable을 활용하여 시스템의 상태를 식별하고, 시스템이 만족해야 하는 속성을 식별함
  • model checking의 본질적인 문제점인 completeness를 보완함
  • Stateflow modeling시에 Modeling 및 model check를 사용하고자 할 때 도움이 될 것으로 기대함
  • 향후 작업으로 Stateflow modeling을 위한 framework를 개발할 때 참조될 수 있을 것으로 기대함