Module Interaction Process Clause Samples
Module Interaction Process. Initially, the pre-day models are estimated, which consist of interconnected dis- crete choice models that model individuals’ demand for travels as derived from their needs to perform activities, representing individuals’ choices at several di- mensions. They are estimated for a year of reference based on data from (i) the Danish National Travel survey (TU survey), which encompasses all travels (grouped as tours) performed by each individual during an entire day, (ii) network skims from the Danish traffic model (Landstrafikmodellen), which are level of service matrices describing car and public transport travel times and costs for different time intervals during a day of the reference year and (iii) zone level data, which includes information on area, population and number of jobs of each zone considered in the model. Based on the pre-day models estimated, the pre- day simulator (agent-based demand simulator), generates detailed activity and travel plans for each individual from a synthetic population. The output of the pre-day simulator is a database with daily activity-schedules for everyone in the synthetic population and it serves as input to EGTrain for simulating railway traffic (Table 9). If changes in rail supply are incorporated into the simulation, it will affect public transport level of service (travel times and costs), and consequently, individuals’ choices. New level of service matrices can be generated for rail and aggregated by zones (python script) to serve as an input for a pre-day simulation of the travel demand for the new rail scenario. The pre-day models can also be re-estimated, according to the new rail scenarios.
Module Interaction Process. The software modules will interact at the beginning of the simulation, to allow the instantiation of the control architecture. Then, throughout the simulation, the modules will interact in a closed-loop fashion, similar to the approach introduced in the EU FP7 project Optimal Networks for Train Integration Management across Europe - ONTIME (▇▇▇▇▇://▇▇▇▇▇▇.▇▇▇▇▇▇.▇▇/project/id/285243). In particular, EGTrain shares information on the observed (and/or predicted) train and passen- ger travels. It does so either with a fixed time periodicity, or when a triggering event occurs. Based on this information, the controller makes decisions on the traffic management strategy, and it shares it with EGTrain for implementation. Such closed-loop can be deployed for any time duration, always making decisions based on the latest available information.
Module Interaction Process. The software modules interact at the beginning of the decision-making process and during the process itself. The control module is in charge of triggering ▇▇- ▇▇▇▇ prediction. At the beginning, the demand prediction based on the current TSP and RTTP (Section 5.3.3) is used to instantiate the control architecture. While decisions are made, new predictions are triggered based on new possible RTTPs to assess passenger reactions to traffic management strategies being considered. In particular, the online demand prediction module shares information about the assignment of passengers to individual trains given the timetable represented by an RTTP. Based on this information, the control module includes indicators related to the perceived level of service from the passenger’s point of view in the rtRTMP (Real-time Railway Traffic Management Problem) formulation. The traffic control module includes passenger information at a high level of detail to preserve a high computational efficiency in real-time.