V-cycle

Development
Process
Software Engineering Case Study

Speaker
Marco Bozzano
ITC-irst
Automated Reasoning System Division
Formal Methods Group
E-mail: bozzano@irst.itc.it

Software Engineering Case Study

Overview
"

"

"

"

"

"

"

Some Motivations
Motivating Examples
Waterfall / V-cycle Process
Formal Methods
Case Study
Conclusions
Future

Software Engineering Case Study

Some Motivations
"

Certain classes of software applications require strongly

controlled development processes:
Highly critical systems (safety, environment)
Complex system (environment, functionalities)
Commercial applications (costs)
Strong requirements (traceability, maintainance, long term
modifiability, documentation)
"

"

"

"

"

The goals of such development processes are:

Achieve higher quality standards
Allow for product certification
Reduce time to market
"

"

"

Software Engineering Case Study

Example 1 - Problem
A simple problem

The controller (Ctrl) has to keep the water

level of a tank between two values: Lmin,
Lmax.
"

Ctrl

The controller continuously reads current

level from a 16 bit analogical/digital sensor.
"

The controller activates a relais to open

and close the out valve of the tank.

"

Software Engineering Case Study

Example 1 - Solution
Solution
System behaviour can be split into two functions: ReadLevel e
ActivateRelais.
"

We assign ReadLevel function development to Team 1 e

ActivateRelais function development to Team 2.
"

We deliver the relevant requirements document to Team 1 and to

Team 2.
"

Software Engineering Case Study

Example 1 Implementation
(1/3)
Team 1: ReadLevel

// read current level from sensor and return it

double ReadLevel() {
unsigned int sensor_readout;
double water_level;
Read_From_Sensor(& sensor_readout);
// 0 = 0 feet, 65535 = 35 feet
water_level = sensor_readout * 35 / 65535;
return water_level;
}

Software Engineering Case Study

Example 1 Implementation
(2/3)
Team 2: ActivateRelais

// open valve if level is approaching Lmax.

// close it if the level gets below Lmin
void ActivateRelais(double Lmax, double Lmin, double current_level) {
if (current_level > Lmax)
Open_Relais_Command();
if (current_level < Lmin)
Close_Relais_Command();
}

Software Engineering Case Study

Example 1 Implementation
(3/3)
Main: Putting All together
// tank is three meters high
#define LMAX 3.0
// we need the tank at least this full
#define LMIN 1.0
main () {
double water_level;
while (water_level = ReadLevel()) {
ActivateRelais(LMAX, LMIN, water_level);
}
}

... the system satisfies the requirements ...

... but fails at run-time, because ...
... measurements units are different !!!
Software Engineering Case Study

Example 1 Considerations
(1/2)
September 23, 1999
Mars Climate Orbiter burns out
while approaching Mars
atmosphere.
Mission cost: 156 M$
"We had planned to approach the planet at an altitude of about 150
km. We thought we were doing that, but upon review of the last six to
eight hours of data leading up to arrival, we saw indications that the
actual approach altitude had been much lower. It appear that the
actual altitude was about 60 km.
Richard Cook, project manager Mars Surveyor Project
Software Engineering Case Study

10

Example 1 Considerations
(2/2)
Motivations for mission failure
"

Root cause: Failure to use metric units in the coding of a ground software file,
"Small Forces" used in trajectory models.
Background causes:
Mission Management:
Navigation Team unfamiliar with spacecraft.
Trajectory correction manoeuvre number 5 not performed.
Project Management:
Inadequate communications between project elements.
Inadequate operations Navigation Team staffing.
Inadequate training.
Technical Requirements:
Undetected mismodeling of spacecraft velocity changes.
System engineering process did not adequately address transition
from development to operations.
Verification and validation process did not adequately address
ground software.
11
Software Engineering Case Study
"

"

"

"

"

"

"

"

"

"

"

Example 2
Marketing aspects
Software applications used for the production of systems on a large
scale basis (e.g., embedded systems) have to take into account also
commercial aspects and market issues (time-to-market, development
costs, marketing costs).
Development Time:
Time required to develop a product to
the point it can be sold to customers
Market window:
Period during which the product
would have highest sales
Average time-to-market constraint is
Time (months)
about 8 months.

Revenues ($)

"

Delays are costly.

Software Engineering Case Study

12

Example 2
Bugs costs
The cost of bugs is crucial
and increases exponentially
with the development time.
"

Bugs Costs

Development Phases

"

Some well-known examples:

"

Pentium bug

"

MULTICS
Software Engineering Case Study

13

Waterfall / V-cycle Processes

Code & Fix Shortcomings
"

"

"

Absence of requirement specification

Small variations of requirements generally have a great impact on
the code
Inability to detect bad design or implementation errors since the
early stags of development

"

Inefficient, unreliable, un-maintainable code

"

Extreme difficulty in meeting the customers needs

Software Engineering Case Study

14

Waterfall / V-cycle Processes

Solution
"

"

The complete solution to Code & Fix process drawbacks

requires a neat detachment from its perspective on system
development.
We need not only to devise a new kind of process but also to gain
advantage from different methodological skills.

Waterfall / V-cycle
+
Formal Methods
Software Engineering Case Study

15

Waterfall / V-cycle Processes

Validation

De
ve
n
me
lop

HW / SW
Components
Design

Validation

Validation

System
Integration &
Test

Module
Integration &
Test

ng

System
Analysis &
Design

System
Acceptance

Te
sti

Requirements
Analysis

HW / SW
Implementation &
Unit Test

Software Engineering Case Study

16

V-cycle Processes
Discussion
"

Drawbacks:
System validation begins after implementation.
No particular format is devised for requirements and design
specification, thus allowing for ambiguity and inconsistencies.
"

"

"

Solution = V-cycle + Formal Methods

"

Formal Methods = Formal Notations + Tools

Software Engineering Case Study

17

V-cycle Revised
Validation

System
Analysis &
Design

De

Formal V&V

ve
n
me
lop

HW / SW
Components
Design

Formal V&V

Validation

Validation

System
Integration &
Test

Module
Integration &
Test

ng

Formal V&V

System
Acceptance

Te
sti

Requirements
Analysis

HW / SW
Implementation &
Unit Test

Formal V&V

Software Engineering Case Study

18

Formal Methods
Overview
"

Characteristics:
Formal Notation + Tools =>
Exhaustive analysis
Intensive Simulation
Intermediate effects:
Early validation: requirements and design are validated and debugged
early in the development cycle (when bug fixing is less costly)
Better quality of documents/prototypes => fewer ambiguities, better
communication among the project team
Reduced manual validation phases
Final effects:
Higher quality standards, higher reliability, higher maintainability
Shortened time- to- market
"

"

"

"

"

"

"

"

"

"

Software Engineering Case Study

19

Formal Methods
Risks
"

"

"

"

"

Can be costly
Can be ineffective (too difficult, application to irrelevant domains)
Can be difficult to introduce
Require training (industrial partner)
Require domain knowledge transferral (formal methods expert)

and their mitigation

"

Our solution to the issues above is to adopt a lightweight approach:

application of FMs to the critical parts only
use of standard technologies
in- house tool support and development (NuSMV in our case)
"

"

"

Software Engineering Case Study

20

NuSMV Model Checker

"

"

Joint project between Carnegie Mellon University and IRST

Re-engineering, re-implementation, and extension of CMU SMV
(first symbolic model checker)

"

Platform for technology transfer of formal methods

"

Ongoing development (NuSMV2, gui, )

"

Open source

"

Freely available (http://nusmv.itc.it)

Software Engineering Case Study

21

NuSMV
"

Tool based on deductive techniques for design verification

"

"

"

Design as Finite State Transition System

Properties as set of admissible behaviours
Verification as exhaustive state space search

Software Engineering Case Study

22

Case Study
Tank Controller (TC)
"

A simple system but:

suitable to demonstrate V-cycle process
close to real systems addressed with formal methods
"

"

"

In particular, abstraction of a IRST technology transfer project,

covered by a non-disclosure agreement, involving:
safety critical issues
high functional complexity
difficult transmission of domain knowledge
product customisation
time-to-market constraints
"

"

"

"

"

"

NuSMV implementation
Software Engineering Case Study

23

TC The System

Level_Too_High
Level_High
Level_Middle
Level_Low
Level_Too_Low

Software Engineering Case Study

24

TC Description
"

The system comprises both SW (controller) and HW (the controlled environment).

"

The tank has inflow from an infinite source and outflow to an end user.

"

The controller tries to:

satisfy requests from the end user
keep level in the Level Middle area
by regulating the flow through the valves.
"

"

"

"

Valves are used in case of high level alarms (the water is in the "Level Too High"
portion of the tank for three times in a row) and low level alarms (the water is the
"Level Too Low" portion of the tank for three times in a row).
The tank is subdivided into areas that are used by the the controller to differentiate
its policy.

Software Engineering Case Study

25

TC Implementation
STEP 1 - Requirements Analyses
We define the System Requirements, i.e. those desired properties that our
system must satisfy
We express such properties both in natural language and using a formal
language (CTL/LTL are the logic formalisms used by NuSMV).
"

"

REQ1. The level always tends to the central portion of the tank
AF ( (Tank.Level < DECREASE_FLOW_IN_LEVEL) &
(Tank.Level > INCREASE_FLOW_IN_LEVEL) )
Always Finally the level of the tank is less than
DECREASE_FLOW_IN_LEVEL and is greater than DECREASE_FLOW_IN_LEVEL

REQ2. The tank never gets empty

AG ( Tank.Level > 0 )
Always Globally the level of the tank is greater than 0

REQ3. The controller never sends a low level alarm

AG

( ! Ctrl.Alarm_low_level )

Always Globally no low level alarm is raised by the controller

Software Engineering Case Study

26

TC Implementation
STEP 2 System Analysis and Design
"

"

"

We represent the architecture of

the system, taking into account
only the basic relationships
between the physical components
of the environment

We formalize this representation into

a NuSMV model
NuSMV model = Finite State
Machine (FSM)

MODULE main
VAR
V_in : valve_type;
V_out : valve_type;
P_in : pump_type(V_in.Status);
P_out : pump_type(V_out.Status);
Tank : tank_type(P_in.Flow, P_out.Flow);

Software Engineering Case Study

27

TC Implementation
STEP 3 RequirementsVerification

(STEP1)
Requirement
FSM

NuSMV

Yes

Counterexample

(STEP2)

Software Engineering Case Study

28

TC Implementation
STEP 4 HW/SW Components Design
"

"

"

We refine the design of the

system, taking into account the
HW/SW components and their
internal behaviour

We formalize this
representation into a NuSMV
model
NuSMV model = Finite State
Machine (FSM)

MODULE controller_type (UserReq, Level)

VAR
Status : {up, down};

ASSIGN
init(Status) :=
case
Level_Low | Level_Too_Low : up;
1 : down;
esac;
next(Status) :=
case
(Status = up) & (Level > DECREASE_FLOW_IN_LEVEL)
: down;
(Status = down) & (Level < INCREASE_FLOW_IN_LEVEL) : up;
1 : Status;
esac;

Software Engineering Case Study

29

TC Implementation
STEP 5 RequirementsVerification

NuSMV demo

Software Engineering Case Study

30

TC - V-cycle Perspective
STEP 1

Validation

Requirements
Analysis

System
Acceptance

STEP 2
System
Analysis &
Design

Validation

System
Integration &
Test

STEP 4

n
me
lop
t

STEP 5

Validation

Module
Integration &
Test

ng

ve

HW / SW
Components
Design

Te
sti

De

STEP 3

HW / SW
Implementation &
Unit Test

Formal V&V

Software Engineering Case Study

31

Conclusions
The V-cycle development process together
with the Formal Methods
addresses the problems
of modern, increasingly complex,
SW applications.

Software Engineering Case Study

32

Future
Next Step
"

"

"

Tighter integration between formal system modeling and

safety analysis.
Research studies and projects about early co-operation
between the different actors of the development process
(design engineers, mechanical/electrical/... engineers, test
engineers, safety engineers, ...)
Current EU-funded project at IRST: ESACS (Enhanced Safety
Assessment for Complex System) and its continuation ISAAC
(Improvement of Safety Activities on Aeronautical Complex
Systems) starting in 2004
Software Engineering Case Study

33