Why Can’t I change the traffic lights with my iPhone…yet? Or Reality Checkpoint Ahead

Why Can’t I change the traffic lights with my iPhone…yet? OrReality 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 ad- hoc 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 • People without smart device…left 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

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 paying the others)

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

Why Can’t I change the traffic lights with my iPhone…yet? Or Reality Checkpoint Ahead