Solving the software safety paradox


소프트웨어의 safety를 보장하기 위해서 구현되어야 하는 기능들을 기술한 article이다. 아주 오래된 기사이기는 하지만, 아직도 이런 내용을 모르는 엔지니어들도 상당수 있으리라 생각하기 때문에 여전히 유용한 정보라고 생각한다. 출처는 아래와 같다.

http://www.eetindia.co.in/ARTICLES/1998DEC/PDF/EEIOL_1998DEC02_EMS_TA.pdf?SOURCES=DOWNLOAD

best practice라고 생각되는 것들을 정리하면 아래와 같다.

  • CPU self-test
  • Guarding against illegal jumps
  • ROM tests
  • Watchdog timers
  • Redundant storage and cross checks of critical variables
  • Stack checks
  • Program checks

 

CPU self-test

부팅시에 CPU의 명령어들이 정상적인 행동을 수행하는지를 판단하는 code를 assembly로 작성한다. 문제가 있으면 부팅 실패로 halt상태로 종료.

Guarding against illegal jumps

사용하지 않는 메모리 영역에 대해 의도적으로 exception이 발생할 수 있는 machine code를 삽입하라는 건데, 이 정도로 illegal jump를 모두 막을 수 있을지는 모르겠으나, 매우 간단하게 어느정도의 문제를 해결할 수 이는 방법이라고는 생각함.

개발자가 의도적으로 illegal jump를 하도록 하는 code를 만들지 않도록 강제하고 code verification하는 방법도 고려해 볼 수 있겠고, control flow monitoring하는 방법을 고려해 볼 수 있겠다.

ROM tests

부팅시에 메모리를 테스트한다. checksum이나 CRC 시험을 한다. 만약 오류가 있으면 ROM의 데이터를 신뢰할 수 없으므로 그대로 멈춰라~(halt)

Watchdog timers

watchdog timer는 여러가지 bad practice가 있으므로 주의 깊게 사용을 해야 하고, 관련 문헌을 더 찾아봐야 한다. 내가 여기 블로그에 포스팅 한 것 중에 watchdog카테고리의 글들을 참조하기 바람(https://iso26262fs.wordpress.com/2014/12/30/proper-watchdog-timer-use/)

Stack checks

on-line으로 지속적인 관찰을 통해 stack이 overflow되고 있는지를 확인해봐라. 대개 RTOS에서 지원되는 기능이기는 한데, RTOS없이도 구현하는 것은 문제가 없음. stack이 overflow되면 어떻게 처리할까?에 대한 내용은 없는데 application specific한 문제라고 생각함. 영원히 halt하는 것이 좋을지 아니면 reset하는 것이 좋을지는 좀 따져봐야 할 듯.

Program checks

CPU의 연산결과를 못믿겠다면? 검산을 하면 된다. 초등학교때 배운 것처럼 검산은 연산 과정을 반대로 수행하는 것이라고 생각할 수 있다.

1+1+1 = 3이란 결과가 나왔다면, 3에서 시작해서 -1-1-1을 수행해서 0이 나오는지를 확인하는 과정.

모든 연산을 이렇게 수행하면 overhead도 상당할 것이고 선택적으로 수행을 해야 할 것으로 생각된다. ASIL B이하 혹은 ASIL C이하에서는 고려하지 않아도 되지 않을까?

ASIL D라고 하더라도 모든 연산을 저렇게 하다가는 deadline에 miss할 수 밖에 없을 것 같다.

 

  1. Neumann, Peter G. Computer Related Risks . Reading, MA: Addison Wesley, 1995, Chapter 2.8.1, p. 66.
  2. Santic, John S., “Watchdog Timer Techniques,” Embedded Systems Programming , April 1995, p. 58.
  3. Lowell, Augustus P., “The Care and Feeding of Watchdogs,” Embedded Systems Programming , April 1992, p. 38.
  4. Blum, Manuel and Sampath Kannan, “Designing Programs that Check Their Work,” Journal of the Association for Computing Machinery , January 1995, p. 269.
Advertisements

Proper watchdog timer use


안전한 시스템을 설계하기 위해서는 watchdog의 사용은 반드시 필요하다. 안전한 설계를 위해서는 반드시 고려되어야 하며, 안전분석이라고 하는 것이 이런 사항들을 고려하여 inspection하는 것을 포함한다고 볼 수 있다.

출처는 아래와 같다. 잘못된 번역이 있을 수 있다.

http://betterembsw.blogspot.kr/2014/05/proper-watchdog-timer-use.html

 

watchdog timer는 임베디드 시스템의 reliability를 보증하는 것을 돕기 위한 일반적인 방법이다. 하지만 그 방법은 적절하게 사용을 할 경우에만 동작한다. 효과적인 watchdog timer는 시스템의 어떠한 주기적인 task의 실패가 watchdog timer의 reset을 유발해야 할 것을 요구한다.

결과: 적절하지 않은 watchdog timer의 사용은 소프트웨어 task의 죽음 및 소프트웨어 task 오버런이 탐지되지 않는 잘못된 결과를 유발할 수 있으며 데드라인을 miss하거나 부분적 소프트웨어 failure를 유발할 수 있다.

허용되는 practices:

 

  • 만약 여러 개의 주기적인 task들이 시스템 안에 있다면 각각의 모든 task들은 자기자신이 살아있음을 보증하기 위해서 watchdog이 kick되도록 직접적인 contribute를 해야 한다.
  • 하드웨어 timer 인터럽트를 사용하여 직접적으로 watchdog을 kick하는 것은 나쁜 practice이다. (ISR이 현재 살아있는 모든 task들에 대해 기록한다면 예외가 될 수 있다.)
  • task health monitoring하는 task를 가장 낮은 우선순위에 두는 것 역시 나쁜 practice이다. 이런 접근법은 높은 우선순위의 task의 detect를 실패한다.
  • watchdog timeout 주기는 현실적인 가장 작은 값으로 설정되어야 한다. 시스템은 watchdog timeout값의 전체 주기에 대해 task의 어떤 조합이 죽을지라도 safe를 유지해야 한다.
  • watchdog tier가 reset하는 매 시간은 전체적인 operational system의 testing동안 발생하며 그 행위는 기록 되고 조사되어야 한다.

토의

간단하게 말해서, watchdog timer는 미리 정해진 어떠한 값에서 0이 될때까지 count down하는 counter로 생각될 수 있다. 만약 watchdog이 실제로 0이 되면, watchdog은 system reset이 발생한 어떤 문제도 고칠 것이라는 믿음으로 system을 reset한다. 그러한 reset을 방지하는 것은 watchdog을 주기적으로 본래의 미리 정해진 값으로 되돌리는 설정을 하는 “kicking” 을 할 것을 요구한다. 그리고 이러한 행위는 reset을 방지한다. 이 idea는 소프트웨어가 hardware watchdog으로 인해 system이 여전히 살아있고 reset을 방지한다는 것을 확신하게 된다. 이 idea는 10대 애들이 매 주기적인 시간마다 전화해서 모든 것이 올바르게 돌아간다는 것을 이야기 할 것을 요청하는 것과는 같지 않다.

Watchdog timer arrangement.

watchdog이 system 을 kick하면 reset은 가장 흔한 행동이다. 비록 restart를 시도하기 전에 유지보수 조정을 위해 기다리는 것이 더 나을 것으로 보이는 경우에 시스템의 영구적인 shutdown이 더 나을 수 있다고 하더라도 말이다.

watchdog timer로부터의 예상되는 장점을 얻기 위해서는 적절한 방법으로 watchdog timer를 사용해야 한다. 예를 들어 무조건적으로 watchdog을 kicking하는 hardware interrupt timer가 tigger하도록 하는 것은 특별히 좋지 않은 practice인데, 그 이유는 그것은 hardware timer ISR이 올바르게 동작하는 것을 제외하고 software task의 어떤 것도 올바르게 동작하는 것을 알려주지 않기 때문이다. (분석에 의해 당신의 10대 어린애에게 컴퓨터를 자동으로 셋업해서 사전에 저장된 소리로 “I’m ok” 메시지를 매우 토요일 밤에 집에 전화하는 것은 그녀가 실제로 그 날에 OK인지를 알려주는 것이 아니다.

여러 개의 task를 가지고 있는 system에 대해서 각각의 그리고 모든 task는 watchdog이 kick되도록 해야 한다. 단지 하나의 task로부터 듣는 것은 충분하지 않다. 모든 task들은 kick된 watchdog에 대해 일종의 unanimous “vote”를 가져야 할 필요가 있다. 동시에,  특별히 나쁜 practice는 하나의 task혹은 ISR가 watchdog의 kick을 통해 동작하고 있다는 것을 보고하는 것이고 이것이 다른 task들이 올바르게 동작하는 것을 의미하도록 하는 것이다. (분석적으로 다시 말하자면 3명의 애들 중에 하나의 목소리를 듣는 것이 나머지 두 명이 괜찮은지를 알 수 있는 건가?) 예를 들면 watchdog는 “interrupt routine으로부터 kick되어서는 안 된다” (MISRA report 3, p 38), 그리고 일반적으로 timer service ISR을 사용하여 watchdog을 kick하는 것은 나쁜 practice이다.

연관된 나쁜 practice는 낮은 task가 동작하고 있을 때를 가정하는 것인데, 이것은 다른 모든 task들이 동작함을 의미한다. 높은 우선순위의 task는 어떤 이유로든 죽을 수 있고 실제로 낮은 우선순위의 task가 동작하도록 더 많은 시간이 부여될 수 있다. 그러므로 만약 낮은 우선순위가 watchdog을 kick하거나 ISR이 kick하도록 flag를 set한다고 한다면 이 방법은 다른 task들이 시기 적절하게 주기적인 방식으로 동작하는 것을 실패한다면 탐지하는 것을 실패할 것이다.

CPU부하를 모니터링하는 것은 watchdog timer의 대체재가 아니다. task는 그들의 deadline을 miss할 수 있는데, 심지어 CPU부하가 70~80%인 경우에도 발생할 수 있는데 갑작스러운 순간적 부하로 인해 시스템 동작의 정상적인 환경에서도 발생할 수 있다. 그런 이유로 CPU의 부하 혹은 간접적 health check를 분석하는 것을 수행하는 것을 모니터링하고 계산식이 문제라는 것을 표시하지 않으면 기본적으로 주기적인 watchdog을 kick하는 것도 bad practice이다. (이것은 ISR의 내부로부터의 watchdog을 kick하는 변종버전이다.)

시스템 소프트웨어는 시간에 대한 workload를 측정하는 책임을 져서는 안된다. 그것은 watchdog의 일이다. 모니터 되는 소프트웨어는 watchdog이 progress를 만들고 있다면 kick를 해야 한다. progress가 충분히 빠른지를 결정하는 것은 watchdog 매커니즘에 달린 일이다. 그러므로 어떠한 조건적인 kick은 단순히 liveness(task들이 실제로 수행되었다)에 기반되어 수행되어야 하며, 시스템 부하(task가 아마도 수행되고 있다고 생각한다)에 기반해서는 안 된다.

multi-tasking system에서 watchdog timer를 kick하는 한가지 방법이 아래 그림에 표시되었다:

이 watchdog 접근의 핵심 속성은 다음과 같다: (1) 모든 task들은 watchdog timer를 kick하기 위해서 살아있어야 한다. 만약 하나의 task가 죽는다면 watchdog timer는 time out될 것이고 system을 reset한다. (2) task들은 그들 자신의 시간 혹은 그들의 CPU 부하를 추적을 유지하지 않으며, 무엇이 살아있는지의 여부에 대해 watchdog timer에게 거짓말을 하는 소프트웨어 fault혹은 execution defect를 가지는 것을 불가능하게 만든다. CPU의 소프트웨어 정책 자체를 만들고 watchdog이 kick하는 것을 기다리도록 shut down하는 대신 이 소프트웨어는 단순히 언제 그들이 수행을 종료했는지에 대해 tasks report를 가지며 watchdog timer가 적절한 정책적인 일을 하게 한다. 보다 복잡한 버전의 code들은 관련된 시스템에 의존적일 수 있다; 이것은 좋은 watchdog의 교실 사례이다. task w가 어디에서 수행되는지는 스케줄링 정책과 얼마나 watchdog timer interval이 tight하는가에 따라 의존적이다. 하지만 낮은 우선순위의task에서 watchdog을 동작시키는 것이 일반적이다.

watchdog시스템의 timing을 setting하는 것은 또한 중요하다. 만약 목표가 task가 적어도 매 5msec마다 수행되어야 하는 것을 보장하기 위해서라면 watchdog timer를 800msec에 setting하는 것은 task가 795msec늦을 때까지 문제를 당신에게 알려주지 않는다. watchdog timer는 가장 느린 task의 period와 가급적 가깝게 set해야 한다. execution variation과 scheduling jitter를 고려한 약간의 extra time(margin)을 고려하라. (=slowest period + margin)

만약 watchdog timer set이 시험 도중 나타났다면 그 현상을 조사해야 한다. 만약 허용할 수 있는 실시간 스케줄링 정책이 사용되었다면 watchdog timer reset은 system failure가 발생하지 않았다면 나타나서는 안 된다. 그러므로 각각의 watchdog timer가 reset 기록으로 근본 원인을 찾아내는 것은 safety critical design의 본질적인 부분이다. 예를 들어, 자동차 문맥에서 어떤 watchdog timer event 기록이 유지보수를 위한 목적으로 vehicle에 저장될 수 있다. 유지 보수 동안, 기술자의 컴퓨터는 이벤트 기록을 수집하고 자동차 제조사에게 인터넷을 통해서 전달해야 한다.

Watchdog timer가 모든 문제를 탐지하지 못하는 반면, 좋은 watchdog timer 구현은 안전한 임베디드 제어 시스템을 만드는 기본이 된다. 안전이 중요한 시스템에서 허용가능한 watchdog timer를 포함하는 것을 누락하는 것은 과실이 있는 설계이다.

References:

  • Addy, E., A case study on isolation of safety-critical software, Proc. Conf Computer Assurance, pp. 75-83, 1991.
  • Ball, Embedded Microprocessor Systems: Real World Design, Newnes, 2002.
  • Brown, D., “Solving the software safety paradox,” Embedded System Programming, December 1998, pp. 44-52.
  • Ganssle, J., The Art of Designing Embedded Systems, Newnes, 2000.
  • IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems (E/E/PE, or E/E/PES), International Electrotechnical Commission, 1998.
  • Lantrip, D. & Bruner, L., General purpose watchdog timer component for a multitasking system, Embedded Systems Programming, April 1997, pp. 42-54.
  • MISRA, Report 1: Diagnostics and Integrated Vehicle Systems, February 1995.
  • MISRA, Report 3: Noise, EMC and Real-Time, February 1995.
  • MISRA, Report 4: Software in Control Systems, February 1995.
  • NASA-GB-8719.13, NASA Software Safety Guidebook, NASA Technical Standard, March 31, 2004.
  • Smith, Digital control of industrial processes, ACM Computing Surveys, Sept. 1970, pp. 211-241.
  • Storey, N., Safety Critical Computer Systems, Addison-Wesley, 1996.

Requirements .. How should I write it?(요구사항.. 어떻게 작성해야 좋을까?)


Issues related to requirements include the following:

  1. How can you divide the boundaries between requirements and design? What content should be recorded in the requirements document and what should be recorded in the design document?
  2. How can we separate the boundaries between system requirements and software requirements?
  3. How can I write good requirements? (How can I make a bad requirement?)

In relation to Issue 1, it is premised that there can not be a clear boundary between requirements and design. In other words, there is no right answer. What I’m talking about here is a recommended approach, but not necessarily.

A requirement is a specification described in terms of ‘What’ and a design is a specification described in terms of ‘how’. (Not necessarily so, but if you have these principles, it’s a little easier to distinguish requirements from design.)

In other words, what features should be implemented? This is a requirement if you need the ability to reduce the sensitivity of the values to the sensor. It is a goal that must be achieved in software. A specific strategy to achieve that goal can be a design. For example, it is possible to recognize a value obtained by cumulatively averaging five values. Alternatively, it can be a way to filter the hardware design to slightly reduce reactivity. This can be included in the design as a strategy to achieve the goal.

I think it is easy to understand up to this point and everyone will be easy to follow. However, if the safety mechanism required by ISO 26262 should be described as a requirement, the situation becomes somewhat complicated.

You need a function to detect the fault for the sensor. Specifically, when it is necessary to detect stuck situations such as stuck at 5V and stuck at ground of sensor, the goal is to detect the fault of the sensor in some way, and how is the function to detect 5V and 0V? I can think of that. Is it the design, not the requirement, to detect the 5V and 0V of the sensor? Wait … Is not it possible to see 5V detection itself as a goal in some way? …

It is like this. It is not always a statement that has a goal attribute, but a statement is a goal from a certain point of view, and a strategy from another point of view. If so, draw a hierarchy for the goal-strategy and divide the boundary at the appropriate level. Up to this point we have categorized it as a requirement, so far we have classified it into a design.

If you add a point to help you break the boundary, you need to think about how you can test it to test the statement. Consider whether the test environment needs to be tested with the integration completed, or whether it is necessary to test during the integration process.

In the aircraft side domain of DO-178C or DO-278A, requirement and design are regarded as high level requirement and low level requirement. That is, high-level requirements are described in the requirement specification and low-level requirements are described in the design specification. This view means that there is no clear classification criteria that is always formal and always applicable to requirements and designs. Some statements can be high level for somebody and low level for others …

Therefore, I do not think it is necessary to apply too strict standards or standards. Even if it is appropriate, nobody says anything. However, the basic principles of goal and strategy (goal, requirement, strategy, design) must be observed.

 

As for issue 2, if most of the system is made up of software, would it make sense to describe it as two kinds of documents? If a particular function is assigned to a hardware chip, motor, or mechanism, the scope of the statement represented by the system and the scope of the statement represented by the software are distinctly different. For example, from the system point of view, if the user input x is input, the motor can be driven at 200 rpm. From a software point of view, when x ‘of the software corresponding to the system-level input x comes into the input, it should be expressed as the motor-related output variable y’ corresponding to 200 rpm.

However, if most of the system is composed of software, the level of description does not seem to be significantly different.

 

Regarding issue 3, it will help you to write good requirements from a testability standpoint.

Examples of bad requirements are:

1) If input x comes in, y should be output as much as possible. – if possible / if possible / if possible / if possible

-> Are you going out? Is it dry? Is it okay if we have to send out y as much as possible?

2) If the input x comes in, you can send out y.

I do not think I will be able to do it if I do not send out the word y.

3) Do not always allow values greater than y.

-> if (condition 1) then do do (action 1) If you have a requirement to describe the requirements from the point of view of action A, and you have created a situation that satisfies condition 1, Do you test? This representation can be useful in formal verification, but it is a worst-case requirement in testing. (That’s why I like formal verification, you’re so perfect …)

-> The safety goal is actually expressed in such a way. “Unintentional acceleration should not occur.” From a testing perspective, when? I want to ask.

4) When the input x comes in, you have to send out y. – fast / slow / proper / comfortable

-> What is the standard of fast? If you can not quantify it is the worst requirement in terms of testing.

 

요구사항과 관련된 이슈들은 다음과 같은 것들이 있다.

  1. 요구사항과 설계의 경계를 어떻게 구분지을 수 있을까? 어떤 내용을 요구사항 문서에 기록하고 어떤 내용을 설계 문서에 기록해야 할까?
  2. 시스템 요구사항과 소프트웨어 요구사항과의 경계는 어떻게 구분지을 수 있을까?
  3. 어떻게 하면 좋은 요구사항을 작성할 수 있을까? (어떻게 하면 망한 요구사항을 만들 수 있을까?)

1번 이슈와 관련되어서는, 요구사항과 설계의 명확한 경계는 있을 수 없다는 전제를 한다. 다시 말하면 정답이 있다는 것은 아니다. 여기에서 언급하는 것도 어디까지나 recommended approach일 뿐이지 반드시 따라야 하는 것은 아니다.

요구사항은 What의 관점에서 기술되는 specification이고 설계는 How의 관점에서 기술되는 specification이다. (반드시 꼭 그렇다는 것은 아니지만, 이런 원칙을 가진다면 요구사항과 설계를 구분하기가 조금 더 쉬워진다.)

다시 말하자면, 구현되어야 하는 기능이 무엇이냐? 센서에 대한 값의 민감도를 줄이는 기능이 필요하다면, 이 것이 바로 요구사항이다. 소프트웨어에서 달성되어야 하는 목표(goal)이다. 그 목표를 달성하기 위한 구체적 전략(strategy)은 설계가 될 수 있다. 예를 들면 5개의 값을 누적 평균한 값을 인식하는 것이 하나의 방법이 될 수 있다. 혹은 하드웨어 설계상으로 필터를 달아서 반응성을 살짝 떨어트리는 것도 방법일 수 있다. 이런 내용이 목표를 달성하기 위한 전략으로서 설계서에 들어갈 수 있다.

여기까지는 쉽게 이해할 수 있고, 다들 따라하기 쉬울 것이라고 생각한다. 그런데 ISO26262에서 요구하는 safety mechanism이 요구사항으로 기술되어야 한다고 할 때에는 약간 상황이 복잡해진다.

센서에 대한 fault를 감지할 수 있는 기능이 필요하다. 구체적으로 센서의 stuck at 5V 및 stuck at ground등과 같은 stuck상황에 대해서 감지를 해야 할 경우, 어떻게 보면 센서의 fault를 감지하는 기능이 goal이고 5V및 0V를 감지하는 기능은 how가 아닌가? 하는 생각이 들 수 있다. 그러면 센서의 5V및 0V를 감지하는 기능이 요구사항이 아니라 설계인가? 잠깐.. 어떻게 보면 5V를 탐지하는 것 자체가 하나의 goal이 되는 것으로 볼 수도 있는 것 아닌가? …

뭐 이런식이다. 항상 어떠한 statement가 goal의 속성을 가지는 것이 아니라 어떤 statement는 어떤 관점에서 보면 goal이기도 하고, 다른 관점에서 보면 strategy이기도 하다. 그런 경우 goal-strategy에 대한 hierarchy를 그려서 적절한 수준에서 경계를 나눈다. 여기까지는 요구사항으로 분류하고, 여기까지는 설계로 분류하고.. 이런 식이다.

경계를 나눌 때 도움이 될 만한 point를 추가하자면, 그 statement를 시험하기 위해서는 어떻게 시험을 할 수 있는지를 고민해봐야 할 필요가 있다. 그 시험 환경이 통합이 완료된 상태에서 시험을 해야 할 필요가 있는 것인지 아니면 통합 과정중에서 시험을 해야 할 필요가 있는 것인지를 생각해본다.

DO-178C나 DO-278A의 항공기쪽 domain에서는 requirement와 design을 High level requirement 및 low level requirement로 간주한다. 즉, high-level requirement는 requirement specification에서 기술하고 low level requirement는 design specification에서 기술한다. 이런 관점은 요구사항과 설계의 언제나 그렇듯 공식적이며 언제나 적용할 수 있는 명확한 분류기준이라는 것이 없다는 것을 의미한다. 어떤 statement가 누구에게는 high level일 수 있고 다른 누구에게는 low level일 수가 있으니까…

그러므로 너무 엄격한 잣대나 기준을 들이댈 필요는 없다고 생각한다. 적당하게 해도 누가 뭐라고 하지 않는다. 다만 goal과 strategy의 기본 원칙(goal은 requirement, strategy는 design)은 준수해야 한다.


2번 이슈와 관련해서는 시스템의 대부분이 software로 이루어진 경우에는 두 종류의 문서로 기술하는 것이 의미가 있겠는가 싶다. 하드웨어 chip이나 모터 혹은 기구부에 특정 기능이 할당된다고 하면 시스템에서 표현하는 statement의 scope과 소프트웨어에서 표현하는 statement의 scope는 명백하게 달라진다. 예를 들면 시스템 관점에서는 사용자 입력 x가 들어오면 200rpm으로 모터를 구동시킨다 등의 표현이 가능할 것이다. 소프트웨어 관점에서는 시스템 수준의 입력 x에 대응되는 소프트웨어의 x’이 입력으로 들어오면 200rpm에 해당하는 모터 관련 출력쪽 변수 y’가 되어야 한다의 식으로 표현해야 할 것이다.

그런데, 시스템의 대부분이 software로 이루어져 있다면 description 수준이 크게 차이날 것 같진 않아보인다.


3번 이슈와 관련해서는 testability관점에서 바라보면 좋은 요구사항을 작성하는데 도움이 될 것이다.

좋지 않은 요구사항의 예는 다음과 같은 것들이 있다.

1) 입력 x가 들어오면 가급적 y를 내보내야 한다. —- 가급적/웬만하면/가능하면/할 수 있으면

–> 내보내라는건가? 말라는 건가? 가급적 y를 내보내야 하니까 형편이 여의치 않으면 안해도 되는건가?

2) 입력 x가 들어오면 y를 내보내면 좋다.

–> 내보내면 좋다는 표현이 웬지 y를 내보내지 않아도 크게 여의치 않을 것 같다.

3) 항상 y보다 큰 값이 나오게 해서는 안된다.

–> if (condition 1) then do action A관점으로 요구사항을 기술해야 condition 1를 만족하는 상황을 만들었을 때 action A를 수행하는지의 여부를 판단하는데, y보다 큰 값이 나오는 상황을 알려주지 않으면 어떻게 시험하는가? 이런 표현 방식은 formal verification에서는 유용할 수 있지만, testing에서는 최악의 요구사항이다. (바로 이것이 내가 formal verification을 좋아하는 이유이다. 넌 너무 완벽해…)

–> safety goal이 사실 저런식으로 표현된다. “의도되지 않는 가속이 발생해서는 안된다.” testing관점에서는 그 때가 언제입니까? 라고 묻고 싶다.

4) 입력 x가 들어오면 빨리 y를 내보내야 한다.  —— 빨리/천천히/적절하게/편안하게

–> 빨리의 기준이 무엇인가? quantify할 수 있지 않으면 testing관점에서는 최악의 요구사항이다.