Microcosmic simulation particle filter data assimilation system and simulation method based on thread pool

Abstract

The invention relates to a microcosmic simulation particle filter data assimilation system and simulation method based on a thread pool, and the system comprises a data assimilation basic element representation module which is used for representing the basic elements of microcosmic simulation particle filter data assimilation; the particle filtering concurrent sampling module is used for executing particle filtering concurrent sampling based on the thread pool; and the particle filtering data assimilation operation control logic is used for scheduling the operation data assimilation basic element representation module and the particle filtering concurrent sampling module according to a correct time sequence and a dependency relationship, and continuously assimilating observation data of a real system into a simulation model by executing a particle filtering calculation step in microscopic simulation, so as to obtain a simulation result. And dynamically adjusting the state of the simulation model to approach the state of a real system. According to the system, particle filtering sampling tasks in microscopic simulation can be efficiently and concurrently executed, and the simulation performance is improved.

Description

Technical Field

[0001] This application relates to the technical field of dynamic data-driven technologies, and particularly to a microscopic simulation particle filter data assimilation system and a simulation method based on a thread pool. Background Art

[0002] Dynamic data-driven simulation is a "model and data combination" simulation paradigm. It continuously injects observations (data) of the real system into the simulation (model), allowing the data to dynamically correct the simulation (state, parameters), so as to improve the simulation-based estimation and prediction capabilities. Since dynamic data-driven simulation integrates information from both model prediction and real-time observation, it can more accurately estimate the state of the real system and predict the future evolution of the state. Because of such advantages, dynamic data-driven simulation has been successfully applied to scenarios such as forest fire spread prediction, pedestrian movement trajectory prediction, and vehicle trajectory reconstruction in urban traffic systems. In dynamic data-driven simulation, "data dynamically correcting the simulation" is achieved by data assimilation technology. And since the "simulation" in dynamic data-driven simulation generally refers to microscopic simulation, and its state evolution process has highly non-linear / non-Gaussian characteristics, therefore, the most commonly used data assimilation method in dynamic data-driven simulation is the particle filter algorithm.

[0003] The particle filter data assimilation software system is a prerequisite and basic support for carrying out dynamic data-driven simulation. However, implementing particle filter data assimilation in microscopic simulation is not as simple and intuitive as in ordinary real vector state equations. Implementing particle filter data assimilation in microscopic simulation poses the following challenges: First, in microscopic simulation, the state of the system model is not a real vector but a complex data structure that may contain both numerical state variables (e.g., the length of the queue in a queuing system) and non-numerical state variables (e.g., the "busy" or "idle" state of the service desk in a queuing system); similarly, the observed data may also be a mixture of numerical and non-numerical observations. Therefore, it is necessary to design a suitable data structure to effectively represent the simulation model state and observed data in microscopic simulation. Second, in microscopic simulation, the particle filter sampling process is a cyclic simulation running process that repeatedly runs the simulation model for a period of time with the simulation model state at the previous moment as the initial value to obtain the simulation model state at the next moment. The sampling process not only involves the running of simulation experiments but is also an asynchronous calling process (in a general real vector state equation, this process is usually a synchronous calling process). Therefore, it is necessary to design a particle filter sampling method suitable for microscopic simulation to ensure that each calculation step in the particle filter is executed in the correct logical order. Although existing methods implement the particle filter sampling steps in microscopic simulation in a backward manner, in the sampling process based on backward, the backward simulation needs to perform operations such as saving and restoring the model state and resetting the future event table of the simulator. These operations are closely related to the specific application and are error-prone. In addition, the sampling process based on backward is executed serially. For applications with high real-time requirements such as dynamic data-driven simulation, the running efficiency and resource consumption of serial execution will become bottlenecks in simulation performance. Summary of the Invention

[0004] Based on this, in view of the above technical problems, it is necessary to provide an easy-to-use, efficient, and concurrently executable microscopic simulation particle filter data assimilation system and simulation method based on a thread pool to improve the state estimation and prediction capabilities of microscopic simulation, so that the predicted state of the simulation model after data assimilation is closer to the real system state.

[0005] A microscopic simulation particle filter data assimilation system based on a thread pool, the system is applied to a microscopic simulation platform, and the system includes: A data assimilation basic element representation module for representing the basic elements of microscopic simulation particle filter data assimilation; A particle filter concurrent sampling module for performing particle filter concurrent sampling based on a thread pool; A particle filter data assimilation operation control logic for scheduling and running the data assimilation basic element representation module and the particle filter concurrent sampling module according to the correct time sequence and dependency relationship, and in microscopic simulation, continuously assimilating the observed data of the real system into the simulation model by executing the calculation steps of the particle filter, so that the simulation model dynamically adjusts its own state to approach the state of the real system.

[0006] Further, the basic elements of data assimilation representation module include a model state class, a weighted particle class, and an observation data class; Among them, the model state class is used to represent the state of the simulation model, and includes two attributes: a time attribute and a state value corresponding to the simulation model; The weighted particle class is used to represent particles with weights. Essentially, a particle is a possible state of the simulation model. Therefore, the weighted particle class includes two attributes: the state of the simulation model and the corresponding weight; The observation data class is used to represent the observation data of the real system, and includes two attributes: the time period when the observation data is collected and the data pair. Among them, the data pair includes a data source and data, and is used to represent the data collected from different data sources.

[0007] Further, the steps for the particle filter concurrent sampling module to perform particle filter concurrent sampling based on a thread pool include: In the initialization stage, the main thread creates a thread pool and a task queue; among them, the task queue includes a calculation task queue stored in sequence and a thread request queue; After the initialization is completed, the main thread creates several calculation tasks, and abstracts the calculation tasks, the task queue, and the threads into a multi-server single-queue queuing system formalized by the Discrete Event System Specification (DEVS). This multi-server single-queue queuing system dynamically schedules and allocates idle threads to execute the calculation tasks based on the states of the calculation task queue and the thread request queue, so as to achieve concurrent execution of the calculation tasks; among them, the calculation task is a particle filter sampling task in microscopic simulation.

[0008] Further, abstracting the calculation tasks, the task queue, and the threads into a multi-server single-queue queuing system formalized by the Discrete Event System Specification includes: Abstracting the calculation tasks, the task queue, and the threads into a multi-server single-queue queuing system, each calculation task serves as a customer in the system and receives calculation services from each thread serving as a server; After formalizing the multi-server single-queue queuing system using the Discrete Event System Specification, the calculation tasks, the task queue, and the threads in this multi-server single-queue queuing system are all described based on the atomic model of the Discrete Event System Specification, and they are coupled and interact with each other through input and output ports.

[0009] Further, the multi-server single-queue queuing system dynamically schedules and allocates idle threads to execute the calculation tasks based on the states of the calculation task queue and the thread request queue, so as to achieve concurrent execution of the calculation tasks, including: The task queue receives the computing task processing requests from each thread through its own request port, sorts them in the order of arrival, and forms a thread request queue. At the same time, after the task queue receives the computing tasks submitted by the main thread through its arrival port, it determines whether there are any idle threads in the thread request queue. If there are, the computing task is sent to the input port of the idle thread through the output port of the task queue, and the idle thread is used to execute the computing task. Otherwise, they are sorted in the order of arrival of the computing tasks, forming a computing task queue and waiting to be executed. When the thread finishes executing the computing task, it interacts with the end port of the computing task through its own end port to notify that the computing task has been executed, and the computing task can continue with subsequent operations. At the same time, the thread becomes idle and sends a computing task processing request to the task queue again through its own request port to check whether there are any computing tasks waiting to be executed in the computing task queue. If there are, the computing task at the head of the computing task queue is taken out and executed. Otherwise, it continues to remain idle waiting for the main thread to submit new computing tasks. When all computing tasks have been executed, all threads in the thread pool become idle, waiting to execute the computing tasks generated by particle filter sampling in the next round of microscopic simulation.

[0010] Furthermore, the execution logic of the task queue described based on the atomic model of discrete event system specification is expressed as: ; Among them, represents the task queue, represents the input of the task queue. Among them, represents the set of input ports of the task queue, including the arrival port and the request port ; The input of the arrival port represents the ID of the computing task submitted by the main thread, and the input of the request port represents the ID of the thread requesting the allocation of a computing task to the task queue; represents the output of the task queue. Among them, represents the set of output ports of the task queue, which only contains one output port ; The output of the output port represents the ID of the computing task to be executed by the thread; represents the state of the task queue. Among them, the computing task queue and the thread request queue Both are FIFO queues, storing the IDs of the computing tasks waiting in line to be executed and the IDs of the threads waiting in line to be assigned computing tasks respectively; Represents the internal state transition function of the task queue. The internal state transition function of the task queue describes how the state of the task queue changes under the control of only the time advancement function in the absence of external input, and is specifically defined as: ; Among them, "-1" means removing the head element from the queue; Represents the external state transition function of the task queue; among them, the set , the external state transition function of the task queue describes how the state of the task queue changes under the excitation of external input, and is specifically defined as: ; Among them, "+" means inserting at the tail of the queue; Represents the output function of the task queue, which defines what information should be output when the task queue undergoes an internal state transition, and is specifically defined as: ; Among them, in is the ID of the computing task at the head of the computing task queue ; it should be noted that the thread in the thread pool whose thread ID is equal to the thread ID at the head of the thread request queue will be responsible for executing the computing task with the ID of ; Represents the time advancement function of the task queue, which defines the duration for which the task queue remains in the state in the absence of external input influence, and is specifically defined as: ; The above formula indicates that when both the computing task queue and the thread request queue are not empty, the time advancement value is set to 0, thereby immediately triggering the internal state transition function of the task queue to assign the computing task at the head of the computing task queue to the idle thread at the head of the thread request queue for execution; the above process is repeated continuously until one of the queues becomes empty.

[0011] Furthermore, the execution logic of the thread described based on the atomic model of the discrete event system specification is expressed as: ; Among them, represents the thread, Represents the input of the thread; among them, Represents the set of input ports of the thread, which contains only one input port ; Input port The input of Represents the ID of the computing task assigned by the task queue to this thread; Represents the output of the thread; among them, Represents the set of output ports of the thread, including the end port And the request port ; End port The output of Represents the ID of the computing task completed by the thread, and the output of the request port The output of Represents the ID of the thread; Represents the state of the thread; among them, In Represents the ID of the computing task currently being executed by this thread, Represents the time remaining for this thread to complete this computing task; if , it means that the thread is currently in an idle state, and at this time, set ; Represents the internal state transition function of the thread, and the specific definition is: ; Represents the external state transition function of the thread, and the specific definition is: ; Among them, Represents the time required for this thread to execute the computing task; it should be noted that only when the thread is in state, that is, in an idle state, can it possibly receive the ID of the computing task output by the task queue; Represents the output function of the thread; when the thread finishes executing the computing task, on the one hand, it notifies through the output port that the computing task has been executed; on the other hand, it also sends a request to the task queue to allocate a new computing task through the output port; therefore, the output function of the thread is specifically defined as: ; Among them, refers to the ID of the thread itself; Represents the time advancement function of the thread, and the specific definition is: 。

[0012] Further, the computing task is specifically defined as: a simulation running process during particle filter sampling in microscopic simulation. This simulation running process uses the particle state at the previous moment as the initial value. After running the simulation model for a period of time, the particle state at the next moment is obtained.

[0013] Further, the particle filter data assimilation operation control logic includes three attributes, namely, the weighted particle attribute, which is used to represent a group of weighted particles; the actuator service attribute, which is used to provide a series of interfaces for accessing the thread pool service; the running duration attribute, which is used to represent the update period of the observed data, that is, the data assimilation period. The particle filter data assimilation operation control logic also includes the following functions, namely: The initialization function is used to generate a group of initial particles and assign weights, obtain the initial weighted particles, and create a thread pool. The create model instance function is an abstract function that is used to support users to instantiate the simulation model according to specific application scenarios. The weight update function is an abstract function that is used to support users to implement weight calculation according to the error model of the observed data of the real system in specific application scenarios. The create computing task function is an abstract function that is used to support users to generate computing tasks based on the simulation model, the initial state, the warm-up time, and the running duration. The sampling function is used to implement the particle filter concurrent sampling step based on the thread pool. During sampling, first call the create model instance function to instantiate the simulation model; then, based on the simulation model, the initial state, and the running duration, call the create computing task function to generate a computing task, and submit the computing task to the thread pool for waiting to be executed; when the computing task is completed by the thread execution, obtain the simulation model state and the predicted observed data, and further call the weight update function to update the weights of the particles. The weight normalization function is used to be called after the weights of all particles are updated to ensure that the sum of the weights of all particles is 1. The resampling function is an abstract function that is used to support users to adopt a specific resampling method according to specific application scenarios. The state estimation function is an abstract function that is used to support users to calculate the state estimation value based on the particles and weights according to specific application scenarios after resampling is completed. The particle perturbation function is an abstract function that is used to support users to use a specific state perturbation method according to the characteristics of specific application scenarios to increase the diversity of particles. The particle filter execution function is used to call this function when new observed data arrives to execute the complete particle filter calculation process.

[0014] A simulation method, the method comprising: Obtaining observation data of a real system, modeling the real system as a simulation model, and deducing the evolution of the state of the real system over time through the simulation model; Using the above-mentioned microscopic simulation particle filter data assimilation system based on a thread pool to continuously assimilate the observation data of the real system into the simulation model, so that the simulation model dynamically adjusts its own state to approximate the state of the real system.

[0015] The above-mentioned microscopic simulation particle filter data assimilation system and simulation method based on a thread pool have the following beneficial effects: 1. Construct a microscopic simulation particle filter data assimilation system based on a thread pool. This system designs a data assimilation basic element representation module with strong versatility, which can flexibly represent the basic elements of data assimilation with different characteristics in particle filtering of microscopic simulation, so as to effectively represent the state of the simulation model and observation data in microscopic simulation.

[0016] 2. This system performs concurrent sampling of particle filtering based on a thread pool, improving the execution efficiency of particle filtering sampling in microscopic simulation. Furthermore, it can achieve efficient microscopic simulation. And the thread pool can reduce the operating system resource overhead and computational amount brought by frequently creating and destroying threads by reusing the already created threads, ensuring the real-time requirements of dynamic data-driven simulation, so as to achieve better simulation performance.

[0017] 3. This system is designed based on the operation control logic of particle filter data assimilation, ensuring the scheduling and operation of particle filtering in microscopic simulation according to the correct timing and dependency relationship, improving the state estimation and prediction ability of microscopic simulation, and making the predicted state of the simulation model after data assimilation closer to the state of the real system. Description of the Drawings

[0018] Figure 1 It is a schematic diagram of the overall architecture of a microscopic simulation particle filter data assimilation system based on a thread pool in an embodiment; Figure 2 It is a schematic diagram of the process of concurrent sampling steps of particle filtering based on a thread pool in an embodiment; Figure 3 It is a schematic diagram of a multi-server single-queue queuing system described in the form of discrete event system specification in an embodiment; Figure 4 It is a schematic diagram of a simulation model in a performance comparison experiment in an embodiment; Figure 5 It is a schematic diagram of performance indicators in an embodiment; Figure 6Schematic diagram of the performance ratio of two particle filter implementation methods under different model scales and particle numbers in an embodiment; Figure 7 Schematic diagram of the average time consumption of single-step data assimilation varying with the number of particles in an embodiment. Detailed implementation manner

[0019] In order to make the objectives, technical solutions and advantages of the present application clearer and more understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0020] In one embodiment, as Figure 1 shown, a microscopic simulation particle filter data assimilation system based on a thread pool is provided. The system is applied to a microscopic simulation platform and includes: A data assimilation basic element representation module, configured to represent the basic elements of microscopic simulation particle filter data assimilation.

[0021] A particle filter concurrent sampling module, configured to perform particle filter concurrent sampling based on a thread pool.

[0022] A particle filter data assimilation operation control logic, configured to schedule and run the data assimilation basic element representation module and the particle filter concurrent sampling module according to the correct time sequence and dependency relationship, and in microscopic simulation, continuously assimilate the observed data of the real system into the simulation model by executing the calculation steps of the particle filter, so that the simulation model dynamically adjusts its own state to approximate the state of the real system. Specifically, the calculation steps of the particle filter include: (1) Sampling: According to the particles at the th step , run the microscopic simulation times to generate the particles at the th step , and update the weight of each particle according to the latest observed data; (2) Weight normalization: Normalize the particle weights to ensure that the sum of the particle weights is equal to 1; (3) Resampling: Randomly determine whether the particle is to be replicated or deleted according to its weight; (4) Estimate the state and output: Based on the particles and weights, adopt a suitable method according to the application characteristics (for example, Monte Carlo integration, or select the particle with the largest weight) to estimate the state of the simulation model and output it as a file for subsequent data analysis and visualization.

[0023] Specifically, resampling and weight update in particle filtering are essentially synchronous call functions. Therefore, in this application, the resampling and weight update steps are designed as abstract functions, only defining interfaces. Users can implement specific resampling methods (e.g., standard resampling, stratified resampling) and weight update methods according to specific application requirements.

[0024] Furthermore, the basic elements of data assimilation include model state, observation data, and particles. In microscopic simulation, the compositions of model state and observation data are diverse and not limited to real vectors. Therefore, a suitable and general data structure needs to be designed to represent the basic elements of data assimilation in microscopic simulation. Thus, the basic element representation module of data assimilation includes a model state class, a weighted particle class, and an observation data class. The specific designs of these classes are as follows: The model state (ModelState) class is used to represent the state of the simulation model. A typical simulation model consists of objects and the relationships between them. The state of the simulation model refers to the set of attributes of all objects that make up the simulation model at a given moment. Therefore, the model state class specifically contains two attributes: a time attribute (time) and a state value (state) corresponding to the simulation model. To enable the model state class to represent various types of state variables, the type of state (e.g., the Object class in Java) should be able to point to variables of any type.

[0025] The weighted particle (WeightedParticle) class is used to represent particles with weights. A particle is essentially a possible state of the simulation model. Therefore, the weighted particle class contains two attributes: the state of the simulation model (modelState) and the corresponding weight (weight).

[0026] The observation data (Observation) class is used to represent the observation data of the real system. In particle filtering, the observation data assimilated in the th step is the data collected during the time period from the th step (excluding) to the th step (including). Therefore, the observation data class contains two attributes: the time period (duration) during which the observation data is collected and the data pair (data). Among them, the data pair contains the data source and the data, and is used to represent the data collected from different data sources.

[0027] Furthermore, as Figure 2 shown, the steps for the particle filtering concurrent sampling module to perform particle filtering concurrent sampling based on a thread pool include: Step S1, in the initialization stage, the main thread creates a thread pool and a task queue; among them, the task queue contains a calculation task queue and a thread request queue stored in sorted order.

[0028] Step S2. After initialization is completed, the main thread creates several computing tasks, and abstracts the computing tasks, task queue, and threads into a multi-server single-queue queuing system formalized by the Discrete Event System Specification (DEVS). Based on the states of the computing task queue and thread request queue, this multi-server single-queue queuing system dynamically schedules and allocates idle threads to execute computing tasks, achieving concurrent execution of computing tasks; among them, the computing tasks are particle filtering sampling tasks in microscopic simulation.

[0029] Among them, abstracting the computing tasks, task queue, and threads into a multi-server single-queue queuing system formalized by the Discrete Event System Specification includes: Abstract the computing tasks, task queue, and threads into a multi-server single-queue queuing system. Each computing task acts as a customer in the system and receives computing services from each thread acting as a server. After formalizing the multi-server single-queue queuing system using the Discrete Event System Specification, the computing tasks, task queue, and threads in this multi-server single-queue queuing system are all described based on the atomic model of the Discrete Event System Specification, and they are coupled and interact with each other through input and output ports.

[0030] The structure of the multi-server single-queue queuing system formalized by the Discrete Event System Specification is as Figure 3 shown. The specific steps for this system to dynamically schedule and allocate idle threads to execute computing tasks based on the states of the computing task queue and thread request queue, achieving concurrent execution of computing tasks, include: The task queue receives the computing task processing requests from each thread through its own request port, and sorts them in the order of arrival of the requests to form a thread request queue; at the same time, after the task queue receives the computing tasks submitted by the main thread through its arrival port, it judges whether there are idle threads in the thread request queue; If there are, the computing task is sent to the input port of the idle thread through the output port of the task queue, and the idle thread is used to execute the computing task; otherwise, it is sorted in the order of submission of the computing tasks to form a computing task queue and waits to be executed; When the thread finishes executing the computing task, it interacts with the end port of the computing task through its own end port to notify that the computing task has been executed, and the computing task can continue to perform subsequent operations (such as obtaining the state of the simulation model and obtaining predicted observation data, etc.); at the same time, the thread becomes idle and sends a computing task processing request to the task queue again through its own request port to query whether there are computing tasks waiting to be executed in the computing task queue; If there is any, take out the computing task at the head of the computing task queue and execute it; otherwise, continue to remain idle and wait for the main thread to submit a new computing task; When all computing tasks are executed, all threads in the thread pool become idle and wait to execute the computing tasks generated by particle filter sampling in the next round of microscopic simulation.

[0031] The above steps schedule and allocate idle threads to concurrently execute computing tasks according to the thread pool and the task queue, so as to realize the concurrent sampling of particle filter in microscopic simulation, ensure that each computing step of particle filter in microscopic simulation is executed in the correct logical order, and improve the execution efficiency of particle filter sampling and the running efficiency of microscopic simulation through the concurrent execution of computing tasks. And the threads in the thread pool will not be destroyed after executing the computing tasks, but become idle and wait to execute the next computing task. The thread pool can reduce the operating system resource overhead and computing volume brought by frequent creation and destruction of threads by reusing the already created threads, ensure the real-time requirements of dynamic data-driven simulation, and thus achieve better simulation performance.

[0032] Specifically, the execution logic of the task queue described based on the atomic model of discrete event system specification is expressed as: ; Among them, represents the task queue, represents the input of the task queue; among them, represents the set of input ports of the task queue, including the arrival port and the request port ; The input of the arrival port represents the ID of the computing task submitted by the main thread, and the input of the request port represents the ID of the thread that requests to allocate a computing task to the task queue; represents the output of the task queue; among them, represents the set of output ports of the task queue, which only contains one output port ; The output of the output port represents the ID of the computing task that the thread is about to execute; represents the state of the task queue; among them, the computing task queue and the thread request queue are both FIFO queues, which store the IDs of the computing tasks waiting to be executed in queue and the IDs of the threads waiting to be allocated computing tasks in queue respectively; Represents the internal state transition function of the task queue. The internal state transition function of the task queue describes how the state of the task queue changes under the control of only the time advancement function in the absence of external input, and is specifically defined as: ; where, "-1" represents removing the head element from the queue; Represents the external state transition function of the task queue; among them, the set , the external state transition function of the task queue describes how the state of the task queue changes under the excitation of external input, and is specifically defined as: ; where, "+" represents inserting at the end of the queue; Represents the output function of the task queue, which defines what information should be output when the task queue undergoes an internal state transition, and is specifically defined as: ; where, in is the ID of the computing task at the head of the computing task queue; it should be noted that the thread in the thread pool whose thread ID is equal to the thread ID at the head of the thread request queue will be responsible for executing the computing task with ID ; the thread whose ID is equal to the thread ID at the head of the thread request queue will be responsible for executing the computing task with ID ; Represents the time advancement function of the task queue, which defines the duration for which the task queue remains in the state in the absence of external input influence, and is specifically defined as: ; The above formula indicates that when both the computing task queue and the thread request queue are not empty, the time advancement value is set to 0, thereby immediately triggering the internal state transition function of the task queue, and allocating the computing task at the head of the computing task queue to the idle thread at the head of the thread request queue for execution; the above process repeats continuously (constantly allocating computing tasks to idle threads) until one of the queues becomes empty (there are no idle threads or no queued computing tasks).

[0033] Specifically, the execution logic of the thread described based on the atomic model of the discrete event system specification is expressed as: ; where, represents the thread, represents the input of the thread; among them, Represents the set of input ports of a thread, containing only one input port ; Input port Input of Represents the ID of the computational task assigned by the task queue to this thread; Represents the output of the thread; among them, Represents the set of output ports of the thread, including the end port And the request port ; End port Output of Represents the ID of the computational task completed by the thread, request port Output of Represents the ID of the thread; Represents the state of the thread; among them, In Represents the ID of the computational task currently being executed by this thread, Represents the time remaining for this thread to complete this computational task; if , it means the thread is currently in an idle state, and at this time set ; Represents the internal state transition function of the thread, specifically defined as: ; Represents the external state transition function of the thread, specifically defined as: ; Among them, Represents the time required for this thread to execute the computational task; it should be noted that only when the thread is in state, that is, in an idle state, can it possibly receive the ID of the computational task output by the task queue; Represents the output function of the thread; when the thread finishes executing the computational task, on the one hand, it notifies through the output port that the computational task has been executed; on the other hand, it also sends a request to the task queue to allocate a new computational task through the output port; therefore, the output function of the thread is specifically defined as: ; Among them, refers to the ID of the thread itself; Represents the time advancement function of the thread, specifically defined as: .

[0034] Furthermore, the above computing task is specifically defined as: a simulation running process during particle filter sampling in microscopic simulation. This simulation running process uses the particle state at the previous moment as the initial value. After running the simulation model for a period of time, the particle state at the next moment is obtained.

[0035] Moreover, this simulation running process is carried out under the constraints of a simulation experiment framework. This framework defines the entities participating in the modeling and simulation activities and the relationships between the entities, including simulation experiment (Experiment), simulation model (SimulationModel), simulator (Simulator), and run control conditions (RunControl); among them, the simulation experiment is carried out on the simulation model, and the execution of the simulation model requires a simulator; the simulation experiment needs to be carried out under given run control conditions, and the run control conditions include simulation start time (startTime), warm-up time (warmupTime), and run duration (runLength); a simulation experiment needs to be run multiple times under the same run control conditions, and each run is called a replication, and each run needs to use a different random number seed (seed).

[0036] Therefore, when performing particle filter sampling in microscopic simulation, the computing task is further defined as a sample run in a simulation experiment and abstracted into a SimulationRun class; among them, the SimulationRun class contains five attributes, namely the simulation model, simulator, initial state (initialState), warm-up time, and run duration required for the sample run, where the simulation start time is implicitly included in the initial state; the SimulationRun class also contains a constructor and a run function. Among them, the constructor is used to complete the initialization of the simulation according to the simulation model, simulator, initial state, warm-up time, and run duration; the run function is used to drive the simulation run according to the simulation model type and the simulation platform operation mechanism. For example, when using the event scheduling method to execute a discrete event model, it is necessary to loop to take out the first event in the simulator's future event table and execute the event handling function until the future event table is empty or the preset run duration is reached.

[0037] After the computational task is completed, it is also necessary to obtain the simulation model state and the predicted observation data (i.e., implement the mapping from state to observation) to support the update of particle weights. Therefore, the simulation model needs to implement the DataAssimilationModelInterface (data assimilation model interface), which supports users to initialize the simulation model based on the given state (setInitialModelState), and obtain the state of the simulation model (getModelState), as well as the predicted observation data (getPredictedMeasurement).

[0038] Specifically, the above concurrent sampling steps of particle filtering based on a thread pool can be implemented based on Java concurrent programming. The Java Development Kit (JDK) is a software development environment for developing and testing Java programs. The JDK has supported concurrent programming since its design, and since version 5.0, the java.util.concurrent package has been newly added to the toolkit, which can greatly simplify the development of Java concurrent (multi-threaded) applications. Users can use the Executor (executor) interface and its implementation classes in the java.util.concurrent package for concurrent programming. The Executor provides an intermediate layer between the user side and the task execution: the user side does not directly execute the task, but executes the task through an intermediate object. The Executor allows developers to manage the execution of asynchronous tasks without explicitly managing the thread lifecycle. Developers can create different types of thread pools (e.g., FixedThreadPool and CachedThreadPool) by calling the factory methods of the Executors class in the java.util.concurrent package; when calling the factory method, an ExecutorService (executor service) object (an Executor with a lifecycle) will be created, and users submit, execute, and manage tasks through this object.

[0039] Users can define tasks by implementing the Runnable interface or the Callable interface in the java.util.concurrent package: Runnable tasks do not return values after execution, while Callable tasks can return values after execution. The Callable interface is a generic interface, and its type parameter represents the return value type after calling the call method of the Callable interface. Moreover, Callable tasks must be submitted through the submit method of the ExecutorService interface. After calling the submit method, a Future object will be generated, which is used to represent the result of asynchronous computation. Future is also a generic interface, and it is parameterized according to the result type returned by Callable. The Future interface provides corresponding methods to check whether the computation task is completed (isDone) and to obtain the computation result (get). When calling the get method of the Future object, this method will block until the task is completed and a result is produced.

[0040] Furthermore, in order to organize various computations in particle filter data assimilation in the correct timing relationship, this application designs a particle filter data assimilation operation control logic in the system. This module includes three attributes, namely the weighted particle attribute (weightedParticles), which is used to represent a group of weighted particles; the executor service attribute (executorService), which is used to provide a series of interfaces for accessing the thread pool service; the running duration attribute (deltaT), which is used to represent the update period of the observed data, that is, the period of data assimilation. The particle filter data assimilation operation control logic also includes the following functions, namely: The initialization function (initialize), which is used to generate a group of initial particles and assign weights, obtain the initial weighted particles, and create a thread pool; The create model instance function (createModelInstance), which is an abstract function used to support users in instantiating the simulation model according to specific application scenarios. It should be noted that the simulation model returned by createModelInstance needs to implement the DataAssimilationModelInterface interface.

[0041] The weight update function (updateWeight), which is an abstract function used to support users in implementing weight calculation according to the error model of the observed data of the real system in specific application scenarios; The create computation task function (createTask), which is an abstract function used to support users in generating computation tasks based on the simulation model, initial state, warm-up time, and running duration. The sampling function (sample) is used to implement the concurrent sampling step of particle filtering based on a thread pool. When sampling, first call the create model instance function to instantiate the simulation model. Then, based on the simulation model, the initial state, and the running duration, call the create calculation task function to generate calculation tasks, and submit the calculation tasks to the thread pool for waiting to be executed. After the calculation tasks are completed by the thread execution, obtain the simulation model state and the predicted observation data, and further call the weight update function to update the weights of the particles. The weight normalization function (normalizeWeights) is used to be called after the weights of all particles are updated to ensure that the sum of the weights of all particles is 1. The resampling function (resample) is an abstract function used to support users to adopt specific resampling methods according to specific application scenarios. The state estimation function (conductEstimation) is an abstract function used to support users to calculate the state estimation value based on particles and weights according to specific application scenarios after resampling. For example, when this application is specifically applied to a traffic simulation platform, use the average value of all particles as the estimation of traffic flow density and take the particle with the largest weight as the estimation of vehicle trajectory. The particle perturbation function (perturbModelState) is an abstract function used to support users to use specific state perturbation methods according to the characteristics of specific application scenarios to increase the diversity of particles. The particle filtering execution function (executeParticleFiltering) is used to call this function to execute the complete particle filtering calculation process when new observation data arrives.

[0042] In summary, the above-mentioned microscopic simulation particle filtering data assimilation system based on a thread pool can flexibly represent the basic elements of data assimilation with different characteristics in particle filtering in microscopic simulation through the internal data assimilation basic element representation module, so as to effectively represent the simulation model state and observation data in microscopic simulation. According to the internal thread pool-based particle filtering concurrent sampling, the execution efficiency of particle filtering sampling in microscopic simulation is improved, and thus efficient microscopic simulation can be realized. Moreover, according to the internal particle filtering data assimilation operation control logic, it ensures the scheduling and operation of particle filtering in microscopic simulation in the correct timing and dependency relationship, improves the state estimation and prediction ability of microscopic simulation, and makes the predicted state of the simulation model after data assimilation closer to the real system state.

[0043] The above-mentioned microscopic simulation particle filtering data assimilation system based on a thread pool can be specifically applied to various microscopic simulation platforms such as the MASON multi-agent simulation platform and the OpenTrafficSim traffic simulation platform.

[0044] MASON is a Java-based and domain-independent multi-agent simulation platform, designed to run large-scale agent simulation applications relatively efficiently on a single machine. The model of MASON is encapsulated in a special object called sim.engine.SimState, which contains a discrete event scheduler (schedule). Users can schedule various agents to be called at specified future times on the schedule. The schedule is essentially the way MASON models represent time. In addition, the MASON model also contains multiple "fields" for representing space, such as networks, continuous spaces, and grids.

[0045] When applying the system provided in this application to the MASON multi-agent simulation platform, a MASON simulation model (MultiAgentsModel) is developed according to the application scenario. It inherits from SimState (simulation state); since it needs to support data assimilation, it needs to implement the DataAssimilationModelInterface interface; MasonParticleFilteringControlLogic (MASON particle filtering control logic) inherits from ParticleFilteringControlLogic (particle filtering control logic) and implements all the abstract functions of ParticleFilteringControlLogic; MasonSimulationRun (Mason simulation run class) inherits from SimulationRun and implements the call function. According to the operation scheduling mechanism of the MASON simulation platform, MasonSimulationRun implements the call function of its parent class SimulationRun. In the call function, first, the simulation model is initialized according to the initial state, and then the initial events of the simulation model are scheduled; next, in the while loop, the step functions of each agent in the model are continuously executed through the schedule until the simulation time reaches the preset simulation running duration; finally, the model state and the predicted observation data are obtained and returned.

[0046] OpenTrafficSim (OTS) is an open-source traffic simulation platform based on Java, aiming to provide efficient and flexible tool support for traffic research, urban planning, and the development of intelligent transportation systems. OpenTrafficSim adopts discrete event simulation technology and can accurately simulate various traffic scenarios from microscopic vehicle behavior to macroscopic road network operation. As an open-source simulation platform, OpenTrafficSim encourages global researchers and developers to participate in collaboration. Users can freely access the source code and conduct secondary development to expand functions or adapt to specific research needs.

[0047] When applying the system provided in this application to the OpenTrafficSim traffic simulation platform, an OTS simulation model (TrafficSimulationModel) is developed according to the application scenario. It inherits from the OTSModelInterface (OTS model interface); similarly, it needs to implement the DataAssimilationModelInterface interface to support data assimilation; the OTSParticleFilteringControlLogic (OTS particle filtering control logic) inherits from ParticleFilteringControlLogic and implements all the abstract functions of ParticleFilteringControlLogic; the OTSSimulationRun (OTS simulation run) inherits from SimulationRun and implements the call function. According to the operation scheduling mechanism of the OpenTrafficSim traffic simulation platform, the OTSSimulationRun implements the call function of its parent class SimulationRun. In the call function, first, the simulator is instantiated, and then according to the simulation start time, warm-up time, running duration, and simulation model, the simulation run sample is instantiated. Next, the initialization of the simulator is carried out to achieve the binding of the simulation model and the simulator; the model is initialized according to the initial state, and then in the while loop, the first event in the future event table is continuously taken out and executed until the simulation time reaches the preset simulation running duration; finally, the model state and the predicted observation data are obtained and returned. It can be seen that the implementation of the call function is very different under different simulation platforms, so it is necessary to conduct targeted design according to the operation scheduling mechanism of the simulation platform.

[0048] To verify the performance of the microscopic simulation particle filter data assimilation system based on the thread pool provided by this application, a simulation experiment was further designed. In the simulation experiment, a simulation model was designed that could flexibly set the model scale (i.e., the number of components in the model). Based on this simulation model, the particle filter data assimilation methods based on the thread pool and fallback were respectively adopted to quantitatively compare the performance of the two methods under different model scales and different numbers of particles.

[0049] The simulation model used in this experiment As Figure 4 shown, the simulation model has components, namely . Each component is a discrete event model, only schedules one type of event, and the corresponding event handling function is ; there is no interaction between components. By changing the number of components , the scale of the simulation model can be flexibly set. During initialization , according to the set number of components , first instantiate components, and then sequentially call the event handling function of each component ; the processing flow of the event handling function is divided into two steps: first, sleep for milliseconds, and then schedule an event after unit time, and its event handling function is still . The "sleep" in the processing flow is used to simulate the physical time consumption of event processing, and the sleep time follows a uniform distribution , where and respectively represent the minimum and maximum values of the physical time required to process an event. The event handling function essentially realizes the function of the component calling the function periodically (every unit time), and this processing flow is the most basic and common processing flow in the simulation. For example, in microscopic traffic simulation, a vehicle processes a maneuver event every 0.5 seconds, and in the maneuver event handling function, it is necessary to update the vehicle's position, speed, acceleration and other attributes according to the surrounding environment information perceived by the vehicle.

[0050] Assume that data assimilation in the experiment is carried out for a total of steps (as Figure 5 shown); when the th observation data arrives ( ), data assimilation needs to complete three basic computational steps: sampling, weight normalization, and resampling. The wall time consumed by these steps is denoted as (as Figure 5 shown). Then, during the entire data assimilation process, the average time consumption for each step of data assimilation is: .

[0051] In this experiment, the average time consumption is used as the performance metric; to distinguish the performance metrics under the two implementation methods based on thread pool and fallback, subscripts are added to , that is, and respectively represent the average time consumption of the two particle filter implementation methods based on thread pool and fallback. It should be noted that under the two implementation methods, only the implementation of the sampling step is different. The implementation method based on the thread pool is concurrent sampling, while the implementation method based on fallback is serial sampling; in addition, in this experiment, both weight calculation and resampling are empty functions without function bodies.

[0052] The operating environment of this experiment is as follows: The computer CPU model is 13th Gen Intel Core i5-13600KF (14 cores and 20 threads), and the operating memory is 32GB; the operating system and version number are Ubuntu 22.04.4 LTS, and the JDK (Java Development Kit) version number is 18.0.2. The specific experimental design includes: To explore the performance of the two particle filter implementation methods based on thread pool and fallback under different model scales and particle numbers, the model scale is set to 20, 40, 60, 80, 100, and the particle number is set to 100, 200, 300, 400, 500, for a total of 25 groups of experiments; to reduce the influence of random factors, each group of experiments is run 5 times. The total number of data assimilation steps is set to , the observation data arrival interval ; the event scheduling period of the components in the simulation model is ; the minimum and maximum values of the event processing time consumption are set to .

[0053] For any combination of values of the model scale ( ) and the particle number ( ), experiments are run respectively based on the two particle filter implementation methods of thread pool and fallback. Each group of experiments is run independently 5 times. According to the results of the 5 experiments, the mean and standard deviation are calculated. The performance experiment results are shown in Table 1. Given and , the average time consumption of single-step data assimilation based on the thread pool implementation of particle filter can be theoretically estimated as follows: ; where represents the number of concurrent threads in the thread pool; in this experiment, it is taken as one less than the number of available CPU threads, that is, 19. Similarly, the average time consumption of single-step data assimilation based on the fallback implementation of particle filter can be estimated as follows: .

[0054] Randomly select a group of , calculate , which is close to the experimental results in Table 1 ( ), indicating that the experimental results in Table 1 are basically reasonable and basically consistent with the theoretical estimation results.

[0055] Table 1 Performance experimental results of two particle filter implementation methods based on thread pool and fallback (unit: second)

[0056] According to the experimental results in Table 1, calculate the ratio of the average time consumption of single-step data assimilation of the two particle filter implementation methods, that is , which represents the performance improvement multiple of the thread pool-based implementation method compared to the fallback-based implementation method. Plot the results as a heat map, as shown in Figure 6 . It can be seen that under the current experimental settings, the performance improvement multiple of the thread pool-based implementation method compared to the fallback-based implementation method is between 17.37 and 19.64, with an average improvement of 18.95 times, and the improvement multiple is approximately equal to the size of the thread pool , which is consistent with the theoretical estimated value .

[0057] Next, further explore the relationship between the performance of the thread pool-based particle filter implementation method and the number of particles. Calculate the relative value of the average time consumption of single-step data assimilation ( ) when the given model scale and the number of particles compared to the average time consumption of single-step data assimilation when the same model scale, , that is , and plot the results as a curve, as shown in Figure 7 . It can be seen from the results that and the number of particles are linearly related, but have no relationship with the model scale . In other words, when the model scale is fixed, the average time consumption of single-step data assimilation increases linearly with the increase of the number of particles . According toFigure 7 , the following relational expression can be obtained by fitting: ; When the number of particles increases by 1 time (i.e., ) on the basis of , the average time-consuming for single-step data assimilation is times of . That is to say, when the number of particles increases exponentially on the basis of 100, the average time-consuming for single-step data assimilation also shows a linear growth relationship with respect to the average time-consuming when the number of particles is 100, but the rate of increase in the average time-consuming is less than the rate of increase in the number of particles.

[0058] In summary, the results of the simulation experiment show that the performance of the micro-simulation particle filter data assimilation system based on the thread pool constructed in this application is significantly better than the existing data assimilation implementation scheme based on rollback, and when the scale of the simulation model is fixed, the average time-consuming for single-step data assimilation increases linearly with the increase in the number of particles, but the rate of increase in the average time-consuming is less than the rate of increase in the number of particles.

[0059] In one embodiment, this application also provides a simulation method, and the method includes: Obtain the observation data of the real system, model the real system as a simulation model, and deduce the evolution of the state of the real system over time through the simulation model; Use the above-mentioned micro-simulation particle filter data assimilation system based on the thread pool to continuously assimilate the observation data of the real system into the simulation model, so that the simulation model dynamically adjusts its own state to approximate the state of the real system.

[0060] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in this specification.

[0061] The above-described embodiments only represent several implementation manners of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of this application. It should be noted that for those of ordinary skill in the art, without departing from the concept of this application, several deformations and improvements can still be made, and these all belong to the protection scope of this application. Therefore, the protection scope of this application should be subject to the appended claims.

Claims

1. A microscopic simulation particle filter data assimilation system based on thread pool, characterized in that: The system is applied to a microscopic simulation platform, and the system comprises: Data assimilation basic elements representation module, used to represent the basic elements of micro-simulation particle filter data assimilation; Particle filter concurrent sampling module, used to perform particle filter concurrent sampling based on thread pool; The particle filter data assimilation operation control logic is used to schedule the operation of the data assimilation basic element representation module and the particle filter concurrent sampling module according to the correct timing and dependency relationship, and in the micro-simulation, the observation data of the real system is continuously assimilated into the simulation model by executing the calculation steps of the particle filter, so that the simulation model dynamically adjusts its own state to approach the state of the real system.

2. The thread pool-based microscopic simulation particle filter data assimilation system according to claim 1 is characterized in that: The data assimilation basic element representation module includes a model state class, a weighted particle class and an observation data class; The model state class is used to represent the state of the simulation model, including two attributes: a time attribute and a state value corresponding to the simulation model; The weighted particle class is used to represent particles with weights. A particle is essentially a possible state of a simulation model, so the weighted particle class contains two attributes: the state of the simulation model and the corresponding weight. The observed data class is used to represent the observed data of a real system, and includes two attributes: a time period for collecting the observed data and a data pair. The data pair includes a data source and data, and is used to represent data collected from different data sources.

3. The thread pool-based microscopic simulation particle filter data assimilation system according to claim 1 is characterized in that: The particle filter concurrent sampling module performs the steps of performing particle filter concurrent sampling based on thread pool, including: In the initialization phase, the main thread creates a thread pool and a task queue; wherein the task queue includes a sorted and stored computing task queue and a thread request queue; After initialization is completed, the main thread creates several computing tasks, and abstracts the computing tasks, task queues and threads into a multi-server single-queue queuing system that is formally described using a discrete event system specification. The multi-server single-queue queuing system dynamically schedules and allocates idle threads to execute computing tasks based on the status of the computing task queue and the thread request queue, thereby realizing concurrent execution of computing tasks; wherein the computing task is a particle filter sampling task in a microscopic simulation.

4. The thread pool-based microscopic simulation particle filter data assimilation system according to claim 3 is characterized in that: The computing tasks, task queues and threads are abstracted into a multi-server single-queue queuing system formally described by discrete event system specifications, including: The computing tasks, task queues and threads are abstracted into a multi-server single-queue queuing system. Each computing task acts as a customer in the system and receives computing services from each thread as a server. After the multi-server single-queue queuing system is formally described using the discrete event system specification, the computing tasks, task queues and threads in the multi-server single-queue queuing system are described based on the discrete event system specification atomic model, and each is coupled and exchanges information through input and output ports.

5. The thread pool-based microscopic simulation particle filter data assimilation system according to claim 4 is characterized in that: The multi-server single queue queuing system dynamically schedules and allocates idle threads to perform computing tasks based on the status of computing task queues and thread request queues, realizing concurrent execution of computing tasks, including: The task queue receives computing task processing requests of each thread through its own request port, and sorts the requests in the order in which they are issued to form a thread request queue; at the same time, after receiving the computing tasks submitted by the main thread through its own arrival port, the task queue determines whether there is an idle thread in the thread request queue; If yes, send the computing task to the input port of the idle thread through the output port of the task queue, and use the idle thread to execute the computing task; otherwise, sort the computing tasks in the order in which they were submitted to form a computing task queue and wait for execution; When the thread completes the computing task, it interacts with the computing task's end port through its own end port to notify the computing task that it has been completed and that the computing task can continue to perform subsequent operations; at the same time, the thread becomes idle and resends a computing task processing request to the task queue through its own request port to query whether there are computing tasks waiting to be executed in the computing task queue; If there is one, take out the computing task at the head of the computing task queue and execute it; otherwise, continue to remain idle and wait for the main thread to submit a new computing task; When all computing tasks are completed, all threads in the thread pool become idle, waiting to execute computing tasks generated by particle filter sampling in the next round of micro-simulation.

6. The thread pool-based microscopic simulation particle filter data assimilation system according to claim 5 is characterized in that: The execution logic of the task queue described by the atomic model of discrete event system specification is expressed as: ； in, Represents a task queue, Represents the input of the task queue; where, Represents the input port set of the task queue, including the arrival port and request port ; Arrival port Input Represents the ID of the computing task submitted by the main thread, request port Input Represents the ID of the thread that requests the task queue to allocate computing tasks; Represents the output of the task queue; where, Represents the output port set of the task queue, which contains only one output port ; Output port Output Indicates the ID of the computational task that the thread will perform; Indicates the status of the task queue; among them, the calculation task queue and thread request queue Both are FIFO queues, storing the IDs of computing tasks waiting to be executed and the IDs of threads waiting to be assigned computing tasks. Represents the internal state transfer function of the task queue. The internal state transfer function of the task queue describes the task queue in the absence of external input, only in the time advancement function How the state changes under the control of is specifically defined as: ； Among them, "-1" means removing the first element from the queue; Represents the external state transition function of the task queue; where the set ,The external state transfer function of the task queue describes how the state of the task queue changes under the stimulation of external input, and is specifically defined as: ； Among them, "+" means inserting to the end of the queue; Represents the output function of the task queue, which defines what information should be output when the task queue undergoes an internal state transition. The specific definition is: ； in, In It is a computing task queue The ID of the computing task at the head of the queue; it should be noted that the thread ID in the thread pool is equal to the thread request queue The thread with the thread ID at the head of the queue will be responsible for executing The computational tasks; Represents the time advancement function of the task queue, which defines the state that the task queue remains in without external input influence The duration of is specifically defined as: ； The above formula indicates that when both the computing task queue and the thread request queue are not empty, the time advancement value is set to 0, thereby immediately triggering the internal state transfer function of the task queue, and assigning the computing task at the head of the computing task queue to the idle thread at the head of the thread request queue for execution; the above process is repeated until one of the queues is empty.

7. The thread pool-based microscopic simulation particle filter data assimilation system according to claim 6 is characterized in that: The execution logic of the thread described by the atomic model of discrete event system specification is expressed as: ； in, Represents a thread, Represents the input of the thread; where, Represents the input port set of the thread, which contains only one input port ; Input port Input Indicates the ID of the computing task assigned to this thread by the task queue; Represents the output of a thread; where Represents the thread's output port set, including the end port and request port ; End port Output Indicates the ID of the computing task that the thread has completed, request port Output Indicates the thread ID; Indicates the state of the thread; among them, In Represents the ID of the computational task currently being executed by the thread. Indicates the time required for the thread to complete the calculation task; if , it means that the thread is currently in an idle state. ; Represents the internal state transfer function of the thread, which is specifically defined as: ； Represents the external state transfer function of the thread, which is specifically defined as: ； in, Indicates the time required for the thread to perform the computing task; it should be noted that only when the thread is Only when the task queue is in idle state can the ID of the computing task output by the task queue be received; Represents the output function of the thread; when the thread completes the computing task, on the one hand, The output port notifies that the computing task has been completed; on the other hand, The output port sends a request to the task queue to allocate a new computing task; therefore, the output function of the thread The specific definition is: ； in, Refers to the ID of the thread itself; Represents the time advancement function of the thread, which is specifically defined as: 。 8. The thread pool-based microscopic simulation particle filter data assimilation system according to any one of claims 3 to 7, characterized in that: The computing task is specifically defined as: a simulation running process when performing particle filter sampling in microscopic simulation, the simulation running process takes the particle state at the previous moment as the initial value, and after running the simulation model for a period of time, obtains the particle state at the next moment.

9. The thread pool-based microscopic simulation particle filter data assimilation system according to claim 1, characterized in that: The particle filter data assimilation operation control logic includes three attributes, namely, the weighted particle attribute, which is used to represent a group of weighted particles; the executor service attribute, which is used to provide a series of interfaces for accessing the thread pool service; the running time attribute, which is used to represent the update cycle of the observation data, that is, the cycle of data assimilation; the particle filter data assimilation operation control logic also includes the following functions, namely: Initialization function, used to generate a set of initial particles and assign weights, obtain initial weighted particles and create a thread pool; The create model instance function is an abstract function used to support users to instantiate simulation models according to specific application scenarios; The weight update function is an abstract function that supports users to implement weight calculation based on the error model of the observed data of the real system in a specific application scenario; The create calculation task function is an abstract function used to support users to generate calculation tasks based on simulation models, initial states, warm-up time, and running time; The sampling function is used to implement the concurrent sampling steps of particle filtering based on the thread pool. When sampling, the model instance creation function is first called to instantiate the simulation model. Then, based on the simulation model, initial state and running time, the calculation task creation function is called to generate the calculation task, and the calculation task is submitted to the thread pool for execution. When the computation task is completed by the thread, the simulation model state and predicted observation data are obtained, and the weight update function is further called to update the particle weight; The weight normalization function is called after all particle weights are updated to ensure that the sum of all particle weights is 1; The resampling function is an abstract function that supports users to adopt specific resampling methods according to specific application scenarios; The state estimation function is an abstract function that supports users to calculate the state estimation value based on particles and weights according to specific application scenarios after resampling is completed; The particle perturbation function is an abstract function that supports users to use specific state perturbation methods according to the characteristics of specific application scenarios to increase the diversity of particles; The particle filter execution function is used to call this function when new observation data arrives to execute the complete particle filter calculation process.

10. A simulation method, characterized in that: The method comprises: Obtain the observation data of the real system, and model the real system as a simulation model, and deduce the evolution of the state of the real system over time through the simulation model; By using the thread pool-based micro-simulation particle filter data assimilation system described in any one of claims 1 to 9, the observation data of the real system is continuously assimilated into the simulation model, so that the simulation model dynamically adjusts its own state to approach the state of the real system.

Images