Back to Software Engineering

75

Successful Software
Applications
What represents success? Well engineered software
is:
Correct in that it both provides the behaviour the client
requires, and also implements that behaviour according to
an agreed on specification
Reliable in that the software performs its required functions
under specified conditions for a specified period of time
Efficient in that it performs its functions within a specified
time and within specified resources
Maintainable over its lifetime in that it is robust with respect
to changes that have to be made the level of confidence
that it meets all its quality attributes is maintained after
changes are made to the system
Intuitively usable with an appropriate user interface
76

3 Vital Components in SE
(The 3 Ps)
People
Must be qualified i.e. competent to do their work
Each person has a specified role (perhaps more
than one)

Process
There are various development processes with
different pros and cons
Waterfall, spiral, agile

Product
The tangible implementation (code, firmware, etc)
Support documents (requirements, design,
analysis, reviews, testing)
77

People
Team members have specific tasks and must
have the training to perform those tasks
Social skills often are as important as
technical skills easy to understand when we
know that software engineering is performed
by groups
Cohesive groups are a pre-requisite for
success and good communications within
and between groups is essential
We have excellent tools to support some of this
78

Process
An effective process must have well defined
steps with explicit milestones and clear success
criteria for each task
The process provides guidance on what to do
next
It helps prevent essential steps from being
skipped
It facilitates planning and scheduling
A well-planned rational process helps us avoid
duplication of effort
work that is not directly useful for the task at hand
79

Example Processes
Software
development
life-cycle is often
referred to as SDLC

Waterfall Model

Requirements analysis
and specification
Design and specification

Code and module

testing

From
Fundamentals of Software
Engineering, Ghezzi, Jazayeri
& Mandrioli

Integration and
system testing
Delivery and
maintenance

Spiral Development
from
Washington University
Computer Science

ati

Ve
ri

fic

Verification connection
to Development

t
en
pm
elo

v
De
time

on

V-Model

time

80

Product
Documentation
Planning documents (including standards), especially
configuration management and revision control
Development documents such as hazard analyses,
requirements, design, code listings, test reports
Installation documents
User guides and operations documents
Maintenance documents

Executable code or alternatives such as circuits for

Field Programmable Gate Arrays (FPGAs)

81

Standards
There are many international standards that govern
the development of software-dependent systems
The three main international standards bodies in this regard
are: IEEE, ISO and IEC

Current standards have a number of positive

attributes
They provide guidance for those who are new to the process
And may be effective teaching tools for all users

They aid forward progress by suggesting next steps

They were designed to serve as a foundation for achieving
and maintaining quality products (unfortunately most
standards are process-focused, and following a good
process is not guaranteed to produce a high quality product)
82

Standards (continued)
Standards provide a means to capture
international consensus on what constitutes
professional practice in their respective areas
Many process oriented standards recommend
ways to avoid systematic errors

83

Summary: Recap of Software

Engineering
Engineering approach to software development
Rigorous rather than hacking
It is much more than good ways to code
The product includes code, but also all supporting
documentation

Requires well-prepared people and processes to

produce an adequate product

Qualified people
Applying a planned and systematic process
Resulting in a well-engineered system
With adequate objective evidence that all quality attributes
have been achieved
84

A Disciplined Approach

Software Quality Attributes

Software Development Principles
Software Processes

85

Engineering
The profession of Engineering was started in
order to further technological innovation and
deployment while protecting the public from
harm
It is natural, therefore, to consider our
responsibility when developing softwareintensive systems that have the capability of
causing harm

86

Safety
Safety is basically freedom from harm
It is a global property of the system you can take 2
components that are provably safe on their own, but
when you put them together the resulting system is
not safe
Developers of safety-critical software must ensure
that
system safety requirements are complied with
the software does not introduce behaviours that could
contribute to the system causing harm
the software will maintain any equipment and processes the
system controls in a safe state, even when hardware fails
must not allow inappropriate system inputs to result in the
87
system causing harm

Safety-Critical Software
Safety-critical systems are those systems in which a
failure may lead to a catastrophic result loss of life,
serious injury, etc.
Safety-critical software is software used in a safetycritical system (definitions coming a little later)
What is different about safety-critical software compared
with general software?

Safety (and security) as a primary goal

ALARA Risk is As Low As Reasonably Achievable
Development with licensing in mind
Hazard analysis
Hard real-time behaviour
Enhanced rigour
Thorough documentation
Stakeholders

88

Safety-Critical Software:
Safety and Security
Safety*: the expectation that a system does
not, under defined conditions, lead to a state
in which human life, health, property, or the
environment is endangered
Security*: the protection of system items
from accidental or malicious access, use,
modification, destruction, or disclosure
* ISO/IEC/IEEE 24765, Systems and software engineering
Vocabulary, 2010-12-15

89

Examples of
Safety-Critical Systems
Pacemaker

Plane
Nuclear Power Station

Train

Modern Car
Insulin Pump

90

Regulation
With regard to software, some application
domains are regulated

Nuclear power
Civil aviation
Medical devices
Trains

Some are not

Automobiles!

91

Example US Nuclear
Regulation

92

Safety-Critical Example
SDS1 & SDS2: Real-Time Monitoring &
Shutdown at a Nuclear Power Plant
These computer systems have hard deadlines in
which they have to detect potential accident
scenarios.
They also have hard deadlines in which they have
to initiate alarms, and, if necessary, initiate
shutdown of the reactor.

93

Safety-Critical Software
Validation Test and
Reliability Qualification
Reports

HAR

System
Requirements
& Design

HAR

Software Integration
Test Report

Software
Requirements
Specification

The essential
components
of the SDLC
Design Review and
Verification Reports

Software
Design
Description

Unit Test
Report

HAR

Legend:
Documents produced in the
forward going development process
Documents produced by
verifications, reviews, analyses and
testing
Activities and data flow
HAR

Hazard Analysis Report

HAR

Code
Code Review and
Verification Reports

94

10

Requirements - 1
Trip Computer Design Requirements (Mills
Black-Box)
Mills, H.D.: Stepwise
refinement and
verification in boxstructured systems.
Computer 21 (1988)
23-36

S1-1
S2-1
S3-1

S1
S2S2
-1
S3

R1
R2

R1 -1
R2 -1

System

R = f ( S, Sh )
S is the set of stimuli, Sh the set of
stimulus history, R the set of responses

95

Top-level Requirements
TCDR

Context diagrams
Stimuli & Responses
Constants
Main function tables - with rationale
Natural language expressions
Tolerances, PTRs and FTRs
Anticipated changes
Changes from previous freezes - rationale

96

11

Black-Box Requirements
We expect that all responses are described in
terms of stimuli and stimuli history only.
It is sometimes advantageous to allow
response history to appear in functional
descriptions.
In deterministic systems, response history is
always a representation of stimuli history.

97

Notation - 1
We refer to stimuli as monitored variables,
and responses as controlled variables.
We prefix identifiers by a suitable character
followed by _ to help identify the role of the
identifier.
m_ name is a monitored variable, c_name is
a controlled variable, k_name is a constant,
etc.

98

12

Notation - 2
m_name represents value of the
current instance of m_name.
m_name-1 represents value of the
previous instance of m_name.
If m_name is time-continuous, theres
an arbitrarily small time, dt, between
m_name and m_name-1.
tnow represents current time.

99

Notation - 3
If m_name is time-discrete, time
between m_name and m_name-1 is
t(m_name) - t(m_name-1). In general,
t(var) returns time stamp of the
instance of var.
In a real system it will not be possible
to represent R = f(S,Sh) by a single
function or function table
So we decompose the function f into a
network of sub-functions
100

13

Example Function

k_setpoint

NON-TRIP REGION

m_signal3
NON-TRIP REGION

k_hysteresis
TRIP REGION

f_sensortripi, i=1,..,4
{For each i = 1,..,4}

Result
Condition

k_setpoint m_signali
{ith signal is now in the trip region}
k_setpoint - k_hysteresis < m_signali < k_setpoint
{ith signal is now in the deadband region}
m_signali k_setpoint - k_hysteresis
{ith signal is now in the non-trip region}

f_sensortripi
e_Trip
No Change
e_NotTrip
101

Anticipated Changes - 1
Information Hiding is a software design paradigm that was
introduced by Parnas in a famous paper in the early 1970s.
The original version of Information Hiding used anticipated
design changes to drive the software decomposition.
It turns out that requirement changes are an even greater
source of secrets.

Parnas, D.: On the criteria to be used in decomposing

systems into modules.
Communications of the ACM December (1972) 1053-1058
102

14

Anticipated Changes - 2
Table 9.1-1 - Anticipated Changes
Id
AC-1

Anticipated Change
Provisions shall be made in the software coding to give all
power dependent setpoints the ability to handle arbitrary
setpoint functions (instead of the current step functions). As
a minimum requirement, facilities to accommodate a
setpoint value for each 1% power change shall be provided
up to an upper limit of 110% Full Power (FP).

AC-2

Ranges as specified in the table that defines values of

constants, see [27], shall be pre-verified so that the
application can use any trip setpoint in the relevant range.

AC-3

New parameter trips may be added.

AC-4

The algorithm and number of detectors used for the

estimated power calculation may change from the current
specification.

AC-5

Individual deadbands may be revised, HTLF in particular.

AC-6

The processing time for the HTLF analog inputs may be

reduced by 100 ms to make provisions to reallocate delay
external to the trip computer, see [47], 2.2.2.

103

More Requirements

Trip Computer Design Description

Uses TCDR as a basis
Adds design information, e.g. pushbutton
debouncing
Model changes to a Finite State Machine with an
arbitrarily small clock-tick
SRS contained within TCDD

104

15

Finite State Machine Model

C(t) - set of controlled vars at time t

M(t) - set of monitored vars at time t
S(t) - set of state vars at time t
t0 - time of initialisation
S(t0) must be known

C(tk) = REQ(M(tk), S(tk))

S(tk+1) = NS(M(tk), S(tk)), k=0,1,2,3,...

105

FSM for Requirements

We have very
simple states in the
TCDD. If f_name
is a function,
f_name-1 is the
value of f_name at
the previous clock
tick. It is a state
variable.

M(tk)

S(tk+1)

NS(M(t k),S(t k))

REQ(M(t k),S(t k ))

C(tk)
106

16

TCDD Documentation

Context diagrams
Monitored & Controlled Variables
Constants
Main function tables
Natural language expressions
M-I mappings, transfer events
C-O mappings, transfer events
Tolerances, PTRs and FTRs
Anticipated changes
Changes from previous freezes

107

TCDD Documentation

Context diagrams
Monitored & Controlled Variables
Constants
Main function tables
Natural language expressions
Well find out
M-I mappings, transfer events
what these are
C-O mappings, transfer events
later
Tolerances, PTRs and FTRs
Anticipated changes
Changes from previous freezes

108

17

Design Details in TCDD

We can see how debouncing pushbuttons
affects the behaviour specified in the TCDR.
In particular, NOP Abnormal 1 setpoint is
requested or cancelled is specified in the
TCDR without debouncing and then respecified in the TCDD with debouncing.

109

Pushbuttons in TCDR
A natural-language expression
Result

Condition

(m_NOPspAbn1ON = e_NotPressed) &

(m_NOPspAbn1OFF = e_NotPressed)
(m_NOPspAbn1ON = e_NotPressed) &
(m_NOPspAbn1OFF = e_Pressed)
(m_NOPspAbn1ON = e_Pressed) &
(m_NOPspAbn1OFF = e_NotPressed)
(m_NOPspAbn1ON = e_Pressed) &
(m_NOPspAbn1OFF = e_Pressed)

NOP Abnormal 1
setpoint is requested
or cancelled
No Change
cancelled
requested
requested
110

18

Debounce Pushbuttons - 1
Pushbuttons in the TCDD
Result

f_NOPspAbn1OFF f_StuckNOPspAbn1OFF

Condition

m_NOPspAbn1OFF = e_NotPressed e_pbNotDebounced

[ m_NOPspAbn1OFF = e_Pressed ]
&
e_pbNotDebounced
NOT [ (m_NOPspAbn1OFF =
e_Pressed) Held for k_Debounce ]
[ (m_NOPspAbn1OFF = e_Pressed)
Held for k_Debounce ] &
e_pbDebounced
NOT [ (m_NOPspAbn1OFF =
e_Pressed) Held for k_pbStuck ]
(m_NOPspAbn1OFF = e_Pressed)
e_pbStuck
Held for k_pbStuck

False
False

False
True

111

Debounce Pushbuttons - 2
So, NOP Abnormal 1 setpoint is requested or
cancelled is now defined in terms of
f_NOPspAbn1ON/OFF
NOP Abnormal 1
Result

Condition

f_NOPspAbn1ON = e_pbStuck OR
f_NOPspAbn1OFF = e_pbStuck
f_NOPspAbn1ON = e_pbNotDebounced &
f_NOPspAbn1OFF = e_pbNotDebounced
f_NOPspAbn1ON = e_pbNotDebounced &
f_NOPspAbn1OFF = e_pbDebounced
f_NOPspAbn1ON = e_pbDebounced &
f_NOPspAbn1OFF = e_pbNotDebounced
f_NOPspAbn1ON = e_pbDebounced &
f_NOPspAbn1OFF = e_pbDebounced

setpoint is requested
or cancelled
requested
No Change
cancelled
requested
requested
112

19

Debounce Pushbuttons - 3

113

Functional Timing Reqs - 1

We need to examine functional timing

requirements in more detail.
As an example, consider a sensor trip that
depends on a sensor (signal) being in a trip
state for a sustained period of time.

114

20

Functional Timing Reqs - 2

f_HTLFsentripi , i=1,..,4
{For each i = 1,..,4}

Result
Condition

tnow
k_HTLFdelay

(f_HTLFimmsentripi = e_Trip) Held for (k_HTLFdelay)

f_HTLFsentripi
e_Trip

{Immediate sensor trip active for at least past k_HTLFdelay time period}

NOT [ (f_HTLFimmsentripi = e_Trip) Held for (k_HTLFdelay) ]

e_NotTrip

{Immediate sensor trip not active for at least one instant in past k_HTLFdelay
time period}

tnow <
k_HTLFdelay

(f_HTLFimmsentripi = e_Trip) Held for (tnow)

e_Trip

{Immediate sensor trip active since initialization}

NOT [ (f_HTLFimmsentripi = e_Trip) Held for (tnow) ]

e_NotTrip

{Immediate sensor trip not active for at least one instant since initialization}

So - what is this Held for thing?

115

Functional Timing Reqs - 3

Allowing tolerances on timing
constants can cause significant
problems

116

21

Definition of Held for

(Condition: bool) Held for (d: R >0, L, R: R 0): bool
duration(Condition: bool): [d- L, d+ R]
Event_start_time(Condition: bool): R 0
Initially:
duration = any value in [d- L, d+ R]; Event_start_time-1 = 0; Condition-1 = False
duration
(Condition = True) & (Condition-1 = False)
(Condition = False) or (Condition-1 = True)

Any value in
[d- L, d+ R]
No Change

Event_start_time
tnow
No Change
Held for

Condition = True

tnow Event_start_time duration

tnow Event_start_time < duration
Condition = False

True
False
False
117

Another General FTR

118

22

And Another General FTR

This one is synchronized with an external clock.

119

Functional Timing
Requirements
Functional timing requirements are timing
requirements that are directly related to the required
behaviour of the application
So, Held for, Periodic and SyncPeriodic are
examples of templates describing functional timing
requirements
Other common functional timing requirements can
be modeled in similar fashion
These requirements are interpreted within the
constraints of the governing model, in our case the
discrete time FSM with arbitrarily small clock-tick.
This describes idealized behaviour with the
capability of including tolerances on all timing
120
durations

23

Performance Timing
Requirements
Idealized behaviour totally ignores the fact that an
implementation cannot continuously monitor sensor
values and requires a finite, non-zero amount of time
to process its results
To complete the description of the required
behaviour, a requirements document must also
specify the performance tolerances that are allowed
in meeting functional timing requirements
We identify two different performance timing
requirements
Timing Resolution
Response Allowance
121

Timing Resolution

122

24

Response Allowance
Response Allowance
The Response Allowance (RA) for a controlledmonitored variable pair specifies an allowable
processing delay
Each controlled variable must have an RA
specified for it. The RA applies to the controlled
variable and the particular monitored variable on
which the controlled variables behaviour depends
The RA is measured from the time the event
actually occurred in the physical domain, until the
time the value of the controlled variable is
generated and crosses the application boundary
into the physical domain
123

The 4 Variable Model

NAT
REQ

IN

SOF

OUT

Software Design
Parnas, D.L., Madey, J.:
Functional documents for
computer systems. Science of
Computer Programming 25
(1995) 41-61

C = REQ(M*), and related to the

software through
124
I = IN(M) and C = OUT(O)

25

The 4 Variable Model

NAT

environmental relation

REQ

requirements

hardware
IN

hardware
SOF

OUT

Software Design
Parnas, D.L., Madey, J.:
Functional documents for
computer systems. Science of
Computer Programming, 25
(1995) 41-61

C = REQ(M*), and related to the

software through
125
I = IN(M) and C = OUT(O)

Input and Output Variables

The TCDD specifies transfer events (what
the software must do to trigger getting a
software input, I, or emitting a software
output, O).
The TCDD also specifies the M-I mappings,
and C-O mappings (what the hardware
does).

126

26

Performance Timing Reqs &

Anticipated Changes
The TCDD specifies a modified list of
performance timing requirements that takes
into account the design aspects added in the
TCDD.
The TCDD also lists a (potentially modified)
list of anticipated changes.

127

Performance Timing Reqs

Table 2.2.2 - Timing Requirements
Controlled
Variable

Governing
Variables

c_NOPparmtrip m_NOPaii, i=1,..,18

PTR

TR

Reference

160 ms

Default

TCDR

(Already
more
restrictive
than required
to meet sealin)
350 ms
TCDR and
m_NOPspAbn1OFF 850 ms (Held
for
[13], #1 and
m_NOPspAbn1ON k_Debounce)
[23]
/ 500 ms
m_NOPspAbn2OFF
m_NOPspAbn2ON
m_NOPspLPOFF
m_NOPspLPON
m_CalibrateEnable
M_RxFnType

Example for
c_NOPparmtrip

M_RxNOPGaini,
i=1,..,18

N/A

1000 ms

TCDR

2000 ms

Default

TCDR

N/A

2000 ms

TCDR

128

27

Example Function in TCDD

2.3.1

S t e am Generator Low Level Sensor Trip

Determines whether there is a Steam Generator low level sensor trip, which is used to
determine whether there is an associated parameter trip.
2.3.1.1

I nputs/Natural Language Expressions

Input
f_SGLLsp
m_SGLeveli, i=1,..,4
2.3.1.2

NL Expression
-

I nitial Value
Name

Initial
Value
e_Trip

(f_SGLLsentripi)-1, i=1,..,4
2.3.1.3

Reference
TCDR

O u tput Units/Type

Output
f_SGLLsentripi, i=1,..,4
2.3.1.4

Reference
2.3.3.4
Table 2.6.1-1

Type
y_trip

f_SGLLsentripi, i=1,..,4

{For each i = 1,..,4}

Result
Condition

f_SGLLsp m_SGLeveli
{SG leveli signal is now in the trip region}
f_SGLLsp + k_SGLLhys > m_SGLeveli > f_SGLLsp
{SG leveli signal is now in the deadband region}
m_SGLeveli f_SGLLsp + k_SGLLhys
{SG leveli signal is now in the non-trip region}

f_SGLLsentripi
e_Trip
(f_SGLLsentripi)-1
e_NotTrip

129

28