Why Can

1
Why Cant I change the traffic lights with my
iPhoneyet? OrReality Checkpoint Ahead

• Jon Crowcroft, University of Cambridge
• Jon.Crowcroft_at_cl.cam.ac.uk
• http//www.cl.cam.ac.uk/jac22

2
Reality Checkpoint
Reality Rears its Ugly Head

• Reality - love it or loathe it, you cant ignore
  it
• In this talk
• I want to bring a sense of realism
• To discussions of pervasive services
• Get a sense of how far we have
• Yet to go
• Picture this -gt

3
Why Cant 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
• Youve 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
  pricingcongestion 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

4
Is the attention grabbing title just

• A gimmick?
• Not really
• illustrates 3 ideas which dont yet pervade our
  thinking
• Physics
• Psychology
• Systems

5
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/con
  gestive collapse)

6
Psychology

• Control traffic lights with my iPhone.
• Keyword is my
• What about you?
• Maybe you dont have an iPhone
• Maybe you think its unfair
• Maybe your battery is flat
• Or youve roamed somewhere and dont want to
  pay..
• Actually I dont even have an iphone - I have an
  HTC android phone -
• maybe the application hasnt been ported yet

7
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

8
Some mere engineering considerations

• Im 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

9
Sensor Net Energy

• Theres a lot of fancy work on self-organising
  nets and random duty cycling for mobile ad- hoc
  wireless sensors to extend battery life
• Most the WINES Projects are static
• Most the sensors monitor a well defined physical
  environment, which isnt 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.

10
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 -)

11
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)?

12
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 dont try to do distributed control
• except TCP in the Internetor 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.

13
Past, Present, Future

• Legacy is not the only problem
• People without smart deviceleft out
• Now consider we get rid of traffic lights
  (disintermediating DfT-)
• 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

14
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 4way intersect, or UK when traffic
  light systems fail
• what if one person only still thinks their iPhone
  is paying the others)

15
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 Ive
  given examples that show it may in fact reduce
  resource needs too

16
Conclusion Embeddings

• A system has to embed (at least) two models that
  might normally be merely implicit
• A model of the physical world (reality)
• A model of the human users (perceptioncognition)
• 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.

17
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.

18
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 CambridgeUCL
• LEO
• Whoever put sign on Parkers Piece.
• http//en.wikipedia.org/wiki/Reality_Checkpoint