*-aware Software
for
Cyber Physical Systems
John A. Stankovic
BP America Professor
University of Virginia
Feb 3, 2012
What is a CPS?
• Isn’t is just an embedded system?
• Not the main question
• Simply parsing “CPS” -> Many systems
are CPS, but that is not the issue
• REALLY INTERESTED IN
– New research needed for the next
generation of physical-cyber systems
Confluence of Key Areas
Cost
Form Factor
Severe Constraints
Small Scale
Closed
Embedded
Systems
Scheduling
Fault Tolerance
Wired networks
Level of
Uncertainty
Real-Time
Architecture
Principles
Wireless Sensor
Networks
Noisy C.
Sensing
Scale
Real-Time/Actuation
Open
Control
Linear
Adaptive
Distributed
Decentralized
Open
Human Models
What’s New
• Openness
• Scale
– World covered by trillions of sensors
• Systems of systems
• Confluence of physical, wireless and
computing
• Human (in the loop) Participation
Theme
• How can we build practical cyber
physical systems of the future?
• 3 Critical (Foundational) Issues: must
be addressed together
– Robustness
– Real-Time
– Openness
Foundational Principle
• Scientific and systematic approach for
the impact of the physical on the cyber
• Propose:
– Physically-aware SW
– Validate-aware SW
– Privacy/security aware SW
Real-time
aware SW
“Open” Smart Living Space
Eavesdrop
Building HVAC
Openness
• Typical embedded systems closed
systems design not applicable
•
•
•
•
Added value
Systems interact with other systems
Evolve over long time
Physical system itself changes
• High levels of uncertainty: Guarantees
Computing in Physical Systems
Road and Street
Networks
Environmental
Networks
Industrial
Open,
BattlefieldHeterogeneousNetworks
Networks
Wireless Networks with
Sensors and Actuators
Building
Vehicle
Networks
Body
Networks
Networks
Outline
• Physically-aware software
• Validate-aware software
• Real-Time-aware software
• Privacy-aware software
Physically Aware: Impact of the
Physical
• For Wireless Communications (things we know)
–
–
–
–
–
–
–
–
–
–
–
Noise
Bursts
Fading
Multi-path
Location (on ground)
Interference
Orientation of Antennas
Weather
Obstacles
Energy
Node failures
Asymmetry
Irregular Range
of A
C
beacon
beacon
A
data
X
B
data
beacon
D
data
A and B are
asymmetric
B, C, and D are the same distance from A.
Note that this pattern changes over time.
Routing
• DSR, LAR:
– Path-Reversal
technique
RREQ
RREQ
RREP
X
A
Source
RREP
B
Impact on Path-Reversal Technique
Dest.
Uncertainties -Voids
Destination
Left Hand Rule
Physically-aware SW
VOID
Source
Cyber-Physical Dependencies
• Sensing
– Sensor properties
– Target Properties
– Environmental interference
Energy Efficient Surveillance System
1. An unmanned plane (UAV) deploys motes
Zzz...
Sentry
3.Sensor network detects
vehicles and wakes up
the sensor nodes
2.
Motes establish an sensor network
with power management
Tracking
– Magnetic sensor takes 35 ms to stabilize
• affects real-time analysis
• affects sleep/wakeup logic
– Target itself might block messages needed
for fusion algorithms
• Tank blocks messages
Environmental
Abstraction Layer (EAL)
Wireless Communication
Interference
Burst
Losses
Weak
Links
Sensing and Actuation
Fading
…
Target
Properties
Weather
Obstacles
Wake
Up Delays
…
Not HW-SW co-design, but rather Cyber-Physical co-design
Open Q: Environment
• How to model
• How to know we have all the issues
covered
• Design Tools
Impact of the Physical on the Cyber
Open Q: Correctness
• What does correctness mean in an open
system
Formal Methods
Don’t Address
Validate Aware: Run Time Assurance
(RTA)
•
•
•
•
Safety Critical
Long Lived
Validated
Re-validated
• Dynamics of
Environmental
Changes Influence
Correctness
See Run Time Assurance paper in IPSN 2010.
RTA Goals
• Validate and Re-validate that system is
still operational (at semantics level)
• Anticipatory RTA
– Before problems arise
• Robust to evolutionary changes
Validate-aware software
RTA Solution
• Emulate sensor readings
• Reduce tests to focus on key
functionality
• Overlap tests and system operation
• Evolve required tests
Current Solutions
• Prior deployment analysis
– Testing
– Debugging
• Post mortem analysis
– Debugging
• Monitoring low-level components of the system
– System health monitoring
Necessary, but not sufficient
RTA
• Formally specify application level
semantics (of correctness)
• Ability to demonstrate that
correctness over time
RTA Framework
Formal
application model
RTA test
specifications
Inputs
Network
database
RTA framework
Code
generation
Test
generation
Test execution
support
Model-based Specification
Sensor Network Event Description Language (SNEDL)
Smoke
>x
Smoke
alarm
S1
Fire
Temperature
S2
> 30°C
Temp.
alarm
>80°C
Test Specification
//Declare the basic elements of the language
Time T1;
Region R1, R2;
Event FireEvent;
//Define the elements (time and place)
T1=07:00:00, */1/2010; //first day of month
R1={Room1};
R2={Room2};
FireEvent = Fire @ T1;
Token Flow
Smoke
>x
Smoke
alarm
S1
Fire
Temperature
S2
>30°C
Temp.
alarm
>80°C
Code Generation
• Code is automatically generated from the
formal model
• Advantages of the token – flow model:
– efficiently supports self-testing at run time
– it is easy to monitor execution states and collect
running traces
– we can easily distinguish between real and test
events
Validate-aware SW
• High level spec on “function”
• Runtime SW that targets
demonstrating “validation”
• SW design for ease of validation
• Framework – to load, run, display tests
• System: Aware of validation mode
Open Q: Run Time Assurance
• Open system evolves
• Validate and re-validate (more than
monitoring)
– Limit number of tests
• Level of detail
Safety Analysis
Real-Time Aware
•
•
•
•
Hard deadlines
Hard deadlines and safety critical
Soft deadlines
Time based QoS
• Dynamically changing platform (HW and
SW)
Example: Group
Management (Tracking)
Base Station
Deadlines
• If we have enough late messages within
groups we can lose the track
– Not straightforward deadline
– Tied to redundancy, speed of target
• If messages don’t make it to base station in
hard deadline we miss activating “IR camera”
• If we don’t act by Deadline D truck carrying
bomb explodes – safety critical
Real-Time Scheduling
Tasks
Deadlines
1
Schedulable
Yes
2
Order
1,2,3
3
1
Algorithm
EDF
2
3
How robust?
CF=1
TIME
Robust RT Scheduling
For Real World CPS
Tasks
Deadlines
1
2
Schedulable
Yes
(1.8)
Order
1,2,3
3
1
Algorithm
EDF
2
3
How robust?
1.8 CF
TIME
Real-Time Technology
• Three possible approaches
– Velocity Monotonic
– Exact Characterization
– SW-based Control Theory
Feedback Control
• Front-End
– feedback loops
based on real world
control
– generate timing
requirements/rates
– generally fixed
– handed to
scheduling algorithm
P1
P2
P3
S
c
h
e
d
u
l
i
n
g
P4
A
l
g
FC-EDF Scheduling
Completed Tasks
MissRatios
MissRatio(t)
EDF
Scheduler
i
PID Controller CPU
CPU
Service Level
Controller
Accepted Tasks
CPUo
FC-EDF
Real-Time aware SW
Admission
Controller
Submitted Tasks
Open Q: Control
• With humans in the loop
– New system models
• Robustness (and Sensitivity Analysis)
• New on-line system ID techniques
Interacting (dependency among) Control Loops
Privacy-aware: Fingerprint And
Timing-based Snoop attack
Adversary
Bedroom #2
Fingerprint and Timestamp
Snooping Device
Kitchen
Timestamps
Bathroom
Living Room
Bedroom #1
Fingerprints
Locations and
Sensor Types
T1
?
T2
?
T3
?
…
…
…
Front Door
V. Srinivasan, J. Stankovic, K. Whitehouse, Protecting Your Daily In-Home
Activity Information fron a Wireless Snooping Attack, Ubicomp, 2007.
Performance
• 8 homes - different floor plans
– Each home had 12 to 22 sensors
• 1 week deployments
• 1, 2, 3 person homes
• Violate Privacy - Techniques Created
– 80-95% accuracy of AR via 4 Tier Inference
• FATS solutions
– Reduces accuracy of AR to 0-15%
ADL
• ADLs inferred:
– Sleeping, Home Occupancy
– Bathroom and Kitchen Visits
– Bathroom Activities: Showering,
Toileting, Washing
– Kitchen Activities: Cooking
Adversary
• High level medical information
inference possible
Fingerprint and Timestamp
Snooping Device
Timestamps
• HIPAA requires healthcare
providers to protect this
information
Fingerprints
Locations and
Sensor Types
T1
?
T2
?
T3
?
…
…
…
Solutions
•
•
•
•
Periodic
Delay messages
Add extra cloaking messages
Eliminate electronic fingerprint
– Potentiometer
• Etc.
Privacy-aware software
Open Q: Privacy
• Eavesdropping
• Access to information (in DB)
• Power of inference over time
Opt-in Strategies
Public Places
Summary
• Robustness – to deal with uncertainties: (major
environment and system evolution)
• Real-Time – for dynamic and open systems
• Openness – great value, but difficult
•
•
•
•
Physically-aware
Validate-aware
Real-Time-aware
Privacy/security-aware
*aware
CPS-aware
• Diversity – coverage of assumptions
• EAL