Method and device for traffic simulation

Abstract

To provide a method and a device for traffic simulation.SOLUTION: A computer-implemented method for traffic simulation includes: accepting input of traffic data including data regarding a geographic region; using the traffic data to generate a plurality of agent objects, each of which represents a traffic participant and associated data; assigning the plurality of agent objects to a plurality of respective processing units; running, on each parallel processing unit, a traffic simulation model for simulating the behavior of the traffic participants, in which the traffic simulation model includes a car-following model, and the traffic simulation model includes a lane change model and / or a junction management model.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to traffic simulation, and more particularly to a traffic simulation method, an associated data processing apparatus, a computer program product, and a computer-readable storage medium. [Background technology]

[0002] There is a trend where the real world can be represented as a digital world. Concepts such as smart cities, digital twins (DT), and the metaverse are receiving particular attention, due at least in part to new and improved technologies that enable advances within these concepts, such as technologies related to the Internet of Things (IoT), the fifth generation technology standard for telecommunications (5G), artificial intelligence (AI), and quantum computing.

[0003] Smart transportation systems are used to deliver a wide range of services to diverse users at scale in real time (or at least fast enough for effective action to be taken) for transportation improvements. It is desirable for the system to deliver a wide range of services created by complex processing of primarily real-time sensory data obtained from sources within (or serving) the transportation network (e.g., from roads and vehicles). Services are often requested in "real time" so that immediate action can be taken by users of the services. There are diverse data sources that generate different types of data at different rates. Services are also diverse and complex, using data in a wide range of different ways.

[0004] As an example, a large city's transportation authority could create a simulation in the form of a system of transit vehicles (DT) that provides a real-time virtual model of traffic flow throughout the city. The virtual model could be driven by data generated in real time from a wide variety of sources, including vehicle movement from in-vehicle GPS, roadside sensors, CCTV analysis, routing requests, live public transport dispatch, etc.; infrastructure status and operation such as traffic signals; and people movement from mobile GPS, ticketing activity, CCTV, etc.

[0005] Agent-based modeling (ABM) is a computational modeling framework for simulating the actions and interactions of autonomous agents (both collective entities, such as organizations or groups, and individual entities). ABM allows computational social scientists and others to simulate a wide range of empirically observed phenomena within a computational sandbox environment, stress-testing systems before adoption. Typically, an agent-based model consists of two components: an agent and an environment. An agent is an autonomous individual, often described as a software object that represents individual-level behavior. For example, an agent can represent a person with characteristics such as age, height, and weight. The environment represents some constrained space within which the agent operates, which may be abstract or based on empirical data from the built environment. Due to its widespread interdisciplinary adoption, challenges to the ABM approach have been identified and explored in detail. One of the most prominent of these is the computational tractability of simulating intensive tasks. To overcome this challenge, modelers sometimes choose to simplify complex representations of real-world systems by approximating complex behavior or reducing the population of agents, at the expense of simulation results.

[0006] Modern ABMs consist of rule-following agents (typically encoded as algorithms) that dynamically interact with their environment and / or each other. The state of each agent is typically contained in their state variables, which can be modified based on the agent's interactions. The agents simulate local (microscopic) interactions that can lead to complex emergent phenomena at various spatiotemporal scales. The recent increase in the availability of computational power has increased the uptake of such methods and greatly increased their popularity in research.

[0007] Microscopic ABM takes a detailed, bottom-up approach to modeling vehicular traffic. Unlike macroscopic models that focus on the overall traffic flow, microscopic ABM treats individual vehicles (and sometimes pedestrians) as independent agents with their own characteristics and decision-making capabilities. This allows for a more realistic simulation of traffic behavior, taking into account factors such as individual driver behavior (each agent has different levels of aggressiveness, patience, and skill, resulting in diverse driving styles), vehicle characteristics (different vehicle types (cars, trucks, motorcycles) have different acceleration, deceleration, and turning capabilities), environmental factors (traffic signals, lane markings, road geometry, and weather conditions all affect agent behavior), and interactions between agents (agents react to each other's actions, such as lane changes, braking, or merging, resulting in emergent traffic phenomena such as congestion and bottlenecks).

[0008] Current state-of-the-art (SOA) traffic simulation techniques use a central processing unit (CPU) to perform vehicle state calculations (a computational representation of the current configuration of vehicle agents at some time t) and to traverse decision trees that select strategic and tactical vehicle behaviors (accelerate, decelerate, stop, etc.). The CPU is configured to execute computer program instructions, such as arithmetic operations, logical operations, control actions, and input / output (I / O) actions.

[0009] Current SOA solutions for microscopic-level computer modeling of large-scale transportation systems face computational complexity challenges when the method involves a significant number of agents (e.g., code representing vehicles or pedestrians). This makes it impossible to achieve a real-time simulation and modeling solution using a CPU, as the computational speed drops below the mark where the real-time factor equals 1 (i.e., 1 virtual second is simulated per clock second). The nonlinear nature of the growing complexity, combined with current hardware available, makes it virtually impossible to compensate purely by adding more computational resources. Summary of the Invention [Problem to be solved by the invention]

[0010] Accordingly, the present inventors have come to recognize that there is a need for techniques that provide improved realistic simulation of scenarios in digital representations of the real world. [Means for solving the problem]

[0011] According to one aspect of the present invention, there is provided a computer-implemented method for traffic simulation, comprising: accepting input traffic data including data about a geographic region; generating a plurality of agent objects using the traffic data, each agent object representing a traffic participant and associated data; assigning the agent objects to respective processing units used in parallel; and running, on each parallel processing unit, a traffic simulation model for simulating the behavior of the traffic participants, the traffic simulation model including a car-following model, a lane-changing model, and / or a junction management model. [Brief explanation of the drawings]

[0012] Reference will now be made, by way of example only, to the accompanying drawings in which: [Figure 1] 1 is a flowchart of a general method for traffic simulation according to an embodiment. [Figure 2] Schematic representation of a modular computing architecture suitable for implementing aspects of the method for predicting the evolution of traffic simulation. [Figure 3] 1 is an exemplary ABM simulation computational pipeline using known techniques. [Figure 4] FIG. 1 is a schematic diagram of an exemplary location update process using known techniques. [Figure 5] 1 is an exemplary ABM simulation computational pipeline using a traffic simulation method according to an embodiment. [Figure 6] FIG. 2 is a schematic diagram of an exemplary location update process using a traffic simulation method according to an embodiment. [Figure 7a] 1 is a benchmark result showing performance metrics for an implementation of a traffic simulation method according to an embodiment and known technology. [Figure 7b] 1 is a benchmark result showing performance metrics for an implementation of a traffic simulation method according to an embodiment and known technology. [Figure 7c] 1 is a benchmark result showing performance metrics for an implementation of a traffic simulation method according to an embodiment and known technology. [Figure 7d] 1 is a benchmark result showing performance metrics for an implementation of a traffic simulation method according to an embodiment and known technology. [Figure 8] 1 is a block diagram of a computing means for implementing a method according to an embodiment; DETAILED DESCRIPTION OF THE INVENTION

[0013] Current SOA traffic simulation algorithms are typically built around discretized ordinary differential equation (ODE) solvers to update the speed and position of vehicles (or traffic participants), e.g., Simulation of Urban Mobility (SUMO) (Krajzewicz et al., 2012). Each vehicle state is updated sequentially throughout each simulation step. This is expected to exhibit a complexity growth of at most O(n), where n is the number of vehicles being simulated. While this is a modest growth factor, without parallelization, larger simulation models quickly face scalability issues and become computationally intractable for real-time simulation requirements.

[0014] Much DT (and indeed any kind of simulation) focuses on replicating complex systems from the real world. The problem with real-world problems is that they involve large populations of individual entities, such as people driving or walking around a city, and the sophisticated processes that these entities undergo. In order to simulate these complex systems in real time, computational tractability must be overcome, and this is where past solutions have struggled.

[0015] The present solution addresses a wide range of applications, from the areas of transportation and logistics to predictive analytics, data science, and social DT implementations. The invention is defined in the independent claims. Particular embodiments are defined in the dependent claims.

[0016] According to one aspect of the present invention, a computer-implemented method for traffic simulation is provided. The method includes accepting traffic data input. The traffic data may be vehicle data and / or pedestrian data. The traffic data may include data obtained from one or more sensors within a given geographic area (the area of ​​the traffic simulation). The traffic data may further include data related to current or upcoming weather, seasons, predetermined events (such as concerts or sporting events), mobility flows, and correlated patterns of traffic from other geographic areas (adjacent and non-adjacent geographic areas). The traffic data may be related, for example, to survey data indicating business or public transportation system use of road segments.

[0017] The method includes generating a plurality of agent objects. This step is performed using traffic data. Each agent object represents a traffic participant and associated data for that traffic participant. For example, an agent object may be a software object representing the behavior of a single vehicle (the associated data includes the vehicle's speed and position) or a software object representing a segment of a road within a geographic region. Depending on the complexity of the simulation, there may be hundreds or thousands of agent objects.

[0018] The method includes assigning each of the agent objects to one or more of a plurality of processing units. These processing units may be, for example, of or within a graphics processing unit (GPU), a specialized electronic circuit originally designed to accelerate computer graphics and image processing (on a video card or embedded on a motherboard, mobile phone, personal computer, workstation, or game console). A processing unit may be an individual core, a group of cores, a thread, a thread block, or a warp of parallel threads.

[0019] The method includes running a microscopic traffic simulation model in parallel for each processing unit and each assigned agent object (e.g., a first processing unit runs a traffic simulation for a first assigned agent object, and substantially in parallel, a second processing unit runs a traffic simulation for a second assigned agent object). In this manner, the method simulates the behavior of traffic participants as represented by the agent objects. In this context, a microscopic traffic simulation or flow model is a mathematical traffic model that simulates a single vehicle driver unit, and thus the dynamic variables of the model represent microscopic characteristics such as the position and speed of a single vehicle. Traffic simulation models include car-following models used to model or determine how traffic participants (e.g., vehicles or pedestrians) follow each other on a road or path. For example, the model can determine the speed of a vehicle relative to a vehicle ahead.

[0020] The traffic simulation model further includes at least one of a lane change model and a junction (or intersection) management model. The lane change model is used to determine speed adjustments associated with lane selection and lane changes on multi-lane roads. The junction management model is used to determine the behavior of traffic participants at various types of intersections, for example, with respect to right-of-way rules, gap acceptance, and avoidance of junction blockages.

[0021] Without changing the general underlying microsimulation principles utilized in current SOA, the techniques herein shift the computational load from the computer's CPU, which has the limitations described above, to more devices with multiple processing units that can be used or operated in parallel, such as GPU devices, thus ensuring the speed and scalability of the traffic model.

[0022] The techniques herein provide data inputs and outputs that allow reading real-world traffic networks, recognizing agent origin and destination data and agent descriptions, as well as other adjacent process descriptions and algorithms within a traffic simulation model.

[0023] For example, a microsimulation model may be converted from a system of ordinary differential equations (ODEs) into an equivalent agent behavior description and encoded into a template-based ABM framework, allowing a traffic model to process each agent's calculations through cores on a GPU. GPUs handle calculations more efficiently and have an inherent ability to parallelize computations. In this way, GPUs can be used as general-purpose GPUs (GPGPUs), where general-purpose computing is performed on the GPU to perform calculations in applications traditionally handled by CPUs.

[0024] CPUs are limited because they are not optimized to perform the algebraic operations required to solve technical problems, nor do they have a large number of cores for parallel computing. CPUs typically have limited memory capacity compared to specialized hardware like GPUs or tensor processing units (TPUs). Large-scale simulations can generate significant amounts of intermediate data, and CPUs can struggle to manage this data efficiently, resulting in potential memory-related performance issues.

[0025] Horizontally scaling a CPU-based simulation by adding more CPU nodes can introduce complexities and challenges related to communication and synchronization between nodes. Developing software that efficiently utilizes the power of multi-core CPUs for simulation is another significant hurdle, as it involves writing inherently complex and error-prone parallel code that optimally utilizes all available CPU cores and manages data dependencies.

[0026] The techniques herein enable users to build real-world transportation network simulations on an unprecedented scale. These techniques enable simulations to operate at speeds that exceed real-time modeling, thereby significantly increasing the efficiency and effectiveness of the simulation process.

[0027] Known simulation engines are hampered by scalability issues that limit their ability to model complex, large-scale systems. The technology herein effectively eliminates these scalability constraints, allowing users to simulate large-scale transportation networks without compromising the quality or accuracy of the results.

[0028] Those skilled in the art will appreciate the applicability of the techniques herein to fields such as transportation planning and engineering. These techniques can be used to evaluate the impact of road infrastructure changes, traffic management strategies, and public transportation services. In the field of autonomous vehicle development, the techniques herein can provide for testing and evaluating the behavior of self-driving cars in simulated environments. In the field of urban planning, the techniques herein allow for studying the impact of transportation systems on land use, air quality, and energy consumption.

[0029] Beyond transportation networks, the techniques herein may be extended to model other systems for the benefit of the public. This versatility makes this approach a valuable asset to a variety of industries and sectors seeking to simulate and optimize a variety of complex systems.

[0030] Furthermore, the techniques herein address a significant technical shortcoming commonly observed in the ABM literature within academia: lack of computational power and scalability.

[0031] Optionally, running the traffic simulation model includes iteratively updating the state of the agent object based on the particular agent object's associated data (e.g., speed and position of a vehicle agent object) and interactions with other agent objects (or their associated data). This iterative updating may be performed until some predetermined simulation termination criterion (e.g., a preset duration, number of iterations, or a preset level of convergence) is met or reached.

[0032] Optionally, multiple processing units may be able to access a single pool data structure. Each processing unit may then update agent object variables in the pool data structure when executing the traffic simulation model. For example, a processing unit may update agent object variables, such as speed or position, for the traffic participant represented by its agent object. Each processing unit may access agent object variables in the pool data structure. For example, a processing unit may access agent object variable values ​​for itself (i.e., the traffic participant represented by its agent object) and for other agent objects in the simulation. That is, an agent object may locally access variables or other agent objects (i.e., the agent object may access its own state / variables stored in the pool). As an example, iterative updating of an agent object's state may include multiple agent objects accessing the above-mentioned pool data structure.

[0033] Optionally, the processing units may be hosted, at least in part, on one or more remote servers. That is, the processing units may be cloud-based. In this way, it is possible to simply increase the number of cores by forming a cluster of GPUs, thereby postponing the point at which increased simulation complexity begins to affect speed. In this regard, high-performance computing (HPC) clusters may be used. Of course, a combination of local and remote processing units may also be utilized.

[0034] Optionally, if the simulation incorporates more agent objects than available processing units, the step of allocating the plurality of agent objects includes forming a processing queue for the processing units (and subsequent simulation runs thereof), i.e., running the traffic simulation model with respect to a first group of agent objects may occur before running the traffic simulation model with respect to a second group of agent objects.

[0035] Optionally, the traffic data accepted as input includes a description of the traffic network. This description may be represented in a compressed sparse row and / or compressed sparse column representation. These aspects of representing the environment data structure as a graph structure ensure high-performance access to this data during simulation runtime and allow efficient querying of both upstream and downstream edges in the graph (edges represent road or route segments, which in this context may be agent objects).

[0036] Optionally, the transportation data includes data obtained from or corresponding to a digital twin (DT) of the geographic area under consideration. The method thereby creates a comprehensive and realistic DT, providing a high level of reliability and accuracy in modeling real-world systems. A DT in this context is a digital model of a transportation system that serves as a virtually indistinguishable digital counterpart of the transportation system for purposes such as simulation, integration, testing, monitoring, and maintenance of the real system.

[0037] Optionally, the traffic data includes sensor data. This sensor data may be obtained in real time from any or all of the following: GPS sensors or antennas, cellular network sensors or antennas, loop sensors, camera sensors, and vehicle parking sensors. The sensors may be on-board sensors, such as GPS or cellular (telecommunications) sensors located in or on a vehicle or pedestrian and configured to transmit the vehicle's or pedestrian's location. Antenna signal triangulation may be used to determine traffic location. Along with GPS and cellular data, any other floating vehicle data may be used as appropriate. Camera sensors may be used to remotely store image data, based on which image processing techniques such as object detection may be used to provide vehicle or pedestrian positioning data. Vehicle parking sensors (which may be on-board or remote from the vehicle) may be used to indicate the vehicle's parking location, thereby providing, for example, parking facility occupancy levels. Of course, the sensor data may also be historical sensor data representing the traffic system at some point in the past.

[0038] Optionally, the car-following model may calculate the velocity v and position x of a vehicular traffic participant from time t over time steps Δt as: v(t+Δt)=max[0,v des (t)-η] x(t+Δt)=x(t)+v(Δt) The information may be updated according to the following. where v des is the maximum speed that conforms to given traffic constraints, and η is a random speed perturbation that allows deviation from optimal driving. One such implementation of this car-following model is the Krauss car-following model, which facilitates a collision-free environment. Of course, alternative car-following models may be used, including the Gipps model (Gipps, 1981).

[0039] Optionally, the method may include running two or more different scenarios in parallel for comparison purposes. For example, the method may include modifying variables of multiple agent objects to generate multiple modified agent objects that reflect some modification in a geographic region. For example, a user may wish to simulate the potential effects of a road closure or a change in speed limit and modify the variables accordingly. The method may then include assigning the multiple modified agent objects to respective multiple processing units, e.g., within a GPU. For each processing unit, in parallel, the method may include running a microscopic traffic simulation model to simulate the behavior of traffic participants with modifications in the geographic region. In this way, each scenario may be investigated to see what could happen in the traffic network during the simulated period. By running these versions of the simulation in parallel with each other, the results of all scenarios can be evaluated faster than they would unfold in real time.

[0040] An embodiment of another aspect of the present invention includes a data processing apparatus comprising a memory, a plurality of processing units, and means for accepting input, the memory storing computer-executable instructions for performing a computer-implemented method for traffic simulation, the plurality of processing units and the means for accepting input configured to execute the instructions.

[0041] Another aspect of the present invention includes a computer program comprising instructions that, when executed by a data processing apparatus, cause the data processing apparatus to perform a computer-implemented method for traffic simulation.

[0042] An embodiment of another aspect of the present invention includes a non-transitory computer-readable storage medium containing instructions that, when executed by a data processing apparatus, cause the data processing apparatus to perform a computer-implemented method for traffic simulation.

[0043] The invention may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them.The invention may also be implemented as a computer program or computer program product, i.e., a computer program tangibly embodied in a non-transitory information carrier, for example a machine-readable storage device or a propagated signal, for execution by, or to control the operation of, one or more hardware modules.

[0044] A computer program may be in the form of a stand-alone program, a computer program portion, or two or more computer programs, may be written in any form of programming language, including compiled or interpreted languages, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a data processing environment. A computer program may be deployed to be executed on one module or on multiple modules at one site, or may be distributed across multiple sites and interconnected by a communications network.

[0045] The method steps of the present invention may be performed by one or more programmable processors executing a computer program that performs the functions of the present invention by operating on input data and generating output. The apparatus of the present invention may be implemented as programmed hardware or as special purpose logic circuitry including, for example, an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit).

[0046] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor receives instructions and data from a read-only memory or a random access memory or both.

[0047] The present invention has been described with reference to specific embodiments. Other embodiments are within the scope of the following claims. For example, the steps of the invention can be performed in a different order and still achieve desirable results.

[0048] Elements of the present invention have been described using the terms "processing unit" and "means for accepting input." Those skilled in the art will understand that such functional terms, and their equivalents, may refer to spatially separated but combined system portions that perform a defined function. Similarly, the same physical portion of a system may provide two or more of the defined functions. For example, separately defined means may be implemented using the same memory and / or processor, where appropriate.

[0049] FIG. 1 provides an overview of a general method for traffic simulation that addresses the aforementioned shortcomings of known simulation techniques. At S11, a computing means implementing the general method accepts traffic data input, including data about a geographic region. At S12, the computing means generates a plurality of agent objects using the traffic data. Each agent object represents a traffic participant and data associated with that traffic participant. At S13, the computing means assigns the plurality of agent objects to respective processing units. At S14, in parallel for each processing unit, the computing means executes a microscopic traffic simulation model to simulate the behavior of the traffic participants. Of course, all agent objects and associated traffic participants are simulated when each processing unit executes its own iteration of the traffic simulation. The traffic simulation model includes a car-following model. In addition, the traffic simulation model includes either a lane-changing model or a junction management model (or both).

[0050] Figure 2 is an example simulation pipeline for a known technology (i.e., SUMO). A description of the traffic network, some form of origin-destination (OD) data for traffic participants, and descriptions of behavioral entities (e.g., vehicles or pedestrians) form a general model of the evolution of the system state (using Krauss's car-following model framework). Using a software interface (e.g., an API), this general model is processed using a conventional CPU. When the simulation finishes (e.g., after a predetermined number of iterations or a predetermined duration), the pipeline outputs the final state of the system.

[0051] FIG. 3 provides a schematic diagram of the vehicle position update process in known techniques. Known techniques take n (number of vehicles) steps, each with a time step of Δt, to sequentially update vehicle positions and velocities. This implies an increase in complexity of at least O(n) from the point at which a single vehicle is inserted into the simulation. In the illustrated example, vehicle 1 communicates with the CPU and requests to change state; it then receives the updated state variables and communicates them to the following vehicle (vehicle 2), in this case. The following vehicle similarly communicates its own variables to lead vehicle 1. Only when vehicle 1 has been updated does the process move on to vehicle 2, which undergoes the same process as vehicle 1. After n iterations, all n vehicles have updated state variables, completing one time increment Δt of the traffic simulation.

[0052] Figure 4 illustrates an exemplary computational pipeline using the techniques herein. A microsimulation model (Krauss car-following model) is transformed from a system of coupled ODEs into an equivalent description of agent behavior and encoded into a template-based ABM framework. This allows the model to process the computations for each agent through cores on a GPU. GPUs handle computations more efficiently and offer inherent capabilities for parallelizing computations.

[0053] Figure 5 provides a schematic diagram of the vehicle position update process in a method according to one embodiment. In this implementation, Krauss's car-following model is converted into an ABM-compatible description and a GPU-enhanced ABM framework is used to interface the model with a GPU. The referenced framework ensures the ability to perform parallel computations for all agents present in the simulation by pooling their messages into a single structure that can be accessed by each agent at the time an update is required. Here, an agent telegraphs or communicates its speed and position to a pool data structure, giving it immediate access to variables left by its direct predecessor and follower. This allows the technique to simultaneously allocate each agent's update equation to a GPU core. Compared to Figure 3, this technique allows for a larger number of vehicles to be handled at any one time within a single time step Δt.

[0054] To satisfy a state change request, several functions must be performed. Each kernel launch operates on a grid of threads formed for concurrent execution. At least in NVIDIA-based implementations, the grid is divided into blocks and assigned to SMs for execution.

[0055] In a working implementation of the techniques herein, we combine the principles of Krauss' collision-free car-following model (described by coupled ODEs) with a GPU-enhanced agent-based modeling framework to provide parallel computing power that enhances current SOAs for traffic simulations in terms of scalability. Those skilled in the art will, of course, understand that other car-following models may also be parallelized. GPUs are chosen to provide multiple processing units because GPU-implemented frameworks offer superior speed and efficiency due to their parallel processing capabilities. GPUs can quickly perform complex calculations, making them ideal for large-scale simulations that require intensive computing power. This speed accelerates simulations, resulting in faster insights and results.

[0056] Faster simulations lead to shorter time-to-insight. Users can iterate simulations more quickly and explore a wider range of scenarios and hypotheses. Despite the potential initial cost, GPU-accelerated frameworks have proven cost-effective in the long term due to their speed and energy efficiency. They can complete simulations faster and reduce overall computing resource requirements.

[0057] The framework uses a template-based programming environment that provides tools for modeling and characterizing individual agents while utilizing multiple processing units to handle the necessary computations. The principles of the car-following model may be programmed individually for each agent. Agents simultaneously exchange messages containing the necessary input variables. This allows the speed and position of each agent to be updated in parallel, rather than sequentially, resulting in faster processing and more immediate simulation results.

[0058] In this working implementation, the computations required to update each agent's state are assigned to individual Compute Unified Device Architecture (CUDA) cores (floating-point units in NVIDIA graphics cards) within the GPU via a framework interface. CUDA is a proprietary, closed-source parallel computing platform and application programming interface (API) that allows software to use certain types of GPUs for general-purpose processing. CUDA cores are optimized to perform the required algebraic calculations with greater efficiency than traditional CPU cores. GPUs such as those from NVIDIA have thousands of cores and can be integrated into high-performance computing (HPC) clusters for seamless scaling effects. Of course, other GPUs from other manufacturers, including AMD and Intel, may also be used. While this approach does not change the computational complexity of the underlying simulation, the techniques herein significantly expand the GPU's ability to perform parallel computations, shifting the inflection point at which increased complexity begins to affect the simulation's execution speed. The more CUDA cores available, the farther the inflection point is shifted relative to the number of agents in the simulation.

[0059] In this work, the microscopic traffic simulation model is provided by the discretized ODE solver SUMO. Of course, other microscopic traffic simulation models and solvers are equally suitable, including AIMSUN (Casas et al., 2010), MATsim (W. Axhausen et al., 2016), ARCHISIM (Champion et al., 2001), and VISSIM (Fellendorf et al., 2010).

[0060] Although very stable, reliable, and well-developed software with diverse toolboxes and sophisticated user interfaces, current SOA solutions for microscopic-level modeling of large-scale transportation systems face computational complexity challenges when the models reach significant numbers of agents (e.g., swarm simulations). Thus, once the computational speed falls below the mark where the real-time factor equals 1 (1 virtual second is simulated in 1 clock second), real-time simulation and modeling solutions become unattainable. Due to the nonlinear nature of the growing complexity and current available hardware, it is impossible to compensate purely by adding more computational resources.

[0061] In this work, a mapping between the formal ABM agent specification for SUMO using C-based scripts and optimized CUDA code for GPU implementation is provided using the open-source software Flexible Large-Scale Agent Modeling Environment for GPUs (FLAME-GPU). FLAME-GPU is an agent-based simulation framework that leverages the parallel architecture of modern GPUs to improve the performance of simulations of complex systems. FLAME-GPU demonstrates this by abstracting the GPU and parallelism away from the modeler, providing separation of concerns and ensuring that models are described separately from their implementation. The performance improvements provided by the framework allow large models to be constructed and simulated in a reasonable amount of time. The framework presents a general approach to agent-based simulation and is not limited to any particular domain. It has been used for a wide range of simulation problems, including pedestrian simulation, simple road network simulation, and cellular models of biological systems. To utilize FLAME-GPU, modelers map their complex systems into abstractions of agents (representing individuals with internal memory), messages (allowing agents to communicate indirectly through a globally accessible message list), and the environment (representing information accessible to all agents in the system).

[0062] This model aims to reproduce traffic behavior at a microscopic level on a real-world traffic network. Each vehicle is modeled separately with respect to its speed and position while traveling along a street network that includes lanes, intersections, traffic signals, speed limits, and other real-world attributes that contribute to a vehicle's movement from one point on the network to another. Vehicles are expected to follow established rules while they are active in the simulation.

[0063] The proposed vehicle model behavior is based on a modified Krauss car-following model, i.e., the same microscopic simulation model used by SUMO. The Krauss car-following model is based on the collision-free principle, where the positions and velocities of agents are updated according to safety rules. The updates are considered safe if, for each step, a minimum distance is always maintained between agents (i.e., upholding the collision-free principle). The basic outline of the model can be expressed as follows: All vehicles must travel at a maximum speed v that complies with specified constraints. des Assuming you are moving with v(t+Δt)=max[0,v des (t)-η] (1) x(t+Δt)=x(t)+v(Δt) (2) The parameter η (>0) is a random speed perturbation to account for deviations from optimal driving. This perturbation can be assumed to be δ-correlated in time. The choice of the time step Δt may depend on the driver's reaction time τ.

[0064] The desired speed may be, for example, the maximum possible speed v max (i.e., the desired speed of the driver under consideration), the maximum safe speed v safe (i.e., the driver always selects a speed below the maximum safe speed). v des (t)=min[v maz ,v(t)+a(v)Δt,v safe (t)] (3) where a is the agent's acceleration. safe may be an empirically derived value or may be defined according to the following equation:

number

number

number

[0065] Lane-changing rules and intersection mechanisms follow those described in the works of Erdmann, J. ("SUMO's lane-changing model", 2014) and Erdmann, J. & Krajzewicz ("SUMO's road intersection model", 2011). These models build on previous models used in SUMO, adding interior junction support to better represent vehicle behavior while navigating complex intersections, as well as an improved and more complex hierarchy of lane and speed selection options, including strategic, tactical, cooperative, and regulatory triggers. These updated rule sets are used by default in the latest version of SUMO and are intended to improve the accuracy of an already reliable model.

[0066] SUMO's lane-changing model determines a vehicle's lane choice for a single simulation stem based on both the vehicle's route and the past and current traffic conditions around the vehicle, and calculates the necessary changes in speed for the vehicle and any obstacles to facilitate the execution of said choice. In this model, a road network consists of edges, which are unidirectional street segments with a fixed number of lanes and speed limits. Each edge consists of parallel lanes. A vehicle is defined by a route containing a set of edges, and during the simulation, it moves along the lanes with some freedom in choosing which lane to use (unless restricted). Connectivity is defined at the lane level, with each lane potentially connecting to zero or more other lanes. If a vehicle's current lane does not connect to the next edge on its route, it must change lanes to continue.

[0067] The lane-changing model considers the vehicle ahead (predecessor) to determine the vehicle's speed, whether in the same lane or the preferred next lane. The car-following model defines the speed of the following vehicle based on the preceding vehicle. A lane change is only possible if there is enough space in the target lane and the vehicle is not getting too close to the preceding or following vehicle in that lane (as defined by the car-following model). If these conditions are not met, the vehicle experiences a "blocking preceding vehicle" or a "blocking following vehicle."

[0068] Each simulation step contains several substeps for each vehicle. 1) Calculate the preferred next lane: The simulation identifies the most suitable lane to switch to in the future. 2) Safe Speed ​​Calculation: This step considers both staying in the current lane and potentially changing lanes, and integrates previous lane change requests. 3) Lane Change Decision: The model decides whether the vehicle should stay, change lanes to the left, or change lanes to the right. 4) Maneuver Execution or Speed ​​Requirement Calculation: Depending on the urgency of the lane change, the vehicle will either attempt the change or plan the speed for the next step taking into account the future lane change. Again, for a complete derivation and explanation of an example lane-changing model, please see the work of Erdmann, J ("SUMO's lane-changing model", 2014).

[0069] SUMO's junction management model represents intersections as nodes with incoming and outgoing edges (roads with one or more lanes). Inside an intersection, "interior lanes" connect incoming lanes to outgoing lanes. Vehicles travel through these interior lanes just like regular lanes. This allows for detailed vehicle tracking and intersection capacity modeling.

[0070] Each lane can have multiple potential next lanes, and these connections are defined by "links" that form a "lane graph" to which the lanes are connected. This graph is distinct from the "intersection graph" in which intersections are connected by roads.

[0071] At most intersections, vehicles wait at the stop line before entering, allowing them to cross without competing traffic. However, for certain situations, such as left turns, SUMO allows vehicles to wait in the center of the intersection. This is modeled by splitting the interior lanes and introducing "interior intersections" within major intersections. Vehicles using these lanes pass through the initial entry point and wait at the interior intersection instead. Right-of-way is determined at these interior intersections in the same way as at regular intersections.

[0072] Again, for a complete derivation and description of an example junction management model, please refer to the work of Erdmann, J. & Krajzewicz (“SUMO's road intersection model”, 2011).

[0073] The simultaneous equations (1) through (4), lane-change and intersection-crossing rules, and other rules required to update the system's state are represented as a set of agent functions. Agent variables required to execute functions are stored and exchanged through a global messaging pool (a feature facilitated by the FLAME-GPU design). Requests for system state updates are satisfied by launching a function kernel for every agent in the agent state population. Each agent is represented by a thread, and as a kernel is launched, a grid of threads is formed and then combined into blocks. The blocks are then assigned to available streaming multiprocessors (SMs) within the GPU for simultaneous execution. NVIDIA GPUs are built around an array of SMs, and multithreaded programs may be partitioned into blocks of threads that execute independently of each other, allowing GPUs with more processing units to automatically execute the program in less time than GPUs with fewer processing units. A kernel in this context is a program function that, when invoked, is executed N times in parallel by N different CUDA threads (not just once, as in a typical C++ function).

[0074] The number of threads is the maximum thread capacity of the GPU, N max Whenever the number of threads n is less than the GPU's maximum thread capacity N, the process can be expected to exhibit roughly O(1) complexity. max If more than c=n%, it takes roughly c=n%N to complete each kernel execution. max (n modulo N max ) steps, thus exhibiting O(c) complexity. This scheme does not fundamentally change the time complexity of the algorithm, but allows for a smooth and efficient computational scaling process.

[0075] To postpone the point where increasing algorithm complexity begins to affect speed, it is possible to increase the available thread capacity by accessing a cluster of GPUs. One way to do so involves the use of high-performance computing (HPC) clusters for deep learning, which are now available for on-demand access via a number of cloud services.

[0076] Figure 6 shows an example resulting simulation pipeline. Note that the current implementation of the traffic simulator accepts the same input files as SUMO. This facilitates straightforward testing, validation, and comparison. Nodes connected by solid lines represent agent states. For example, "VehicleDefault" represents an agent object corresponding to a vehicle with default configuration settings (e.g., default value for maximum speed). As mentioned above, agent objects not only correspond to moving traffic participants, but may also represent static traffic participants such as traffic signals, or abstract routines such as the "pre-insertion" of a moving traffic participant (e.g., the entry of a new vehicle into the geographic area under consideration).

[0077] Nodes surrounded by dashed lines represent agent functions that are responsible for the behavior of an agent object. For example, the agent function "OutputLocation" represents the instruction provided to an agent object to output the location coordinates of that agent object (e.g., to a shared data pool accessible by all processing units).

[0078] Nodes surrounded by dashed-dotted lines represent messages that create execution order dependencies between agents and functions; that is, they are data requests. For example, the data request "PreMoveLocation" is a data request for the location of the vehicle agent object of interest before any lane change or movement along the road segment.

[0079] To translate a transportation model into the FLAME-GPU framework, a network-based messaging approach may be adopted for the majority of agent communication. This approach allows agents to exist in a static multi-lane network by using the network structure to query agents in the same or adjacent edges or lanes. Both compressed sparse row (CSR) and compressed sparse column (CSC) representations of the network may be stored within the agent environment, allowing efficient querying of both upstream and downstream edges. Network lookups may be used for computations to find following and preceding vehicles (components traversing the network and entering junctions). Other uses of network communication include in the context of vehicle following, lane changes, and vehicle insertions. Within the FLAME-GPU implementation, the vehicle is able to make dynamic lane selections but still use pre-computed routes to reach its destination; equivalent behavior is observed from within SUMO by using an equivalent route file generated from the SUMO routing tool.

[0080] The FLAME-GPU model uses agents to represent vehicles. SUMO model parameters and distributions may be mapped to FLAME-GPU agent variables. Vehicle agents in this working implementation have three distinct states. The default state is "driving," in which the agent performs call following, lane changes, and junction crossings. Vehicles also utilize states for pre-insertion and pre-removal from the network. The former uses gap acceptance to ensure that the vehicle can safely enter road edges, while the latter allows the agent to persist within the model for data collection purposes. Agents may be used to represent sections of the road network (and thus not the moving traffic participants themselves). This facilitates data aggregation and collection. Additionally, agents may be used to represent traffic lights that use fixed patterns (e.g., on or off) within the FLAME-GPU model.

[0081] The techniques herein can be used for any ABM simulation implementation. A straightforward example involves feeding traffic data in a SUMO-compatible format into several instances of a simulation. Each simulation instance can represent a scenario of what could happen in the transportation network during the simulated time period. These instances of the simulation can be run in parallel, faster than real-time deployment, to evaluate the outcomes of all scenarios. Those skilled in the art will understand that the techniques herein can be used, for example, in the fields of urban management, smart city development, statistical modeling, environmental research, and logistics management.

[0082] As an example implementation, we demonstrate the applicability to real-world transportation networks. The purpose of the following example is to quantitatively demonstrate the computational scalability of the proposed solution to simulating large-scale agent-based models, using vehicular traffic as the domain of exploration. A quantitative metric used in the past is the real-time factor (RTF). RTF can be described as the quotient of simulated time and computation time; if 1 hour is simulated in 360 seconds, the real-time factor is 10. An RTF greater than 1 indicates that the simulation is running faster than real time, while an RTF less than 1 indicates that the simulation is running slower than real time. We employ this metric to directly benchmark our technology against SUMO's technology. Therefore, our example experiments are conducted on both platforms using the same hardware and parameter inputs. SUMO was chosen as the benchmark model because of its widespread adoption in research.

[0083] It is common to test traffic simulation engines on artificial grids. Artificial networks have regular repeating patterns that result in relatively consistent performance characteristics. The techniques described herein can handle the scale of complex simulations, but also the complexity associated with real-world networks, which are much more diverse and heterogeneous in their characteristics.

[0084] The network chosen for this exemplary experiment is the Isle of Wight transport system. This system was chosen because it can effectively be viewed as a small testbed with sufficient network complexity to present real-world traffic modeling challenges. There are several caveats to mention. First, working with a real-world network prevents researchers from being able to procedurally scale its size. Second, high-quality real-world data on vehicles moving around road networks is difficult to obtain. Therefore, to populate the network, random trip generation utilities developed to accompany SUMO simulations are used, namely the randomTrips and duarouter functions. To scale the simulation, the vehicle insertion density parameter is varied in increments of 60 for the first 360 seconds, starting from 60 cars per hour per kilometer of the road network to 600 cars per hour.

[0085] Each simulation is repeated three times, and the average value is presented as the output. The simulation run is initialized at time step 0 and terminated at time step 3600 (corresponding to 1 hour). The machine used to perform the experiments has the following specifications: Intel Core i7-5930K, NVIDIA GeForce RTX 3090 (24 GiB), 64 GB host memory. The machine used is running Ubuntu 20.04.6 LTS.

[0086] FIG. 7 shows four sub-views comparing a method according to an embodiment with conventional SUMO.

[0087] Figure 7a plots RTF on a logarithmic scale (y-axis) and compares the method according to the embodiment with SUMO (using FLAME-GPU). While SUMO shows a decrease in performance as the number of vehicles in the simulation increases, the method according to the embodiment maintains a high RTF, achieving an average of approximately 99 at the end of the simulation compared to SUMO's 1.45. These results demonstrate that the techniques herein can simulate a larger population of vehicles in a significantly shorter time than SUMO.

[0088] Figure 7b complements these findings, displaying the average simulation time in seconds as the number of vehicles increases. SUMO takes over 2,481 seconds (41.35 minutes) to simulate approximately 95,000 vehicles, while the method according to the embodiment completes the simulation in approximately 36 seconds, representing approximately a 68x speedup. Furthermore, while SUMO's simulation time increases linearly with the number of vehicles, the time using the method according to the embodiment remains relatively consistent.

[0089] Interactions between agents and their environment can become computationally intensive as the number of agents increases. Figure 7c compares updates per second (number of state changes across all agents per second) with the number of vehicles in the model. While interactions grow linearly with the number of vehicles for the method according to the embodiment, SUMO maintains an average of approximately 116,000 updates per second. The final data point, with 95,000 vehicles loaded, shows that the method according to the embodiment performs vehicle updates approximately 62 times faster than SUMO.

[0090] The final benchmark test in Figure 7d evaluates how quickly the model can calculate available spots on the street network for inserting new vehicles. SUMO appears to outperform the method according to the embodiment, indicating that SUMO is more efficient at loading new vehicles onto the road network. The graph reveals that the insertion rate of the method according to the embodiment decreases as the number of vehicles increases. This is in part due to small differences in congestion clearance compounding over time. If vehicles join the queue faster than they leave it, even small differences in clearance speed can accumulate quickly, leading to fewer available slots for new vehicles to insert in the model with the slower clearance speed.

[0091] These results demonstrate the performance advantages of the techniques herein over SUMO. Algorithmic efficiency in loading new agents into the environment is an area where SUMO excels. However, in terms of raw performance (the time it takes to run a model from time step 0 to N), simulations run using multiple processing units in the form of GPUs can be significantly faster than simulations that primarily utilize CPUs.

[0092] 8 is a block diagram of a computing device, such as a data processing server, that may be used to implement the method for traffic simulation and embody the present invention. The computing device comprises multiple processors or processing units 993 and memory 994. Optionally, the computing device also includes a network interface 997 for communicating with other computing devices, such as other data storage devices or external data processing devices. Some embodiments may consist of a network of such computing devices.

[0093] Optionally, the computing device also includes one or more input mechanisms, such as a keyboard and mouse 996, and one or more display units, such as one or more monitors or screens 995. These components can be connected to each other via a bus 992.

[0094] The memory 994 may include a computer-readable medium, a term that can refer to a single medium or multiple media (e.g., centralized or distributed databases and / or associated caches and servers) configured to carry computer-executable instructions or store data structures. Computer-executable instructions may include, for example, instructions and data that are accessible by a general-purpose computer, a special-purpose computer, or a special-purpose processing device (e.g., one or more processors) to cause it to perform one or more functions or operations. Thus, the term “computer-readable storage medium” may also include any medium capable of storing, encoding, or carrying a set of instructions for execution by the machine, causing the machine to perform any one or more of the methods of the present disclosure. Thus, the term “computer-readable storage medium” may be interpreted to include, but is not limited to, solid-state memory, optical media, and magnetic media. By way of example, and not limitation, such computer-readable media may include non-transitory computer-readable storage media including random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid-state memory devices).

[0095] The multiple processors 993 are configured to control computing devices and perform processing operations, such as executing code stored in memory to implement the traffic simulation and related simulation methods described herein. The memory 994 stores data that is read from and written to by the multiple processors 993. As referred to herein, a processor may include one or more general-purpose processing devices, such as a microprocessor, a central processing unit, or the like. The processor may include a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or combinations of instruction sets. The processor may include one or more special-purpose processing devices, such as an ASIC, an FPGA, a digital signal processor (DSP), a network processor, or the like. In one or more embodiments, the processor is configured to execute instructions to perform the operations and steps described herein.

[0096] A display 995 may display a user interface. A touchscreen or screen and input 996 in the form of a keyboard and / or voice may be used for user input. The user interface may be embodied as a user application shown on the display and optionally connected to the audio input / output of the user device for voice input and audio output. Local storage of, for example, simulation parameters may be provided by memory 994, and multiple processors 993 may perform background functions. Core functionality (e.g., running the simulation) may preferably be implemented remotely from the user device, for example on the cloud.

[0097] The network interface (network I / F) 997 may be connected to a network such as the Internet and may be connected to other such computing devices via the network. The network I / F 997 controls data input and output to and from other devices via the network. Other peripheral devices such as a microphone, speaker, etc. may also be included in the computing device.

[0098] Multiple processors 993 can execute instructions stored in portions of memory 994 to exchange data between modules via bus 992 and to exchange data with external entities such as traffic sensors via network I / F 997.

[0099] Methods embodying the present invention may be performed on a computing device such as that shown in Figure 8. Such a computing device need not have all of the components shown in Figure 8, but may consist of a subset of those components. Methods embodying the present invention may be performed by a single computing device in communication with one or more data storage servers over a network. The computing device may itself be data storage for storing preconfigured interventions, buffered sensor data, historical sensor data, multi-function optimization models and parameters, etc.

[0100] Methods embodying the present invention may be performed by a plurality of computing devices operating in cooperation with one another, one or more of which may be data storage servers that store at least some of the pre-configured simulation parameters, traffic network details, agent object data, etc.

[0101] The various methods described above may be implemented by a computer program. The computer program may include computer code (e.g., instructions) configured to instruct a computer to perform one or more functions of the various methods described above. For example, the steps of the method described in connection with FIG. 1 may be performed by the computer code. The steps of the above-described method may be performed in any suitable order. The computer program and / or code for performing such methods may be provided to an apparatus such as a computer on one or more computer-readable media, or more generally, on a computer program product. The computer-readable medium may be transitory or non-transitory. The one or more computer-readable media may be, for example, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, or a propagation medium for data transmission, for example, downloading code via the Internet. Alternatively, the one or more computer-readable media may take the form of one or more physical computer-readable media, such as a semiconductor or solid-state memory, magnetic tape, removable computer diskettes, random access memory (RAM), read-only memory (ROM), rigid magnetic disks, and optical discs such as CD-ROMs, CD-R / Ws, or DVDs. The instructions may also reside, completely or at least partially, within memory 994 and / or within the controller circuitry of the multiple processors 993 during their execution by the computing system, with the memory 994 and the controller circuitry of the multiple processors 993 also constituting computer-readable storage media.

[0102] In some implementations, the modules, components, and other features described herein may be implemented as discrete components or integrated into the functionality of a hardware component such as an ASIC, FPGA, DSP, or similar device.

[0103] A "hardware component" is a tangible (e.g., non-transient) physical component (e.g., a set of one or more processors) capable of performing certain operations, and may be configured or arranged in some physical manner. A hardware component may include dedicated circuitry or logic that is permanently configured to perform certain operations. A hardware component may include a dedicated processor such as an FPGA or ASIC. A hardware component may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations.

[0104] Additionally, the modules and components may be implemented as firmware or functional circuitry within a hardware device. Further, the modules and components may be implemented in any combination of hardware devices and software components, or solely in software (e.g., code stored or otherwise embodied in a machine-readable medium or transmission medium).

[0105] Unless otherwise indicated, and as will be apparent from the following description, throughout the description, discussions utilizing terms such as "receive," "determine," "compare," "enable," "maintain," "identify," "obtain," "access," and the like will be understood to refer to the actions and processes of a computer system or similar electronic computing device that manipulate and convert data represented as physical (electronic) quantities in the computer system's registers and memory into other data similarly represented as physical quantities in the computer system's memory or registers, or other such information storage, transmission, or display device.

[0106] While certain embodiments have been described, these embodiments are presented by way of example only and are not intended to limit the scope of the invention. Indeed, the novel methods and apparatus described herein may be embodied in a variety of other forms; further, various omissions, substitutions, and changes may be made in the form of the methods and apparatus described herein.

[0107] The following numbered statements (appendices) are useful in the present invention: [S1] A computer-implemented method for traffic simulation, the method comprising: accepting input of traffic data including data about a geographical region; using the traffic data to generate a plurality of agent objects, each agent object representing a traffic participant and associated data; assigning the plurality of agent objects to respective plurality of processing units used in parallel; and running, on each parallel processing unit, a traffic simulation model to simulate the behavior of the traffic participants, the traffic simulation model including a car-following model, and the traffic simulation model including a lane-changing model and / or a junction management model. [S2] The method described in statement S1, wherein executing the traffic simulation model includes iteratively updating the agent object based on the agent object's associated data and interactions with other agent objects until a predetermined simulation termination criterion is reached. [S3] A method as described in statement S1 or statement S2, wherein the plurality of processing units have access to a pool data structure, and for each processing unit, executing the traffic simulation model includes updating agent object variables in the pool data structure and / or accessing agent object variables in the pool data structure. [S4] The method of any one of statements S1 to S3, wherein the plurality of processing units are at least partially hosted on a remote server. [S5] A method according to any one of statements S1 to S4, wherein if the plurality of agent objects includes more agent objects than the plurality of processing units includes, allocating the plurality of agent objects includes forming a processing queue for the processing units. [S6] The method of any one of statements S1 to S5, wherein the traffic data further comprises a description of the traffic network in a compressed sparse row representation and / or a compressed sparse column representation. [S7] The method of any one of statements S1 to S6, wherein the traffic data includes data obtained from a digital twin of the geographic area. [S8] The method of any one of claims 1 to 7, wherein the traffic data includes sensor data obtained from any or all of the following: GPS sensors or antennas, cellular network sensors or antennas, loop sensors, camera sensors, and vehicle parking sensors. [S9] The car-following model calculates the speed v and position x of a vehicle traffic participant from time t as v(t+Δt)=max[0,v des (t)-η], updated according to x(t+Δt)=x(t)+v(Δt), where v des The method of any one of statements S1 to S8, wherein η is the maximum speed consistent with predetermined traffic restrictions and η is a random speed perturbation to account for deviations from optimal driving. [S10] The method of any one of claims 1 to 9, further comprising: modifying the plurality of agent objects to generate a plurality of modified agent objects that reflect the modifications in the geographical area; assigning the plurality of modified agent objects to the respective plurality of processing units; and, for each processing unit in parallel, running the traffic simulation model to simulate the behavior of the traffic participants using the modifications in the geographical area. [S11] A data processing device comprising: a memory storing computer-executable instructions for executing the method according to any one of statements S1 to S10; a plurality of processing units configured to execute the instructions; and means for accepting input. [S12] A computer program comprising instructions that, when the program is executed by a computer, cause the data processing device of statement S12 to perform the method of any one of statements S1 to S10. [S13] A computer-readable medium storing the computer program of statement S12. [Explanation of symbols]

[0108] VehicleDefault Vehicle default OutputLocation Output location PreMoveLocation Pre-move position OutputLaneChangeRequest Outputs a lane change request LaneChangeRequest Lane change request UpdateLane Update lane OutputFollowLocation Outputs the follow position FollowLocation Follow location UpdateFollowSpeed ​​Update the follow speed JunctionMoveRequestF Junction move request F JunctionMoveRequestD Junction move request D MoveVehicle Move a vehicle VehiclePreinsertion Vehicle preinsertion PreRemoval Location RequestDeparture Request departure DepartureRequestD Departure request D Depart Default PreInsertion TrafficLightsDefault Traffic Light Default PhaseUpdate

Claims

1. 1. A computer-implemented method for traffic simulation, the method comprising: accepting input of traffic data including data about a geographic area; using the traffic data to generate a plurality of agent objects, each agent object representing a traffic participant and associated data; assigning the plurality of agent objects to respective plurality of processing units for use in parallel; for each parallel processing unit, executing a traffic simulation model for simulating the behavior of said traffic participants, wherein said traffic simulation model comprises a car-following model, and wherein said traffic simulation model comprises a lane-changing model and / or a junction management model; method.

2. 2. The method of claim 1, wherein executing the traffic simulation model includes iteratively updating the agent objects based on their associated data and interactions with other agent objects until a predetermined simulation termination criterion is reached.

3. 2. The method of claim 1, wherein the plurality of processing units have access to a pool data structure, and wherein, for each processing unit, executing the traffic simulation model includes updating and / or accessing agent object variables in the pool data structure.

4. The method of claim 1 , wherein the traffic data further comprises a description of the traffic network in a compressed sparse row representation and / or a compressed sparse column representation.

5. The method of claim 1 , wherein the traffic data comprises data obtained from a digital twin of the geographic area.

6. The traffic data includes the following: GPS sensor or antenna, cellular network sensors or antennas, Loop sensors, Camera sensors, and vehicle parking sensors The method of claim 1 , wherein the sensor data is obtained from any or all of:

7. The car-following model calculates the speed v and position x of a vehicular traffic participant from time t as follows: v(t+Δt)=max[0,v des (t)-η]、 x(t + Δt) = x(t) + v Δt Update according to, where v des is the maximum speed that complies with the given traffic restrictions, and η is a random speed perturbation to account for deviations from optimal driving. The method of claim 1.

8. modifying the plurality of agent objects to generate a plurality of modified agent objects that reflect modifications in the geographic region; assigning the plurality of modified agent objects to the respective plurality of processing units; for each parallel processing unit, executing the traffic simulation model to simulate the behavior of the traffic participants with the modifications in the geographical area; The method of claim 1 further comprising:

9. a memory storing computer-executable instructions; 1. A data processing apparatus comprising a plurality of processing units and means for accepting input, configured to execute the instructions to perform a method, the method comprising: accepting input of traffic data including data about a geographic area; using the traffic data to generate a plurality of agent objects, each agent object representing a traffic participant and associated data; assigning the plurality of agent objects to respective plurality of processing units for use in parallel; for each parallel processing unit, executing a traffic simulation model for simulating the behavior of said traffic participants, wherein said traffic simulation model comprises a car-following model, and wherein said traffic simulation model comprises a lane-changing model and / or a junction management model; Data processing device.

10. A computer program comprising instructions that, when executed by a computer, cause a data processing apparatus to perform operations, said operations being: accepting input of traffic data including data about a geographic area; using the traffic data to generate a plurality of agent objects, each agent object representing a traffic participant and associated data; assigning the plurality of agent objects to respective plurality of processing units for use in parallel; for each parallel processing unit, executing a traffic simulation model for simulating the behavior of said traffic participants, wherein said traffic simulation model comprises a car-following model, and wherein said traffic simulation model comprises a lane-changing model and / or a junction management model; Computer program.

Images