Why Can’t I change the traffic
lights with my iPhone…yet?
Or
Reality Checkpoint Ahead
Jon Crowcroft, University of
Cambridge
Jon.Crowcroft@cl.cam.ac.uk
http://www.cl.cam.ac.uk/~jac22
Reality Checkpoint
Reality Rears it’s Ugly Head
 Reality - love it or loathe it, you can’t ignore
it
 In this talk:
I wan’t to bring a sense of realism
To discussions of pervasive services
Get a sense of how far we have
Yet to go
Picture this ->
“Why Can’t I change the traffic
lights with my iPhone”, expanded





You are at the lights and about to be late for
a very important key note
You’ve heard that people use smart phones to
control TVs and to pay for things
What if you could pay to get priority service?
- perhaps you would pay other drivers/cyclists
to sit at red for longer (cf. shadow
pricing==congestion charge)
So you can get to your important meeting
soonest (or get out of bed later:)
You write an app to control traffic lights and
start looking for VC…
Is the attention grabbing title just



A gimmick?
Not really
illustrates 3 ideas which don’t yet
pervade our thinking:



Physics
Psychology
Systems
Physics


Control traffic lights with my iPhone.
Key word is : Control


Has an impact on real world (actuator)
current pervasive services just sensors



Effect is indirect (human in loop)
All sorts of error checking (comparison with
other data sources)
All sorts of built in delays (no fast feedback
loop - no black Monday/flash
crowd/oscillation/congestive collapse)
Psychology


Control traffic lights with my iPhone.
Keyword is: my







What about you?
Maybe you don’t have an iPhone
Maybe you think its unfair
Maybe your battery is flat
Or you’ve roamed somewhere and don’t want to
pay..
Actually I don’t even have an iphone - I have an
HTC android phone maybe the application hasn’t been ported yet…
Systems


Control traffic lights with my iPhone.
Keyword is: traffic



Traffic constitutes a system which is
complex lights are just one part of it
If we make very local dynamic decisions, we
may disrupt careful controls (yes, really
they are there:) designed by road traffic
planners…
Some mere engineering
considerations



I’m going to detour to look at pure sensor
systems for a bit coz we have a lot of
experience in those now
UK WINES Programme has many projects
building smart sensor nets
Lets look at two aspects of these



Energy sources
Combatting errors
The purpose of the detour is to show how
even simple systems need some higher level
considerations
Sensor Net Energy

There’s a lot of fancy work on self-organising
nets and random duty cycling for mobile adhoc wireless sensors to extend battery life





Most the WINES Projects are static
Most the sensors monitor a well defined physical
environment, which isn’t even very dynamic
Often, the environment contains moving air (wind
farm) water (sewer) or power (metro rail)
Most amusingly, nottingham folks noticed that
monitored cattle can quite easily carry a 10kg
battery….
Oh, and more than half the environments have
cellular coverage….
Sensor system consistency



If you have more than 1 sensor in a system,
one assumes they are monitoring a property
over some area/volume (temperature,
humidity, sound level)
This property has certain physical constraints
(heat and sound propagate at a certain
maximum rate) which lead to sanity checks on
the d/dt of that property over x,y,z…
This may be more easy to check than running
a Byzantine Fault Tolerance algorithm :-)
Control Systems and no surprises

We have a couple of hundred years
experience of control systems




Feedback controllers (“regulators”) in steam trains
etc
The human race has sort of gotten used to these
just about, and this is good since we rely on them they contain few surprises
Aircraft use 3-fold redundant, heterogeneous
systems - even when they go wrong, manual backup
works quite well
So what can we learn from these (that sadly
economists fail to have grasped)?
No surprise principle part b

They are largely local-operation only




set-point controllers may distribute the setpoint
from time to time e.g. traffic light rate, and do clock synch, but we
don’t try to do distributed control
except TCP in the Internet…or “lightly”
regulated financial service industry
There, you can still get a flash mob when you
combine a set of locally controlled systems in
a distributed environment.

Flashmobs of iphone-0wning impatient SUV drivers
late for the school drop would lead to, (yes, you
got it), a run on the price for a greenlight.
Past, Present, Future

Legacy is not the only problem


Now consider we get rid of traffic
lights (disintermediating DfT:-)




People without smart device…left out
Your iPhone is part of a mobile social net
Or its just part of your satnav
Implements traffic norms as well as local
preference/price…
Now add robot cars
So we need to embed


We need to embed a model of the physical
environment, which includes propagation delay
of physical effects and policy/control for
feedback (both local and collective) to
actuators
We need to embed a model of human
expectation given current perceived (and
understood) state of the real world
environment, including apparent state other
humans


(think US 4=way intersect, or UK when traffic
light systems fail…
what if one person only still thinks their iPhone is
Appropriate Phase for Embedding

Clear some designers already do this at design
time.


Often, a pervasive service has a design team
including other groups who convey this in
requirements (implicitly or explicitly)
Its clear to me that sometimes at least the
system needs to capture the embedded
knowledge at runtime too.

This may be resource intensive, but I hope I’ve
given examples that show it may in fact reduce
resource needs too
Conclusion: Embeddings
A system has to embed (at least) two
models that might normally be merely
implicit

1.
2.
A model of the physical world (reality)
A model of the human users
(perception&cognition)
These embeddings are not just design time
it may be necessary to execute them at run
time -




Continuously to verify the system view and
Continually re-calibrate it against reality and use.
Take home messages



Its easy to be a geeky creator
Its hard to avoid major pitfalls that
have little to do with mainstream
Computer Science/Engineering
Embedding these other modes of
thinking in our tools and techniques is
not optional.
Acknowledgements





EPSRC & BCS for UK Grand Challenge in
Ubicomp support (ideas from Tom
Rodden, Robin Milner, et al)
EPSRC for Horizon Digital Econony Hub
Colleagues in Cambridge&UCL
LEO
Whoever put sign on Parker’s Piece.
http://en.wikipedia.org/wiki/Reality_Checkpoint