Verifying Behavioral Component Interoperability Using PosNeg Scenarios

1
Verifying Behavioral Component Interoperability
Using Pos/Neg Scenarios
Weimin Ma Lawrence Chung Kendra Cooper
Department of computer Science The University of
Texas at Dallas
IWSSA07, Las Vegas, U.S.A.
2
Considering A Traffic Control System Goal Safety
of Intersection
The safety of an intersection involves the safety
of cars and the safety of pedestrians. A traffic
control system will help both of these.
Walk Button
Traffic Light
Pedestrian Signal Light
Properties of the Traffic Control System
3
How to Build A Traffic Control System Using
Components?
The safety of an intersection involves the safety
of cars and the safety of pedestrians. A traffic
control system will help both of these.
Component-Aware System Architecting IWSSA06
Controlled Devices
Traffic Control System
Monitored Device
Press to walk Change to green Proceed Blink
pedestrian signal End blink
Pedestrian Light Controller
Pedestrian Signal Light
Central Controller
Change to green Turn off traffic light Apply to
walk Walk Blink pedestrian Stop blink Change to
red
Traffic Light Controller
Turn green Turn yellow Turn red
Walk Button
Traffic Light
Structural mismatch Interface operation name
Properties of the Traffic Control System
4
Component Interoperability (Possibility With
Adapters)
Traffic Control System
Functional Interoperability Structural Mismatch
Interface attribute (name, type)
Interface operation (name,
parameter list) Solution for Structural Mismatch
Adapters
Functional Interoperability Structural Mismatch
Interface attribute (name, type)
Interface operation (name,
parameter list) Solution for Structural Mismatch
Adapters
Behavioral Interoperability Problem Structural
match ? behavioral match. Solution for
Behavioral Mismatch Adapters ?
Definition Behavioral Interoperability 1.
Call/message sequence 2. Proper Coordination 3.
Components interaction with respect to the
requirements
5
Problem and Proposed Solution

• Problem Assessing behavioral interoperability
  among components with/without using adapters
• Need notion of system/component interoperability
  at requirements level
• Need to be able to consider adapters
• Need to be able to ask what could go wrong
  questions
• Verification

• Solution
• State transition formalism for representing
  individual component behavior scenarios for
  component interactions at requirements level
• Positive scenarios and positive scenarios with
  negative traces lead to liveness and safety
  properties
• Model checking behavioral models (with pos/neg
  adapters) checked against liveness and safety
  properties

6
Models Satisfying Properties
RP To have a safe intersection, cars and
pedestrians shall not encounter at the
intersection.
RN To have a chaotic intersection, cars and
pedestrians shall encounter at the intersection.
sd
m0
sd
SDP
SDN
m0
neg
m1
m3
m2
SDP m0 m3
m3
SDN m0 m1 m2 m3
SP
S0
S2
SN
m0
S3
m3
S0
S1
S2
m0
m1
m3
m2
S1
S4
PRP Liveness
PRP It is always the case that if walk button
is pressed then the pedestrian signal light
eventually becomes walk.
PRN (False delaying) the traffic light is green
and the walk button is pressed, but the
pedestrian cannot proceed.
PRN Safety
7
A Positive Set of InteractionsWith Negative
Traces
sd Traffic Control System
Controller
Pedestrian Signal
Traffic Light
Adapter
Change to green
Change to green
Walk Button
Turn green
Press to walk
Press to walk
Apply to walk
Walk
Proceed
Blink pedestrian
Blink pedestrian signal
Stop blinking
End blinking
Turn off traffic light
Turn yellow
Press to walk
neg
Press to walk
Apply to walk
Walk
Proceed
Change to red
Turn red
P
It is always the case that if the press button
is pressed then the pedestrian signal light
eventually becomes walk. AG ((PressButton
Pressed) -gt AF (PedestrianSignal Walk))
P
There exists the situation that in the same
direction, the traffic light is yellow and the
pedestrian signal light is walk. EG
((TrafficLight Yellow) ? (PedestrianSignal
Walk))
RP
RN
8
Model Checking
Model
SPIN Linear Temporal Logic (LTL) SMV Branching
Temporal Logic (BTL) UPPAAL, SCR LTL BTL
If M S Yes, properties hold If M ? S No,
properties violated Counter example
Model Checker (e.g. SMV, SPIN, UPPAAL, SCR,
etc.) Single M S ?
Kripke Structure
Specification
Liveness AG ((PressButton Pressed) -gt AF
(PedestrianSignal Walk))
With components MPC1 ? MPC2 S
Safety EG ((TrafficLight Yellow) ?
(PedestrianSignal Walk))
(MNC1 ? MPC2 ? S?, MPC1 ? MNC2 ? S?, MNC1 ?
MNC2 ? S?)
With adapters MPC1 ? MPC2 ? MPA S
(Properties) (Temporal Logic)
(MNC1 ? MPC2 ? MPA ? S?, MPC1 ? MNC2 ? MPA ?
S?, )
9
Illustration Traffic Control System (Components
Are Non-Interoperable Without Adapters)
The central controller and the traffic light
controller are interoperable with pos/neg
adapters (SP PRP, SP PRN, SN PRP, SN
PRN) (Components Initial states are
inconsistent )

• Case 1.1 (Pos Adapter) Synchronization (Adapter
  moves Traffic Light Controller forward to Red
  On state before central controller starts
  Change to green message, and moves traffic
  light controller forward to Green On state
  after central controller sends Change to red
  message.)
• Verification result of case 1.1
• Case 1.2 (Neg Adapter) Synchronization (when
  the traffic light is yellow/red and the walk
  button is pressed)
• Verification result of case 1.2 (The negative
  model shows fault tolerance)

10
Case 1.1 Initial States Are Inconsistent(Central
Controller, Positive Adapter and Traffic Light
Controller PRP, PRN)
1. RP To have a safe intersection, cars and
pedestrians shall not encounter at the
intersection.
Inconsistent Initial States
Adapter Inconsistent initial states synchronized
Proposed Solution
11
Verification Result of Case 1.1(Central
Controller, Positive Adapter and Traffic Light
Controller PRP, PRN)
3. UPPAAL Properties
1.
2. UPPAAL Model
v
v
4. Verification Result
12
Case 1.2 Initial States Are Inconsistent(Central
Controller, Negative Adapter and Traffic Light
Controller PRP, PRN)
1. RN To have a risky intersection, cars and
pedestrians shall encounter at the intersection.
Inconsistent Initial States
Adapter Inconsistent initial states synchronized
2. SDN (Sequence of positive interactions)

• Central controller changes the traffic light to
  yellow/red
• Pedestrian pressed the walk button, waiting for
  crossing
• Central controller receives the message
• Central controller sends a message to the
  pedestrian light to change it to walk

Adapter created following the negative scenarios
3. SN (Negative model)
Proposed Solution

• When the adapter in Yellow on state and the
  walk button is pressed, the adapter goes into the
  Walk button recorded state
• In red state, the adapter transitions to walk
  ready state when walk button recorded is true.

4. P
RN (Properties extracted from negative scenarios)
In the same direction, the traffic light is
red/yellow, the pedestrian light is walk. EF
((TrafficLight Red/Yellow) (PedestrianLight
Walk))
13
Verification Result of Case 1.2(Central
Controller, Negative Adapter and Traffic Light
Controller PRP, PRN)
3. UPPAAL Properties
1.
2. UPPAAL Model
4. Verification Result
v
v
The negative model shows fault tolerance, i.e.
the pedestrian signal controller is not in the
state to change to green.
14
Contributions and Future Work

• Contributions
• Components representing requirements level
  specification
• Safety and liveness derived from positive
  scenarios with negative traces
• Verification of pos/neg model from pos/neg
  scenarios when using adapters through model
  checking

• Future Work
• Classification of satisfaction of negative model
  on pos/neg properties
• Verification of non-functional interoperability
  using anti-goal or anti-model

15
QUESTIONS
16

• Appendix

17
Appendix I Case 2.1 Atomic Messages (Central
Controller, Positive Adapter and Pedestrian Light
Controller PRP, PRN)
Different Message Sequence
Adapter Concerning Atomic Messages
Central Controller
Pedestrian Signal Controller
loop
loop
Change to green

alt
critical
Apply to walk
Change to green
Walk
Press to walk
Blink pedestrian
End blinking
Proceed
Turn off traffic light
Blink pedestrian signal
Terminate
Stop blinking
Otherwise
Turn off traffic light
Atomic messages
Atomic messages
Terminate cycle
Non-atomic messages
Atomic messages require two messages occur
consecutively, no matter which comes first.
Adaptation non-interoperable with pos adapters
18
Verification Result of Case 2.1 (Central
Controller, Positive Adapter and Pedestrian Light
Controller PRP, PRN)
Different Message Sequence
SCR Model
1.
2.
SPIN Verification Result
4.
Properties in Temporal Logic
3.
EG ((TrafficLight Yellow) ? (PedestrianSignal
Walk)) AG ((PressButton Pressed) -gt AF
(PedestrianSignal Walk))
Properties in SCR
X
v
19
Appendix II Case 2.2 Atomic Messages (Central
Controller, Negative Adapter and Pedestrian Light
Controller PRP, PRN)
1. RN To have a risky intersection, cars and
pedestrians shall encounter at the intersection.
Different Message Sequence
2. SDN (Sequence of positive scenario with
negative traces)

• Central controller changes the traffic light and
  the pedestrian light to green
• Central controller changes the traffic light to
  yellow
• Central controller changes the traffic light to
  red
• Pedestrian pressed the walk button, waiting for
  crossing
• Central controller receives the message
• Central controller sends a message to the
  pedestrian light to change to walk
• Central controller blinks the pedestrian light
• Central controller stops the blinking of the
  pedestrian light

3. SN (Negative model)
4. P
RN (Properties extracted from negative scenarios)
In the same direction, the traffic light is
red/yellow, the pedestrian light is walk. EG
((TrafficLight Red/Yellow) (PedestrianLight
Walk))
Properties from negative scenarios become Safety.
20
Verification Result of Case 2.2 (Central
Controller, Positive Adapter and Pedestrian Light
Controller PRP, PRN)
3.
UPPAAL Model
1.
Positive Scenario with neg Traces
Adapter built from Scenario with neg Traces
2.

• Realization of Neg Traces
• Adapter records the button pressed event when
  traffic light is red
• Adapter issues the button pressed event when
  traffic light is green

v
v
21
Appendix III Goal Decomposition(Safety of
Intersection)
Safety of Intersection
Safety of Pedestrian
Safety of Car




Traffic Light Control System (TLCS)
Access to Pedestrian System
Driver Following Traffic Light
22
Appendix IV Background
Four-Variable Model
Req
m
c
NAT(m, c) ? IN(m, i) ? SOFT(i, o) ? OUT(o, c) ?
REQ(m, c)
IN
OUT
i
o
SOFT
Reference Model
P
W
W, R eh, ev, sv S ev, sh
eh
S
sh
R
M
KAOS
S, D, Ac R where S, D, Ac ? false D, R, AS
G where D, R, AS ? false
Safety of Intersection
Safety of Car
Safety of Pedestrian
Ac Accuracy AS Expectation
Car speed max 40 mph
Traffic Light
Accessible of pedestrian button

23
Appendix V Proposal of Neg Model
Proposed Approach
General Approach
Proposed Approach General approach
General Approach
Negative Goal
Positive Goal
Positive Requirements
Negative Requirements
Or higher level
Positive Specification
Negative Specification
Verification performed on this level
Positive Model
Negative Model