Modeling and Verification of Cyber PhysicalSystems: Two Case Studies

M. V. Panduranga Rao

Indian Institute of Technology Hyderabad

1

Outline

• Model Based Design

• The Hybrid Automata Option for CPS

• A Case Study

• Stochastic Modeling

• A Case Study

2

Floodgate management

with Akhilesh Chaganti

3

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

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

Formal modeling

• Discrete systems: Finite Automata (and its cousins)

• Continuous systems: Differential Equations

• Hybrid systems? Combine both! Hybrid automata!

6

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

Hybrid Automata (contd)

• Flow(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

An Example

Source: Internet

• Possible to “compose” automata using “synchronization labels”

9

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

Automatic Verification

• Verify the formally defined system against the formally specified

requirements

• Symbolic Model Checking

• Symbolic Model Checker for “Linear” Hybrid Automata: HyTech

11

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

Examples: Tokyo Flood Management System G-CAN

Tokyo Flood Management System

Source: Internet

13

“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

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

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 +∑

igij −

∑jgij

• 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

An Example Mode

Two sites, site 2 drains into river

• Label: OC

• Flow Conditions:

– L̇1 = R1 − I12

– L̇2 = R2 + I12

• Invariants:

– l1 ≤ L1 ≤ u1

– l2 ≤ L2 ≤ u2

– Example Jump Conditions:

– If L1 falls below 5, goto Label “delayCC”

17

– 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

The Architecture of the Tool

Current Water Levels,Current Rate of Rise

Actuator Commandsfor Opening/Closing

Strategy as

Floodgate Management System

FeedbackHyTech File

Floodgates Sensor Network

HyTech

19

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

Building Occupancy Modeling

with Anmol Kohli

21

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

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

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

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

Building topology

o1p (t)

1µ ( t)

p (t)

p (t)

o2

o3

λ (t)µ ( t)

µ ( t)

2

3

1

2

3

26

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

Room 1 population plot

0 10 20 30 40 50 60

020

4060

8010

0

time

popu

latio

n

28

Room 2 population plot

0 10 20 30 40 50 60

020

4060

8010

0

time

popu

latio

n

29

Room 3 population plot

0 10 20 30 40 50 60

05

1015

2025

time

popu

latio

n

30

One room building

0 10 20 30 40 50 60

020

4060

80

time

popu

latio

n

31

Rajalakshmi et. al. @ IITH

32

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

Thanks, Questions?

34