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

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의 정의

시스템의 상태와 그 상태에 대한 우리의 지식이 같은 것이 아니다. 실제로의 상태는 매우 복잡하지만 우리의 인식상에서는 유용한 것들만 추려서 의도에 맞도록 추상화를 시킬 수 있는데, 우리는 이러한 추상화를 “상태 변수”라고 부른다. 시스템의 알려진 상태는 관심 시점(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을 식별하는 사례를 나타내주고 있다.

결론

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

시스템 및 소프트웨어 요구사항 관리 방법?

휴가중에 최근 어떤 분이 다음과 같은 문의를 해주셨다.

“어떤 경우 시스템 요구사항과 소프트웨어 요구사항이 겹치는 것 같다. ”

이 부분은 어느정도 사실이다. 그리고 좋은 현상이다. 다만 시스템의 scope와 소프트웨어의 scope간의 경계를 어떻게 정할 것인지에 대해서 약간은 명확하지 않아서 어려움을 겪고 계신 것이라고 생각한다.

요구사항을 작성하려면 그게 sys일지 sw일지에 대해서 생각해 보지 말고, 일단 interface가 어떤 형태일지 생각해보자. interface가 작성하고자 하는 요구사항의 scope가 된다. 꼭 sys로 작성하고 sw로 한번 더 작성해야 한다고 생각할 필요는 없다. 장난감을 만드는 경우라면 굳이 분리하는 것이 의미가 없을 수도 있고, 거대한 것을 만드는 경우라면 분리를 해야만 관리가 용이할 것이다.

그리고 interface를 정의했으면, 그 interface를 가지고 검증을 한다고 생각을 하라. 우리의 신체를 예를 들어서 설명하자면, 췌장에 염증이 있는지 없는지를 확인하기 위해서 배를 갈라서 뱃속을 뒤적거리면서 정상인지 확인할 수 있는 방법이 있다.

소프트웨어에 인터페이스가 정의되어 있지 않으면 췌장 검사하듯이 소프트웨어의 배를 갈라야 할 것이다.  무슨 이야기를 하고 싶은거냐면, 저렇게 하면 안된다는 얘기를 하고 싶은거다. 머리가 좀 아프면 두개골을 열어보고 어디 문제 있는지 확인할건가? 그런 생각을 가지고 있는 사람은 별로 없을 것이다.

결국 요구사항을 정의할 때 검증 가능성에 대해서 생각을 해 봐야 한다는 의미가 된다. 그게 가능할지의 여부는 정의한 interface에 의해 결정이 된다. 또한 어떤 장비를 사용하느냐에 따라서 관찰 가능성의 범위가 달라질 수 있다. 디버그 장비를 이용해서 trace를 이용하거나 디버그 장비를 이용해서 오실로스코프를 이용해서 검증할 수도 있겠다. 혹은 대상 시스템의 출력 인터페이스를 이용해서 관측한 결과를 가지고 검증할 수도 있다.

어떻게 하더라도 상관은 없다. 불편하게 검증하고 싶으면 불편한 거고, 편리하게 검증하고 싶으면 편리한 것이고 개인적인 취향일 수도 있으니까.

여기까지 제대로 따라왔다면 interface가 정의되었고, 대상의 boundary가 정의된 것이기 때문에 작성하고자 하는 scope가 결정된것이다. 여기서 requirement라는 것을 작성한다고 하면 interface및 boundary를 감안해서 정의를 하도록 가급적 노력해야 한다.

물론 모든 경우에 적용할 수 있는 그런 법칙같은 것은 없다고 생각해야 하겠으나, 일반적으로 적용 가능한 법칙은 다음과 같다.

interface를 INPUT_SET, OUTPUT_SET으로 정의를 하고, INPUT_SET은 입력 interface의 집합, OUTPUT_SET은 출력 interface의 집합으로 정의를 하자면,

요구사항의 집합인 REQUIREMENT_SET은 다음과 같이 정의를 할 수 있다.
OUTPUT_SET = function of (State, INPUT_SET)

다만, 시스템 범위의 비기능 요구사항들이 저런 방식으로 정의가 가능한지는 확실치는 않고, 기능적 요구사항은 저렇게 정의할 수 있다. Simulink나 stateflow를 떠올려보면 쉽게 상상이 될 것이다. state machine의 수학적 정의가 저렇게 된다.

여기서 이 글을 쓰게 된 동기인 요구사항 겹침 문제로 돌아가보자.

sys간 요구사항과 sw간 요구사항은 겹친다. 겹칠 수 있다. 그것이 자연스러운 것이고 정상적이다. 그런데, 장난감을 만드는 것이 아니라면 sys요구사항이 sw요구사항을 전부 포함하거나 sys요구사항 및 설계에서 sw요구사항 및 설계를 포함한다면 그것은 바람직하지는 않은 것 같다.

그럼 정확하게 어떻게 분리를 시킬 것인가?

sys의 기능적 요구사항 중 일부분(REQ_SYS_FUNC1)이 sw로 구현한다면 REQ_SYS_FUNC1은 시스템 요구사항이면서도 sw요구사항이 될 수 있다.

여기서 한 단계 더 나아가자면, sys로부터 할당받은 sw 요구사항은 보다 상세화시킬 수 있다.

여기서 좀 다른 얘기로 들릴 수 있지만, sw요구사항을 작성한다는 것은 기술 문서를 작성하는 것이다. 기술 문서를 작성하기 위해서는 문서 작성 교육을 받아야 한다. 주제를 잡고, 개요를 짜서 문서의 뼈대를 만들고, 스타일을 적용해서 두괄식으로 할지 미괄식으로 할지….

sys로부터 할당받은 sw요구사항을 어떻게 상세화 시킬 것인가? 이 부분은 그 주제로 어떻게 기술문서를 작성하도록 하느냐와 유사하다. 그리고 그것은 분명히 sys 수준과는 차이가 있어야 한다. 어떻게 하냐고 묻는다면 그것은 위에서 이야기 했던 것들을 고려하고 기술문서 작성을 위한 고민을 해봐야 한다.

아무래도 무슨 말인지는 대충 알겠는데, 그래서 어떻게 하라는지 좀 이해가 잘 안될 것이다. 그렇다면 이제부터 고민해보시길 !

Requirement elicitation and analysis (요구사항 수집 및 분석)

한국어는 아래로 스크롤..

When doing SW certification consulting, most customers are conceptually aware of what they need to develop and know roughly how to implement it. So the requirements collection and analysis phase was not too difficult.

However, in the project I am participating in, the customer did not have requirements. Obviously, there exists what we have to do, but the concept of what our team should do is not perfect either.

So I perform requirements collection and analysis activities.

It is a very vague and difficult task. I feel like I create a concept called iPad when the iPad does not exist in this world.

It is very vague and I need a lot of time. But there is not much time given in the project.

I want to get a consulting service for this project (Lesson learned is really valuable information).

In fact, this project is not a software development project, but a laboratory building project. I think it is a very different field, but I have found that there is not much difference. The similarity is that wherever I participate, “I” am only a consultant, and have little knowledge about a product.

I collects data from ‘domain experts’ and collects and identifies requirements. So I looked up useful resources. Here are some resources to help you do this.

These activities are called ‘requirements gathering and analysis’ activities, and related resources are found by Google.

Requirements Collection and Analysis (Lecture note)
When you want to write a requirement, there is a way to guide you to write it in a framework, which I do not personally prefer. I think there will be places where this area is appropriate.

SW Requirements Analysis Guide (Korean)

SW인증 컨설팅을 할 때, 대부분의 고객들은 자신이 무엇을 개발해야 하는지에 대해서는 개념적으로는 알고 있고, 어떻게 구현할지에 대해서도 대략적으로는 알고 있다. 그래서 요구사항 수집 및 분석 단계가 그리 어렵지 않았다.

하지만, 지금 참여하고 있는 프로젝트에서는 고객이 요구사항을 가지고 있지 않았다. 분명히 무엇을 하긴 해야 하는데 그 팀은 어떻게 해야 할지에 대한 개념 자체도 완벽하지 않다.

그래서 어쩌다보니 요구사항 수집 및 분석 활동을 하게 되었다.

굉장히 애매하고 어려운 작업이다. 마치 이 세상에 아이패드가 존재하지 않을때, 아이패드라는 컨셉을 만들어야 하는 느낌?

굉장히 막연하면서도 시간은 많이 필요하다는 느낌. 하지만 과제에서 주어진 시간은 별로 없다.

이것을 위해 컨설팅이라도 받고 싶은데(교육의 힘은 위대하다, 그리고 해 본 사람의 능력은 위대하다. Lesson learned 정보는 정말 귀한 정보이다) 가능할지 미지수이다.

사실, 이 프로젝트는 소프트웨어 개발 프로젝트가 아니라 시험소 건축 프로젝트이다. 굉장히 다른 분야라고 볼 수 있으나, 겪어보니 domain이 다를 뿐 크게 차이가 없다는 것을 알게 되었다. 비슷한 점은 어딜가나 ‘나’는 컨설턴트일 뿐이고 제품에 대해서는 철저한 문외한이다.

‘나’는 ‘도메인 전문가들’로부터 자료를 수집해서 요구사항을 수집하고 식별해낸다. 그래서 자료를 좀 찾아보았다. 이런 작업을 위해 도움이 될 만한 자료를 소개한다.

이런 활동을 ‘요구사항 수집 및 분석’활동이라고 하며, 관련 자료는 구글님이 다 찾아주신다.

요구사항 수집 및 분석자료(Lecture note)

요구사항을 작성하려고 할 때, Framework방식으로 기술하도록 가이드 하는 방식이 있는데, 개인적으로는 선호하지 않는다. 이런 분야가 적합한 곳도 있을 것이라고 생각은 든다.

SW요구 분석 가이드(Korean)