Distributed Internet of Things simulation system based on time synchronization, event driving and message bus

Abstract

The invention provides a distributed Internet of Things simulation system based on time synchronization, event driving and a message bus, and the system comprises a simulation model which is used for simulating different types of Internet of Things equipment or communication entities; the model management system is used for managing and controlling the life cycle, configuration and version management of the simulation model so as to ensure that the system adds, deletes or modifies different simulation models; the time synchronizer is used for ensuring that all nodes in distributed simulation keep a unified time reference so as to ensure the sequence and synchronous execution of events; the message bus is used for transmitting messages, events and data among the simulation nodes so as to ensure real-time communication and cooperation of each unit in the distributed system; and the front-end interface is used for monitoring a simulation process, operating equipment and checking simulation data in real time. According to the invention, the problem of low operation and maintenance efficiency of Internet of Things simulation software in the prior art can be solved.

Description

Technical Field

[0001] The present invention relates to the technical field of Internet of Things simulation systems, and in particular to a distributed Internet of Things simulation system based on time synchronization, event drive and message bus. Background Art

[0002] The Internet of Things (IoT) system is a system of multiple interconnected devices and networks that can collect and exchange data. The core goal of IoT is to improve efficiency, enhance convenience and achieve automation through intelligent connectivity and data analysis.

[0003] The IoT simulation system is a tool used to simulate and test IoT devices, networks, and applications. It can evaluate the performance, reliability, and security of the system without actually deploying the device.

[0004] As the IoT system is large and complex, traditional IoT simulation software is bloated and inefficient in operation and maintenance. The main reason for this phenomenon is that in a simulation experiment, the simulation software needs to start the simulation models of a large number of devices at the same time, load the simulation resources of these devices, and process the interactive data of these devices, which will bring huge operating pressure to the computer or server, resulting in slow simulation operation and difficult software maintenance.

[0005] Although a single IoT simulation system consumes a lot of storage and computing resources during operation, when multiple people conduct IoT simulation experiments at the same time, they will not start the simulation at the same time. Often, someone is running the simulation, someone is building the circuit, and someone is analyzing the results at the same time. Therefore, developing a distributed IoT simulation system can make use of idle simulation resources, reduce the computing pressure of a single computer or server, make full use of the computing power of each node, and improve the overall operating performance and reliability of the system. Summary of the invention

[0006] In order to solve the problems existing in the prior art, the purpose of the present invention is to provide a distributed Internet of Things simulation system based on time synchronization, event-driven, and message bus to solve the problem of low efficiency in operation and maintenance of Internet of Things simulation software in the prior art.

[0007] The present invention achieves the above-mentioned purpose through the following technical solutions:

[0008] A distributed Internet of Things simulation system based on time synchronization, event drive and message bus, including:

[0009] Simulation models, used to simulate different types of IoT devices or communication entities; each simulation model represents an independent physical device or communication entity, and is used to simulate the behavior, data generation and reception of the device;

[0010] Model management system, used to manage and control the life cycle, configuration and version management of simulation models to ensure that different simulation models can be added, deleted or modified in the system;

[0011] A time synchronizer is used to ensure that all nodes in a distributed simulation maintain a unified time base to guarantee the order and synchronous execution of events;

[0012] Message bus, used to transmit messages, events and data between simulation nodes to ensure real-time communication and collaboration among various units in the distributed system;

[0013] The front-end interface is used to provide a user-friendly interface to manage simulation models, configure parameters, start and stop simulations, and display device status, sensor data, communication status, and event logs in real time.

[0014] According to a distributed Internet of Things simulation system based on time synchronization, event drive, and message bus provided by the present invention, the simulation model adopts an event-driven architecture, including a simulation model, an event, an event queue, and an event scheduler. An event is a representation of a change in the state of a device in the system. The event queue is used to store upcoming events. All events are sorted according to their triggering time. Each event corresponds to a processing function, which triggers corresponding device behavior when the event occurs.

[0015] When the simulation time reaches the trigger time of an event, the event scheduler takes the event out of the queue and triggers its corresponding operation, and schedules the event according to time sequence and priority; among them, the event is placed in the priority queue according to its scheduled execution time, and the scheduler takes the event out of the queue in order and executes it.

[0016] According to a distributed IoT simulation system based on time synchronization, event drive, and message bus provided by the present invention, before starting the simulation, firstly, instances of all IoT devices are created, their states are initialized, and then their states and behaviors are registered in the event scheduler of the simulation system;

[0017] When starting the simulation, the event queue is checked regularly through the event scheduler, events at scheduled times are triggered and the corresponding event handlers are called; when the device status changes, new events are generated based on the current device status and dynamically added to the event queue; for operations that require synchronization, the communication and operations between different devices are coordinated through simulation time.

[0018] According to a distributed Internet of Things simulation system based on time synchronization, event drive, and message bus provided by the present invention, the model management system provides a RESTful API or a gRPC interface to manage the simulation model through HTTP or RPC;

[0019] The model management system uses the state mode to achieve the management of the model life cycle;

[0020] The model management system uses a database to save model instances and their running states to support breakpoint resuming, and uses a configuration file or a database to save device configuration parameters.

[0021] According to a distributed Internet of Things simulation system based on time synchronization, event-driven, and message bus provided by the present invention, the time synchronizer also includes a virtual time management function, which accelerates or decelerates the simulation time by adjusting the time step of event processing; and uses a control algorithm to automatically correct the time difference between simulation nodes.

[0022] According to the present invention, a distributed Internet of Things simulation system based on time synchronization, event-driven and message bus is provided. The message bus is implemented using open source message middleware, supports publish-subscribe mode and point-to-point communication mode, uses a queue model to process concurrent messages, maintains the sending and receiving order of messages through a FIFO queue, and persists the messages in a database when necessary.

[0023] According to a distributed Internet of Things simulation system based on time synchronization, event drive, and message bus provided by the present invention, before the message is transmitted, the message content is dynamically selected to be compressed according to the real-time requirements and compression rate requirements of the message transmission;

[0024] Before message compression, a batch operation is first performed to merge multiple messages to be transmitted into one data packet, wherein the triggering condition of the batch operation is based on a preset time window or message quantity threshold;

[0025] After receiving the compressed data packet, the receiving node first performs a decompression operation to restore the original message content, and then further processes the message.

[0026] According to a distributed Internet of Things simulation system based on time synchronization, event drive, and message bus provided by the present invention, the front-end interface uses a modern front-end framework to build a user interface, and combines a visualization library to realize a graphical display of device status and simulation data;

[0027] The front-end interface uses WebSocket or Server-Sent Events to achieve real-time communication with the backend.

[0028] According to a distributed Internet of Things simulation system based on time synchronization, event drive, and message bus provided by the present invention, before starting the simulation, the device type, quantity, and topology structure between them in the Internet of Things simulation environment are defined and edited through a graphical tool provided by a front-end interface;

[0029] Configure detailed properties of each IoT device;

[0030] The front-end interface collects all the data configured by the user and transmits this configuration information to the back-end model management system for storage in a structured data format;

[0031] After receiving the configuration data transmitted by the front end, the model management system automatically parses the data and dynamically generates an IoT simulation model instance consistent with the configuration based on the parsing results;

[0032] The generated simulation model instance includes all devices, topology and configuration information defined by the user.

[0033] According to a distributed Internet of Things simulation system based on time synchronization, event drive, and message bus provided by the present invention, during the simulation operation, various interactive commands are sent during the simulation operation through the interactive function provided by the front-end interface; the front-end interface UI component responds to the user's operation and generates a corresponding API request, which includes the interactive command information that the user wants to implement;

[0034] The front-end interface sends the API request to the back-end model management system through the network. After receiving the request, the model management system immediately parses it and identifies the user's intention and specific command content;

[0035] The model management system locates the corresponding simulation device in real time according to the parsed command content and applies the command to the device to achieve dynamic control of the simulation device;

[0036] After receiving the command, the simulation device immediately adjusts its operating status, configuration parameters or performs specific actions according to the command to respond to the user's interaction request.

[0037] It can be seen that compared with the prior art, the system provided by the present invention has the following beneficial effects:

[0038] 1. Distributed architecture supports large-scale simulation: Traditional simulation software is mostly deployed on a single machine, which cannot effectively handle large-scale IoT nodes or complex scenarios and is easily limited by the performance of a single computing node. The present invention adopts a distributed architecture, which can distribute simulation tasks to multiple physical or virtual nodes and support the simultaneous simulation of tens of thousands of devices; through load balancing and task scheduling, it can better handle high-concurrency simulation tasks and support ultra-large-scale IoT network simulation.

[0039] 2. Time synchronization to ensure consistent event order: Traditional simulation software usually advances simulation based on simple time steps, and does not have the precise time synchronization function across nodes, which may lead to disordered simulation event order. The present invention uses a time synchronizer to perform strict time control to ensure that the time between distributed nodes is consistent; physical clocks or logical clocks can be used to ensure that events occur in the expected order, which is particularly suitable for high-precision, time-sensitive application scenarios.

[0040] 3. Event-driven architecture, optimized performance: Most traditional simulation software is based on loops or time steps, frequently polling device status, resulting in a waste of computing resources. The present invention adopts an event-driven architecture, which executes the corresponding device logic only when a specific event is triggered, thereby reducing invalid calculations and resource occupation, greatly improving performance, and is particularly suitable for simulation environments with limited resources.

[0041] 4. Flexible message bus, supporting multiple communication protocols: Traditional simulation software uses traditional fixed communication protocols, which have poor scalability and are difficult to adapt to the diverse protocol requirements in the Internet of Things. The present invention implements a flexible communication mechanism through a message bus, supports multiple communication protocols (such as MQTT, HTTP, CoAP, Zigbee, LoRa, etc.), and can dynamically expand the protocol stack to adapt to various complex communication scenarios. The message bus also supports efficient message routing and load balancing to ensure real-time message delivery.

[0042] 5. Real-time monitoring and dynamic control: After the simulation is run, the results of traditional simulation software cannot be obtained in real time, and it is necessary to wait until the simulation is finished to replay and analyze the data. The present invention supports real-time monitoring. Users can view device status, message flow, sensor data, etc. during the simulation process. They can also dynamically control the device and adjust the configuration in the simulation. This real-time feedback and interactive capability is very critical for debugging and optimization in complex scenarios.

[0043] 6. Highly scalable and modular design: Traditional simulation software is often a single, integrated design, which makes it difficult to expand or replace system modules, resulting in limited customization capabilities. The modular design of the present invention allows users to expand or replace various parts as needed, such as adding a new protocol stack, adjusting the message transmission mechanism, and introducing a new simulation model or algorithm. Users can flexibly customize the simulation environment according to specific needs.

[0044] The present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 It is a schematic diagram of an embodiment of a distributed Internet of Things simulation system based on time synchronization, event drive, and message bus of the present invention. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the drawings of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0047] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0048] See also Figure 1 The present invention provides a distributed Internet of Things simulation system based on time synchronization, event drive, and message bus, including:

[0049] Simulation models are used to simulate different types of IoT devices, protocol stacks, sensors, actuators, etc. Each simulation model represents an independent physical device or communication entity and is used to simulate the device's behavior, data generation, and reception.

[0050] The model management system is the background management part of the system, which is used to manage and control the life cycle, configuration and version management of the simulation model to ensure that the system adds, deletes or modifies different simulation models.

[0051] Time synchronizers are used to ensure that all nodes in a distributed simulation maintain a unified time base to guarantee the order and synchronous execution of events, especially during cross-node interactions.

[0052] The message bus is the core communication mechanism in the system, which is used to transmit messages, events and data between simulation nodes to ensure real-time communication and collaboration among various units in the distributed system.

[0053] The front-end interface is the entry point for users to interact with the system. It is used to monitor the simulation process, operate the equipment and view the simulation data in real time. The front-end interface can be used to provide a user-friendly interface to manage simulation models, configure parameters, start and stop simulation, and display the status of equipment, sensor data, communication status and event logs in real time.

[0054] In this embodiment, the main functions of the simulation model include: 1. simulating the internal logic and operation of the device (such as sensor reading data, communication protocol processing); 2. simulating communication between devices (such as data exchange through MQTT or TCP / IP); 3. supporting simulation of multiple protocols (such as WiFi, Zigbee, LoRa, etc.); 4. responding to external commands or messages from other devices under an event-driven architecture.

[0055] In the specific implementation, C++ and Python are used in combination with mature network simulation frameworks (such as NS3 and OMNet++), mature controller simulation tools QEMU, and mature electronic signal simulation engines SystemC, SystemC-AMS, and SPICE to realize the simulation of network signals, controller behaviors, and electronic signals.

[0056] Each IoT device is abstracted through a class or object, and the state (sensor value, connection status, etc.) and behavior (sending data, receiving commands, etc.) of each IoT device is encapsulated into an interface. These interfaces will correspond to an event.

[0057] For IoT devices that do not involve network communication, such as buttons and LED lights on the same single-board hardware, their behaviors can be processed within the same simulation model without increasing the burden on the data bus and other simulation modules.

[0058] The simulation model adopts an event-driven architecture, including simulation models, events, event queues, and event schedulers. Events represent changes in device status in the system, such as sensors reading new values, devices sending / receiving data, etc. The event queue is used to store upcoming events. All events are sorted according to their triggering time. Each event has a corresponding processing function, which triggers corresponding device behaviors when an event occurs, such as updating device status, communicating over the network, and interacting with other simulation modules.

[0059] When the simulation time reaches the trigger time of an event, the event scheduler takes the event out of the queue and triggers its corresponding operation, and schedules the event according to time sequence and priority; among them, the event is placed in the priority queue according to its scheduled execution time, and the scheduler takes the event out of the queue in order and executes it.

[0060] Before starting the simulation, first create instances of all IoT devices and initialize their states, then register their states (such as sensor values) and behaviors (such as sending data) to the event scheduler of the simulation system. When starting the simulation, the event scheduler periodically checks the event queue, triggers events at a predetermined time, and calls the corresponding event handler; when the device state changes (such as receiving external data or sensor value changes), a new event is generated based on the current device state and dynamically added to the event queue; for operations that require synchronization such as network communication, the communication and operations between different devices are coordinated through the simulation time (such as the simulation time step of NS3).

[0061] Since most events in the simulation process are asynchronous, for example, when a sensor generates data or a controller receives a command, there is no need to wait for all events to execute synchronously. This event-driven architecture can decouple various operations in the simulation process, improve system efficiency, and simulate the asynchronous operation of real devices.

[0062] In this embodiment, the main functions of the model management system include: 1. registering, starting and destroying simulation models; 2. configuring the model's operating parameters, device characteristics and behavioral logic; 3. providing model update, version control and log management functions; 4. supporting load balancing and task allocation of simulation nodes in a distributed environment; 5. interacting with other modules through API or UI interface (such as operating the simulation model through the front-end interface).

[0063] In the specific implementation, the model management system provides a RESTful API or gRPC interface to manage the simulation model through HTTP or RPC. The interface can be built using frameworks such as Flask, FastAPI, gRPC, etc.

[0064] Each simulation model should have an independent life cycle, including creation, start, pause, destruction and other states. Therefore, the model management system uses the state mode to manage the model life cycle.

[0065] The model management system needs to persist the state and configuration of the model, use a database (such as PostgreSQL, MongoDB) to save the model instance and its running state to support breakpoint resumption, and use configuration files or databases (such as YAML, JSON, database tables) to save the device configuration parameters (such as device type, protocol stack, network topology, etc.).

[0066] In large-scale simulation, task scheduling and load balancing are particularly important. Device scheduling and load balancing can be achieved through resource-based dynamic scheduling and priority management. This requires simulation task allocation so that simulation tasks are executed in parallel on multiple nodes, and setting priorities for simulation tasks to ensure that high-priority tasks are processed first. The following uses Celery as an example to outline the implementation method of a distributed model management system.

[0067] Celery is a distributed task queue system that can execute tasks in parallel and supports task status tracking and result storage. Celery schedules and distributes tasks by combining message queues (such as Redis and RabbitMQ). First, create a task queue, and simulate the model's tasks, such as starting, pausing, and data processing. Each operation can be regarded as an independent task. Encapsulate these tasks as Celery tasks and add them to the queue. Then, run Celeryworkers on multiple machines, and these worker nodes can execute tasks in a distributed environment. Celery workers will take tasks from the task queue and execute them. Multiple workers can execute simulation tasks on different devices in parallel. During the simulation, tasks can be evenly distributed to appropriate workers through Celery's load balancing strategy. According to the system load, Celery can automatically assign tasks to idle nodes. If some nodes are overloaded, you can set an automatic expansion strategy to add more worker nodes to share the tasks. Celery provides a state tracking mechanism that records the execution status of each simulation task and saves it in a database (such as PostgreSQL or MongoDB). This allows tasks to be restored when the system fails or restarts.

[0068] Finally, a version control mechanism can be used for each simulation model to ensure that the update of different simulation models will not affect the overall operation of the system. Tools such as Git and SVN can be used to manage code and model versions.

[0069] In this embodiment, the main functions of the time synchronizer include: 1. Synchronizing the system time of each simulation node to ensure time consistency during the simulation process; 2. Maintaining the logical clock or physical clock, and determining the order of event execution based on the timestamp; 3. Processing time errors caused by time offset and delay, and performing time correction through protocols such as NTP or PTP; 4. Pausing and resuming the simulation when necessary.

[0070] In this system, virtual time is separated from physical time. Virtual time is the logical time used to track the occurrence of events in the simulation, while physical time refers to the passage of time in the real world. Through virtual time management, the simulation process can be accelerated or decelerated, thereby controlling the execution speed of simulation events.

[0071] Among them, the time synchronizer also includes a virtual time management function, which accelerates or decelerates the simulation time by adjusting the time step of event processing; and uses a control algorithm to automatically correct the time difference between simulation nodes.

[0072] Specifically, the time synchronizer is responsible for controlling the execution rhythm of simulation events, allowing simulation time to be faster or slower than real time, but the virtual time of all simulation models must be synchronized. The time synchronizer achieves this function by adjusting the time step of event processing.

[0073] First, define the scaling factor between virtual time and physical time in the simulation model. For example, setting it to 2 means that the simulation time runs at 2 times the speed, and 0.5 means that the simulation time runs at half the speed. This scaling factor will be used to adjust the scheduling frequency of events. In the event scheduling system, each time an event is scheduled, the virtual time manager adjusts the execution time of the next event according to the set scaling factor. This method can dynamically control the speed of time passing in the simulation, so that the simulation can be accelerated, decelerated, or paused.

[0074] To ensure that the execution order of simulation events on each node is consistent, a logical clock synchronization mechanism is required, such as the Lamport clock. Each node maintains an integer logical clock, and the clock value increases every time an event occurs or a message is received from another node. When an event is sent, the clock value of the sending node is attached, and the receiver takes the maximum value of its own clock and the sender's clock.

[0075] Since the physical clocks of each node may drift, especially in long-term simulations, time drift control becomes crucial. The time difference of each simulation node can be detected periodically to record the time drift. For example, a certain time interval can be set to synchronize the physical clock using the NTP or PTP protocol to ensure that the physical time of the simulation nodes is consistent. The simulation speed can also be adjusted by a PID controller to reduce the time difference between nodes. For example, when the time drift of a node is too large, the virtual time ratio of the node can be adjusted to make it run slightly faster or slower to correct the drift.

[0076] In this embodiment, the main functions of the message bus include: 1. Using the publish-subscribe (Pub / Sub) model to realize data transmission between devices and modules; 2. Distributing messages through communication protocols (such as MQTT, AMQP, ZeroMQ); 3. Routing events and data, and correctly delivering information according to the type of message and the target node; 4. Supporting message queues to handle message traffic under high concurrency; 5. Providing message persistence and logging functions to facilitate system debugging and monitoring.

[0077] In the specific implementation, the message bus is implemented using open source message middleware, such as RabbitMQ, ZeroMQ, Kafka or Mosquitto (MQTT). The message middleware supports the publish-subscribe mode (Pub / Sub) and the point-to-point communication mode, ensuring that the system can flexibly handle a variety of communication needs.

[0078] Use the queue model to process concurrent messages, maintain the order of message sending and receiving through the FIFO queue, and persist the messages to the database when necessary to ensure that the messages are not lost when the system is restarted.

[0079] The message bus requires an efficient routing mechanism that can distinguish different message types and target nodes by topic or queue name. When routing messages, a hash distribution algorithm (such as consistent hashing) can be used to determine the message forwarding path to ensure load balancing.

[0080] In large-scale IoT simulation scenarios, if multiple devices send status data at the same time, a combination of data compression and batch processing can be used to reduce network bandwidth consumption, improve simulation efficiency, and reduce simulation latency.

[0081] Therefore, before the message is transmitted, the message content is dynamically selected to be compressed according to the real-time requirements and compression rate requirements of the message transmission. Specifically, the purpose of message compression is to compress the data before the message is transmitted, thereby reducing the data size and bandwidth consumption. This embodiment selects compression algorithms such as LZ4 and Zlib. LZ4 is a high-speed compression algorithm suitable for scenarios requiring high throughput, but the compression rate is relatively low. It is suitable for simulation models with high real-time requirements. Zlib is a general compression algorithm with a high compression rate, but the compression speed is relatively slow. It is suitable for scenarios requiring a higher compression rate. When transmitting a message, the message content is first compressed and then sent to the receiving node. After the receiving node receives the message, it is first decompressed and then processed.

[0082] Before message compression, batch processing is first performed to merge multiple messages to be transmitted into one data packet, where the triggering condition of the batch processing is based on a preset time window or message quantity threshold. Specifically, the purpose of batch processing is to merge multiple messages into one data packet for transmission, reduce the number of transmissions and protocol header overhead, and improve transmission efficiency. Batch processing is suitable for scenarios with large-scale and high-frequency message transmission. Specifically, a time window or message quantity threshold can be set in the simulation model. When the time window expires or the number of messages meets the requirement, all messages within the time period are merged and sent.

[0083] After receiving the compressed data packet, the receiving node first performs a decompression operation to restore the original message content, and then further processes the message.

[0084] In actual use, the data can be merged first, and then a suitable algorithm can be selected for compression, which can further reduce bandwidth consumption and transmission delay. At the same time, combined with virtual time management, this can ensure the message transmission efficiency and consistency of each node and improve the efficiency of information transmission.

[0085] In this embodiment, the main functions of the front-end interface include: 1. Providing a user-friendly interface to manage simulation models, configure parameters, start and stop simulation; 2. Displaying the device status, sensor data, communication status and event log in real time; 3. Visualizing the time synchronization status, message flow and interaction between devices in the system; 4. Providing analysis results in the form of charts, logs, reports, etc. to help users understand the simulation results; 5. Supporting remote control interface for device operation and system configuration.

[0086] In the specific implementation, the front-end interface uses modern front-end frameworks (such as React, Vue.js or Angular) to build the user interface, and combines visualization libraries (such as D3.js, ECharts) to realize the chart display of device status and simulation data;

[0087] Furthermore, the front-end interface uses WebSocket or Server-Sent Events to achieve real-time communication with the backend, which can ensure that the status and data of the simulation process can be updated in real time on the front end. At the same time, dynamic information such as device communication traffic, message logs, event occurrence time, etc. can be displayed in real time.

[0088] Furthermore, the front-end interface needs to provide a control panel so that users can operate the simulation system, such as starting, pausing, resetting the simulation, modifying the device configuration, etc. It supports users to upload configuration files or parameters so as to flexibly adjust the simulation model and environment.

[0089] Furthermore, in order to facilitate the management of the communication topology between IoT devices, the front-end interface provides a drag-and-drop graphical editor, through which users can create or modify device connections.

[0090] In this embodiment, before starting the simulation, the type and quantity of devices in the IoT simulation environment and the topological structure between them are defined and edited through the graphical tools provided by the front-end interface;

[0091] Configure detailed properties of each IoT device;

[0092] The front-end interface collects all the data configured by the user and transmits this configuration information to the back-end model management system for storage in a structured data format;

[0093] After receiving the configuration data transmitted by the front end, the model management system automatically parses the data and dynamically generates an IoT simulation model instance consistent with the configuration based on the parsing results;

[0094] The generated simulation model instance includes all devices, topology and configuration information defined by the user.

[0095] In the specific operation process, first, create a simulation scene. The user uses this software to create a new simulation scene and define the device type, quantity and communication protocol in the simulation environment. In the front-end interface, users can use graphical tools to edit the topology of IoT devices and configure the properties of each device (such as communication protocol, sensor type, message format, etc.).

[0096] All configuration data is passed from the front end to the back end model management system, which uses JSON or YAML format to save device configurations and simulation scenarios. The back end system parses these configurations, generates simulation model instances, and prepares to start simulation.

[0097] When the user clicks the "Start Simulation" button, the model management system will generate all simulation models according to the configuration and initialize the system. After the simulation starts, each simulation model in the system starts working according to the defined time step and event sequence, and each device communicates through the message bus. The user can view the simulation progress in real time in the front-end interface, monitor the device status, communication log, sensor data, etc. The system provides the functions of pausing, resuming and stopping the simulation, and the user can dynamically adjust the simulation parameters during the simulation.

[0098] The backend starts the time synchronizer to keep the time of each simulation node consistent and starts the life cycle management of the simulation model. The message bus is responsible for handling the message transmission between simulation devices. The front end maintains real-time communication with the back end through WebSocket or SSE to display simulation data. The system's built-in event scheduler manages the event triggering and processing of all devices to ensure that events are executed in the predetermined order.

[0099] During the simulation process, various interactive commands are sent through the interactive functions provided by the front-end interface; the front-end interface UI components respond to user operations and generate corresponding API requests, which contain the interactive command information that the user wants to implement; the front-end interface sends the API request to the back-end model management system through the network. After receiving the request, the model management system immediately parses it and identifies the user's intention and specific command content; the model management system locates the corresponding simulation device in real time based on the parsed command content, and applies the command to the device to achieve dynamic control of the simulation device; after receiving the command, the simulation device immediately adjusts its operating status, configuration parameters or performs specific actions according to the command to respond to the user's interactive request.

[0100] As can be seen, users can view the operating status, sensor data, and message flow of each device in real time on the front end. The system supports interactive control of the devices in the simulation. Users can send commands, modify device configurations, or dynamically adjust communication parameters. Real-time data is pushed from the back end to the front end via WebSocket or SSE, and graphical libraries (such as D3.js, ECharts) are used to display data. The operation commands sent by the user trigger API requests through the front-end UI components, and the back-end system passes these commands to the corresponding simulation devices, which take effect immediately.

[0101] During the simulation, the system will continuously record all events and device status changes. After the simulation, these data are saved in the database or file system. After the simulation, the system will generate simulation results, including operation data of all devices, event trigger records, message exchange logs, etc. Users can further analyze the simulation results on the front-end interface. Based on the simulation results, users can re-enter the configuration interface through the front-end, modify simulation parameters or device behavior, and re-run the simulation to test different scenarios.

[0102] In summary, the present invention adopts a distributed architecture, which can distribute simulation tasks to multiple physical or virtual nodes and support simultaneous simulation of thousands of devices; through load balancing and task scheduling, it can better handle high-concurrency simulation tasks and support ultra-large-scale Internet of Things network simulation.

[0103] Furthermore, this embodiment performs strict time control through a time synchronizer to ensure that the time between distributed nodes remains consistent; a physical clock or a logical clock can be used to ensure that events occur in the expected order, which is particularly suitable for high-precision, time-sensitive application scenarios.

[0104] Furthermore, this embodiment adopts an event-driven architecture, and the corresponding device logic is executed only when a specific event is triggered, thereby reducing invalid calculations and resource usage, greatly improving performance, and is particularly suitable for simulation environments with limited resources.

[0105] Furthermore, this embodiment implements a flexible communication mechanism through a message bus, supports multiple communication protocols (such as MQTT, HTTP, CoAP, Zigbee, LoRa, etc.), and can dynamically expand the protocol stack to adapt to various complex communication scenarios. The message bus also supports efficient message routing and load balancing to ensure real-time message delivery.

[0106] Furthermore, this embodiment supports real-time monitoring. Users can view device status, message flow, sensor data, etc. during the simulation process. They can also dynamically control devices and adjust configurations in the simulation. This real-time feedback and interactive capability is critical for debugging and optimization in complex scenarios.

[0107] Furthermore, this embodiment adopts a modular design to allow users to expand or replace various parts as needed, such as adding a new protocol stack, adjusting the message transmission mechanism, introducing a new simulation model or algorithm, and users can flexibly customize the simulation environment according to specific needs.

[0108] The system provided in this embodiment is suitable for large-scale network environments that need to simulate tens of thousands or even millions of IoT devices, such as smart cities, smart agriculture, large-scale sensor networks, etc. The distributed architecture and time synchronization mechanism of the system ensure efficient coordination and communication between large-scale devices.

[0109] In complex scenarios that need to support multiple communication protocols at the same time (such as smart home, industrial Internet of Things, etc.), this system can simulate multiple protocol devices such as WiFi, Zigbee, LoRa, etc. through a flexible message bus and maintain interoperability between protocols. It is suitable for verifying scenarios of multi-protocol interconnection.

[0110] This system is particularly suitable for the scenario of IoT teaching simulation application in colleges and universities. There are many computers in the computer room of colleges and universities, and when conducting IoT simulation experiments, students do not start the simulation at the same time. Often, someone is running the simulation, someone is building the circuit, and someone is analyzing the results at the same time. When different students perform simulations at different times, the system can automatically assign tasks to idle computing nodes to balance the load, avoid a certain machine being overloaded while other machines are idle, thereby improving the utilization rate of the entire computer room. Because the system runs in a distributed manner, there is no need to configure a high-performance computer for each student separately. Only computers with general performance are needed. More efficient simulation can be achieved through clustering, reducing hardware procurement and maintenance costs.

[0111] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, 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, they should be considered to be within the scope of this specification.

[0112] The above-mentioned embodiments are only preferred embodiments of the present invention and cannot be used to limit the scope of protection of the present invention. Any non-substantial changes and substitutions made by technicians in this field on the basis of the present invention shall fall within the scope of protection required by the present invention.

Claims

1. A distributed Internet of Things simulation system based on time synchronization, event drive, and message bus, characterized in that: include: Simulation models, used to simulate different types of IoT devices or communication entities; each simulation model represents an independent physical device or communication entity, and is used to simulate the behavior, data generation and reception of the device; Model management system, used to manage and control the life cycle, configuration and version management of simulation models to ensure that different simulation models can be added, deleted or modified in the system; A time synchronizer is used to ensure that all nodes in a distributed simulation maintain a unified time base to guarantee the order and synchronous execution of events; Message bus, used to transmit messages, events and data between simulation nodes to ensure real-time communication and collaboration among various units in the distributed system; Front-end interface for real-time monitoring of simulation progress, operation of equipment, and viewing of simulation data.

2. The system according to claim 1, characterized in that: The simulation model adopts an event-driven architecture, including a simulation model, events, event queues, and event schedulers. Events are representations of device state changes in the system. Event queues are used to store upcoming events. All events are sorted according to their triggering time. Each event has a corresponding processing function, which triggers corresponding device behavior when the event occurs. When the simulation time reaches the trigger time of an event, the event scheduler takes the event out of the queue and triggers its corresponding operation, and schedules the event according to time sequence and priority; among them, the event is placed in the priority queue according to its scheduled execution time, and the scheduler takes the event out of the queue in order and executes it.

3. The system according to claim 2, characterized in that: Before starting the simulation, first create instances of all IoT devices, initialize their states, and then register their states and behaviors with the event scheduler of the simulation system; When starting the simulation, the event queue is checked regularly through the event scheduler, the events at the scheduled time are triggered and the corresponding event handlers are called; When the device status changes, a new event is generated based on the current device status and dynamically added to the event queue; for operations that require synchronization, the communication and operations between different devices are coordinated through simulation time.

4. The system according to claim 1, characterized in that: The model management system provides a RESTful API or gRPC interface to manage the simulation model via HTTP or RPC; The model management system uses the state mode to achieve the management of the model life cycle; The model management system uses a database to save model instances and their running states to support breakpoint resuming, and uses a configuration file or a database to save device configuration parameters.

5. The system according to claim 1, characterized in that: The time synchronizer also includes a virtual time management function, which realizes acceleration or deceleration of simulation time by adjusting the time step of event processing; and uses a control algorithm to automatically correct the time difference between simulation nodes.

6. The system according to claim 1, characterized in that: The message bus is implemented using open source message middleware, supports publish-subscribe mode and point-to-point communication mode, uses a queue model to process concurrent messages, maintains the order of sending and receiving messages through a FIFO queue, and persists messages to a database when necessary.

7. The system according to claim 6, characterized in that: Before the message is transmitted, the message content is dynamically compressed according to the real-time requirements and compression rate requirements of the message transmission; Before message compression, a batch operation is first performed to merge multiple messages to be transmitted into one data packet, wherein the triggering condition of the batch operation is based on a preset time window or message quantity threshold; After receiving the compressed data packet, the receiving node first performs a decompression operation to restore the original message content, and then further processes the message.

8. The system according to claim 1, characterized in that: The front-end interface uses a modern front-end framework to build a user interface, and combines with a visualization library to realize the graphical display of device status and simulation data; The front-end interface uses WebSocket or Server-Sent Events to achieve real-time communication with the backend.

9. The system according to claim 8, characterized in that: Before starting the simulation, define and edit the device types, quantities and topology between them in the IoT simulation environment through the graphical tools provided by the front-end interface; Configure detailed properties of each IoT device; The front-end interface collects all the data configured by the user and transmits this configuration information to the back-end model management system for storage in a structured data format; After receiving the configuration data transmitted by the front end, the model management system automatically parses the data and dynamically generates an IoT simulation model instance consistent with the configuration based on the parsing results; The generated simulation model instance includes all devices, topology and configuration information defined by the user.

10. The system according to any one of claims 1 to 9, characterized in that: During the simulation, various interactive commands are sent through the interactive functions provided by the front-end interface. The front-end UI component responds to the user's operation and generates a corresponding API request, which contains the interactive command information that the user wants to implement. The front-end interface sends the API request to the back-end model management system through the network. After receiving the request, the model management system immediately parses it and identifies the user's intention and specific command content; The model management system locates the corresponding simulation device in real time according to the parsed command content and applies the command to the device to achieve dynamic control of the simulation device; After receiving the command, the simulation device immediately adjusts its operating status, configuration parameters or performs specific actions according to the command to respond to the user's interaction request.

Images