Fire! Requirements for reconfigurability.

1. Fire!Requirements for reconfigurability. Stephen Hailes Department of Computer Science, UCL Technical Manager, RUNES project s.hailes@cs.ucl.ac.uk http://www.ist-runes.org

2. Introduction Introduction Story Requirements Technology Future Conclusions • 1999 – The story of Mont Blanc • 2019 – SAFECOM requirements • Technology • Hardware • RUNES software systems – issues and challenges • The Future • Conclusions

3. Somewhere in the world… 1999

4. Mont Blanc Introduction Story Requirements Technology Future Conclusions • Wednesday morning, March 24, 1999, 10.46 AM • The Belgian Gilbert Degraves, 57, a truck driver for 25 years drives his Volvo FH12 tractor trailer and a refrigerated trailer loaded with 9 tons of margarine and 12 tons of flour for Italy past the toll at the French side. • Nothing abnormal was visible. • Ignition must have started about now..

5. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 10.52, presumed 6 minutes after ignition • First signs of smoke were noticed by oncoming trucks 2-3 km into the tunnel. • The obscuration detector in rest area #18 signals a strong air obscuration and sets off visual and audio alarms at the French control station. • This alarm also automatically switches monitors to that section. • The operator acknowledged the alarm and observed the cameras in #18, 16, 17 and 19. He saw the smoke on the truck.

6. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 10.53, 7 minutes a.i. • Oncoming cars flash their headlights at the driver. • He looks into his mirror, sees smoke and stops 6.7km in, area #21. • Flames burst out on both sides of the cab… “It exploded…” • Automatic video cameras detect cars turning in rest area 22 whose drivers probably saw the blaze. People on foot were also visible in that area.

7. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 10.54, 8 minutes a.i. • A phone call from area 22 is received at the Italian control room. • Smoke is detected on the video monitors between areas 16 and 21. • On the Italian side, trucks stop, drivers leave their cabs see a thick wall of black smoke under the ceiling. They all managed to escape on foot - the airflow blew smoke away from them. • On the French side and 2 truck drivers up front left their vehicles and run back towards the French entrance. • They died probably of toxic smoke 200 - 240m away. • Car drivers also tried to escape but they managed to make only 100 – 500m before dying. Most other drivers stayed in or near their vehicles. • 27 were found dead in the wrecks. • Lack of oxygen brings engines to a halt.

8. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 10.57, 11 minutes a.i. • The ATMB fire engine of the safety force drives into the tunnel from the French side. Aboard 4 firemen.

9. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 10.58, 12 minutes a.i. • The French Central Alarm Centre CTA in Annecy is alerted at 10:58:30 and forwards the alarm to the Main Rescue Centre in Chamonix. • CHRISTIAN COMTE, fire brigade chief, Chamonix: “On the day of the fire we are called for smoke in the tunnel, just one lorry, but nobody knows exactly what happened.” • 4 firemen from the French side are still 1km from the burning lorry. They report sudden heavy smoke decreasing visibility to 0 and cutting the engine. They get the order to take shelter in safety space #17 at 5.1 km.

10. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 11.01, 15 minutes a.i. • The lighting equipment was destroyed and fell out at 11.01. • The same for the sprinkler system on the French side and the exhaust dampers on the Italian side. • No redundant or failsafe systems were installed.

11. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 11.02, 16 minutes a.i. • The Courmayeur firefighters are alerted. At the same moment the first fire engine leaves its base at Chamonix. • The Italian fire detection system loses all transmission data from the acquisition cabinet in area #19.

12. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 11.04, 18 minutes a.i. • The first fire engine leaves its base at Courmayeur.

13. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 11.10, 24 minutes a.i. • The first firefighters from Chamonix arrive at the tunnel and immediately drive inside. Meanwhile short circuits cut more and more of the lighting system.

14. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 11.19, 33 minutes a.i. • Driving carefully in the dark tunnel, the Chamonix' firefighters get suddenly enclosed by thick smoke near the space #12 at 3.7 km (2.5 km before the burning truck) • After attempting to turn around the engine dies from lack of oxygen. • They abandon the engine and take cover in space #12 which had no sheltered room. 2 people without masks immediately suffer heavy smoke inhalation. • They triggered the alarm switch to get attention. The emergency phones were already out of order as the wiring had burnt and short circuited.

15. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 11.24, 38 minutes a.i. • The commander of the Chamonix' firefighters arrives and is informed of the situation. • Everything is very chaotic, nobody knows if and how many people are still inside. Survey cameras show nothing as black smoke if they work at all. No coordination is made with the Italian side's operators.

16. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 11.31, 45 minutes a.i. • An overview of who's where inside: • 6 Italian men trapped in shelter at #17, their engine burned out. • 6 French firefighters trapped in space #12 • 5 men near #5, 2 of them trapped in the sheltered room without oxygen masks. • 1 man missing with his motorcycle

17. Mont Blanc Introduction Story Requirements Technology Future Conclusions • 18.35, 7 hours 48 minutes a.i. • A French fire engine manages to save the 6 people in the sheltered room at #17, taking extremely high risks. • At this moment it was clear to everyone that nobody still inside could be alive. Source: http://www.landroverclub.net/Club/HTML/MontBlanc.htm

18. Somewhere in the world… Introduction Story Requirements Technology Future Conclusions 2019

19. What if… • Sensors, embedded systems are pervasive • Tunnel • Cars • People • They are networked • Firefighters can • Query status of the network in advance • Visualise the information • Change the environment – actuators • Communicate with victims

20. SAFECOM Introduction Story Requirements Technology Future Conclusions • SAFECOM is managed by the Department of Homeland Security (DHS) • Its mission is to help public safety agencies improve response through more effective and efficient interoperable wireless communications • Statement of Requirements – looking to 2019

21. SAFECOM requirements Introduction Story Requirements Technology Future Conclusions • Interactive data communications… accountability, text, image, video • Accountability. • Know where every firefighter is: • 3D location with high resolution • Know their health and condition: • biometrics such as heart rate, temperature, respiratory rate, and blood pressure • Know position and status of equipment: • vehicles, oxygen tank supply • The data must be continuously updated on the Incident Commander's GIS and the dispatcher's CAD displays to indicate the location and health of all firefighter assets. • This data must be current, accurate, time sensitive, and have a high priority.

22. SAFECOM requirements Introduction Story Requirements Technology Future Conclusions • Text • Access to current and archived computerized information, e.g., information about contents, uses, ownership of buildings; medical records of patients, etc., • Images • Maps and drawings of buildings, roads, utilities, hazardous locations, hydrants, and terrain. • Pictures (ground level and aerial) are useful for tactical firefighting decisions • Pictures of victims help remote doctors recommend best response. • Video • Video pictures sim. useful for firefighting response, to coordinate rescue efforts, to help distant medical personnel • Can also include specialized non-visual imaging to warn of spreading fire, chemical hazards, etc. • Robotics video is needed at the site to aid in controlling robots, but is also useful for tactical direction by the incident commander.

23. SAFECOM requirements Introduction Story Requirements Technology Future Conclusions • Vision is one in which • information is available from sensors spread throughout the environment • tied back to online resources • fed to firefighters using HUD • allowing commanders to visualise and control environment • securely, scaleably, fault tolerantly, …

24. SAFECOM requirements Introduction Story Requirements Technology Future Conclusions A variety of different communication paradigms are needed – real time, synchronous, asynchronous, DTN • The system must be capable of supporting a variety of passive/active sensors on the network that transmit data at periodic/non-periodic intervals. Information must be available on request or pushed to specified users for critical data. • The system must support the creation and implementation of automated communications triggers, e.g., if a bulletproof vest detects a bullet impact, it notifies the appropriate objects.

25. SAFECOM requirements Introduction Story Requirements Technology Future Conclusions Devices must be reconfigurable on different timescales – maintenance, upload of new components, dynamic adaptation to network conditions • Devices on the network must be reprogrammable over the air in a reasonable amount of time. Multiple device reprogramming can occur simultaneously. • Routine maintenance must be performed without any noticeable degradation on the system. • User configurations must be transferable between radios. • Devices must be capable of storing and maintaining configurations of user-selectable parameters.

26. SAFECOM requirements Introduction Story Requirements Technology Future Conclusions The system must work with and without infrastructure, but must have simple setup – automatic service discovery • The system must support the ability to drop in infrastructure and go operational with little to no configuration or setup. • The communication system must be able to scale in terms of coverage area in a very cost-efficient manner while still maintaining high availability and reliability, as well as vertical scalability. • If there is no infrastructure available, the communications objects that arrive on an incident must be capable of automatically setting up and configuring an ad hoc communications network.

27. SAFECOM requirements Introduction Story Requirements Technology Future Conclusions Failure tolerance is very important – diversity and autonomic response • The system architecture will be such that there are no single points of failure. • The system will be capable of detecting link/device failures and other network performance issues and reconfiguring communications paths to maintain performance. • Some form of self healing will be available in the network.

28. SAFECOM requirements Introduction Story Requirements Technology Future Conclusions There are many security requirements – focussed on authentication, encryption and resistance to DoS attacks of various types, including jamming and the ability to geolocate it.

29. Summary so far Introduction Story Requirements Technology Future Conclusions • To meet the requirements for firefighting in 2019, want systems capable of: • Dealing with heterogeneity in hardware, including various sensors, audio/video devices, robots, etc. • Dealing with different underlying comms paradigms • Dynamic reconfiguration/reprogramming - adaptation • Self configuration, service discovery, easy setup • Various NF requirements – fault tolerance, security • Visualisation

30. Somewhere in the world… Introduction Story Requirements Technology Future Conclusions The Technology

31. Networked Embedded Systems Introduction Story Requirements Technology Future Conclusions • Embedded systems are becoming increasingly networked • Controller-area-networks (CAN) bus in automobiles • Services in large buildings are now run across networks • e.g. heating, lighting, security

32. Internetworked Embedded Systems Introduction Story Requirements Technology Future Conclusions • Networks are becoming increasingly networkedandheterogeneous (inter-networked) Connect Blue Sensor Routing Node ARM7 – 32K RAM, 512K flash Lippert MoteMaster: PC/104 128M RAM, 256M flash

33. Embedded networks Introduction Story Requirements Technology Future Conclusions • …involve: • Many interacting nodes… • … of different types…. • … embedded in control systems without human intervention … • … for purposes other than general computing … • … used and interacted with by non-expert users [Source: Embedded, Everywhere, NRC]

34. Development challenges Introduction Story Requirements Technology Future Conclusions • Building scalable systems… • … tightly coupled to the real world…. • … in a resource-constrained environment … • … that will persist for a long time … • … and be predictable and manageable enough for naïve users … • … in a secure and energy efficient way

35. State of the Art (software) Introduction Story Requirements Technology Future Conclusions • Increasing prevalence of networked embedded systems • inherently heterogeneous and dynamic • So why do we not have heterogeneous, dynamic, large-scale systems applications already? • Interaction and scale too complex • Do not have necessary (software) infrastructure • The software fabric of such systemstends to be ad-hoc • little provision for generalisable and reusable abstractions and services: applications are bespoke and limited Need a genericprogramming platform • need abstractions and services that can span the full range of networked embedded systems • need consistent mechanisms for configuring, deploying, and reconfiguring systems • must be small, simple, efficient and highly tailorable

36. sira USA Australia

37. RUNES Vision Introduction Story Requirements Technology Future Conclusions • To enable the creation of large scale, widely distributed, heterogeneous networked embedded systems that inter-operate and adapt to their environments • By providing a standardised architecture capable of self-organisation to suit the environment

38. The RUNES programming model Introduction Story Requirements Technology Future Conclusions • A generic component-based programming model • Components allow for a unified way of accessing, configuring and reconfiguring the system • Encapsulation behind well-defined interfaces • Basis of dynamic adaptation & reconfiguration • Inspectable, adaptable and extensible at runtime • ‘low level’ and efficient; can employ different implementations on different hardware • Applied uniformly throughout the stack • network, OS, middleware, applications • all above uniformly realised as reconfigurable compositions of components

39. Component frameworks (CFs) Introduction Story Requirements Technology Future Conclusions • Re-usable, dynamically-deployable, software architectures • give structure, tailorability and constraint • built as compositions of components and/or other CFs • Provide “life support environments” for plug-in components in a particular area of concern • example: a protocol stacking CF that takes plug-in protocols • the caplet/ reflective extensions are themselves CFs • other examples follow… • Embody constraints on pluggability • example: disallow stacking of IP plug-in above TCP plug-in • constraint specification may be ad-hoc • or may employ generic constraint languages such as OCL (with automatically generated run-time machinery)

40. Summary of RUNES approach Introduction Story Requirements Technology Future Conclusions • Apply the “components everywhere” principle • optional extensions • caplets, loaders and binders • reflective extensions • Build systems from CFs • give structure, tailorability and constraint • optionally and dynamically (un)deployable • Deploy appropriate CFs and plug-ins • network, interaction, distributed reconfiguration, location, advertising/discovery, coordination

41. All life on earth is insects Introduction Story Requirements Technology Future Conclusions 90% of microprocessors are embedded Pentium has <2% of the market Annual shipments will pass 10 billion during 2007. Very few of these billions of micro-controllers are networked According to "Embedded Report: The Information Network," in 2005 there were 7.477 billion micro-controllers shipped worldwide.

42. ANOTHER BEER PLEASE HAL… I’M SORRY DAVE, I CAN’T DO THAT. THE BATHROOM SCALES AND THE HALL MIRROR ARE REPORTING DISTURBING FLAB ANOMALIES Introduction Story Requirements Technology Future Conclusions

43. The RUNES DVD Introduction Story Requirements Technology Future Conclusions Play

44. Conclusions Introduction Story Requirements Technology Future Conclusions • To reach the 2019 vision, we need to do the research now – collaboratively • Hardware is getting there • The killers are software • …and system management. • So, experiment with a generic middleware framework • Take care about security & other NF requirements • Build it, and test it

45. Questions? ? http://www.ist-runes.org s.hailes@cs.ucl.ac.uk

46. Challenges: Physical layer • Physical layer • Energy minimisation • Multihop effects – go long, or multiple short hops? • Software radio • Open research issues: • Modulation schemes (simple, low power) • Signal propagation effect minimisation (MIMO) • Hardware design (low cost, small) – integration with MEMS sensors • UWB • Hardening – temp cycles, humidity, etc. • Tamperproofing

47. Challenges: Network End of the E2E argument? • Heterogeneity – where’s the waist? • MAC protocols for mobile sensor nets • Particularly self organising ones for mobile sensors • Power efficiency • combination with sensing & interaction paradigms • adaptive power efficient source vs channel coding – signal processing • Addressing & routing • Explicit, data centric (attribute based), mesh networking, multihoming • Gatewaying and protocol translation • Transport layer protocol design • QoS • Adaptive clustering • Overlay networks • DTN NOT ALL IP

48. Challenges: Middleware • Highly heterogeneous environment • Some with potentially very scarce resources • => Can we devise a common API? • Autoconfiguration • User centric context awareness => dynamic reconfiguration • Service description, advertisement, discovery (ontology problem and more) • Localisation • Interaction paradigms: uni, multi, any, pub/sub… • Filtering and data aggregation CAN’T IGNORE THE NETWORK

49. Challenges: Usability • Fundamental questions for ‘invisible’ systems • What is user expectation? What then is QoS? • Heterogeneity • Scarce resources affect user interfaces • General paradigms? • Non technical users • Adaptation  HUGE complexity in interaction • Debugging??? => localised intelligence and managed service provision

50. Challenges: Predictability S NETWORK C A • Some applications require predictability despite: • Context-change  adaptation – in real time • Mobility • Linkage to an unpredictable physical environment • Coordination between multiple devices – e.g. power • Network / service management • Data centric control • Cooperative behaviour and control in presence of faults and unpredictable delays?