This document describes modeling and verification of cyber-physical systems using two case studies. The first case study models urban flood management using a hybrid automaton approach. Sites in a city are represented as vertices in a graph, with water channels and floodgates between sites. The water levels and operations of floodgates over time are modeled as a hybrid automaton. The second case study models occupancy in a multi-room building, with people arriving and moving between rooms probabilistically based on time of day. Both occupancy levels over time and metrics like peak occupancy are modeled stochastically. Future work aims to generalize these models and integrate modeling and experimental data.
4. Model Based Design for CPS
• Model the system using precise semantics
• Formally specify requirements expected of the system
• (Automatically) verify if the system meets the requirements
Why take the pain?
• Advantages: Vital for safety critical systems, Early detection of
errors; better understanding of the system leading to better
design
4
5. Characteristics of CPS
• Have a discrete component, typically the control logic and
computation
• Have a continuous component, typically the controlled
environment
• Infinite Execution
• Several Concurrent Processes with networked communication
Strikingly similar to Hybrid Systems!
5
7. Hybrid Automata: A Quick and Dirty Introduction
• L: Finite ordered set L = {l1 . . . ln } of real valued variables;
˙
also L
• G: Control multigraph G(V, E); V finite, called modes and E
called control switches
• Init(v): specifies for each v the values that L can take initially
• Inv(v): specifies for each v the values that variables in L must
necessarily have
7
8. Hybrid Automata (contd)
• F low(v): specifies for each v the allowable rates of change of
variables from L
• jump(e): specifies for each e ∈ E , potential source and
target values each li can take
• Events: A finite set Σ of events, with an edge labeling function
event : E → Σ.
8
10. Requirements
Examples:
• Safety: Something bad never happens
• Liveness: Something good eventually happens
• Duration: Something happens only for a fraction of the time
Can be specified in Integrator Computation Tree Logic
10
11. Automatic Verification
• Verify the formally defined system against the formally specified
requirements
• Symbolic Model Checking
• Symbolic Model Checker for “Linear” Hybrid Automata: HyTech
11
12. Case Study 1: Urban Flood Management
n sites in a city with
• Water channels between (some of) the sites; some site(s) drain
water out of the system
• Floodgates that open into the water channels along with
actuators to operate them
• Sensors that detect (i) the present water level and (ii) the rate of
increase of the water level
• A central control room that obtains the sensor data and decides
how to operate the floodgates
We need to know how to operate the floodgates to prevent flooding
12
13. Examples: Tokyo Flood Management System G-CAN
Tokyo Flood Management System
Source: Internet
13
14. “Graph”ically
• n sites represented by the vertices of a directed acyclic graph
• Lower and Upper limits (li and ui ) of water level Li for every
site i
• If there exists a water channel from site i to j , there is a directed
edge (i, j) in the directed graph and a floodgate gij at i
• A delay associated with each gate
14
15. The problem
• A Floodgate Configuration: A bit string B with one bit for each
floodgate that can take values “C” or “O” as follows: “C” if the
corresponding floodgate is open and “O” otherwise.‘
• A strategy: A transition function that takes as input the current
floodgate configuration, sensor data and outputs the next
configuration.
Problem: Figure out if a given strategy for floodgate management is
“safe”: i.e., the water levels always remain within safe limits at all
sites.
15
16. The Hybrid Automaton
Two types of discrete locations: One type for configurations and one
type for delays.
For a given configuration C:
• Invariants: li ≤ L ≤ ui ∀i
• Flow Conditions: dLi /dt = ri + i gij − j gij
• Jump conditions: depends on strategy!
For locations corresponding to delay, there is a clock variable:
• Invariants: clock should not exceed 2 units
• Flow conditions: the clock variable rises with slope 1
16
17. An Example Mode
Two sites, site 2 drains into river
• Label: OC
• Flow Conditions:
˙
– L1 = R1 − I12
– ˙
L2 = R2 + I12
• Invariants:
– l1 ≤ L1 ≤ u1
– l2 ≤ L2 ≤ u2
– Example Jump Conditions:
– If L1 falls below 5, goto Label “delayCC”
17
18. – If L2 rises above 10, goto Label “delayOO”
• Label: delayOC
– Flow Conditions: same as OC and clock variable starts
– Invariants: clock variable has value less than T seconds
– Jump Condition: When the clock variable equals T , goto
Label “CC”
Safety requirement: The water levels are safe at all sites in the
city
18
19. The Architecture of the Tool
HyTech
Strategy as Feedback
HyTech File
Floodgate Management
System
Current Water Levels, Actuator Commands
Current Rate of Rise for Opening/Closing
Sensor Network Floodgates
19
20. Ongoing Work
• One HA for each site, compose using synchronization labels.
Saves state space! Easier to handle!
Future Directions
• General city topology (i.e. DAGs that are not line graphs)
• Synthesis of the necessary and sufficient conditions for safety:
Parametric Analysis
20
22. Why?!
• Energy expenditure and appliance requirement of a building is
proportional to ocupancy.
• Need to justify deployment of smart energy management
systems. (akin to safety!)
• To estimate the number and capacity of environment/lighting
control appliances
22
23. Typical questions
• For what fraction of time would the occupation of a room be
– ≤ (say) 20%?
– ≥ (say) 80%?
• What is the peak occupancy?
• Etc.
23
24. Existing work
• Has attracted a lot of interest in recent times
• Single rooms [WFR05]
• Household occupancy [RTI08]
• Agent based modeling [JRMS08]
• Agent based + graphical models [LB10]
• Specific cases and/or complex approaches! Scope for
generalization and simplification!
24
25. Stochastic Modeling of Building Occupancy
• A building consists of some (say three) rooms interconnected by
corridors
• People arrive at a building in a Poisson fashion at a rate that
depends on time of the day (TOD).
• Each person goes to one of the rooms according to a
distribution that again depends on TOD.
• People exit each room according to an exponential distribution
with rate that depends on TOD.
• Each person that exits has a destination according to some
probability distribution.
• All parameters to be learned from real data.
25
26. Building topology
µ 1( t)
1
p (t)
o1
2 µ 2( t)
λ (t) p
o2
(t)
p (t)
o3
3
µ 3( t)
26
27. Simulation parameters
Hours 1 2 3 4 5 6 7 8 9 10
λ 10 10 1 1 1 10 1 1 1 1
µ’s 0 1 1 1 20 1 1 1 10 10
Example exit distribution:
Out of Room 1, at lunch break and end of day: 0.95 go out, 0.2 and
0.3 to rooms 1 and 2
At all other times, 0.2 go out, 0.4 each to rooms 2 and 3.
• Each room maximum capacity assumed to be 150.
27
28. Room 1 population plot
100
80
60
population
40
20
0
0 10 20 30 40 50 60
time
28
29. Room 2 population plot
100
80
60
population
40
20
0
0 10 20 30 40 50 60
time
29
30. Room 3 population plot
25
20
population
15
10
5
0
0 10 20 30 40 50 60
time
30
31. One room building
80
60
population
40
20
0
0 10 20 30 40 50 60
time
31
33. Future Work
• Generalize the model including, e.g., corridor delays
• Learn/correlate with experiments ongoing at IITH
• A tool for building occupancy, incorporating various models
• Can be used for the new IITH campus?
33
