# A Choreography-Based and Collaborative Road Mobility System for L'Aquila City
## 4 Case Study
Before describing the CRMS case study in detail, it is worth mentioning that having a mobility system in its intermediate phase is the best that we can achieve in the partial (and under evolution) execution and infrastructural environment offered today by the L'Aquila city. Furthermore, for the CRMS use case, differently from other INCIPICT use cases, emergency management and disaster recovery issues are left for future work. The CRMS use case includes two choreographies: Eco Driving Planning Application (EDP) and Smart Data Collection Application (SDC). Figure 5 shows EDP choreography specification by using a BPMN2 Choreography Diagram. The application is triggered when driver starts the navigation app, i.e., Driver and inputs the origin and destination information that are then sent to Eco Route Planner (choreography task Get Eco Routes). Starting from this information, Eco Route Planner retrieves a set routes (choreography task Get Routes) and it initiates two parallel flows (see the parallel branch represented as a rhombus marked with a \"+\", with two outgoing arrows, namely a Diverging Parallel Gateway, just after the choreography task Get Routes) to collect, for each route, environmental and traffic information. The resulting information together with the route information are sent to the Driver (choreography task Set Eco Routes). After selecting a route, the driver is notified when new environmental or traffic information is available. This is done through two parallel flows in which Eco Route Planner subscribes to the environmental and traffic information, respectively. An event notifies the availability of new environmental or traffic information for a specific route (see the intermediate event represented as a circle with a triangle inside). Then, the new information is transmitted to the Eco Route Planner that, in turn, sends the related updated route information to the Driver. When the driver reaches the destination, this is notified to the Eco Route Planner (see the intermediate event represented as a circle with two leftwards arrows inside) that unsubscribes to the environmental and traffic information updates. The Smart Data Collection choreography (Figure 6) is a long-running choreography. It is designed to continuously collect environmental and traffic information and use it for fast response upon requesting. The choreography starts with the Viability Control Center sending the area of interest to the Smart Data Collector. From this information, Smart Data Collector starts two parallel executions to retrieve the related environmental and traffic information. In particular, the top-most parallel branch concerns the environmental information. In this branch, the Environmental Information participant receives weather and air quality information after subscribing to it. Environmental Information can possibly unsubscribe from the reception of this information. The bottom-most parallel flow has the same structure. It involves the retrieval of traffic information through the subscription to congestion, accident and road status information. We used the choreographies specification in Figures 5 and 6 to realize a CRMS for the city of L'Aquila, where local municipalities offer a number of publicly available services to be reused. They have been reused--as black-box third-party software--to instantiate the roles of the participants  
Figure 5: Eco Driving Planning choreography. Route Information, Weather, Air Quality, Congestion, Accidents, and Road Status. The other participants had to be developed from scratch, and here our choreography synthesis method comes into play. These participants represent the missing logic to be composed and coordinated with the logic offered by the reused services. As formalized in [20], due to the distributed nature of the system, when realizing all the nested parallel and branching flows specified by the choreography, coding the missing logic by hand and coordinating its interaction with the logic coming from the reused services is non-trivial and error prone.