Cyber-Physical Test Protocol Processing System and Method

Abstract

The present invention discloses a cyber-physical testing method, which includes the following steps: parsing a configuration file: parsing protocol attributes, parsing the root node name, packet searching method, and byte order; traversing data types, traversing all data types, and saving all types in a type container; starting from the root node, constructing a protocol tree. Starting from the root node, traverse the data included in the root node in sequence. If the included data is a basic type, directly construct a leaf node; if the included data is a packet type, then use the packet as the root node of the subtree and construct the subtree of the packet. The present invention solves problems such as differentiation, incompatibility, and configuration redundancy in the process of data interaction and processing.

Description

Technical Field

[0001] The present invention relates to an information system, and in particular to a cyber-physical test protocol processing system and method. Background Art

[0002] When a system involves multiple physically independent subsystems, data needs to be transferred between the subsystems. The data formats between the subsystems are often uniformly designed during system design according to different business scenarios. After the data format is designed, each subsystem separately writes the sending and receiving programs for this data format, thereby completing the communication between the subsystems. The drawback of this is that once the business scenario changes, the data format also has to change accordingly; once the data format changes, the data processing program also has to be rewritten.

[0003] A cyber-physical test system has to face hundreds or thousands of test devices. These test devices are of various types, and most of the data formats have been defined. If we want to communicate with these known devices on the market and more unknown devices in the future, it is necessary to perform specialized encoding for each data format, which will greatly waste the workload.

[0004] Current industry solutions: Currently, for similar problems, the main idea in the industry is to abstract the communication protocol, abstract the data format into general concepts such as integers, floating-point numbers, strings, containers, etc. The user configures the data format through a configuration file, and then a unified program parses the configuration file, which can save some development workload. The user only needs to write the code for this interface. A typical product is protobuf open-sourced by Google.

[0005] Problems of the current solution: Both the sender and receiver need to use the same middleware for data transfer; most of the products connected to the cyber-physical test system are independent products. The design and development of these products are not under our control. It is unrealistic to require these products to be specifically developed with the designated middleware for connection to our system; users still need to write code for business scenarios; in the current solution, only the encapsulation and transmission of data are abstracted, and different business scenarios still need to be specifically developed in the code, and zero-code connection cannot be achieved; data cannot be finely operated bit by bit. In the current solution, the definition of the data format only reaches the byte level, and bit-level control cannot be achieved. For devices connected to the cyber-physical system, in order to compress the data volume, the data format is usually designed to the bit level. Byte order cannot be flexibly controlled. In the current solution, local data uses the local byte order, the network byte order is used during transmission, and the data is converted back to the local byte order after reception. However, in some extremely special business scenarios (possibly design defects), different byte orders exist in the data, and this situation cannot be supported by the current solution. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to overcome the above-mentioned defects existing in the prior art and provide a cyber-physical test protocol processing system and method.

[0007] A cyber-physical test system includes an FMU (Functional Model Unit) model, a visual programming module, a terminal system simulation module, a parameter and fault injection module, a data analysis and status display module, and a use case automated test module.

[0008] A cyber-physical test method is characterized by including the following steps: Parsing the configuration file: parsing the protocol attributes, parsing the root node name, packet searching method, and byte order; traversing the data types, traversing all data types, and storing all types in a type container; traversing the packets, traversing all data types, and storing all types in a packet container; traversing the unions, traversing all data types, and storing all types in a union container; starting from the root node, constructing a protocol tree. Starting from the root node, sequentially traverse the data included in the root node. If the included data is a basic type, directly construct a leaf node; if the included data is a packet type, then use the packet as the root node of the subtree and construct the subtree of the packet.

[0009] A method for receiving data in a cyber-physical test system, comprising the following steps: packet searching, searching for packets through a specific packet header; determining the starting position, length, and data type of each field of the current data; filling data, using the pre-constructed protocol tree, traversing each leaf node sequentially from the root node. When the leaf node is basic data, since the starting position, length, and data type of each field have been determined, the corresponding value can be directly obtained from the data stream and saved in the node. When the leaf node is a packet (sub-tree), traverse this sub-tree recursively; providing an interface for reading data. Each basic data in the protocol has a unique ID. Use a dedicated container to store the correspondence between the IDs and names of these data. When obtaining the data of a certain field, convert it to the corresponding ID according to the name, and then search for the corresponding data in the container and return it to the calling program.

[0010] A method for sending data in a cyber-physical test system, comprising the following steps: filling data, the user fills each field in the protocol according to business needs. Since the protocol tree has been generated, the data can be directly written into the corresponding leaf node when filling data; determining the starting position, length, and data type of each field of the current data; checking data integrity. When sending data, all basic data must be filled before a complete protocol data can be formed. If there is a default value and the field has not been filled, fill the default value; fixed value, if it is a fixed value, fill the fixed value regardless of whether the field has been filled; checking data correctness, checking whether all fields meet the maximum and minimum value limits. Generating a data stream, traversing each leaf node of the protocol tree. If it is basic data, fill it into the binary stream.

[0011] The beneficial effects of the present invention are as follows: Analyze the data interaction and data processing modules of the cyber-physical test system. Studied five aspects including the data interaction process, protocol call process, protocol database, communication cycle, and protocol structure design, and discussed and explained several key nodes in the protocol design process.

[0012] According to the requirements of the data interaction and data processing parts of the cyber-physical test system, by constructing a protocol model, the data interaction and processing process is standardized into the design and configuration of packet building and unpacking. Through this method, problems such as differentiation, incompatibility, and configuration redundancy in the data interaction and processing process are solved. At the same time, in the programming design process, a modular and interfaced design method is adopted, enabling the protocol design and application process to reference various protocol templates and supporting local modification functions to achieve the function of protocol reuse in test tasks, thereby improving the simulation efficiency. In the structure and design of data interaction and data processing, what is presented to the system user by the network page is the construction and application of the protocol, and the internal details are encapsulated. The model is applied in a visual programming manner, and the protocol model is applied to the test task through port connection. The specific implementation method is not specifically displayed, improving the user-friendliness for the staff. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is a schematic diagram of the system structure of the present invention; Figure 2 is a data interaction flowchart of the present invention; Figure 3 is a protocol call flowchart of the present invention; Figure 4 is a data parsing flowchart of the present invention; Figure 5 is a protocol structure diagram of the present invention; Figure 6 is a data processing timing diagram of the present invention; Figure 7 is a received data flowchart of the present invention; Figure 8 is a transmitted data flowchart of the present invention; Figure 9 is a protocol function diagram of the present invention; Figure 10 is a UI page diagram of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0014] To make the above objects, features, and advantages of the present invention more obvious and understandable, the following detailed description of the specific embodiments of the present invention is made in conjunction with the accompanying drawings, so that the above and other objects, features, and advantages of the present invention will be clearer. The same reference numerals indicate the same parts in all the drawings. The drawings are not deliberately drawn to scale, and the focus is on showing the gist of the present invention.

[0015] See Figure 1 , the cyber-physical test system can generally be divided into six parts: the creation of the FMU (Functional Model Unit) model, the visual programming task design, the terminal system simulation operation, the parameter and fault injection, the data analysis and status display, and the use case automated testing. Each process performs its own duties and is closely connected in sequence.

[0016] First, the FMU model is constructed for various devices and subsystem variables involved in the system. The model construction also includes two parts: hardware configuration modeling of the tested components and data transmission format configuration modeling. The FMU model relies on a third-party simulation modeling platform (such as Dymola, Jmodelica, Simulink and other software) to create a device model, and its model interface is based on FMI. The generated FMU file is added to the platform in the model management interface of the platform, and a fixed icon is generated to facilitate visual programming. At the same time, it is added to the model database for easy terminal call at any time.

[0017] Secondly, the simulation task is visually programmed, and other models associated with the hardware and environmental simulation models are built on the simulation design platform in the form of software. The simulation platform where the software under test is located is connected to the virtual test control software through resource loading. After the model under test and other related models are imported, they are connected to the input / output ports according to the actual connection relationship, and the initial parameters and simulation configuration of each test model are set, so that many models are integrated into a complete test system.

[0018] The construction and design of the platform belongs to a distributed semi-physical simulation system. When registering each simulation task, you need to select a terminal simulation resource. It can be understood that each simulation resource is an independent computer with complete hardware and software resources, thus realizing a distributed computer simulation system. Every time the terminal is started, the SimuMaster program starts running and monitors the task information. When the simulation task starts, the program of each terminal will have SimuMaster pull up a specific execution program SimuSlave to initialize the simulation task and run the simulation. During the initialization process, the system will create a unique ID based on the semi-physical simulation task, and identify and save all models and connection relationships in the task.

[0019] In addition, if you need to perform operations such as parameter injection and fault injection on the simulation task during the semi-physical simulation test, you can configure the relevant parameters in the test control software. If the simulation results obtained after the test need to be visualized, you can select the required display port information and display format through the test control software, and finally the display control software will display the semi-physical simulation results.

[0020] Creating automated test cases is a crucial step in virtual test technology. Automated test cases can be generated by dedicated software, which can model complex test tasks, facilitating the modification of test tasks and retesting. First, clarify the test logic based on the simulation task, call the relevant models in the atomic library of the dedicated software to generate test cases. Then, perform data configuration for the test cases, such as defining to execute after waiting for 5 seconds, execute after judging conditions, appropriate injection values, timeout end instructions, simulation end conditions, etc., and finally generate automated test cases. They can also be saved in the database for subsequent simulation tasks.

[0021] When the test model system connection and simulation control settings on the cyber-physical simulation test control software are completed, and a considerable number of test sequences are generated by the test case software, it is possible to enter the main test link in the hardware-in-the-loop simulation test. In this link, according to the needs of the test task, operations such as pausing, continuing, parameter injection, and ending the test can be performed on the system under test. The selected port information during the test process is presented in the previously configured result display platform in the required manner. After the test is completed, the test data is automatically saved in the simulation result database and can be viewed.

[0022] Finally, if it is necessary to analyze and diagnose the test data, the test data can be transmitted to the data analysis software. The data analysis software collects useful information from the test data, and through operations such as fault diagnosis algorithms and data interpretation, it can identify, diagnose, and locate the faults of the system under test in the hardware-in-the-loop simulation test.

[0023] During the operation process, the control computer is responsible for collecting the sensing data of various devices, packetizing the data and transmitting it to the receiving system by the hardware system for unpacking. The remote control process is the opposite. The ground sends remote control instruction packetized data, which is received by the hardware system and then handed over to the control computer to unpack the instruction data and perform control according to the instruction information.

[0024] In the data interaction process, two data interaction and data processing methods of packetizing and unpacking are involved. In the present invention, these two methods are collectively referred to as protocols. First, set the data format on the simulation verification platform of the cyber-physical test system, and then during the initialization process of the hardware-in-the-loop simulation task, transmit the set simulation protocol to the terminal system, and the task attributes determine whether to packetize or unpack the data.

[0025] Figure 2This is the data interaction process. The packet assembly process involves generating packet data from simulation data and instructions and sending it to the device under test using communication methods such as 1553B and serial ports. The result data generated by the device is also transmitted back to the terminal system using the same communication method. The unpacking process is then carried out by the terminal system, which uses the unpacking protocol to send the data back to the simulation platform. The data is also transmitted to the display and control software of the platform system for data verification and analysis, and finally stored by the platform system.

[0026] The 1553B bus board, R422 interface board, network board, etc. connected to the device under test identify the data stream as binary data. The data for the semi-physical simulation process is converted and processed between binary data and service data according to the data format agreed upon by both communication parties, which is a key link in the data interaction and processing flow of the cyber-physical test system.

[0027] To address the differences, inheritance, and compatibility in data interaction between binary data and service data, the present invention adopts the method of protocol construction and reuse, defining the packet assembly and unpacking protocols in a unified standard and form to facilitate flexible and efficient description of different data formats. The creation of the data protocol acts as an interpreter in the semi-physical simulation test process. The protocols created in the protocol configuration template library will be reflected in the template library during the creation of engineering tasks. Each engineering task can choose to create a template or directly reference and modify it according to its own needs. For each task, after the protocol is introduced, the parameters can be adjusted and modified at will, and then passed to the terminal system through the middleware Redis for parsing. By analyzing the data format, the data in other bases is converted into the binary language recognized by the machine and the corresponding memory space is allocated, thus completing the packet assembly and unpacking processes of data interaction and data processing in the cyber-physical test system. The protocol call process is as Figure 3 shown.

[0028] The definition of the data format is achieved through the invocation of the protocol configuration library file, aiming to reduce the coupling between protocol configuration and other platforms as well as each test task. It abandons the drawback of the "one-to-one" communication between the data format and the encoding and translation software. The modification of the data format does not lead to the iteration or maintenance of the encoding and translation software. It can handle various semi-physical simulation test tasks, with strong applicability and good generality. At the same time, based on the achievements of modern information technology, a high-performance computer is used to solve the problem of the reduced execution efficiency and extended execution time of the simulation task caused by protocol parsing during each simulation initialization process through its powerful computing and data processing capabilities.

[0029] The protocol storage database is divided into two categories. One is the template database, and the other is all the protocols involved in each task. The two are in a replication relationship and are both stored in the MySQL database. Such a design ensures that the changes to the protocols in each individual task will not affect other tasks or the template, reducing the irreversible destruction of engineering tasks caused by human errors. At the same time, it will not be affected by the upgrade and change of the protocol data attributes in the model library for the tasks that have been created. Each part is clearly hierarchical, interrelated but not affecting each other.

[0030] The protocol configuration process is as Figure 4 shown. After the protocol configuration is completed, the Key-Value key-value pairs are determined according to the page information and transmitted to the terminal system through the Redis channel. Redis publish / subscribe (pub / sub) is a message communication mode: the sender (pub) sends messages, and the subscriber (sub) receives messages. Redis clients can subscribe to any number of channels.

[0031] With the assistance of the data subscription server Redis and the database server MySQL, the platform operation control system can be responsible for data reception, processing, forwarding, and device management, respond to the processing operations of the protocol data by the total control operation console, and store and broadcast the mapping relationships of the FMU model, protocol model, and hardware model interfaces in the design drawing.

[0032] Generally, in the data format, "Frame" is used as the basic unit, but in the research of this invention, the data of the cyber-physical test system is uniformly defined as "Packet". As the data unit in the TCP / IP protocol communication transmission, it is generally also called "data packet". In the cyber-physical test system, data can be transmitted not only using the local area network protocol but also through a wired connection between systems and using other data communication protocols. Therefore, in order to unify the concept of data interaction in this article and retain the original set format of the data, the distinction between "packet" and "frame" will no longer be made in the protocol. The structural characteristics of both will be abstracted into the packet structure and fields in the protocol attribute settings.

[0033] Secondly, whether it is the transmission frame main header, transmission frame data field, or other parts of the transmission frame

[23] , its essence is data, but only the data content and protocol packet structure are different. Therefore, in the process of constructing the protocol model (packet), the unified standard design and implementation are mainly completed for the data type and data structure.

[0034] The design of data types mainly comes from various types of data existing in the leading header and data fields of the data, which can be divided into common data types and special data types. Among them, the common data types are defined as 8 basic data types in the present invention, and the special data types are defined as custom data types in the present invention. Through the instantiation definition of basic data types and the abstraction configuration of custom data types, such a design scheme can meet the requirements of various types of data for data interaction and data processing module analysis.

[0035] From the analysis of the actual data packet format, it can also be found that the essence of the data format is the arrangement and combination of data of different sizes. We can abstract the data format and divide it into root packet, packet header, packet length, data, sub-packet, and checksum. The basic structure of the protocol is as Figure 5 shown.

[0036] Among them, the root packet is the root node of the protocol model, and there is one and only one, which serves as the identification entry during the data processing process. By instantiating each part, a data communication protocol is formed, or rather, a brand-new custom data format. From a programming perspective, it is equivalent to that the root packet, packet header, packet length, data, sub-packet, and checksum are classes, and the created ones are objects. The overall packet is a large struct (custom structure).

[0037] For basic data types, the type that only stores a single data is defined as the basic type. It includes: integers (1 / 2 / 4 / 8 bytes, divided into signed and unsigned), floating-point numbers (float, double), booleans, strings, binary buffers; basic data, the data of the basic type is defined as basic data; a packet is a collection of multiple types of data, which includes basic data, "packet" type data, and "union" type data. The entire protocol can be regarded as a packet. The root node is always a packet.

[0038] As Figure 5 shown, the entire protocol is constructed into a tree. The root node is virtual and represents the start part of the data. The sub-nodes are the respective data fields included in the protocol. The sub-node may be a basic data or a packet. Calculate the starting point and length of all current data fields. Read and write the field according to the starting point, length, and data type of the data field.

[0039] Regarding the execution process of the hardware-in-the-loop simulation task for the cyber-physical test system, how to coordinate the data interaction paces of the FMU model, protocol model, and hardware model is also a key part of the design. The strategy adopted here is that the simulation step size of the simulation task is determined according to the communication step size of each FMU and remains unchanged after the simulation task starts. The transmission of hardware data is not specifically regulated at the software level and is determined by the baud rate of the hardware communication interface. During the data caching process, as much data as comes in is processed and cached. When there are two data packets transmitted during the FMU reading cycle, the previous data packet is discarded and only the data packet closest to the time node is read. The timing design for unpacking the data of the hardware board interface connected to the device and the data of the FMU model is as Figure 6 shown.

[0040] Parse the configuration file: Parse the protocol attributes, parse the root node name, packet search method, and byte order; traverse the data types, traverse all data types, and save all types in the type container; traverse the packets, traverse all data types, and save all types in the packet container; traverse the unions, traverse all data types, and save all types in the union container; starting from the root node, construct the protocol tree. Starting from the root node, traverse the data contained in the root node in sequence. If the contained data is a basic type, directly construct a leaf node (the type information is obtained from the type container); if the contained data is a packet type, then use the packet as the root node of the subtree and construct the subtree of the packet (recursive idea).

[0041] Receive data, as Figure 7 shown. Search for packets. The data sent from the third-party device may be continuous or discrete. If it is discrete, it is relatively easy to handle, and each received data is a complete copy. If it is continuous, then a piece of data may be received in several parts; the received data may contain the second half of the previous data or the first half of the new data, so additional processing is required. When the data is sent continuously, the user needs to configure how to search for packets. There are the following methods: Distinguish by a specific packet header. Each piece of data contains a special piece of data at the beginning, called the "packet header". The third-party device ensures that no data other than the data part of the packet will contain data that duplicates the packet header. In this way, by scanning the data and finding two packet headers, the part between the two packet headers is the data part of the packet. Mark the length of the packet in a specified field. The user can also indicate the length of the packet in a certain field of the packet. After receiving the data of the corresponding length, we consider that the complete data has been received. If the length specified in this reception is not reached, then this section of data will be saved. When new data reaches the specified length during the next reception, then it will be combined with the saved data to form a complete piece of data. Distinguish by the packet header and length. The present invention is a combination of the above two methods, which specifies both the packet header content and the length of the data.

[0042] Determine the starting position, length, and data type of each field of the current data.

[0043] Fill in the data. Use the constructed protocol tree to traverse each leaf node in sequence from the root node. When the leaf node is basic data, since the starting position, length, and data type of each field have been determined, then directly obtain the corresponding value from the data stream and save it in the node; when the leaf node is a packet (subtree), recursively traverse this subtree.

[0044] Provide an interface for reading data. Each basic data in the protocol has a unique ID. We use a special container to store the correspondence between the IDs and names of these data. When obtaining the data of a certain field, convert it to the corresponding ID according to the name, and then look up the corresponding data in the container and return it to the calling program.

[0045] Send data, such as Figure 8 As shown, fill in the data. According to business needs, the user fills in each field in the protocol. Since the protocol tree has been generated, directly write the data into the corresponding leaf node when filling in the data.

[0046] Determine the starting position, length, and data type of each field of the current data.

[0047] Check data integrity. When sending data, all basic data must be filled in completely to form complete protocol data. There are two exceptions: default value. If there is a default value and the field has not been filled, then fill in the default value; fixed value. If it is a fixed value, regardless of whether the field has been filled, fill in the fixed value.

[0048] Check data correctness. Check whether all fields meet the maximum and minimum value limits.

[0049] Generate a data stream. Traverse each leaf node of the protocol tree. If it is basic data, then fill it into the binary stream.

[0050] During the research process of data interaction and data processing in the cyber-physical test system, the main development and design tasks involved include the following points.

[0051] (1) Design the protocol model structure: mainly divided into root packet (root node), sub-packets, data, etc.;

[0052] (2) Design protocol fields: BaseType, RootPackage, Package, Formula, etc.;

[0053] (3) Determine basic data types: int, float, double, etc. and custom data types such as fixed buffer and terminal;

[0054] (4) Analyze page requirements and design page functions;

[0055] (5) Analyze terminal requirements and write terminal code.

[0056] According to the main development tasks, the functional design scheme of the data interaction and data processing modules in the cyber-physical test system is determined. In the functional design of the platform page, a three-column vertical module design method is adopted. The three modules are on the same page to facilitate reducing the hierarchy, easy viewing and display, and at the same time facilitate the staff to construct a protocol list. The protocol function design is as Figure 9 shown.

[0057] The design requirements of the main functions in the protocol list of the platform are divided into three parts. The first part is to be able to create protocol folders in the protocol list, and the same type of protocols can be classified and sorted. For data types, it is generally divided into two parts, one is the basic type and the other is the custom type.

[0058] The second part is to add protocol objects during the protocol configuration design to achieve specific data functions. It includes a protocol number, which is used as the identity ID of the protocol object and can be quickly retrieved and viewed in the database. It also includes information such as protocol name, protocol type, creator, creation time, update time, and relevant description. The protocol name needs to be filled in by the user himself to facilitate the addition, deletion, modification, and query on the platform. The protocol type will be selected from the classification summary of the created protocol list. The relevant description, as an optional item, is also filled in by the user himself, while the creator, creation time, and update time are filled in by the system. At the same time, in order to avoid the protocol being too complex, an expandable and collapsible function is designed.

[0059] The third part considers the scenario of cross-platform application of the protocol. To meet the requirement of protocol reuse, the import and export functions of the protocol are designed, which also includes viewing, verifying, and saving the generated JSON protocol for the configuration.

[0060] The protocol page also includes the design of other small functions, including the functions of adding, deleting, modifying, and querying protocol folders at all levels and the protocol itself, the functions of adding, deleting, modifying, and querying other data types that do not include basic data types in the data type, and the functions of adding, deleting, modifying, and querying various parts of data, sub-packages, formulas, packet headers, packet lengths, checksums, etc. in the protocol package.

[0061] The structural design of the protocol generally includes two parts: packet assembly design and packet disassembly design. Combining the specific requirements of the cyber-physical test platform, in the process of structural design of packet assembly and disassembly in this paper, they are unified into a set of design schemes, that is, the protocol is configured once to generate a packet assembly model and a packet disassembly model respectively. Its data port has one more enable port as a model switch in the packet assembly model, and the other ports are the same. The main packet, that is, the design of the header layer packet, is the root packet, which determines the packet searching method, whether there is a packet header, packet length, and checksum of the data in the cyber-physical test system. Other types also include ordinary packets and data. It should be noted that the packet header, packet length, and checksum cannot be directly deleted from the packet structure, and only whether they exist in the packet structure can be selected in the settings. Other types can perform functions such as addition, deletion, modification, and query.

[0062] At the same time, the structure and function design form of the Web page of the platform play a crucial role in the usability and robustness of the data interaction and data processing modules of the cyber-physical test system. According to the project requirements of the development task, in the design process of this paper, the zTree control is selected to implement the construction of the "protocol tree". The reasons for its use mainly include the following three points.

[0063] (1) Its core code is segmented according to functions, and unnecessary code can be not loaded.

[0064] (2) It is compatible with multiple browsers such as IE, FireFox, and Chrome, and supports JSON data.

[0065] (3) It has flexible editing (add / delete / modify / query) functions, and nodes can be dragged randomly, which is convenient for adjusting the structural order of the protocol model.

[0066] The node type and node position are important factors constituting the tree-shaped data structure. Taking the addition of nodes as an example, JavaScript is used to put dynamic text into the HTML page to achieve flexible changes in page display. The pseudo-code of the specific implementation process is shown in Table 1.

[0067] Table 1 Pseudo-code for adding tree nodes

[0068]

[0069]

[0070] According to the characteristics of the data packet level in the cyber-physical test system's semi-physical simulation process, which has a hierarchical "superior-subordinate" relationship structure, associated tables are used to store information in the database, and hash tables are used for quick lookup in the terminal background. This can quickly determine the root node and clarify the attributes of each node. Therefore, the entire packet is constructed and presented in a tree topology structure, with an intuitive effect and easy to read. Defining any data type will automatically become a packet structure when adding subordinate data. Except for the packet header, packet length, and checksum, which can only be dragged at the creation level, other packet structure types can be dragged between the same level and different levels. It has clear logic in presentation and is flexible in configuration, which is a major highlight in the protocol structure design.

[0071] In the data interaction process of the present invention, it mainly includes two aspects. The platform system and the terminal system complete data interaction through various protocols, and the platform system and the user complete the data interaction process through page configuration. Based on the design characteristics of the basic platform system itself and the requirements of the data interaction UI development of the present invention, a lightweight UI type library Knockout is used as the framework for the platform protocol page, which can make the UI design more concise and improve the efficiency of code writing.

[0072] At the same time, because a large number of node DOM constructions are involved in the development of the UI interaction page, we use the jQuery UI plugin to complete the protocol configuration page of the platform system. jQuery UI is a plugin tool that can operate elements and events more conveniently. It contains many state-maintaining widgets. The widgets of jQuery UI are created based on the Widget Factory, and the widget library provides a general API.

[0073] To achieve the simplicity and usability of the data interaction page configuration, the attribute configurations of each part of the protocol are generally the same. Therefore, the development method of the UI page is relatively unified in the research of the present invention. Taking the dropdown list in the page design as an example, the pseudo-code developed using HTML language is shown in Table 2.

[0074] Table 2 Pseudo-code for UI page development

[0075]

[0076]

[0077] In this pseudocode, general formatting design and writing are used. What options points to is an array or ko.observableArray(). Knockout will convert the array elements into dropdown options. If it is ko.observableArray(), when elements are dynamically added or removed from the array, the dropdown options will immediately increase or decrease accordingly. optionsText and optionsValue are used to generate the array elements of the dropdown options. They can be JavaScript objects with multiple properties, and the property name strings are set through optionText and optionValue. value points to a specific property of the ViewModel, and the property is generally declared with ko.observable(). In this way, when a new value is selected from the dropdown menu, the value in the <option> will be updated to the ViewModel property. Once this property is modified by the program or changed due to user input, the dropdown menu will automatically switch to the <option> corresponding to the new value. optionsCaption is the default selection of the dropdown options. The position and size of the text area and text box in the page are designed through css classes, and the value input by the user is bound by knockout.

[0078] Apply the above-mentioned UI page development method to engineering practice and write UI page development code with a unified design format. The results achieved are as Figure 10 shown.

[0079] The data types applied in the protocol model are divided into two categories in this article. One category is the basic data type, which is defined by the platform system, cannot be changed, and has a high usage frequency. The other category is the custom data type, which is customized by the user according to the data format, is flexible and changeable, and can meet various types of data formats. An entry for data type setting is provided in the first column of the protocol list on the platform configuration page. According to the modular design principle and to reduce the coupling of the system program, the data type is configured and viewed through a separate small window.

[0080] The basic data types are provided in the data type, including bealoon which represents the boolean type with the unit of byte and the encoding method of int64 bits. The integer data types are int1, int2, int3, int4, with the unit of byte and the encoding method of int64 bits. The unsigned integer data types are uint1, uint2, uint3, uint4, with the unit of byte and the encoding method of uint64 bits. The single-precision data types are float1, float2, float3, float4, with the unit of byte and the encoding method of double type. The double-precision data type is double, with the unit of byte and the encoding method of double type. The long integer data type is long, with the unit of byte and the encoding method of int64 bits.

[0081] For the custom data type, the type name needs to be filled in during the setting process, and the encoding method needs to be selected, including the double-precision type double, the integer 64-bit int64, the unsigned integer 64-bit uint64, the fixed-size buffer type FixedBuffer, and the terminator type Termial. For those encoded as double, int64, and uint64 types, the unit of bit or byte (default byte) needs to be selected and the data length needs to be filled in, and the description can be filled in optionally. For the encoding type of Fixed Buffer, the unit of bit or byte (default byte) needs to be selected and the data length needs to be filled in, and the description can be filled in optionally. For the encoding type of Termial, the terminator content and the terminator length need to be filled in, and the description can be filled in optionally.

[0082] For the design of the protocol module, the encoding method represents the data memory size occupied by the data in the terminal system. Fixed Buffer is a space address with a fixed length, and the type and size of the length are filled in by the user. And Termial can be regarded as an array with a customizable terminator, which can improve the flexibility of string usage, but still follows the default string format of adding "\0" at the end inside the system.

[0083] For the default data types, for the purpose of reducing the usage difficulty and the cost of misoperation, the modification and deletion functions are not set. However, for the user-defined data types, the modification and deletion functions are essential. In the design of the data node type in the "protocol tree", the basic data types and the custom data types can be applied to meet the requirements of various types of data during the protocol construction process.

[0084] The root package is the main package of the data packet, and its hierarchical structure is at the highest level. The positioning function of the protocol packet is realized by defining core attributes such as the packet search method, the selection of big-endian and little-endian, and whether to perform verification.

[0085] In the present invention, aiming at achieving a general design and based on various data formats, four forms of packet searching methods are defined: no packet searching, packet searching by packet header, packet searching by packet header + fixed length, and packet searching by packet header + variable length. In terms of setting the packet searching method attribute of protocol packet assembly, it is realized that the packet header and packet length can exist in the packet structure or, by agreement between the two communicating parties, do not exist in the packet structure. When disassembling the protocol, the root packet is used as the basis for identifying the start and end positions of the packet. Here, the application scenarios of packet assembly and disassembly are abstracted as attributes, and the format features of data interaction and data processing are innovatively applied.

[0086] The method of no packet searching is designed with the scenario of receiving a stable and continuous segment of data. When sending data, no packet header is configured. When receiving data, the start data of the data packet is not detected, and what is received is what it is.

[0087] When searching for packets by the packet header method, a packet header agreed upon by the two communicating parties is attached during the data interaction process. The packet header is used as the start position of each packet of data to ensure that the data packet can be correctly located when receiving data discretely. Taking the EB90 packet header as an example, the valid data in the two segments of information EB90123456EB90789 and 456EB90123 is 123456 and 789456 respectively. The adopted strategy is that when the next packet header data is not detected, the half - section data is first cached without parsing, waiting for the next packet header, and the data between the two packet headers is determined as valid data.

[0088] When using the packet searching method of packet header + fixed length, two cases are designed: without a packet length field and without a packet length field. The packet length does not appear in the packet structure in a structured form. Instead, it is assumed that the two communicating parties' staff already know the packet length jointly, and only the packet length (bytes) needs to be filled in as the basis for packet searching. In the case of having a packet length field, the packet length (bytes) is filled in as the basis for packet searching, and the packet length will appear in the packet structure in a structured form. The difference between the two lies in whether the packet length itself is reflected in the packet structure and occupies a certain space, which can meet the design requirements of data configuration diversity.

[0089] When using the packet searching method of packet header + variable length, the packet length is constructed in the packet structure in a structured form, and the size of the packet length is calculated automatically according to the start and end positions of the packet length.

[0090] The big-endian and little-endian designs are to adapt to the storage and processing hardware designed and produced by different hardware manufacturers, breaking the manufacturer barriers in information interaction. Taking the C language as an example, in addition to the char with one byte (8 bits), there is also the short with two bytes (16 bits), or the long with four bytes (32 bits) (which may vary under different compilers). For 16-bit or 32-bit processors, that is, processors with a width greater than 8 bits, since the register width is greater than one byte, there is a problem of how to store the data of a multi-byte variable. Therefore, there are big-endian and little-endian distinctions. Big-endian and little-endian refer to the storage order of data in memory. In the little-endian mode, the high byte of the data is stored at the high address. In the big-endian mode, the high byte of the data is stored at the low address.

[0091] Verification provides a way to check whether data is lost or in error during data interaction. During data interaction, it is determined by the user himself whether to use it and what verification algorithm to use according to the current task requirements. In protocol construction, the root packet serves as the root node. Its attribute selection can define the overall packet search method and the big-endian or little-endian selection of the overall interaction data. The verification method is the same as other packet attributes. The UI development of the packet header can apply the configuration parameters involved to the semi-physical simulation process.

[0092] In the attribute configuration of the packet header, there are type, length (bytes), position (bytes), and content. The type is divided into hexadecimal and ASCII forms. Although they are different in the input display process, when actually sent to the terminal, the data is sent in hexadecimal form. The length (bytes) refers to the space size occupied by the packet header in the packet structure. The position (bytes) refers to the size of the position of the packet header from the starting position of the packet structure, with a default value of 0. The content is the specific value of the packet header, such as EB90. The UI development result of the packet header attributes can be applied to the configuration of various packet header attributes, and can apply the configuration parameters of type, length, position, and content to the semi-physical simulation process, facilitating the search and assembly of packet data during data interaction and data processing.

[0093] When the packet length exists in the packet structure, attribute configuration can be performed on it, which is divided into display attributes and configuration attributes. The display attributes are the attribute configurations during the root packet design process, including whether it is a fixed packet length and whether there is a packet length field, which cannot be changed in the packet length attribute design. The configuration attributes include the packet length field length (bytes), the start field of the packet length, and the end field of the packet length. The packet length field is the space size occupied by the packet length itself in the packet structure. The selection of the start and end fields of the packet length can flexibly control the calculation range of the packet length.

[0094] One particularly important aspect in the design of the packet length attribute is how the packet length is automatically calculated. When selecting, the start field of the upper packet length and the end field of the packet length should be data that is definitely present, and this will filter out relevant options in the UI design. The UI development of the packet length attribute is applicable to the root packet node and other ordinary packet nodes. The parameter selection of the packet length position and the automatic calculation of the packet length can not only apply relevant parameters to the semi-physical simulation results, but also improve the simulation efficiency of the staff.

[0095] Verification is the inspection of the data transmitted in the data packet, used to determine whether there is data loss, duplication or error. The strategy adopted when data problems are found is to discard the packet and retransmit it. The verification methods used in the present invention include CRC-16, CRC-32 and XOR verification. In addition, the length (in bytes) of the verification field needs to be designed to occupy a certain space in the packet structure, so as to store the verification result and facilitate data verification and comparison. The selection of the start field and the end field of the verification is the same as the strategy for selecting the packet length range. At the start of the verification operation, the packet structure has unique certainty.

[0096] The verification algorithms involved in the present invention are as follows:

[0097] CRC, called cyclic redundancy check, establishes an agreed relationship between data bits and check bits by using the principles of division and remainder, and is a calculation method for verifying the accuracy of information transmission in data interaction. For the party that groups the data, the check formula of CRC will be used in the process of data interaction.

[0098] CRC-16 and CRC-32 are not essentially different. The main difference lies in the algorithms as shown in 3-1 and 3-2:

[0099] x 16 +x 15 +x 2 +1 CRC-16(3-1)

[0100] x 32 +x 26 +x 23 +x 22 +x 16 +x 12 +x 11 +x 10 +x 8 +x 7 +x 5 +x 4 +x 2 +x + 1 CRC-32(3-2)

[0101] Calculate the check value of the information contained in the packet data within the check range, and fill the check value in the address space in the packet structure where the check is located. The party that unpacks the data calculates the unpacked data within the check range using the same formula method. If the two CRC results are inconsistent, it indicates that an error has occurred during the data interaction process. The receiving party will perform packet loss handling and request the sending party to resend the data packet.

[0102] The advantage of CRC check is that it can correct errors in the information transmission process at a high proportion, calculate the data check code in a very short time, and quickly complete the error correction process. By automatically resending data packets, the communication speed in the data interaction process of the information physical test system is greatly improved, ensuring communication efficiency and security. Since the CRC algorithm has extremely strong error detection ability and low detection cost, it is widely used in data interaction and data processing.

[0103] XOR check is a kind of exclusive OR check. It takes 8Bit data, that is, every two hexadecimal data as a calculation unit, and performs exclusive OR operation in turn until the last byte. Here we assume that the packet header is F3E2 (hexadecimal) and the data is 423A (hexadecimal). The calculation process adopted in the design of XOR check in this article is as follows.

[0104] (1) In the data packet, the packet header also exists in the packet structure in the form of data. F3, E2, 42, and 3A can be regarded as four bytes of hexadecimal data, a total of 32 bits.

[0105] (2) The first step of calculation: Perform an exclusive OR operation on the first byte (8Bit) data and the second byte (8Bit) data, and save the calculation result for iterative calculation. Here, taking the packet header data as an example, perform an exclusive OR operation on F3 and E2. The calculation process is as follows:

[0106] 1111 0011 (F3)

[0107] XOR 1110 0010 (E2)

[0108] Result: 0001 0001 (11)

[0109] (3) Perform an exclusive OR operation (iteration) on the previous calculation result and the third byte (8Bit) data again, and save the calculation result for the next iterative calculation. In this example, perform an exclusive OR operation on 11 and 42. The calculation process is as follows: 0001 0001 (11)

[0111] XOR 0100 0010 (42)

[0112] Result: 0101 0011(53)

[0113] (4) Then, by performing an exclusive OR operation (iteration) on the previous calculation result and the data of the last byte (8Bit), the correct exclusive OR check (XOR) result can be obtained. In this example, the exclusive OR operation is performed on 53 and 3A, and the calculation process is as follows: 0101 0011(53)

[0115] XOR 0011 1010(3A)

[0116] Result: 0110 1001(69)

[0117] During the packet assembly process, after determining the unique packet structure form, according to the scope of the check, the check result will be filled in the check bit in the packet structure. The length (in bytes) of the check bit is user-defined. Once overflow occurs, an exception will be thrown and the program will end. During the packet disassembly process, according to the received packet structure and the data within the check scope, the check bit is recalculated and compared with the check bit data in the packet assembly. If an error is found, the packet will be discarded and retransmitted.

[0118] The development result of the check property UI can meet the parameter selection of the check algorithm and the check position, as well as the parameter filling of the check field length. The application of its parameters plays an important role in the data processing of the semi-physical simulation process.

[0119] The design of the data attributes in the protocol model is relatively complex. In the attribute function design, according to the different data types and input types, the protocol attribute configuration design of the platform page will also change accordingly.

[0120] (1) In the node type of the data attribute design, it is a basic data type. This attribute is the default attribute for packet node identification and cannot be changed. The data type is optional and includes the user-defined data types in the data type design and the default data types in the platform.

[0121] (2) General attributes: This attribute only exists in specific data types, including integer data types such as int, uint, long, etc. with various data lengths, whether default or user-defined. When non-integer data types such as float, double, long double are selected, the general attributes will not appear. The general attributes include two attribute designs, namely endianness and bit order. In the data interaction and data processing of the cyber-physical test system, due to the involvement of distributed simulation and cross-platform interaction, the transmission order during data transmission and the storage method in memory play very important roles. The endianness is briefly described in the root packet attribute design, and a more detailed introduction will be given here.

[0122] 1) Big-Endian and Little-Endian

[0123] There are two types of endianness attributes designed, big endian or little endian. In the cyber-physical test system, what the endianness controls is essentially the byte order, which is divided into two categories: Big-Endian and Little-Endian. The standard definitions of Big-Endian and Little-Endian are as follows:

[0124] a) Little-Endian means that the low-order byte is placed at the low-address end of the memory, and the high-order byte is placed at the high-address end of the memory. During the read and send process, the little endian will read from the least significant byte bit.

[0125] b) Big-Endian means that the high-order byte is placed at the low-address end of the memory, and the low-order byte is placed at the high-address end of the memory. During the read and send process, the big endian will read from the most significant byte bit.

[0126] In the implementation process, two library functions are mainly used, namely the htonl() function and the ntohl() function. Among them, the htonl() function converts the host number into the network byte order of an unsigned long integer, and the ntohl() function converts an unsigned long integer from the network byte order to the host byte order.

[0127] Taking an example to illustrate, define an unsigned integer array unsinged char buf, and the unsigned integer data is 0x12345678, where 0x12, 0x34, 0x56, and 0x78 are each a byte. Assuming the address starts from 0x8883, its storage and transmission order is shown in Table 3:

[0128] Table 3 Schematic Diagram of Big-Endian and Little-Endian Comparison

[0129]

[0130] Although the storage methods of big endian and little endian are different, which causes the values corresponding to the array to also change, but through the movement of the pointer, the bytes can be read in the order that conforms to the normal reading order of humans - first the high bytes and then the low bytes.

[0131] If the data is stored in the order of increasing address, then the hexadecimal number 0x12345678 can be regarded as big-endian data, and it puts the four bytes into the memory from left to right. Conversely, little-endian data puts the four bytes into the memory from right to left, and the structure is as follows.

[0132] Left -------> 0x12 34 56 78 <------- Right

[0133] 2) Bit Order

[0134] The bit order is in bits, and what is concerned is the sequence order between bits within a byte. Taking the binary 01110101 as an example, the structure is as follows.

[0135] Left ------> 01110101 <------- Right

[0136] a): Low-order first: Within the 8-bit binary data, 10101110 is stored in sequence from right to left in the 0th to 7th bits of the 0 address unit, as shown in Table 4.

[0137] Table 4 Schematic table of low-order first

[0138]

[0139] b): High-order first: Within the 8-bit binary data, 01110101 is stored in sequence from left to right in the 0th to 7th bits of the 0 address unit, as shown in Table 5.

[0140] Table 3.5 Schematic table of high-order first

[0141]

[0142] 3) Little-endian (byte order) and bit order Simply put, the little-endian mode and high-order first always read and transfer data from right to left, while the big-endian mode and low-order first always read and transfer data from left to right. Their difference is only in whether it is in units of bytes or bits. In the attribute setting, the default is big-endian and low-order first, that is, reading and transferring data from left to right.

[0143] Integrate the configuration of the packet assembly protocol attributes and the configuration of the packet disassembly protocol attributes, and then conduct an abstract design for the functions of packet assembly and disassembly. The design of the packet assembly attributes with more configuration information is made into a sub-module in the data attribute design separately. In the protocol model of packet disassembly, the corresponding function will not be called, this part of the information will be ignored and no response will be made.

[0144] The packet assembly attributes include the selection of input types, among which hexadecimal data input or decimal data input is designed. The default attribute is decimal data input. In the selection of whether it is a fixed value, if "yes" is selected, the size of the fixed value needs to be input. At the same time, it should be noted that the strategy adopted here is that fixed-value data will not generate ports in the protocol model, which can reduce the complexity of the protocol model and improve the user-friendliness for users. The formula is used for testers to flexibly adjust the numerical value in the later stage. The recognizable range of the formula is a simple binomial, which can achieve simple data adjustment for the data x, and the adjustment form is as shown in Formula 3-3.

[0145] ax + b(3 - 3)

[0146] In the design of the platform page, when the setting of whether it is a fixed value is set to "No", it means that the data is input from the FMU output port. When there is no FMU data input, the initialized data is the default value. Certain constraints need to be imposed on the input data, so the maximum and minimum values need to be filled in to prevent uncontrollable errors from causing the program to crash.

[0147] The UI development result of the packet assembly attributes can implement the special attribute configuration that differentiates the packet assembly process from the unpacking process, including input type, fixed value, default value, maximum and minimum values, and the parameter selection and filling of the formula. In the packet assembly process of semi-physical simulation, the configuration of this parameter provides a basis for data interaction and data processing.

[0148] When the data type is selected to be data with encoding methods of FixedBuffer and Terminal, the default input type is ASCLL. In addition, a hexadecimal data input type is designed. The unit is the byte or bit set when the custom data type is used, and the length corresponds to the following padding. To improve the user experience of the staff and reduce the complexity of configuration, the same content can be cyclically filled until the maximum length.

[0149] Protocol normal packet. First, in the construction design of the normal packet, its logical strategy is to add another new data under a data node, so that the original data node will become a packet node type, and its purpose is to realize the construction of a multi-layer packet structure. Second, when the packet node type is a normal packet, there are two attributes: whether there is a packet length field and whether there is a checksum. In the design of the platform interface, if it is selected that there is a packet length field, that is, the packet length exists in the packet structure, then the length of the packet length field (bytes), the start field of the packet length, and the end field of the packet length need to be filled in. Compared with the root packet length, this packet length is not used in the packet searching process, but only for calculating and explaining the length of the sub-packet. If it is selected that there is a checksum, the design of the checksum attribute includes the selection of the checksum algorithm, the filling of the length of the checksum field (bytes), and the selection of the start field and the end field of the checksum. Compared with the root packet, the selection range of the start field and the end field of the checksum is only within this normal packet, and does not include the uniquely determined data in the upper-level and same-level packet structures.

[0150] Field design for data processing. The field design for data processing is to transmit the protocol configuration information of the platform system UI interaction page to the terminal system in the form of fields and values, which facilitates the information interaction between the two parts of the program in the information physical test system. How to define the protocol configuration information in the form of fields that are easy for the terminal system to recognize is a particularly important part. The design process of the protocol fields needs to be jointly defined by both the platform system and the terminal system, so that the platform system can generate field information that can be recognized by the terminal system in the data interaction and data processing modules. Finally, the field information will be used as an important basis for simulation data interaction.

[0151] JSON description of field information. The transmission form of the protocol configuration information is based on the field information, and choosing what data description language becomes a key step in the field design of data processing.

[0152] JSON (JavaScript Object Notation), namely JavaScript Object Notation, is used as an intermediate language for data interaction and data processing. It is transmitted in pure text form and is mostly used to store and exchange information. JSON is a relatively lightweight data interaction and data processing text format. It is similar to XML in terms of structure, but JSON has a smaller size and simpler syntax than XML, so it is faster in the process of data interaction and data processing.

[0153] Overall structure field design. After the user selects or fills in the Value, it will correspond to the designed field and be transmitted to the terminal system for processing together. For the sake of easy distinction, in this invention, the names of Key and Value are uniformly defined as field and type, and will not be elaborated further below.

[0154] Table 8 Overall structure field table

[0155]

[0156] As shown in Table 8, the BaseType field defines the default data type and custom data types, which are used as the basic data type definition and usage of the data interaction protocol. It exists in the form of an array in the entire JSON protocol and must have specific content.

[0157] The RootPackage field defines the unique attributes of the entire root package. Since its attribute types are few and the structure is single, it does not use the array type, but directly uses the Key-Value form of the object attribute feature in the JSON protocol. As the root node of the package, it must also exist and have content.

[0158] The Package field defines the attributes of all nodes in the integrated package structure. It is the logical representation of the data protocol package structure, and its type is fixed in the Json protocol in the form of an output array. It includes three inherent package attributes: packet header, packet length, and checksum, as well as the interactive data in the information physical test and the attributes of different ordinary packets (sub-packets) generated in various packet structures.

[0159] The Formula field is defined as a simple formula attribute field. In the data interaction and data processing of the information physical test system, the formula attributes that need to be filled in by the user are transmitted from the platform system to the terminal system in this field. Similarly, this field can be left blank. The field is retained but its content is empty. If it appears in the JSON protocol, it appears in the form of an array.

[0160] In addition, for the packet assembly and disassembly models generated by protocol construction, the output port in the packet assembly model is defined as inChannel, and the input port of packet disassembly is defined as outChannel. The definitions of these two ports are required not only for the input and output of the model itself, but also for search and identification by the terminal program, providing design support for data interaction and data processing.

[0161] Design of the BaseType field

[0162] Table 9 BaseType field table

[0163]

[0164]

[0165] In the BaseTyp field, four types of fields, namely name, size, len_type, and encoding, are defined through the use of an array type. Their meanings are type name, type length, unit of type length, and encoding type respectively. The four types are string, integer, string, and string. Their value ranges are shown in Table 9. The type names cannot be repeated, the type lengths are unlimited, the unit of type length provides two forms: byte and bit, and the encoding type provides choices, which is the reserved space size during data processing.

[0166] Design of the RootPackage field

[0167] Table 10 RootPackage field table

[0168]

[0169] As shown in Table 10, in the RootPackage field, the name, search_type, and endian fields are defined by the use of object types, whose meanings are the root package name, the packet search method, and the endianness respectively. The types are all of the String type, and there is no range for the values of the package name. In the packet search method, "none" means not searching for packets, "by_header" means searching for packets through the packet header, "by_header_fixed_len" means searching for packets through the packet header plus a fixed length, and "by_header_unfixed_len" means searching for packets through the packet header plus an unfixed length. In the endianness, there are only two Value values, one is little endian and the other is big endian.

[0170] There is also a reserved field "encode_control", whose meaning is enable. The reason for designing this field is to add the effect of an enable terminal. When the input is "0", the protocol is valid and the data interaction and data processing process continue. When the input is "1", the protocol is invalid and the data interaction and data processing process are paused and terminated.

[0171] Design of the RootPackage field

[0172] Table 11 Package field table

[0173]

[0174]

[0175] The Package field is shown in Table 11. In the design, two major categories of keywords are defined: the attr keyword and the data keyword. attr represents the package attribute settings of each level and node, and data represents the specific attribute settings of the data types in each level and node. This design scheme can retrieve each packet node and the data therein through Package, making the structure of the entire protocol packet clear and the logic clear. The keyword for retrieval is name, and the packet node and data are determined by the Key value name. This requires that the user cannot have the same name in the data name and various packet node names, otherwise an error will be reported and the program will exit. The numerical type of the attr field is an object, and the numerical type of the data field is an array. The numerical types of other fields nested in these two fields are more common Bool (Boolean), String (string), and Integer (integer).

[0176] The present invention first designs and explains the overall structure of data interaction and data processing from two aspects: functional design and protocol structure. Then it introduces the development method of the relevant UI pages, and elaborates on the design reasons and ideas for the key attributes such as data types, root packages, packet headers, packet lengths, checksums, data, and ordinary packets during the protocol construction process. And through the implementation of the UI development code, the UI development results of each part of the attributes in the protocol configuration are obtained, which can correspond to the protocol design, and thus the protocol construction and configuration work can be completed through the UI page.

[0177] The configuration information related to the protocol is described in JSON language and sent to the terminal simulation execution program. The design of the fields corresponds to the Keys in the JSON data format, and the values of the fields are equivalent to the Values in the JSON data format. Finally, the functions and roles of the fields required for converting the protocol into the JSON data format are described in detail, laying a solid foundation framework for the research on data interaction and data processing in the cyber-physical test system.

[0178] Many specific details are described above 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. Therefore, the present invention is not limited by the specific implementations disclosed above. At the same time, any person skilled in the art can make many possible changes and modifications to the technical solution of the present invention, or modify it into an equivalent embodiment with equivalent changes, without departing from the scope of the technical solution of the present invention. Any simple modification, equivalent change, and modification made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention still fall within the scope of protection of the technical solution of the present invention.

Claims

1. A cyber-physical test system, characterized in that, It includes FMU (Functional Mockup Unit) model, visual programming module, terminal system simulation module, parameter and fault injection module, data analysis and status display module, and use case automated testing module; The FMU (Functional Model Unit) model includes two parts: hardware configuration modeling of the tested component and data transmission format configuration modeling. The FMU model relies on a third-party simulation modeling platform to create a device model. Its model interface is based on the FMI standard. The generated FMU file is added to the platform in the platform's model management interface to generate a fixed icon. The visual programming module builds other models and environmental simulation models associated with the hardware on the simulation design platform in the form of software. The simulation platform where the software under test is located is connected to the virtual test control software through resource loading. After the model under test and other related models are imported, they are connected to the input / output ports according to the actual connection relationship, and the initial parameters and simulation configuration of each test model are set, so that many models are integrated into a complete test system. Terminal system simulation module, every time the terminal is started, the SimuMaster program starts running and monitors the task information. When the simulation task starts, each terminal program will have SimuMaster pull up a specific execution program SimuSlave to initialize the simulation task and run the simulation. During the initialization process, the system will create a unique ID according to the semi-physical simulation task, and identify and save all models and connection relationships in the task; The parameter and fault injection module performs parameter and fault injection operations on the simulation task during the physical simulation test and configures relevant parameters in the test control software; Data analysis and status display module: after testing, if the simulation results need to be visualized, the test control software can be used to select the required display port information and display format, and the display control software will finally display the semi-physical simulation results; The use case automation test module clarifies the test logic according to the simulation task, calls the relevant models of the atomic library in the special software, generates test cases, and then configures the data of the test cases, and finally generates automated test cases, which are also saved in the database for use in subsequent simulation tasks; When the test model system connection and simulation control settings on the information-physical simulation test control software are completed, and the test case software generates a considerable number of test sequences, the main test phase of the semi-physical simulation test is entered. In this phase, according to the needs of the test task, the system under test is paused, continued, parameter injected, and the test is ended. The selected and displayed port information during the test process is displayed in the required manner on the previously configured result display platform. After the test is completed, the test data is automatically saved in the simulation result database and can be viewed; If the test data needs to be analyzed and diagnosed, the test data is transferred to the data analysis software; The data analysis software collects useful information from the test data. This information is used to identify, diagnose and locate the faults of the system under test in the semi-physical simulation test through fault diagnosis algorithms and data interpretation operations. During the operation, the control computer is responsible for collecting the sensing data of various devices. After the data is packetized, it is transmitted by the hardware system to the receiving system for unpacking. The remote control process is the opposite. The ground sends the packetized data of the remote control instructions. After being received by the hardware system, it is handed over to the control computer to unpack the instruction data and perform control according to the instruction information.

2. The test system according to claim 1, wherein In the data interaction process, two data interaction and data processing methods of packetization and unpacking are involved. The packetization process involves generating packetized data from simulation data and instructions and sending it to the device to be detected using the 1553B and serial communication methods. The result data generated by the device is also transmitted to the terminal system using the same communication method. The unpacking process is that the terminal system returns the data to the simulation platform through the unpacking protocol, and the data will also be transmitted to the display and control software of the platform system for data verification analysis and finally stored by the platform system.

3. The test system according to claim 2, wherein Adopt the method of protocol construction and reuse to define the packetization and unpacking protocols in a unified standard and form, and realize the definition of data format through the call of the protocol configuration library file.

4. The test system according to claim 3, wherein In the said protocol, the root packet is the root node of the protocol model, and there is one and only one, and it serves as the identification entry in the data processing process.

5. The test system according to claim 3, characterized in that, Construct the entire protocol into a tree. The root node is virtual and represents the start part of the data. The child nodes are the respective data fields included in the protocol. The child node may be a basic data or a packet. Calculate the start point and length of all current data fields. According to the start point, length and data type of the data field, read and write the field.

6. A testing method using the cyber-physical testing system according to claim 1, characterized in that, Include the following steps: Parse the configuration file: Parse the protocol attributes, parse the root node name, packet search method and byte order; Traverse the data types, traverse all data types, and save all types in the type container; Traverse the packets, traverse all data types, and save all types in the packet container; Traverse the unions, traverse all data types, and save all types in the union container; Taking the root node as the starting point, construct the protocol tree. Starting from the root node, traverse the data included in the root node in turn. If the included data is a basic type, directly construct the leaf node; if the included data is a packet type, then take the packet as the root node of the subtree and construct the subtree of the packet.

7. A data receiving method using the cyber-physical test system according to claim 1, characterized in that, Include the following steps: Search for packets, search for packets through a specific packet header; Determine the start position, length and data type of each field of the current data; Fill in the data. Use the constructed protocol tree to traverse each leaf node in turn from the root node. When the leaf node is basic data, since the start position, length and data type of each field have been determined, directly obtain the corresponding value from the data stream and save it in the node; when the leaf node is a packet (subtree), recursively traverse this subtree; Provide an interface for reading data. Each basic data in the protocol has a unique ID. Use a special container to store the correspondence between the IDs and names of these data. When obtaining the data of a certain field, convert it to the corresponding ID according to the name, and then find the corresponding data in the container according to the ID and return it to the calling program.

8. A data sending method using the cyber-physical test system according to claim 1, characterized in that Include the following steps: Fill in the data. According to business requirements, the user fills in each field in the protocol. Since the protocol tree has been generated, when filling in the data, it can be directly written to the corresponding leaf node; Determine the starting position, length, and data type of each field of the current data; Check data integrity. When sending data, all basic data must be filled in completely to form complete protocol data. If there is a default value and the field has not been filled, fill in the default value; Fixed value. If it is a fixed value, regardless of whether the field is filled or not, fill in the fixed value; Check data correctness. Check all fields to see if they meet the maximum and minimum value restrictions; Generate a data stream. Traverse each leaf node of the protocol tree. If it is basic data, fill it into the binary stream.

Images