Date post: | 26-Dec-2015 |
Category: |
Documents |
Upload: | randall-obrien |
View: | 218 times |
Download: | 0 times |
RUNES
Fire!Requirements for reconfigurability.
Stephen HailesDepartment of Computer Science, UCL
Technical Manager, RUNES project
http://www.ist-runes.org
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Introduction
• 1999 – The story of Mont Blanc• 2019 – SAFECOM requirements• Technology
– Hardware– RUNES software systems – issues and challenges
• The Future• Conclusions
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Somewhere in the world…
1999
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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..
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 11.04, 18 minutes a.i.– The first fire engine leaves its base at Courmayeur.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Mont Blanc
• 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
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Somewhere in the world…
2019
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
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
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM
• 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
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
• 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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
• 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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
• 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, …
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
SAFECOM requirements
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.
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Summary so far
• 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
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Somewhere in the world…
The Technology
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Networked Embedded Systems
• 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
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Internetworked Embedded Systems
• Networks are becoming increasingly networked and heterogeneous (inter-networked)
Lippert MoteMaster: PC/104 128M RAM, 256M flash
Connect Blue Sensor Routing NodeARM7 – 32K RAM, 512K flash
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Embedded networks
• …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]
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Development challenges
• 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
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
• 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
State of the Art (software)Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
• 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
RUNES VisionIntroduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
The RUNES programming model
• 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
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Component frameworks (CFs)
• 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)
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Summary of RUNES approach
• 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
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
All life on earth is insects
Pentium has <2% of the market90% of microprocessors are embeddedAccording 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
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
ANOTHER BEERPLEASE HAL…
I’M SORRY DAVE, ICAN’T DO THAT. THEBATHROOM SCALES
AND THE HALL MIRRORARE REPORTING
DISTURBING FLAB ANOMALIES
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
The RUNES DVD
Play
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
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
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Questions?
?http://[email protected]
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
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
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Challenges: Network
• 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 IPEnd of the
E2E argument?
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
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
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
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
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
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?
NETWORKC
S
A
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
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…
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Cross stack issues
• Security• Dialtone reliability• Energy efficiency• Adaptation and control
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
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
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
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
Introduction Story Requirements Technology Future Conclusions
RUNES
16th session of the Software Technology Forum, Budapest 08/06/2006
Questions?
?http://[email protected]