## 6 Application Example
### Emergency Response Process  
When the accident took place, the diagnosis process involved some minutes due the complexity of the physical scenario, and it began when the first firefighter company arrived to the area in question. Although the accident was recorded by various surveillance cameras (_i.e._, a regular sensor), neither automatic alarms were activated nor video records were shared with the emergency centers that could have helped reduce the reaction time. Analyzing the accident video records (using one or more HBS) it is possible to estimate the size and type of the emergency in approximately one minute. Therefore, sharing this video with the proper emergency center could have triggered a quick response in only a few minutes resulting in more saved lives. Once the first diagnosis was known, the emergency center performed a formal dispatch of resources, particularly firemen, police officers and ambulances. By that time, the traffic and communications in the area had collapsed, therefore the dispatched resources (many of them were HBS) experienced numerous difficulties, not only in arriving to the emergency site, but also in receiving and reporting information. Two helicopters, 110 ambulances, 55 police vehicles (over a hundred policemen) and six firefighting companies (over three hundred firemen) participated in the response process. Fifteen hospitals received the injured people (a total of 676 people according to the official report [37]). The ambulances started transporting these people to the three closest hospitals. Once these hospitals were overcrowded, other options were taken. However, for this situation to become visible to the ambulances was a complex task that required a considerable time. Therefore, many ambulances tried to leave injured people in more than one hospital until they found one able to receive them. The first paramedic (_i.e._, HBS) arriving to an overcrowded hospital could record the hospital status in one or most witness units, and thus other ambulances accessing such an information can know where exactly to transport the people. After the first 12 h, no lists of dead and injured people were available. Therefore, relatives and friends of potential victims were asking in different hospitals and at the city morgue for hours, interfering with an already complex response process. The hospital managers (_i.e._, potential HBS) could have made public the list of injured people located there, e.g., through a Web portal or in a witness unit, allowing thus civilians (also HBS) to perform their searches quickly and without jeopardizing the emergency response activities. The search and rescue process took all day. At the end of the day there was still a missing person, who was found 48 h later. He was a young man who got into the train 20 min before the crash. He was travelling in a compartment where passengers are not allowed to be. The rescuers scanned over the spot without noticing his presence. This situation could have been addressed more effectively through the use of a contactless Smart card called SUBE (that stands for Electronic Ticket Unified System), that identifies each user. By making a small extension to the current ICT infrastructure supporting the SUBE, it is possible to sense (e.g., count) the number of people in the train, and also the identity and location of each passenger. If this information is shared through a witness unit, then it is possible to accelerate the response process, triggering parallel procedures that help reduce the injury. It also would have allowed an early detection of the missing person. An extra support for locating people could also be obtained using localization mechanisms based on cellular phones (with the WAP-OTA protocol). Concerning communication support in the affected area, there is no clear information in the emergency reports, except that the telephone networks (both wired and wireless) collapsed immediately after the incident and that they were down for some hours.