## 3 A Multimodal Mobility Recommender System for Urban Areas
### Interactions of Software Agents  
Figure 4 depicts a sequence diagram that explains the interactions between two agents and messages exchanged in order to produce a route recommendation for a commuter. In a nutshell, a sequence diagram captures the key objects of the system and exhibits the order of interaction between these objects during collaboration. The first message of the sequence diagram originates from the commuter who submits a journey request to the commuter agent, normally through a mobile app interface, which in turn reads the serialized message and extracts the commuter preferences, including the source, destination, departure time, and ideal modes of commuting (e.g., bus, metro, cycling, and walking). The commuter agent sends these trip details to the route recommender agent, which deciphers the request and calculates a routing solution given the knowledge it holds about the transport network. Finally, the recommended multimodal route is returned to the commuter mobile phone.  
Figure 5 describes the interactions between three agents of the multimodal recommender system and one object outside the system (i.e., urban traffic management and control server) to update the agents' internal state or knowledge base about the current situation of the transport network. This ensures that routing decisions are derived based on the latest status of the transport network. The traffic data fetcher, which plays the role of a sensing agent, requests real-time traffic data, e.g., from the UTMC server, which extracts and processes the raw sensory data and replies with the live traffic status (e.g., traffic density, average travel times, carbon emissions (g/m)) about the urban environment. Next, the traffic data fetcher forwards this information to the respective transport agents, which simulate the physical layers of the network. Only once the traffic updates become available, the traffic data fetcher agent sends these updates to the designated transport agents. Consequently, each transport agent updates its beliefs about the traffic network and its internal costs (i.e., estimated travel time and transport emission). Each transport agent sends a message containing the costs of using the transport segment that it represents to the route recommender agent, which in turn updates a table of journey objects holding the costs of all transport segments of the city being modeled. This table of journey objects is searched to retrieve the fastest or eco-friendliest routes depending on user queries. It is worth noting that this interaction sequence is repetitive. Therefore, the transport agents are updated with the status of traffic conditions every \(\tau\) minutes.  
Figure 4: A commuter journey request message sequence.  
Some notable advantages of our multiagent architecture include flexibility and extensibility. Indeed, the multi-agent architecture can be extended easily with new types of agents to account for other modes of transport (e.g., flight, ferry) or with other agents to optimize travel costs and solutions provided. Our multimodal recommender system can also be adjusted to accommodate any urban city regardless of the complexity of the traffic management system (for example, cities where real-time information is unavailable owing to lack of road monitoring sensors).