태그 보관물: software architecture

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


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

Unit testing을 요구하는 표준과 그렇지 않은 표준


Unit level의 testing을 요구하는 표준이 있고, 그렇지 않은 표준이 있다. 둘간에 별 차이가 없을 거라고 생각할지도 모르겠다. 어차피 사람이 하는 일이고, 사람마다 눈 두 개 달려 있고, 손 두 개 달려있으니, 그게 그거 아니겠는가? 하고 말이다.

Automotive SPICE와 ISO26262의 경우에는 unit level의 testing을 요구하는 반면, DO-178C나 DO-278A에서는 그런 요건이 존재하지 않는다. 다만 요구사항 기반으로 시험을 하라고 요구한다.

재밌는것은 unit level의 testing을 요구하는 자동차쪽 domain에서 test case를 추출하는 기법으로 requirement based testing을 요구하고 있다는 점이다.

요구사항 관점에서 설계를 하거나 구현을 할 때, 두 가지 구현 방식이 있을 수 있다. 하나는 architecture를 설계하고 그 설계에서 component를 설계하고 그 안의 unit을 설계해서 구현하는 방식이 있다. 이 방식은 수직적 방식으로 계층적 구조를 지닌다.

다른 하나는 수평적 방법으로 요구사항에 대한 sub요구사항을 만들어서 그 요구사항에 대한 로직을 설계해서 구현하는 방식이다. 이 방식은 수평적 방식으로 볼 수 있다.

수직적 설계 방식을 적용했을 때, 요구사항에서 architecture로의 trace를 해 보았는가? 해 보았다면 과연 그게 쉬웠는가?

만약 가능하다고 대답하고 싶다면, 그 application의 경우 그럴 수 있다고 생각하고, 일반적인 경우에 대해 가능하냐고 묻고 싶다. In general, is it possible ?

이는 불가능하다고 생각한다.

그런 방식에서는 요구사항에 대한 추적이 쉽지 않다.

예를 들어서 사람의 인체로 설명을 해보자.

사람을 물리적으로 나눈다면 5장 6부가 있다. (곤충을 머리, 가슴, 배로 나누듯이) 그런데 인간의 걷는 기능과 관련된 인체 내의 part와의 관계(추적성)는 어떻게 맺을 수 있을까? 인간의 먹거나 자는 기능과 관련된 추적성은 어떻게 맺을 수 있을까?

연관이 없는게 없다고 하기도 뭣하고, 하나만 연관짓기도 뭣하고…참으로 거시기 할 것이다.

일반적으로 인체의 5장 6부로 구조화 한것은 인간이 수행할 수 있는 여러가지 기능(or activity)별로 쪼갠것이 아니다. 일반적으로 system level의 function은 sub-system(5장 6부)의 유기적인 interaction과 process에 의해 달성되기 때문이다.

sub-system(5장 6부)의 기능은 system level의 function에 1:1로 매핑되지 않는것과 같이, 그리고 그러한 방식으로 architect 되지 않았듯이, 일반적으로 sw설계에서도 그러하다.

다른 방식으로 다시 설명을 해보자면, software architecture로 넘어와서 crosscutting block의 경우 requirement기반의 기능과 mapping시킨다고 할 때, 혹은 middleware level을 설계했을때, 이를 requirement와 mapping시킨다고 했을때, 그게 쉬운가?

진짜로 쉬운가? 진심으로? 정말로? 혼또니 ?

그럴리 없다.

정말 어려운 일이다.

 

결론이다. unit level testing은 최상위 요구사항에 대해 mapping하는 것은 매우매우 어렵다.
unit level testing을 하려면 sw architecture를 설계해야 한다.하지만 모든 sw가 architecture를 필요로 하는 것은 아니라고 생각한다. architecture를 설계할때의 장단점이 있을 뿐, 그게 없다고 sw가 안되거나 하진 않는다. ISO26262의 sw개발 concept과 DO-178C의 sw 개발 concept이 같다고 생각하겠지만, 실상은 그렇지 않다. (비슷해 보일 수는 있을지라도 같은 것은 아님)

나는 개인적으로 DO-178C쪽의 표준이 더 잘 정의되었고, best practice로서 적용하기도 좋다고 생각한다.

그렇다고 자동차쪽 sw개발 방식을 비판했다거나 뭐 그런것도 아니다.

어떤 approach건 pros와 cons는 존재하기 마련이다.

그리고 그러한 방식이 잘 맞는 application이 있기 마련이다.

세상에 silver bullet이란 건 없다.

만약 존재한다면 그것은 매우 가격이 높아서 공학적으로 가치가 없을 것이다.
(그런 의미에서 효용성이 없어서 silver bullet이 없다는 의미도 된다.)

 

 

인기있는 Framework을 만들고 싶다면..


인기있는 Framework을 만들고 싶지 않은 사람은 없을 것이다…나 또한 그러하고, 항상 사용성을 극대화시킬 수 있는 방법을 고민하는데, 이 내용이 도움이 될 것이라 생각한다.

arload - my Load, to Architect

여러분!! 인기 있는 Framework를 만들고 싶으신 가요? 저 역시 그렇습니다.

인기 있는 Framework를 만들기 위해 Framework Design Guidelines에서  나온 내용(.NET Framework 설계자인 Krzystof Cwalina의 조언)들을 일부 여러분과 공유하고자 합니다.

  • 사용성 테스트
  • 점진적인 학습 곡선
  • 캡슐화의 오해

이번 포스트에서 다룰 주제는 이렇습니다. 자 그럼 하나씩 살펴 보도록 하죠 🙂

원본 글 보기 461단어 남음