카테고리 보관물: ISO 26262

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


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를 개발할 때 참조될 수 있을 것으로 기대함

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) 항공분야의 복잡 시스템에 대한 안전 분석 방법들(0)


출처: safety analysis methods for complex systems in aviation

참고자료: (paper) 항공분야의 복잡 시스템을 위한 안전분석 방법들(1)

 

논문에 대한 개인적 의견:

현재의 기술로는 부족한 점들이 많다. 표준으로 정의한 것들(ARP 4754a/ARP4761)을 따른다고 과연 safety를 달성할 수 있을지에 대하여 회의적인 시각을 갖게 되었다.

산업적인 측면에서 봤을때는 고객이 해달라는 대로 해줄거고, 그게 보통은 표준에서 요구하는대로 수행하는 것일 게다. 그런데, 문제는 고객도 safety에 대해 잘 알지 못하고, 공급자도 safety에 대해서 잘 모르기는 마찬가지이다.

개인적인 의견은, safety는 고객이 알고 있어야 하고 validation을 해야 한다. supplier입장에서는 safety를 vehicle level에서 바라보기에는 한계를 가지고 있기 때문이다.

프로세스와 기술적 방법이 문제가 아니다. 그거야 오히려 비교적 쉽다. 문제는 그걸 따른다고 safety가 달성되는 관계가 아니라는 것이 문제이다.

그렇다고 비표준 방법인 안전분석법을 supplier가 수행한다면? 아마도 고객의 입에서는 이런 이야기가 나올것이다.

‘당신이 뭔데 그런 듣도보도 못한 방법을 쓰느냐?’

그리고 supplier의 경영진들 또한 이러한 말을 할 것이다.

‘고객이 시키지도 않는데, 그렇게까지 굳이 해야겠니?’

Safety에 대한 산업측에서의 적용은 그래서 굉장히 애매하면서도 일부 이해되지 않지만 그냥 하라는 대로 하는 형태(best practice)로 될 가능성이 높다고 본다.

나중에 사고가 나면 누가 잘못한 것인지 blame게임을 하게 될거고… 악순환은 반복될 것이다.

그래도 언젠간 나아지겠지..