Transcript Slide 1

RUNES
Fire!
Requirements for reconfigurability.
Stephen Hailes
Department of Computer Science, UCL
Technical Manager, RUNES project
[email protected]
http://www.ist-runes.org
Introduction
RUNES
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
16th session of the Software Technology Forum, Budapest 08/06/2006
Somewhere in the world…
RUNES
1999
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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..
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
Introduction Story Requirements Technology Future Conclusions
• 11.04, 18 minutes a.i.
– The first fire engine leaves its base at Courmayeur.
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
RUNES
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
16th session of the Software Technology Forum, Budapest 08/06/2006
Somewhere in the world…
RUNES
Introduction Story Requirements Technology Future Conclusions
2019
16th session of the Software Technology Forum, Budapest 08/06/2006
What if…
RUNES
• 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
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM
RUNES
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
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
RUNES
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, …
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
RUNES
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.
16th session of the Software Technology Forum, Budapest 08/06/2006
Summary so far
RUNES
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
16th session of the Software Technology Forum, Budapest 08/06/2006
Somewhere in the world…
RUNES
Introduction Story Requirements Technology Future Conclusions
The
Technology
16th session of the Software Technology Forum, Budapest 08/06/2006
Networked Embedded Systems
RUNES
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
16th session of the Software Technology Forum, Budapest 08/06/2006
Internetworked Embedded Systems
RUNES
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
16th session of the Software Technology Forum, Budapest 08/06/2006
Embedded networks
RUNES
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]
16th session of the Software Technology Forum, Budapest 08/06/2006
Development challenges
RUNES
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
16th session of the Software Technology Forum, Budapest 08/06/2006
State of the Art (software)
RUNES
Introduction Story Requirements Technology Future Conclusions
• Increasing prevalence of networked embedded systems
– inherently heterogeneous and dynamic
• So why do we not have heterogeneous, dynamic, largescale 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
16th session of the Software Technology Forum, Budapest 08/06/2006
RUNES
sira
USA
Australia
16th session of the Software Technology Forum, Budapest 08/06/2006
RUNES Vision
RUNES
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
16th session of the Software Technology Forum, Budapest 08/06/2006
The RUNES programming model
RUNES
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
16th session of the Software Technology Forum, Budapest 08/06/2006
Component frameworks (CFs)
RUNES
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)
16th session of the Software Technology Forum, Budapest 08/06/2006
Summary of RUNES approach
RUNES
•
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
16th session of the Software Technology Forum, Budapest 08/06/2006
All life on earth is insects
RUNES
Introduction Story Requirements Technology Future Conclusions
90%
of shipments
microprocessors
are
embedded
Very
Pentium
Annual
According
few
has
oftothese
<2%
"Embedded
billions
of
willthe
pass
market
of
Report:
10
micro-controllers
billion
Theduring
Information
2007.
are networked
Network," in 2005 there
were 7.477 billion micro-controllers shipped worldwide.
16th session of the Software Technology Forum, Budapest 08/06/2006
RUNES
Introduction Story Requirements Technology Future Conclusions
ANOTHER BEER
PLEASE HAL…
16th session of the Software Technology Forum, Budapest 08/06/2006
I’M SORRY DAVE, I
CAN’T DO THAT. THE
BATHROOM SCALES
AND THE HALL MIRROR
ARE REPORTING
DISTURBING
FLAB ANOMALIES
The RUNES DVD
RUNES
Introduction Story Requirements Technology Future Conclusions
Play
16th session of the Software Technology Forum, Budapest 08/06/2006
Conclusions
RUNES
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
16th session of the Software Technology Forum, Budapest 08/06/2006
Questions?
RUNES
http://www.ist-runes.org
[email protected]
16th session of the Software Technology Forum, Budapest 08/06/2006
Challenges: Physical layer
RUNES
• 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
16th session of the Software Technology Forum, Budapest 08/06/2006
Challenges: Network
RUNES
• Heterogeneity – where’s the waist?
• MAC protocols for mobile sensor nets
End of the
NOTE2E
ALL IP
argument?
– 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
16th session of the Software Technology Forum, Budapest 08/06/2006
Challenges: Middleware
RUNES
• 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
16th session of the Software Technology Forum, Budapest 08/06/2006
Challenges: Usability
RUNES
• 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
16th session of the Software Technology Forum, Budapest 08/06/2006
Challenges: Predictability
RUNES
• Some applications require predictability despite:
– Context-change  adaptation – in real time
– Mobility
– Linkage to an unpredictable physical environment
S
C
NETWORK
A
• Coordination between multiple devices – e.g. power
– Network / service management
– Data centric control
• Cooperative behaviour and control in presence of faults
and unpredictable delays?
16th session of the Software Technology Forum, Budapest 08/06/2006
Challenges: Verification
RUNES
• 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…
16th session of the Software Technology Forum, Budapest 08/06/2006
Cross stack issues
RUNES
•
•
•
•
Security
Dialtone reliability
Energy efficiency
Adaptation and control
16th session of the Software Technology Forum, Budapest 08/06/2006
Social, political, ethical issues
RUNES
• 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
16th session of the Software Technology Forum, Budapest 08/06/2006
Conclusions
RUNES
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
16th session of the Software Technology Forum, Budapest 08/06/2006
Questions?
RUNES
http://www.ist-runes.org
[email protected]
16th session of the Software Technology Forum, Budapest 08/06/2006