Prioritization and Selection

5.2 Prioritization and Selection

Considering the analysis on the previous sections, and the constraints of the project with regards to the number of sensors to be deployed and the availability of certain layers – i.e. shopping, tolling, parking – the list of use cases has been arranged by priority on their implementation, in the same way as the use cases in D1.1. [D11].

Thus, the following ordered list should be considered when programming the development of the different components in each of the two prototypes that will be delivered:

1. UC01M: Adaptive trip planner. This is the basic use case describing the first scenario. Even if it describes a complex sequence of actions, all of them should be feasible and achievable by GAMBAS.

2. UC01E: Running with a friend. The basic use case describing the second scenario should also be targeted with the highest priority. The use case itself already addresses the use of the privacy framework to enable the sharing of information.

3. UC02M: Predictive destination. The capability to infer information based on past and current context is analyzed in this use case. This is one of the most critical features to demonstrate the Adaptive Middleware for Behavior-driven autonomous services.

4. UC02E: Pollution map (noise, pollen and CO2 from bus sensors). Once the basic feature of having a smart city layer – i.e. the Environmental System – providing data related to levels of pollution in the city is available, the next step will be to provide the system with services to end-users.

5. UC05.1M: Added value services based on QoS crowded bus metric. In order to provide new added value services to travelers using the Madrid public bus network, one of the most interesting QoS metrics will be the number of passengers per bus. This use case should have nearly the same priority as UC05M. However, UC05.1M will be addressed first since it may need more effort to get completed. In any case, both use cases are independent and can be achieved individually.

6. UC03.1E: Alert of high level of pollen in planned bus route.

Similar to the above use case, this one should have the same priority level as UC03. Current order only responds to the challenge of addressing the most complex use cases first, considering that they would need more time and effort. Again, both UC03.1E and UC03E are independent, and if necessary their order in the list could be altered.

7. UC03M: Demand Response in real time. From the point of view of the public bus operator (EMT), adapting the operations in the network, based on the demand, is critical. It can be address in real time or after a statistical analysis. The most interesting and innovative approach would be to do it in real time.

8. UC2.1E: Pollution map noise detected from mobile devices. This use case presents the same functionality than UC2E. However, the innovation required to implement this use case is much higher, and still under analysis.

9. UC07M: Added value services based on Social Layer. Even if the functionality presented in this use case – i.e. travelling with a friend - is not covered by any of the use cases above, the mechanism enabling such functionality are already addressed in UC02E and UC02M.

10. UC06E: Environmental footprint for Public Transport passengers. Relying on the services and information obtained in other use cases – as UC02E and UC05xM – it will be possible to calculate the individual environmental footprint per passenger, customized to the trip and the number of passenger in the bus.

11. UC05M: Quality of Service indicator through estimation of passengers per bus. From the point of view of the bus operator, the number of passenger in each bus is a valuable metric to increase the quality of the service. The metric itself is calculated by the same mechanism as in UC05.1M, however, the use of this metric is different. Within UC05M, it is the bus operator who will adapt its behavior – operations – in response to the new piece of information.

12. UC03E: Alert of high level of pollen in area. In the same way UC05M address a different user as UC05.1M, this use case is more generic than UC03.1E. Both can be achieved independently.

13. UC04M: Demand desponse from statistics. Adapting the operations of the bus network in reaction to the demand based on statistic is something usual in any public transport exploitation system. However, in the context of GAMBAS, this adaptation will consider new pieces of information coming from the data acquisition framework deployed within the project.

14. UC05E: Public transport incentives depending on pollution levels. This use case, even if it is pretty interesting from the environmental point of view, presents serious handicaps regarding its feasibility in the short term. It would require adapting tariffs and establishing a new business model where the municipality covers the costs of the incentives to public transport users – a sort of shadow tolling.

15. UC01.1M: Adaptive intermodal trip planner. As a natural extension of UC01M, this use case could be implemented if we had a third party offering the intermodal trip planner engine, or at least more than one transport operator. In the context of GAMBAS, the use of Google API will be explored.

16. UC04E: Urban tolling depending on CO2 pollution. The implementation of urban tolling based on CO2 levels is something that has been explored in different cities across Europe. The adaptability in real time of prices and the granularity of the CO2 measurements is however something still under analysis. As in UC05E, 16. UC04E: Urban tolling depending on CO2 pollution. The implementation of urban tolling based on CO2 levels is something that has been explored in different cities across Europe. The adaptability in real time of prices and the granularity of the CO2 measurements is however something still under analysis. As in UC05E,

17. UC01.2M: Adaptive intermodal trip planner with park and ride. Once again, the need of a third party layer is not tackled within GAMBAS, this reduces the priority level of this use case. The use of already existing technology from the PECES project [PECES] will be studied, and if possible adapted to demonstrate this use case.

18. UC04.1E: Alert if urban tolling higher than a certain price in planned route. Even if there is no tolling layer within GAMBAS, as in UC04E, this use case presents a nice challenge involving different services and information.

19. UC06M: Added value services based on shopping layer. Despite the fact that this use case addressed one of the original motivating scenarios, it has been left at the end of the priority list due to the lack of a shopping layer, and the little experience the members of the consortium have on this topic.

In order to guarantee that both scenarios are properly covered, a use case from each scenario should

be tackled alternatively.