Table of Contents Author Guidelines Submit a Manuscript
Journal of Advanced Transportation
Volume 2018, Article ID 7592926, 13 pages
https://doi.org/10.1155/2018/7592926
Research Article

Every Second Counts: Integrating Edge Computing and Service Oriented Architecture for Automatic Emergency Management

1Research Institutes of Sweden, RISE Viktoria, Lindholmspiren 3A, 417 56 Gothenburg, Sweden
2School of Information Technology, Halmstad University, 301 18 Halmstad, Sweden

Correspondence should be addressed to Lei Chen; es.ir@nehc.iel

Received 14 September 2017; Revised 23 November 2017; Accepted 3 January 2018; Published 5 February 2018

Academic Editor: Hwasoo Yeo

Copyright © 2018 Lei Chen and Cristofer Englund. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract

Emergency management has long been recognized as a social challenge due to the criticality of the response time. In emergency situations such as severe traffic accidents, minimizing the response time, which requires close collaborations between all stakeholders involved and distributed intelligence support, leads to greater survival chance of the injured. However, the current response system is far from efficient, despite the rapid development of information and communication technologies. This paper presents an automated collaboration framework for emergency management that coordinates all stakeholders within the emergency response system and fully automates the rescue process. Applying the concept of multiaccess edge computing architecture, as well as choreography of the service oriented architecture, the system allows seamless coordination between multiple organizations in a distributed way through standard web services. A service choreography is designed to globally model the emergency management process from the time an accident occurs until the rescue is finished. The choreography can be synthesized to generate detailed specification on peer-to-peer interaction logic, and then the specification can be enacted and deployed on cloud infrastructures.

1. Introduction

Despite the rapid development of information and communication technologies (ICT) and the continuous efforts to improve the road infrastructure, traffic safety remains a major challenge. Globally, since 2007, more than 1.2 million fatalities occur each year [1], leading to significant social and economical cost. Within the EU, according to the accident statistics database CARE (https://ec.europa.eu/transport/road_safety/specialist/statistics/index_en.htm), there were one million road accidents in 2013, which caused 26.000 fatalities and left 1.4 million injured. Significant efforts are still urgently needed to improve the traffic safety and to minimize the number of fatalities and severe injuries.

Cooperative intelligent transport system (C-ITS) is an emerging and fast growing area that utilizes connectivity, for example, vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I), as the key technologies for enabling advanced traffic applications to address challenges within the transport sector. Major stakeholders are working intensively from advanced policy making such as the US Department of Transportation and the standardization activities such as ISO CALM [2], IEEE WAVE [3], ETSI C-ITS [4, 5], to the consumer application innovation by car manufacturers. C-ITS allows vehicles and infrastructure, as well as all types of vulnerable road users to actively communicate with each other, thus minimizing the overall accidental risks. The world’s first commercial C-ITS system has been deployed in Japan by Toyota on the 760 MHz frequency band where the emergency vehicle (EV) warning was one of the first deployed applications. In the meanwhile, large scale pilots are implemented worldwide such as connected vehicle safety pilot (https://www.its.dot.gov/pilots/index.htm) in the US and the C-ITS corridor (http://c-its-korridor.de/) in the EU. C-ITS today is primarily based on Dedicated Short Range Communication (DSRC), for example, IEEE 802.11p, and in general is not able to fully support advanced automotive applications. Future traffic applications have different requirements. The safety-critical applications need highly reliable communications with low latency, while infotainment applications need high bandwidth. For supporting applications with differential QoS, various techniques have been proposed by the telecommunication industries as part of the continuous evolution of cellular networks such as multiaccess edge computing (MEC) and network slicing [6]. With the publication of the first set of standards on LTE for V2V [7] and the launch of 5G Automotive Association (5GAA) (http://5gaa.org/), the automotive industry has been considered as one of the key vertical sectors for the forthcoming 5G communications.

Connectivity enables efficient information exchange, while artificial intelligence (AI) enables advanced decision support. The past years have witnessed significant development of AI in both algorithm development, for example, deep learning, and applications, for example, autonomous vehicles. With advanced algorithms and the reach of cloud computation resource, machines in the future are able to perform tasks such as accident recognition and evaluation based on rich information including sensor data, images, and streaming video. In addition, several earlier advanced planning and optimization algorithms, whose ability was limited by the computing resources and data, can now be deployed with integration of recent advancement to deliver more efficient solutions. Classical problems such as emergency resource planning, dispatching, and EV routing are expected to be tackled with performance far beyond traditional solutions. Furthermore with MEC, some intelligent services, for example, automatic intersection coordination [8] and image recognition, are able to be deployed closer to the end-users, for example, at the network edge, to provide more responsive solutions.

Efficiency of an emergency management system relies on the collaboration between the involved stakeholders. A well-defined emergency management framework with detailed specification of information exchange and coordination flow that can be executed automatically can significantly improve the overall performance of the emergency response. Service choreography, as one of the service composition methods in the paradigm of service oriented architecture (SOA), provides a promising method for collaborating multistakeholder activities in a distributed approach. With choreography, each stakeholder implements the professional tasks within its own organization and provides them through services. The stakeholder collaboration is then realized by interaction between services according to the specified business logic, for example, emergency response procedure. In view of this potential, an integrated platform for automatic synthesis of dynamic and secured choreographies, that is, CHOReVOLUTION (http://www.chorevolution.eu/), is under development. It is expected that the platform also provides software tools for efficient choreography-based application development. Notice that such platforms go beyond the scope of this paper and we focus on the overall design of automatic emergency response system based on choreography and with introduction of emerging technologies.

This paper is built further on an initial work in [9] and presents a future-oriented automated emergency management system (AEMS) by integrating MEC and SOA. AEMS combines emerging MEC technologies and artificial intelligence and utilizes the concept of choreography from SOA to coordinate multidomain activities for automating the emergency management. The system provides advanced support to human activities/interaction through machine activities/interaction, thus reducing the response time and improving the rescue efficiency. Service-choreographies are introduced to model the entire response procedure, where each stakeholder performs its professional tasks within its organization and exposes collaboration details through web services.

The remainder of the paper is organized as follows. Section 2 gives a brief summary of the emergency management and the challenges, together with recent advancements within the area. Section 3 gives an introduction to the integrated architecture of MEC and SOA together with a brief introduction of the choreography concept. In Section 4, a layered architecture of AEMS is proposed and described with specification of actors and design of corresponding services. Based on those, Section 5 presents the designed AEMS choreography through diagrams and describes the coordination processes. Section 7 concludes the paper and outlines research challenges along with ongoing and future work.

2. Emergency Management

2.1. Emergency Management Challenges

Emergency management has long been recognized as a social challenge as the situation may be life-critical. Therefore, the response requires all stakeholders within the cycle including public-safety answering point (PSAP), police, medical services, and road operators to collaborate in a very efficient way. Figure 1 shows the emergency response process, together with actors and challenges for each of the stages.

Figure 1: Emergency management phases and challenges.

In an emergency situation such as a crash scene, time is critical. Minimizing the emergency response time will help to significantly reduce the damage and maximize the chance of survival of the injured. This involves minimizing the time needed for each of the stages including accident reporting from the accident site, decision and planning at the PSAP, EV routing on the road, and on-site rescue. Significant challenges exist for each of the stages.

Accident reporting nowadays depends largely on manually call-in by either the driver or passenger(s) of the accident vehicle, or a witness passing by. In most cases, the persons on site may be hurt or panic; thus accurate information may not be well communicated. This makes it hard for the PSAP to make appropriate decisions.

The PSAP is under great pressure. Firstly, it needs to evaluate the situation for decision-making. Secondly, it needs to consider the availability of resources and optimizes the dispatch. Those two tasks need complex decision algorithms that are computationally intensive and require accurate information. Thirdly, the first responders are usually required to arrive within a certain time, which places great pressure on the EV drivers. Despite intensive research on EV routing [10, 11], the travel time of ambulances depends heavily on the traffic situation. In some situations, ambulances themselves may cause traffic chaos and become victims [12]. In an early study, the German Federal Highway Research Institute (BASt) [13] found that EVs had an eight times higher risk of being involved in traffic accidents with serious injuries and a four times higher risk with respect to lethal accidents compared to an average vehicle. Going through red traffic lights, going through uncontrolled intersections, and overtaking were among the major scenarios, and the reasons were mostly due to unclear intention exchange between the EV and the other road users and lack of assistance from the infrastructure.

2.2. Recent Developments

Connectivity and automation are considered as key enablers for the Vision Zero (http://www.visionzeroinitiative.com/) which claims that no fatalities or severe injuries are acceptable in traffic. While the development of connected and automated vehicles has been focusing on preventing accidents from happening, the equally important process for postcrash emergency management has also been considered.

Accident reporting can be improved with in-vehicle emergency call services, such as GM OnStar, Ford SYNC, BMW connected drive, Audi connect, and HELPNET (https://www.helpnet.co.jp/car/) in Japan. In case of emergency, drivers or vehicles are able to call helpdesks provided by the corresponding car manufacturer. If necessary, certain data will be sent to the public emergency response center for further actions. It has been a good move, however, still far from efficient. The processes involve two decision-making procedures, that is, the evaluation at both the car manufacturer’s response center and the public response center, each taking time, let alone the fact that their interactions are usually done through human conversations. To make the accident reporting automatic, another initiative is the eCall (https://ec.europa.eu/digital-single-market/en/ecall-time-saved-lives-saved) system proposed by the EU. The eCall system is an emergency call system embedded within the vehicle and is able to contact the pan-European emergency center in case of accidents and send simple data such as vehicle positions. It is expected that emergency response time can be reduced by 50% in the countryside and 60% in the urban areas with such a system. Systems for automatic accident detection and recognition have been proposed and prototyped in such as [1417] with discussion on future trends in emergency response systems. In principle, eCall only supports voice and simple data transmission. This may be a disadvantage to fully explore the benefits as the emergency center only has information that an accident occurs, while no further information can be used for, for example, in-advance accident evaluation and emergency resource preparation. This has been recognized by experts and works on next generation emergency response systems have also been started such as the concept of next generation 911/112 (NG911/112), as well as the project EMYNOS (https://www.emynos.eu/).

As also shown in [14], emergency services are evolving with the development of connected transport systems. In the future, connected vehicles are able to provide rich information that can be used by artificial intelligence to evaluate the accidents and to give suggestions on how to react. It is then expected that advanced algorithms can be deployed by PSAP at both the control center and edge clouds for accident recognition, severity evaluation, casualty status evaluation, and so on. This will greatly help to improve resource allocation and vehicle dispatching, as also recognized by the World Health Organization (WHO) [18]. In the meanwhile, the casualty information can be used for premedical treatment and preparation of facilities [19].

Emergency resource planning and optimization has long been an active area due to the problem complexity and its unique importance in the society. This can be shown by numerous literature covering emergency facility sitting problem [20, 21], EV reallocation [22], and so forth. A number of studies have been conducted to facilitate EV with emerging technologies such as traffic signal control [2325] and vehicular communications [26, 27] and have shown great potential. In addition, EV warning has also been listed as one of the day-1 C-ITS applications [28] and has been demonstrated in the Grand Cooperative Driving Challenge (http://www.gcdc.net) in 2016. It is expected that future ambulances are able to communicate with infrastructure and other road users for free passages on their planned route.

Clearly, to minimize the overall emergency response process, a multistakeholder collaborative system is needed to seamlessly execute tasks of all response stages. In this paper, we try to specify the process with the help of service choreography and aim at an innovative automatic emergency management system.

3. MEC and SOA Architecture Integration

MEC aims to bring services to the edge of the network, thus providing real-time services to the end-users with extreme low latency. Leveraging the MEC platform, SOA makes use of standard web services to build reusable and interoperable software components, enabling multistakeholder collaboration while maintaining organizational agility. Figure 2 illustrates the integration of MEC and SOA in an vehicular environment and more discussion can be found in the following part.

Figure 2: MEC and SOA architecture.
3.1. Multiaccess Edge Computing

The network has evolved to the stage that the current architecture is not able to support massive connections with differential Quality of Services (QoS) requirements, especially when services integrate with real-time computation-intensive intelligence that goes beyond the capabilities of traditional cloud computing where cloud servers are usually located far away. In order to provide differential services and local intelligence to the end-users, MEC has been proposed and is currently under standardization by ETSI [29]. The method shares similar concept with, for example, Cloudlet and fog computing, and moves resources and functions from the central cloud to the network edge, thus reducing the communication delay and providing local computing and storage support.

As shown in Figure 2, edge cloud can be deployed at each of the cellular base stations and provides services with a single-hop communication. MEC is access agnostic so that vehicles are able to connected to the network through multiple access technologies including WiFi, DSRC, and cellular communications. Depending on the scenario, edge cloud is able to provide intelligent services locally such as intersection control, vehicle coordination, and accident recognition, with extreme low latency. It connects to the central cloud through the backhaul network so that the edge services can be integrated with central cloud services from different organizations through service orchestration or choreography, thus realizing advanced applications.

3.2. SOA and Choreography

SOA is an architectural concept for interconnecting independently developed services [30]. A service is a self-contained logical representation of a repeatable business activity. It may be composed by other services and usually serves the consumers in a black-box fashion. Services are the basic elements that form the SOA and allow software components to collaborate with each other through standard communication protocols. Being language neutral and by leveraging existing cloud computing platforms, SOA provides solutions for streamline service integration across systems from multiple organizations for efficient organizational collaboration.

Two service composition approaches exist in SOA, namely, orchestration and choreography [31, 32]. Service orchestration denotes a centralized service coordination scheme, where a central service exists for coordinating all other services. On the contrary, choreography denotes a distributed approach for service composition, where only peer-to-peer interactions between services are defined and no central coordination service exists.

With a centralized service, orchestration is suitable for single domain workflow description, where the central service is able to control and coordinate all other services. While for multidomain services, where stakeholders and their services from different domains are equally present with no dominant controlling services, choreography provides a method for distributed coordination. Since interactions happen only between services, choreography is highly suitable for data-centric workflow description, as high amounts of data can easily overload the centralized service in the orchestration scheme. Considering that AEMS involves stakeholders from different domains and large amounts data connections are foreseeable in future traffic systems, the choreography scheme is promising.

The need for service choreography is also recognized by specification of the Business Process Modeling Notation (BPMN) 2.0 (http://www.bpmn.org/), where extensions are introduced for modeling choreography tasks. Choreography synthesis and service adaption have been studied in literature such as [3339], and automatic synthesizing platforms are also under development such as the CHOReVOLUTION platform. We focus in this paper on the system architecture of AEMS and the utilization of choreographies to coordinate multistakeholder services for emergency management.

4. AEMS Architecture

AEMS targets a fully connected and automated emergency response system. It is a three-layered system integrating today’s emergency response system with introduction of emerging services enabled by, for example, MEC infrastructure, connected vehicles, and artificial intelligence. Figure 3 illustrates the architecture together with key actors, services, and their interactions following the process shown in Figure 1. We describe in the following part for each of the layer the identified actors and the associated services for the purpose of coordination. Notice that the architecture is generic and stakeholder responsibilities may vary among countries.

Figure 3: A layered architecture of AEMS.
4.1. Local Coordination Layer

As shown in Figure 3, the local coordination layer involves mostly intelligent agents that are involved during the response process such as personal devices and vehicles. They have embedded intelligence and perform professional tasks and collaborate with each other through service interactions.

4.1.1. Vehicles

Future vehicles are equipped with communication abilities to support different applications. One such application is enhanced emergency call that goes beyond the capabilities of eCall. When an accident occurs (as shown with accident vehicle in Figure 3), the vehicle is able to connect directly to the PSAP and establish a communication link for data transmission. Data may include live streaming data and vehicle dynamics data upon the accident as well as certain amounts of historical data. In the worst case where no continuous transmission is possible, the system should be able to transmit the minimum set of data (MSD) as specified in eCall. This will help to recognize the factors that cause the accident and evaluate the severity of the accident. In the meanwhile, all vehicles should be able to broadcast and receive accident warning information to its immediate neighbor so that nearby vehicles get a warning to avoid further accidents.

Another application for connected vehicles is road priority requesting for EVs. EVs today use alarm and siren to notify other road users and request priority passing. As discussed, this traditional method is not efficient and sometimes causes additional accidents. In AEMS, the connected EVs will be able to collaborate with both the infrastructure and other road users to clearly specify their intention, thus facilitating free passage.

A third application is the emergency vehicle approaching warning running on road vehicles. Upon receiving road priority requests from an EV, the application automatically analyzes the situation and suggests the driver to give way at a proper time. This eliminates the confusion and gives the driver enough time to respond and consequently make sure that the EVs have free passage.

Associated with vehicles, the following services are designed to perform the above-discussed tasks. Those services can be integrated either within vehicle on-board systems as standard connected vehicle applications or through after-market solutions.(i)CV-eCall: this is the connected vehicle emergency call service that resides in vehicles and is able to send rich media of the accident scene to PSAP for evaluation.(ii)CV-AW: this is the connected vehicle accident warning service that resides in vehicles and is able to exchange accident information with neighboring vehicles.(iii)CV-EV, CV-PEV: those two are the connected vehicle emergency vehicle services that reside in ambulances and police vehicles, respectively. They are used to interact with infrastructure and other road users for the EV status and for requesting road priority.(iv)CV-EVW: this is the emergency vehicle warning service that resides in vehicles that are able to analyze the request from EVs and suggests drivers to perform give-way maneuvers or in case of autonomous vehicles, let the vehicles execute maneuvers automatically.

4.1.2. Personal Devices

Personal devices mostly correspond to smart phones. The device can be with the driver and passengers in the accident vehicle or witnesses. In AEMS, witnesses are assumed to have smart phones that are able to report the accident scene in rich media such as pictures and video, as well as through voice communication. For this purpose, the following service is designed.(i)W-eCall: this service resides in the smart phone and is able to send both voice and video information to the response center for automatic accident recognition and evaluation. This helps to eliminate the emotional factor and gives the emergency center more accurate information.

4.2. Edge Layer

Though being equipped with rich sensors and connectivity, the road infrastructure today is not intelligent enough to handle emergency situations. The time it takes for EVs to arrive at the accident site significantly depends on the traffic on the roads. And in most of the cases, other road users have no clue where the ambulance comes and which path it wants to take. Considering the upcoming connected transportation system with MEC support, lots of intelligent services can be introduced at the network edge to assist the vehicles to make efficient decisions. Associating with the road infrastructure, the following two services are designed to take care of emergency infrastructure status changing and prioritized traffic lights setting, respectively. The services are deployed at local infrastructure with predefined policies to assist EVs. For security issues, they will need to verify the EV status through authorization from the road administration. In addition, PSAP is able to deploy accident evaluation services at the network edge for preevaluation of the accidents, thus further reducing the reaction time.(i)ITS-IRM: this is the intelligent road management service that resides locally at the road infrastructure that is able to automatically take in requests from EVs and change infrastructure status to facilitate EVs. The services can include automatic road closure and variable road signs.(ii)ITS-ITL: this is the intelligent traffic light service that resides at each of the traffic lights. It is able to coordinate the intersection traffic with predefined rules and algorithms. The EVs can be prioritized by giving in-advance green light. ITS-ITL at different traffic lights can coordinate with each other to formulate a traffic-free route for EVs. The algorithms will be deployed at the edge cloud for local computational support.(iii)SOS-AE: this forms part of the accident evaluation service and preevaluates information from the accident sites such as video and voice. By deploying SOS-AE at edge cloud, the evaluation time can be reduced significantly and evaluation can be done as quick as possible. The results can then be communicated with the centralized SOS-AE at PSAP for final decision support.

4.3. Organizational Coordination Layer
4.3.1. PSAP

The most important organization involved in AEMS is naturally the emergency response center or PSAP. It is responsible for the core tasks such as accident evaluation, emergency resource planning, and dispatching, as well as EV routing. In AEMS, it is expected that the emergency response center is highly automated, and information from the accident site is automatically processed by computers, both at the edge cloud and at the control center. With the support of big data analytics and machine learning the system is able to recognize, evaluate, and make suggestions to the operators for decision-making, thus reducing the response time and providing accurate information for optimizing the usage of emergency resources. The following services are designed in association with the PSAP.(i)SOS-AE: this is the central part of automatic accident evaluation service that takes in evaluation results from the edge SOS-AE for final evaluation and decision.(ii)SOS-ERD: this is the emergency resource distribution service that takes input from SOS-AE and performs optimized resource dispatching based on accident severity and availability of emergency resources. It generates the optimized routes for EVs with consideration of real-time traffic information and monitors the EV operation until the mission is completed.

4.3.2. Police

In certain circumstances, police officers are needed for maintaining the order to facilitate the response process. In such cases, PSAP requests assistance from the police department for joint mission. A service is designed for the police department to automate the process of requests and response.(i)P-ER: this is the police emergency response service that interacts with SOS-AE for joint mission and monitors the police vehicles through interacting with CV-PEV.

4.3.3. Medical Center

In case of severe accidents, immediate medical services are needed. However, before the first responders arrive at the accident site, the witnesses are the only persons available for assistance and they may not be professionals. Considering the intensive digitalization process within the health sector, remote medical advisory is considered in AEMS and is provided through the following service.(i)H-RMA: this is the hospital remote medical advisory service that resides in the hospital response center. It interacts with SOS-AE and establishes/shares communication links to W-eCall and/or CV-eCall. Through H-RMA, professional doctors are able to guide the witnesses on site for proper preparations until first responders arrive. Temporary psychological services may also be provided remotely to both the witnesses and the casualties.

4.3.4. Road Administration

Road administrators are the policy makers and infrastructure monitors. They are responsible to make the decision remotely change the status or authorize automatic status changing of road infrastructure such as road signs and traffic lights, to facilitate EVs. They also maintain databases and public APIs that provide real-time traffic information to road users and third-party service providers. In AEMS, the following services are considered.(i)ITS-ER: this is the emergency response service designed as part of the ITS system that manages the road infrastructure. It interacts with SOS-ERD and P-ER for EV information and interacts with ITS-IRM and ITS-ITL for infrastructure control.(ii)ITS-RTTI: this corresponds to existing traffic information services at the road administration to provide real-time traffic and infrastructure information to general public or third-party traffic information services.

The above-mentioned actors and organizations are in general independent from each other and play equally important roles during the emergency response. For an automatic emergency response system, they need to on the one hand focus on their own professional tasks and on the other hand cooperate with others for the entire response process. In AEMS, the collaboration is done by seamless coordination between services associated with each of the actors. Each service executes its own task within its own domain and exposes collaboration details through service interfaces. They will be provided publicly and can be reused through service composition. AEMS is such a system built on composing the above-designed services, more specifically choreographing the services. Based on BPMN 2.0, we design and present the AEMS choreography diagram that realizes the multistakeholder coordination for emergency management and discuss in detail the work flows.

5. AEMS Service Choreography Design and Specification

BPMN 2.0 is the latest version for service choreography models and is maintained by the Object Management Group (OMG) (http://www.omg.org/). To make the paper self-contained, a list of the notations that are used by the AEMS choreography is shown in Figure 4. A choreography always starts with a start event and finishes with an ending event. In between, multiple choreography tasks are executed following the business logic. A choreography task is an atomic activity denoting interactions between two participants, that is, one initiating participant and one receiving participant, through exchange of messages. A subchoreography is a compound activity involving two or more receiving participants and contains multiple tasks. Gateways are used to branch the business flow. A parallel gateway denotes that two or multiple parallel flows start simultaneously, while an exclusive gateway denotes that only one flow can continue according to conditions. An event based gateway triggers a process by an event. If certain choreography tasks are repeated until some conditions are reached, a loop can be used. For more detailed explanations on the usage of notation, we advise the readers to the BPMN standard.

Figure 4: Main notations for choreography modeling.

With the above notations and the previously designed services and based on the emergency response logic, a service choreography diagram is constructed and shown in Figure 5. The diagram illustrates the work flow of AEMS from the moment an accident occurs until the rescue is finished.

Figure 5: AEMS service choreography.
5.1. Accident Reporting

As illustrated in Figure 5, an accident triggers three parallel processes. The first process involves the CV-eCall services within the accident vehicles that request emergency services from PSAP through firstly establishing communications with the SOS-AE hosted at the edge cloud, then with the central cloud. We do not differentiate the edge SOS-AE and the central SOS-AE for the reason of simplicity and also due to the fact that they share the same responsibility for accident evaluation. Data exchange is thus established between the vehicle and the PSAP. Meanwhile, the witnesses start emergency calls through W-eCall at their smart phones and establish more simultaneous data flows to SOS-AE. It is anticipated that more data streams provide more information for accident recognition and evaluation at SOS-AE. As a third one, the CV-AW broadcasts accident information through local vehicular networks to its immediate neighbors to prevent further accidents until the EV arrives.

5.2. Public Emergency Response

SOS-AE conducts automatic streaming data analysis for locating the accidents, evaluating the accident severity and the status of injuries. It is expected that the entire process can be done automatically through on-line data analysis based on the support of edge and central cloud computing, traffic accident database, and advanced algorithms. Once SOS-AE finishes the evaluation, results and recommendations will be presented to the operators for action, thus triggering parallel rescue processes.

One of the processes is to dispatch the emergency resources in an optimal way. For this, SOS-AE interacts with another service at the PSAP, that is, the SOS-ERD. Based on information from SOS-AE and command from the operators, resource optimization will be conducted and ambulances will be sent out accordingly. Meanwhile, SOS-ERD interacts with ITS-ER at the road administration for requesting road priority support by sharing information of the ambulances. When ambulances are on the way, on-line monitoring is done through interaction between the SOS-ERD and CV-EV. Optimal routing will be continuously updated with consideration on the real-time traffic information. Meanwhile, CV-EV interacts with ITS-IRM, ITS-ITL, and CV-EVW locally to request road priority.

Besides activities within the PSAP, SOS-AE interacts with the P-ER service at the police station for requesting police assistance. Based on the information received, P-ER arranges police vehicles and resources to assist the response process. Once the police EVs are sent out, P-ER interacts with CV-PEV for monitoring the statuses. Similarly to SOS-ERD, P-ER requests road priority support by interacting with the ITS-ER service at the road administration. And CV-PEV interacts with ITS-IRM, ITS-ITL, and CV-EVW locally for prioritized passing.

Another parallel process started by SOS-AE is the emergency medical advisory. If remote medical advisory is needed, SOS-AE requests assistance by interacting with H-RMA at the hospital and establishes a shared communication link to the accident site. Professional medical staff can then help the injured by interacting with CV-eCall and also assist the witnesses for temporary medical action by interacting with W-eCall.

5.3. Emergency Vehicle Road Priority Support

EVs need free passage on the way they plan to take, which is one of the largest challenges for emergency response. The emerging ITS system connects vehicle and infrastructure, allowing efficient collaboration to help the EVs for free passage. In AEMS, this is done by (1) the road infrastructure to give certain assistance such as through emergency traffic signs; (2) the traffic light to give green lights; and (3) other road users to give way. Normally, EVs have traffic exemption rules that they are allowed to contravene red traffic light and speed limits, however, as already mentioned, this may introduce dangerous situations. With intelligent infrastructure such as connected traffic lights, EVs are able to share information with the infrastructure so that early actions can be taken such as to close certain roads automatically, to shown certain traffic signs, and to grant green lights on its way in advance to facilitate the passing.

Figure 6 illustrates the subchoreography of road priority assistance for both ambulances and police vehicles. The CV-EV/PEV service interacts with ITS-IRM and ITS-ITL for infrastructure support. After authorization from ITS-ER, ITS-IRM and ITS-ITL execute infrastructure changes, such as road closure and traffic light statuses changes. Those changes will then be communicated with CV-EV/PEV and will also be openly published through ITS-RTTI. For other vehicles on the road, CV-EV/PEV continuously interacts with CV-EVW services and shares the precise itinerary of the EV. The CV-EVW services notify the drivers in advance and allow the drivers to perform the give-way maneuvering safely and smoothly, thus eliminating the confusion and avoiding chaotic situations.

Figure 6: Subchoreography for road priority assistance.

6. Simulation Results

While we are working with stakeholders for collaborative details on AEMS on the organization level, a microscopic simulation is done with SUMO [40] to illustrate the effectiveness of an automated emergency response system. AEMS is future oriented where AI will be integrated to take care of tasks such as accident recognition, evaluation, and emergency resource distribution. Those tasks are independent and belong to each organizations where significant research is needed. This paper focuses on a smooth coordination framework and the effects of AEMS in emergency rescue. Thus in this section we focus on the coordination of EV with other vehicles and with the infrastructure, that is, traffic lights, and demonstrate how AEMS would reduce emergency response time significantly with assumption that stakeholder collaboration is running as expected.

The simulation is done with the Luxembourg SUMO Traffic (LuST) scenario [41], where Luxembourg city map has been used and traffic demand has been generated and calibrated with realistic demographic traffic data. The simulated route is from the hospital (marked with H) to accident site (market with X) in the city center as shown in Figure 7. The whole route is about 4.5 km long and passes through roads with speed limits from 50 km/h to 70 km/h and different congestion conditions. EVs are configured to be able to go beyond the road speed limit with 20%. The simulation corresponds the rush hour at around eight in the morning during weekdays when most roads have very heavy traffic especially near the city center. There are in total 21 intersections with traffic lights.

Figure 7: The Luxembourg scenario and the chosen route.

Different systems have been considered including(i)TL-exemption: this corresponds to the current system where EVs use alarm and siren to warn vehicles. EVs are mostly exempted from the traffic lights so they are allowed to pass through red lights but carefully. Other vehicles can only give way when the EV is nearby and when it is possible to give way,(ii)TL-exemption with CV: with connected vehicles, EVs will be able to warn other vehicles in advance with clear indications on road usage. Therefore, EVs have higher possibilities to maintain a higher speed. Here we assume high penetration of connected vehicles and human drivers are willing to give way. In order to reduce risks at intersections, EVs will mostly need to slow down at intersections with red lights. For this, we require that EVs reduce the speed to half if it intends to contravene the red light,(iii)AEMS: with AEMS, both vehicles and traffic lights are connected. All traffic lights will grant green waves to EVs for the chosen route ahead of time to empty vehicles on the route. In addition, all vehicles that remain on the route get alert and give way ahead of time. This essentially leads to an almost free passage for EVs.

Figures 8 and 9 show the results of speed and time profiles of the EV with different systems. As illustrated, with the current system TL-exemption, the EV has to follow the congested traffic flow. Even if it is exempted from the red light, it may not be able to pass through intersection because of the heavy congestion during the rush hour. For the chosen route and traffic condition, the EV takes in total 903 seconds to arrive at the accident site with average speed of 4.8 m/s (17 km/h).

Figure 8: Speed profiles of the EV.
Figure 9: Response time of the EV.

In comparison, when CV is introduced, the situation can be improved significantly. The CV-EV service running at the EV and CV-EVW service running at other road vehicles interact with each other to facilitate road priority. This tries to clear traffic for the EV on the planned route so that the EV is able to run with higher speed and avoid total stop when approaching the traffic lights. However, as mentioned, the EV is not allowed to run through a red light with full speed. Instead, it is required to reduce the speed to half to minimize safety risks. In this case, it takes in total 339 seconds to arrive at the accident site with average speed of 12.77 m/s (46 km/h). This already cuts the response time by almost two-thirds, demonstrating the great potential of vehicle connectivity.

With AEMS, not only will other road vehicles give priority, but traffic lights will also coordinate with the EV through the ITS-ITL service and form a series of green lights to facilitate the EV. Essentially, this is able to give a free passage for the EVs in the planned route. In such cases, EVs can run with full speed most of the time since green lights are granted automatically and other vehicles have clear indications. With AEMS, only 279 seconds are needed to arrive at the site, indicating a further 18% reduction of time compared with TL-exemption with CV. And compared with today's common practice where only TL-exemption is allowed, the total time can be cut by 69%.

As shown by the simulation, vehicle connectivity is the key to enable an efficient rescue system. With addition of infrastructure connectivity, powered by seamless stakeholder collaboration through service interaction, AEMS could facilitate much more efficient rescue process, thus saving lives.

7. Conclusion, Challenges, and Future Works

The connectivity has already become a norm in transportation with the intensive development on connected vehicles and cooperative intelligent transport system. Based on this context and the emerging multiaccess edge computing, as well as artificial intelligence, a future-oriented automatic emergency management system is proposed. The system architecture is presented with introduction of services designed for each stakeholder to perform its professional tasks within its domain and exposes the collaboration details through standard service interaction protocols. Choreography is used for modeling the coordination between the multidomain activities through service interactions.

While the paper provides preliminary design and evaluation of the system, significant challenges remain to be addressed. First of all, the AEMS coordination logic involves many stakeholders that need explicit definition of the tasks and interaction for automation, which requires close cooperation between domain experts on the organizational level. One example is the ongoing project AD Aware Traffic Control (https://www.drivesweden.net/en/projects/ad-aware-traffic-control-emergency-vehicles) within the Swedish innovation program Drive Sweden. The project aims to share EV information with autonomous vehicles for minimizing safety risks. Meanwhile within each specific domain, experts are expanding the capabilities of their single domain activities, where innovative solutions are considered for integrating emerging technologies for efficient solutions. For example, to enable tasks such as automatic accident recognition, evaluation, and reporting, large accident database and classification methods are needed, as well as advanced artificial intelligence methods. For tasks such as efficient emergency resource planning and on-line ambulance routing, optimization algorithms need to go beyond traditional methods and consider new features such as intelligent infrastructure and real-time traffic information. In addition to collaboration and decision processes, information delivery requires highly reliable communication solutions that are able to support high capacity, high mobility, bursting traffic, and stringent requirements on latency. The rapid evolution of 5G technologies will be foundations for AEMS. For fast processing of information such as accident recognition without going through central cloud, MEC is key, and challenges of MEC network design and optimization call for innovative solutions, such as the joint optimization of communication, computation, and storages.

In addition, platform support for service composition is another challenge. This paper focuses on the design of choreography for AEMS, while synthesis of the choreography for cloud deployment remains to be demonstrated. An integrated platform will definitely help to enable fast innovation through the reuse of multidomain services. We are currently investigating the CHOReVOLUTION platform for a prototype of AEMS while we also acknowledge that AEMS can be built on any suitable service composition platforms. In addition, the BPMN 2.0 itself has open issues and challenges such as described in [42]. This is under exploration within the CHOReVOLUTION platform for potential solutions.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This work is supported by the EU H2020 Project CHOReVOLUTION Automated Synthesis of Dynamic and Secured Choreographies for the Future Internet with Project no. H2020-644178.

References

  1. World Health Organization, “Global status report on road safety 2015,” Tech. Rep., 2015. View at Google Scholar
  2. ISO 21217, “Intelligent transport systems – Communications access for land mobiles (CALM) – Architecture,” Tech. Rep., 2014. View at Google Scholar
  3. IEEE 1609.0, “IEEE Guide for Wireless Access in Vehicular Environments (WAVE) - Architecture,” Tech. Rep., 2013. View at Google Scholar
  4. European Telecommunications Standards Institute, “Intelligent Transport Systems (ITS); Communications Architecture,” ETSI-EN-302 665, 2010.
  5. L. Chen and C. Englund, “Cooperative ITS - EU standards to accelerate cooperative mobility,” in Proceedings of the 3rd International Conference on Connected Vehicles and Expo, (ICCVE '14), pp. 681–686, Vienna, Austria, November 2014. View at Publisher · View at Google Scholar · View at Scopus
  6. NGMN Alliance, “NGMN 5G White Paper,” Tech. Rep., 2015. View at Google Scholar
  7. 3GPP, “3GPP TR 36.885 V14.0.0 Study on LTE-based V2X Services,” Tech. Rep., 2016. View at Google Scholar
  8. L. Chen and C. Englund, “Cooperative intersection management: a survey,” IEEE Transactions on Intelligent Transportation Systems, vol. 17, no. 2, pp. 570–586, 2016. View at Publisher · View at Google Scholar · View at Scopus
  9. L. Chen and C. Englund, “CHOREM: Choreographing services for emergency management,” ITS World Congress, pp. 10–14, 2016. View at Google Scholar
  10. A. Haghani, “An optimization model for real-time emergency vehicle dispatching and routing,” Transportation, pp. 1–20, 2003. View at Google Scholar
  11. V. Pillac, M. Gendreau, C. Guéret, and A. L. Medaglia, “A review of dynamic vehicle routing problems,” European Journal of Operational Research, vol. 225, no. 1, pp. 1–11, 2013. View at Publisher · View at Google Scholar · View at MathSciNet
  12. C. S. Burke, K. A. Wilson, E. Salas, and J. P. Kincaid, “Emergency vehicles: responder or victim?” Ergonomics in Design: The Quarterly of Human Factors Applications, vol. 10, no. 1, pp. 23–28, 2016. View at Publisher · View at Google Scholar
  13. Bundesanstalt für Straßenwesen, “Ursachenuntersuchung innerörtlicher Unfallstellen,” Tech. Rep.
  14. F. J. Martinez, C.-K. Toh, J.-C. Cano, C. T. Calafate, and P. Manzoni, “Emergency services in future intelligent transportation systems based on vehicular communication networks,” IEEE Intelligent Transportation Systems Magazine, vol. 2, no. 2, pp. 6–20, 2010. View at Publisher · View at Google Scholar · View at Scopus
  15. M. Fogue, P. Garrido, F. J. Martinez et al., “Prototyping an automatic notification scheme for traffic accidents in vehicular networks,” IFIP Wireless Days, vol. 1, no. 1, 2011. View at Google Scholar · View at Scopus
  16. M. Fogue, P. Garrido, F. J. Martinez, J.-C. Cano, C. T. Calafate, and P. Manzoni, “Automatic accident detection: assistance through communication technologies and vehicles,” IEEE Vehicular Technology Magazine, vol. 7, no. 3, pp. 90–100, 2012. View at Publisher · View at Google Scholar · View at Scopus
  17. M. Fogue, P. Garrido, F. J. Martinez, J.-C. Cano, C. T. Calafate, and P. Manzoni, “A system for automatic notification and severity estimation of automotive accidents,” IEEE Transactions on Mobile Computing, vol. 13, no. 5, pp. 948–963, 2014. View at Publisher · View at Google Scholar · View at Scopus
  18. World Health Organization, “Post-crash response: Supporting those affected by road traffic crashes,” Tech. Rep., 2017. View at Google Scholar
  19. S. K. Bhoi and P. M. Khilar, “VehiHealth: an emergency routing protocol for vehicular Ad Hoc network to support healthcare system,” Journal of Medical Systems, vol. 40, no. 3, p. 65, 2016. View at Publisher · View at Google Scholar · View at Scopus
  20. C. ReVelle, “Review, extension and prediction in emergency service siting models,” European Journal of Operational Research, vol. 40, no. 1, pp. 58–69, 1989. View at Publisher · View at Google Scholar · View at MathSciNet · View at Scopus
  21. X. Li, Z. Zhao, X. Zhu, and T. Wyatt, “Covering models and optimization techniques for emergency response facility location and planning: a review,” Mathematical Methods of Operations Research, vol. 74, no. 3, pp. 281–310, 2011. View at Publisher · View at Google Scholar · View at MathSciNet · View at Scopus
  22. L. Brotcorne, G. Laporte, and F. Semet, “Ambulance location and relocation models,” European Journal of Operational Research, vol. 147, no. 3, pp. 451–463, 2003. View at Publisher · View at Google Scholar · View at MathSciNet · View at Scopus
  23. U.S. Department of Transportation, “Traffic signal preemption for emergency vehicles,” Tech. Rep., 2006. View at Google Scholar
  24. Global Traffic Technologies LLC, “Traffic signal priority control for emergency vehicle preemption,” Tech. Rep., 2011. View at Google Scholar
  25. A. S. Eltayeb, H. O. Almubarak, and T. A. Attia, “A GPS based traffic light pre-emption control system for emergency vehicles,” in Proceedings of the 1st IEEE International Conference on Computing, Electrical and Electronics Engineering, (ICCEEE '13), pp. 724–729, Khartoum, Sudan, August 2013. View at Publisher · View at Google Scholar · View at Scopus
  26. M. Cetin and C. A. Jordan, “Making way for emergency vehicles at oversaturated signals under vehicle-to-vehicle communications,” in Proceedings of the IEEE International Conference on Vehicular Electronics and Safety, (ICVES '12), pp. 279–284, Istanbul, Turkey, July 2012. View at Publisher · View at Google Scholar · View at Scopus
  27. A. Buchenscheit, F. Schaub, F. Kargl, and M. Weber, “A VANET-based emergency vehicle warning system,” in Proceedings of the IEEE Vehicular Networking Conference (VNC '09), pp. 1–8, IEEE, Tokyo, Japan, October 2009. View at Publisher · View at Google Scholar · View at Scopus
  28. ETSI, “Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Definitions,” TR 102 368 V1.1.1, 2009. View at Google Scholar
  29. ETSI, “Mobile edge computing; framework and reference architecture,” Tech. Rep., 2016. View at Google Scholar
  30. M. P. Papazoglou, “Service-oriented computing: Concepts, characteristics and directions,” in Proceedings of the IEEE CS 4th International Conference on Web Information Systems Engineering (WISE '03), pp. 3–12, IEEE, Rome, Italy, Italy, December 2003. View at Publisher · View at Google Scholar
  31. C. Peltz, “Web services orchestration and choreography,” The Computer Journal, vol. 36, no. 10, pp. 46–52, 2003. View at Publisher · View at Google Scholar · View at Scopus
  32. S. Cherrier, Y. M. Ghamri-Doudane, S. Lohier, and G. Roussel, “Services collaboration in Wireless Sensor and Actuator Networks: Orchestration versus Choreography,” in Proceedings of the 17th IEEE Symposium on Computers and Communication, (ISCC '12), pp. 411–418, IEEE, Cappadocia, Turkey, July 2012. View at Publisher · View at Google Scholar · View at Scopus
  33. J. Misra, “A programming model for the orchestration of web services,” in Proceedings of the Second International Conference on Software Engineering and Formal Methods, (SEFM '04), pp. 2–11, Beijing, China, September 2004. View at Publisher · View at Google Scholar · View at Scopus
  34. S. Meng and F. Arbab, “Web services choreography and orchestration in Reo and constraint automata,” in Proceedings of the ACM symposium on Applied computing - (SAC '07), pp. 346–353, Seoul, Republic of Korea, March 2007. View at Publisher · View at Google Scholar · View at Scopus
  35. L. A. F. Leite, G. Ansaldi Oliva, G. M. Nogueira, M. A. Gerosa, F. Kon, and D. S. Milojicic, “A systematic literature review of service choreography adaptation,” Service Oriented Computing and Applications, vol. 7, no. 3, pp. 199–216, 2013. View at Publisher · View at Google Scholar · View at Scopus
  36. A. D. Salle, P. Inverardi, and A. Perucci, “Towards adaptable and evolving service choreography in the future internet,” in Proceedings of the IEEE World Congress on Services Services, pp. 333–337, Anchorage, AK, USA, June 2014. View at Publisher · View at Google Scholar
  37. A. Weiß and G. Santiago, “Approach and refinement strategies for flexible choreography enactment,” OTM “Confederated International Conferences” On the Move to Meaningful Internet Systems, pp. 93–111, 2014. View at Google Scholar
  38. L. Leite, C. E. Moreira, D. Cordeiro, M. A. Gerosa, and F. Kon, “Deploying large-scale service compositions on the cloud with the CHOReOS enactment engine,” in Proceedings of the 13th IEEE International Symposium on Network Computing and Applications, (NCA '14), pp. 121–128, Cambridge, Mass, USA, August 2014. View at Publisher · View at Google Scholar · View at Scopus
  39. M. Autili, P. Inverardi, and M. Tivoli, “Automated synthesis of service choreographies,” IEEE Software, vol. 32, no. 1, pp. 50–57, 2015. View at Publisher · View at Google Scholar · View at Scopus
  40. D. Krajzewicz, J. Erdmann, M. Behrisch, and L. Bieker, “Recent development and applications of SUMO - Simulation of urban mobility,” International Journal On Advances in Systems and Measurements, vol. 5, no. 3-4, pp. 128–138, 2012. View at Google Scholar
  41. L. Codeca, R. Frank, S. Faye, and T. Engel, “Luxembourg SUMO traffic (LuST) scenario: Traffic demand evaluation,” IEEE Intelligent Transportation Systems Magazine, vol. 9, no. 2, pp. 52–63, 2017. View at Publisher · View at Google Scholar · View at Scopus
  42. M. Cortes-Cornax, S. Dupuy-Chessa, and D. Rieu, “Choreographies in BPMN 2.0: New challenges and open questions,” in Proceedings of the 4th Central European Workshop on Services and Their Composition, (ZEUS '12), vol. 847, pp. 50–57, February 2012. View at Scopus