Cyber-physical test system with universal interface module

Abstract

This invention discloses a cyber-physical testing system with a universal interface module. The universal interface module connects to various hardware components. The module includes a 1553B bus. The 1553B bus utilizes a dual-redundant design, consisting of two redundant buses, BUS-A and BUS-B, connected to a 1553B interface communication module. The two buses are connected to a bus coupler, employing an ESI-310-1553B coupler. The system's hardware operations are abstracted into a universal interface. System programming is performed solely on the universal interface, and each hardware component exposes a unified interface to external programs.

Description

Technical Field

[0001] The present invention relates to an information system, and in particular to an information-physical testing system containing a universal interface module. Background Art

[0002] Cyber-physical test systems need to interconnect with a wide range of hardware. These hardware interfaces are diverse and include network hardware such as TCP and UDP, serial port hardware such as RS232 and RS422, I / O hardware such as analog and digital I / O, and bus hardware such as CAN, FlexRay, and 1553B. These hardware components operate in different ways, both in principle and in practice. Traditionally, the system requires developing a separate submodule for each hardware type to perform functions such as initialization, data reading and writing, and shutdown. This approach presents two problems: the system needs to directly operate each specific hardware type, and as the number of hardware types increases, the system becomes increasingly complex. Some hardware types lack open programming interfaces, making them inaccessible to programs. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to overcome the above-mentioned defects in the prior art and provide a cyber-physical testing system containing a universal interface module.

[0004] A cyber-physical test system containing a universal interface module, characterized in that the cyber-physical test system is connected to various hardware via the universal interface module, the universal interface module includes a 1553B bus, the 1553B bus adopts a dual-redundant design, and is connected to the 1553B interface communication module by two redundant buses BUS-A and BUS-B, the two buses are connected to a bus coupler, and the bus coupler adopts an ESI-310-1553B coupler; the 1553B bus has a hardware protocol, and the hardware protocol attributes include a protocol number, a protocol name, and a protocol Type and sub-address mode; the protocol number is the landmark field of the hardware protocol, which enables the platform configuration subsystem and the server terminal subsystem to complete the encapsulation and parsing of the data according to the protocol number; the protocol type indicates the role played by the protocol in the simulation project, which is divided into 1553B bus controller (BC) mode or 1553B remote terminal (RT) mode; the sub-address transmission mode includes "Deep" and "Flat", "Deep" means that the 1553B bus will send the simulation data packet in a flat manner to all sub-addresses responsible for receiving data under the RT, and "Flat" means that The 1553B bus sends all data packets to one of the sub-addresses under RT that is responsible for receiving data. The 1553B hardware protocol is applied to the bus controller (BC) and remote terminal (RT) working modes of the 1553B bus system. Two 1553B hardware models are generated in the simulation project and deployed in the programs of the bus control device and remote terminal device respectively. After the 1553B hardware protocol is created, the platform configuration subsystem program will persist the protocol attribute data in the database. The FMI co-simulation system will send a request to the platform server subsystem program to obtain the 1553B hardware protocol. While parsing the request, the platform server subsystem program will generate two 1553B hardware models with the same attribute values ​​in the simulation project, namely the BC model and the RT model. Each model contains the IP address and port of the target device for data transmission. The BC model corresponds to the bus control device, and the RT model corresponds to the remote terminal device. When the simulation project is started, the bus control device program sends the simulation data generated by the FMU module to the specified remote terminal according to the 1553B hardware protocol attributes encapsulated in the BC model. Data transmission is realized by the 1553B bus. After receiving the simulation data, the RT model deployed at the remote terminal sends the data back to the FMU module, forming a closed loop for the entire transmission process.

[0005] The beneficial effects of the present invention are as follows: the system's operations on hardware are abstracted into a universal interface. The system is programmed only for the universal interface, and the interface exposed to external programs for each type of hardware is unified. When new hardware is added, there is no need to write a program specifically for the new hardware, but the upper-level code of the system remains unchanged. This minimizes the scope of change and improves the quality and maintainability of the system. For non-programmable hardware, it can be encapsulated into a static library or dynamic library according to the specified interface, and the system can directly call it without accessing the actual code. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 Schematic diagram of the system structure of the present invention; Figure 2 This is the functional block diagram of the 1553B interface communication module; Figure 3 The functional structure design diagram of the subsystem configuration of the platform of the present invention; Figure 4 This is the data interaction flow chart between the 1553B hardware model and the FMU module;

[0007] Figure 5 To realize the three-layer structure relationship diagram of 1553B model program; Figure 6 Flowchart for data input and output; Figure 7 This is the flow chart of the import procedure for the 1553B hardware model; Figure 8 This is a four-layer structure program call sequence diagram. DETAILED DESCRIPTION

[0008] To make the above-mentioned objects, features, and advantages of the present invention more readily apparent, the following detailed description of specific embodiments of the present invention is provided in conjunction with the accompanying drawings, so that the above-mentioned and other objects, features, and advantages of the present invention will become more apparent. Like reference numerals denote like parts throughout the drawings. The drawings are not drawn to scale; emphasis is placed on illustrating the subject matter of the present invention.

[0009] The hardware that is interconnected with the cyber-physical test system generally exists in the form of boards. A board is a card that integrates certain specific hardware functions and is plugged into the motherboard through interfaces such as PCI / PCIE / PXI. The board may integrate hardware sub-modules with different functions. For example, the motherboard integrates hardware with different functions such as network cards, serial ports, USB, etc. to transmit data. Hardware sub-modules with the same function can also transmit multiple channels of data at the same time. For example, if there are multiple USB interfaces, the network card can transmit data through multiple TCP ports. Figure 1 As shown in FIG, the cyber-physical test system is connected to various hardware via a universal interface module to achieve mutual communication.

[0010] The universal interface module includes the 1553B bus. To ensure the synchronization and consistency of the bus design structure with the 1553B bus protocol when the data interaction function is activated, the following important technical details are required during the configuration and construction of the data interaction device motherboard:

[0011] (1) The multifunctional 1553B interface communication module is installed in the standard 32-bit PCI slot of the industrial control host motherboard, so that the module can realize data interaction with the CPU through the PCI controller.

[0012] (2) The 1553B bus network adopts a dual-redundancy design, with two redundant buses BUS-A and BUS-B connected to the 1553B interface communication module. The two buses are connected to a bus coupler, which adopts an ESI-310-1553B coupler. In the present invention, a SCSI-1553 dedicated connection line is selected as the data transmission cable.

[0013] (3) The network port of the data interaction device is connected to the central Gigabit Ethernet switch, and the platform configuration subsystem sends simulation data to the program in the data interaction device through the Redis channel.

[0014] (4) The data interaction device uses the Linux 64-bit operating system (Centos-7-x86_64-DVD-1810) and can be connected to a keyboard, mouse, VGA monitor, and hard disk, enabling developers to deploy program-controlled 1553B interface communication modules in the data interaction device.

[0015] The bus monitoring device serves as the configuration information input interface in the hardware module. It is responsible for unified management of the configuration information of the FMI joint simulation system and sends data signals to each simulation terminal device. It can also serve as the output interface of FMU data information, display simulation data in real time, and store and analyze historical data.

[0016] The bus monitoring device uses a PC host as its hardware carrier, running Windows. It uses the AltaView bus analyzer as a visual monitoring tool for 1553B bus data interactions, and AltaRTVal software as a remote terminal (RT) mode validity tester. The Alta View bus analyzer is an internet-based, fully passive data monitoring and big data analysis tool. Its primary function is to monitor configuration signals and remote control commands transmitted to various simulation devices, enabling interception of initial setup signals for each node and centralized management of data communications. It parses simulation data packets in real time according to system configuration information and controls 1553B bus test equipment testing and result display. The AltaRTVal tool, a submodule of the Alta View bus analyzer, allows developers to test whether programs running on simulated terminal devices implement the remote terminal (RT) device functionality required by the 1553B communication protocol. Developers use the Alta View bus analyzer to configure 1553B board properties and initialize the 1553B interface communication module.

[0017] On the bus monitoring device initialization interface, first specify the bus channels involved in data exchange and the 1553B interface communication module IDs of each data exchange device. You also need to configure the IP addresses and port numbers of the data exchange devices, ensuring that each data exchange device has a corresponding IP address and port. The bus monitoring device establishes a connection with the data exchange device according to the corresponding configuration, synchronously parsing and displaying the simulation data transmitted between the data exchange devices, thus implementing the simulation data monitoring function.

[0018] The design and implementation of the 1553B interface communication module is a key component of each physical device in the hardware module. It mainly realizes the information integration, resource sharing, task scheduling and fault-tolerant reconstruction functions of the 1553B bus. Therefore, the design of the 1553B interface communication module in the physical module is particularly important. The data interaction device and bus monitoring device of the present invention are both equipped with a 1553B interface communication module. Each device realizes data interaction and data monitoring functions through its internal 1553B interface communication module. The functional block diagram of the 1553B interface communication module is shown in the figure. Figure 2 shown.

[0019] After the platform configuration subsystem sends a simulation data message to the data exchange device, the device first parses the simulation instructions and the message data to be transmitted. The server terminal subsystem program then initiates a Target write instruction and accesses the relevant registers and RAM in the FPGA. The controller then transmits the data message to the 1553B bus via the transceiver and isolation transformer. Receiving a message is the reverse of sending a message. The data exchange device first initializes the protocol controller. Upon receiving a data message, the controller sends a request signal to the data exchange device. Upon receiving the request, the data exchange device initiates a Target read instruction to retrieve the data from the corresponding registers and RAM.

[0020] FPGA is a programmable gate array chip that developers can customize and program for synchronous simulation. FPGA loading is highly efficient, and reconfiguration can reduce hardware overhead. The FPGA processor used in this invention supports BC, RT, and BM modes simultaneously, enabling the data exchange modes of BC to RT, RT to RT, broadcast, and mode instructions specified by the 1553B bus communication protocol. This chip is programmable, and developers use a bus monitoring device to drive and configure the 1553B multi-function board. Operations such as 1553B bus protocol control and 1553B bus data reading and writing are performed by the FPGA processor through programs deployed in the data exchange device.

[0021] The design of the platform configuration subsystem. In the process of designing the platform configuration subsystem function, the present invention first designs the 1553B hardware protocol field and specifically displays it in the platform configuration subsystem. Subsequently, the data type of the hardware model is designed according to the 1553B word format, which is mainly divided into three parts: frame synchronization, time synchronization, and data service. Secondly, the 1553B hardware protocol is configured to generate a 1553B hardware model. Finally, the platform configuration subsystem is implemented to send simulation instructions and simulation data to the server terminal subsystem. According to the above main functional design, the functional structure design diagram of the platform configuration subsystem in the FMI joint simulation system is as shown in the figure. Figure 3 shown.

[0022] The functional structure design of the platform configuration subsystem is divided into three parts, and the main implementation is as follows: (1) Create a hardware directory in the hardware list and divide the directory into two levels. The first-level directory represents the type of hardware board, and the second-level directory represents the hardware protocol. Multiple hardware protocols can be configured under the same board type to achieve the classification and organization of boards and protocols with different functions. (2) Create a hardware model and configure properties during the hardware configuration design process. Each hardware model is used as a hardware protocol to implement a specific semi-physical simulation data interaction function. The protocol number, protocol name, protocol type and sub-address method are designed in the hardware protocol properties. The protocol number is the iconic field of the hardware protocol, so that the platform configuration subsystem and the server terminal subsystem follow the protocol number to complete the encapsulation and parsing of the data. The protocol type represents the role played by the protocol in the simulation project, which is divided into 1553B bus controller (BC) mode or 1553B remote terminal (RT) mode. The sub-address transmission modes include "Deep" and "Flat". "Deep" means that the 1553B bus will send the simulation data packet in a flat manner to all sub-addresses responsible for receiving data under RT. "Flat" means that the 1553B bus will send all data packets to one of the sub-addresses responsible for receiving data under RT. After the simulation project sends the determined hardware protocol to the server terminal subsystem, the system parses the protocol configuration and sends the data packet to the specified data interaction device. (3) The present invention takes into account the cross-platform application scenario of the hardware protocol, and therefore designs the import and export functions of the hardware protocol, realizes the persistent storage of the protocol, and enables the JSON generated by the hardware protocol to be applied to different simulation projects, thereby improving the reusability of the hardware protocol.

[0023] During the implementation of the hardware protocol configuration page for the platform configuration subsystem, an interface was created to interact with the backend program. This interface retrieved dynamically bound node data and then displayed the node data back to the frontend page using the zTree library functions. The entire implementation process employed JavaScript statements to embed dynamic text within static HTML, making the interface more flexible. The pseudocode for this implementation is shown in Table 1.

[0024] Table 1

[0025]

[0026] As shown in Table 1, the implementation process of the generateTree() function is divided into three stages:

[0027] Step 1: First, send a request interface to the backend through Ajax. After receiving the request, the backend passes the node data to the response domain, and the frontend obtains the node data through response.data.

[0028] Step 2: Call the init() function to instantiate the node data into a tree structure object, and assign an id value to each node data in the tree structure object through the self-increment of idBase.

[0029] Step 3: Call the dom.setAttribute() function to echo the tree structure with node data on the hardware protocol configuration page according to the node ID.

[0030] Implementation method of hardware protocol configuration page. Semi-physical simulation instructions refer to the process in which the bus controller determines the address and data length of the simulation data sent through the semi-physical simulation instructions during the 1553B bus transmission, and sends the simulation data to the remote terminal according to the instruction information. Based on the design characteristics of the FMI joint simulation system and the development requirements of the present invention for the configuration of data interaction pages, the lightweight UI type library Knockout is used as the development framework of the 1553B hardware protocol configuration page, and the JSTL technology is used as the dynamic tag library of static HTML, so that the interface is more concise and the code writing efficiency is greatly improved. Based on the remote terminal and sub-address structure of the 1553B bus system, a drop-down list is designed and the remote terminal ID and sub-address ID are configured to realize the persistent storage of the 1553B hardware protocol. At the same time, in the process of the server terminal subsystem program calling the hardware interface, the data structure of the 1553B hardware protocol is an important factor in driving the 1553B board and realizing semi-physical simulation. Therefore, based on the structural system of the 1553B bus protocol, the present invention designs and implements an entity class for each node attribute of the 1553B hardware protocol. Its main functions include the following three points: (1) Responsible for receiving the 1553B hardware protocol form information submitted in the platform configuration subsystem and saving it to the MySQL database. (2) After the simulation project is started, the hardware protocol data in the cache database is called back and sent to the server terminal subsystem via Redis. (3) The hardware interface is called and, based on the attribute information of the 1553B hardware protocol, the simulation data is sent to the specified remote terminal. The implementation code of the 1553B hardware protocol entity class is shown in Table 2.

[0031] Table 2

[0032]

[0033] In the implementation of the 1553B hardware protocol entity class, the channel number and channel name fields determine the channel address for simulated data transmission. The data type field indicates the type of simulated data, which can be categorized as frame synchronization data, time synchronization data, and simulation data. Frame synchronization data enables the remote terminal to distinguish the start and end points of each frame in the received binary bit stream, enabling bus monitoring devices to monitor changes in each frame of simulated data. Time synchronization data synchronizes the bus controller and remote terminal on the time base, enabling accurate and low-latency data communication. The message type indicates the data exchange mode of the 1553B bus. After determining the data exchange mode, the bus controller (BC) can locate the remote terminal receiving the simulated data using the remote terminal (RT) address and RT subaddress. The data length, start subaddress, and end subaddress determine the specific location where the simulated data is sent. The entity class is modified with annotations from the Lombok plugin. The Data annotation privatizes all properties in the 1553B hardware protocol entity class without creating get and set functions. This prevents external programs from directly manipulating their property values, instead accessing them through automatically generated interfaces, ensuring the security of the data within the protocol. The NoArgsConstructor and AllArgsConstructor annotations create corresponding no-argument and argument constructors for the entity class. At the same time, the method for configuring the page program is implemented in the platform configuration subsystem. The specific process is as follows:

[0034] (1) In view of the requirements of each node attribute in the 1553B hardware protocol, the configuration page is described using HTML hypertext markup language. At the same time, since there are a maximum of 32 remote terminals in a 1553B bus system and each remote terminal corresponds to 32 sub-addresses, the present invention uses JavaScript to generate a dynamic drop-down box for the attributes of each protocol node to realize the function of configuring protocol attributes.

[0035] (2) Using the knockout architecture as a JavaScript library, it is possible to generate a rich text display interface with good display and editing functions using only a clear and complete basic layer data information model. The specific implementation is to convert the protocol data into a JavaScript array, and bind each data in the array to a table in the interface or in a div by traversing. When the data in the array changes, the interface will automatically respond and synchronize the data, thus ensuring the consistency of the 1553B hardware protocol attribute data. The implementation code of the 1553B hardware protocol configuration page is shown in Table 3.

[0036] Table 3

[0037]

[0038] The core implementation steps of the 1553B hardware protocol configuration page are as follows:

[0039] Step 1: Use the ko.observable() function to monitor each 1553B hardware protocol attribute value entered in the configuration page, and use the ko.observableArray() function to monitor each option in the drop-down list to achieve real-time dynamic binding of attribute values.

[0040] Step 2: In a 1553B bus system, since a BC can exchange data with up to 31 RTs, and each RT can map up to 31 subaddresses, the present invention uses a for loop to assign attribute values ​​to the drop-down boxes for remote terminal and remote terminal subaddress. Users can select the corresponding address parameters on the configuration page, making the configuration page more user-friendly while reducing the probability of input errors.

[0041] Step 3: Call the validation() function to verify the input attribute value to ensure that the user fills it in the correct format to prevent the platform configuration subsystem program from being unable to generate the 1553B hardware protocol due to data format errors.

[0042] Step 4: Use the if statement to control the verification result in step 3. When the return value of the valid() function is true, it means that the verification is passed. Then, the platform configuration subsystem program interface is called through the context.fetchbackun() function to encapsulate all 1553B attribute values ​​monitored in ko.observable() and then submit them to the background program for processing.

[0043] Generation method of 1553B hardware model. In the process of creating a semi-physical simulation project, in addition to building FMU-related modules, the FMI joint simulation system will also call the 1553B hardware protocol data in the platform configuration subsystem and generate the corresponding 1553B hardware model in the simulation project. The FMU module represents a collection of multiple FMUs connected together. Each FMU module is connected through a 1553B hardware model to achieve the function of simulating semi-physical simulation in the UI display of the simulation project. At the same time, at the simulation data level, the FMU module sends the simulation data to the designated server terminal subsystem through the 1553B hardware protocol. The server terminal subsystem program parses the 1553B hardware protocol attributes and sends the simulation data to the FMU module deployed on other remote terminals. The data interaction process between the 1553B hardware model and the FMU module is as follows: Figure 4 shown.

[0044] like Figure 4As shown in the figure, in a semi-physical simulation project, a 1553B hardware protocol is applied to the bus controller (BC) and remote terminal (RT) operating modes of a 1553B bus system. This means that two 1553B hardware models need to be generated in the simulation project, deployed in the programs of the bus controller and remote terminal, respectively. Once the 1553B hardware protocol is created, the platform configuration subsystem program persistently stores the protocol attribute data in a database. During the construction of the semi-physical simulation project, the FMI co-simulation system sends a request to the platform server subsystem program to obtain the 1553B hardware protocol. The platform server subsystem program parses the request and generates two 1553B hardware models with identical attribute values ​​within the simulation project: the BC model and the RT model. Each model contains the IP address and port number of the target device for data transmission. The BC model corresponds to the bus controller, and the RT model corresponds to the remote terminal. When the simulation project is started, the bus controller program sends the simulation data generated by the FMU module to the designated remote terminal according to the 1553B hardware protocol attributes encapsulated in the BC model. Data transmission is implemented via the 1553B bus. After receiving the simulation data, the RT model deployed at the remote terminal sends the data back to the FMU module, forming a closed loop for the entire transmission process.

[0045] The present invention adopts the MVC design pattern in the implementation of the 1553B hardware model, and the program structure is designed as a simulation control layer (controller), a model data layer (model) and a model view layer (view). The model control layer is mainly responsible for processing the request interface for calling the 1553B hardware protocol data in the FMI joint simulation system, and the specific processing method is handed over to the model data layer. The model data layer encapsulates the 1553B hardware protocol data in the platform configuration subsystem, generates a 1553B model and returns it to the model control layer. The model view layer is responsible for displaying the model information received in the model control layer in the simulation project. The three-layer structural relationship of the 1553B model program is as follows: Figure 5 shown.

[0046] During the 1553B hardware model generation process, method calls between the three layers of the program are implemented in Java. The 1553B hardware model corresponds to a class object in the program, namely the 1553B hardware protocol entity class defined in the previous section. The model data layer accesses the database to retrieve specific protocol attribute data. Once the model is instantiated and assigned values, the model data is cached in memory from the time the hardware model is generated until the simulation project is run. The model data is not sent to the server terminal subsystem until the simulation project is completed and the simulation begins. The pseudocode for generating the 1553B hardware model is shown in Table 4.

[0047] Table 4 Generates pseudo code for the 1553B hardware model

[0048]

[0049] In the implementation of Table 4, @RequestMapping(" / generative / Hardware / Model") is used to receive requests for obtaining the 1553B hardware model in a semi-physical simulation project. It forms a mapping relationship with the generativeHardwareModel() function, indicating that a method for generating a specific hardware model is called. This method exists in the model control layer and returns the result returned by the model data layer, that is, the encapsulated 1553B hardware protocol data.

[0050] In the model data layer, the HardwareProtocolService interface receives the URL request passed in the model control layer. The HardwareProtocolImpl class is implemented in the HardwareProtocolService interface and is responsible for calling the HardwareProtocolMapper interface to query the 1553B hardware protocol data stored in the database.

[0051] When there is a query request, MyBatis will trigger the JDK dynamic proxy mechanism and generate a Proxy object mapped to the HardwareProtocolMapper interface. The implementation of the JDK dynamic proxy uses the Java reflection mechanism. The proxy object Proxy will intercept the interface function and form a mapping association between the function name in the HardwareProtocolMapper interface and the attribute values ​​such as the id of the select tag in the Mapper mapping file. At the same time, it will send the SQL statement in the select tag to the MYSQL database, and then encapsulate the execution result of the SQL statement into a 1553B hardware model object and return it to the model view layer.

[0052] Once the 1553B model is generated, the model file data is stored in the platform configuration subsystem. Platform users can use the interface to import and export 1553B hardware model files. Taking the import function as an example, the communication process between the platform and the data interaction device program is as follows: Under the premise of following the HTTP protocol, the model file data is stored in the HTTP request body and sent to the data interaction device in the form of a binary stream. The data interaction device program parses the request through httpServletRequest, processes the hardware model data in the request body, and saves it to the local disk of the data interaction device, completing the import of the 1553B hardware model file.

[0053] Since the 1553B protocol entity class attributes contain string type data, and integer data can also be represented by strings, the present invention uses the character stream mechanism to implement the model import and export method, and writes the 1553B hardware model file into the data interaction device in character units through the output stream. When acquiring, the local 1553B hardware model is read into the program in character units through the input stream, and the program parses the character data and returns it to the platform in the form of a file. The flowchart of data input and output is shown in the figure below. Figure 5 shown.

[0054] While processing the data stream, a model file in JSON format needs to be generated locally on the data interaction platform. Therefore, the present invention uses commons-fileupload and common-io components as a development toolkit for generating 1553B hardware model files in program implementation. Common-io encapsulates a function library developed for IO streams and integrates the class structure of input streams, output streams, and cache streams, enabling the reading, writing, and copying of file data. When the data interaction device program receives the model file data sent by the platform, the built-in function of commons-fileupload will parse and process the data and generate a 1553B hardware model file locally.

[0055] During the implementation of the import method, the model file data in the platform needs to be submitted in the form of a form. When there are multiple model data, the enctype attribute in the form tag needs to be set to multipart / form-data. The HTTP protocol will generate a string of random hexadecimal separators through this attribute value and divide the model data into multiple segments. The data interaction device uses the isMultipartContent() function to determine whether the received data is valid multi-segment data. The FileItem class receives each segment of model data and generates the corresponding model file. The import program flow chart of the 1553B hardware model is as follows: Figure 6 shown.

[0056] Because data transmission between the FMI co-simulation system platform and the data interaction device follows the HTTP protocol, the present invention uses HttpServletRequest to receive model file data during the implementation of the import function code and responds to the platform with the function processing results via HttpServletResponse. The implementation code for the 1553B hardware model import method is shown in Table 5.

[0057] Table 5

[0058]

[0059] As shown in Table 5, the main implementation steps are as follows:

[0060] Step 1: Receive the data in the HTTP request body sent by the FMI co-simulation system platform through HttpServletRequest. Since the data received can only be confirmed to be in model file format if it is in multi-part format, the isMultipartContent() function is called to determine whether the received data is in multi-part format. Only if the data is in multi-part format will it be parsed; otherwise, it will not be parsed.

[0061] Step 2: Create a FileItemFactory factory class and generate a ServletFileUpload object. At the same time, parse the model file data through ServletFileUpload, generate multiple FileItems and save them to the List collection. Each FileItem corresponds to a model file.

[0062] Step 3: Use a for loop to iterate over the collection and write each FileItem to the specified path on the local data interaction device. Then, use the response.setStatus() function to return a status code of 200 to notify the FMI co-simulation system platform that the model file has been successfully imported.

[0063] In the implementation process of the export model method, the database is first queried to obtain the specified 1553B hardware protocol data and encapsulated into a 1553B hardware model. The hardware model is then returned to the platform through the output stream. At the same time, the FMI co-simulation system is notified of the file type sent through the HTTP response header.

[0064] The export process is similar to the import process. Since the 1553B model file data also follows the HTTP protocol during export, the code implementation also uses HttpServletRequest to receive requests from the platform and returns the function processing results to the FMI co-simulation system via HttpServletResponse. The implementation code for the 1553B hardware model export method is shown in Table 6.

[0065] Table 6

[0066]

[0067] Step 1: During the data interaction process of the export function, the FMI co-simulation system sends the model file name to be obtained to the data interaction device in the form of an interface, and the getUrlPath() function receives the request and obtains the file name.

[0068] Step 2: Encapsulate the 1553B hardware model into the InputStream input stream through the servletContext.getResourceAsStream() function.

[0069] Step 3: Create an output stream OutputStream, call the IOUtils.copy() function to copy the 1553B hardware model data cached in the InputStream in step 2 to the OutputStream, and return it to the FMI joint simulation system platform through the response body of the HTTP protocol.

[0070] Step 4: Based on step 3, the value of the Content-Disposition attribute in the HTTP protocol response header is set to attement through the response.setHeader() function, so that the FMI joint simulation system can use it for downloading after receiving the response data.

[0071] 1553B message transmission method. In the process of semi-physical simulation, the transmission process of 1553B message is controlled by the program deployed in the server terminal subsystem. Based on the design characteristics of the server terminal subsystem program architecture, the present invention designs the 1553B message transmission method into a four-layer structure, namely the device communication layer, the bus control layer, the message preprocessing layer and the message cache layer. Each layer of the structure controls each other through hardware functions, and finally realizes the transmission of 1553B message. The four-layer structure program call timing diagram is shown as follows Figure 7 shown.

[0072] In the implementation process of transmitting 1553B messages, the program calling steps of the four-layer structure are as follows:

[0073] Step 1: The device channel layer program drives the 1553B interface communication module and performs a security check on the 1553B bus channel to ensure that the hardware device can function properly. Once the check passes, the bus control layer program activates the bus controller (BC) function of the 1553B board in the bus control device, enabling it to send 1553B messages and dispatch all remote terminals (RTs) in the 1553B bus system, thus enabling data exchange between terminal nodes.

[0074] Step 2: The message preprocessing layer program encapsulates the FMU simulation data information according to the data structure (CDP) and encapsulates the 1553B hardware protocol data into the control structure (BCCB).

[0075] Step 3: The bus control layer program calls the hardware interface function to complete the reading and writing of BCCB and CDP data from the 1553B bus system, realizing the transmission of 1553B messages.

[0076] Step 4: After the semi-physical simulation ends, the bus control layer program stops sending 1553B messages and disables the bus controller (BC) function. The device channel layer program shuts down the 1553B-related hardware. The code for implementing 1553B message transmission is shown in Table 7.

[0077] Table 7

[0078]

[0079]

[0080] The steps for implementing 1553B message transmission are as follows:

[0081] Step 1: In the implementation of the OpenDevice() function, the device_id parameter represents the ID of the currently specified 1553B board, and the data parameter represents the simulation information involved in the data exchange. At the same time, because the memory function of the 1553B board causes the device to store the cached data after the last 1553B message transmission, the ADT_L1_1553_InitDefault_ExtendedOptions() function is called to initialize the 1553B board so that it can correctly send this 1553B message.

[0082] Step 2: Call the ADT_L1_GetVersionInfo() function to enable the 1553B board to send or receive 1553B messages on the specified bus channel using the 1553B device version number, channel number, and other parameter information. Simultaneously, call the ADT_L1_1553_INT_EnableInt(device_id) function to drive the 1553B board into operational mode.

[0083] Step 3: Since a control structure (BCCB) corresponds to a 1553B message, and a 1553B message is encapsulated as a data structure (CDP), before sending the 1553B message, a for loop is used and the ADT_L1_1553_BC_CB_CDPAllocate() function is called to apply for memory space for each data structure (CDP) and write the 1553B message into the memory space.

[0084] Step 4: The configuration parameters such as the remote terminal (RT) address, RT sub-address, frame synchronization data and data transmission mode in the control structure (BCCB) are expressed as command words in the 1553B message, and the data structure (CDP) is expressed as 1553B message data words and status words. The ADT_L1_1553_BC_CB_Write() function and ADT_L1_1553_BC_CB_CDPWrite() function are called to write the 1553B message into the 1553B bus buffer.

[0085] Step 5: Call the ADT_L1_1553_BC_Start() function to start the bus controller (BC) function of the 1553B board and send the 1553B message in the buffer area to complete the transmission of the 1553B message.

[0086] Specific details have been described in the above description to facilitate a full understanding of the present invention. However, the above description is only a preferred embodiment of the present invention, and the present invention can be implemented in many other ways different from those described herein, so the present invention is not limited to the specific implementation disclosed above. At the same time, anyone familiar with this field of technology can use the above-disclosed methods and technical contents to make many possible changes and modifications to the technical solution of the present invention without departing from the scope of the technical solution of the present invention, or modify it into an equivalent embodiment of equivalent changes. Any simple modification, equivalent change and modification made to the above embodiment based on the technical essence of the present invention without departing from the content of the technical solution of the present invention still falls within the scope of protection of the technical solution of the present invention.

Claims

1. A cyber-physical testing system containing a universal interface module, characterized in that: The cyber-physical test system is connected to various hardware via a universal interface module. The universal interface module includes a 1553B bus. The 1553B bus adopts a dual-redundant design, consisting of two redundant buses, BUS-A and BUS-B, connected to the 1553B interface communication module. The two redundant buses are connected to a bus coupler, which adopts an ESI-310-1553B coupler. The 1553B bus has a 1553B hardware protocol. The attributes of the 1553B hardware protocol include a protocol number, a protocol name, a protocol type, and a sub-address transmission mode. The protocol number is a landmark field of the 1553B hardware protocol, enabling the platform configuration subsystem and the server terminal subsystem to complete data encapsulation and parsing according to the protocol number. The protocol type indicates the role played by the 1553B hardware protocol in the simulation project. The roles are divided into 1553B bus controller mode and 1553B remote terminal mode. The sub-address transmission mode includes deep mode and flat mode. The deep mode means that the 1553B bus sends simulation data packets in a flat manner to all sub-addresses responsible for receiving data under the remote terminal. The flat mode means that the 1553B bus sends all data packets to a sub-address responsible for receiving data under the remote terminal. The 1553B hardware protocol is applied to the bus controller and remote terminal working modes in the 1553B bus system. Two 1553B hardware models are generated in the simulation project. The two 1553B hardware models are deployed in the programs of the bus controller and remote terminal device respectively. When the 1553B hardware protocol is created, the platform configuration subsystem program will persist the data of the protocol attributes in the database, and the FMI joint simulation system will send a request to the platform server subsystem program to obtain the 1553B hardware protocol. While parsing the request, the platform server subsystem program will generate two 1553B hardware models with the same attribute values ​​in the simulation project, namely the bus controller model and the remote terminal model. Each model contains the IP and port of the target device for data transmission, where the bus controller model corresponds to the bus control device and the remote terminal model corresponds to the remote terminal device. When the simulation project is started, the bus control device program will send the simulation data generated by the FMU module to the specified remote terminal according to the 1553B hardware protocol attributes encapsulated in the bus controller model. Data transmission is realized by the 1553B bus. After receiving the simulation data, the remote terminal model deployed at the remote terminal sends the data back to the FMU module, forming a closed loop for the entire transmission process.

2. The cyber-physical testing system containing a universal interface module according to claim 1, characterized in that: The configuration of the 1553B hardware protocol includes: The ko.observable function is used to monitor the attribute value of each 1553B hardware protocol entered in the configuration page, and the ko.observableArray function is used to monitor each option in the drop-down list to achieve real-time dynamic binding of attribute values. Use a for loop to assign attribute values ​​to the drop-down boxes of the remote terminal and remote terminal sub-address, and select the corresponding address parameters through the configuration page; Call the validation function to verify the input attribute value and get the verification result; The verification result is controlled by using an if statement. When the return value of the valid function is true, it means that the verification is passed. Then, the platform configuration subsystem program interface is called through the context.fetchbackun function to encapsulate all 1553B attribute values ​​monitored in ko.observable and then submit them to the background program for processing.

3. The cyber-physical testing system containing a universal interface module according to claim 1, characterized in that: The implementation of the 1553B hardware model adopts the MVC design pattern. The program structure is designed as a simulation control layer, a model data layer and a model view layer. The model control layer is responsible for processing the request interface for calling the 1553B hardware protocol data in the FMI joint simulation system, and the specific processing method is handed over to the model data layer. The model data layer encapsulates the 1553B hardware protocol data in the platform configuration subsystem, generates a 1553B hardware model and returns it to the model control layer. The model view layer is responsible for displaying the model information received in the model control layer in the simulation project.

4. The cyber-physical testing system containing a universal interface module according to claim 1, characterized in that: After the 1553B hardware model is generated, the model file data is stored in the platform configuration subsystem, and the import and export of the 1553B hardware model file can be completed through interface operations.

5. The cyber-physical testing system containing a universal interface module according to claim 4, characterized in that: Importing the 1553B hardware model file includes: The data in the HTTP request body sent by the FMI co-simulation system is received through HttpServletRequest. Since the data sent can only be determined to be in the model file format when the received data is in multi-segment format, the isMultipartContent function is called to determine whether the received data is in multi-segment format. Only when the data is in multi-segment format will it be parsed, otherwise it will not be parsed; Create a FileItemFactory factory class and generate a ServletFileUpload object. At the same time, parse the model file data through ServletFileUpload, generate multiple FileItems and save them to the List collection. Each FileItem corresponds to a model file. The collection is traversed through a for loop, and each FileItem is written to the specified path locally on the data interaction device. Subsequently, the status code is returned through the response.setStatus function to notify the FMI co-simulation system that the model file has been successfully imported.

6. The cyber-physical testing system containing a universal interface module according to claim 4, characterized in that: The export of 1553B hardware model files includes: Step 1: During the data interaction process of the export function, the FMI co-simulation system sends the model file name to be obtained to the data interaction device through the interface. The getUrlPath function receives the request and obtains the file name. Step 2: Encapsulate the 1553B hardware model into the InputStream input stream through the servletContext.getResourceAsStream function; Step 3: Create an output stream OutputStream, call the IOUtils.copy function to copy the 1553B hardware model data cached in the InputStream in step 2 to the OutputStream, and return it to the FMI co-simulation system through the response body of the HTTP protocol; Step 4: Based on step 3, the value of the Content-Disposition attribute in the HTTP protocol response header is set to attement through the response.setHeader function, so that the FMI joint simulation system can download and use the response data after receiving it.

Images