Similarity between Academic paper and Requirements

When researcher writes academic paper, one of important thing is to make structure. Usually research is one’s own study so it is hard to understand for people who are not interested in the topic. So s/he has to consider how to reader can understand easily.

S/he also consider internal consistency for better understanding.

I realized that writing requirement is quite similar to write an academic paper. If requirements are written without consideration of structure, it is hard to understand. Readers cannot understand what are system’s sub systems, what are functions allocated to sub-systems.

It is not technical point of view. But if they are not clear it is hard to defense against audit, because auditor will confuse it and will not understand what you are saying.

Then s/he will not give a good grade.

 

 

Advertisements

“Doing Nothing” is better than “Doing Wrong”

It is related to identify safety requirement. For safety related systems, to avoid unintended function is essential. But I sometimes find that some engineers have a rule that watchdog function shall be regarded as a safety function.

Is it really true?

It will be critical for company’s financial profit because of quality problem. It surely might be a problem but in safety aspect watchdog is not always related to safety.

Let’s assume that there is a system(sys_A) that report some information to other system(sys_B) which controls vehicle’s movement. A requirement allocated to sys_B is determined as ASIL C, while sys_A is determined as ASIL A or B.

Let assume that sys_B can perceive Sys_A’s liveness by monitoring message that Sys_A sent.

In safety aspect, Sys_A’s safe state might be dead state. It means that when Sys_A detect a fault that leads to violate safety function that is allocated to Sys_A, it is better to do nothing than do wrong.

In this case, what do you think that watchdog fault is safety related or non-safety related ?

In some cases, I found that watchdog function is not a safety function. It is just a general function.

Identifying safety requirement is so important for functional safety manager. Functional safety engineer or functional safety manager have to consider it carefully.

It surely leads to engineers confusing when they regard non-safety functions as safety function. All safety activities after requirement phase will be messed up because there will not be consistent in their work products. Their safety arguments will be no longer convincing.

 

 

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

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