Fibre Channel (FC) network simulation method and device based on simulation platform and electronic equipment

Abstract

This application discloses an FC network simulation method, apparatus, and electronic device based on a simulation platform, relating to the field of optical communication network simulation technology. The method includes: configuring simulation parameters and constructing an FC node model to generate FC packets. An FC switch model is constructed based on the simulation parameters, including a switch port model, a message distribution model, and a switch processor model. The switch port model includes cascaded ports, achieving accurate simulation of large-scale networks. FC packets are sent from the FC node model to the switch port model and then uploaded to the message distribution model via the switch port model. Based on the message distribution model, the FC packets are distributed to the switch processor model or cascaded ports according to packet field information. Based on the switch processor model or cascaded ports, the FC packets are cached and forwarded to the corresponding target node model based on priority, achieving a reliable distribution mechanism and improving the adaptability of the simulation.

Description

Technical Field

[0001] This application relates to the field of optical communication network simulation technology, and in particular to FC network simulation methods, devices and electronic equipment based on simulation platforms. Background Technology

[0002] FC (Fiber Channel) network simulation technology is widely used in avionics systems, data centers, and storage area networks. However, as network scale expands, especially in large-scale or ultra-large FC network simulations, traditional simulation methods face severe challenges. The surge in the number of nodes leads to an exponential increase in hardware costs, the complexity of the FC protocol stack is amplified, and the cumulative latency effect of cascading multi-level switches significantly reduces computational accuracy. Current methods struggle to verify the stability and reliability of large-scale, complex networks.

[0003] Therefore, improving the adaptability of large-scale FC network simulation is an urgent problem to be solved. Summary of the Invention

[0004] The main purpose of this application is to provide a simulation method, device and electronic device for FC network based on a simulation platform, which aims to solve the technical problem of how to improve the adaptability of large-scale FC network simulation.

[0005] To achieve the above objectives, this application proposes a simulation method for FC networks based on a simulation platform, the method comprising:

[0006] Configure simulation parameters;

[0007] Based on the simulation parameters, an FC node model is constructed, and FC messages are generated.

[0008] An FC switch model is constructed based on the simulation parameters. The FC switch model includes a switch port model, a message distribution model, and a switch processor model. The switch port model includes cascaded ports.

[0009] Message transmission occurs between the FC node model and the FC switch model;

[0010] The step of transmitting messages between the FC node model and the FC switch model includes:

[0011] The FC node model sends FC messages to the switch port model, and the switch port model uploads them to the message distribution model.

[0012] Based on the message distribution model, the FC message is distributed to the switch processor model or the cascade port according to the message field information;

[0013] Based on the switch processor model or the cascaded port, the FC message is cached and forwarded to the corresponding target node model based on priority.

[0014] In one embodiment, the simulation parameters include structural configuration parameters and message configuration parameters, and the FC node model includes a traffic model, an interface control model, a service model, and an FC processor model. The step of constructing the FC node model based on the simulation parameters and generating FC messages includes:

[0015] Node addresses are assigned to each FC node model according to the structure configuration parameters, and source address, destination address, load length and priority are configured for each message according to the message configuration parameters to obtain node configuration information;

[0016] The message configuration parameters are sent to the traffic model to extract traffic parameters and generate traffic messages.

[0017] The traffic message is sent to the interface control model to obtain the interface control message;

[0018] The interface control message is input into the business model, and the load data of the interface control message is injected with business functions to generate a processed message.

[0019] The processed message is sent to the FC processor model, and the processed message is framed using the FC protocol according to the node configuration information to generate an FC message.

[0020] In one embodiment, the business model includes a sequence integrity injection model and a data integrity injection model. The step of inputting the interface control message into the business model, injecting business into the payload data of the interface control message, and generating a processed message includes:

[0021] The sequential integrity injection model is used to inject a sequence identifier into the payload portion of the interface control message to generate a first processed message.

[0022] Cyclic redundancy check codes are injected into the payload portion of the interface control message using the data integrity injection model to generate a second processed message.

[0023] In one embodiment, the service model further includes a sequence integrity verification model and a data integrity verification model. After the step of transmitting messages between the FC node model and the FC switch model, the following steps are included:

[0024] If the FC message contains a sequence identifier, the validity of the sequence identifier is checked by the sequence integrity verification model;

[0025] If the FC message contains a Cyclic Redundancy Check (CRC) code, the validity of the CRC code is checked using the data integrity verification model.

[0026] In one embodiment, the traffic model includes a Poisson distribution traffic model, an exponential distribution traffic model, and a log-normal distribution traffic model. The step of sending the message configuration parameters to the traffic model, extracting the traffic parameters, and generating a traffic message includes:

[0027] Based on the message configuration parameters, traffic distribution characteristics are extracted, including Poisson distribution traffic characteristics, exponential distribution traffic characteristics, and log-normal distribution characteristics.

[0028] When the flow distribution characteristics are Poisson distribution, the Poisson distribution flow model is used to simulate the occurrence rate of random events.

[0029] When the flow distribution characteristics are exponential, the exponential flow model is used to simulate the exponential decay of the interval time.

[0030] When the flow distribution characteristics are log-normal, the log-normal flow model is used to simulate the long-tail distribution characteristics.

[0031] Based on the traffic model and the priority, traffic parameters are extracted and traffic messages are generated.

[0032] In one embodiment, the step of distributing the FC message to the switch processor model or the cascaded port based on the message distribution model and according to the message field information includes:

[0033] After the message distribution model receives the FC message, it determines whether the FC message is a current domain message;

[0034] If the FC message is a current domain message, then the current domain message is distributed to the switch processor model;

[0035] If the FC message is not a current domain message, then the FC message is distributed to the cascade port.

[0036] In one embodiment, the step of transmitting messages between the FC node model and the FC switch model further includes:

[0037] When the triggering condition is met, a fault injection model is inserted between the FC node model and the FC switch model. The fault injection model includes a physical fault injection model, an FC header fault injection model, a packet loss model, and a cyclic redundancy check error injection model.

[0038] Based on the physical fault injection model, random bit errors are injected into the load portion to simulate bit error phenomena in actual transmission.

[0039] Based on the FC header fault injection model, according to the FC header matching rules, the original fields are replaced with new FC header fields to simulate FC header fault injection.

[0040] Based on the packet loss model, packets are randomly selected and discarded to simulate packet loss in actual transmission.

[0041] Based on the Cyclic Redundancy Check (CRC) error injection model, erroneous CRC codes are injected to simulate the CRC error phenomenon in actual transmission.

[0042] In one embodiment, the node model includes a clock-synchronized FC node model, and the step of transmitting messages between the FC node model and the FC switch model includes:

[0043] PTP protocol messages are transmitted between the clock-synchronized FC node model and the FC switch model. The clock-synchronized FC node model includes a master node model and a slave node model.

[0044] The step of transmitting PTP protocol messages between the clock synchronization FC node model and the FC switch model includes:

[0045] The master node model broadcasts PTP synchronization clock messages to the slave node model at synchronization time intervals.

[0046] After receiving the PTP synchronization clock message, the slave node model sends a PTP clock request message to the master node model.

[0047] After receiving the PTP clock request message, the master node sends a PTP clock request response message to the slave node.

[0048] After receiving the PTP clock request response message, the slave node calculates the time offset based on the PTP synchronization clock message and the PTP clock request response message, and corrects the time of the slave node model based on the time offset.

[0049] The process returns to the step of broadcasting PTP synchronization clock messages to the slave node model at synchronization time intervals until the time of the master node model and the slave node model is synchronized.

[0050] Furthermore, to achieve the above objectives, this application also proposes an FC network simulation device based on a simulation platform, the FC network simulation device based on the simulation platform comprising:

[0051] The parameter configuration module is used to configure simulation parameters;

[0052] The node construction module is used to construct an FC node model based on the simulation parameters and generate FC messages.

[0053] A switch construction module is used to construct an FC switch model based on the simulation parameters. The FC switch model includes a switch port model, a message distribution model, and a switch processor model. The switch port model includes cascaded ports.

[0054] The message transmission module is used to perform message transmission between the FC node model and the FC switch model;

[0055] The message transmission module is further configured to send FC messages to the switch port model through the FC node model, and upload them to the message distribution model through the switch port model; based on the message distribution model, distribute the FC messages to the switch processor model or the cascade port according to the message field information; based on the switch processor model or the cascade port, cache the FC messages, and forward them to the corresponding target node model based on priority.

[0056] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the FC network simulation method based on the simulation platform described above.

[0057] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the FC network simulation method based on the simulation platform described above.

[0058] One or more technical solutions proposed in this application have at least the following technical effects:

[0059] By configuring simulation parameters and defining network structure and message attributes through parameterization, the complexity of configuration caused by manual coding or file modification in traditional FC network simulation is solved. Compared with hardware simulation methods, it achieves flexible and efficient simulation initialization and reduces development costs.

[0060] FC node models are built based on simulation parameters to generate FC messages. FC node models are built based on configuration parameters, and FC messages are generated through modular design (such as flow models and FC processor models). This solves the problem of insufficient scalability caused by hardware dependence, realizes software simulation, and improves adaptability to complex scenarios such as avionics systems.

[0061] An FC switch model is constructed based on simulation parameters. The FC switch model includes a switch port model, a message distribution model, and a switch processor model. The switch port model includes cascaded ports, which support multi-level network connections. This solves the protocol complexity and latency accumulation effect when multiple switches are cascaded, and realizes accurate simulation of large-scale networks.

[0062] This system facilitates packet transmission between the FC node model and the FC switch model. The FC node model sends FC packets to the switch port model, which then uploads them to the message distribution model. Based on the message distribution model, the FC packets are distributed to the switch processor model or cascaded ports according to packet domain information. The switch processor model or cascaded ports then buffer the FC packets and forward them to the corresponding target node model based on priority. During packet transmission, the FC node model sends FC packets to the switch port model and uploads them to the message distribution model, achieving efficient packet entry and avoiding routing errors caused by inaccurate entry processing in traditional methods. The message distribution model distributes packets based on packet domain information, determining the current domain packet and distributing it to the switch processor model or cascaded ports. This solves the intelligent decision-making problem for multi-domain network routing, achieving a reliable distribution mechanism and timely processing of high-priority packets, thus improving the overall network stability and reliability. Attached Figure Description

[0063] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0064] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0065] Figure 1 This is a flowchart illustrating the first embodiment of the FC network simulation method based on a simulation platform according to this application.

[0066] Figure 2 This is a schematic diagram illustrating the construction of a large-scale network based on an embodiment of this application;

[0067] Figure 3 This is another flowchart illustrating the first embodiment of the FC network simulation method based on a simulation platform according to this application;

[0068] Figure 4 This is a schematic diagram of the simulation process of the FC switch model in the embodiment of this application;

[0069] Figure 5 This is a flowchart illustrating the second embodiment of the FC network simulation method based on a simulation platform according to this application.

[0070] Figure 6 This is a schematic diagram of the simulation process of the fault injection model in an embodiment of this application;

[0071] Figure 7 This is a schematic diagram of the network structure of the fault injection model in an embodiment of this application;

[0072] Figure 8 A schematic diagram of the simulation process for data verification after injecting a fault into an embodiment of this application;

[0073] Figure 9 This is a schematic diagram of the simulation process of the PTP high-precision clock synchronization model in an embodiment of this application;

[0074] Figure 10 This is a schematic diagram of the module structure of the FC network simulation device based on the simulation platform according to an embodiment of this application;

[0075] Figure 11 This is a schematic diagram of the device structure of the hardware operating environment involved in the FC network simulation method based on the simulation platform in the embodiments of this application.

[0076] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0077] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0078] To better understand the technical solution of this application, the following detailed description, in conjunction with the accompanying drawings, through specific embodiments and application scenarios, provides the FC network simulation method, FC network simulation device, and electronic device based on the simulation platform provided in this application.

[0079] It should be noted that the FC network simulation method based on the simulation platform can be applied to the terminal, and can be executed by the hardware or software in the terminal.

[0080] The terminal includes, but is not limited to, portable communication devices such as mobile phones or tablets with touch-sensitive surfaces (e.g., touchscreen displays and / or touchpads). It should also be understood that, in some embodiments, the terminal may not be a portable communication device, but rather a desktop computer with touch-sensitive surfaces (e.g., touchscreen displays and / or touchpads).

[0081] The following embodiments describe a terminal including a display and a touch-sensitive surface. However, it should be understood that the terminal may include one or more other physical user interface devices such as a physical keyboard, mouse, and joystick.

[0082] It should be noted that the simulation platform can be the OMNeT++ platform. The modular design of OMNeT++ allows for the implementation of the FC protocol layer by layer, which is suitable for protocol innovation, performance optimization and education and training, and supports custom protocol extensions. It can also be integrated with other network technologies to simulate heterogeneous storage network environments. The following embodiments and implementation methods describe the FC network simulation method based on the OMNeT++ platform.

[0083] Based on this, the embodiments of this application provide an FC network simulation method based on a simulation platform, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the FC network simulation method based on a simulation platform according to this application.

[0084] In the first embodiment, the FC network simulation method based on the simulation platform includes steps S10 to S40:

[0085] Step S10: Configure simulation parameters.

[0086] It should be noted that simulation parameters include structural configuration parameters and message configuration parameters. For example, an ICD (Interface Control Document) configuration file and a NED (Network Description Language) configuration file can be provided. The ICD configuration file defines the communication parameters for each message, while the NED configuration file defines the network connection structure and node interconnection relationships, and is suitable for the OMNeT++ platform.

[0087] Step S20: Construct an FC node model based on simulation parameters and generate FC messages.

[0088] For example, an FC node model can be constructed based on the ICD configuration file and the NED configuration file. The FC node model is a composite model, which can consist of a traffic model, an ICD model, a service model, and an FC processor model. For example, multiple FC node models can be constructed, and each FC node model communicates by sending and receiving messages. The network's operating status can be viewed by monitoring the message sending and receiving information of each FC node model.

[0089] Step S30: Construct an FC switch model based on simulation parameters. The FC switch model includes a switch port model, a message distribution model, and a switch processor model. The switch port model includes cascaded ports.

[0090] It should be noted that the FC switch model is a composite model, which can consist of a switch port model, a message distribution model, and a switch processor model. It simulates the functions of an FC switch, supports message buffering, cascading, and multi-level priority processing, and is used to implement packet routing in large-scale networks. For example, ... Figure 2 As shown, the large-scale network consists of 5 small networks (SmallNets). Each SmallNet contains a 24-port FC switch model and 22 FC node models. In this simulated network, there are 110 FC node models and 5 FC switch models, realizing multi-level cascading functionality. Each FC node model communicates by sending and receiving messages, and the network's operating status can be viewed by monitoring the message sending and receiving information of the node models.

[0091] Step S40: Message transmission is performed between the FC node model and the FC switch model.

[0092] It should be noted that, referring to Figure 3 Step S40 includes:

[0093] Step S401: The FC message is sent to the switch port model through the FC node model, and then uploaded to the message distribution model through the switch port model.

[0094] It should be noted that switch port models can include regular ports and cascade ports. Cascade ports are specifically used to connect multiple switches, supporting multi-level network cascading.

[0095] Step S402: Based on the message distribution model, the FC message is distributed to the switch processor model or cascade port according to the message field information.

[0096] It should be noted that the message distribution model is responsible for distributing the received FC packets to the switch processor model (for local domain processing) or the cascading port (for cross-domain forwarding), intelligently deciding the distribution path based on the packet domain information. Step S402 includes: after the message distribution model receives the FC packet, it determines whether the FC packet is a current domain packet; if the FC packet is a current domain packet, it distributes the current domain packet to the switch processor model; if the FC packet is not a current domain packet, it distributes the FC packet to the cascading port.

[0097] For example, message domain information can be identifiers in FC messages, such as domain IDs, used to distinguish the domain to which the message belongs, and to determine during routing whether the message should be processed locally or forwarded to other domains. Current domain messages can be FC messages whose message domain information matches the current switch domain, and are distributed to the switch processor model after being determined by the message distribution model.

[0098] Step S403: Based on the switch processor model or cascade port, the FC message is cached and forwarded to the corresponding target node model based on priority.

[0099] It's important to note that the switch processor model processes FC packets within its local area, including buffering packets (temporarily storing them to handle congestion) and priority-based forwarding (setting the processing order according to packet priority) to ensure efficient packet routing. The forwarding order is determined based on the priority of the FC packets, such as a four-level system: high, medium, low, and default. High-priority packets are processed first, simulating the QoS (Quality of Service) mechanism of a real FC network. The destination node model can be understood as the FC node model that receives and forwards the FC packets, serving as the endpoint for packet transmission.

[0100] For example, such as Figure 4 As shown, after initialization based on parameters such as the number of ports and domain ID, the switch port model receives FC packets and then hands them over to the message distribution model for message distribution. After receiving FC packets, the message distribution model hands over FC packets from the local domain to the switch processing model, while those from non-local domains are forwarded by the cascaded ports. After receiving FC packets, the FC switch processing model stores the packets and forwards them based on factors such as priority and receiving order.

[0101] In this embodiment, simulation parameters (such as ICD configuration files and NED files) are configured, and network structure and message attributes are defined parametrically. This solves the configuration complexity problem caused by manual coding or file modification in traditional FC network simulation. Compared with hardware simulation methods, this achieves flexible and efficient simulation initialization and reduces development costs. Furthermore, an FC node model is constructed based on the configuration parameters, and FC packets are generated through modular design (such as traffic models and FC processor models). This solves the problem of insufficient scalability caused by hardware dependence, realizes software simulation, and improves adaptability to complex scenarios such as avionics systems. Further, an FC switch model is constructed, including a switch port model (including cascaded ports), a message distribution model, and a switch processor model. Cascaded ports support multi-level network connections, solving the protocol complexity and latency accumulation effects of multi-level switch cascading, and achieving accurate simulation of large-scale networks. During packet transmission, FC packets are sent to the switch port model and uploaded to the message distribution model through the FC node model, achieving efficient packet entry and avoiding routing errors caused by inaccurate entry processing in traditional methods. Based on a message distribution model, packets are distributed according to their domain information. By determining the current domain of the packet and distributing it to the switch processor model or cascaded ports, the intelligent decision-making problem of multi-domain network routing is solved, achieving a reliable distribution mechanism and expanding network scale. Finally, FC packets are cached based on the switch processor model or cascaded ports and forwarded according to priority. Through caching to handle congestion and priority scheduling, the problem of unstable network traffic is solved, enabling timely processing of high-priority packets and improving the overall stability and reliability of the network. The entire process relies solely on a software platform, significantly reducing hardware costs while improving the simulation accuracy and adaptability of large-scale FC networks.

[0102] Reference Figure 5 , Figure 5 This is a flowchart illustrating the second embodiment of the FC network simulation method based on a simulation platform according to this application. Figure 1 The first embodiment shown presents a second embodiment of the FC network simulation method based on a simulation platform according to this application.

[0103] In the second embodiment, the FC node model includes a traffic model, an interface control model, a service model, and an FC processor model. Step S20 includes:

[0104] Step S201: Assign node addresses to each FC node model according to the structure configuration parameters, and configure source address, destination address, load length and priority for each message according to the message configuration parameters to obtain node configuration information.

[0105] It should be noted that the structure configuration parameters can be network topology parameters defined in the network configuration NED file, including network structure information such as node connection relationships, number of ports, and domain ID. Message configuration parameters can originate from the parameter definitions in the ICD configuration file, including message attributes such as source address, destination address, load length, and priority (e.g., level 4). Node configuration information can be configuration data generated by combining structure parameters and message parameters, including node address allocation results and message routing rules.

[0106] Step S202: Send the message configuration parameters to the traffic model, extract the traffic parameters, and generate a traffic message.

[0107] For example, the traffic model is a core component of the FC node model, generating traffic messages based on traffic parameters (distribution type, rate, priority). Traffic parameters can be understood as key data extracted from the message configuration, including traffic distribution type, message generation rate, load size, and priority level. Traffic messages can be raw data units generated by the traffic model, containing simulated business content and a 4-level priority identifier, serving as input stimuli for the interface control model.

[0108] Step S203: Send the traffic message to the interface control model to obtain the interface control message.

[0109] It should be noted that the Interface Control Model (ICD model) can convert traffic messages into standardized ICD messages, adding protocol headers such as source / destination addresses. Interface Control Messages (ICD messages) are semi-finished messages conforming to the FC protocol format (address encapsulation is complete, but no service payload is added).

[0110] Step S204: Input the interface control message into the business model, inject business into the load data of the interface control message, and generate the processed message.

[0111] It should be noted that the business model is used to inject business logic into the payload data of ICD messages and modify the payload data according to configuration parameters, such as adding sequence numbers or verification fields, to generate processed messages.

[0112] Step S205: The processed message is sent to the FC processor model, and the processed message is framed according to the node configuration information to generate an FC message.

[0113] It should be noted that the FC processor model can encapsulate processed messages into complete FC messages based on node configuration information. FC protocol framing is the process of encapsulating processed ICD messages into standard FC messages based on node configuration information. Its technical essence is to construct transmission units that conform to the FC network communication standard by adding protocol headers, payload encapsulation, and other operations.

[0114] In this embodiment, node addresses are allocated and message parameters are configured according to structural configuration parameters. Network topology and message attributes are automatically defined through NED files and ICD configuration files, solving the complexity problem of manually coding and configuring nodes and messages in traditional simulations and achieving efficient parameter-driven initialization. By sending message configuration parameters to the traffic model to generate traffic messages, the problem that a single traffic model cannot adapt to diverse scenarios such as avionics and data centers is solved, achieving high-precision simulation of real network traffic. Furthermore, the traffic messages are converted into standard interface control messages through the ICD model, and source / destination addresses are automatically added based on the ICD configuration, solving the inefficiency problem of manually assembling protocol headers and achieving automated encapsulation of the protocol stack. On this basis, the ICD message payload is injected with services through the business model, supporting both sequential integrity and data integrity verification models, solving the problem of the disconnect between simulation data and real business logic, and achieving accurate restoration of business scenarios such as avionics commands and storage operations. Finally, FC messages are generated by framing through the FC processor model, and protocol encapsulation is automatically completed according to node configuration, solving the limitation of protocol implementation relying on dedicated hardware in traditional methods and achieving pure software-based standard FC message generation.

[0115] In one implementation, the traffic model includes a Poisson distribution traffic model, an exponential distribution traffic model, and a log-normal distribution traffic model. Step S202 includes: extracting traffic distribution characteristics based on message configuration parameters, the traffic distribution characteristics including Poisson distribution traffic characteristics, exponential distribution traffic characteristics, and log-normal distribution characteristics; when the traffic distribution characteristics are Poisson distribution traffic characteristics, using a Poisson distribution traffic model to simulate the occurrence rate of random events; when the traffic distribution characteristics are exponential distribution traffic characteristics, using an exponential distribution traffic model to simulate the exponential decay of the interval time; when the traffic distribution characteristics are log-normal distribution characteristics, using a log-normal distribution traffic model to simulate the long-tail distribution characteristics; and extracting traffic parameters and generating traffic messages based on the traffic model and priority.

[0116] For example, the Poisson distribution traffic model, based on a traffic generator using Poisson distribution theory, is used to simulate the occurrence rate of random events (such as the burst arrival of network packets) and can be used to simulate burst command transmissions in avionics system simulations. The exponential distribution traffic model, based on a traffic generator using an exponential distribution, simulates the exponential decay characteristics of event intervals (such as the fixed latency of packet transmission) and is suitable for steady-state traffic simulations in data centers. The log-normal distribution traffic model, based on a traffic generator using a log-normal distribution, simulates long-tail distribution characteristics (such as latency fluctuations in large file transfers) and is used for large data block transmission scenarios in storage networks.

[0117] In this implementation, traffic distribution characteristics are extracted based on message configuration parameters. By parsing the ICD configuration file, three distribution characteristics—Poisson, exponential, and log-normal—are automatically identified. This solves the limitation of traditional simulations where a single traffic model cannot adapt to multiple service scenarios (such as avionics burst commands and storage steady-state transmission). It achieves scenario-based and accurate matching of traffic generation. By dynamically selecting the distribution model, when the traffic characteristics are Poisson, the Poisson model is used to simulate the occurrence rate of random events (such as command bursts), solving the problem of distorted simulation of avionics system command response. When the traffic characteristics are exponential, the exponential model is used to simulate interval decay (such as fixed-period heartbeat packets), solving the problem of insufficient simulation accuracy for periodic fluctuations in data center traffic. When the traffic characteristics are log-normal, the log-normal model is used to simulate long-tail characteristics (such as large file transmission delays), solving the problem of excessive simulation deviation for large data block transmission in storage networks. Based on this, by combining four-level priority parameters to generate traffic messages, the characteristics of service scenarios (such as high-priority avionics control commands) are integrated with traffic statistical characteristics, solving the problem of differentiated modeling of complex network mixed service flows.

[0118] In one implementation, the business model includes a sequence integrity injection model and a data integrity injection model. Step S204 includes: injecting a sequence identifier into the payload portion of the interface control message through the sequence integrity injection model to generate a first processed message; and injecting a cyclic redundancy check (CRC) code into the payload portion of the interface control message through the data integrity injection model to generate a second processed message.

[0119] It should be noted that the business model also includes a sequence integrity verification model and a data integrity verification model. Therefore, after step S40, the model further includes: if the FC message contains a sequence identifier, then the validity of the sequence identifier is checked through the sequence integrity verification model; if the FC message contains a cyclic redundancy check (CRC) code, then the validity of the CRC code is checked through the data integrity verification model.

[0120] For example, the business model can be divided into business injection and business validation. The business injection model includes a sequence integrity injection model and a data integrity injection model, while the business validation model includes a sequence integrity validation model and a data integrity validation model. When using the sequence integrity validation model to verify data integrity, the sequence integrity injection model is used in the node model, injecting sequence into the load portion. The sequence integrity validation model checks whether the load order is valid, thereby achieving the purpose of verifying data integrity. When using the data integrity validation model to verify data integrity, the data integrity injection model is used in the node model, injecting the load's CRC into the load portion. The data integrity validation model checks whether the load's CRC field is valid, thereby achieving the purpose of verifying data integrity. Business injection and business validation are used together to verify data integrity.

[0121] In this implementation, by adding identifiers such as sequence numbers to simulate the order guarantee mechanism of a real FC network, the problem of difficulty in simulating out-of-order message phenomena (such as command misalignment in avionics systems) in traditional simulations is solved. Compared with existing hardware simulation methods, high-fidelity simulation of order-sensitive service scenarios is achieved, improving the credibility of simulation results. Furthermore, by injecting CRC codes through a data integrity injection model and embedding check codes in the load to simulate data protection mechanisms, fault tolerance simulation for high-risk environments such as storage networks is achieved. Based on this, end-to-end order integrity verification is realized by checking the legality of sequence identifiers using an order integrity verification model. The entire process, through bidirectional collaboration between injection and verification, significantly improves the realism and robustness of the simulation.

[0122] In one implementation, step S40 further includes: when the triggering condition is met, inserting a fault injection model between the FC node model and the FC switch model. The fault injection model includes a physical fault injection model, an FC header fault injection model, a packet loss model, and a cyclic redundancy check (CRC) error injection model. Based on the physical fault injection model, randomly injecting errors into the load portion to simulate bit error phenomena in actual transmission. Based on the FC header fault injection model, replacing the original fields with new FC header fields according to the FC header matching rules to simulate FC header fault injection. Based on the packet loss model, randomly selecting and discarding packets to simulate packet loss phenomena in actual transmission. Based on the CRC error injection model, injecting erroneous CRC codes to simulate CRC errors in actual transmission.

[0123] For example, such as Figure 6As shown, the fault injection model can be used to simulate real network faults in the FC packet transmission path. The physical fault injection model randomly injects errors (such as bit flips) into the FC packet payload. The trigger condition is the error probability threshold in the configuration parameters (e.g., when the error rate is set to 0.1% in the ICD configuration, random error injection is triggered once every 1000 packets), simulating physical link interference. The FC header fault injection model replaces existing fields according to FC header matching rules (e.g., modifying the correct field ID to an invalid value). The trigger condition is the header field matching rule (e.g., forced injection when the destination address is 0xFF), simulating protocol configuration errors. The packet loss model selects and discards FC packets. The trigger condition is the packet loss probability parameter (e.g., when the packet loss rate is configured to be 1%, 1% of packets are randomly discarded), simulating network congestion or device failure. The CRC error injection model injects erroneous CRC checksums into FC packets. The trigger condition is a CRC error probability threshold (e.g., triggered when the CRC injection switch is enabled and the probability > 0.5%), simulating a checksum failure in data transmission. The network structure of the fault injection model can be found in [reference needed]. Figure 7 The simulation process for data verification after fault injection can be found by referring to... Figure 8 .

[0124] In this implementation, on-demand fault injection is achieved by dynamically configuring triggering conditions (such as probability thresholds and rule matching), overcoming the limitation of traditional simulations in simulating real network fault scenarios and realizing precise and controllable simulation of abnormal network behavior. By randomly injecting load errors through a physical fault injection model, the fault tolerance capability of sensitive scenarios such as avionics systems is verified. By replacing header fields through an FC header fault injection model and simulating protocol configuration errors based on matching rules (such as specific addresses), robustness stress testing of the FC protocol stack is achieved. By randomly discarding packets through a packet loss model, quantitative analysis of packet loss tolerance in large-scale data center environments is realized. By injecting error check codes through a CRC error injection model, the entire lifecycle verification of the data protection mechanism for the storage network is achieved.

[0125] In one implementation, the node model includes a clock-synchronized FC node model, and step S40 further includes: transmitting PTP (Precision Time Protocol) messages between the clock-synchronized FC node model and the FC switch model. The clock-synchronized FC node model includes a master node model and a slave node model.

[0126] Specifically, the steps for transmitting PTP protocol messages between the clock-synchronized FC node model and the FC switch model include: the master node model broadcasting PTP synchronization clock messages to the slave node model at synchronization intervals; after receiving the PTP synchronization clock messages, the slave node model sends PTP clock request messages to the master node model; after receiving the PTP clock request messages, the master node sends PTP clock request response messages to the slave node; after receiving the PTP clock request response messages, the slave node calculates the time offset based on the PTP synchronization clock messages and the PTP clock request response messages, and corrects the slave node model's time based on the time offset; the process returns to the step of the master node model broadcasting PTP synchronization clock messages to the slave node model at synchronization intervals, until the time of the master node model and the slave node model is synchronized.

[0127] For example, such as Figure 9 As shown, the simulation process of the PTP high-precision clock synchronization model includes a master node model, a slave node model, and an FC switch model. Both the master and slave node models are PTP high-precision clock synchronization node models. The specific process is as follows:

[0128] (1) The master node model sends a PTP synchronization clock message to the slave node model via broadcast;

[0129] (2) After receiving the PTP synchronization clock message, the slave node model sends a PTP clock request message to the master node model.

[0130] (3) After receiving the PTP clock request message, the master node model sends a PTP clock request reply message to the slave node model.

[0131] (4) After receiving the PTP clock request response packet, the slave node model calculates the time offset and corrects the time of the slave node model.

[0132] It is understandable that the process described above (1) to (4) is a cyclical and continuous synchronization process. Steps (1) to (4) are executed periodically according to the synchronization time interval to maintain time synchronization between the slave node model and the master node model.

[0133] In this implementation, broadcasting PTP synchronization clock messages (such as time base distribution in avionics systems) by the master node model solves the problem of insufficient time synchronization accuracy in traditional FC network simulations (due to the cumulative delay effect caused by cascading multi-level switches). By sending PTP clock request messages and receiving response messages by the slave node model, a bidirectional delay compensation mechanism is implemented based on message exchange to measure network transmission delay, improving the reliability of simulation results. Furthermore, by calculating the time offset and correcting the time by the slave node model, and dynamically adjusting the local clock using timestamp differences (such as timing alignment of avionics control commands), the problem of service logic disorder caused by node time drift in large-scale networks is solved, achieving high-precision network-wide time consistency. Finally, by periodically returning to the broadcast step until time synchronization, and continuously iterating at synchronization time intervals, an adaptive synchronization mechanism is implemented, thereby supporting the long-term stable operation of large-scale networks.

[0134] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the FC network simulation method based on the simulation platform of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0135] This application also provides an FC network simulation device based on a simulation platform, please refer to... Figure 10 The FC network simulation device based on the simulation platform includes:

[0136] Parameter configuration module 10 is used to configure simulation parameters;

[0137] Node building module 20 is used to build an FC node model based on the simulation parameters and generate FC messages;

[0138] The switch construction module 30 is used to construct an FC switch model based on the simulation parameters. The FC switch model includes a switch port model, a message distribution model, and a switch processor model. The switch port model includes cascading ports.

[0139] Message transmission module 40 is used to transmit messages between the FC node model and the FC switch model;

[0140] The message transmission module 40 is further configured to send FC messages to the switch port model through the FC node model, and upload them to the message distribution model through the switch port model; based on the message distribution model, distribute the FC messages to the switch processor model or the cascade port according to the message field information; based on the switch processor model or the cascade port, cache the FC messages, and forward them to the corresponding target node model based on priority.

[0141] The FC network simulation device based on a simulation platform provided in this application, employing the FC network simulation method based on a simulation platform as described in the above embodiments, can solve the technical problem of how to improve the adaptability of large-scale FC network simulation. Compared with the prior art, the beneficial effects of the FC network simulation device based on a simulation platform provided in this application are the same as those of the FC network simulation method based on a simulation platform provided in the above embodiments, and other technical features in the FC network simulation device based on a simulation platform are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0142] This application provides an electronic device 2000 including: at least one processor 2001; and a memory 2003 communicatively connected to the at least one processor 2001; wherein the memory 2003 stores instructions that can be executed by the at least one processor 2001, and the instructions are executed by the at least one processor 2001 to enable the at least one processor 2001 to execute the FC network simulation method based on the simulation platform in the above embodiment 1.

[0143] The following is for reference. Figure 11 This diagram illustrates a structural schematic of an electronic device 2000 suitable for implementing embodiments of this application. The electronic device 2000 in this application embodiment may include a processor 2001 and a memory 2003. The processor 2001 and the memory 2003 are connected, for example, via a bus 2002. Optionally, the electronic device 2000 may also include a transceiver 2004. It should be noted that in practical applications, the transceiver 2004 is not limited to one, and the structure of this electronic device 2000 does not constitute a limitation on the embodiments of this application.

[0144] Processor 2001 may be a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic device, transistor logic device, hardware component, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 2001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0145] Bus 2002 may include a pathway for transmitting information between the aforementioned components. Bus 2002 may be a PCI bus or an EISA bus, etc. Bus 2002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 11 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0146] The memory 2003 may be ROM or other type of static storage device capable of storing static information and instructions, RAM or other type of dynamic storage device capable of storing information and instructions, or EEPROM, CD-ROM or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0147] The memory 2003 stores the application code that executes the scheme of this application, and its execution is controlled by the processor 2001. The processor 2001 executes the application code stored in the memory 2003 to implement... Figure 10 The illustrated embodiment demonstrates the operation of the FC network simulation device based on a simulation platform.

[0148] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0149] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A simulation method for FC networks based on a simulation platform, characterized in that, The method includes: Configure simulation parameters, which include structural configuration parameters and message configuration parameters; An FC node model is constructed based on the simulation parameters, and FC messages are generated. The FC node model includes a traffic model, an interface control model, a service model, and an FC processor model. An FC switch model is constructed based on the simulation parameters. The FC switch model includes a switch port model, a message distribution model, and a switch processor model. The switch port model includes cascaded ports. Message transmission occurs between the FC node model and the FC switch model; The step of constructing an FC node model based on the simulation parameters and generating FC messages includes: Node addresses are assigned to each FC node model according to the structure configuration parameters, and source address, destination address, load length and priority are configured for each message according to the message configuration parameters to obtain node configuration information; The message configuration parameters are sent to the traffic model to extract traffic parameters and generate traffic messages. The traffic message is sent to the interface control model to obtain the interface control message; The interface control message is input into the business model, and the load data of the interface control message is injected with business functions to generate a processed message. The processed message is sent to the FC processor model, and the processed message is framed according to the node configuration information to generate an FC message. The steps for transmitting messages between the FC node model and the FC switch model include: The FC node model sends FC messages to the switch port model, and the switch port model uploads them to the message distribution model. Based on the message distribution model, the FC message is distributed to the switch processor model or the cascade port according to the message field information; Based on the switch processor model or the cascaded port, the FC message is cached and forwarded to the corresponding target node model based on priority.

2. The method as described in claim 1, characterized in that, The business model includes a sequential integrity injection model and a data integrity injection model. The step of inputting the interface control message into the business model, injecting business data into the payload data of the interface control message, and generating a processed message includes: The sequential integrity injection model is used to inject a sequence identifier into the payload portion of the interface control message to generate a first processed message. Cyclic redundancy check codes are injected into the payload portion of the interface control message using the data integrity injection model to generate a second processed message.

3. The method as described in claim 2, characterized in that, The business model also includes a sequence integrity verification model and a data integrity verification model. Following the step of transmitting messages between the FC node model and the FC switch model, the following steps are included: If the FC message contains a sequence identifier, the validity of the sequence identifier is checked by the sequence integrity verification model; If the FC message contains a Cyclic Redundancy Check (CRC) code, the validity of the CRC code is checked using the data integrity verification model.

4. The method as described in claim 1, characterized in that, The traffic model includes a Poisson distribution traffic model, an exponential distribution traffic model, and a log-normal distribution traffic model. The step of sending the message configuration parameters to the traffic model, extracting the traffic parameters, and generating a traffic message includes: Based on the message configuration parameters, traffic distribution characteristics are extracted, including Poisson distribution traffic characteristics, exponential distribution traffic characteristics, and log-normal distribution characteristics. When the flow distribution characteristics are Poisson distribution, the Poisson distribution flow model is used to simulate the occurrence rate of random events. When the flow distribution characteristics are exponential, the exponential flow model is used to simulate the exponential decay of the interval time. When the flow distribution characteristics are log-normal, the log-normal flow model is used to simulate the long-tail distribution characteristics. Based on the traffic model and the priority, traffic parameters are extracted and traffic messages are generated.

5. The method as described in claim 1, characterized in that, The step of distributing the FC message to the switch processor model or the cascaded port based on the message distribution model and according to the message field information includes: After the message distribution model receives the FC message, it determines whether the FC message is a current domain message; If the FC message is a current domain message, then the current domain message is distributed to the switch processor model; If the FC message is not a current domain message, then the FC message is distributed to the cascade port.

6. The method as described in claim 1, characterized in that, The step of transmitting messages between the FC node model and the FC switch model further includes: When the triggering condition is met, a fault injection model is inserted between the FC node model and the FC switch model. The fault injection model includes a physical fault injection model, an FC header fault injection model, a packet loss model, and a cyclic redundancy check error injection model. Based on the physical fault injection model, random bit errors are injected into the load portion to simulate bit error phenomena in actual transmission. Based on the FC header fault injection model, according to the FC header matching rules, the original fields are replaced with new FC header fields to simulate FC header fault injection. Based on the packet loss model, packets are randomly selected and discarded to simulate packet loss in actual transmission. Based on the Cyclic Redundancy Check (CRC) error injection model, erroneous CRC codes are injected to simulate the CRC error phenomenon in actual transmission.

7. The method as described in claim 1, characterized in that, The node model includes a clock-synchronized FC node model, and the step of transmitting messages between the FC node model and the FC switch model includes: PTP protocol messages are transmitted between the clock-synchronized FC node model and the FC switch model. The clock-synchronized FC node model includes a master node model and a slave node model. The step of transmitting PTP protocol messages between the clock synchronization FC node model and the FC switch model includes: The master node model broadcasts PTP synchronization clock messages to the slave node model at synchronization time intervals. After receiving the PTP synchronization clock message, the slave node model sends a PTP clock request message to the master node model. After receiving the PTP clock request message, the master node sends a PTP clock request response message to the slave node. After receiving the PTP clock request response message, the slave node calculates the time offset based on the PTP synchronization clock message and the PTP clock request response message, and corrects the time of the slave node model based on the time offset. The process returns to the step of broadcasting PTP synchronization clock messages to the slave node model at synchronization time intervals until the time of the master node model and the slave node model is synchronized.

8. An FC network simulation device based on a simulation platform, characterized in that, The FC network simulation device based on the simulation platform includes: The parameter configuration module is used to configure simulation parameters, which include structural configuration parameters and message configuration parameters. The node construction module is used to construct an FC node model based on the simulation parameters and generate FC messages. The FC node model includes a traffic model, an interface control model, a service model, and an FC processor model. A switch construction module is used to construct an FC switch model based on the simulation parameters. The FC switch model includes a switch port model, a message distribution model, and a switch processor model. The switch port model includes cascaded ports. The message transmission module is used to perform message transmission between the FC node model and the FC switch model; The node construction module is further configured to allocate node addresses to each FC node model according to the structure configuration parameters, and configure source address, destination address, load length, and priority for each message according to the message configuration parameters to obtain node configuration information; send the message configuration parameters to the traffic model to extract traffic parameters and generate traffic messages; send the traffic messages to the interface control model to obtain interface control messages; input the interface control messages to the service model to inject services into the load data of the interface control messages to generate processed messages; and send the processed messages to the FC processor model to perform FC protocol framing on the processed messages according to the node configuration information to generate FC packets. The message transmission module is further configured to send FC messages to the switch port model through the FC node model, and upload them to the message distribution model through the switch port model; based on the message distribution model, distribute the FC messages to the switch processor model or the cascade port according to the message field information; based on the switch processor model or the cascade port, cache the FC messages, and forward them to the corresponding target node model based on priority.

9. An electronic device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the FC network simulation method based on a simulation platform as described in any one of claims 1 to 7.

Images