D1.2 Theoretical principles and methodological approach of the PHOEBE framework and selection of tools

Deliverable 1.2 Theoretical principles and methodological approach of the PHOEBE framework and selection of tools PHOEBE - PROJECT.EU This project has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement No 101076963 UK participants in Horizon Europe Project PHOEBE are supported by UKRI grant numbers 10038897 (The International Road Assessment Programme – iRAP) and 10056912 (The Floow) The sole responsibility for the content of this document lies with the authors. It does not necessarily reflect the opinion of the European Union. Neither CINEA nor the European Commission are responsible for any use that may be made of the information contained therein. phoebe-project.eu Copyright © by PHOEBE 1 Document Control Page Deliverable number 1.2 Deliverable title Theoretical principles and methodological approach of the PHOEBE framework and selection of tools Deliverable version 3.1 Work Package number 1 Work Package Title PHOEBE Framework - Methodological and technical approach Due date of delivery 31/10/2023 Actual date of delivery 27/10/2023 Dissemination level Public Type Report Editor(s) Amir Pooyan Afghari, Amna Chaudhry, Amir Hossein Kalantari, Shanna Lucchesi, Monica Olyslagers Contributor(s) Amir Pooyan Afghari, Amna Chaudhry, Amir Hossein Kalantari, Shanna Lucchesi, Monica Olyslagers, Marcel Sala, Antonio Pellicer, Arunava Putatunda, Christelle Al Haddad, Constantinos Antoniou, Apostolos Ziakopoulos, Maria Oikonomou, Sam Chapman, Eleonora Papadimitriou Reviewer(s) EIRA, UPV Project name Predictive Approaches for Safer Urban Environments Project Acronym PHOEBE Project starting date 01/11/2022 Project duration 45 months Rights PHOEBE consortium phoebe-project.eu Copyright © by PHOEBE 2 PM efforts per beneficiary that contributed to the deliverable # Partner PM effort in the Deliverable 1 TUD 5.00 2 NTUA 0.50 3 TUM 3.75 4 iRAP 1.00 5 AIM 1.53 6 FLOOW 1.36 7 POLIS 0.01 8 EIRA 0.05 Total PHOEBE Consortium 13.20 phoebe-project.eu Copyright © by PHOEBE 3 Document History Version Date Beneficiary Description 0.1 06/07/2023 Amir Pooyan Afghari & Eleonora Papadimitriou (TUD) Outline of the Deliverable structure and draft overview and behavioural models 0.2 29/08/2023 Amna Chaudhry, Amir Hossein Kalantari, Amir Pooyan Afghari (TUD) Apostolos Ziakopoulos & Maria Oikonomou (NTUA) Arunava Putatunda, Christelle Al Haddad, Constantinos Antoniou (TUM) Shanna Lucchesi, Monica Olyslagers & James Bradford (iRAP) Antonio Pellicer & Marcel Sala (AIM) Sam Chapman (FLOOW) Input for the different sub-chapters, namely: Road safety assessment (iRAP), Traffic microsimulation (AIM), Behavioural models (TUD), Mode choice and modal shift (TUM), Socioeconomic impacts (TUM), Consolidation of the framework (NTUA), Selection of tools (iRAP) 1.0 26/09/2023 Amna Chaudhry, Amir Hossein Kalantari, Amir Pooyan Afghari (TUD) First draft of the complete deliverable shared with contributing partners 1.1 02/10/2023 Amna Chaudhry, Amir Hossein Kalantari, Amir Pooyan Afghari (TUD) Final draft of the complete deliverable with comments from all partners addressed Executive summary and conclusions of the Deliverable, proofreading, consolidation of final draft for internal review (by EIRA, UPV) 2.0 25/10/2023 Amna Chaudhry, Amir Hossein Kalantari, Amir Pooyan Afghari (TUD) Updated version of the deliverable with comments from internal reviews addressed and sent to all partners for last check before submission 2.1 26/10/2023 Arunava Putatunda (TUM) Additional input provided and comments addressed by all partners in the different sub-chapters 3.0 27/10/2023 Amna Chaudhry, Amir Hossein Kalantari, Amir Pooyan Afghari (TUD) Final document 3.1 30/10/2023 Amir Pooyan Afghari, Amna Chaudhry (TUD) Progress beyond the state of the art added to the final document phoebe-project.eu Copyright © by PHOEBE 4 Project summary The EU-funded ‘Predictive Approaches for Safer Urban Environment’ (PHOEBE) project aims to develop an integrated, dynamic human-centred predictive safety assessment framework in urban areas. This will be achieved by bringing together the interdisciplinary power of traffic simulation, road safety assessment, human behaviour, mode shift and induced demand modelling and new and emerging mobility data. Focused on vulnerable road users' safety, the 3.5-year-long PHOEBE project will draw inspiration from real-world scenarios in the three pilot cities of Athens (GR), Valencia (ES) and West Midlands (UK). Testing activities will be performed across the use cases to simulate and forecast the impact of changes on safety in different scenarios of disruptions or transitions across urban transport networks. Predicting and visualising the safety and socioeconomic outcomes of new forms of transport, new technologies, or regulatory and behavioural changes from the individual (micro) level up to the networkwide (macro) level will also be a significant game-changer for urban stakeholders. The results of PHOEBE can be used as a blueprint by other European cities to develop their knowledge products, such as socioeconomic analysis model, urban road safety assessment, human behaviour and choice modelling. phoebe-project.eu Copyright © by PHOEBE 5 PHOEBE pilot cities List of participating cities: • Athens (Greece) • Valencia (Spain) • West Midlands (United Kingdom) Social Links: https://twitter.com/Project_PHOEBE https://www.linkedin.com/company/phoebe-project/ https://www.youtube.com/@phoebeproject For further information please visit WWW.PHOEBE-PROJECT.EU phoebe-project.eu Copyright © by PHOEBE 6 Project partners Organisation Country Abbreviation EVROPSKI INSTITUT ZA OCENJEVANJE CEST - EURORAP SI EIRA ETHNICON METSOVION POLYTECHNION EL NTUA TECHNISCHE UNIVERSITEIT DELFT NL TUD TECHNISCHE UNIVERSITAET MUENCHEN DE TUM AIMSUN SLU ES AIM POLIS AISBL BE POLIS FACTUAL CONSULTING SL ES FC UNIVERSITAT POLITECNICA DE VALENCIA ES UPV OSEVEN SINGLE MEMBER PRIVATE COMPANY EL O7 THE FLOOW LIMITED UK FLOOW INTERNATIONAL ROAD ASSESSMENT PROGRAMME UK iRAP phoebe-project.eu Copyright © by PHOEBE 7 List of abbreviations and acronyms Acronym Meaning AADT Average annual daily traffic ADC Average difference of cost ADE Average difference of unit of effectiveness API Application programming interface AV Automated vehicle BCR Benefit-cost ratio CBA Cost-benefit analysis CF Calibration factor CEA Cost-effectiveness analysis CMF Crash modification factor DR Deceleration rate EVT Extreme value theory EAI External agent interface FHWA Federal Highway Administration (US) FSI Fatal and serious injury GTFS General transit feed specification ICER Incremental cost effectiveness ratio KPI Key performance indicator LMV Light mobility vehicle (micro-mobility) LOC Loss of control (crash type) ML Machine learning NPV Net-present value OSM Open Street Map PET Post-encroachment time PR Percentage reduction SEA Socio-economic analysis SEM Structural equation model SSM Surrogate safety measure SRS Star Rating score TD Travel diaries TTC Time to collision ViDA iRAP’s computational platform VoI Value of injury VoSL Value of statistical life VoT Value of time VRU Vulnerable road users WTP Willingness-to-pay phoebe-project.eu Copyright © by PHOEBE 8 Table of Contents Executive summary ................................................................................................................................... 12 Progress beyond the state of the art ......................................................................................................... 14 Structure of the deliverable and links with other work packages/deliverables ...................................... 14 1 Theoretical principles & methodological approaches ........................................................................ 16 1.1 Research questions and objectives ......................................................................................... 16 The How Matrix explained ................................................................................................... 19 2 The PHOEBE Framework.................................................................................................................. 21 2.1 Overview................................................................................................................................... 21 Step 1 – Baseline calculations ............................................................................................. 23 Step 2 – scenario change calculations ................................................................................ 24 Step 3 – Socioeconomic analysis ........................................................................................ 25 2.2 Demand models ....................................................................................................................... 29 Processes ............................................................................................................................ 30 Data ...................................................................................................................................... 30 Theoretical basis .................................................................................................................. 35 Model testing ........................................................................................................................ 37 2.3 Traffic microsimulation ............................................................................................................. 37 Processes ............................................................................................................................ 39 Models in traffic simulation................................................................................................... 40 Data ...................................................................................................................................... 40 Model testing ........................................................................................................................ 41 2.4 Behavioural models .................................................................................................................. 42 Processes ............................................................................................................................ 42 Data ...................................................................................................................................... 44 Models .................................................................................................................................. 44 Model testing ........................................................................................................................ 45 2.5 Road safety assessment .......................................................................................................... 46 Data ...................................................................................................................................... 46 Models and processes ......................................................................................................... 50 Model testing ........................................................................................................................ 54 2.6 Safety indicators and dynamic risk outputs .............................................................................. 54 Taxonomy of safety (risk) indicators .................................................................................... 56 Risk indicators in traffic microsimulation .............................................................................. 58 Dynamic safety (risk) indicators ........................................................................................... 60 phoebe-project.eu Copyright © by PHOEBE 15 The extent of the details covered in this deliverable are related to the overall methodology of the PHOEBE framework meaning that the description within the deliverable primarily covers the theoretical details on the methods/models under each component within the framework along with their interaction with each other. The details on how different methods/models within each of the above components will be practically implemented in the relevant tools (e.g. AIMSUN microsimulation and iRAP road safety assessment), will be provided in PHOEBE Work Packages 3 (Model development and enhancement) and 4 (Safety use-case implementation). Finally, it is worth mentioning that the PHOEBE methodological framework (the ‘HOW’ matrix together with the process flowchart) serves two purposes: (i) to be a new research and development (R&D) framework that advances the state-of-the-art and can be used by other researchers and scholars for dynamically performing the road safety assessments through integrating the existing, emerging, and future changes within the demand models, traffic microsimulation, behavioural models, and road safety assessment models; and (ii) to be a “blueprint” for how cities can establish and apply the predictive safety assessment framework efficiently and cost-effectively, providing a practical guide on how it works and how to implement it through the knowledge products such as socioeconomic analysis model, urban road safety assessment, human behaviour and demand modelling. phoebe-project.eu Copyright © by PHOEBE 16 1 Theoretical principles & methodological approaches 1.1 Research questions and objectives The PHOEBE Framework is a methodological approach designed for cities to better understand the future safety implications of changes in the transport systems, such as changes in road user behaviours, the redesign or creation of new infrastructure, or the introduction of a new mode. It aims to be a “blueprint” for how cities can establish and apply the predictive safety assessment framework efficiently and costeffectively. To do so, it aims to bring together several existing elements currently used in transport planning, assessment and modelling, including: • Travel demand and mode shift models, which can predict consumer choices and road user flow changes; • Traffic simulation environments, which provide insights into how these various elements interact in virtual traffic scenarios; • Human behaviour models which can help anticipate how road users respond in given scenarios, and the extent to which they may deviate from typical behaviours; • Road safety assessment, which can provide objective measures of road user safety linked to speed, flow and the physical road features; and • Socio-economic impact assessment which can understand the health, safety, economic and environmental impacts of changes in the transport system. The PHOEBE Framework brings these elements together to enable analysis on the combined effect of future changes, as well as how they evolve over time. The development of the PHOEBE Framework involves three principal aspects: 1 The theoretical developments, which includes the research, where necessary, for key principles and methodology of the Framework. These include, for example, how forecast safety impacts can be extrapolated across a city-wide network. 2 The technical developments required to ensure that each component of the Framework has the necessary functionality to produce the analysis required. This includes, for example, the model developments to allow safety ratings to be incorporated into traffic simulation. 3 The tools and materials required for the use and exploitation of the Framework for its intended end users, to ensure the Framework can be utilised for its stated purpose and meet its desired objective. The PHOEBE Framework thus needs to ultimately be a practical guide on how it works and how to implement it. This deliverable is the output of the PHOEBE Project Tasks 1.2 (proposition for the dynamic risk assessment methodology), 1.3 (socioeconomic analysis methodology) & 1.4 (technical development preparation). It aims to address how the following research and technical aspects required for the development of the PHOEBE Framework will be achieved, namely: phoebe-project.eu Copyright © by PHOEBE 17 • How to model mode shift and induced demand for new modes of transport and extrapolate it to network-level; • How to integrate vrus into traffic microsimulation environments, more accurately and more comprehensively (in terms of their safety); • How to incorporate the pertinent behavioural models into traffic microsimulation environments; • How to make use of traffic microsimulation and create suitable safety indicators for the creation of dynamic safety outputs in road safety assessment; • How to conduct a socio-economic analysis of the safety impacts; and • How to determine the technical methods, resources and tools needed to deliver the technical aspects of the project and achieve the integration of the above aspects (including technical specifications and related inter-dependencies). It is important to note that while the research and development part of the Framework may include a broad range of data/models for each of the five components in PHOEBE, not all of them may ultimately be implemented in PHOEBE. Only those that are relevant and feasible (particularly with an eye on the use case needs) will be implemented. Figure 1-1 shows how the different elements of the PHOEBE are linked with one another in an integrated framework. Figure 1-1 The dynamic dimension of the PHOEBE framework phoebe-project.eu Copyright © by PHOEBE 18 As discussed in the state-of-the-art and end user needs review report of PHOEBE (Deliverable 1.1), the PHOEBE Framework spans different levels of analysis (micro-, mesoand macroscopic). Figure 1-2 shows, conceptually, how each element connects with these levels. Figure 1-2 The multilevel dimension of the PHOEBE framework As the PHOEBE Framework works to systematise the integration of these elements, the project team has identified several focus questions to guide its research and technical developments. These are: • What information needs to be provided by mode share and induced demand models to inform the dynamic simulation framework? How can changes in demand or new modes be modelled? • What are the entry points of traffic simulation models to receive input for the dynamic risk assessment – how can induced demand and behavioural models be introduced into traffic simulation? • How can new modes of transport and other intervention scenarios in urban areas be modelled in traffic simulation environments? • What behavioural models are best suited for considering the most critical behaviours of road users with potential safety impacts? How can behavioural changes be linked to safety outputs? • How can road safety assessment be calculated ‘dynamically’, that is, for different traffic speeds and flows over the course of a day? • How can the finer spatial dimensions of traffic simulation be integrated with the mesoscopic safety assessment from road safety assessment models? • What safety indicators are needed to estimate socio-economic impacts of policies and changes in the transport network? How can the PHOEBE Framework provide these indicators? phoebe-project.eu Copyright © by PHOEBE 19 To address the questions, it is necessary to understand the required data, models and processes that are within each element that make up the PHOEBE Framework, as well as the relationship between the components. This includes: the input data and entry points; all models to be applied on the data coming through those entry points; and the outputs of those models. To assist with this, a matrix in Figure 1-3 maps the targeted data, models and processes into the five main components of PHOEBE: demand models, traffic microsimulation, behavioural models, road safety assessment and socio-economic impact assessment. The matrix is reinforced by the analysis scale in each component (micro, meso and macro). Figure 1-3 The “how” matrix of data, models and processes in PHOEBE methodology The matrix shows how each component is interrelated with other components (i.e., what inputs it receives from other components, what models it applies on those inputs, and what outputs it gives to other components) and how the predictive safety assessment moves from micro to meso to macro scales of analysis and the other way around (i.e., scalability). Hence, the matrix is referred to as the How Matrix. The How Matrix explained Starting from the top left cell in the matrix, the demand models take several inputs as explanatory variables to compute travel demand and provide this demand in terms of OD matrices and mode choice probabilities to traffic microsimulation (PDM12). In return, traffic microsimulation provides updated inputs or explanatory variables due to the changes to the demand models to re-calculate the travel demand, including the induced demand (PDM21). This back and forth giving and receiving occur for other components in PHOEBE too. However, there may be no direct exchange between some components in the framework. For example, demand models will phoebe-project.eu Copyright © by PHOEBE 20 not directly provide any inputs to behavioural models, road safety assessment and socioeconomic impact assessment and hence the corresponding cells in the matrix (PDM13, PDM14 and PDM15) are greyed out. Traffic microsimulation provides surrogate safety measures as proactive indicators of safety to behavioural models (PDM23) and dynamic flow and speed to road safety assessment (PDM24). There is no direct link between traffic microsimulation and socioeconomic impact assessment (PDM25 and PDM52), or between behavioural models and socioeconomic impact assessment (PDM35 and PDM53). While behavioural models will not give any direct input to demand models (PDM31), they provide traffic microsimulation with the likelihood of road user behaviours (PDM32) and road safety assessment with behavioural FSI values (PDM34). Road safety assessment is the only component in PHOEBE that will give input to all other components. It will provide static safety assessment of roads (for example, risk scores) to demand models (PDM41), traffic microsimulation (PDM42), and behavioural models (PDM43). It also provides the socioeconomic analysis with final FSI estimations (PDM345) based on dynamic safety assessment. In return, the socioeconomic analysis will give the overall impact assessment back to the demand models (PDM51) to adjust the demand after an intervention has been implemented. In the following sections, details of the above data (input and output), models and processes in each component are explained, and the inter-relationship between the cells in the How Matrix are then discussed. The result of consolidating the data, models, processes and the inter-relationship between PHOEBE components is then the integrated scalable framework. phoebe-project.eu Copyright © by PHOEBE 21 2 The PHOEBE Framework 2.1 Overview The PHOEBE Framework assembles existing tools and models in such a manner that, with the required amendments to their inputs and outputs, they can exchange information to forecast the impacts on road safety more precisely, with emphasis on vulnerable road users (VRU). In addition to the research and technological developments required to connect the PHOEBE Framework elements, the incorporation of VRU into some of these elements requires dedicated attention. 1 Figure 2-1 shows in detail how these interconnections work. It is important to note it does not delve into the particularities of each component. These particularities will be discussed in the following sections. The input data within each component include necessary data from external sources and from other components within the PHOEBE Framework. Although depicted in Step 1, the external data inputs are assumed to be available, collected, cleaned and standardised before the process start (as in any typical road safety evaluation/calculation process). Specifically, the data inputs for each component (from outside the other PHOEBE components) include the following: 1 Data for road safety assessment includes that relevant to prediction of future crashes such as historic crash data, operational traffic flow data (speeds, flows or similar – e.g. occupancies), geometrical and infrastructure/network characteristics data such as the number of lanes on the roads, presence of cycle lanes, pedestrian crossings, bus stops, traffic signals etc. 2 Data for mode choice and induced demand models includes that relevant for mode choice and travel demand modelling, such as socio-demographic data, land-use data, network data, data from origin-destination (OD) surveys, etc. 3 Data for the behavioural modelling requires human factors based behavioural data, such as counts of specific behavioural instances (e.g. distraction, speeding illegal crossings), related geometric, network & infrastructure data, relevant crash data and pertinent survey data. 4 Data for the traffic microsimulation includes that needed for modelling the study area including network characteristics (geometric layout, transport features (e.g. pedestrian crosswalks, functional attributes, configurations, etc.), traffic demand and compositions, traffic control data, vehicular kinematics, etc. 1 VRU-specific aspects are present in all elements, such as behavioural modelling, traffic simulation and road safety analysis (especially with surrogate crash measures). However, the VRU particularities, in data and real conditions, will be handled internally as they are encountered within each of the elements and are not discussed here. phoebe-project.eu Copyright © by PHOEBE 22 Figure 2-1 The PHOEBE Framework flowchart phoebe-project.eu Copyright © by PHOEBE 23 It should be noted that overlap exists across the data needs of each element. The similarities in data types can often serve for validation across data sources, and verification that the same areas are described with the same signs and magnitudes across databases (e.g. for geometric data). In latter stages of the Framework, the sources that are deemed as most accurate and most complete will be selected and used exclusively, while the others will be retained for comparison and reference purposes in data frames. The following sub-sections further provide a summary of the individual steps within the framework, the components involved, and their interaction with each other while sections 3 and 4 delve into more theoretical details on the models within each component as well as the input-output flow from one to the other component within the framework. The details of how the models will be implemented in the respective tools (i.e. AIMSUN microsimulation and iRAP road safety assessment) will be covered in WP3. Finally, the PHOEBE predictive safety assessment framework will measure the impacts (KPIs) over the present or a baseline year and in future after implementing the changes, over some time frame (e.g. in 5, 10,15 years, or longer time period), to account for the changes in the network through introduction of interventions, regulations, behaviours, or new technologies etc., and even if there are no such changes, to simply account for the naturally occurring changes in future such as through the population growth or travel patterns. Historical trends such as population growth, tourism growth, pre-existing trends in mode choice and/or travel patterns, land use changes, etc. can be used for baseline forecasts. For projections in any future baseline scenario, an annual multiplier factors based on historical data or estimates will be required. Consideration must be given to any skewness in the data due to any reasons e.g. impact of the global pandemic. The precise forecasting or planning horizon will be decided later in forthcoming work packages (WP3 and WP4). Step 1 – Baseline calculations The purpose of Step 1 in the flowchart is to accurately capture the existing baseline scenario (the current situation). The baseline scenario is the reference point against which the impact of any future changes can be compared (Figure 2-2). Step 1 Baseline scenario (without any changes) Figure 2-2 The PHOEBE Framework flowchart – Step 1 phoebe-project.eu Copyright © by PHOEBE 24 In this step, data passes between each of the elements as follows: • Road safety assessment provides static road safety crash risk and crash occurrence estimates by segment to the mode choice and behavioural modelling. • Mode choice modelling (incl. induced demand) provides mode choice probabilities and behavioural modelling provides probabilities of specific behaviour occurrence to traffic microsimulation. • After the traffic microsimulation runs, the traffic microsimulation provides simulated trajectories of the road users which (through post-processing in a surrogate safety assessment model) provides number of conflicts to the behavioural modelling. It also provides flow and speed data to road safety assessment. • The behavioural modelling provides the fatal and severe injury (FSI) calibration parameters to road safety assessment for calculating the updated safety ratings (Star Ratings) for variable speed and flows (“dynamic Star Ratings”). • Road safety assessment provides updated Star Ratings per segment to the traffic microsimulation for visualisation of dynamic risk. • The core outputs from Step 1 of the PHOEBE Framework are the KPIs received from the traffic microsimulation and road safety assessment to be used for scenario comparison. Step 2 – scenario change calculations In Step 2, road safety (or other transport-oriented) changes are assumed to have been implemented in the study areas. Step 2 receives inputs comparable to those of Step 1 to conduct the necessary calculations for the KPIs after taking the specific changes (e.g. infrastructure, regulatory, behavioural, etc.) into account (Figure 2-3). Step 2 New scenario (with changes) Figure 2-3 The PHOEBE Framework flowchart – Step 2 phoebe-project.eu Copyright © by PHOEBE 31 When compared to the baseline scenario, the mode choices of different scenarios produce an important indicator called mode shift. The relevant inputs and outputs (data) of the mode choice modelling process are listed and described below (Department for Transport, 2014; Ortúzar & Willumsen, 2014). 2.2.2.1 Input data The demand or mode choice models are sophisticated discrete choice models (statistical models) that can predict the mode choices and mode shifts. Three modelling steps are carried out to develop these models: model estimation, calibration, and validation (Department for Transport, 2020a). Specific data are used as input data to develop such discrete choice models (Department for Transport, 2020b; D. A. ; Hensher & Button, 2008; Ortúzar & Willumsen, 2014). This data is termed input data and are typically of the following types: (Socio-)demographic data: Demographic or sociodemographic data are the most crucial input dataset in demand modelling. This data provides essential information regarding the demography of the region under consideration, e.g., household structures, employment status, trip generation rates, car/other modes of transport ownership and availability trends, socioeconomic structure, and license holding (Department for Transport, 2020a), as depicted in the following Figure 2-6. Figure 2-6 Sociodemographic data input requirements for demand models Source/s: This data can be obtained from the regional or national census data, national travel surveys, or specialised local household (travel) surveys can be set up, especially for this purpose. Land-use data Land-use data ties the population data to the geographical dimension and enables the calculation of the trips spatially for doubly (work, education) and singly (shopping, leisure) constrained purposes for the considered person groups. Source/s: This data can be obtained from the regional or national census, workplace statistics, and local authority planning data for residential, employee, retail, and commercial floorspace by zone. Network data Network data refers to datasets encompassing details of the network or the transport supply side. It provides the utilities, such as time, distance, etc., for the demand calculations. It also provides inputs about an essential mode of transport, e.g., frequency and headways of public transport, as well as road safety assessment risk scores. Source/s: This data can be obtained from Open Street Map (OSM) and local public transport service providers. Often, public transport data are available in the form of GTFS datasets too. Road safety phoebe-project.eu Copyright © by PHOEBE 32 assessment risk scores (including pre-existing data) can be derived from the existing road safety assessment tools for any region of interest. Travel to zonal destinations by Purpose, Mode, and Time of Day (Period) These datasets provide the trends concerning the destinations and the purpose of the trips, mode choices, and the times and costs of the trips. These trends are used to estimate the mode choice models. Thus, these datasets are considered critical for estimating the mode choice models. Source/s: Principally specialised surveys, including the stated preference surveys and revealed preference. It can also be collected from sources, e.g., roadside interviews, mobile network data, automatic number plate recognition, and local/national/regional household travel surveys. Travel diaries (including longitudinal travel diaries) are also used to gather this data. Explainer notes Stated preference surveys (SP) The SP survey (the Contingent Valuation) is a technique for establishing valuations between alternatives. The subject is asked to choose between policies, products, or services with desirable and undesirable characteristics. In doing so, they indirectly reveal which parts are most important to them. SP surveys are instrumental in cases without real-world data to make conclusions. In the following steps, detailed stated preference surveys will be designed and disseminated among the subjects of pilot cities (use cases) to collect the SP data. The SP data will facilitate the processes of the suitable demand model class choice and the estimation of the chosen models. Revealed preference data (RP) The RP data assumes consumers' purchasing (demand) habits reveal their preferences. RP data will be gathered from several sources, e.g., the actual purchase data (e.g., ticket purchases) and consumption or demand data (e.g., actual travel demand counts). The RP data will facilitate the demand model choice, estimation, and validation of the chosen demand models (mode choice models). (Longitudinal) Travel diaries (TD) Longitudinal travel diaries are records to study and track individuals' travel patterns and behaviours over an extended period. Unlike regular travel diaries that keep records for a specific period, i.e., a day or a week, longitudinal travel diaries collect information over several weeks, months, or years. Longitudinal travel diaries are a type of revealed preference survey. Thus, these data sources will capture the actual behaviour and choices of the respondents for specific contexts. Trip lengths and times Trip lengths and trip times are specialised datasets used indirectly in the mode choice model development process. This data is not used during the model estimation but in the model validation process. Trip lengths and times are often used with their spatial, temporal, and purpose contexts, i.e., in conjunction with the origin-destination, origin-destination times, and purpose of the trips. Source/s: The local/regional/national household travel surveys are the chief sources of these datasets. In addition to these surveys, (longitudinal) travel diaries are also considered rich data sources. Vehicle occupancies Vehicle occupancies across all the person groups, purpose, and mode segments are noteworthy datasets used in demand modelling processes. These datasets are utilised to estimate the number of vehicles moving in the network. In addition to the number of vehicles, these datasets are also used to estimate the transport performance (subsequently the KPIs, e.g., emissions, consumptions, etc.) of the different modes of transport. phoebe-project.eu Copyright © by PHOEBE 33 Data sources: The local/regional/national household travel surveys are the chief sources of these datasets. In addition to these surveys, (longitudinal) travel diaries are also considered. Vehicle operating costs (generalised costs) and Value of Time (VoT) The vehicle operating costs and the generalised costs of vehicle operation for different person groups and purposes of trips and the VoT are used to estimate the impedances arising while making trips between the origin-destination pairs in the demand modelling process. Source/s: The vehicle operating, generalised costs, and the VoT are generally provided by local planning and statistical authorities. These values can also be estimated from the "travel to zonal destinations by Purpose, Mode, and Time of Day (Period)" datasets. Table 2-1 lists all the required data and their probable sources for demand modelling. Table 2-1 Demand modelling data requirements and their sources Nr. Main dataset Sub dataset To be used in Sources 1 Population Household structure Employment status Trip generation rates Trip generation rate calculations Socioeconomic and person group categorisation Mode split distribution Regional or national census data National travel surveys Specialised local household (travel) surveys 1.1 1.2 1.3 1.4 Socioeconomic structure License holding Cars and other modes of transport availability 1.5 1.6 2 Land-use data Trip generation Trip distribution Traffic Analysis Zone demarcation Regional or national census Workplace Statistics Local authority planning data 3 Network data Utility calculations Incorporation of transport supply side in calculations Open Street Maps (OSM) Local authorities and public transport service providers 4 Travel to zonal destinations by Purpose, Mode, and Time of Day Trip generation Trip distribution Time period choice Ascertaining trends Specialised travel surveys including stated preference surveys. Revealed preferences Travel diaries 5 Trip lengths and times Model calibration Model validation Specialised travel surveys Travel diaries 6 Vehicle occupancies Estimation of the number of vehicles Specialised travel surveys phoebe-project.eu Copyright © by PHOEBE 34 Nr. Main dataset Sub dataset To be used in Sources Estimation of transport performances Estimation of KPIs, e.g., emissions, consumptions etc. Travel diaries 7 Vehicle operating costs (generalised cost) and Value of time (VoT) Estimation of utilities and disutilities. Estimation of impedances. Local planning and statistical authorities Travel surveys Travel diaries 2.2.2.2 Output data The demand model generates specific output data. The main outputs are described as follows. Estimated mode choice probabilities Mode choice probabilities, as the outputs of a mode choice model, represent the likelihood or probability that a group of individuals will choose for a specific purpose, a specific transportation mode (such as walking, bike, car, or public transit) among the available options for a given trip, based on their characteristics and the attributes of the modes. These probabilities add up to 1 (Figure 2-7), indicating that one of the modes will be chosen for the trip. These probabilities are essential in understanding and predicting mode choices in travel demand modelling. A higher probability for a particular mode suggests that the model predicts a greater likelihood that individuals will choose that mode for the given trip, considering the specified factors and attributes. Figure 2-7 Mode choice probabilities phoebe-project.eu Copyright © by PHOEBE 35 Estimated mode splits Individual mode choice probabilities associated with specific modes of transport can be interpreted as mode split amongst all the available modes. Mode split can be further used to generate mode shift. Mode shifts A change in the input variables of the mode choice models, e.g., travel time, cost, etc., will develop a new mode split or mode share; thus, the baseline mode share can be compared with the new share to calculate mode shift. Estimated OD movements (trips) matrices including the induced travel demand The mode share or split can be used to generate the OD movements in terms of the trips categorised by modes of transport. These trip matrices can be derived by multiplying the OD trip matrices obtained from the trip distribution calculations with the mode choice probabilities. In addition to the regular OD matrices, the (discrete choice) model estimated for forecasting the induced demand will also generate the OD matrices of the induced travel demand in terms of the number of new trips added due to the changes introduced (Kalliga, 2021). Demand elasticities For a given scenario (i.e., a different set of input variables compared to the baseline situation), the outputs of the mode choice models can be used to generate demand elasticities. These demand elasticities help understand the changes of the dependent variables under the changing magnitude of the independent or explanatory variables. 𝑒 =log(𝑇1)−log(𝑇0) log(𝐶1)−log(𝐶0) (2-1) Where, 𝑒 is the elasticity, 𝑇 is the demand with superscripts 0 and 1 indicating the values before and after the change of cost, 𝐶 is the cost with superscripts 0 and 1 indicating the values before and after costs. Theoretical basis In PHOEBE, the development of suitable discrete choice models is envisioned for large-scale forecasting of the mode shift (M. E. Ben-Akiva & Lerman, 2006). The estimation of more complicated models, such as hybrid class models (models with latent variables) and latent class choice models are also envisioned to forecast specific entities such as experience and effects of external factors like real-time information flows through the internet and apps. These models will be developed as per the three steps (estimated, calibrated, and validated). The relevant parts of such models will be considered in the project's discrete choice model, which will be planned for large-scale forecasting. The primary aims of the choice model development are listed below: 1 Forecasting the large-scale mode choice and mode shift by different person groups (BenAkiva & Lerman, 2006; Domencich & McFadden, 1975); 2 Incorporating various modes of transport in the model (Domencich & McFadden, 1975); 3 Incorporating specific intangible properties in the form of input (latent) variables in the model (Motoaki & Daziano, 2015); and phoebe-project.eu Copyright © by PHOEBE 36 4 Incorporating the latent class choice models to capture observed and unobserved heterogeneity. These models can relate a set of observed discrete multivariate variables to a set of latent variables (variables that are not directly observed but are rather inferred) (GarcíaMelero et al., 2022; Lee et al., 2003). Most of the modelling process depends on the input data (explained in the preceding sections) and the SP/RP surveys. The final model type and modelling processes will be thus finalised after the completion of the input data collection, including the completion of the SP/RP surveys. A generalised model representation is given below: Explainer notes Generalised discrete choice model for forecasting mode choice (Ben-Akiva & Lerman, 2006) A discrete choice model works within the foundational assumption of rational choices the individual (groups) makes when confronted with a discrete set of alternatives to maximise their benefit or utility. The discrete choice evaluates the input or explanatory variables concerning the characteristics of the user groups and the available alternatives. The choice is expressed in terms of probability. The generalised form of the discrete choice model is presented below: 𝑃𝑖𝑗 =𝑓(𝑆𝑖,𝑋𝑗) (2-2) Where, 𝑃𝑖𝑗 selection or choice probability of mode (alternative) 𝑗 by a person group 𝑖. 𝑓 Decision function (discrete choice function) 𝑆𝑖 set of characteristics of the person group 𝑖, e.g., workers, students etc. 𝑋𝑗 set of characteristics of the alternatives (modes of transport, e.g., car, bike) 𝑗, e.g., cost, time.etc. The set of characteristics 𝑺𝒊 and 𝑿𝒋 (Ben-Akiva & Lerman, 2006) The set of characteristics, namely 𝑆𝑖 and 𝑋𝑗, can be encapsulated under a single terminology commonly known as utility (𝑈). It can be defined as the attractiveness of each alternative that the decision-maker will enjoy if they choose it. A utility has two components, namely: ● Systematic or measured utility, also known as deterministic utility (𝑉). ● Stochastic/random component (𝜀). As shown below, the total utility is expressed by adding these two utility types. 𝑈 =𝑉+𝜀 (2-3) The deterministic utility (𝑉) contains the explanatory variables that can be measured, e.g., Ride time, fare, and number of transfers. The coefficients (𝛽) or the parameters control the sensitivity of the explanatory variables. A generic utility (deterministic) equation is given below: 𝑉𝑗𝑞 =𝛼𝑗𝑞 +𝛽𝑗1.𝑥𝑞1 +𝛽𝑗2.𝑥𝑞2 +⋯ = 𝛼𝑗𝑞 +∑𝛽𝑗𝑘.𝑥𝑞𝑘𝑘 (2-4) 𝑉𝑆𝑡𝑢𝑑𝑒𝑛𝑡𝑠.𝑃𝑇 =1.0+(−0.1).𝑅𝑖𝑑𝑒𝑇𝑖𝑚𝑒+(−0.75).𝐹𝑎𝑟𝑒+⋯ (2-5) Where, 𝑉𝑗𝑞 deterministic utility value 𝛼𝑗𝑞 constant for alternative 𝑞 for group 𝑗 𝛽𝑗𝑘 parameter determining importance of attribute 𝑘 for group 𝑗 𝑥𝑞𝑘 value of attribute 𝑘 for the alternative 𝑞 The decision function 𝒇 (Ben-Akiva & Lerman, 2006) The decision function 𝑓 is also known as the model or choice model class. The type of 𝑓 depends upon the distribution of the stochastical utility 𝜀, e.g., if the 𝜀 is assumed to be independent and identically phoebe-project.eu Copyright © by PHOEBE 37 distributed as an extreme value distribution 𝐸𝑉(0,𝜇) (i.i.d. Extreme Value) 𝑓 is called as logit model. A logit model can be given by: 𝑃(𝑖|𝐶𝑛)=𝑒𝜇.𝑉𝑖𝑛 ∑𝑒𝜇𝑉𝑗𝑛 𝑗𝜖𝐶𝑛 (2-6) where, 𝐶𝑛 a choice set of alternatives with 𝑛 alternatives 𝜇 scaling factor 𝑉𝑖𝑛 deterministic utility of alternative 𝑖 from 𝐶𝑛. The latent variables (Lee et al., 2003) Some phenomena cannot be measured; thus, indirect measurements are used to introduce or incorporate them in a choice model. Often, psychometrics is used to solve these problems. An example of indirect measurements of latent concept is, ease of travelling with a particular mode of transport with children. Such variables are called latent variables and are used to explain the utility function. Thus, the intangible perception can be incorporated into the choice modelling framework. These types of choice models are often termed hybrid choice models. Model testing The demand models' testing sequence for the PHOEBE use cases is described below: • Data collection: Good data source is the most critical component of the model testing. The data come from the SP/RP surveys and other sources, e.g., census data, land-use data, travel diaries, traffic counts, VehKM, and TripKM data. • Model choice: A suitable choice model will be chosen based on the data collected and the requirements of the use cases. • Model estimation: The input variables and other components of the chosen model will be finalised, and subsequently, the model will be estimated with the data from the surveys and the travel diaries. • Model calibration and validation: The estimated model will then be validated, calibrated, and re-validated with the help of real-world count data. This step will provide a demand model for simulating the current or baseline scenario. This model will produce a baseline mode share, which will be used as a reference to generate the mode shift for the planned scenario. • Forecast for the use cases scenarios: According to the particular use case scenario, the input variables of the baseline demand model will change, producing a forecasted mode share. This mode share will then be compared with the baseline mode share to generate the mode shift for the succeeding processes. 2.3 Traffic microsimulation Traffic microsimulation in PHOEBE is a key enabler for combining the input from different components of the PHOEBE framework to simulate and forecast the safety impacts of changes and future scenarios across urban transport networks. Testing in a virtual environment speeds up testing, without the delays of real-world implementations and reduce cost, both social and monetary, and to allow reproducibility and control over experiments that would not be possible in the real world. Microsimulation enables the reproduction of the trajectories of each single road user (pedestrians, bicycles, e-scooters, cars, buses, and others) unveiling their potential unsafe interactions. Leveraging from the power and capabilities of microsimulation to integrate other different models and tools, the PHOEBE framework combines the microsimulation component with mode choice models, human factor phoebe-project.eu Copyright © by PHOEBE 38 based behavioural models, and road safety assessment models, for reproducing more realistic interactions between different road users and consequently improving the assessment framework for road safety in a prospective manner through giving a methodological framework which can be expanded for the inclusion of emerging and future mobility options. Traffic microsimulation modelling starts with a transport road graph which involves developing abstract representation of transport networks that consists of links and nodes. These objects have their own attributes that make each of them unique. When multiple links and nodes are linked together, a representation of the mobility network is achieved. The following are the general requirements to build a microsimulation from scratch. This starts with a network representation for the areas to simulate. A network graph is typically imported from Open Street Map (OSM) and corresponds to 3-dimensional abstract representation of the transport road network. This means having all stationary elements within the road network, enabling the accurate simulation of vehicular movements, such as shown in Figure 2-8 (a). The network model pertains to the depiction of a network employed by microscopic simulation-driven models. This requires more intricate data, including elements such as traffic management strategies, pedestrian walkways, nodes governed by traffic signals, the type of intersection control, capacities, travel demand, and so forth. An example of a network model is illustrated in Figure2-8 (b). a) b) Figure 2-8 Network graph vs. network model a) Network graph in OSM b) Network model in Aimsun Next with traffic lights, tramway and bus schedules, priorities at intersections, etc. After the network is built, the process of calibrating the supply and demand factors is initiated. This is to ensure that the simulation environment represents real traffic conditions and can be used to deploy and phoebe-project.eu Copyright © by PHOEBE 39 assess the changes, within the PHOEBE Framework. The data which are typically required to perform this task include: • Network geometry – Data describing the geometrical aspects of the use case area. • Demand – Data, expressed in number of trips between origin and destination per transportation mode. • Traffic control – Characterisation of traffic control elements like traffic lights. • Transit operation – Data characterising the operation of public transport, such as transit routes, stops, and schedule. • Network traffic state and performance – Data characterising how traffic behaves along roadway elements, such as volumes, speeds, travel times, location of bottlenecks, etc. Data should be collected for all critical time periods being studied, e.g., AM peak, Midday peak, PM peak, weekend. Processes The microsimulation component within the PHOEBE Framework links to other components in the framework, as shown in Figure 2-9 through exchange of several inputs and outputs. To be more specific, the mode choice modelling component provides OD matrices per mode as input to the microsimulation component. It also takes the human factor based behavioural models input from the behavioural modelling component of the framework to represent the driving and walking behaviours of motorised and nonmotorised road users in the simulation model. This means that more realistic driving or walking styles are modelled into the microsimulation environment. With those inputs microsimulation can produce results on variables of interest (KPIs) such as traffic flows per road user type and road segment, travel times, emissions, and many others. The output from microsimulation runs also include individual vehicle / pedestrian trajectories for further processing through a surrogate safety assessment model to identify conflicts, which will be used by the behavioural modelling component for estimating the FSI calibration parameters to be used in the road safety assessment component. In addition, the relevant variables (such as speeds and flows, etc.) from the microsimulation output will also be utilised by the road safety assessment component to calculate the updated risk scores (dynamic) which can then be integrated within the simulation model but only for visualisation purpose. Figure 2-9 Interaction between traffic microsimulation and other components phoebe-project.eu Copyright © by PHOEBE 40 Models in traffic simulation Traffic microsimulation can be overwhelmingly complex and therefore requires a software package that comes with all the necessary features. In general, the models involved are (i) the network representation, which by itself is a model, (ii) the path finding and shortest path models, (iii) demand loading models, (iv) stochastic and random choice models and (v) the models to move vehicles or pedestrians. The last models are the ones to have the greatest impact on safety as they govern the actions of vehicles and pedestrians. Pedestrians are typically modelled by a social force model. On the other hand, vehicular movements are governed by kinematics models commonly known as vehicle behaviour models within microsimulation modelling domain. For example, typically the vehicles move in the longitudinal axis according to a carfollowing model, and through the transversal axis according to a lane-changing model. In some occasions, it is possible to have a 2-D model that combines both to have non-lane-based traffic dynamics. Additionally, there are the gap acceptance models for intersections, which govern the behaviour of vehicles on unsignalised intersections (no traffic lights) and pedestrian decision making at pedestrian crossings. Figure 2-10 illustrates a general modelling flow of traffic microsimulation along with an external control. Figure 2-10 General modelling flow of traffic microsimulation enabling external control Within the context of PHOEBE project, which in addition to combining other models and tools within the framework also involves incorporating human factor based behavioural models in microsimulation models, some external application programming interfaces (APIs) will be used as per the needs, for instance, to reflect the drivers’ characteristics (such age group, gender etc.) and speeding behaviour, based on the human factor based behavioural models (as explained in section 2.4) on a segment in the model. Similar approach will be applied for modelling the unsafe and/or non-complying behaviours of motorised and nonmotorised road users, prioritised within the PHOEBE project. Data Traffic microsimulation can generate vast amounts of data, as data can be gathered for each single simulated object at each simulation step. Typically to avoid being overwhelmed with such vast quantities of data, aggregated KPIs are stored and shown to the end user. phoebe-project.eu Copyright © by PHOEBE 47 2 Observed flows: Motorcycles, bicycles and pedestrians along or crossing observed flows are part of this group. Observed flows are not directly used in Star Ratings. They are used to validate and check road user flow data. 3 Speed limit: Speed limit is collected for general traffic. The speed limit for motorcycles and heavy vehicles may also be collected, but these are used for analytical purposes only (and are not automatically used for Star Rating calculations). Major differences in operating speed or speed limit are recorded, as well as speed management and traffic calming features. 4 Mid-block attributes: Road feature attributes that do not relate to intersections. Includes information about the number of lanes, lane width, curvature (radio and quality), median type, grade, sight distance, presence of lighting and delineation must be recorded. Also includes pavement quality attributes (skid resistance and road condition) as well as the presence of vehicle parking, service roads, and road works along the section. These attributes can be correlated with links in the traffic simulation types of networks. Upgrade costs are also collected to support safer road investment plans (i.e., it is not required for Star Ratings or FSI Estimation models). 5 Roadside attributes: Roadside objects and their distance from the road. Includes road shoulder width and if there are rumble stripes present in the edge lines. 6 Intersection attributes: Features related to intersections, such intersection type (including number of legs, signalisation, turning lanes), intersection quality, connecting road flows, and presence of channelisation and property accesses. 7 VRU features: Features related to pedestrians, bicyclists and motorcyclists, such as sidewalks, bicycle and motorcycle facilities, and road crossings and school zones. Includes area type which influences risk factors and land use which is used to help predict the presence of VRUs. 2.5.1.2 Operational parameters The operation parameters refer to speed and flows of the different road users. This includes vehicle average annual daily traffic (AADT) flow, percentage of motorcycles, pedestrian and bicycle peak hour flows, and operating speeds (85th percentile and mean). More information on the operation parameters can be found in the iRAP Star Rating and Investment Plan Manual. Speeds Speed is an essential attribute within the iRAP protocols. The iRAP Star Rating models use the 85th percentile operating speed and speed limit for determining Star Ratings, while mean operating speed is used to generate FSI Estimations. Traditionally, Star Ratings are based on the larger of the speed limit and the operating speed (85th percentile speed - the speed at or below which 85 percent of all vehicles are observed to travel under free-flowing conditions past a monitored point). The model enhancement as part of PHOEBE will prioritise the operating speeds to allow speed fluctuation along the day. Speed risk factors also inform countermeasure triggers and economic benefits. The speed risk factors work as multipliers for every crash type included in the model, highly impacting the Star Rating Score. Flows The Star Rating models use different flow parameters. They are: Vehicles flows: Vehicle flows are represented by the Annual average daily traffic (AADT). The AADT is used in the calculation of Star Ratings and to estimate the number of fatalities for each 100m segment of road. Higher traffic flows increase a road user’s exposure to certain crash types, such as a head-on phoebe-project.eu Copyright © by PHOEBE 48 collision. Generally, a larger AADT will result in a lower Star Rating and a higher estimated number of fatalities for a 100m segment of road. Motorcyclists and heavy vehicles are counted as the percentage of those types of vehicles in the daily flows. A motorcyclist Star Rating will only be calculated if motorcyclists are present. If the motorcycle % is zero, then no motorcyclist Star Rating will be produced and the estimate of motorcyclist fatalities will be zero. Bicyclists flow: Considers all bicycles, including conventional bicycles and e-bikes, passing through the segment in the peak hour. Bicycle flow is used to estimate the number of bicyclist fatalities for each 100m segment of road. A bicyclist Star Rating will only be calculated if bicyclists are present. If the bicyclist peak hour flow is zero, then no bicyclist Star Rating will be produced, and the estimate of bicyclist fatalities will be zero. Ideally this data will be supplied by the road authority or other relevant organisation. In circumstances where reliable flow data are not available estimates must be made. The process for estimating bicycle flows should follow a similar methodology as for pedestrian flows. Pedestrian flows: Pedestrian peak hour flows are recorded individually for flows along the driver-side, along the passenger-side and across the road. Changes in pedestrian flows do not affect the Star Ratings, though larger pedestrian flows will result in a lower and higher estimated number of pedestrian fatalities. If pedestrian flow across and along the road is zero, then no corresponding Star Rating will be produced and the estimate of pedestrian fatalities will be zero. Ideally, this data will be supplied by the road authority. In circumstances where reliable flow data is not available, estimates must be made. The final peak hour pedestrian flows used in the analysis ultimately need to reflect the specific road environment. Relationships between flows and road attributes can vary significantly between countries and regions. It is therefore good practice to develop a methodology for estimating flows that reflects the specific context of the assessment. 2.5.1.3 Crash data Numbers of fatalities by road user and crash type are used to calibrate the dataset and produce the FSI Estimation and Investment Plan reports in ViDA (The iRAP computational platform for star rating and FSI estimation models). Calibration factors are used to ensure that the total estimated number of FSI on the network is equal to the actual number of FSI on that network. Ideally, crash data for a 3-year period will be supplied by the road authority or another relevant agency, such as police. The fatalities must be distributed into user groups and crash types and inputted as number of fatalities or percentages of the total fatalities. Table 2-2 displays the user groups and the types of crashes for which the information is needed. Table 2-2 User groups and crash types in question User groups Crash types Car occupants Motorcyclists Pedestrians Bicyclists Micro mobility (e.g. e-scooters) Run-off LOC driver-side Run-off LOC passenger-side Head-on LOC Head-on overtaking Intersection Property access Along Crossing intersected road Crossing inspected road Other *LOC: Loss of Control phoebe-project.eu Copyright © by PHOEBE 49 The CycleRAP model will also be used in selected use cases where cyclists and other Light Mobility Vehicle (LMV) users are the primary focus. The data collected for CycleRAP is different to that described above since the assessments are centered on facilities bicyclists and LMV are using which may not necessarily capture from the road network as is in the Star Rating models. 2 However, the two may be used together. Details and specifications for the CycleRAP data can be found at the CycleRAP User Guide. The output data the Star Rating and FSI Estimation models includes: • Crash type scores per road user group (vehicle occupant, pedestrian, bicyclist, motorcyclist); • Star Rating Scores (SRS) and Star Ratings per road user group; • FSI Estimations per road user group and for all road users; and • For CycleRAP, risk scores by crash type (vehicle-bicycle/LMV; bicycle/LMVbicycle/LMV; bicycle/LMV-pedestrian; single bicycle/LMV) and total risk score (combined). The full list of Star Rating and FSI Estimation output data is provided in Table 2-3. Table 2-3 Star Rating and FSI Estimations model output data Users Risk Scores Fatality estimations Star Ratings Vehicle occupants Vehicle SRS Run-Off LOC Driver-Side Vehicle SRS Run-Off LOC Passenger-Side Vehicle SRS Head-On LOC Vehicle SRS Head-On Overtaking Vehicle SRS Intersection Vehicle SRS Property Access Vehicle SRS Total Vehicle SRS Total Smoothed Vehicle Occupant FSI Estimation Run-Off LOC Driver-side per km per year Vehicle Occupant FSI Estimation Run-Off LOC Passenger-side per km per year Vehicle Occupant FSI Estimation HeadOn LOC per km per year Vehicle Occupant FSI Estimation HeadOn Overtaking per km per year Vehicle Occupant FSI Estimation Intersection per km per year Vehicle Occupant FSI Estimation Property Access per km per year Vehicle Occupant FSI Estimation Total per km per year Vehicle Star Rating Raw Vehicle Star Rating Smoothed Motorcyclists Motorcyclist SRS Run-Off LOC Driver-Side Motorcyclist SRS Run-Off Passenger-Side Motorcyclist SRS Head-On LOC Motorcyclist FSI Estimation Run-Off LOC Driver-side per km per year Motorcyclist FSI Estimation Run-Off LOC Passenger-side per km per year Motorcyclist FSI Estimation Head-On LOC per km per year Motorcyclist Star Rating Raw Motorcyclist Star Rating Smoothed 2 Like Star Rating data, CycleRAP data includes facility-related attributes and operational attributes. phoebe-project.eu Copyright © by PHOEBE 50 Users Risk Scores Fatality estimations Star Ratings Motorcyclists (cont.) Motorcyclist SRS Head-On Overtaking Motorcyclist SRS Intersection Motorcyclist SRS PropertyAccess Motorcyclist SRS Along Motorcyclist SRS Total Motorcyclist SRS Total Smoothed Motorcyclist FSI Estimation Head-On Overtaking per km per year Motorcyclist FSI Estimation Intersection per km per year Motorcyclist FSI Estimation Property Access per km per year Motorcyclist FSI Estimation Along per km per year Motorcyclist FSI Estimation Total per km per year Pedestrians Pedestrian SRS Along Pedestrian SRS Crossing Intersecting Road Pedestrian SRS Crossing Inspected Road Pedestrian SRS Total Pedestrian SRS Total Smoothed Pedestrian FSI Estimation Along Driverside per km per year Pedestrian FSI Estimation Along Passenger-side per km per year Pedestrian FSI Estimation Crossing Side Road per km per year Pedestrian FSI Estimation Crossing Through Road per km per year Pedestrian FSI Estimation Total per km per year Pedestrian Star Rating Raw Pedestrian Star Rating Smoothed Bicyclists Bicyclist SRS Along Bicyclist SRS Intersection Bicyclist SRS Run-Off Bicyclist SRS Total Bicyclist SRS Total Smoothed Bicyclist FSI Estimation Along per km per year Bicyclist FSI Estimation Intersection per km per year Bicyclist FSI Estimation Run-Off per km per year Bicyclist FSI Estimation Total per km per year Bicyclist Star Rating Raw Bicyclist Star Rating Smoothed **LOC: Loss of Control SRS: Star Rating Scores Models and processes The Star Rating and FSI Estimation model use an evidence-based, standardised approach. This allows reliability and transferability of the PHOEBE structure to other cities. The first deliverable in PHOEBE (D1.1 State of the art and end-users need) described how the Star Rating, CycleRAP and the FSI Estimations models work and its characteristics that are advantageous to a road safety framework. As part of the PHOEBE Framework, the Star Ratings and the CycleRAP models bring the infrastructure risk component to measure road safety impact. Star Ratings represent a risk to an individual user type (vehicle occupant, motorcyclist, bicyclist, and pedestrian) and is the sum of individual crash type scores phoebe-project.eu Copyright © by PHOEBE 51 (run-off-road, heads-on, intersections and access points, travelling along the road and crossing the road). They are an objective measure of: i. How likely it is that a road crash will occur for an individual road user, based on the speed, volume and physical features of the road; and ii. The severity of the outcome when a crash does occur. The iRAP models consider the contribution of several infrastructure and operational elements described in the previous section and their contribution to one or both previously discussed components. They are combined in a multiplicative model to determine total risk, associated Star Rating, and FSI Estimations. While the Star Rating model indicates the risk to an individual road user, the FSI Estimation Model considers the Star Rating results to estimate how many FSI crashes will occur on the road network, considering exposure (road user flows). Therefore, the FSIs will be the main indicator of safety for the PHOEBE framework. Figure 2-14 Road Safety assessment process flow within PHOEBE framework phoebe-project.eu Copyright © by PHOEBE 52 The road safety assessment process is detailed in Figure 2-14. From the theoretical perspective, road safety assessment (that is, the Star Ratings, FSI Estimations and where relevant, CycleRAP) interact with the other elements within the PHOEBE Framework in five different stages of the process. From road safety assessment to other components: i. Static risk scores are inputs for demand and behavioural models; ii. Dynamic risks scores are an input for traffic simulation, however, only for visualisation; and iii. Crash risk scores and FSIs are used to generate PHOEBE KPIs. From other components to road safety assessment: i. Dynamic risk scores which use variable speed and flow data from traffic simulation; and ii. Behavioural calibration factors for the FSI Estimation model. The road safety assessment flow can start in two different ways depending on whether the assessments already exist or if it is an entirely new assessment. Both result in ‘static’ scores, that is, a risk score for a point in time. For new assessments, the process starts with data gathering (road survey and/or data gathering from AI and other sources). A comprehensive dataset is compiled which align with that described in section 2.5.1. The collected data is then used to calculate the preliminary crash scores for each individual road segment. Where there is an existing assessment (and therefore pre-existing data as well as output data in the form or Star Ratings and FSI Estimations), the process starts with converting the 100-segment results to be compatible with the simulation network (links and nodes). Existing or new datasets then serve as the foundation for the baseline assessment phase. Explainer notes Changing the data structure to reflect nodes and links The Star Rating Score (SRS) and the FSI Estimation are calculated for each 100m road segment for vehicle occupants, motorcyclists, pedestrians and bicyclists. This means that all road attribute data comprises 100m coding segments. The 100m segments are equally distributed from the assessment's starting point defined by the survey. When a new survey starts, a new reference starting point is established. Each row of the ViDA core files represents one 100m segment. The latitudes and longitudes provided refer to the beginning of each segment. However, simulation models structure the data differently: using nodes and links. Three approaches will be developed and tested for PHOEBE: (i) Procedure for networks with most links with more than 100m When most of the links in the network are more than 100m long, the data coding can still be done per 100m segment, and the data point will be spatially joined by the link, with the risk score averaged by the link and the FSI's summed. Procedures to compatibilise the networks will be established and tested during WP3. (ii) Procedure for networks with most links with less than 100m When most of the links in the network are less than 100m long, coding needs to be done per link. The impacts of changing the coding standardisation will be tested and analysed as part of WP3 using PHOEBE use cases. (iii) Procedure to match intersection scores and nodes Intersections, particularly in cities and urban areas, can take many forms. In reality, intersections may have as many as 6or 8-legs and be a combination of slip lanes, on and off ramps to overpasses, and phoebe-project.eu Copyright © by PHOEBE 53 staged traffic signals. Therefore, matching Star Rating data points that present an intersection coded with micro-simulation nodes is far more complex than matching mid-block sections with links. Due to the complexity described above, the PHOEBE framework will provide guidelines on matching intersection scores and nodes per intersection type. The intersections in the use case study areas offer many examples, including 3 and 4-leg junctions, roundabouts and merge lanes in single or doublecarriageways. User guidelines on how to identify the best procedure and how to operate the analysis will be developed as part of WP3. After the static results are generated and structured according to links and nodes, the Star Rating models wait for output data (variable speed and flows) from the traffic microsimulation and the FSI calibration parameters received from the behavioural modelling component. These are then used to generate the ‘dynamic’ risk profiles. The dynamic crash scores are then sent back to the traffic simulation tool for visualisation purposes and will be used to inform PHOEBE KPIs. Visual maps are then used to illustrate the spatial distribution of risk scores across the entire expanse of the road network. Star Ratings will be recalculated in step 2, to take into account changes in road conditions, speeds and road user flows. 2.5.2.1 Estimating FSI Estimating FSI uses the iRAP FSI Estimation model to predict the number of FSI associated with each specific road segment over a given period (typically 20 years). The process relies on a comprehensive understanding of the road attributes in conjunction with their interaction with the prevailing traffic conditions. The FSI Estimation model will generate the first estimates based on the infrastructure crash risk (the Star Ratings), number of road users and is calibrated using crash data (for the baseline scenario). 3 Variable speed and flow data from the traffic microsimulation and behavioural calibration factors Estimates from behaviour models will adjust these values. The final FSIs will inform PHOEBE KPIs and socioeconomic analysis. FSI Estimations will be recalculated in step 2 based on changes in the Star Rating, road user flows and behaviour calibration factors. This allows provides the basis to understand the safety impacts of the changes. Explainer notes Variable speed and flows to produce dynamic risk scores The Star Ratings, CycleRAP, and FSI estimations models provide a static risk evaluation. This means the results refer to a specific time-related point related to the moment the images were captured and the supporting data collected. Traffic speeds and flows are highly variable compared to infrastructure-related elements of a road. With new technologies capture data much faster, the risk assessment model can capture these variations and provide dynamic risk scores. This helps road authorities understand changes that may be occurring throughout a typical day, and address times when risk is highest. The dynamic allocation of speed and flows requires enhancements in the current models. The following enhancements are planned in WP3: 3 This calibration takes into account factors which are beyond those considered by the Star Rating models, such as vehicle safety standards and features (e.g. seat belts and airbags), road user behaviours (aside from operating speed which is directly considered) and crash response which may influence FSI outcomes. phoebe-project.eu Copyright © by PHOEBE 54 Establishment of the database structure to account for more than one risk result per location: to allow risk calculation, for instance, for different hours of the day, the model input file needs to be structured in a way that would enable computation and visualisation of the results. Methodology for non-daily flows: Currently, the model uses Road AADT for vehicles and motorcycle flows and peak hour flows for bicycles and pedestrians. The model needs to be prepared and tested to receive inputs of different parameters for vehicle and VRU flows. Data transferability procedures to automate risk calculation based on traffic simulation inputs: Standardisations of inputs/outputs formats and the API connections need to be developed together with the traffic simulation tool to allow smooth data sharing among models. Calibration of FSI to reflect behavioural changes The FSI Estimation model is calibrated using crash data for the assessed roads. The calibration factors (CF) check that the total estimated number of FSI on the network is equal to the actual number of FSI on that network. The following equations show the CF formula for the pedestrian crash crossing the inspected road (PED CR-IR) crash fatalities as an example: 𝐶𝐹𝑃𝐸𝐷⁡𝐶𝑅−𝐼𝑅 =⁡𝐴𝑐𝑡𝑢𝑎𝑙⁡𝑛𝑜.⁡⁡𝑜𝑓⁡𝑝𝑒𝑑𝑒𝑠𝑡𝑟𝑖𝑎𝑛⁡𝑐𝑟𝑎𝑠ℎ⁡𝑓𝑎𝑡𝑎𝑙𝑖𝑡𝑖𝑒𝑠⁡𝑤ℎ𝑒𝑛⁡𝑐𝑟𝑜𝑠𝑠𝑖𝑛𝑔⁡𝑡ℎ𝑒⁡𝑖𝑛𝑠𝑝𝑒𝑐𝑡𝑒𝑑⁡𝑟𝑜𝑎𝑑⁡𝑜𝑛⁡𝑡ℎ𝑒⁡𝑛𝑒𝑡𝑤𝑜𝑟𝑘 ∑(𝑆𝑅𝑆𝑃𝐸𝐷−𝐶𝑅−𝐼𝑅×𝑎(𝐴𝐴𝐷𝑇)𝑏×𝑉𝑁𝑂𝑁−𝑀𝐶×𝐹𝐺)⁡ (2-12) where, 𝐶𝐹𝑃𝐸𝐷⁡𝐶𝑅−𝐼𝑅= Calibration factor for pedestrian crash fatalities when crossing the inspected road n= the number of 100-metre segments of road SRS PED-CR-IR = Star Rating Score for pedestrians crossing the inspected road a = AADT multiplier AADT = annual average daily traffic b = AADT power V NON-MC = non-motorcycle AADT FG = fatality growth exponent In this way, the FSI Estimation model takes account of factors that influence the number of fatalities on the road other than infrastructure, speed and flow. Therefore, when crash data is available, the FSIs account for FSI originating from unsafe behaviour. FSIs will be calibrated based on the behavioural model results. The proposition is that the calibration factor formula will have an extra component representing the percentage of increase/decrease in the number of deaths for the particular behaviour studied and provide more granularity in the calibration. The approach and testing will be finalised in the WP3 activities. Model testing All planned enhancements to the models will be tested. The iRAP ViDA system provides access to testing data in more than 90 countries, ensuring that training and testing phases encompass a diverse range of diverse traffic scenarios. This rigorous analysis of all the methods not only substantiates its effectiveness within the PHOEBE project but also showcases its potential for enhancing road safety on a broader scale. 2.6 Safety indicators and dynamic risk outputs The basic definition of risk in safety science is the occurrence probability of an event multiplied by the consequence of that event. Based on this definition, many indicators can be defined for risk and safety on the road. Traditionally, road crashes are used as indicators of road safety (in which the risk can be calculated as the probability of crash occurrence multiplied by the severity of crashes). However, there are many issues phoebe-project.eu Copyright © by PHOEBE 55 with using crashes as an indicator. First it is a reactive approach, meaning one or more people need to be involved in FSI crashes before safety issues are noticed or addressed; and second, many crashes (particularly the property damage only crashes) are not reported and so their data are not available in the crash databases. This is particularly the case for non-vehicle occupant road users. However, predictive models can identify zones at high risk of FSI crashes with an acceptable level of confidence. From many years of research in road safety, it is already well-known what road components affect the likelihood and severity of crashes. Many prediction formulations have been established and used as presented in D1.1. Recently, surrogate safety measures have been commonly used for road safety assessment (as explained in section 3.1.7.1 of D1.1), to identify traffic conflicts by processing the vehicular trajectories from the output of traffic microsimulations. Traffic conflicts have been used more recently as proactive and more frequent indicators of safety (in which case the risk would be the probability of conflicts multiplied by their severity). According to the Swedish Traffic Conflicts Technique, the same causes can be attributed to near-crashes or traffic conflicts and can act as a tool for safety assessment. The various possible interactions between road users and the associated risk can be further elaborated through the “safety pyramid” by Hydén (Figure 2-15; Hydén, 1987), presenting different zones of safety critical events while also reflecting the associated severity. Figure 2-15 Classification of safety critical events according to the Swedish Traffic Conflicts Technique (Hyden, 1987) The Federal Highway Administration (FHWA)’s Surrogate Safety Assessment Model (SSAM) provides various parameters for identifying the traffic conflicts including: • TTC = Time to collision; • PET = Post-encroachment time; • DR = Deceleration rate; • MaxS = Maximum of the speeds of two vehicles; • DeltaS = Maximum relative speed; • Classification as lane-change, rear-end, or path-crossing event type; • DeltaV = Vehicle velocity change had the event proceeded to a crash. In addition to the direct safety measures, there are some factors which are predictors of safety (as opposed to direct indicators). For example, harsh acceleration or cornering may directly lead to conflicts or crashes and so they are good predictors of safety. For both indicators and predictors of safety, some are fine- phoebe-project.eu Copyright © by PHOEBE 56 grained (suitable for microscopic safety analysis), and some are more aggregated (suitable for macroscopic safety); some are only relevant for drivers (e.g., harsh acceleration), and some are relevant for vulnerable road users too (e.g., conflicts). As a result, it is of high importance to create a taxonomy of safety indicators to better integrate the data, models and processes of the components in PHOEBE and establish the methodology. Taxonomy of safety (risk) indicators The taxonomy of safety indicators (Table 2-4) is developed considering both indicators and predictors of safety. The indicators include: • Direct measures such as crashes (number and severity); • Surrogate measures such as conflicts (frequency and severity); • Predictor variables such as hazardous factors such as related to infrastructure (from road safety assessment star ratings); and • Human factors (risky behaviours of road users), which can lead to potential collisions. Factors associated with crash causes are generally categorised as driver-related, vehicle-related or related to the roadway environment (infrastructure, pavement surface condition, sight obstructions, and others). The predictor variables include a variety of safety critical factors related to infrastructure and road users’ behaviours, which can potentially lead to collisions, such as: • Inadequacies within the Infrastructure for safe traffic operations; • Lack of compliance to roadway rules, distracted driving, fatigued driving, aggressive driving behaviours, etc. Vehicle structural characteristics within various vehicle types are out of the scope and hereby have not been considered. Table 2-4 Taxonomy of Safety/Risk Indicators Road Users Variable Level Relationship with Risk Drivers and vehicle occupants Conflicts (frequency and severity) (calculated using TTC, PET, DR, MaxS, DeltaS, type, DeltaV) Micro: Individual instances Meso: Number of conflicts across a segment / at an intersection Macro: Number of conflicts over a network Indicator Crashes (frequency and severity - FSI) Micro: Individual crashes Meso: Number of crashes across a segment / at an intersection Macro: Number of crashes over a network Indicator Star Rating Risk Scores (Infrastructure) Meso: risk score of a segment / intersection Indicator phoebe-project.eu Copyright © by PHOEBE 63 3.1 Procedure This section elaborates on two methods of SEA that are chosen for assessing the socioeconomic impacts of the deployed changes to be considered in PHOEBE. The chosen methods are: • Cost-Benefit Analysis (CBA); and • Cost-Effectiveness Analysis (CEA). Cost-Benefit Analysis (CBA) CBA is a systematic socioeconomic evaluation technique deployed to evaluate a project, policy, or decision's pros and cons. It is carried out by comparing the total costs associated with implementing the project, policy, or decision to the total benefits generated by it. Since a deployed change is such an intervention, the CBA can be used to evaluate the social and economic impacts of a particular change. CBA is a quantitative method of evaluation. The primary objective of a cost-benefit analysis is to determine whether the benefits of an action outweigh its costs in monetary terms. The steps of carrying out a CBA against a change are described below. Figure 3-1 provides a conceptual flow of the process. a) Identifying the benefits: The benefits of a deployed change chiefly comprise two separate elements (Daniels et al., 2019), namely: I. The number of crashes prevented by the deployed change; and II. Other possible benefits relating to the mobility and environmental impacts. b) Quantifying or monetising the benefits: Specific benefits generated by any change are quantitative, e.g., property damage avoidance and emergency cost savings. However, part of the benefits are qualitative, e.g., the number of deaths and severe injuries prevented. These KPIs are qualitative because the costs associated with these KPIs are variable and depend upon several factors. To estimate the costs associated with such KPIs, a technique like Willingness-to-Pay (WTP) is deployed. • Willingness-to-Pay method: The following scenario is considered to describe the WTP method. Suppose a change or policy is expected to reduce the number of deaths caused by road crashes 𝑛 by over a given time frame for a population of size 𝑃. Now, if 𝑣 is the average amount each member of the population is willing to pay to fund the road safety measure for risk reduction, then the total amount to be paid by the population is 𝑣.𝑃. Thus, the willingness to pay per fatality is (𝑣.𝑃)/𝑛 (OECD, 2001). WTP can be further used to estimate the Value of Statistical Life (VoSL) or the Value of Preventing a Fatality (VPF). VoSL, or VPF, is a quantitative (often monetary) value used to quantify the benefit of avoiding a fatality. Generally, empirical approaches, e.g., Revealed (OECD, 2001) or Stated preference methods (contingent valuation) (Antoniou, 2014; Rizzi & Ortúzar, 2006), are deployed to estimate WTP and VoSL. • Stated preference (SP) method: This method is dependent on stated preference surveys (Antoniou, 2014). The respondents are asked to deliver their responses through a rating scale. A suitable discrete choice model (e.g., Multinomial or Nested logit (in case the IIA does not hold) is then selected, with each potential response coded as an alternative. An example of the SP method with ordered probit model is presented below. Suppose 𝑌 is the response variable with 𝐾 levels (scales); in this case the model can be represented as (Antoniou, 2014): phoebe-project.eu Copyright © by PHOEBE 64 𝑃(𝑥)=𝛷(𝜃𝑗−𝛽′𝑥) (3-1) where, 𝛷 is the cumulative normal function 𝜃0= −∞< 𝜃1<⋯ <𝜃𝑘<∞ are the break points 𝑥 is the vector of explanatory variables 𝛽 is the vector of unknown parameters The distribution of the choice probability 𝑃 as the function of the utility 𝑈 can be presented as Figure 3-2. The road safety benefits for a period 𝑛, depending on level of severity 𝑠 that results from the introduction of a measure, can then be calculated as (Daniels et al., 2019): 𝐵𝑒𝑛𝑒𝑓𝑖𝑡𝑠𝑛=⁡∑𝑇𝑎𝑟𝑔𝑒𝑡𝑐𝑟𝑎𝑠ℎ𝑒𝑠𝑠∗𝐸𝑓𝑓𝑒𝑐𝑡𝑖𝑣𝑒𝑛𝑒𝑠𝑠𝑠∗𝐶𝑟𝑎𝑠ℎ𝑐𝑜𝑠𝑡𝑠⁡ 𝑛 (3-2) Where, According to Daniels et al. (2019) and Wijnen & Stipdonk, (2016) the 𝐸𝑓𝑓𝑒𝑐𝑡𝑖𝑣𝑒𝑛𝑒𝑠𝑠 is typically expressed by means of the percentage reduction (PR) of either the number of crashes or the number of casualties as a consequence of the measure as a consequence of the measure (calculated, for instance, with Crash Modification Factors). The effectiveness often varies according to the level of severity concerned. The target crashes (𝑇𝑎𝑟𝑔𝑒𝑡𝑐𝑟𝑎𝑠ℎ𝑒𝑠) are the number of crashes (or injuries) of various severity levels that possibly can be affected by the measure, so typically in before-after studies this is the estimated number of crashes in the before period corrected for regression to the mean and for trend effects. The benefits can be expressed in monetary values by multiplying the number of prevented crashes or injuries with the monetary value of the benefit, i.e., the cost per crash or injury (𝐶𝑟𝑎𝑠ℎ𝑐𝑜𝑠𝑡). Crash costs typically consist of several components of which human costs, i.e., immaterial costs, tend to be the most important. Crash costs are strongly dependent on the severity level of the crash (Daniels et al., 2019; Wijnen & Stipdonk, 2016). Figure 3-2: Distribution of the responses Adapted from Antoniou (2014) phoebe-project.eu Copyright © by PHOEBE 65 c) Identification and quantification of cost: Since costs are the second most crucial factor, they should be identified and quantified comprehensively. Section 3.2.1.2 presents different kinds of costs associated with the CBA. However, most cost types are quantitative and must be added together to quantify the total cost associated with the deployed change. d) Discounting and calculating the Net Present Value (NPV): The quantified costs and benefits must be discounted to counter factors like inflation. The discounting should be carried out with a suitable and well-researched discount rate to achieve the corresponding NPV of both the costs (- ) and benefits (+). The following formula can be used to discount the costs and benefits. 𝑁𝑃𝑉 = ∑𝑛𝑜𝑚𝑖𝑛𝑎𝑙⁡𝑣𝑎𝑙𝑢𝑒 (1+𝑑𝑖𝑠𝑐𝑜𝑢𝑛𝑡⁡𝑟𝑎𝑡𝑒)𝑛 𝑁 𝑛=1 (3-3) Net Present Value of the deployed can be calculated by subtracting 𝑁𝑃𝑉𝐶𝑜𝑠𝑡𝑠 from 𝑁𝑃𝑉𝐵𝑒𝑛𝑒𝑓𝑖𝑡𝑠, i.e., 𝑁𝑃𝑉𝑅𝑆𝑀 =𝑁𝑃𝑉𝐵𝑒𝑛𝑒𝑓𝑖𝑡𝑠 −𝑁𝑃𝑉𝐶𝑜𝑠𝑡𝑠. The value of the NPV of the costs and benefits decides the validity of the CBA, i.e., the CBA only makes sense iff: 𝑁𝑃𝑉𝑅𝑆𝑀 >0. e) Calculating BCR: As described in the preceding sections, BCR is an important metric of CBA. It is calculated by dividing the 𝑁𝑃𝑉𝐶𝑜𝑠𝑡𝑠 by 𝑁𝑃𝑉𝐵𝑒𝑛𝑒𝑓𝑖𝑡𝑠. The CBA makes sense iff 𝐵𝐶𝑅⁡>⁡1. Thus, a deployed change is considered effective iff 𝑁𝑃𝑉𝑅𝑆𝑀 >0 and 𝐵𝐶𝑅⁡> ⁡1. Cost-Effectiveness Analysis (CEA) The Cost-Effectiveness Analysis (CEA) is another method to analyse the socioeconomic impact of road safety measures. Methodologically, CEA is closely related to CBA. Sometimes, CEA is considered a variant of CBA (Wesemann, 2000). In CEA, the costs associated with a change deployed are quantified along with the number of fatalities and injuries. One way of carrying out CEA to evaluate a particular road safety measure is by using Incremental Cost Effectiveness Ratio (ICER) (Chantith et al., 2021) ICER is also used to rank road safety measures in terms of their effectiveness. Mathematically, ICER is described as: 𝐼𝐶𝐸𝑅 =𝐴𝐷𝐶 𝐴𝐷𝐸 (3-4) ADC represents the average change in the budget in the given time interval (the period from no road safety measure till its engagement). In contrast, ADE represents the average change in the number of deaths caused by road crashes during the same time interval. The resultant ICER for each measure is then accounted for along with the four quadrants of the CEA plane shown in Figure 3-3 below. Figure 3-3 CEA plane (four quadrants) (Chantith et al., 2021) phoebe-project.eu Copyright © by PHOEBE 66 3.2 Data Input data The input data to the component of socioeconomic analysis (SEA) can be categorised into two classes (OECD, 2001), namely: • Input data to calculate the benefits; and • Input data to calculate the costs. Both these classes of input data are described in the sections below. 3.2.1.1 Input data to calculate the benefits The input data for the component of socioeconomic analysis for calculating the benefits (due to the introduction of road safety measures) primarily consists of multiple Key Performance Indicators (KPIs 4 ). The KPIs present the measurable form of all the benefits that the deployed changes produce. A measurable or objective format of the KPIs enables the monetisation process of the benefits. Table 3-1 presents the three principal issues or categories, and the corresponding foreseeable KPIs (Chantith et al., 2021; Daniels et al., 2019; Elvik, 2001). The preceding components of project PHOEBE's methodological framework, namely demand modelling, behavioural modelling, traffic microsimulation, and road safety assessment, are set (in proper order and loops) to produce these KPIs. However, it is to be noted that additional KPIs may be added, and the currently listed KPIs can be edited or removed from the list depending on the detailed modelling considerations. Table 3-1 Principal issues, road safety measures and corresponding KPIs Nr Principle issues Corresponding KPIs 1 Health and Safety Percentage change in FSI Number. of quality-adjusted life years due to uptake of active modes and changes in air quality Percentage of travel at 3-star or better by road user type Percentage participation in walking, cycling & other forms of active mobility 2 Environment Percentage change in motorised trips Percentage change in nonmotorised trips Percentage change in carbon emissions and/or fuel consumption 3 Economy Health sector savings per km (from less trauma / better health etc.) Rising cost per quality-adjusted life year due to uptake of active modes and changes in air quality Percentage change in economic cost of FSI Household savings resulting from uptake of active modes 4 The selection of the KPIs is a vital part of the project PHOEBE. In the later phase of the project, the project committee and the respective stakeholders can jointly select the KPIs. phoebe-project.eu Copyright © by PHOEBE 67 The KPIs listed in Table 3-1 will be calculated before and after introducing the changes. This way, the benefits generated by the changes can be delineated and quantified (monetised), which will further act as the benefit side input data for the SEA component. 3.2.1.2 Input data to calculate costs The other side of the input data to the SEA component consists of the data describing the overall costs of the changes (Daniels et al., 2019). The cost side can be defined as all the costs involved in setting up the changes, including all the one-time investment and recurring costs implicated in setting up the change. The cost part of the input data is more objective than the benefit part since it includes primarily the investment costs, which can be easily quantified in monetary terms. The input costs can be classified into several categories or types, namely: • Initial capital costs: These costs include all the one-time expenses incurred at the beginning of the project implementing changes, e.g., costs of design, construction, equipment purchases, and installation. • Operation and maintenance costs: These costs include any ongoing costs and recurring expenses required to keep the change operational over time, e.g., inspection costs, repair costs, or improvement costs. • Administrative costs: These costs include any one-time or recurring administrative expenses associated with managing the deployed change over time, e.g., Staff salaries, training, and overhead costs related to the RSM. • Monitoring and evaluation costs: These costs involve the expenses associated with tracking the deployed changes in terms of its effectiveness in providing road safety over time. These costs include expenses for data collection, analysis, and reports on safety evaluation. Outputs and further analyses The socioeconomic analysis of deployed changes provides valuable outputs, insights, and information to decision-makers. It also enables further analyses that shed light on the potential impacts, benefits, and costs of implementing the changes. The outputs and the further analyses enabled by the socioeconomic analysis are listed below. 3.2.2.1 Outputs The outputs of socioeconomic analysis typically include: 1 Net Present Value (NPV): The NPV is a standard output of socioeconomic analysis (costbenefit analysis) of any changes (Daniels et al., 2019; Drèze & Stern, 1987). The NPV is a numerical value representing the difference between the present value of the benefits provided by the change and its present cost. A positive NPV indicates that the change is economically viable. 2 Benefit-Cost Ratio (BCR): Like NPV, the BCR is another standard output of the socioeconomic analysis (cost-benefit analysis) of any change. The BCR presents the value of the ratio of the benefits generated by the change deployed to its costs. A BCR > 1 signifies that the benefits generated by the change are more than the costs involved in setting up that change (Daniels et al., 2019; Drèze & Stern, 1987). 3 Incremental Cost Effectiveness Ratio (ICER): Like BCR, ICER is the ratio of the average change in the budget in the given time interval, i.e., the period from no deployed change till its engagement to the average change in the number of deaths caused by crashes during the same time interval. The resultant ICER for each change is compared to the four quadrants of the CEA plane to provide its effectiveness (Chantith et al., 2021; Wesemann, 2000). It is an output of the cost-effectiveness analysis (CEA). The CEA plane is presented in Figure 3-3. phoebe-project.eu Copyright © by PHOEBE 68 4 Monetised benefits and costs: The socioeconomic analysis provides detailed and quantified information about the benefits and the costs in terms of monetary values (CBA) associated with the deployed change. 3.3 Further analyses Further analyses supported by SEA that can be carried out following the SEA process are: 1 Sensitivity Analysis: The sensitivity analysis explores the effects of changing values of the critical assumptions or variables on the results. 2 Other economic (indicators) analyses: Economic indicators such as the Internal Rate of Return (IRR) calculation can be used to assess the rate of return on investment and the financial attractiveness of the deployed change. 3 Risk assessment analysis: The risk assessment analysis can provide a qualitative or quantitative assessment of the potential risks and uncertainties associated with the road safety measure's outcomes and costs. 4 Inputs for Policy Decisions: The analyses of the outputs of the SEA provide critical information for making informed policy decisions. Decision-makers can use the results to prioritise and allocate resources effectively. Additionally, feedback loops can be arranged to control the potency or effectivity of the change to the preceding modules of the project PHOEBE, e.g., mode choice modelling, traffic microsimulation, behavioural modelling, and road safety assessment module. 5 Monitoring and Evaluation Plan: The SEA outputs can also provide the necessary information in setting up recommendations for a monitoring and evaluation plan to track the actual outcomes of the implemented changes and compare them to the projected benefits and costs. phoebe-project.eu Copyright © by PHOEBE 69 4 Solution requirements and technical specifications This section is focused on the existing and ‘to become available’ techniques and related technologies required for the PHOEBE Framework, and sets out the priorities and related information required for WP3. It includes: • Technical sheets which outline all the relevant details about each component, such as model descriptions, inputs and outputs, equipment, and license requirements; • The technological developments for the models’ integration and harmonisation of concepts, inputs and parameters and their delivery timetable; and • Uncertainties and issues to be addressed in WP3. 4.1 Technical sheets The technical sheets compile technical data about each of the elements in the PHOEBE Framework. The purpose of the technical sheets is to provide a reference to the PHOEBE technical partners to support the development work in WP3 and to facilitate information findings in future applications of the PHOEBE Framework. The technical sheet content reflects the knowledge of the current stage of PHOEBE development. Therefore, the technical sheets will be updated as the WP3 and the PHOEBE project progresses. The technical sheets are included in the appendices of this document. 4.2 WP3 technical development plan To put PHOEBE’s theoretical methodology into practice, the technical partners must perform a series of activities to achieve the level of technical development necessary to test the proposed theoretical framework. The activities can be split into three phases: (i) preparation, (ii) development and (iii) integration and refinements. Figure 4-1 presents the main activities in each development phase. phoebe-project.eu Copyright © by PHOEBE 70 Figure 4-1 WP3 development phases PHASE I: Preparation (6 months) Phase I, the preparation phase, aims to set the specificities of the approach. With the definition of the information flows established in the theoretical framework, partners must agree on the technical aspects to successfully receive inputs. Examples of matters that need to be discussed are: • Network compatibility between traffic simulation models and road safety assessment methods; • Modal split outlook format to input into traffic simulation; or • Behavioural parameters that need to be calibrated into traffic simulation models and how to calibrate them. This phase has some intersections with other work packages. The design of new surveys will be formulated as part of the preparation for model developments but will have close cooperation with the data management efforts handled in WP2. The same is true for the results of the assessments and the information they generated that will be available for other purposes in the project under the umbrella of WP2. Likewise, the Framework needs to calculate the changes in KPIs, theoretically established in this deliverable but also agreed with the local stakeholders as part of the WP4 activities. Similarly important is the preparation of the traffic microsimulation environment for integration. The simulation tool provided by AIMSUN will be the platform that aggregates the inputs and feed models with their outputs, ensuring the dynamic outputs expected for PHOEBE. PHASE II: Development (12 months) The Phase II activity results will determine the suitability and replicability of the PHOEBE predictive approach. It is one of the project's most complex and critical moments because it occurs when the model developments and enhancements are elaborated, calibrated (if that is the case) and tested. This process phoebe-project.eu Copyright © by PHOEBE 71 is expected to be an iterative, continuous and evolutionary process, where in each round of testing, encounter issues will be worked out to adjust models' statistical and technical fits. Phase II has a strong alignment with the activities on WP2. In case it is necessary, a continuous process of data delineation is planned to support new data collection. The same is true for WP4, since local stakeholders need to evaluate the project results and provide feedback on the visualisation tool, which will also be developed to allow end users to understand the impacts of testing changes. The visualisation tool will be part of AIMSUN solutions. Phase II also includes some research aspects. The methodological framework (the ‘HOW’ matrix together with the process flowchart) serves as a new research and development (R&D) framework too that advances the state-of-the-art and can be used by other scholars for integrating the existing or emerging elements of demand models, traffic microsimulation, road safety assessment, and behavioural models. However, it is important to note that while the R&D part of the framework may include a broad range of data/models for each of the five components in PHOEBE, not all of them may ultimately be implemented in PHOEBE and only those that are relevant and feasible (particularly with an eye on the use case needs) will be implemented. For example, driving under influence (DUI) is one of the major illegal behaviours among drivers in urban environments and thus may need to be integrated within traffic microsimulation too. Collecting the data for this behaviour is not a trivial task and may be costly and time consuming. Yet, there is no obstacle in having this behaviour in the R&D part of the project and as a type of illegal behaviours of motorised road users (Section 2.4.2 of this deliverable), especially since the analytical models pertaining to this behaviour may not be substantially different than other relevant behaviours in PHOEBE. PHOEBE partners have already identified research opportunities within the project scope. Depending on the research findings, the results may or may not be integrated with the final configuration of PHOEBE, but these will be documented and presented in WP3 deliverables. PHASE III: Integration and refinements (4 months) Phase III focusses on the integration and possible refinements of the Framework. The complete integration will happen as part of WP5, but WP3 need to develop and test the means of integration. The PHOEBE Framework will provide a series of supporting materials to ensure replicability. The preparation of the user guides, as well, as the final model development documentation will be performed during Phase III and be part of deliverable D3.2. 4.3 WP3 timeline The WP3 timeline considers the three phases described above and the project milestones and deliverables planned. The WP GANTT charts are in Appendix B. As highlighted in the timeline (in April 2024 and April 2025), two deliverables need to be prepared respectively to document the technical development work. They are: D3.1 - New and enhanced models/simulation environments and user support materials (Beta ed.) D3.1 will present the models' preparations for the use case testing and the upgrades in the simulation environment. The Deliverable D3.1 is considered a mid-term deliverable since the work would still be in progress on the deliverable due date. The nature of the models applied on PHOEBE implies different levels of development at the stage where D3.1 need to be presented. In other words, it is expected that models that are data dependent, such as the demand models and behavioural models, can only be developed entirely after the project achieves the milestone of working data available for WP3, WP4 and WP5, which the due date is the same as that of D3.1. phoebe-project.eu Copyright © by PHOEBE 72 The D3.1 presentation format is still under discussion but must combine technical documentation and visualisation of upgrades. The deliverable content will present the advances in the simulation environment and the road safety assessments to demonstrate the PHOEBE framework in the use cases. D3.2 - Finalised models/simulation environments methodology factsheets and user support materials D3.2 will present the final version of the model, including the refinements and lessons learned as part of the use case demonstration. The user documentation will also be part of D3.2, where the practical and theoretical information to guide the end user in applying the PHOEBE framework will be presented. PHOEBE development interdependencies The complexity of the PHOEBE Framework is strongly related to the number of inter-dependencies among its components. The connections and data flows between the elements of the PHOEBE Framework (as depicted in Figure 1-1) are relevant to the project's technical developments. This section describes the interdependencies that need to be resolved in WP3. The technical sheets in Appendix A provide more detail on the technical interdependencies. Technical specificities to be resolved regarding the interdependencies: • Definition of dynamic risk profiles (Star Ratings, crash risk scores and/or FSI Estimations); To create the conditions for risk scores to be used in such models, they will be calculated first as static scores based on road AADT and 85th percentile operating speed, representing the overall condition of the network over the day to the models. The results can be updated further in the process after the speed and flow profiles are available for the dynamic risk assessments from the simulations. • Validity and relevance of Star Ratings as a surrogate measure for safety perception (research and validation required): Although the iRAP Star Rating does not reflect road user perceptions, the characteristics of the infrastructure affect the demand for specific modes (e.g., more cycling trips when cycling infrastructure is available) or the way road users use the infrastructure (e.g., driving close to cyclist when there is road mark separating the flows). Therefore, risk scores must be available before estimating the demand and behavioural models. • Simulation timeframes and demand data availability: The simulation of the scenarios depends on the flow information in the shape of OD matrix and zoning. Therefore, the demand data's availability will inform the scenarios to be tested as part of PHOEBE (on-peak, off-peak, hourly, or other). AIMUSN Next defines the data parameters well since this is a standard input for traffic simulation scenarios. • Establishment of calculation procedures to adjust microsimulation behavioural factors: The traffic simulation depends on the individual behavioural probabilities or behavioural parameters in the car-following, lane-changing and gap acceptance models. How the models that describe the target behaviours will be incorporated into the AIMSUN next tool will be discussed in WP3. • Data transfer procedures from givers to receivers: The PHOEBE integration will be successful if the data flows are well established in data configuration to match receivers' requirements and the flow timeline (in each moment of the flow process, the outputs and inputs should be shared). Each of the interdependencies's arrows presented in Figure 1-1 has its own set of arrangements that need to be made by the pair of partners. The WP3 deliverables will document and describe the data transfer procedures to support further applications of PHOEBE. phoebe-project.eu Copyright © by PHOEBE 79 References Antoniou, C. (2014). A stated-preference study of the willingness-to-pay to reduce traffic risk in urban vs. rural roads. European Transport Research Review, 6(1), 31–42. https://doi.org/10.1007/s12544-013-0103-3 Barff, R., Mackay, D., & Olshavsky, R. W. (1982). A Selective Review of Travel-Mode Choice Models. Journal of Consumer Research, 8(4), 370. https://doi.org/10.1086/208877 Ben-Akiva, M. E., & Lerman, S. R. (2006). Discrete choice analysis: Theory and application to travel demand (Vol. 9). The MIT Press. Bertazzon, S., & Elikan, O. (2009). Alternative neighbourhood specifications of the spatial weight matrix; effects on spatial autocorrelation index and multivariate analysis of health data. In 17th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems (ACM GIS 2009): 4-6 November 2009; Seattle. Bierlaire, M., 1998. Discrete choice models. In Operations research and decision aid methodologies in traffic and transportation management (pp. 203-227). Berlin, Heidelberg: Springer Berlin Heidelberg. Chantith, C., Permpoonwiwat, C. K., & Fowles, R. (2021). Cost-Effectiveness of Road Safety Policy for Preventing and Reducing Road Traffic Fatalities in Thailand. Thailand and The World Economy, 39(2), 1–17. https://so05.tci-thaijo.org/index.php/TER/article/view/251882 Chen F. (2007). Sensitivity of goodness of fit indexes to lack of measurement invariance, Struct. Equ. Modeling. 14, 464–504. Daniels, S., Martensen, H., Schoeters, A., Van den Berghe, W., Papadimitriou, E., Kaiser, S., AignerBreuss, E., Soteropoulos, A., Wijnen, W., Weijermars, W., Carnis, L., Elvik, R., Martin Perez, O., & Ziakopoulos, A. (2019). A SYSTEMATIC COST-BENEFIT ANALYSIS OF 29 ROAD SAFETY MEASURES. Department for Transport. (2014). TAG UNIT M1, Principles of Modelling and forecasting. Department for Transport. (2020a). TAG UNIT M1.2, Data Sources and Surveys. Department for Transport. (2020b). TAG UNIT M2.1, Variable Demand Modelling. Domencich, T. A., & McFadden, D. (1975). URBAN TRAVEL DEMAND - A BEHAVIORAL ANALYSIS. Drèze, J., & Stern, N. (1987). Chapter 14 The theory of cost-benefit analysis (Vol. 2, pp. 909–989). Elsevier. https://doi.org/10.1016/S1573-4420(87)80009-5 Elvik, R. (2001). Cost-benefit analysis of road safety measures: applicability and controversies. In Accident Analysis and Prevention (Vol. 33). www.elsevier.com García-Melero, G., Sainz-González, R., Coto-Millán, P., & Valencia-Vásquez, A. (2022). Ridesourcing mode choice: A latent class choice model for UberX in Chile. Transportation Research Interdisciplinary Perspectives, 16, 100722. https://doi.org/10.1016/j.trip.2022.100722 Hensher, D. A. ;, & Button, K. J. ; (2008). Handbook of transport modelling: Vol. Volume 1 (D. A. Hensher & K. J. Button, Eds.; Second edition). Emerald. https://doi.org/10.1108/9780857245670 Hydén, C. (1987). The development of a method for traffic safety evaluation: The Swedish Traffic Conflicts Technique. Bulletin Lund Institute of Technology, Department, (70). Kalliga, V. (2021). Who Does New Trips and Why?-An Analysis Towards the Modelling of Induced Demand [Master thesis]. Technical University of Munich. Lee, B., Fujiwara, A., Zhang, J., Conference, Y. S.-10th I., & 2003, undefined. (2003). Analysis of mode choice behaviours based on latent class models. Academia.EduBJ Lee, A Fujiwara, J phoebe-project.eu Copyright © by PHOEBE 80 Zhang, Y Sugie10th International Conference on Travel Behaviour Research, Lucerne, 2003•academia.Edu. https://www.academia.edu/download/34170559/lee.pdf Moran, P. A. (1950). Notes on continuous stochastic phenomena. Biometrika, 37(1/2), 17-23. Motoaki, Y., & Daziano, R. A. (2015). A hybrid-choice latent-class model for the analysis of the effects of weather on cycling demand. Transportation Research Part A: Policy and Practice, 75, 217– 230. https://doi.org/10.1016/j.tra.2015.03.017 Narayanan, S., & Antoniou, C. (2023). Shared mobility services towards Mobility as a Service (MaaS): What, who and when? Transportation Research Part A: Policy and Practice, 168, 103581. https://doi.org/10.1016/j.tra.2023.103581 Novikov, D., Korepanov, V., & Chkhartishvili, A. (2018). Reflexion in mathematical models of decisionmaking. International Journal of Parallel, Emergent and Distributed Systems, 33(3), 319–335. OECD. (2001). Economic Evaluation of Road Traffic Safety Measures. OECD. https://doi.org/10.1787/9789282112861-en Ortúzar, J. de D., & Willumsen, L. G. (2014). Modelling Transport. Wiley. https://doi.org/10.1002/9781119993308 Pestel, E., Friedrich, M., HEIDL, U., PILLAT, J., Schiller, C., & SCHIMPF, M. (2016). Qualitaetssicherung von Verkehrsnachfragemodellen. In M. Taillevent & R. Deschaux (Eds.), Straßenverkehrstechnik. Droz. https://trid.trb.org/view/1437391 Rizzi, L. I., & Ortúzar, J. de D. (2006). Estimating the willingness-to-pay for road safety improvements. Transport Reviews, 26(4), 471–485. https://doi.org/10.1080/01441640600602302 von Schmidt, A., López Díaz, M., & Schengen, A. (2021). Creating a Baseline Scenario for Simulating Travel Demand: A Case Study for Preparing the Region Test Bed Lower Saxony, Germany. International Conference on Advances in System Simulation (SIMUL), 51–57. https://elib.dlr.de/144358/ Washington, S., Karlaftis, M., Mannering, F. and Anastasopoulos, P., 2020. Statistical and econometric methods for transportation data analysis. Chapman and Hall/CRC. Wesemann, P. (2000). Economic evaluation of road safety measures. Wijnen, W., & Stipdonk, H. (2016). Social costs of road crashes: An international analysis. Accident Analysis & Prevention, 94, 97–106. https://doi.org/10.1016/j.aap.2016.05.005 Winkler, C., & Mocanu, T. (2017, October). Methodology and Application of a German National Passenger Transport Model for Future Transport Scenarios. Proceedings of the 45th European Transport Conference. https://elib.dlr.de/117999/ Ziakopoulos, A., & Yannis, G. (2020). A review of spatial approaches in road safety. Accident Analysis & Prevention, 135, 105323. Ziakopoulos, A., Vlahogianni, E., Antoniou, C., & Yannis, G. (2022). Spatial predictions of harsh driving events using statistical and machine learning methods. Safety science, 150, 105722. Sha, H., Haouari, R., Singh, M. K., Tympakianaki, A., Hu, B., Zach, M., Oikonomou, M., Chaudhry, A., Thomas, P., Quddus, M., Morris, A. (2022). Transferability of Results within the Levitate Project, Transferability Working Group Working Paper of the H2020 project LEVITATE. Ullman, J.B. and Bentler, P.M., 2012. Structural equation modeling. Handbook of Psychology, Second Edition, 2. phoebe-project.eu Copyright © by PHOEBE 81 Appendices Appendix A: Technical sheets phoebe-project.eu Copyright © by PHOEBE 82 Technical sheet Behavioural Modelling Models Description Behavioural Models: Two major modelling techniques for modelling human behaviours will be used including: o Discrete Choice Models: These models take the perspective of discrete decision-making processes (e.g. discrete instances of going over the speed limit) - Multinomial logit models - Ordered probit models - Random parameters logit/probit models - Latent class logit/probit models o Structural Equations Models: These models look at the continuous proportions of behaviours over a certain period of time (the ratio of aggressive mobility over kilometres travelled). - Principal component analysis - Confirmatory factor analysis - Generalised linear models - Latent variable models Three general groups of behavioural models will be developed corresponding with the three human factors prioritised in PHOEBE: ● Group #1: speeding behaviour of motor vehicles on urban arterials ● Group #2: o illegal crossing of pedestrians at intersections and\or zebra crossings o red-light running of bicycles and e-scooters ● Group #3: harsh manoeuvring (acceleration, deceleration) cornering of drivers and\or cyclists Expected inputs Individual driving instances (or proportions) with speed over the speed limit Individual driving instances of violations to roadway regulations (all road user types) Red-light running events (all road user types) J-walking or illegal crossing events Not yielding events (e.g., motorised vehicles not yielding to VRUs) Events of aggressive driving Events of distracted driving (e.g., use of cell phone) Roadway and Traffic Characteristics related data Input data sources Cameras Sensors Floating Car Data Telematics Traffic Survey Data Travel Attitudes Survey (could be the source for violations and distracted driving etc.) phoebe-project.eu Copyright © by PHOEBE 83 Technical sheet Behavioural Modelling Expected outputs Individual probabilities or proportion of the population conducting each of the modelled behaviour Conflicts results in the number of FSI crashes Conflicts caused by the targeted behaviours PHOEBE Framework Dependencies (what is this dependent on happening before) Acquiring relevant data from available sources as well as collecting necessary data in the case of unavailability from the available sources (e.g. some useful data for the proposed behavioural models could be collected through the stated/revealed preference surveys) PHOEBE Framework Predecessors (what does this inform) Microsimulation models for calibrating the behavioural parameters to be used in the microsimulation models Road safety assessment tools through providing calibration factors for behaviours and estimation of FSI because of the modelled behaviours Equipment (Software requirements) Aimsun software Necessary Statistical Analysis Software License requirements (if any) Aimsun License License for any particular statistical analysis software (if not already available) PHOEBE developments Three general groups of behavioural models will be developed corresponding with the three human factors prioritised in PHOEBE: ● Group #1: Speeding - speeding behaviour of motor vehicles on urban arterials ● Group #2: Violations - illegal crossing of pedestrians at intersections and\or zebra crossings - red-light running of bicycles and e-scooters ● Group #3: Harsh manoeuvring - acceleration, deceleration, cornering of drivers and\or cyclists Additional information Detailed information about the behavioural models can be found in PHOEBE Deliverable 1.2. phoebe-project.eu Copyright © by PHOEBE 84 Technical sheet Traffic Simulation Models Description Aimsun simulation platform Aimsun provides a comprehensive simulation software. It includes all the relevant aspects in traffic simulation: network representation, traffic lights control, demand modelling, different user behaviour modelling, traffic routing, public transportation and pedestrians among the most relevant. On top of that the software offers various coding capabilities to expand their functionality using ad-hoc solutions. Aimsun default models Aimsun software platform has a wide variety of models to achieve a comprehensive simulation software. For PHOEBE project the most relevant are those related to traffic dynamics, these are the car following model, Modelling Vehicle Movement - Aimsun Next User’s Manual. Then in multi lane streets or roads, the lane changing model Modeling Vehicle Movement - Aimsun Next User’s Manual, and in unsignalised intersections the gap acceptance model Modelling Vehicle Movement - Aimsun Next User’s Manual. Last but not least the pedestrian model driven by a social force model that enables or simulate individuals pedestrians Simulating Pedestrians - Aimsun Next User’s Manual and Gap Acceptance Model for Pedestrians at Traffic Signals - Aimsun Next User’s Manual. Expected inputs ● Network general geometric data: To set up a simulation model a representation of the network is required, including the links, nodes and turnings. This can be imported from various sources or preexisting simulation models. ● Traffic light operational features: traffic lights timing and control schemes need to be introduced into the simulation platform. ● Demand data: origin destination matrices by transportation mode are required. ● Public transportation: if any effects of the public transportation vehicles moving through the network are required, then the public transportation data, including, paths, stops and schedule are needed. Open GTFS is typically enough. ● Traffic flow data: in order to validate traffic models, at least traffic flow count at some key locations is needed, speeds and density or occupancy values are appreciated. ● Behavioural data: for highly detailed model calibration users’ behavioural data like trajectories, acceleration or speed profiles are necessary. Input data sources ● Open-source data: network information can be gathered from OSM, public transportation from GTFS, an many times there are public AADT. ● Project partners: are expected to provide detailed data like Origin Destination matrices and complimentary data to the open-source data. phoebe-project.eu Copyright © by PHOEBE 85 Technical sheet Traffic Simulation ● Use case stakeholders: are expected to provide details on the infrastructure changes to model and some additional data to enrich the data already obtained from open source and project partners. Expected outputs ● Calibrated simulation models: Aimsun Next simulation models to assess the what if scenarios around the zones of interest. ● Dynamic traffic parameters: from the simulation models the three main traffic variables will be available as time series (fluctuating over time). These are: flow, speed and density. ● Vehicles trajectories: this will enable an in-detail analysis of the conflicts that arise at different places of the network as well as the use of Surrogate Safety Measures with software packages like SSAM. PHOEBE Framework Dependencies (what is this dependent on happening before) ● Data: to develop the Aimsun models a significant amount of data is required, this is already explained in the expected inputs, but the PHOEBE framework dependencies are: ○ iRAP star rating data ○ Mode choice models ● Behavioural models: calibration of simulation models is dependent on the behavioural models used to perform the simulation; thus, modelling cannot be completed until the behavioural models to use are fully developed. PHOEBE Framework Predecessors (what does this inform) ● iRAP dynamic star rating: to develop dynamic star rating, simulation is needed to test different scenarios. ● Mode choice iterations: to asses the optimal mode choice split the simulation platform needs to be ready. Equipment (Software requirements) ● Aimsun Next 23 ● Python 3.10 and the optional libraries needed (this will depend on the PHOEBE project development) License requirements (if any) ● Adequate Aimsun licence. Aimsun is a proprietary software that needs a licence to be used. There are different tiers of licences, depending on the modules needed PHOEBE developments ● Simulation model with integrated PHOEBE modules ○ Simulation model development ○ Integration of new behavioural models ○ Integration of the mode choice model ○ Integration of the iRAP star ratings into a simulation platform ○ Integration of the new dynamic star rating phoebe-project.eu Copyright © by PHOEBE 86 Technical sheet Mode choice and modal shift models Models Description Discrete choice models: The discrete choice models will be deployed to forecast the mode choice of the individual scenarios, including the modal shift between two scenarios. Discrete choice models specify the probability of choosing an alternative (out of all the alternatives available) by a group of individuals (out of all the groups under consideration). A suitable model type will be chosen, considering the input data. Expected inputs ● Stated-Preference (SP) survey data: The SP survey data (stated preference) will be an essential input to the model. Through the stated preference surveys, hypothetical situations are presented to the respondents, who are then asked to choose based on the given attributes for each alternative without necessarily experiencing them in real situations. ● Revealed Preference (RP) data: The RP data capture travellers’ current or revealed travel behaviour. For instance, one is interested in knowing the mode a traveller uses, travel times, and destinations. ● Travel diaries: A travel diary is an individual's record of his or her travels. This essentially is a type of revealed data. ● Telematics data: The telematics data capturing location, speed, fuel consumption, vehicle faults, etc., will be used as inputs for the model. ● Demographic data: Demographic data containing details like age, gender, location, household information, car availability, etc., will be used as input for the model. ● Count data: Count data, e.g., the number of vehicle trips, vehicle miles travelled, the number of person miles travelled, etc., will be used for calibrating the model. Input data sources ● SP data: The SP data will be gathered from surveys. ● RP data: The RP data can be gathered from several sources: ● From travellers’ travel diaries ● Operational data revealing the preferences of the travellers from the road authorities ● Travel diaries: From surveys. ● Telematics data: From professional data providing companies, local authorities. ● Demographic data: From local authorities, census etc. ● Count data: From professional data providing companies, local authorities. Expected outputs The model is expected to deliver the probabilities of choosing different alternatives by different groups of individuals. These probabilities can then be used to generate the OD matrices for all the individual groups using all the alternatives. phoebe-project.eu Copyright © by PHOEBE 87 Technical sheet Mode choice and modal shift models PHOEBE Framework Dependencies (what is this dependent on happening before) Before model estimation: The models have a dependency on the quality and type of the input data. After model estimation: After model estimation, the calibration of the model depends on the quality and type of the count data. Interscenario dependencies: The models will have dependencies on all the steps and models that can alter the input or explanatory variables of the mode choice models, e.g., Travel time, cost, number of transfers, speed etc. PHOEBE Framework Predecessors (what does this inform) Surveys and other input data. Equipment (Software requirements) BIOGEME: Pythonand Pandas-based open-source software. Apollo: R-based open-source package. MS Excel, AIMSUN (travel demand modelling software) License requirements (if any) AIMSUN PHOEBE developments As part of the PHOEBE developments, the mode choice models are planned to: ● Reflect the multidimensionality of human behaviour while choosing modes, e.g., personal preferences, socioeconomic characteristics, attitudes, cultural influences, driver characteristics, response times, adaptation behaviours, and psychological factors. ● Incorporate the perception of risks associated with modes while choosing modes. ● Reflect the spatiotemporal characteristics of mode choice. ● Incorporate the effects of the real-time information flow through apps and internet in mode choice. ● Incorporate the VRUs in mode choice framework. phoebe-project.eu Copyright © by PHOEBE 88 Technical sheet Road Assessment Methodology Models Description iRAP Star Rarting Methodology Road inspection data to provide a simple and objective measure of the level of safety 'built-in' to the roads for vehicle occupants, motorcyclists, pedestrians and bicyclists. iRAP Fatal and Severe injuries estimation methodology Fatal and Serious Injury (FSI) Estimates draw on the road attribute data used for Star Ratings, flow data for each road user and network-level crash data to provide an estimation of FSIs along each segment of a road and support localised prioritisation of investment. CycleRAP Road safety risk model for bicycle and light mobility users to evaluate the risk of incidents of road and bicycling infrastructure. Expected inputs • Enriched Geometry data: encoded road-related attributes each detailing the immediate road environment and risk influencing attributes for road segments. The attributes to be recorded can be found on the iRAP Coding Manual (left hand drive and right hand drive versions). • Operational data: speed and flows Guidelines on how to traditionally collect speed and flow data for static Star Rating analysis can be found at iRAP Survey Manual. • Georeferenced crash data by road user category (vehicle occupants, motorcyclists, pedestrians and bicyclists) and crash type (run-off passenger and driver side, head-on for loss of control or overtaking, intersection, property access, along, crossing inspected or intersected road). Crash data input format can be found at the iRAP Star Rating and Investment Plan Manual Road user category and crash types considered in the analysis can be found at iRAP Methodology Fact Sheet #4 Crash types Input data sources • Road feature data recorded from video survey or from an AiRAP data supplier • Operational data on speed and flows can be taken from local authority data when present, road operation measurement or use of data suppliers providing measured speed and flow data (for example The Floow or O7 may provide measures road speed or other data to support the model) • Crash data from road authorities All data need to be compatible with iRAP specification available at: https://irap.org/specifications/ More details on the input data for the PHOEBE project can be found at PHOEBE Deliverable 2.1 - Consolidated data requirements and use case region data availability report. phoebe-project.eu Copyright © by PHOEBE 95 GANTT chart for road safety assessment enhancements – Part 2 GANTT chart for traffic microsimulation enhancements