Interface system for information physical interaction of digital-real fusion test system and digital-real fusion test system

Abstract

The invention belongs to the technical field of data-real fusion testing, and particularly relates to an interface system for information physical interaction of a data-real fusion testing system and the data-real fusion testing system. The interface system comprises a physical model interface; the physical model interface is used for converting the communication physical interface of each sub-entity included in the physical entity into a unified communication driving interface, so that the physical entity, serving as a tested object, of the digital-real fusion test system is in data interaction with the digital model through the communication driving interface. According to the invention, the communication physical interface of each sub-entity is converted into a unified communication driving interface, and communication driving of different types of physical entity interfaces is completed through one communication driving interface, so that driving interfaces do not need to be separately configured for different physical entity interfaces. According to the method and the device, the technical problem of low universality and expansibility of a data-real fusion test system due to non-uniform interfaces among different entity equipment in the prior art is solved.

Description

Technical Field

[0001] The present invention belongs to the technical field of digital-physical integration testing, and particularly relates to an interface system for cyber-physical interaction in a digital-physical integration testing system and a digital-physical integration testing system. Background Art

[0002] In order to verify the product performance, it is generally necessary to test and verify the product during the product design or inspection phase. Traditional testing methods rely on documents to inspect the test objectives, where both the test objectives and the test environment are kept in a real state, so the obtained test results are also authentic. However, some Cyber-Physical Systems (CPS) are too large in scale or too high in physical hardware cost to be tested by traditional testing methods. Virtual simulation testing helps save costs and time while providing a more flexible test environment. However, the real environment of CPS testing is difficult to fully simulate and has limited credibility. Therefore, the simulation testing of virtual-real integration, that is, Live-Virtual-Construction (LVC) testing, is proposed, which not only retains the characteristic of reliable data in traditional testing but also can save testing costs and time through virtual simulation testing, improve testing efficiency, flexibility, and coverage, and at the same time can improve system performance according to the evaluation results.

[0003] The digital-physical integration interfaces in the prior art often design specific interfaces for specific entity equipment. There is a lack of a unified standard interface between different equipment, lacking sufficient generality and scalability, and the accuracy of data and the fluency of interaction cannot be guaranteed. This design usually cannot effectively adapt to the introduction of new entity equipment, is not conducive to interaction, and will face compatibility problems. In addition, due to the differences in data acquisition accuracy, frequency, and format between the digital part and the physical part, the interaction efficiency is low when saving and converting the existing interface data, and at the same time, the maintenance cost is high, the expandability is poor, and errors are prone to occur. These problems may affect the accuracy of the test results, especially in application scenarios that require high precision and high reliability. Summary of the Invention

[0004] The purpose of the present invention is to provide an interface system for cyber-physical interaction in a digital-physical integration testing system and a digital-physical integration testing system to solve the technical problem that the interfaces between different entity equipment in the prior art are not unified, resulting in low generality and expandability of the digital-physical integration testing system.

[0005] To solve the above technical problems, the technical solution of an interface system for cyber-physical interaction in a digital-physical fusion test system provided by the present invention is as follows: An interface system for cyber-physical interaction in a digital-physical fusion test system, the interface system includes a physical model interface; the physical model interface is used to convert the communication physical interfaces of each sub-entity included in the physical entity into a unified communication driver interface, so that the physical entity as the object under test in the digital-physical fusion test system can perform data interaction with the digital model through the communication driver interface.

[0006] The beneficial effects of the above technical solution are as follows: The technical solution of an interface system for cyber-physical interaction in a digital-physical fusion test system of the present invention belongs to an improved invention. The present invention converts the communication physical interfaces of each sub-entity into a unified communication driver interface, and completes the communication drive of the interfaces of different types of physical entities through a single communication driver interface, without separately configuring a driver interface for different physical entity interfaces, greatly enhancing the versatility and expandability of the digital-physical fusion test system. The present invention solves the technical problem in the prior art that the interfaces between different entity devices are not unified, resulting in low versatility and expandability of the digital-physical fusion test system.

[0007] Further, the interface system further includes a digital model interface; data interaction is carried out between each sub-model included in the digital model through the digital model interface, and each sub-model performs data interaction with the physical entity through the same digital model interface.

[0008] Further, the communication driver interface includes a first interface, a second interface, a third interface, a fourth interface, and a fifth interface that are sequentially called in the digital-physical fusion test;

[0009] The first interface is used to instantiate a physical model; the second interface is used to set parameters and callback functions for the physical model; the third interface is used to initialize the physical model; the fourth interface is used to control the physical model during the simulation process to complete the digital-physical fusion test; the fifth interface is used to end the call of the communication driver interface.

[0010] Further, the parameters set by the second interface for the physical model include an ID, thread parameters during simulation, and channels for reading and writing data;

[0011] And / or the callback functions set by the second interface for the physical model include a read callback function and a log callback function.

[0012] Further, the fourth interface includes a start interface for starting the simulation, a read interface for reading data from the channel corresponding to the physical model, a write interface for writing data to the channel corresponding to the physical model, and a stop interface for stopping the simulation.

[0013] Further, the fifth interface includes an anti-initialization interface for anti-initializing the physical model and a destruction interface for destroying the physical model, which are called in sequence.

[0014] Further, the digital model interface is established based on fmilib.

[0015] Further, each sub-model is represented by a class in the simulation; the digital model interface includes a callback function for observing the simulation process of the sub-model corresponding to the digital model interface, a simulation control for controlling the sub-model corresponding to the digital model interface during the simulation process to complete the digital-physical fusion test, and class operations of the sub-model corresponding to the digital model interface.

[0016] Further, the basic attributes of the digital model interface include the file directory path of the sub-model corresponding to the digital model interface, the name of the sub-model corresponding to the digital model interface, and the complete path of the sub-model file corresponding to the digital model interface after download.

[0017] Further, the digital model interface is established based on fmilib; the callback function includes callback functions required for applying memory for the sub-model, printing logs, or releasing memory, the handle returned after the sub-model is loaded into fmilib, and the memory information returned after the sub-model is loaded into fmilib.

[0018] Further, the interface system further includes a protocol model interface located between the digital model interface and the physical model interface. The protocol model interface is used to packetize the data output by the digital model and send it to the physical model, and to depacketize the data output by the physical model and send it to the digital model.

[0019] Further, the protocol model interface includes a constructor for instantiating an object, a destructor for reclaiming the object's memory, a name acquisition interface for obtaining the protocol model name, a port ID acquisition interface for obtaining the ID of a specified port name, an attribute value acquisition interface for obtaining the value of a specified type of a specified ID port, an attribute value setting interface for setting the value type of a specified ID port, a processing interface for data packetization and depacketization, a list acquisition interface for obtaining the protocol model parameter list, and a protocol model ID acquisition interface for obtaining the protocol model ID.

[0020] Further, the interface system further includes a data exchange interface. In the digital-physical fusion test system, data is transmitted between each subsystem and the object under test through the data interaction interface;

[0021] In the digital-physical fusion test, by defining a class to store the data sent by the data sender in the form of different data types, and allowing the data receiver to read any type of data in the class through the data exchange interface.

[0022] Further, the data exchange interface includes a string length interface for storing the length of string-type data, a data type interface for storing data types, an encoding type interface for storing the encoding type of data, a numerical storage interface for storing numerical values, a string storage interface for storing string data, a constructor for instantiating data objects according to input values and value types, a destructor for releasing memory, an operator interface for overriding operators, and a data reading interface for reading data of a specified data type.

[0023] Further, the interface system further includes a communication interface and a driver interface for at least one of a 1553B bus, a CAN bus, and a serial bus; the 1553B bus is used to implement communication between physical entities in the object under test and each subsystem of the digital-physical fusion test system; the CAN bus is used to implement communication between each sub-entity of the physical entity; the serial bus is used to implement the transmission of sensor acquisition signals or simple control instructions.

[0024] The present invention also provides a technical solution for a digital-physical fusion test system: a digital-physical fusion test system includes an interface system for cyber-physical interaction, and the interface system includes a physical model interface; the physical model interface is used to convert the communication physical interfaces of each sub-entity included in the physical entity into a unified communication driver interface, so that the physical entity as the object under test of the digital-physical fusion test system can perform data interaction with the digital model through the communication driver interface.

[0025] The beneficial effects of the above technical solution are: The technical solution of a digital-physical fusion test system of the present invention belongs to an improved invention creation. The present invention converts the communication physical interfaces of each sub-entity into a unified communication driver interface, and completes the communication drive of the interfaces of different types of physical entities through a single communication driver interface, without separately configuring driver interfaces for different physical entity interfaces, greatly enhancing the versatility and scalability of the digital-physical fusion test system. The present invention solves the technical problem in the prior art that the interfaces between different entity devices are not unified, resulting in low versatility and scalability of the digital-physical fusion test system.

[0026] Further, the digital model includes sub-models, and the interface system further includes a digital model interface; data interaction between each sub-model included in the digital model is performed through the digital model interface, and each sub-model performs data interaction with the physical entity through the same digital model interface.

[0027] Further, the interface system further includes a protocol model interface located between the digital model interface and the physical model interface. The protocol model interface is used to packetize the data output by the digital model and send it to the physical model, and to depacketize the data output by the physical model and send it to the digital model.

[0028] Further, the interface system further includes a data exchange interface, and data is transmitted between each subsystem and the object under test in the digital-physical fusion test system through the data interaction interface;

[0029] In the digital-physical fusion test, a class is defined to store the data sent by the data sender in the form of different data types, and the data receiver is allowed to read any type of data in the class through the data exchange interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 Schematic diagram of the digital model interface in the digital-physical fusion test system embodiment of the present invention;

[0031] Figure 2 Schematic diagram of the protocol model interface in the digital-physical fusion test system embodiment of the present invention;

[0032] Figure 3 Schematic diagram of the physical model interface in the digital-physical fusion test system embodiment of the present invention;

[0033] Figure 4 Schematic diagram of the call sequence of the physical model interface in the digital-physical fusion test system embodiment of the present invention;

[0034] Figure 5 Schematic diagram of the data interaction interface in the digital-physical fusion test system embodiment of the present invention;

[0035] Figure 6 Schematic diagram of the digital-physical fusion test system architecture in the digital-physical fusion test system embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0036] The present invention converts the communication physical interfaces of each sub-entity into a unified communication driver interface, and completes the communication drive of the physical entity interfaces of different types through a communication driver interface, without separately configuring a driver interface for each different physical entity interface, greatly enhancing the versatility and scalability of the digital-physical fusion test system. The present invention solves the technical problem in the prior art that the interfaces between different entity equipments are not unified, resulting in low versatility and scalability of the digital-physical fusion test system.

[0037] Embodiment of the digital-physical fusion test system:

[0038] The digital-physical fusion test system is as Figure 6As shown in the figure, the test design scenario server writes test scripts according to test requirements. The digital-physical fusion automated test engine obtains the test scripts from the test design scenario server, and then parses and executes the test scripts. The multidisciplinary joint simulation server receives the instructions from the automated test engine and performs simulation using different types of digital models. The simulation results are transmitted to the sensor simulation server to simulate the sensor data of unmanned equipment, providing multi-source information input for the test scenario. Then, the hardware-in-the-loop or unmanned equipment is operated and controlled to further provide feedback to the digital simulation model. The simulation subscription server is used to receive and obtain simulation test data and configuration information in real time, realizing data synchronization and real-time information distribution during the simulation process. The evaluation server processes and evaluates the data results generated during the simulation and physical test, generating the performance indicators and analysis results of the equipment.

[0039] In the digital-physical fusion test system, the object under test consists of a digital model and a physical entity. The digital model is stored in the multidisciplinary joint simulation server and includes multiple different types of sub-models. The physical entity includes multiple different sub-entities.

[0040] The digital-physical fusion test system also includes a cyber-physical interaction system, which includes a digital model interface and a physical model interface. Data interaction between the sub-models of the digital model is carried out through the digital model interface, and each sub-model conducts data interaction with the physical entity through the same digital model interface. The physical model interface converts the communication physical interfaces of each sub-entity into a unified communication driver interface to achieve data interaction between the physical entity and the digital model.

[0041] The cyber-physical interaction system also includes a data exchange interface and a protocol model interface located between the digital model interface and the physical model interface. The protocol model interface is used to packetize the data output by the digital model and send it to the physical model, and to depacketize the data output by the physical model and send it to the digital model. In the digital-physical fusion test system, data is transmitted between each subsystem and the object under test through the data interaction interface. The data exchange interface is used to store the data sent by the data sender in different data types and allows the data receiver to read any type of data.

[0042] (1) Digital model interface: In this embodiment, the FMI standard is adopted to define the digital model, and fmilib is used to operate the digital model. However, due to the numerous interfaces of fmilib and the lack of consideration for cyber-physical interaction, interfaces are further defined and encapsulated on the basis of fmilib. The digital model is abstracted as a class in the simulation terminal, and the interface definition method of the class is as Figure 1 shown.

[0043] Among them, the detailed interface definition includes the basic attributes of the sub-model, callback functions for observing the simulation process of the sub-model, simulation control for controlling the sub-model during the simulation process to complete the digital-physical fusion test, and class operations, which are specifically as follows:

[0044] Basic attributes:

[0045] Specify path_ as the file directory path of the sub-model;

[0046] Set name_ as the name of the sub-model;

[0047] Specify resource_locaton_ as the complete path of the sub-model file after downloading;

[0048] Callback functions:

[0049] Define callBackFunctions_ as the callback functions required for operations such as the model applying for memory, printing logs, and releasing memory;

[0050] Define fmu_xml_ as the handle returned after the model is loaded and parsed by fmilib;

[0051] Set context_ as the memory information returned after the model is loaded by fmilib;

[0052] Simulation control:

[0053] Define start_ as the simulation start time; define end_ as the simulation end time; define step_size as the simulation step size;

[0054] Define relativeTol_ as the accuracy set during the model simulation;

[0055] Class operations:

[0056] Define FmuCsV2 as the constructor of the class, which saves the set attribute values while instantiating the object; define ~FmuCsV2() as the destructor of the class, which releases the memory used by the model loaded by fmilib and releases the object itself;

[0057] Define the GetModelName interface to obtain the model name;

[0058] Define the GetInternalPortID interface to obtain the internal port ID of the port with the specified name;

[0059] Specify the GetValue interface to obtain the value from the port with the specified ID, and the interface saves the value in the specified abstract numerical object according to the specified data type; specify the SetValue interface to set the value of the data type to the port with the specified ID;

[0060] The Init1 interface calls the fmilib interface to load the model, including setting callback functions required for operations such as applying for memory, printing logs, and releasing memory, loading binary files, creating an instance of the model, setting the start time, simulation time, simulation step size, and simulation accuracy;

[0061] The Init2 interface calls the fmilib interface to complete the initialization of the model instance;

[0062] The DoStep interface performs model solution based on the current simulation time.

[0063] (2) Physical model interface: Physical entities are abstracted as physical models during the simulation process. The interaction between the digital model and the physical model corresponds to the data interaction between the digital model and the physical entities; Different communication physical interfaces and communication protocols are configured to avoid individual adaptation for each physical entity, so as to reduce the development workload and complexity; Every time a new physical entity is added or an existing entity changes, re - adaptation is required, which is obviously unrealistic and will significantly reduce the flexibility and scalability of the system.

[0064] To solve this problem, the present invention constructs an abstract adaptation layer, which is located between the digital model and the physical model as middleware and is responsible for information conversion and transmission; It converts various different communication physical interfaces and communication protocols into a unified communication driver interface; Ensure that regardless of the communication interface and protocol of the physical entity, the digital model can communicate through the unified driver interface.

[0065] The communication driver interface includes a first interface, a second interface, a third interface, a fourth interface, and a fifth interface called in sequence; The first interface is used to instantiate a physical model; The second interface is used to set parameters for the physical model; The third interface is used to initialize the physical model; The fourth interface is used to control the physical model during the simulation process to complete the digital - physical fusion test; The fifth interface is used to end the call of the communication driver interface.

[0066] The second interface sets parameters for the physical model including ID, thread parameters during simulation, read callback function, log callback function, and channel settings. The fourth interface includes a start interface for starting the simulation, a read interface for reading data from the channel corresponding to the hardware model, a write interface for writing data to the channel corresponding to the hardware model, and a stop interface for stopping the simulation. The fifth interface includes an anti - initialization interface for anti - initializing the physical model and a destruction interface for destroying the physical model called in sequence.

[0067] The physical model is also abstracted as a class in the simulation terminal, and the interface design method of the class is as Figure 3 shown. The detailed interface design is as follows:

[0068] Specify the SimuHWCreateBoard interface (i.e., the first interface) to instantiate a physical model and return a handle; specify the SimuHWDestroyBoard interface to destroy the physical model and release the memory;

[0069] The SimuHWInit interface (i.e., the third interface) initializes the physical model according to the specified physical model handle, configuration file, and driver library;

[0070] Define the SimuHWUnInit interface to de-initialize the corresponding physical model;

[0071] Define the SimuHWSetCardID interface to set an ID for the specified hardware model handle for identification; specify the SimuHWSetThreadAttr interface to set the thread parameters during simulation for the specified hardware model handle;

[0072] Specify the SimuHWRegisteReadCB interface to set a read callback function for the hardware model with the specified handle. During the simulation process, the data sent by the physical entity can be received by the callback function into the simulation system;

[0073] Specify the SimuHWSetLogCB interface to set a log callback function for the hardware model with the specified handle; define the SimuHWGetChannels interface to obtain the channel settings of the hardware model with the specified handle;

[0074] Define the SimuHWStart interface to start the simulation for the hardware model with the specified handle; the SimuHWStop interface to stop the simulation for the hardware model with the specified handle;

[0075] Specify the SimuHWWriteNoBlock interface to write data to the corresponding hardware channel of the hardware model corresponding to the specified handle;

[0076] The SimuHWReadCB interface performs a read operation on the corresponding hardware channel of the hardware model.

[0077] The call order of the interfaces during the simulation process is as Figure 4 shown.

[0078] Among them, the SimuHWSetCardID, SimuHWSetThreadAttr, SimuHWRegisteReadCB, SimuHWSetLogCB, and SimuHWGetChannels interfaces constitute the second interface; the SimuHWStart, SimuHWStop, SimuHWWriteNoBlock, and SimuHWReadCB interfaces constitute the fourth interface; the SimuHWUnInit and SimuHWDestroyBoard interfaces constitute the fourth interface.

[0079] (3) Protocol model interface: Construct a protocol model, which is responsible for packing the data output by the digital model and sending it to the physical model, and unpacking the data output by the physical model and sending it to the digital model; decouple the protocol format design from the physical entity to facilitate the reuse and maintenance of the protocol. The interface design of its class is as Figure 2 shown. The detailed interface design is as follows:

[0080] Define Protocol as the constructor of the class, which is responsible for instantiating the object (i.e., the protocol model); define ~Procotol as the destructor of the class, which is responsible for recycling the memory of the object;

[0081] Specify the GetModelName interface (i.e., the name acquisition interface) to obtain the protocol model name; specify the GetInternalPortID interface (i.e., the port ID acquisition interface) to obtain the ID of the specified port name;

[0082] The port here refers to the source or destination location for specifying data transmission. For example, the protocol model needs to know from which port the data is sent and to which port the data should be received, through the port ID acquisition interface.

[0083] Specify the GetValue interface (i.e., the attribute value acquisition interface) to obtain the value of the specified type of the specified ID port; specify the SetValue interface (i.e., the attribute value setting interface) to set the type value of the specified ID port;

[0084] The type here refers to the type of data being transmitted, which can be numerical type, string type, or boolean type.

[0085] Define the Build (i.e., the processing interface) interface to construct the abstract data structure of the protocol according to the protocol configuration file, and implement data packing and unpacking;

[0086] Construct the GetParamValueList (i.e., the list acquisition interface) to obtain the parameter list of the protocol model;

[0087] Define SetProtocolID (i.e., the protocol model ID acquisition interface) to obtain the ID of the protocol model.

[0088] (4) Data exchange interface: In the cyber-physical interaction, there are various types of data and frequent data conversions. If separate designs are made for each type of data and for data exchange with different types of models, not only is the interaction efficiency low, but also the maintenance cost is high, the scalability is poor, and errors are likely to occur.

[0089] The present invention defines an abstract class to store various types of data and read any data type simultaneously. The interface design method of this abstract class is as Figure 5 shown. This abstract class serves as an intermediate layer to uniformly store and manage various types of data transmitted between subsystems and the object under test in the cyber-physical fusion test system, providing a flexible data interaction mechanism. The detailed interface design of this abstract class in this embodiment is as follows:

[0090] Specify kMaxValueStringSize (i.e., the string length interface) to save the string length of string type data;

[0091] Define data_type_ (i.e., the data type interface) to save the type of data, which is an enumeration value;

[0092] Set encoding_type_ (i.e., the encoding type interface) as the encoding type of the data, which is an enumeration value;

[0093] Save the value of the numerical type to basic_value_ (i.e., the numerical storage interface);

[0094] Store the string data to str_value (i.e., the string storage interface);

[0095] Define Variable as the constructor of the abstract class, which can instantiate data objects according to the input value and the type of the value; define ~Variable as the destructor of the abstract class, which can release the occupied memory;

[0096] Define the operator interface as the override of the operator to complete the numerical operations and comparisons of the abstract class;

[0097] The data reading interface for reading any data type includes:

[0098] Define the AsBool interface to read boolean type data;

[0099] Define the AsSignedChar interface to read 8-bit integer type data; define the AsUnsignedChar interface to read 8-bit unsigned integer type data;

[0100] Define the AsShort interface to read 16-bit integer data; define the AsUShort interface to read 16-bit unsigned integer data; define the AsInt interface to read 32-bit integer data; define the AsUInt interface to read 32-bit unsigned integer data; define the AsLongLong interface to read 64-bit integer data; define the AsULongLong interface to read 64-bit unsigned integer data; define the AsFloat interface to read floating-point data; define the AsDouble interface to read double-precision floating-point data; define the AsString interface to read string data.

[0101] (5) Configure and encapsulate the communication interface and driver interface of the 1553B bus: The 1553B bus protocol is a data communication protocol widely used in the military and aerospace fields, used to transmit data and control information between different devices. Its design aims to provide highly reliable communication, adapting to harsh environmental conditions and complex system architectures.

[0102] The 1553B bus protocol adopts a master-slave structure, where a master device can communicate with multiple slave devices. The core of the communication is the bidirectional differential signal transmitted through twisted pair or coaxial cable. The devices on the bus are divided into two types: RT (Remote Terminal, slave device) and BC (Bus Controller, bus controller). Bus Controller (BC): The BC is responsible for controlling data transmission and command issuance on the bus. It sends control commands to the RT and also receives data from the RT. Remote Terminal (RT): The RT is a slave device on the bus, responsible for executing the instructions of the BC and providing data. Each RT has a unique address, and the BC selects the corresponding RT for communication based on the address.

[0103] In this embodiment, the digital-physical fusion test system issues operation control instructions to the physical entity (i.e., Figure 6 the tested unmanned equipment controller in) in the object under test through the 1553B bus, and the physical entity receives the operation control instructions through the 1553B bus.

[0104] Configure the BC of the 1553B, set the configuration board card number, channel number, frame frequency, RT settings, sub-address settings. An example of the configuration file design method is as follows:

[0105]

[0106]

[0107] In the present invention, configure the RT, set the board card number, channel number, RT settings, sub-address settings. An example of the configuration file design method is as follows:

[0108]

[0109]

[0110] The design of the BC driver interface encapsulating the 1553B bus is as follows:

[0111] Define the SimuHWInit interface to read and parse the configuration file, and call the initialization interface of the board driver for initialization; according to the frame frequency, RT settings, and sub - address settings in the configuration file, call the BC's initialization interface, interrupt setting interface, and BC's frame configuration interface in sequence to complete the BC configuration;

[0112] Set the SimuHWUnInit interface to release the data buffer spaces for receiving and sending;

[0113] Define the SimuHWRegisteReadCB interface, which is called when the board receives data and uploads the received data to the simulation terminal;

[0114] Define the SimuHWStart interface to call the BC start - working interface of the board driver; define the SimuHWStop interface to call the BC stop - working interface, BC shutdown interface, and board shutdown interface of the board driver in sequence;

[0115] The SimuHWWriteNoBlock interface calls the transceiver buffer write interface of the driver to write the data to be sent;

[0116] The interface design of the present invention for encapsulating the RT driver is as follows:

[0117] Define the SimuHWInit interface to read and parse the configuration file, and call the initialization interface of the board driver for initialization. Subsequently, according to the RT settings and sub - address settings in the configuration file, call the RT's initialization interface, interrupt setting interface, and RT's frame configuration interface in sequence to complete the RT configuration;

[0118] Define the SimuHWUnInit interface to release the data buffer spaces for receiving and sending;

[0119] Set the SimuHWRegisteReadCB interface, which is called when the board receives data and uploads the received data to the simulation terminal;

[0120] Define the SimuHWStart interface to call the RT start - working interface of the board driver; define the SimuHWStop interface to call the RT stop - working interface, RT shutdown interface, and board shutdown interface of the board driver in sequence;

[0121] Define the SimuHWWriteNoBlock interface to call the transceiver buffer write interface of the driver to write the data to be sent.

[0122] (6) Configure and encapsulate the communication interface and driver interface of the CAN bus: The CAN bus is a broadcast type of bus that supports linear topology, star topology, tree topology, and ring topology, etc. At least two node devices are required in the CAN network to communicate. It is not possible to send a message only to a specific node device. When sending data, all nodes inevitably receive all traffic. However, the CAN bus hardware supports local filtering, so each node can be set to respond to valid messages.

[0123] Specifically, in this embodiment, each sub-entity communicates through the CAN bus.

[0124] In the present invention, configure the name and baud rate of the CAN channel. An example of the configuration file design method is as follows:

[0125] {

[0126] "DeviceChannelName":"can0",

[0127] "BuadRate":115200

[0128] }

[0129] The encapsulation of the CAN driver interface in the present invention is designed as follows:

[0130] Define the SimuHWInit interface to read and parse the configuration file, and call the initialization interface of the board driver for initialization.

[0131] Set the SimuHWUnInit interface to release the receive and transmit data buffer space;

[0132] Define the SimuHWRegisteReadCB interface, which is called when the board receives data and uploads the received data to the simulation terminal;

[0133] Define the SimuHWStart interface to call the CAN start working interface of the board driver; the SimuHWStop interface to call the CAN stop working interface of the board driver;

[0134] Define the SimuHWWriteNoBlock interface to call the transmit interface of the driver to send data to the bus.

[0135] (7) Configure and encapsulate the communication interface and driver interface of the serial data port: Configure the name, baud rate, data bits, stop bits, parity bit, flow control of the serial port; Define the encapsulated call function of the serial port driver. It is applied to sensor data acquisition or simple instruction transmission, and provides diversified communication support for the system together with other communication interfaces.

[0136] Configure the name, baud rate, data bits, stop bits, parity bit, flow control of the channel. An example of the configuration file design method is as follows:

[0137] {

[0138] "Port":" / dev / ttyAP0",

[0139] "BaudRate":115200,

[0140] "DataBits":8,

[0141] "StopBits":1,

[0142] "Parity":"None",

[0143] "FlowControl":"None"

[0144] }

[0145] The interface design for encapsulating the serial port driver in the present invention is as follows:

[0146] Define the SimuHWInit interface to read and parse the configuration file, and call the initialization interface of the board driver for initialization.

[0147] Set the SimuHWUnInit interface to release the data buffer spaces for reception and transmission;

[0148] Define the SimuHWRegisteReadCB interface, which is called when the board receives data and uploads the received data to the simulation terminal;

[0149] Define the SimuHWStart interface to call the serial port start working interface of the board driver; the SimuHWStop interface to call the serial port stop working interface of the board driver;

[0150] Define the SimuHWWriteNoBlock interface to call the send interface of the driver to send data to the bus.

[0151] An example of the interface system for the cyber-physical interaction of the digital-physical fusion test system:

[0152] An interface system for cyber-physical interaction in a digital-physical fusion test system. The interface system includes a physical model interface. The physical model interface is used to convert the communication physical interfaces of each sub-entity included in the physical entity into a unified communication driver interface, so as to realize the data interaction between the physical entity and the digital model in the digital-physical fusion test system and its object under test. Specifically, the interface system for cyber-physical interaction in the digital-physical fusion test system has been introduced in sufficient detail in the above embodiments of the digital-physical fusion test system, and will not be repeated here.

[0153] The present invention has the following characteristics:

[0154] (1) Applying sensing technology enables the digital model to obtain immediate physical parameters, ensuring that the model can respond within an appropriate time frame and maintaining the continuity of the simulation process; providing high-precision data input provides a real-world benchmark for the digital model, enhancing the accuracy and authenticity of the simulation; combining sensing technology with execution technology to form a complete feedback loop to achieve two-way interaction between the digital model and the physical entity; dynamically updating the simulation process to adapt to the changing physical environment; integrating cyber-physical interaction technology to aggregate multi-modal data and provide a comprehensive physical view for the digital model; keeping the data collected by the sensor synchronized with the inside of the model to ensure data consistency. Using sensing technology provides a basis for cyber-physical interaction, which ensures efficient and accurate data exchange between the digital model and the physical entity.

[0155] (2) Receiving and processing the data generated by the physical model's response and changes to the outside world to ensure its quality and consistency; uniformly formatting the data from different sensors or sources to make it conform to the input standards and requirements of the digital model; sending the data or feedback generated by the physical model to the digital model, including data packing, optimization and verification, to ensure the integrity and accuracy of data transmission; defining data exchange specifications and communication protocols to ensure effective communication between both parties and meet the data structures and requirements between different models; in addition, it ensures that the data structures and requirements between different models are met; processing data is the core part of cyber-physical interaction, connecting and supporting the seamless interaction between the digital model and the physical model, which ensures the accurate, effective and continuous transmission of information between different models.

[0156] (3) Selecting the hardware communication method according to the specific requirements and application scenarios of the simulation; defining interfaces with specific sensors, actuators or other hardware devices to ensure good compatibility and stability between the communication interface and the device; designing an effective error detection and correction mechanism to cope with various possible communication interferences and failures; using hardware communication as a bridge in cyber-physical interaction to connect the digital model and the physical model. An efficient, stable and secure hardware communication system is the cornerstone of achieving high-quality cyber-physical interaction.

[0157] Finally, it should be noted that the above are only the preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still make modifications to the technical solutions described in the foregoing embodiments without creative efforts, or perform equivalent replacements for some of the technical features. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. An interface system for information-physical interaction of a digital-physical fusion test system, characterized in that: The interface system includes a physical model interface; the physical model interface is used to convert the communication physical interfaces of each sub-entity included in the physical entity into a unified communication driver interface, so that the physical entity of the digital-physical fusion test system as the object under test can interact with the data of the digital model through the communication driver interface.

2. The interface system for information-physical interaction of a digital-physical fusion test system according to claim 1, characterized in that: The interface system also includes a digital model interface; each sub-model included in the digital model performs data exchange through the digital model interface, and each sub-model performs data exchange with the physical entity through the same digital model interface.

3. The interface system for information-physical interaction of a digital-real fusion test system according to claim 1 or 2, characterized in that: The communication driver interface includes a first interface, a second interface, a third interface, a fourth interface and a fifth interface which are sequentially called in the digital-real fusion test; The first interface is used to instantiate a physical model; the second interface is used to set parameters and callback functions for the physical model; the third interface is used to initialize the physical model; the fourth interface is used to control the physical model during simulation to complete the digital-real fusion test; the fifth interface is used to end the communication driver interface call.

4. The interface system for information-physical interaction of a digital-physical fusion test system according to claim 3, characterized in that: The parameters set by the second interface for the physical model include an ID, thread parameters during simulation, and a channel for reading and writing data; And / or the callback function set by the second interface for the physical model includes a read callback function and a log callback function.

5. The interface system for information-physical interaction of a digital-real fusion test system according to claim 3, characterized in that: The fourth interface includes a start interface for starting simulation, a read interface for reading data from a channel corresponding to the physical model, a write interface for writing data to the channel corresponding to the physical model, and a stop interface for stopping simulation.

6. The interface system for information-physical interaction of a digital-physical fusion test system according to claim 3, characterized in that: The fifth interface includes a deinitialization interface for deinitializing the physical model and a destruction interface for destroying the physical model, which are called in sequence.

7. The interface system for information-physical interaction of a digital-physical fusion test system according to claim 2, characterized in that: The digital model interface is established based on fmilib.

8. The interface system for information-physical interaction of a digital-physical fusion test system according to claim 2, characterized in that: Each sub-model is represented by a class in the simulation; the digital model interface includes a callback function for observing the simulation process of the sub-model corresponding to the digital model interface, a simulation control for controlling the sub-model corresponding to the digital model interface during the simulation process to complete the digital-real fusion test, and a class operation of the sub-model corresponding to the digital model interface.

9. The interface system for information-physical interaction of a digital-physical fusion test system according to claim 8, characterized in that: The basic properties of the digital model interface include the file directory path of the sub-model corresponding to the digital model interface, the sub-model name corresponding to the digital model interface and the complete download path of the sub-model file corresponding to the digital model interface.

10. The interface system for information-physical interaction of a digital-physical fusion test system according to claim 8, characterized in that: The digital model interface is established based on fmilib; the callback function includes a callback function used to apply for memory for the sub-model, print log or release memory, a handle returned after the sub-model is loaded into fmilib, and memory information returned after the sub-model is loaded into fmilib.

11. The interface system for information-physical interaction of a digital-physical fusion test system according to claim 2, characterized in that: The interface system also includes a protocol model interface located between the digital model interface and the physical model interface, and the protocol model interface is used to package the data output by the digital model and send it to the physical model, and to unpack the data output by the physical model and send it to the digital model.

12. The interface system for information-physical interaction of a digital-physical fusion test system according to claim 11, characterized in that: The protocol model interface includes a constructor for instantiating an object, a destructor for reclaiming object memory, a name acquisition interface for obtaining the name of the protocol model, a port ID acquisition interface for obtaining the ID of a specified port name, an attribute value acquisition interface for obtaining a value of a specified type of a specified ID port, an attribute value setting interface for setting a value of a value type of a specified ID port, a processing interface for data packaging and unpacking, a list acquisition interface for obtaining a protocol model parameter list, and a protocol model ID acquisition interface for obtaining a protocol model ID.

13. The interface system for information-physical interaction of a digital-physical fusion test system according to claim 1 or 2, characterized in that: The interface system also includes a data exchange interface, and data is transmitted between each subsystem and the object under test in the digital-real fusion test system through the data exchange interface; In the digital-real fusion test, a class is defined to store data sent by a data sender in the form of different data types, and a data receiver is allowed to read any type of data in the class through the data exchange interface.

14. The interface system for information-physical interaction of a digital-physical fusion test system according to claim 13, characterized in that: The data exchange interface includes a string length interface for saving the string length of string type data, a data type interface for saving the data type, an encoding type interface for saving the encoding type of data, a numerical storage interface for saving numerical values, a string storage interface for saving string data, a constructor for instantiating a data object according to an input value and the type of the value, a destructor for releasing memory, an operator interface for overriding an operator, and a data reading interface for reading data of a specified data type.

15. The interface system for information-physical interaction of a digital-physical fusion test system according to claim 1 or 2, characterized in that: The interface system also includes a communication interface and a drive interface of at least one of the 1553B bus, the CAN bus and the serial bus; the 1553B bus is used to realize the communication between the physical entity in the object under test and the subsystems of the digital-real fusion test system; the CAN bus is used to realize the communication between the various sub-entities of the physical entity; the serial bus is used to realize the transmission of sensor acquisition signals or simple control instructions.

16. A digital-real fusion testing system, characterized in that: It includes an interface system for information-physical interaction, and the interface system includes a physical model interface; the physical model interface is used to convert the communication physical interfaces of each sub-entity included in the physical entity into a unified communication driver interface, so that the physical entity of the digital-physical fusion test system as the test object interacts with the data of the digital model through the communication driver interface.

17. The digital-real fusion test system according to claim 16, characterized in that: The digital model includes sub-models, and the interface system also includes a digital model interface; the sub-models included in the digital model exchange data with each other through the digital model interface, and the sub-models exchange data with the physical entity through the same digital model interface.

18. The digital-real fusion test system according to claim 17, characterized in that: The interface system also includes a protocol model interface located between the digital model interface and the physical model interface, and the protocol model interface is used to package the data output by the digital model and send it to the physical model, and to unpack the data output by the physical model and send it to the digital model.

19. The digital-real fusion test system according to claim 16 or 17, characterized in that: The interface system also includes a data exchange interface, and data is transmitted between each subsystem and the object under test in the digital-real fusion test system through the data exchange interface; In the digital-real fusion test, a class is defined to store data sent by a data sender in the form of different data types, and a data receiver is allowed to read any type of data in the class through the data exchange interface.

Images