Winter Term 2011/12 Prof. Dr. Dr. h. c. Dieter Rombach

Software Engineering Research Group: Processes and MeasurementFachbereich InformatikTU Kaiserslautern

Grundlagen des Software EngineeringFundamentals of Software Engineering

Winter Term 2011/12

Prof. Dr. Dr. h. c. Dieter Rombach

Chapter 4.2:

Software Application Engineering – Requirements Engineering for Embedded Systems

Last update: 21/11/2011

� Embedded Systems (ES)�Characteristics

�Req. Categories

�Properties

� Requirement Specification for ES�4 Variables model

�Sequence Based Specification

�Software Cost Reduction

© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 1

AE – RE for Embedded Systems

Goals

� The goals of this chapter are to be able to

– characterize embedded systems (ES)

– identify and define issues relevant for engineering ES

– identify requirements categories for ES

– Use a simple model for documenting functional ES requirements

� Literature

– David Parnas and Jan Madey. Functional Documents for Computer Science. Science of Computer Programming, Elsevier, 1995“

– Stacy J. Prowell, Carmen J. Trammell, Richard C. Linger, and Jesse H. Poore. 1999. Cleanroom Software Engineering: Technology and Process. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.


�Req. Categories

�Properties






Characteristics

� Interaction

– With User – always?

– With environment – always!

� Complex functionality

– Specific tasks (does not imply trivial !!)

� Limited memory

� Application specific control logic

– Special hardware (ASIC/ FPGA/ Microcontroller)

� Low power

– Often battery operated (autonomous)

– Power issues (heat management)

� Low manufacturing cost (mass products)


�Req. Categories

�Properties






Requirements categories

� Functional

– Domain-dependent

– User-dependent

� Non-functional

– Performance �

– Resource consumption (e.g., power)

– Dependability

→ Safety �

→ Reliability �

→ Availability �

→ Maintainability ?

→ Integrity ?

� Inverse

– All safety critical issues

� (Design Constraints)


�Req. Categories

�Properties






Some example properties of interest in software for ES

� Functional

– Real-time (soft � hard!): Button X is pressed � do task in deadline s.

– Response to external events (event-driven/reactive): Button X is pressed � do task

– Temporal: safety and liveness

→ Safety: Something bad will never happen

→ Liveness: Something good will eventually happen.

– Communication and concurrency

– Heterogeneity

� Non-functional

– Performance: Component X processes Y requests / hour

– Resources: Available memory is 128 KB

– Dependability: Failure rate of the component ≤ 10-4 failures / month

� E.g., Fault tolerance ?

– Is this really a property / requirement?

– A means for achieving higher dependability

→ Other means include prevention, removal and forecasting

– However, fault tolerance is often needed e.g., networked ES


�Req. Categories

�Properties






Requirement Specification for ES- A closer look at an ES

CMOS Light(Sensor)

Electronic shutter

(Actuator)

Microcontroller / Microprocessor

Memory(Software )

A/D (D/A) conversion

ASIC / FPGA


�Req. Categories

�Properties






Requirement Specification for ES- A closer look to an ES: Block diagram

Sensor

Actuators

D/A

Control Logic

(Hardware +Software)

System input

System output

A/D


�Req. Categories

�Properties






Requirement Specification for ES- A closer look to an ES: Block diagram

� How do we begin?

– Identify system boundary

→ Interfaces

� Input

� Output

– Define what is true at system boundary

→ Relation between input and output

– Define constraints on the system

→ Also a relation between input and output


�Req. Categories

�Properties






Requirement Specification for ES- Logical model

Sensor

Actuators

D/A

Control Logic

(Hardware +Software)

Monitored valuem(t)

Controlled valuec(t)

A/D

O(t)i(t)

Input device

Output device


�Req. Categories

�Properties






� System requirements document

– Black-box view of the system

– Description of the environment

→ Constraints from the environment e.g., physical laws

– Constraints relevant for the system to be built

– Assumptions

� Document whose content is defined by mathematical r elations

� Before we continue, Elementary set-theoretic concep ts:

– Relation

→ AH: Set of {Age, Height}: {{20, 170}, {25,170}, {30,180}, {35,185}}

– Function

→ NA: Set of {Name, Age}: {{A, 20}, {B, 25}, {C, 30}, {D, 35}}

→ A well-behaved relation

– Domain

→ For a function f or a relation r domain Dom ( f) or Dom (r) : X-values

→ Dom (AH): {20, 25, 30, 35}

– Range

→ For a function f or a relation r range Ran (f) or Ran (r) : Y-values

→ Ran(NA): {20, 25, 30, 35}


�Req. Categories

�Properties






4 Variables model

SOFMonitored valuem i(t)

Controlled valuec i(t)

Oi(t)

i i(t)

Sensor

Input device

Actuators

Output device

Logical System boundary REQ


�Req. Categories

�Properties






4 Variables model- Monitored and Controlled variables

� Characteristics

– Monitored variables: (Sensor) Variables whose values influence output of the machine / system

– Controlled variables: (Actuator) Variables whose values are determined by the system

– Exist (are visible) outside the system boundary

→ Often physical quantities

– Values often vary with time

� Mathematically

– Monitored variables m i(t)

→ m(t): R � Value

� “m”: function assigning a time dependent real value.

→ M(t) : {m1(t), m2(t), …, mn(t)} : Vector of monitored variables

– Controlled variables c i(t)

→ c(t): R � Value

� “c” : function assigning a time dependent real value.

→ C(t) : {c1(t), c2(t), …, cn(t)} : Vector of controlled variables


�Req. Categories

�Properties






4 Variables model- Input and Output variables

� Input variables– Input variables ii(t)

→ Variables whose values are the result of measurement of mi(t)– Output variables oi(t)

→ Variables whose values are the result of computation by the machine

� For all ( ∀∀∀∀) m i(t) there exists ( ∃∃∃∃) a corresponding i i(t)� ∀∀∀∀ c i(t) ∃∃∃∃ o i(t)

– Vice-versa need not be true– Often ii(t) and oi(t) will be discrete and digital

→ If the machine is HW/SW control logic


�Req. Categories

�Properties






4 Variables model- Relations

� NATural constraints expressed as a relation between the vectors of monitored variables M(t) and controlled variables C(t)

– Dom (NAT): values of M(t) – Ran (NAT): values of C(t) – {M(t), C(t)} ∈ NAT if and only if (iff) environment (nature) permits the behavior

� REQuirements specified as a relation between the vec tors of monitored variables M(t) and controlled variables C(t)

– Dom (REQ): values of M(t) – Ran (REQ): values of C(t) – {M(t), C(t)} ∈ REQ iff system should permit the behavior

� INput device description is a relation between monit ored variables M(t) and Input variables I(t)

� OUTput device description is a relation between outp ut variables O(t) and controlled variables C(t)

� SOFtware requirements specified as a relation betwee n Input variables I(t) and output variables O(t)

– Dom (SOF): values of I(t) – Ran (SOF): values of O(t) – {I(t), O(t)} ∈ SOF iff software should permit the behavior


�Req. Categories

�Properties






4 Variables model- Properties

� This should ALWAYS be true– Dom (REQ) ⊇⊇⊇⊇ (is a subset of) Dom (NAT) or document is incomplete– If (Dom (NAT ∩∩∩∩ REQ) = Dom (NAT) ∩∩∩∩ Dom (REQ)) also holds then REQ is

considered feasible with respect to NATElse system breaks laws of nature

� Software behavior is acceptable if

∀∀∀∀ M(t), C(t), I(t), O(t) [IN(M(t), I(t)) & SOF(I(t),O(t)) & OUT(O(t), C(t)) & NAT(M(t), C(t)) ]

→ REQ(M(t), C(t) )


�Req. Categories

�Properties






4 Variables model- Summary

MON CON

INPUT OUTPUT

NAT

REQ

SOF

IN OUT


�Req. Categories

�Properties






4 Variables models

� We now know:

– What to document in an system requirement specification of embedded systems

– What properties it must satisfy

→ Completeness, feasibility, acceptability (of software)

– Abstraction

� How do we go about documenting this?

– Natural language

→ Common practice

→ Can be imprecise and ambiguous

– Critical systems demand usage of formalized notation where syntax and semantics are precisely defined

– Known example

→ SBS

→ Software cost reduction


�Req. Categories

�Properties






Sequence Based Specification

� Tag requirements

� Define system boundary

– Identify stimuli

– Identify responses

– Choice of appropriate abstraction

→ Stimuli and responses could change depending on the level of abstraction

� Systematic enumeration of Stimuli Sequence � Response and Stimuli Sequenceequivalence


�Req. Categories

�Properties







� Tag requirements

Tag Requirements

1The security alarm has a detector that sends a trip signal when motion is detected

2 The security alarm is activated by pressing the SET button

3 The SET button is illuminated when the security alarm is set

4If a trip signal occurs while the security alarm is set, a tone (alarm) is emitted

5 A three-digit code must be entered to silence the alarm tone

6 Correct entry of the code deactivates the security alarm

7If a mistake is made when entering the code, the user must press the CLEAR button before the code can be reentered


�Req. Categories

�Properties







� Define system boundary

– Identify stimuli

– Identify responses

Stimulus Description Symbol Trace

Set Device activator S 2

Trip Signal from detector T 1

BadDigitIncorrect entry of a digit in thecode

B 7

Clear Clear entry C 7

GoodDigit

A digit that is part of thecorrect entry of the 3-digitcode that deactivates the alarmand the device

G 5,6

Response Description Trace

Light On Set button illuminated 3

Light Off Set button not illuminated 6

Alarm On Alarm tone activated 4

Alarm Off Alarm tone deactivated 5


�Req. Categories

�Properties







� Systematic enumeration of Stimuli Sequence � Response and Stimuli Sequence equivalence

– Rule:

→ Do not extend the sequence IF

� the response is “illegal” OR IF

� the sequence is declared equivalent to a previous sequence

� ELSE extend

– Sequences of length 0 and 1

– Derived requirements

Sequence Response Equivalence Trace

λ (empty) null D1

S Light On 2, 3

T Illegal D1

B Illegal D1

C Illegal D1

G Illegal D1

D1 The security alarm is initially deactivated


�Req. Categories

�Properties








– Sequences of length 2


SS null S D2

ST Alarm On 4

SB null D3

SC null S D4

SG null D5

D2After the device has been set, the Set button has no further effect until the device has been deactivated

D3 The device produces no external response to an erroneous entry

D4 The device produces no external response to a Clear entry

D5The device produces no external response to correct entry of a GoodDigit until all three digits of the code have been entered


�Req. Categories

�Properties








– Rule:

→ The enumeration is complete if there are no more sequences to extend

– Sequences of length 5


STGGS null STGG D2

STGGT null STGG D6

STGGB null STB D3

STGGC null ST D4

STGGGAlarm OffLight Off

λ 3, 5, 6


�Req. Categories

�Properties






Software cost reduction (SCR)

� Developed at the US Naval Research Labs during the development of the A-7 aircraft

– Tabular representation of state changes

– Uses 2 of the relations from the 4 variable model (NAT, REQ)

– Synchronous model

→ One set of inputs processed in a state before processing the inputs at next state

– One input assumption

→ Only one input changes at a time

MON MON

INPUT OUTPUT

NAT

REQ

SOF

IN OUT

SCR mainly deals with this part


�Req. Categories

�Properties






Elements of the SCR model

� System is a state machine (S, S 0, Em,T) consisting of

– States S, initial state S0

– Em : set of monitored events

– T : allowable transitions

→ Function mapping monitored event (e ∈ Em) and the current state (s ∈ S) to the next state (s’ ∈ S)

� System mode class: An equivalence class of system s tates (a set of states)

– Values of a mode class are called modes

� Condition: Predicate defined on a single system state

– Predicate is often a Boolean-valued function

� Event: Predicates on two system states

� Occurrence: An event occurs if a condition changes

� Conditioned event: @T(c) WHEN d

� @T(c): @T(c) WHEN TRUE: c becomes True

� @F(c): @T(c) WHEN FALSE : c becomes False


�Req. Categories

�Properties






Types of SCR tables

� Variable Tables: Definition of monitored & controlled variable values

� Mode Condition Table: Definition of modes based on monitored variables

� Mode Transition Table: Mode transitions described as a function of current mode and monitored variables

– i.e. (conditioned) monitored events

� Event Table: Definition of values of a controlled variable given (conditioned) monitored events and modes

Functions should be total i.e. defined for all poss ible inputs


�Req. Categories

�Properties






Software Cost Reduction

mSetmTripmNumber[1,2,3]mClear

ClightcAlarm

I O

Req

Sof

SW-System

mVar cVar

System


�Req. Categories

�Properties






Variable tables – monitored variables

mSet

Event / Condition Values

Initial OR

@T(!3 correct digits entered!) when mSet=$on$

$off$

@T(!user pushes setButton!) $on$

mTrip


@T(!motion_detected)when mTrip = $off$

$on$

Initial OR @T(!3 correct digits entered!)

when mTrip = $on$$off$

mNumber[i=1..3]


Initial OR

@F(!user pushes the right digit number i!)

$F$

@T(!user pushes the right digit number i!)

$T$

mClear


@T(!user pushes clear button!)

when mSet = $on$$on$

Initial OR

@T(!user entered a digit!)$off$


�Req. Categories

�Properties






Variable tables – controlled variables

cLight


Initial OR

@T(mSet = $off$)$off$

@T(mSet=$on$) $on$

cAlarm


Initial OR

i=1,2,3: mNumber[i] = $T$$off$

@T(mTrip=$on$) when $mSet$ = $on$

$on$


�Req. Categories

�Properties






Contition table

� Describe Modes (= externally visible states)

– Informal

– Mode condition table

� Example of a mode condition table:

mode condition

*off* mSet = $off$

*on* mSet = $on$ AND

- *passive* mTrip = $off$ AND

- *pas_0*

- *pas_1* mNumber[1] = $T$

- *pas_2* mNumber[2] = $T$

- *active* mTrip = $on$ AND

- *act_0*

- *act_1* mNumber[1] = $T$

- *act_2* mNumber[2] = $T$


�Req. Categories

�Properties






Mode transition table

� Describe Mode transitions

– Informal

– Mode transition matrix

� Example of mode transition matrix (automobile):

inputmode

output mode

* off * * inactive * …

* off *@T(ignitio

nVar = $on§)

…

* inactive *@F(ignitio

nVar =$on$)

… …

… … … …


�Req. Categories

�Properties






Mode transition table

I / O *off* * act_0 * *act_1* *act_2* *pas_0* *pas_1* *pas _2*

*off* @T(mSet = $on$)

*act_0* @T(mNumber[1] = $T$)

*act_1* @T(mNumber[1] = $F$) OR @T(mClear=$on$)

@T(mNumber[2] = $T$)

*act_2* @T(mNumber[2] = $T$)

@T(mNumber[2] = $F$) OR @T(mClear=$on$)

*pas_0* @T(mTrip = $on$)


*pas_1* @T(mTrip = $on$)

@T(mClear=$on$)


*pas_2* @T(mNumber[3] = $T$)

@T(mTrip = $on$)

@T(mClear=$on$)


�Req. Categories

�Properties






Event table

� Give time-independent specification of the sw funct ion

Mode Conditions

*X* Cond 1 Cond 2 Cond 3

*automaticon*

!too slow! …. …

cAccelerate

!increasespeed!

….. …..

mode Conditions

*off*

*pas_0*

*pas_1*

*pas_2*

*act_0*

*act_1*

*act_2*

---

T

T

T

T

T

T

T

---

---

---

---

---

---

---

---

---

---

T

T

T

T

T

T

T

---

---

---

cLight $on$ $off$

cAlarm $on$ $off$