Fire! Requirements for reconfigurability. Stephen Hailes Department of Computer Science, UCL Technical Manager, RUNES project [email protected]

RUNES

Fire!Requirements for reconfigurability.

Stephen HailesDepartment of Computer Science, UCL

Technical Manager, RUNES project

[email protected]

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


Somewhere in the world…

1999

RUNES


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


RUNES


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.


RUNES


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.


RUNES


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.


RUNES


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.


RUNES


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.


RUNES


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.


RUNES


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.


RUNES


Mont Blanc

• 11.04, 18 minutes a.i.– The first fire engine leaves its base at Courmayeur.


RUNES


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.


RUNES


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.


RUNES


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.


RUNES


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


RUNES


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


RUNES



2019


RUNES


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


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


RUNES


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.


RUNES



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


RUNES



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


RUNES



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.


RUNES



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.


RUNES



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.


RUNES



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.


RUNES



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.


RUNES


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


RUNES



The Technology


RUNES


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


RUNES


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


RUNES


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]


RUNES


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


RUNES


• 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


AustraliaUSA

sira

RUNES


• 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


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


RUNES


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)


RUNES


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


RUNES


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


RUNES


ANOTHER BEERPLEASE HAL…

I’M SORRY DAVE, ICAN’T DO THAT. THEBATHROOM SCALES

AND THE HALL MIRRORARE REPORTING

DISTURBING FLAB ANOMALIES


RUNES


The RUNES DVD

Play


RUNES


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


RUNES


Questions?

?http://[email protected]

RUNES


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


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


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


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


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


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


Cross stack issues

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

RUNES


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


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


RUNES


Questions?

?http://[email protected]

Documents

Fire! Requirements for reconfigurability. Stephen Hailes Department of Computer Science, UCL Technical Manager, RUNES project [email protected]