Friday, March 7, 2008

Homogeneity and heterogeneity in disasters

The problems of homogeneity

The video sequence of the collapsing WTC towers has probably been burned into my memory forever. It was unique in many ways. There was of course the shock, the unbelievable cruelty... But there was also astonishment and surprise. About the fact that they collapsed at all, the fact that they collapsed both and the apparently choreographic elegance the towers collapsed. To some this was so unbelievable, that they called for conspiracy theories. After the disaster, the experts looked at what went wrong when conceiving and building those towers. Questioning the used materials, the fire protection measures, the building statics calculations.... But at a more abstract level there was something more fundamental, most people seemed to ignore: the homogeneity of the towers.

In May 2004 the computer worm Sasser caused a serious worldwide epidemic. In 48 hours at least 1,3 million PCs were infected and the infection rate continued at half a million per day. Till today, nobody knows the exact figures. How could this happen? Because the exploited vulnerability existed in a Windows library file (LSASRV.DLL) shipped with all Windows versions (98, NT, 2000, XP, ME). In 2004 these were about 94% of all online computers (3% left for Linux and additional 3 % left for Mac). So, the infection rate and the global spreading of Sasser and other worms only became possible because of the homogeneity of operating systems.

We could continue the list of examples about the raise of fascism before world war 2 and the homogeneity of minds, different blackouts of the internet, power supply and telecommunication networks and the homogeneity of networks.


The attractiveness of homogeneity

Of course and for legitimate reasons we do everything to achieve homogeneity and to avoid heterogeneity in our daily life: standardization efforts, procedures, unification of concepts, etc... What a nightmare if paper sizes (A4, Letter) weren't standardized, if there were no standards for screws, USB, IP addresses, ..... Software development is in general a huge effort of standardizing tasks, processes and concepts. The benefits are very clear of course.


The impact of homogeneity and heterogeneity in crisis situations

The underlying problem is that homogeneity designed for ease and efficiency in normal situations is quite often also beneficial for disasters to strike, for exactly the same reasons.

In crisis communication we have a natural heterogeneity of organizations (first responders, police, fire fighters) , of procedures, of formal and informal communication channels and of the respective telecommunication means (fixed telephony, mobile telephony, IP, Tetra, pagers, FAX). The multitude of systems and technologies is the result of a great independence of each of these organizations. In the past, the public or civil fire fighter organizations just didn't consult the technical or purchase department of the police corps before investing in a communication system or equipment.

In general this lack of homogeneity is not only considered as a major cost factor but also as a problem for efficient crisis communication and disaster recovery. How can the fire fighter's analog radio system communicate with the police officers TETRA network?
But as exposed above it has also some hidden resilience benefits in disasters and might minimize the impacts from outages on overall communication efficiency. If one system or network fails the other ones may remain in place.


Interconnecting heterogeneous communication systems


To benefit from both worlds' advantages, you may consider for the involved organizations to put an homogeneous overlay messaging application over the heterogeneous communication systems in place.
This idea is at the heart of the unified incident and alarm management system that our company is actively developing since several years. AlarmTILT a multi media, multi technology messaging system specially designed for incident and crisis communication applications bridging between existing communication networks and devices in those situations.

Monday, February 25, 2008

Human sensors in crisis communication

Most of the times when we talk about sensors, we mean technical devices, measuring some relevant metrics and transmitting them to some data collection or management entity.


Sensing data

Sensors are more or less dumb and most of the time very specialized. Not to minimize the importance of technical sensors in the preparedness context, but a flood sensor may only tell you that the water level of a river exceeded a predefined threshold. It won't tell you that the floods damaged a road making it unusable for rescue operations.

Using his mobile phone, a person might notify some central crisis management entity about the damaged road. But this solution of sensing and assessing complex events, lets another problem pop up: How to consolidate the transmitted data, verbally communicated in a non structured way by a person to a crisis operator? Beyond the contextual information and knowledge the operator needs in this case, this communication isn't very efficient and prone to errors.


Consolidating data

The big advantage of the communication with the technical sensor is that it only understands one question "What is the water level?" and gives precise answers like "2,11 m (above some defined reference)". The transmission of this data can be stored locally and transmitted at regular interval or on demand, or can be automatically pushed to a central location, by mobile or fixed telecommunication means.

Consolidating human data is somewhat more complex. You can imagine that a trained call center operator will transcode human provided data into structured data usable by crisis management systems. But you can also imagine that a local application on the human sensors' mobile phone or PDA pops up and ask the relevant questions, e.g. "Can you confirm that the bridge is destroyed? YES/NO", "How many vaccines have you left in the Flu Pandemic Vaccination Center? Enter the number".

Of course there are some prerequisites and constraints to this approach:
  • Central management of the application's dialogs (questions and answer)
  • Users' awareness of the data sensing application. Minimal training might be required
  • Users' ability to use their own mobile phone or PDA beyond pure telephony
  • Device management and User-device associations: which user has which device, which devices have J2ME support, what screen resolution and communication facilities are available
The usability of the transmitted data could or should be augmented by time and location and presence data provided by the users device and it's application.

Collecting, structuring, parsing and validating user provided data is only part of the story. Consolidating them in a useful way with technical sensor data and using them for procedure and alarm triggers is the most challenging part.

Part of these features are already reality in my company's solution (AlarmTILT), the remaining parts are under development. Stay tuned ...


Assessing data

A good model of the crisis environment is of course the prerequisite for human sensors to provide added value. Detailed planning of the applications and training of the users is the key to successfully exploit the valuable human sensor data. Just recall Tsunami or the London Bombing in your memory to understand that a lot of highly useful "field" information is available but is left unused most of the time.

Tuesday, February 19, 2008

Why asynchronous communication deserves more consideration in crisis situations

Crisis managers and contingency planners have very different backgrounds. At least in most countries, you cannot study "Crisis Management" and get a "Master in Crisis Management" diploma. Crisis managers backgrounds may vary from military, health care, IT, telecommunications and more exotic ones.
This could be an explanation why in conventional setups command control centers still play a dominant role in crisis management and communication.
But in reality for most crisis types, be it flu pandemic, terrorist threat (or even attack) or floods, the responsible individuals at the political level and the teams at the operational and response levels are quite often mobile professionals that belong to different organisms or administrations. They even may be geographically dislocated.
The common solution proposed to address these problems are telephony and or video conference facilities, allowing people to virtually meet when the crisis happens. These facilities are only a part of the solution because two important aspects are too often ignored:
  1. Conference systems are synchronous communication tools that requires people to be available at the same time. The killing argument why this shouldn't be a problem is the following: if there is a crisis, it is the top priority for everybody, so agenda clashed cannot occur and thus are not a problem . This, of course, isn't true. If a major incident or even a catastrophic one (e.g. London bombing) happened, many organizations may be involved at different level, add hoc task groups might be created and most importantly a multitude of measures may be implemented.
    As an example, Luxembourg (the country, not the city) has defined 187 different measures in the context of the flu pandemic risk, of which several might need to be implemented in parallel (c.f. http://www.grippeaviaire.public.lu/mesures/gouv/index.html ). Luxembourg is among the smallest countries in the world, which might reduce the scale of the crisis, but which also increases the chances that the same people are relevant in several contexts.

  2. Even to organize a physical (~synchronous) meeting or a telephony or video conference (~synchronous), you need to call in local participants or notify participants that are on the move or at a remote location my any means. You not only may want to notify them in a fully automated way, but you also may want to know in real time who will be available, to make a proper planning of your crisis management. People may have mobile or fixed phones, instant messaging, e-mail, BlackBerrys or pagers. In these situations asynchronous messaging communication is probably the only rapid and affordable way to get the job done.
When comparing synchronous communication (physical meeting, telephony or video conference) to asynchronous communication, several other aspects may be important:
  • intrusiveness, e.g. can a first responder answer to a phone call when he is busy saving lives?
  • communication clashes - what happens if I'm involved in more communications or communication threads? Are messages carrying vital information delayed or even lost?
  • logging and tracing of communications - how can crisis managers extract lessons learned and how can they justify their choices afterwards?


The table below gives the summary of the main differences.


To conclude, in the crisis communication context, an asynchronous messaging system might be an essential complement to the command control conferencing facilities, as it is the only way to efficiently communicate with people relevant to the crisis, but that are on the move, or key persons that have more than one function in the management of the crisis.

Are specialized messaging systems for crisis situations available on the market?
The clear answer is yes!

Who is providing such a solution?
Guess ;-) ? My company:

alarmtilt

But to be fair, there are also other companies, it might be worth to have a look at:
mir3
n3
paradigm
strohl systems

If you find some more solutions to add to the list please write a comment and let us know!