Fire! Requirements for reconfigurability.

1
Fire!Requirements for reconfigurability.

• Stephen Hailes
• Department of Computer Science, UCL
• Technical Manager, RUNES project
• s.hailes_at_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 105830 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/Mon
  tBlanc.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 networked and
  heterogeneous (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 systems tends to be
  ad-hoc
• little provision for generalisable and reusable
  abstractions and services applications are
  bespoke and limited
• Need a generic programming 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
(No Transcript)
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 lt2 of the market
According to "Embedded Report The Information
Network," in 2005 there were 7.477 billion
micro-controllers shipped worldwide.
Annual shipments will pass 10 billion during 2007.
Very few of these billions of micro-controllers
are networked
42
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_at_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 wheres 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
• gt Can we devise a common API?
• Autoconfiguration
• User centric context awareness gt dynamic
  reconfiguration
• Service description, advertisement, discovery
  (ontology problem and more)
• Localisation
• Interaction paradigms uni, multi, any, pub/sub
• Filtering and data aggregation
• CANT 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???
• gt localised intelligence and managed service
  provision

50
Challenges Predictability

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

51
Challenges Verification

• Prototypes must be built and tested
• Much research work in the area is simulation-only
• Learn much even from real small scale systems
  c.f. MANET
• However, also want to test against a vision of
• Scale
• Heterogeneity
• Implies the need for realistic simulations to be
  used.
• Simulation methods for resource challenged mobile
  systems

52
Cross stack issues

• Security
• Dialtone reliability
• Energy efficiency
• Adaptation and control

53
Social, political, ethical issues

• Socially, this is a really important innovation.
  c.f. SWAMI, POST
• The issues regarded as most important both in
  terms of impact were
• fear of loss of control
• the increased possibility for surveillance
  offered by AmI
• profiling and security risks
• new opportunities for crime.
• Complexity the decision making process behind
  intelligent systems and the way valuable
  information is produced is not transparent.
• Other concerns death of privacy
• individuals are completely transparent
• They feel they are not in control of the
  technologies, but are controlled
• power structures tend to be opaque
• Some groups can fight a loss of control over
  technologies, some lack the intellectual, social
  or financial resources
• increasing dependency on AmI systems
• no public participation in AmI development process

54
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

55
Questions?

• ?
• http//www.ist-runes.org
• s.hailes_at_cs.ucl.ac.uk