A distributed communication system and method in a simulation system

Abstract

The present invention discloses a distributed communication system and method in a simulation system. The communication system includes a model side and a virtual device processor (VDPU) side, wherein the model side exchanges data with several VDPUs via a bus. The model side runs several model processes and client communication processes, and the model processes and client communication processes are mapped one-to-one. Each VDPU side runs several virtual controller services and server communication processes, and the number of server communication processes is the same as the number of virtual controller services, and the two are mapped one-to-one. The model side and the VDPU side run on different workstations. When the number of virtual controller services running on a workstation exceeds a set value, the system can be expanded by adding workstations with the same configuration. The present invention improves data communication efficiency, has good scalability, reduces network load, reduces the probability of errors, and improves system flexibility.

Description

Technical Field

[0001] The present invention belongs to the technical field of simulation systems, and in particular relates to a distributed communication system and method in a simulation system. Background Art

[0002] With the continuous improvement of the automation and intelligence level of distributed control systems, control logic and algorithms are becoming more and more complex. A newly designed configuration logic is not allowed to be directly downloaded into a real distributed control system without sufficient testing and verification. Especially after the system is put into operation, in order to ensure its safe and reliable operation, it is not recommended to perform frequent experimental operations on the actual distributed control system. At the same time, operation and maintenance personnel also need to learn and practice the complex workflow of distributed control systems, but it is unrealistic to train operation and maintenance personnel in a real distributed control system environment. Therefore, a simulation system for distributed control systems is very necessary, and data communication is equivalent to the context of the simulation system. The stability, reliability and real-time performance of data communication are very important. The shortcomings of the existing technology are as follows:

[0003] 1) The architecture design is fixed, inflexible, and has poor scalability;

[0004] 2) Communication efficiency is limited and cannot meet the application scenarios where HMI operation requires fast response;

[0005] 3) The data interaction interface design between the communication program and the model is not user-friendly, and different communication client programs need to be developed for models from different manufacturers;

[0006] 4) The configuration is not flexible and cannot be expanded. Summary of the Invention

[0007] To address the deficiencies in the prior art, the present invention provides a distributed communication system and method in a simulation system, which improves the efficiency of data communication, has good scalability, reduces network load, reduces the probability of errors, and improves system flexibility.

[0008] In order to achieve the above object, the technical solution adopted by the present invention is:

[0009] In a first aspect, a distributed communication system in a simulation system is provided, comprising: a model end and several VDPU ends, wherein the model end and the several VDPU ends exchange data through a bus; the model end runs several model processes and client communication processes, and the model processes and the client communication processes are mapped one-to-one; each of the VDPU ends runs several virtual controller services and server communication processes, and the number of server communication processes is the same as the number of virtual controller services, and is mapped one-to-one; the model end runs on a workstation, and each of the VDPU ends runs on a workstation; when the number of virtual controller services running on a workstation exceeds a set value, it is expanded by adding workstations with the same configuration.

[0010] Furthermore, the model side maintains a mapping table between client communication processes and virtual controller index numbers, and the VDPU side maintains a mapping table between server communication processes and virtual controller index numbers. In addition, the model side also maintains a mapping table between the virtual controller index number and the IP address of the workstation where the virtual controller is located, the server communication process port number, and the client communication process port number. The VDPU side also maintains a mapping table between the virtual controller index number and the IP address of the model side workstation, the client communication process port number, and the server communication process port number. Each virtual controller on the model side corresponds to a client communication process, that is, a client communication process is specifically responsible for providing data source services for a virtual controller. Each virtual controller on the VDPU side corresponds to a client communication process, that is, a server communication process is specifically responsible for providing data access services for a virtual controller. The client communication process and the server communication process are also one-to-one mapped. Each client communication process and each server communication process use an independent communication link for data transmission.

[0011] Furthermore, the model side is configured with a model process management configuration file manage.csv, a communication parameter configuration file client.ini, and a point table configuration file MMI.csv; the VDPU side is configured with a server process management configuration file manage.csv, a communication parameter configuration file server.ini, and a point table configuration file MMI.csv; each configuration file has a category of virtual controller name to identify different configuration information, and maps the information of the three configuration files for different purposes together.

[0012] Furthermore, the virtual controller name in the model process management configuration file is used to identify different model processes; the virtual controller name in the server process management configuration file is used to identify different server communication management processes; the virtual controller name in the communication parameter configuration file client.ini is used to identify the IP address of the workstation on the VDPU side where this virtual controller is located, the port number of the server communication process mapped to this virtual controller on the VDPU side, and the port number of the client communication process mapped to this virtual controller on the model side; the virtual controller name in the communication parameter configuration file server.ini is used to identify the IP address of the workstation on the model side, the port number occupied by the client communication process mapped to this virtual controller on the model side, and the port number occupied by the server communication process mapped to this virtual controller on the VDPU side; the virtual controller name in the point table configuration file MMI.csv is used to identify the label point category, the model side label point name, and the VDPU side label point name.

[0013] Furthermore, the client communication process interacts with the model process in the form of a third-party library and provides various interfaces for the model to call, including: initialization, registration information, obtaining label point index, reading model information, writing model information and issuing instructions.

[0014] Furthermore, tag point types include: analog input, analog output, digital input and digital output. Different types of tag points correspond to measurement points in different application scenarios. Real-time data of different types of tag points are stored in different data pools. During the data transmission process, data is written to or obtained from the mapped data pool according to the type of tag point. Data of different tag point types are transmitted and stored independently.

[0015] Furthermore, the operating condition instructions are distributed by the model management process to all server communication processes on the VDPU side, and then the server communication process transmits the operating condition instructions to the virtual controller service. After receiving the operating condition instructions, the virtual controller service operates the virtual controller according to the content of the instructions.

[0016] Furthermore, when the operating condition instruction is transmitted, auxiliary information conInf is also carried. When conInf is 0, it means controlling all virtual controller services. When conInf is the virtual controller index number, it controls a virtual controller mapped by a virtual controller index separately. The configuration information of the operating condition instruction is in the point table configuration file MMI.csv, including the virtual controller name, the label point corresponding to runStop, and the label point corresponding to scenario. The auxiliary information conInf is obtained through the virtual controller name mapping in the management configuration file manage.csv.

[0017] Furthermore, the VDPU also runs an SMS process, a TMS process, and an ACS process: the SMS process is used to register and address services. It maintains a database of registered services, groups, and security information in the background, and uses the information stored in this database to send requests sent by the client to the final destination; the TMS process is used to transmit data using TCP, UDP, or unicast or multicast methods according to different data volumes; the ACS process is used to maintain a security information list. When a client sends a request to the server, the server first checks whether it has the authority to respond to the request.

[0018] In a second aspect, a distributed communication method in a simulation system is provided, which is based on the distributed communication system in the simulation system described in the first aspect. The method includes: a server communication process periodically receives request information from the bus, verifies that the data is sent to itself, and then receives the data according to the distributed addressing design, which is used for processing by the virtual controller, and stores the processed data in the output cache, wherein the data received by the server communication process from the bus is the data that the client communication process obtains from the model and sends to the bus according to a preset refresh cycle; the server communication process periodically obtains data from the output cache and sends it to a custom soft bus, which is used for the client communication process to periodically read the target data from the bus and then write it into the input cache of the model. The model obtains different output data according to different preset algorithm modules, and stores the data in the output cache for reading by the client communication process.

[0019] Compared with the prior art, the present invention has the following beneficial effects:

[0020] (1) The data interaction between the model side and the VDPU side of the present invention adopts a distributed communication design, distributing the virtual controller service and server communication process on multiple workstations, making the best use of computer hardware resources, avoiding waiting due to resource constraints, reducing network load, improving data communication efficiency, and achieving good scalability;

[0021] (2) In the present invention, each client communication process and each server communication process use independent communication links for data transmission, which reduces the bus load, improves communication efficiency, and shortens the operation response time on the HMI;

[0022] (3) The present invention eliminates the need to modify the client program for different third-party models, thereby reducing the degree of coupling between the client communication program and the model program and improving the reusability of the simulation communication program.

[0023] (4) The present invention can control all controllers in a unified manner or control a certain virtual controller separately, thereby improving the flexibility of simulation debugging. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 This is a block diagram of the communication principle of a distributed communication system in a simulation system provided by an embodiment of the present invention;

[0025] Figure 2 This is a diagram of internal data communication on the model side in an embodiment of the present invention;

[0026] Figure 3 This is a schematic diagram of the interface data interaction process between the client communication process and the model process in an embodiment of the present invention;

[0027] Figure 4 This is a diagram of internal data communication on the VDPU side in an embodiment of the present invention;

[0028] Figure 5 This is a flow chart of internal transmission data of DPC in the embodiment of the present invention.

[0029] Figure 6 This is a diagram of the internal mapping relationship of the model side in an embodiment of the present invention;

[0030] Figure 7 This is a diagram of the internal mapping relationship of the VDPU end in an embodiment of the present invention. DETAILED DESCRIPTION

[0031] The present invention will be further described below in conjunction with the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solutions of the present invention and are not intended to limit the scope of protection of the present invention.

[0032] Example 1:

[0033] like Figure 1 As shown, a distributed communication system in a simulation system is physically composed of a model end and multiple VDPU ends, and logically composed of a model process module, a client communication process module, a server communication process module and a virtual controller service module (VDPUn).

[0034] The model end is composed of a workstation in actual operation, and the programs running inside it include model process and client communication process; the model process and client communication process can be one or more in actual work, and the model process and client communication process are mapped one to one.

[0035] The VDPU end can be composed of one or more workstations according to actual needs. Each workstation runs different virtual controller services and server communication processes. A virtual controller service represents the working status of a virtual controller and provides an interface for reading and writing data. In order to reasonably control the network and hardware resource load, the maximum number of virtual controller services running on a workstation is 10. When there are more than 10 virtual controllers, only one workstation with the same configuration environment needs to be added and the name of the virtual controller needs to be updated. This is simple, convenient, error-prone, and scalable. The number of server communication processes is the same as the number of virtual controller services, and they are mapped one to one.

[0036] The connection hub between the client communication process and the server communication process is the virtual controller index number, that is, the model side maintains a mapping table between the client communication process and the virtual controller index number, and the VDPU side maintains a mapping table between the server communication process and the virtual controller index number. In addition, the model side also maintains a mapping table between the virtual controller index number and the IP address of the workstation where the virtual controller is located, the server communication process port number, and the client communication process port number. The VDPU side also maintains a mapping table between the virtual controller index number and the IP address of the model side workstation, the client communication process port number, and the server communication process port number. Each virtual controller on the model side corresponds to a client communication process, that is, a client communication process is specifically responsible for providing data source services for a virtual controller. Each virtual controller on the VDPU side corresponds to a client communication process, that is, a server communication process is specifically responsible for providing data access services for a virtual controller. The client communication process and the server communication process are also one-to-one mapping relationships. Each client communication process and each server communication process use independent communication links for data transmission.

[0037] The communication method between the model side and the VDPU side is as follows.

[0038] Step 1: The client communication process obtains data from the model according to the preset refresh cycle and sends a request to the custom data bus.

[0039] Step 2: The server communication process periodically receives request information from the data bus, verifies that the data is sent to itself, and sends a subscription request to the plug-in data carrier DPC. The DPC addresses the data based on the tag identification code in the original request and sends the request to the target address based on the pre-registered information. The target address may be on the virtual controller of a local or remote server. The entire addressing process is transparent. The server communication process receives the data and writes it to the input buffer of the virtual controller.

[0040] Step 3: The service process in the virtual controller publishes the information. After receiving the subscription request, it sends the response data that meets certain conditions to the DPC at a fixed time. The DPC forwards the response information to the simServer process. After certain processing, the virtual controller stores the processed data in the output cache.

[0041] Step 4: The service process of the virtual controller obtains the corresponding data from the publishing service according to the tag identification code in the sending request information, and pushes it to the DPC according to the subscription conditions. The simServer process periodically obtains data from the output buffer of the DPC and sends it to the custom soft bus.

[0042] Step 5: The client communication process on the model side periodically reads the target data from the soft bus and then writes it into the model's input buffer.

[0043] Step 6: The model obtains different output data according to different preset algorithm modules and stores it in the output cache for the client communication process to read.

[0044] The client communication process on the model side and the server communication process on the VDPU side are responsible for data transmission and reception on both sides respectively. One client communication process maps to one server communication process. Therefore, the number of client communication processes on the model side is equal to the total number of server communication processes on all VDPU sides.

[0045] Due to the limited hardware resources such as processors, memory and network bandwidth, the present invention adopts a distributed communication method to distribute virtual controller services and server communication processes on multiple workstations, thereby maximizing the use of computer hardware resources, avoiding waiting due to resource limitations, reducing network load, improving data communication efficiency and achieving good scalability.

[0046] The detailed flow chart of data communication within the model end is as follows Figure 2 shown.

[0047] The internal data communication method of the model side is as follows.

[0048] Step 1: Start the model process management program modelManager.exe, load the configuration file manage.csv, and start and manage the corresponding model process according to the content in manage.csv.

[0049] The manage.csv file consists of three parts: the model process name, the data refresh cycle of the model end, and the name of the virtual controller. The unit of the data refresh cycle is milliseconds by default.

[0050] After the model process management program is started, a UI interface is displayed. The UI interface is divided into two parts: process status monitoring and working condition instruction control.

[0051] The process status display information includes model process name, process ID, running status, heartbeat and virtual controller name, and the process status monitoring information includes selecting all processes, deselecting all, starting processes, pausing processes and restarting processes.

[0052] The working condition instruction control part has two drop-down menus, a text box and a control button. The drop-down menus are used to select the virtual controller index number and runStop instruction information respectively, and the text box is used to edit the file name of the configuration to be saved. After the control button is enabled, the above configuration information is transmitted to the VDPU end to complete the issuance of the working condition instruction. The configuration is simple and the operation is simple, which improves the friendliness and ease of use of the software.

[0053] Through the model process management program UI interface, you can monitor whether the model process is running normally and which virtual controller it is mapped to. When a process is abnormal, you can observe it immediately and take corresponding measures in time.

[0054] Step 2: When starting the client communication process simClientLib, load the client communication parameter configuration file client.ini and the point table file MMI.csv.

[0055] The communication parameter configuration file client.ini consists of the virtual controller name, IP_REMOTE, PORT_REMOTE and PORT_LOCAL, where the virtual controller name is used to identify and distinguish the other three parameters to facilitate the positioning of the server communication process on the VDPU side that interacts with the client communication process data; IP_REMOTE represents the IP address of the workstation on the VDPU side where this virtual controller is located; PORT_REMOTE represents the port number of the server communication process on the VDPU side mapped to this virtual controller, and PORT_LOCAL represents the port number of the client communication process on the model side mapped to this virtual controller.

[0056] The content of the point table file MMI.csv includes the tag point type, model-side tag point name, VDPU-side tag point name, change threshold, description information and virtual controller name, among which the tag point type includes analog input, analog output, digital input and digital output. Different types of tag points correspond to measurement points in different application scenarios, and the simulation model algorithms are also different, so the data transmission requirements are also different. During the data communication process, the real-time data of different types of tag points are stored in different data pools. During the data transmission process, the data is written to the mapped data pool or obtained from the mapped data pool according to the type of the tag point. Data of different tag point types are transmitted and stored independently. At the same time, different transmission strategies are set for different types of tag points in the configuration file according to actual needs, thereby improving the flexibility of data communication.

[0057] Step 3: Start the model process, load various types of algorithm libraries, process the data in the input cache and store it in the output cache for the client communication process to read.

[0058] Step 4: The client communication process creates two threads, thread 1 and thread 2. Thread 1 reads data from the output cache of the model process according to the preset refresh cycle and sends the data to the data pool DPA of the soft bus.

[0059] The data pool DPA is divided into different sub-data pools DPA_type1, DPA_type2, DPA_type3, etc. according to different tag point types. The data with tag point type type1 read from the output cache of the model process is written into the sub-data pool DPA_type1, the data with tag point type type2 is written into the sub-data pool DPA_type2, and so on.

[0060] Data of different tag point types are transmitted and stored independently. At the same time, different transmission strategies are set for different types of tag points in the configuration file according to actual needs, which improves the flexibility of data communication.

[0061] Step 5: Thread 2 of the client communication process periodically reads data from the data pool DPB of the soft bus and writes the data into the input buffer of the model process.

[0062] The data pool DPB is divided into different sub-data pools DPB_type1, DPB_type2, DPB_type3, etc. according to different label point types. Data with label point type type1 is obtained from the sub-data pool DPB_type1 and written into the output cache of the model process. Data with label point type type2 is obtained from the sub-data pool DPB_type2 and written into the output cache of the model process, and so on.

[0063] In the present invention, the client communication process interacts with the model process in the form of a third-party interface library, and its flow chart is as follows: Figure 3 As shown in the figure. Typically, a third-party model manufacturer provides an interface, and the client communication process exchanges data with the model process through the model library. Because different simulation applications use different model manufacturers, the client communication process may communicate with many different third-party models. Each time a different model is changed, the client program needs to be redeveloped, increasing complexity. To improve the reusability of the simulation communication program, the client communication program has been redesigned to provide interfaces for model invocation, such as initialization, registration information, obtaining tag point indexes, reading model information, writing model information, and issuing instructions. This eliminates the need to change the client program for different third-party models, reducing the coupling between the client communication program and the model program and improving the reusability of the simulation communication program.

[0064] The method of data interaction between the client communication process and the model process is as follows.

[0065] Step 1: Perform initialization work. The model process provides the path information of the configuration file and pre-allocates a certain amount of memory space.

[0066] Step 2: Register the entry address of the analog quantity and data quantity information in the read and write model into the system for easy access later.

[0067] Step 3: Call the Get Tag Point Index Number interface to obtain the index number from the tag point mapping table using the tag point name, thereby improving the efficiency of accessing model data.

[0068] Step 4: Call the send command information interface to send the necessary working condition instructions.

[0069] The model management process distributes operating instructions to all server communication processes on the VDPU side. The server communication process then transmits the operating instructions to the virtual control service. Upon receiving the operating instructions, the virtual control service operates the virtual controller according to the instructions. The operating instructions include runStop, scenario, and auxiliary information conInf. runStop can be 1, 2, 3, or 4, where 1 indicates start, 2 indicates stop, 3 indicates download, and 4 indicates save. scenario only takes effect when runStop is 4 and defines the file name of the configuration to be saved. When conInf is 0, it controls all virtual controller services. When conInf is the virtual controller index number, it controls a virtual controller mapped to a virtual controller index. This allows for both unified control of all controllers and individual control of specific virtual controllers, improving the flexibility of simulation debugging. The configuration information for the operating instructions runStop and scenario is stored in the point table configuration file MMI.csv, including the virtual controller name, the label point corresponding to runStop, and the label point corresponding to scenario. The auxiliary information conInf is obtained by mapping the virtual controller names in the management configuration file manage.csv. The model management process UI is designed with two drop-down menus, a text box, and a control button to complete the setting and issuance of working condition instructions. The drop-down menu is used to select the virtual controller index number and runStop instruction information, respectively, and the text box is used to edit the file name of the configuration to be saved. After the control button is enabled, the above configuration information is transmitted to the VDPU end.

[0070] Step 5: Use the data read interface to read data information from the model.

[0071] Step 6: Use the write data interface to write data into the model.

[0072] The detailed flow chart of internal data communication on the VDPU side is as follows: Figure 4 shown.

[0073] The internal data communication method on the VDPU side is as follows.

[0074] Step 1: Start the server communication management process processManager.exe, load the manage.csv configuration file, and start the server communication management process according to the content of the manage.csv file.

[0075] The content of the manage.csv configuration file consists of three parts: the server communication process name, the data refresh cycle of the VDPU end, and the virtual controller name. The default unit of the data refresh cycle is milliseconds.

[0076] After the server communication management process is started, a UI interface appears. Its layout is divided into two main parts: a list and a button container. The list has five columns: the server communication process name, process ID, running status, heartbeat, and virtual controller name. The button container has options for selecting all processes, deselecting all, starting a process, pausing a process, and restarting a process.

[0077] Step 2: When the server communication process simServer.exe starts, it loads the communication parameter configuration file server.ini and the point table file MMI.csv.

[0078] The communication parameter configuration file server.ini includes the virtual controller name, IP_REMOTE, PORT_REMOTE and PORT_LOCAL, wherein the virtual controller name is used to identify the server communication process corresponding to the other three parameters. Because the virtual controller and the server communication process are mapped one to one, the server communication process mapped by the virtual controller VDPU1 will automatically load the IP_REMOTE, PORT_REMOTE and PORT_LOCAL parameters corresponding to VDPU1 in the server.ini file when it starts, so as to carry out correct data interaction with the client communication process mapped by the model end VDPU1; IP_REMOTE represents the IP address of the workstation where the model end is located, PORT_REMOTE represents the port number occupied by the client communication process mapped by the model end and this virtual controller during operation, and PORT_LOCAL represents the port number occupied by the server communication process mapped by the VDPU end and this virtual controller during operation.

[0079] The content of the point table file MMI.csv is the same as that of the MMI.csv on the model side, and must be completely consistent, otherwise communication abnormalities will occur. The content of MMI.csv includes the tag point type, model side tag point name, VDPU side tag point name, change threshold, description information and virtual controller name. Similarly, the tag point type includes analog input, analog output, digital input and digital output. During the data communication process, the real-time data of different types of tag points are stored in different data pools on the VDPU side, which facilitates the adoption of different transmission strategies according to actual needs to improve the flexibility of data communication.

[0080] Step 3: Start the virtual controller service, and the background service process will publish the pre-registered data.

[0081] Step 4: The server communication process creates two threads, thread 1 and thread 2. Thread 1 periodically receives request information from the data bus, verifies that the data is sent to itself, and then receives and sends a subscription request to the plug-in data carrier DPC. The DPC addresses the data based on the tag identification code in the original request and sends the request to the target address based on the pre-registered information. The target address may be on the virtual controller of a local or remote server. The entire addressing process is transparent.

[0082] Step 5: The service process of the virtual controller obtains the corresponding data from the publishing service according to the tag identification code in the sending request information, and pushes it to the DPC according to the subscription conditions. Thread 2 of the server communication process reads the data from the output buffer of the DPC and sends it to the data pool DPB of the soft bus.

[0083] The DPC module includes the SMS (Sign up Manage Service) submodule, the TMS (Transport Manage Service) submodule, and the ACS (Access Control Service) submodule. The SMS submodule is responsible for registration and addressing services, maintaining a database of registered services, groups, and security information in the background. It uses the information stored in this database to send client requests to their final destination. The SMS service only generates inter-process addressing, or level 0 addressing; higher-level addressing uses an algorithm that obtains service lists from multiple lower-level addressing databases rather than directly registering them. The TMS submodule is a program that provides the function of transferring data structures between different storage spaces, using unicast or multicast for data transmission depending on the amount of data. The ACS submodule is responsible for access control permissions and authentication services, maintaining a list of security information. When a client sends a request to the server, the server first checks whether it has the authority to respond to the request.

[0084] The internal transmission data flow diagram of DPC is as follows Figure 5 The transmission method is as follows:

[0085] Step 1: When the client starts, it creates a new connection and sends the connection information to the SMS module for registration. After the SMS module receives the client's connection information, it saves it to the local database.

[0086] Step 2: When the above client starts, it will send a unicast request service ID to all servers and other clients, and then register all remote and local service IDs in the local SMS. The service IDs include those from the local, other stations and virtual controllers. The registration information includes the service ID and the address of the station where it is located.

[0087] Step 3: The above connection information includes the address of the station where the connection process is created, the connection number, the connection quality and the connection flag; the address of the station where the connection process is created is used to identify the station where this connection is located, because the connection numbers of different stations all start from 0; the connection number is the unique identifier of the connection within the station; the connection quality indicates the priority of the process when multiple identical processes are started at the same time; the connection flag indicates the connection status, whether it is communicable or disconnected.

[0088] Step 4: The client sends an initial request to the SMS module in subscription mode based on the newly created connection.

[0089] Step 5: The above subscription method initializes subscription information when sending a request. The subscription information includes the minimum request time, the maximum request time and the minimum change value.

[0090] Step 6: When TMS starts, it creates a connection and sends the connection information to the SMS module for registration. After the SMS module receives the client's connection information, it saves it to the local database.

[0091] Step 7: The above connection information includes the address of the station where the connection process is created, the connection number, the connection quality and the connection flag.

[0092] Step 8: After receiving the initial request message from Clinet, the SMS searches the local database for the destination and connection information based on the service ID in the request message. It then forwards the request to the local TMS. The TMS then sends the message to the address of the target data based on the addressing information provided by the SMS. The entire addressing process is transparent.

[0093] Step 9: If the target data is local, the TMS directly sends the response data to the Client; if the target data is remote, the TMS sends the addressing information to the Ethernet.

[0094] Step 10: The above addressing information is sent to the target server. The TMS of the target server first receives the request information and sends it to the local SMS. The SMS searches the local database for the target data according to the service ID in the request information.

[0095] Step 11: When the TMS is started, it creates a new connection and sends the connection information to the SMS module for registration. After receiving the connection information from the Client, the SMS module saves it to the local database.

[0096] Step 12: After receiving the request, the SMS obtains the username and password of the client's initial requester from the local TMS. The local TMS then sends the request to the remote client's TMS. The client's TMS forwards the request to the SMS on the same end. The SMS retrieves the requester's username and password from the local database and sends them to the server according to the request path.

[0097] Step 13: After receiving the username and password, the SMS server sends them to the ACS for authentication and then sends the authentication result back to the SMS server.

[0098] Step 14: SMS adds the requester's authentication information to the initial request to form a request with security authentication and sends it to the server.

[0099] Step 15: The above server creates a connection when it starts and sends the connection information to the SMS module for registration. After the SMS module receives the connection information of the client, it saves it to the local database.

[0100] Step 16: When the server is started, it sends the service ID to all clients in a multicast manner. After the client receives it, it registers it in the SMS on the client side.

[0101] Step 17: When the server is started, it registers the local service ID in the local SMS. The registration information includes the service ID and the address of the local site.

[0102] Step 18: After the above server creates a connection and registers the service ID information, it publishes the data of all service IDs.

[0103] Step 19: After the server receives the request with security authentication, if the authentication is successful, it queries the target data corresponding to the requested service ID from the published data information and forwards it directly to the local TMS. The local TMS sends the response data to the TMS on the client side, and the TMS on the client side forwards the response data to the client process.

[0104] Step 20: The above Client and Server are both logical roles. The Client and Server may run simultaneously in the same physical site according to actual needs.

[0105] There are three types of configuration files in the present invention: management configuration file, communication parameter configuration file and point table configuration file.

[0106] The management configuration files are divided into the model process management configuration file manage.csv and the server communication process management configuration file manage.csv.

[0107] The communication parameter configuration files are divided into client.ini and server.ini, and the point table configuration file MMI.csv is consistent on the model side and the VDPU side. The configuration information of the working condition instructions runStop and scenario is stored in the point table configuration file MMI.csv, including the virtual controller name, the label point corresponding to runStop, and the label point corresponding to scenario. The auxiliary information conInf is obtained by mapping the virtual controller name in the management configuration file manage.csv.

[0108] Each configuration file contains a category called the virtual controller name, which is used to identify different configuration information.

[0109] In the model process management configuration file, the virtual controller name is used to identify different model processes; in the server communication process management configuration file, the virtual controller name is used to identify different server communication management processes; in the client.ini file, the virtual controller name is used to identify the IP address of the workstation on the VDPU side where the virtual controller is located, the port number of the server communication process mapped to the virtual controller on the VDPU side, and the port number of the client communication process mapped to the virtual controller on the model side, such as Figure 6 As shown in .

[0110] The virtual controller name in the server.ini file is used to identify the IP address of the workstation where the model side is located, the port number occupied by the client communication process mapped to the model side and the server communication process mapped to the VDPU side, such as Figure 7 As shown in .

[0111] The virtual controller name in the point table configuration file MMI.csv is used to identify the tag point category, model-side tag point name, and VDPU-side tag point name; each configuration file maintains a mapping table in the system.

[0112] The management configuration file manage.csv on the model side corresponds to the model management process modelManager.exe, and the communication parameter configuration file client.ini and the point table configuration file correspond to all client communication processes. Each workstation on the VDPU side is allocated the server communication process management configuration file manage.csv, the communication parameter configuration file server.ini, and the point table configuration file MMI.csv. The virtual controller names in the configuration files on different workstations vary according to actual conditions. By adding a category virtual controller name to each configuration file, the information of three seemingly unrelated configuration files with different purposes is closely mapped together. The configuration content is clearly organized and less prone to errors. While improving the degree of automation, it also improves the efficiency of information positioning and data transmission.

[0113] The internal mapping relationship of the model side is as follows Figure 6 As shown in the figure, the connection between the client communication process and the server communication process is the virtual controller index number. Specifically, the model maintains a mapping table between the client communication process and the virtual controller index number, and the VDPU maintains a mapping table between the server communication process and the virtual controller index number. Furthermore, the model also maintains a mapping table between the virtual controller index number and the IP address of the workstation where the virtual controller resides, the server communication process port number, and the client communication process port number. Each virtual controller on the model corresponds to a client communication process, meaning that a client communication process is specifically responsible for providing data source services for that virtual controller.

[0114] The internal mapping relationship of the VDPU end is as follows Figure 7 As shown, the VDPU maintains a mapping table between virtual controller index numbers, the model workstation's IP address, the client communication process port number, and the server communication process port number. Each virtual controller on the VDPU corresponds to a client communication process, meaning a server communication process provides data access services specifically for that virtual controller. There is also a one-to-one mapping between client and server communication processes. Each client and server communication process uses an independent communication link for data transmission, reducing the load on the soft bus, improving communication efficiency, and shortening HMI operation response time.

[0115] Example 2:

[0116] Based on the distributed communication system in a simulation system described in Example 1, this embodiment provides a distributed communication method in a simulation system, including: a server communication process periodically receives request information from a bus, verifies that the data is sent to itself, and then receives the data according to a distributed addressing design, for processing by a virtual controller, and stores the processed data in an output cache, wherein the data received by the server communication process from the bus is data that the client communication process periodically obtains from the model and sends to the bus according to a preset refresh cycle; the server communication process periodically obtains data from the output cache and sends it to a custom soft bus, which is used by the client communication process to periodically read target data from the bus and then write it into the input cache of the model, and the model obtains different output data according to different preset algorithm modules, and stores the data in the output cache for reading by the client communication process.

[0117] The embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code. The scheme in the embodiments of the present application can be implemented in various computer languages, for example, object-oriented programming language Java and directly interpreted scripting language JavaScript, etc.

[0118] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0119] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0120] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 The steps for the function specified in one or more boxes.

[0121] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present application.

[0122] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A distributed communication system in a simulation system, characterized in that: include: A model terminal and several VDPU terminals, wherein the model terminal and the VDPU terminals exchange data via a bus; The model side runs several model processes and client communication processes, and the model processes and client communication processes are mapped one to one; Each of the VDPUs runs a number of virtual controller services and server communication processes, where the number of server communication processes is the same as the number of virtual controller services, and the number of processes is mapped one to one. The model side runs on a workstation, and each VDPU side runs on a workstation; when the number of virtual controller services running on a workstation exceeds a set value, expansion is performed by adding workstations with the same configuration; The model side maintains a mapping table between a client communication process and a virtual controller index number, and the VDPU side maintains a mapping table between a server communication process and a virtual controller index number. In addition, the model side also maintains a mapping table between a virtual controller index number and the IP address of the workstation where the virtual controller is located, the server communication process port number, and the client communication process port number. The VDPU side also maintains a mapping table between a virtual controller index number and the IP address of the model side workstation, the client communication process port number, and the server communication process port number. Each virtual controller on the model side corresponds to a client communication process, that is, a client communication process is specifically responsible for providing data source services for a virtual controller. Each virtual controller on the VDPU side corresponds to a client communication process, that is, a server communication process is specifically responsible for providing data access services for a virtual controller. The client communication process and the server communication process are also one-to-one mapped. Each client communication process and each server communication process use an independent communication link for data transmission.

2. The distributed communication system in the simulation system according to claim 1, characterized in that: The model side is configured with a model process management configuration file manage.csv, a communication parameter configuration file client.ini and a point table configuration file MMI.csv; The VDPU is configured with a server process management configuration file manage.csv, a communication parameter configuration file server.ini, and a point table configuration file MMI.csv; Each configuration file has a category called the virtual controller name, which is used to identify different configuration information and map the information of the three configuration files with different purposes together.

3. The distributed communication system in the simulation system according to claim 2, characterized in that: The virtual controller name in the model process management configuration file is used to identify different model processes; The virtual controller name in the server process management configuration file is used to identify different server communication management processes; The virtual controller name in the communication parameter configuration file client.ini is used to identify the IP address of the workstation on the VDPU side where the virtual controller is located, the port number of the server communication process mapped to the virtual controller on the VDPU side, and the port number of the client communication process mapped to the virtual controller on the model side. The virtual controller name in the communication parameter configuration file server.ini is used to identify the IP address of the workstation where the model side is located, the port number occupied by the client communication process mapped to the model side and the server communication process mapped to the virtual controller; The virtual controller name in the point table configuration file MMI.csv is used to identify the tag point category, model-side tag point name, and VDPU-side tag point name.

4. The distributed communication system in the simulation system according to claim 1, characterized in that: The client communication process interacts with the model process in the form of a third-party library and provides various interfaces for the model to call, including: initialization, registration information, obtaining label point index, reading model information, writing model information and issuing instructions.

5. The distributed communication system in the simulation system according to claim 4, characterized in that: Tag point types include: analog input, analog output, digital input, and digital output. Different types of tag points correspond to measurement points in different application scenarios. Real-time data of different types of tag points are stored in different data pools. During the data transmission process, data is written to or obtained from the mapped data pool according to the type of tag point. Data of different tag point types are transmitted and stored independently.

6. The distributed communication system in the simulation system according to claim 1, characterized in that: The operating condition instructions are distributed by the model management process to all server communication processes on the VDPU side, and then the server communication process transmits the operating condition instructions to the virtual controller service. After receiving the operating condition instructions, the virtual controller service operates the virtual controller according to the content of the instructions.

7. The distributed communication system in the simulation system according to claim 6, characterized in that: When transmitting the working condition instruction, auxiliary information conInf is also carried. When conInf is 0, it means controlling all virtual controller services. When conInf is the virtual controller index number, it controls the virtual controller mapped by a virtual controller index separately. The configuration information of the working condition instruction is in the point table configuration file MMI.csv, including the virtual controller name, the label point corresponding to runStop, and the label point corresponding to scenario. The auxiliary information conInf is obtained through the virtual controller name mapping in the management configuration file manage.csv.

8. The distributed communication system in the simulation system according to claim 1, characterized in that: The VDPU also runs the SMS process, TMS process, and ACS process: SMS process, used for registration and addressing services, maintains a database of registered services, groups and security information in the background, and sends the request sent by the client to the final destination with the help of the information stored in this database; The TMS process is used to transmit data using TCP, UDP, unicast, or multicast according to the amount of data. The ACS process is used to maintain a security information list. When a client sends a request to a server, the server first checks whether it has permission to respond to the request.

9. A distributed communication method in a simulation system, characterized in that: Based on the distributed communication system in the simulation system according to any one of claims 1 to 8, the method comprises: The server communication process periodically receives request information from the bus, verifies that it is data sent to itself, and then receives the data according to the distributed addressing design for processing by the virtual controller and stores the processed data in the output buffer. The data received by the server communication process from the bus is the data obtained from the model and sent to the bus by the client communication process according to the preset refresh cycle. The server communication process periodically obtains data from the output cache and sends it to the custom soft bus. The client communication process periodically reads the target data from the bus and then writes it into the model's input cache. The model obtains different output data based on different preset algorithm modules, stores it in the output cache, and makes it available for reading by the client communication process.

Images