CN114428728A - Information physical test protocol processing system and method - Google Patents
Information physical test protocol processing system and method Download PDFInfo
- Publication number
- CN114428728A CN114428728A CN202111551927.0A CN202111551927A CN114428728A CN 114428728 A CN114428728 A CN 114428728A CN 202111551927 A CN202111551927 A CN 202111551927A CN 114428728 A CN114428728 A CN 114428728A
- Authority
- CN
- China
- Prior art keywords
- data
- packet
- test
- protocol
- simulation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3664—Environments for testing or debugging software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses an information physical testing method, which comprises the following steps: analyzing the configuration file: analyzing protocol attributes, analyzing root node names, packet searching modes and byte sequences; traversing the data types, traversing all the data types, and storing all the types in a type container; taking a root node as an initial point, constructing a protocol tree, starting from the root node, sequentially traversing data contained in the root node, and directly constructing leaf nodes if the data contained in the root node is of a basic type; if the contained data is of the packet type, the subtree of the packet is constructed with the packet as the root node of the subtree. The invention solves the problems of differentiation, incompatibility, configuration redundancy and the like in the data interaction and processing process.
Description
Technical Field
The present invention relates to information systems, and more particularly, to a system and method for processing an cyber-physical test protocol.
Background
When a system involves multiple physically independent subsystems, data transfer between the subsystems is required. The data format transmitted between subsystems is designed uniformly during system design according to different service scenes. After the data format is designed, each subsystem respectively writes a transceiving program of the data format, thereby completing the communication between the subsystems. The disadvantage is that once the service scene changes, the data format is changed correspondingly; once the data format changes, the handler for the data is also rewritten.
An cyber-physical test system is faced with hundreds of test devices. These test devices are of a wide variety and most data formats are well defined. If we want to communicate data with these known devices on the market, and more unknown devices in the future, we have to encode each data format specifically, which is a significant waste of work.
The current industry solutions are: at present, the industry mainly aims at similar problems, and the main idea is to abstract a communication protocol, abstract a required data format into general concepts such as integers, floating point numbers, character strings and containers, configure the required data format through a configuration file by a user, and then analyze the configuration file through a unified program, so that a part of development workload can be saved, the user only needs to write codes aiming at the interface, and a more typical product is a protobuf of Google open source.
Problems of the current solution: both the transmitting and receiving parties need to use the same middleware to carry out data transmission; most products interfaced with the cyber-physical test system are independent products. The design and development of these products is not under our control. It is impractical to require these products to be developed exclusively with specific middleware in order to interface with our system; the user is still required to write codes for the business scenario; in the current scheme, only data encapsulation and transmission are abstracted, different service scenes still need to be developed in a targeted manner in codes, and 0 code docking cannot be realized; the data can not be refined according to the bit, and the current scheme only defines the data format to the byte level and can not control the bit level. Devices interfacing with the cyber-physical system typically format data to a bit level in order to compress the amount of data. The byte order can not be flexibly controlled, in the current scheme, local data adopts local byte order, network byte order is adopted during transmission, and the local byte order is converted after the data is received. However, there are some very special service scenarios (which may be a design defect) where different endianness exists in the data, which cannot be supported by the current scheme.
Disclosure of Invention
The technical problem to be solved by the present invention is to overcome the above-mentioned defects in the prior art, and to provide a system and a method for processing an cyber-physical test protocol.
An information physical test system comprises 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 state display module and a use case automation test module.
An cyber-physical testing method, comprising the steps of: analyzing the configuration file: analyzing protocol attributes, root node names, packet searching modes and byte sequences; traversing the data types, traversing all the data types, and storing all the types in a type container; traversing the packet, traversing all the data types, and storing all the types in a packet container; traversing the union, traversing all data types, and storing all the types in a union container; taking a root node as an initial point, constructing a protocol tree, starting from the root node, sequentially traversing data contained in the root node, and directly constructing leaf nodes if the data contained in the root node is of a basic type; if the contained data is of the packet type, the subtree of the packet is constructed with the packet as the root node of the subtree.
A data receiving method of an information physical test system comprises the following steps: searching a packet through a specific packet header; determining the initial position, the length and the data type of each field of the current data; filling data, traversing each leaf node from a root node in sequence by using a constructed protocol tree, and directly acquiring a corresponding value from a data stream and storing the value in the node when the leaf node is basic data because the initial position, the length and the data type of each field are determined; when a leaf node is a packet (sub-tree), recursively traversing the sub-tree; providing an interface for reading data, wherein each basic data in a protocol has a unique ID, storing the corresponding relation between the IDs and the names of the data by using a special container, converting the data of a certain field into the corresponding ID according to the name when the data of the field is required to be acquired, searching the corresponding data in the container according to the ID, and returning the data to a calling program.
A data transmission method of an information physical test system comprises the following steps: filling data, wherein a user fills each field in a protocol according to service requirements, and because a protocol tree is generated, the data can be directly written into corresponding leaf nodes when being filled; determining the initial position, the length and the data type of each field of the current data; checking the integrity of data, when sending data, finishing filling all basic data to form complete protocol data, if a default value exists and the field is not filled, filling the default value; a fixed value, if the field is filled, the fixed value is filled regardless of whether the field is filled; check data correctness, check all fields, and meet the maximum and minimum limits. And generating a data stream, traversing each leaf node of the protocol tree, and filling the data stream into a binary stream if the data is basic data.
The invention has the following beneficial effects: the data interaction and data processing module analysis of the cyber-physical test system are analyzed. Five aspects of data interaction flow, protocol calling flow, protocol database, communication period, protocol structure design and the like are researched, and a plurality of key nodes in the protocol design process are discussed and explained.
According to the requirements of the data interaction and data processing part of the information physical test system, a protocol model is constructed, and the data interaction and processing process is standardized into the design and configuration of packaging and unpacking. By the method, the problems of differentiation, incompatibility, configuration redundancy and the like in the data interaction and processing process are solved. Meanwhile, a modularized and interfaced design mode is adopted in the programming design process, so that various protocol templates can be introduced in the protocol design and application process, and the local modification function is supported, so that the function of protocol multiplexing in the test task is realized, and the simulation efficiency is improved. In the structure and design of data interaction and data processing, the construction and application of a protocol are shown to a system user by a network page, and internal details are encapsulated. The model is applied in a visual programming mode, the protocol model is applied to the test task through port connection, specific display is not carried out on a specific implementation mode, and the use friendliness of workers is improved.
Drawings
FIG. 1 is a schematic diagram of the system of the present invention; FIG. 2 is a flow diagram of the data interaction of the present invention; FIG. 3 is a flow chart of protocol invocation of the present invention; FIG. 4 is a flow chart of data parsing according to the present invention; FIG. 5 is a diagram of the protocol architecture of the present invention; FIG. 6 is a timing diagram illustrating the processing of data by the present invention; FIG. 7 is a flow chart of the present invention for receiving data; FIG. 8 is a flow chart of the present invention for sending data; FIG. 9 is a functional diagram of a protocol of the present invention; FIG. 10 is a UI page diagram of the present invention.
Detailed Description
The above and other objects, features and advantages of the present invention will become more apparent from the following detailed description of the preferred embodiments of the present invention when taken in conjunction with the accompanying drawings. Like reference numerals refer to like parts throughout the drawings. The drawings are not intended to be to scale, emphasis instead being placed upon illustrating the principles of the invention.
Referring to fig. 1, the cyber-physical test system can be roughly divided into six parts, namely, creation of an FMU (functional model unit) model, visual programming task design, simulation operation of a terminal system, parameter and fault injection, data analysis and state display, and use case automation test. Each process takes its own role and is closely linked in front and back.
Firstly, FMU model construction is carried out on various devices and subsystem variables related to the system. The model construction further comprises hardware configuration modeling and data transmission format configuration modeling of the tested part. The FMU model is created by means of a third-party simulation modeling platform (such as software like Dymola, Jmodelica, Simulink and the like), and the model interface of the FMU model is based on FMI. And adding the generated FMU file into the platform in a model management interface of the platform, and generating a fixed icon so as to realize visual programming. Meanwhile, the model database is added to facilitate the terminal to call at any time.
And secondly, performing visual programming on the simulation task, constructing other models and environment simulation models associated with hardware on a simulation design platform in a software mode, and connecting the simulation platform where the software to be tested is located to the virtual test control software through resource loading. After the tested model and other related models are imported, the tested model and other related models are connected with the input/output port according to the actual connection relation, the initial parameters and the simulation configuration of each test model are set, and a plurality of models are integrated into a complete test system.
The construction and design of the platform belong to a distributed semi-physical simulation system, terminal simulation resources are required to be selected when a simulation task starts to register each time, and each simulation resource can be understood as an independent computer and has complete software and hardware resources, so that the distributed computer simulation system is realized. And when the simulation task starts, the SimuMaster program pulls up a specific executive program SimuSlave by the program of each terminal to carry out the initialization and simulation operation of the simulation task, a system can create a unique ID (identity) according to the semi-physical simulation task in the initialization process, and identifies and stores all the relationships between models and connecting lines in the task.
In addition, if the simulation task needs to be subjected to operations such as parameter injection, fault injection and the like in the semi-physical simulation test process, relevant parameters can be configured in the test control software. If the simulation result obtained after the test needs to be visually displayed, the needed display port information, the display form and the like can be selected through the test control software, and finally the semi-physical simulation result is displayed through the display control software.
Creating automated test cases is a key step in virtual testing techniques. The automatic test case can be generated through special software, a complex test task can be modeled, and the test task can be modified and retest can be performed conveniently. Firstly, a test logic is determined according to a simulation task, and a relevant model of a primitive library in special software is called to generate a test case. And then carrying out data configuration of the test case, such as defining execution after waiting for 5 seconds, execution after judging conditions, proper injection numerical values, overtime ending instructions, simulation ending conditions and the like, and finally generating the automatic test case. It may also be saved to a database for use by subsequent simulation tasks.
When the connection of the test model system on the information physical simulation test control software and the setting of the simulation control are finished, and simultaneously, a test case software generates a considerable number of test sequences, the main test link in the semi-physical simulation test can be entered. In the link, operations such as pause, continuation, parameter injection, test ending and the like can be performed on the tested system according to the requirement of the test task. The port information selected and displayed in the test process is displayed in a required mode on a previously configured result display platform. After the test is finished, the test data is automatically stored in the simulation result database and can be checked.
Finally, if the test data needs to be analyzed and diagnosed, the test data can be transmitted to the data analysis software. The data analysis software collects useful information in the test data, and the information can identify, diagnose, position and the like the faults of the tested system in the semi-physical simulation test through the operations of fault diagnosis algorithm, data interpretation and the like.
In the operation process, the control computer is responsible for collecting the sensing data of various devices, and the data is packaged and then transmitted to the receiving system by the hardware system for unpacking processing. The remote control process is opposite to the process, remote control command packet data is sent out from the ground, received by a hardware system and then sent to a control computer to unpack the command data, and the control is carried out according to the command information.
Two data interaction and data processing modes, namely packaging and unpacking, are involved in the data interaction flow, and are collectively referred to as a protocol in the invention. Firstly, setting a data format on a simulation verification platform of an information physical test system, then transmitting a set simulation protocol to a terminal system in a semi-physical simulation task initialization process, and determining whether to package or unpack data according to task attributes.
Fig. 2 is a data interaction flow, the package process involves sending simulation data and instruction generated package data to a device to be detected in a communication mode such as 1553B and a serial port, and the result data generated by the device is transmitted to a terminal system in the same communication mode. And in the unpacking process, the terminal system returns the data to the simulation platform through an unpacking protocol. The data can also be transmitted to display and control software of the platform system for data verification and analysis and finally data storage by the platform system.
The data streams identified by the 1553B bus board card, the R422 interface board card, the network board card and the like connected with the tested device are binary data, so that the data in the semi-physical simulation process is converted and processed from the binary data and the service data according to the data format agreed by both communication parties, and the data is a key ring in the data interaction and processing flow in the information physical test system.
In order to solve the difference, inheritance and compatibility of data interaction of binary data and service data, the invention adopts a protocol construction and multiplexing mode, and defines a package and unpacking protocol in a uniform standard and form so as to describe different data formats flexibly and efficiently. The creation of the data protocol plays a role of a translation officer in the semi-physical simulation test process, the protocol created in the protocol configuration template library can be reflected in the template library in the creation of engineering tasks, and each engineering task can select to create a template or directly refer to and modify the template according to the requirement of the engineering task. For each task, after the protocol is introduced, the protocol can be randomly adjusted and modified, then the modified protocol is transmitted to a terminal system through a middleware Redis for analysis, data of other binary systems and binary languages identified by a machine are mutually converted through analysis of a data format, corresponding memory spaces are distributed, and therefore a packet unpacking process of data interaction and data processing in the information physical test system is completed, and a protocol calling flow is shown in fig. 3.
The definition of the data format is realized by calling the protocol configuration library file, the coupling of the protocol configuration with other platforms and each test task is reduced, the defect of one-to-one communication between the data format and the code translation software is overcome, the modification of the data format does not cause the iteration or maintenance of the code translation software, various semi-physical simulation test tasks can be processed, and the method is high in applicability and good in universality. Meanwhile, on the basis of the development achievement of modern information technology, the problems that the execution efficiency of simulation tasks is reduced and the execution time is prolonged due to protocol analysis in each simulation initialization process are solved by using a high-performance computer through strong computing power and data processing capacity of the high-performance computer.
The protocol storage database is divided into two types, wherein one type is a template database, and the other type is a copy relation of all protocols involved in each task and is stored in the MySQL database. The design ensures that the change of each independent task to the protocol does not influence other tasks and does not change the template, thereby reducing the irreversible engineering task damage caused by human errors. Meanwhile, the created and completed tasks are not influenced by the upgrading change of the protocol data attribute in the model library. The layers of the parts are distinct and are related to each other but do not influence each other.
As shown in fig. 4, after the protocol configuration is completed, the Key-Value Key Value pair is determined according to the page information and is transmitted to the terminal system through the Redis channel. Redis publish-subscribe (pub/sub) is a messaging mode: the sender (pub) sends a message and the subscriber (sub) receives the message. A Redis client may subscribe to any number of channels.
The platform operation control system can be responsible for receiving, processing and forwarding data and managing equipment under the assistance of a data subscription server Redis and a database server MySQL, responds to the processing operation of a master control console on protocol data, and stores and broadcasts the mapping relation of FMU (failure mode unit), protocol model and hardware model interface connection in a design drawing.
In general, a "Frame" is used as a basic unit in a data format, but in the present invention, data of an cyber-physical test system is collectively defined as a "Packet". It is used as data unit in TCP/IP protocol communication transmission, and is generally called "data packet"[22]. Besides using local area network protocol to transmit data in information physical test system, it can also implementThe systems are wired to each other and use other data communication protocols. Therefore, in order to unify the concept of data interaction and preserve the original set format of data, the distinction between the "packet" and the "frame" is not performed in the protocol, and the structural features of the two parts are abstracted and abstracted into the packet structure and the field in the protocol attribute set.
Second, whether it is the transmission frame preamble, the transmission frame data field, or other transmission frame portions[23]The essence of the protocol model (packet) is data, and only the data content and the protocol packet structure are different, so that the design and implementation of a unified standard are mainly completed aiming at the data type and the data structure in the construction process of the protocol model (packet).
The data types are designed mainly from the types of data existing in the leading header and data field of the data, and can be divided into common data types and special data types. The common data types are defined as 8 basic data types in the invention, and the special data types are defined as custom data types in the invention. By the instantiation definition of the basic data type and the abstract configuration of the custom data type, the design scheme can meet the requirements of data interaction and data processing module analysis on various types of data.
From the analysis of the actual data packet format, it can be found that the essence of the data format is to arrange and combine data of different sizes. We can abstract the data format into root packet, header, packet length, data, sub-packet and check, and the basic structure of the protocol is shown in fig. 5.
The root packet is used as a root node of the protocol model, has one and only one root node, and is used as an identification entrance in the data processing process. And then, by instantiating each part, a data communication protocol or a brand new self-defined data format is formed. Based on the programming thinking, the method is equivalent to a root packet, a packet header, a packet length, data, a sub packet and check, the object is taken out and created, the whole packet is a large struct (self-defined structure),
the basic data type defines a type for storing only a single data as a basic type. The method comprises the following steps: integers (1/2/4/8 bytes, divided into signed and unsigned), floating point numbers (float, double), boolean, string, binary Buffer; basic data, data with the type as basic type is defined as basic data; a packet, is a collection of data that includes both base data and "packet" type data, as well as "federation" type data. The whole protocol can be regarded as a packet. The root node is always a packet.
As shown in fig. 5, the entire protocol is constructed as a tree, and the root node is virtual and represents the beginning of the data. The child nodes are respectively the data fields contained in the protocol. A child node may be an underlying data or may be a packet. The starting point and length of all the current data fields are calculated. And reading and writing the data field according to the starting point, the length and the data type of the data field.
Aiming at the execution process of the semi-physical simulation task of the information physical test system, how to coordinate the data interaction pace of an FMU model, a protocol model and a hardware model is also a key ring in the design. The transmission of hardware data is not specifically regulated and controlled in a software layer, the data is processed and cached according to the baud rate of a hardware communication interface, when two data packets are transmitted in an FMU reading period, the last data packet is abandoned and read, and only the data packet closest to a time node is read. The timing sequence design for unpacking data processing between the hardware board interface connected with the device and the data of the FMU model is shown in FIG. 6.
Analyzing the configuration file: analyzing protocol attributes, root node names, packet searching modes and byte sequences; traversing the data types, traversing all the data types, and storing all the types in a type container; traversing the packet, traversing all the data types, and storing all the types in a packet container; traversing the union, traversing all data types, and storing all the types in a union container; taking a root node as an initial point, constructing a protocol tree, starting from the root node, sequentially traversing data contained in the root node, and if the contained data is a basic type, directly constructing a leaf node (type information is acquired in a type container); if the contained data is of the packet type, the subtree of the packet is constructed with the packet as the root node of the subtree (recursive idea).
The data received, as shown in fig. 7, is packet-based, and the data sent from the third party device may be continuous or discrete. If the data is discrete, the data is processed well, and each time the data is received, the data is a complete copy. If continuous, a piece of data may be received in several parts; the received data, i.e. the second half of the last data and the first half of the new data, may be included, so that additional processing is required. When data is continuously transmitted, a user needs to configure a method for finding a packet, which includes the following steps: each piece of data initially contains a special piece of data, referred to as a "header", distinguished by a specific header. The third party device ensures that the data portion other than the packet never contains data that duplicates the packet header. Thus, by scanning the data and finding out the two headers, the part of the two headers is the data part of the packet. The length of the packet is marked in the designated field, the user can also mark the length of the packet in a certain field in the packet, and the user can consider that the complete data is received after receiving the data with the corresponding length. If the receiving time does not reach the specified length, the data is stored, and when the receiving time is next time, once the new data reaches the specified length, the new data and the stored data form a complete data. By distinguishing the packet header and the length, the invention is a collection of the two modes, not only appoints the content of the packet header, but also appoints the length of the data.
And determining the starting position, the length and the data type of each field of the current data.
And filling data, and traversing each leaf node from the root node in turn by using the constructed protocol tree. When the leaf node is basic data, because the initial position, the length and the data type of each field are determined, corresponding values are directly obtained from the data stream and stored in the node; when a leaf node is a packet (subtree), the subtree is recursively traversed.
An interface for reading data is provided, and each basic data in the protocol has a unique ID. We use a special container to store the ID and name correspondence of these data. When data of a certain field is to be acquired, the data is converted into a corresponding ID according to the name, corresponding data is searched in the container according to the ID, and the data is returned to the calling program.
And sending data, as shown in fig. 8, filling data, and filling each field in the protocol by the user according to service requirements. Since the protocol tree is generated, the data is directly written into the corresponding leaf node when being filled.
And determining the starting position, the length and the data type of each field of the current data.
Checking the integrity of data, when sending data, all basic data must be filled to form complete protocol data, with two exceptions: default values, if any, and the field is not filled, the default values are filled; and if the field is a fixed value, filling the fixed value regardless of whether the field is filled.
Check data correctness, check all fields, and meet the maximum and minimum limits.
And generating a data stream, traversing each leaf node of the protocol tree, and filling the data stream into a binary stream if the data is basic data.
The main development and design tasks involved in the data interaction and data processing research process of the cyber-physical test system include the following points.
(1) Designing a protocol model structure: the method mainly comprises root packets (root nodes), sub-packets, data and the like;
(2) designing a protocol field: BaseType, RootPackage, Package, Formula, etc.;
(3) determining the basic data type: int, float, double, etc. and custom data type fixed buffer, terminal, etc.;
(4) analyzing page requirements and designing page functions;
(5) analyzing the terminal requirements and compiling terminal codes.
According to the main development task, a functional design scheme of a data interaction and data processing module in the information physical test system is determined. In the functional design of the platform page, a design mode of three columns of vertical modules is adopted, so that the three modules are on the same page, the hierarchy is reduced conveniently, the three modules are easy to view and display, meanwhile, a protocol list is convenient for a worker to construct, and the protocol functional design is shown in fig. 9.
The design requirements of the main functions in the protocol list of the platform are divided into three parts. The first part is to create a protocol folder in a protocol list, and can classify and sort the same type of protocols, and for the data type, the whole part is divided into two parts, one is a basic type and the other is a self-defined type.
The second part adds protocol objects in the design protocol configuration process to implement specific data functions. The protocol number is included, and the identity ID used as the protocol object can be quickly searched and consulted in the database. The system also comprises information such as protocol names, protocol types, creators, creation time, update time, related descriptions and the like, wherein the protocol names need to be filled by users to facilitate the addition, deletion, modification and check on the platform, the protocol types can be classified, collected and selected in a created protocol list, the related descriptions are also filled by the users as unnecessary items, and the creators, the creation time and the update time are filled by the system. And at the same time, the expansion and retraction functions are designed to avoid the protocol being too complex.
The third part considers the scene of the cross-platform application of the protocol, and designs the import and export functions of the protocol in order to meet the requirement of protocol multiplexing, wherein the import and export functions also comprise checking, verifying and storing the JSON protocol generated by configuration.
The protocol page also comprises other small function designs, wherein the small function designs comprise an add-delete check function of each level of the protocol folder and the protocol, an add-delete check function of other data types without basic data types in the data types, and an add-delete check function of each part of data, sub-packets, formulas, packet headers, packet lengths, checks and the like in the protocol packet.
The structure design of the protocol generally comprises two parts of packaging and unpacking design, and combines the specific requirements of an information physical test platform, the protocol is unified into a set of design scheme in the packaging and unpacking structure design process, namely, the protocol is configured once to respectively generate a packaging model and an unpacking model, one more enabling port of a data port of the protocol is used as a model switch in the packaging model, and the other ports are consistent. The main packet, i.e. the header packet, is designed as a root packet, and determines the packet searching mode, the presence or absence of a packet header, the packet length and the verification of the data of the physical information test system. Other types also include normal packets, data. It should be noted that the header, the length and the checksum of the packet cannot be deleted directly from the packet structure, and only whether the header, the length and the checksum exist in the packet structure can be selected in the setting, and other types can perform the functions of addition, deletion, modification and checking.
Meanwhile, the structure and function design form of the Web page of the platform play a vital role in the data interaction of the cyber-physical test system and the usability and the robustness of the data processing module. According to the project requirement of the development task, a zTree control is selected in the design process, and the protocol tree is constructed. The reasons for its use include the following three main points.
(1) The core code is divided according to the function, and unnecessary codes can not be loaded;
(2) the method is compatible with multiple browsers such as IE, FireFox, Chrome and the like, and supports JSON data;
(3) flexible editing (adding/deleting/modifying/searching) function, and can drag nodes at will, thus being convenient for adjusting the structural sequence of the protocol model.
The node type and the node position are important factors for forming a tree data structure, for example, adding the node, JavaScript is used to put dynamic text into an HTML page to realize flexible change of page display, and pseudo codes of a specific implementation process are shown in table 1.
Table 1 tree node adding pseudo code
According to the characteristics that the data packet hierarchy is clear in the semi-physical simulation process of the information physical test system and a 'top-bottom' relational structure exists, the information is stored in the database by using the association table, and the information is quickly searched by using the hash table in the terminal background, so that the root node can be quickly determined and the attribute of each node can be determined. Therefore, the whole package is constructed and displayed in a tree topology structure, the effect is visual, the reading is easy, any data type can be automatically changed into a package structure when lower-level data is added, the package head, the package length and the verification can be dragged only on a creation level, and other package structure types can be mutually dragged between the same level and different levels. The logic is clear in the exhibition, and the flexibility in configuration is a big highlight in the design of the protocol structure.
The data interaction process mainly comprises two aspects, namely, the platform system and the terminal system finish data interaction through various protocols, and the platform system and a user finish the data interaction process through page configuration. The design characteristics of the basic platform system and the requirement of the development of the data interaction UI of the invention use a lightweight UI type library Knockout as a frame of a platform protocol page, thus leading the UI design to be more concise and improving the work efficiency of code compiling.
Meanwhile, because most of node DOM constructions are involved in the development of the UI interaction page, the protocol configuration page of the platform system is completed by using the jQuery UI plug-in. The jQuery UI is a plug-in tool which can facilitate operation elements and events, and contains a plurality of widgets (widgets) for maintaining states, wherein the widgets of the jQuery UI are created based on a component library (Widget Factory), and the Widget library provides a general API.
In order to realize the simplicity and the easiness of the data interaction page configuration, the attribute configuration of each part of the protocol is also basically the same, so the development method of the UI page is more uniform in the research of the invention. Taking a drop-down list of page designs as an example, pseudo code developed using the HTML language is shown in table 2.
Table 2UI page development pseudo-code
In this pseudo code, a common formatting design and writing is used, options point to an array or ko. In the case of ko, the pull-down option is also immediately increased or decreased when the array element is dynamically added or removed. The optionsText and optionsValue are used to generate an array element of the drop-down option, which may be a JavaScript object with multiple attributes, with which attribute name strings are set. value points to a specific attribute of the ViewModel, which is typically declared in ko. Thus, when the drop-down menu selects a new value, the value in the option < option > is updated to the ViewModel attribute, and once the attribute is modified by the program or changed by user input, the drop-down menu will automatically switch to the < option > option corresponding to the new value. OptionsCaption is the default selection of the pull-down option, the position and size of the text field and the text box in the page are designed through the css class, and the value input by the user is bound by knock out.
Applying the above UI page development method to engineering practice, writing UI page development code with a uniform design format, and the implemented result is shown in fig. 10.
The data types applied in the protocol model are divided into two types, wherein one type is a basic data type which is defined by a platform system, can not be changed and has high use frequency, and the other type is a self-defined data type which is self-defined and flexible by a user according to the data format and can meet various types of data formats. And providing an entry for setting data types in a first list of protocol lists in a platform configuration page, wherein the data types are configured and viewed by a single small window according to a modular design principle and in order to reduce the coupling of system programs.
The basic data type is provided in the data type, wherein bealeon represents a Boolean type, the unit of the Boolean type is byte, and the encoding mode is int64 bit. Integer data types int1, int2, int3 and int4 are in units of bytes, and are encoded in int64 bits. The unsigned integer data types include uint1, uint2, uint3 and uint4, the unit of the unsigned integer data type is byte, and the encoding mode is uint64 bits. The single precision data types include float1, float2, float3 and float4, the unit is byte, and the coding mode is double type. The double-precision data type has double, the unit of which is byte, and the coding mode is double type. The long integer data type has long, and the unit is byte, and the encoding mode is int64 bit.
The self-defined data type needs to fill in a type name in the setting process, and an encoding mode is selected, wherein the encoding mode comprises a double-precision type double, an integer 64-bit int64, an unsigned integer 64-bit uint64, a Fixed-size Buffer type Fixed Buffer and a terminator type Termal. The unit of the required selection coded as double, int64, and agent 64 is bit or byte (default byte) and fills in the data length, and the description can be selected and filled in. The encoding type is Fixed Buffer, which needs to select the unit of bit or byte (default byte) and fill in the data length, and the description can be filled in. The encoding type is Termediate, the content and the length of a terminator need to be filled in, and the description can be optionally filled in.
For the design of the protocol module, the coding mode represents the size of the data memory occupied by the data in the terminal system. Fixed Buffer is a block of space address of Fixed length, the type and size of length being filled in by the user. While the Termediate can be regarded as an array of the self-defining terminator, so that the flexibility of using the character string can be improved, and the character string still follows the default format end of the character string to add '\ 0' inside the system.
For the default data type, modification and deletion functions are not set for the purpose of reducing the difficulty of use and the cost of misoperation. But modification and deletion functions are essential for user-defined data types. In the data node type design of the protocol tree, the basic data type and the user-defined data type can be applied to the data node type design, and the requirements on various types of data in the protocol construction process are met.
The root packet is used as a main packet of the data packet, the hierarchical structure of the root packet is in the highest level, and the positioning function of the position of the protocol packet is realized by defining a packet searching mode, selecting a large end and a small end, checking whether the core attributes are the same or not, and the like.
In the invention, aiming at realizing the universal design, based on various data formats, four forms are defined for the packet searching mode: the method comprises the following steps of searching packets without searching packets, searching packets with a packet head plus a fixed length, and searching packets with a packet head plus a non-fixed length. In the aspect of the attribute setting of the packet searching mode of the protocol packet, the fact that the packet head and the packet length can exist in the packet structure or do not exist in the packet structure through the agreement of both communication parties is realized. When the protocol is unpacked, the root packet is used as a basis for identifying the initial position and the end position of the packet. The packed and unpacked application scenes are abstracted into attributes, and format characteristics of data interaction and data processing are innovatively applied.
The method for receiving the data packets is characterized in that a packet searching mode is used for receiving a section of stable and continuous data as a design scene, a packet header is not matched when the data is sent, and the starting data of the data packets is not detected when the data is received, namely what the data is received.
The packet is searched in a packet header mode, a well agreed packet header by both communication parties is matched in the data interaction process, and the packet header is used as the starting position of each packet of data, so that the data packet can be correctly positioned when the data is discretely received. Taking the EB90 packet header as an example, effective data of two pieces of information, EB90123456EB90789 and EB90123, are 123456 and 789456. When the strategy is adopted, when the next packet header data is not detected, half data is firstly cached without being analyzed, the next packet header is waited, and the data between the two packet headers is determined to be valid data.
The packet header and the fixed length are used as packet searching modes, a non-packet-length field and a non-packet-length field are also designed, the packet length does not appear in a packet structure in a structured form, but the packet length is acquiescent that both communication workers know the packet length together, and only the packet length (byte) needs to be filled as a packet searching basis. In the case of the packet length field, the filling of the packet length (bytes) is used as a basis for packet searching, and the packet length appears in a structured form in the packet structure. The difference between the two is that whether the packet length is reflected in the packet structure or not, and the packet length occupies a certain space, so that the design requirement of configuration diversity of data can be met.
And constructing the packet length in a packet structure in a structured manner by taking the packet head and the unfixed length as packet searching modes, wherein the size of the packet length can be automatically calculated according to the initial position and the end position of the packet length.
The design of the size end is to adapt to the storage processing hardware designed and produced by different hardware manufacturers, and the manufacturer barrier of information interaction is broken. For example, in C language, besides char with one byte (8 bits), short with two bytes (16 bits), or long with four bytes (32 bits) (which may be different under different compilers), for a processor with 16 bits or 32 bits, i.e. a processor with more than 8 bits, since the width of the register is more than one byte, there is a problem how to store data of a multi-byte variable, so that the size of the register has to be divided into two[34]. The size end is meant to indicate the order in which data is stored in memory. The small-end mode stores high bytes of data in high addresses. The big-end mode stores the high byte of data in the low address.
The verification provides a verification mode for judging whether data is lost or not and whether errors exist in the data interaction process, and a user judges whether to use the data or not and what verification algorithm is used according to the current task requirement in the data interaction process. In the protocol construction, a root packet is used as a root node, the attribute selection can define an integral packet searching mode and the size end selection of integral interactive data, the verification mode is consistent with the attributes of other packets, and the UI development of the packet header can apply the related configuration parameters to the semi-physical simulation process.
The attribute configuration of the packet header includes type, length (byte), position (byte) and content, wherein the type is divided into hexadecimal form and ASCII form, and although the type is different in the input display process, when actually transmitted to the terminal, the data is transmitted in the hexadecimal form. The length (byte) refers to the space occupied by the packet header in the packet structure, the position (byte) refers to the distance from the packet header to the start position of the packet structure, the default is 0, and the content is the specific value of the packet header, such as EB 90. The UI development result of the packet header attribute can be suitable for the configuration of various attributes of the packet header, and the configuration parameters of the type, the length, the position and the content can be applied to the semi-physical simulation process, so that the assembled packet data can be conveniently searched in the data interaction and data processing processes.
When the packet length exists in the packet structure, the attribute configuration can be carried out on the packet length, wherein the attribute configuration is divided into a display attribute and a configuration attribute, the display attribute is the attribute configuration carried out in the root packet design process, and the attribute configuration is divided into whether the display attribute is a fixed packet length field or not and whether the display attribute is a packet length field or not, and the display attribute cannot be changed in the packet length attribute design. The configuration attributes include a packet length field length (bytes), a packet length real field, and a packet length end field. The packet length field is the space occupied by the packet length in the packet structure, and the selection of the initial field and the end field of the packet length can flexibly control the calculation range of the packet length.
One of the most important points in the design of the packet length attribute is how the packet length is automatically calculated. The selection of the start field of the packet length and the end field of the packet length should be data that is determined to be present, which filters out relevant options in the UI design. The development of the package length attribute UI is suitable for root package nodes and other common package nodes, the parameter selection of the package length position and the automatic calculation of the package length can be realized, the related parameters can be applied to semi-physical simulation results, and the simulation efficiency of workers can be improved.
The check is to check the data transmitted by the data packet, and is used for judging whether the data is missing, repeated or wrong, and the adopted strategy for finding the data has problems is packet loss retransmission, and the check method used in the invention comprises CRC-16, CRC-32 and XOR check. In addition, the length (byte) of the check field needs to be designed to occupy a certain space in the packet structure, so that the check result is stored, and the data verification comparison is facilitated. The selection of the start field and the end field of the check has the same strategy as the selection of the packet length range, and the packet structure has unique certainty when the check operation is started.
The verification algorithm involved in the invention is as follows:
CRC, called cyclic redundancy check, is a calculation method for checking the accuracy of information transmission in data interaction by establishing a predetermined relationship between data bits and check bits by using the principles of division and remainder. On the side of the data package, the CRC check formula is used in the data interaction process.
CRC-16, CRC-32 are not different in nature, the main difference is that the algorithms are different as shown in 3-1 and 3-2:
x16+x15+x2+1 CRC-16(3-1)
x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1 CRC-32(3-2)
and calculating the check value of the information contained in the packet data in the check range, filling the check value in the address space in the packet structure in which the check is positioned, and calculating the unpacked data in the check range by adopting the same formula method on the data unpacking side. If the two CRC results are not consistent, the two CRC results indicate that an error occurs in the data interaction process, the receiving side can perform packet loss processing, and the transmitting side is required to retransmit the data packet.
The CRC has the advantages that errors in the information transmission process can be corrected in a high proportion, the calculation of data check codes can be completed in a very short time, the error correction process can be completed quickly, the communication speed in the data interaction process of the information physical test system is greatly improved in a data packet automatic retransmission mode, and the communication efficiency and safety are guaranteed. The CRC algorithm has strong detection capability and low detection cost, so the CRC algorithm is widely used in data interaction and data processing.
The XOR check is an exclusive or check, which takes 8-Bit data, that is, data in hexadecimal of every two bits as a calculation unit, and sequentially exclusive ors until the last byte. Here we assume that the header is F3E2 (hexadecimal) and the data is 423A (hexadecimal), where the calculation procedure used herein in the design work of the exclusive-or check is as follows.
(1) In the data packet, the header is also present in the form of data in the packet structure, and F3, E2, 42, 3A can be regarded as four bytes of hexadecimal data, which is 32 bytes in total.
(2) Calculating a first step: and carrying out exclusive or operation on the first byte (8Bit) data and the second byte (8Bit) data, and storing the calculation result for iterative calculation. Taking the packet header data as an example, the xor operation is performed on F3 and E2, and the calculation process is as follows:
1111 0011(F3)
XOR 1110 0010(E2)
as a result: 00010001(11)
(3) Performing XOR operation (iteration) again on the last calculation result and the third byte (8Bit) data, and saving the calculation result again for the next iteration calculation[36]. In this example, 11 and 42 are xored, which is calculated as follows:
0001 0001(11)
XOR 0100 0010(42)
as a result: 01010011(53)
(4) Then the last calculation result is subjected to exclusive OR operation (iteration) with the last byte (8Bit) data to obtain a correct exclusive OR (XOR) result[37]. In this example 53 is xored with 3A, and the calculation is as follows:
0101 0011(53)
XOR 0011 1010(3A)
as a result: 01101001(69)
In the packaging process, after the unique package structure form is determined, the check result is filled in the check bit in the package structure according to the check range, the length (byte) of the check bit is set by a user in a self-defined mode, and once the check bit overflows, the exception is thrown out and the program is ended. In the unpacking process, according to the received data in the packet structure and the check range, the check bit is calculated again and compared with the check bit data in the packet, and if errors are found, the packet is discarded for retransmission.
The development result of the verification attribute UI can meet the requirements of parameter selection of a verification algorithm and a verification position and parameter filling of the length of a verification field, and the application of the parameters plays an important role in data processing of a semi-physical simulation process.
The design for the data attribute in the protocol model is relatively complex, and in the attribute function design, the protocol attribute configuration design of the platform page can be changed according to the difference between the data type and the input type.
(1) The node types designed by the data attributes are basic data types, and the attributes are used as default attributes identified by the package nodes and cannot be changed. The data types are selectable and comprise data types customized in data type design and data types existing in the platform by default.
(2) General attributes: the attribute exists only in a specific data type, wherein the attribute comprises integer data types such as int type, uint type and long type of various default or custom data lengths, and when non-integer data types such as float type, double type and long double type are selected, the general attribute does not appear. The general attribute comprises two attribute designs, namely a big end and a small end and a bit sequence, and in the data interaction and data processing process of the cyber-physical test system, because distributed simulation and cross-platform interaction are involved, the transmission sequence and the storage mode in a memory in the data transmission process play very important roles, wherein the big end and the small end are simply explained in the root packet attribute design and are introduced in more detail.
1) Big and small end
Two types, namely a large section or a small end, are designed in the attribute of the large end and the small end, the property controlled by the large end and the small end in the information physical test system is essentially byte order, and the byte order is divided into two types: Big-Endian and Little-Endian. The definitions of Big-Endian and Little-Endian using the standard are as follows:
a) the Little-Endian is that the low-order byte is arranged at the low address end of the memory, and the high-order byte is arranged at the high address end of the memory. During a read transaction, the small end will start reading from the least significant byte bit.
b) Big-Endian is that the high order byte is arranged at the low address end of the memory, and the low order byte is arranged at the high address end of the memory. During the read transmission, the big-end will start reading from the most significant byte bit.
Two kinds of library functions, namely an htonl () function and an ntohl () function, are mainly used in the implementation process. Where the htonl () function converts the host number into unsigned long integer network byte order and the ntohl () function converts an unsigned long integer number from network byte order to host byte order.
By way of example, an unsigned integer array unsigned character buf [4] is defined, where unsigned integer data is 0x12345678, where 0x12, 0x34, 0x56, and 0x78 are each a byte. Assume that the address starts with a 0x8883 address, which is shown in table 3 in the storage and transfer order:
TABLE 3 size-to-size ratio schematic table
Although the storage modes of the big end and the small end are different, the values corresponding to the array are changed, but byte reading, namely high byte and low byte, can be carried out according to the normal reading sequence of human beings by moving the pointer.
If the data is stored in the order of addresses from low to high, the hexadecimal number 0x12345678 can be considered as the big-end data, which puts four bytes into memory from left to right. Otherwise, the small-end data is put into the memory from right to left, and the structure is as follows.
Left 0x12345678 < - > right
2) Bit sequence
Bit order is in bits, and what is concerned is the precedence order between the bits in the byte. Taking binary 01110101 as an example, the structure is as follows.
Left 01110101-right
a) The method comprises the following steps Low position is as before: in the binary 8-Bit data, 10101110 is stored in the 0 th Bit to the 7 th Bit in the 0 th address unit from right to left in sequence, as shown in table 4.
TABLE 4 lower order preceding schematic table
b) The method comprises the following steps High-order preceding: in the binary 8-Bit data, 01110101 are stored in the 0 th Bit to the 7 th Bit in the 0 address location from left to right in order, as shown in table 5.
TABLE 3.5 high-order preceding schematic Table
3) Size end (endian) and Bit order in short, the small end mode and the high order bits always read and transfer data from right to left in front, while the large end mode and the low order bits always read and transfer data from left to right in front, which are different only in the unit of Byte or Bit. In the attribute setting, data is read and transmitted by default with the large end and the low order leading, i.e., from left to right.
The configuration of the package protocol attribute and the configuration of the unpacking protocol attribute are integrated together, so that the functions of package and unpacking are abstractly designed, the design of the package attribute with more configuration information is independently made into a submodule in data attribute design, a phase function cannot be called in an unpacking protocol model, and the information is ignored and is not reacted.
The package attributes include a selection of input types, where hexadecimal data input or decimal data input is designed, and default attributes are decimal data input. In the aspect of selecting whether the fixed value is selected, if yes, the size of the fixed value needs to be input, and meanwhile, the strategy adopted here is that the fixed value data does not generate a port in the protocol model, so that the complexity of the protocol model can be reduced, and the user friendliness is improved. The formula is used for flexibly adjusting the numerical value by later-stage testers, the recognizable range of the formula is a simple binomial formula, simple data adjustment on the data x can be realized, and the adjustment form is shown as a formula 3-3.
ax+b (3-3)
In the design of the platform page, when whether the fixed value is set to "no" means that the data is incoming from the FMU output port. When no FMU data is input, initialized data is a default value, certain constraint is required to be carried out on the input data, so that the maximum and minimum values need to be filled, and program crash caused by uncontrollable errors is prevented.
The package attribute UI development result can realize special attribute configuration that the package process is different from the unpacking process, wherein the special attribute configuration comprises parameter selection and filling of input types, fixed values, default values, maximum and minimum values and formulas, and the configuration of the parameters provides package basis for data interaction and data processing in the package process of semi-physical simulation.
When the data type is selected to be data of which the encoding modes are FixedBuffer and Terminal, the input type is defaulted to ASCLL, besides, a hexadecimal data input type is also designed, the unit is a byte or a bit set when the data type is customized, the length corresponds to the following filling, in order to improve the use experience of workers and reduce the complexity of configuration, the same content can be filled circularly until the maximum length.
And (4) protocol normal packets. Firstly, in the construction design of a common packet, the logic strategy is to add another new data under a data node, so that the original data node becomes a packet node type, and the aim is to realize the construction of a multi-layer packet structure. Secondly, when the type of the packet node is a common packet, the packet node has two attributes of a packet length field and a check attribute. If a packet length field is selected in the design of the platform interface, namely the packet length exists in the packet structure, the length (byte) of the packet length field, the initial field of the packet length and the ending field of the packet length are required to be filled. Compared with the root packet length, the packet length is not used for the packet searching process, and only the calculation of the sub-packet length is explained. If verification is selected, the design of the verification attribute comprises selection of a verification algorithm, filling of a verification field length (byte), and selection of a verification start field and a verification end field. Compared with the root packet, the selection range of the check starting field and the check ending field is only in the common packet, and unique deterministic data in upper-level and same-level packet structures are not included.
And the field design of data processing is to transmit the protocol configuration information of the UI interaction page of the platform system to a terminal system in the form of fields and numerical values, so that the information interaction of two parts of programs in the information physical testing system can be facilitated. How to define the protocol configuration information as a form of field that is easily recognized by the terminal system is a loop of which is particularly important. The design process of the protocol field needs to be defined by both a platform system and a terminal system, so that the platform system can generate field information which can be identified by the terminal system in the data interaction and data processing module, and the final field information is used as an important basis for simulating data interaction.
JSON description of field information. The transmission form of the protocol configuration information is based on the field information, and the data description language used becomes a key step of designing the data processing field. Json (JavaScript Object notification), which is a JavaScript Object representation, is an intermediate language for data interaction and data processing, and is transmitted in a plain text form, and is used for storing and exchanging information. JSON is a relatively lightweight data interaction and data processing text format, similar to XML in structural form, but is smaller in size and simpler in syntax than XML, and therefore is faster in data interaction and data processing.
And designing a field of the overall structure, wherein after the Value is selected or filled by a user, the Value corresponds to the designed field and is transmitted to a terminal system together for processing. For the convenience of distinction, the names of Key and Value in the present invention are uniformly specified as fields and types, and will not be described in detail below.
TABLE 8 Overall Structure field Table
As shown in table 8, the BaseType field defines a default data type and a custom data type, which are defined and used as basic data types of the data interaction protocol. It exists in array form in the whole JSON protocol, and specific content must exist.
The RootPackage field defines the specific attribute of the whole root packet, the attribute types are less, the structure is single, so that the type of an array is not adopted, and the object attribute characteristic Key-Value form in the JSON protocol is directly used. It must also be present and have content as the root node of the package.
The Package field defines the attributes of all nodes in the integrated Package structure, and is the logic display of the data protocol Package structure, and the type is fixed in the Json protocol in the form of an output array. The method comprises three inherent attributes of packet header, packet length and verification, interactive data in an information physical test and different common packet (sub-packet) attributes generated in various packet structures.
The Formula field is defined as a simple Formula attribute field, and in data interaction and data processing of the cyber-physical test system, the Formula attribute which needs to be filled by a user is transmitted to the terminal system in the field by the platform system. The same field may optionally be left unfilled, which is reserved but the field content is empty, which appears in the form of an array if it appears in the JSON protocol.
In addition, for the packing and unpacking model generated by the protocol construction, the output port in the packing model is defined as inChannel, and the input port for unpacking is defined as outChannel. The definition of the two ports can be searched and identified by a terminal program besides the output and input requirements of the model, and design support is provided for data interaction and data processing.
BaseType field design
TABLE 9 BaseType field Table
In the basetype field, four types of fields of name, size, lenjype and encoding are defined through the use of array types, meaning that the unit of type name, type length and encoding type are defined respectively. The four types are character string, integer, character string, respectively. The value range is shown in table 9, the type name is not repeatable, the type length is not limited, the unit value of the type length provides two forms of bytes and bits, and the coding type provides a choice, that is, the size of the reserved space in the data processing process.
RootPackage field design
Table 10 RootPackage field table
As shown in table 10, the RootPackage field defines the name, search _ type, and endian fields by the use of the object type, and the meanings are root package name, packet searching mode, and endian, respectively. The types are all String types, and the values of the packet names have no range. In the packet searching mode, a none is not used for searching a treasure, a by _ header is used for searching a packet through a packet header, a by _ header _ fixed _ len is used for searching a packet through a fixed length reinforced by the packet header, and a by _ header _ unfixed _ len is used for searching a packet through a fixed length reinforced by the packet header. The Value values in endian are only two, one is little bit and the other is big bit.
Meanwhile, a reserved field 'encode _ control' is provided, which means enabling, the field is designed because the effect of an enabling end is increased, if the input is '0', the protocol is valid, the data interaction and data processing process is continued, if the input is '1', the protocol is invalid, and the data interaction and data processing process is suspended and terminated.
RootPackage field design
TABLE 11 Package field Table
The Package field is shown in table 11, and two major types of keywords are defined in the design: attr key words and data key words, wherein attr represents the packet attribute setting of each level and node, and data represents the specific attribute setting of the data type in each level and node. According to the design scheme, each packet node and data in the packet node can be retrieved through the Package, so that the structure of the whole protocol packet is clear and the logic is clear. The searched keyword is name, and the package node and the data are determined by the Key value name, so that the condition that the user cannot have the same name in the data name and the names of various package nodes is required, and otherwise, the user can report an error to exit. The attr field value type is an object, the data field value type is an array, and the numerical value types of other fields nested in the two fields are more common Bool (Bool), String (String) and Integer (Integer).
The invention firstly designs and explains the overall structure of data interaction and data processing from the aspects of functional design and protocol structure. Then, a development method of a related UI page is introduced, and design reasons and design ideas are explained for key attributes of a protocol construction process, such as data types, root packets, packet headers, packet lengths, verification, data, common packets and the like. And the UI development result of each part of attributes in the protocol configuration is obtained through the realization of the UI development code, the UI development result and the design of the protocol can correspond to each other, and further the construction and configuration work of the protocol can be completed through a UI page.
The configuration information related to the protocol is described through JSON language and is issued to the terminal simulation executive program. The field is designed to correspond to Key in a JSON data format, the Value of the field is equivalent to Value in the JSON data format, and finally, detailed description of functions and actions is carried out on the field required by protocol conversion into the JSON data format, so that a tamping basic framework is established for data interaction and data processing research of an information physical test system.
In the previous description, numerous specific details were set forth in order to provide a thorough understanding of the present invention. The foregoing description is only a preferred embodiment of the invention, which can be embodied in many different forms than described herein, and therefore the invention is not limited to the specific embodiments disclosed above. And that those skilled in the art may, using the methods and techniques disclosed above, make numerous possible variations and modifications to the disclosed embodiments, or modify equivalents thereof, without departing from the scope of the claimed embodiments. Any simple modification, equivalent change and modification of the above embodiments according to the technical essence of the present invention are within the scope of the technical solution of the present invention.
Claims (8)
1. An information physical test system is characterized by comprising 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 state display module and a case automation test module;
the FMU (functional model unit) model comprises a hardware configuration modeling part and a data transmission format configuration modeling part of a tested part, wherein the FMU model is used for establishing a device model on a third-party simulation modeling platform, a model interface of the FMU model takes FMI as a standard, and a generated FMU file is added into the platform on a model management interface of the platform to generate a fixed icon;
the visual programming module is used for constructing other models and environment simulation models related to hardware on a simulation design platform in a software mode, connecting the simulation platform where the tested software is located to virtual test control software through resource loading, connecting the tested models and other related models to an input/output port according to an actual connection relation after the tested models and other related models are imported, setting initial parameters and simulation configuration of each test model, and integrating a plurality of models into a complete test system;
the terminal system simulation module starts to run each time a terminal is started, a SimuMaster program monitors task information, when a simulation task starts, the SimuMaster can pull up a specific execution program SimuSlave to carry out simulation task initialization and simulation running work, and in the initialization process, the system can create a unique ID according to a semi-physical simulation task and identify and store all models and connection relations in the task;
the parameter and fault injection module is used for performing operations such as parameter injection, fault injection and the like on the simulation task in the physical simulation test process and configuring related parameters in the test control software;
the data analysis and state display module is used for visually displaying the simulation result obtained after testing, selecting port information and display forms and the like to be displayed through the test control software, and finally displaying the semi-physical simulation result through the display control software;
the case automatic test module is used for determining test logic according to the simulation task, calling a relevant model of an atomic library in special software to generate a test case, then performing data configuration on the test case, and finally generating an automatic test case which can be stored in a database for a subsequent simulation task;
when the connection and the setting of the simulation control of the test model system on the information physical simulation test control software are finished, and simultaneously, the test case software generates a considerable number of test sequences, the main test link in the semi-physical simulation test can be entered, in the link, the operations of suspending, continuing, injecting parameters, ending the test and the like can be carried out on the tested system according to the requirements of test tasks, the port information selected and displayed in the test process is displayed on a previously configured result display platform in a required mode, and after the test is finished, the test data is automatically stored in a simulation result database and can be viewed.
If analytical diagnosis of the test data is required, the test data can be transmitted to the data analysis software. The data analysis software collects useful information in the test data, and the information can identify, diagnose, position and the like the faults of the tested system in the semi-physical simulation test through the operations of fault diagnosis algorithm, data interpretation and the like;
in the operation process, the control computer is responsible for collecting the sensing data of various devices, and the data is packaged and then transmitted to the receiving system by the hardware system for unpacking processing. The remote control process is opposite to the process, remote control command packet data is sent out from the ground, received by a hardware system and then sent to a control computer to unpack the command data, and the control is carried out according to the command information.
2. The test system of claim 1, wherein two data interaction and data processing modes, namely, a packaging mode and an unpacking mode, are involved in the data interaction flow, the packaging process involves sending simulation data and group data generated by a command to a detected device by using communication modes such as 1553B, a serial port and the like, and result data generated by the device is also transmitted to the terminal system by using the same communication mode; in the unpacking process, the terminal system returns the data to the simulation platform through an unpacking protocol, and the data is also transmitted to display and control software of the platform system for data verification and analysis and finally data storage by the platform system.
3. The test system of claim 2, wherein the package and unpack protocols are defined in a unified standard and form in a protocol build and multiplex manner, and the definition of the data format is implemented through invocation of a protocol configuration library file.
4. The test system of claim 3, wherein the root packets in the protocol are used as root nodes of a protocol model, and are only one and used as identification entries in the data processing process.
5. A test system according to claim 3, characterized in that the whole protocol is constructed as a tree, the root node is virtual and represents the beginning of the data, the child nodes are each data field included in the protocol, the child nodes may be a basic data or a packet, the starting point and the length of all current data fields are calculated, and the fields are read and written according to the starting point, the length and the data type of the data fields.
6. An cyber-physical testing method, comprising the steps of:
analyzing the configuration file: analyzing protocol attributes, root node names, packet searching modes and byte sequences;
traversing the data types, traversing all the data types, and storing all the types in a type container;
traversing the packet, traversing all the data types, and storing all the types in a packet container;
traversing the union, traversing all data types, and storing all the types in a union container;
taking a root node as an initial point, constructing a protocol tree, starting from the root node, sequentially traversing data contained in the root node, and directly constructing leaf nodes if the data contained in the root node is of a basic type; if the contained data is of the packet type, the subtree of the packet is constructed with the packet as the root node of the subtree.
7. A data receiving method of an information physical test system is characterized by comprising the following steps:
searching a packet through a specific packet header;
determining the initial position, the length and the data type of each field of the current data;
filling data, traversing each leaf node from a root node in sequence by using a constructed protocol tree, and directly acquiring a corresponding value from a data stream and storing the value in the node when the leaf node is basic data because the initial position, the length and the data type of each field are determined; when the leaf node is a packet (sub-tree), recursively traversing the sub-tree;
providing an interface for reading data, wherein each basic data in a protocol has a unique ID, storing the corresponding relation between the IDs and the names of the data by using a special container, converting the data of a certain field into the corresponding ID according to the name when the data of the field is required to be acquired, searching the corresponding data in the container according to the ID, and returning the data to a calling program.
8. A data transmission method of an information physical test system is characterized by comprising the following steps:
filling data, wherein a user fills each field in a protocol according to service requirements, and because a protocol tree is generated, the data can be directly written into corresponding leaf nodes when being filled;
determining the initial position, length and data type of each field of the current data
Checking the integrity of data, when sending data, filling all basic data to form complete protocol data, if default value exists and the field is not filled, filling the default value; a fixed value, if the field is filled, the fixed value is filled regardless of whether the field is filled;
check data correctness, check all fields, and meet the maximum and minimum limits.
And generating a data stream, traversing each leaf node of the protocol tree, and filling the data stream into a binary stream if the data is basic data.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111551927.0A CN114428728A (en) | 2021-12-17 | 2021-12-17 | Information physical test protocol processing system and method |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111551927.0A CN114428728A (en) | 2021-12-17 | 2021-12-17 | Information physical test protocol processing system and method |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114428728A true CN114428728A (en) | 2022-05-03 |
Family
ID=81312119
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111551927.0A Pending CN114428728A (en) | 2021-12-17 | 2021-12-17 | Information physical test protocol processing system and method |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114428728A (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115098218A (en) * | 2022-05-25 | 2022-09-23 | 西南科技大学 | Method for describing and simulating functional block model from FMU (functional modeling Unit) model to configuration software |
CN115914427A (en) * | 2022-10-24 | 2023-04-04 | 宁波义钛云软件有限公司 | Terminal protocol integration and calling method and device, computer equipment and storage medium |
CN116225967A (en) * | 2023-05-05 | 2023-06-06 | 贵州易鲸捷信息技术有限公司 | Distributed database testing method based on set enumeration tree and pruning strategy |
CN117768561A (en) * | 2024-02-22 | 2024-03-26 | 北京暖流科技有限公司 | method for automatically identifying equipment communication protocol and information acquisition system |
-
2021
- 2021-12-17 CN CN202111551927.0A patent/CN114428728A/en active Pending
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115098218A (en) * | 2022-05-25 | 2022-09-23 | 西南科技大学 | Method for describing and simulating functional block model from FMU (functional modeling Unit) model to configuration software |
CN115098218B (en) * | 2022-05-25 | 2024-03-19 | 西南科技大学 | Description and simulation method from FMU model to functional block model in configuration software |
CN115914427A (en) * | 2022-10-24 | 2023-04-04 | 宁波义钛云软件有限公司 | Terminal protocol integration and calling method and device, computer equipment and storage medium |
CN116225967A (en) * | 2023-05-05 | 2023-06-06 | 贵州易鲸捷信息技术有限公司 | Distributed database testing method based on set enumeration tree and pruning strategy |
CN116225967B (en) * | 2023-05-05 | 2023-07-07 | 贵州易鲸捷信息技术有限公司 | Distributed database testing method based on set enumeration tree and pruning strategy |
CN117768561A (en) * | 2024-02-22 | 2024-03-26 | 北京暖流科技有限公司 | method for automatically identifying equipment communication protocol and information acquisition system |
CN117768561B (en) * | 2024-02-22 | 2024-04-23 | 北京暖流科技有限公司 | Method for automatically identifying equipment communication protocol and information acquisition system |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN114428728A (en) | Information physical test protocol processing system and method | |
US11741293B2 (en) | Systems and methods of a script generation engine | |
US8838653B2 (en) | Translating an object-oriented data model to a YANG data model | |
US11868226B2 (en) | Load test framework | |
US7444619B2 (en) | Inter-process communication using different programming languages | |
Ladkin et al. | Interpreting message flow graphs | |
CN109768970B (en) | Configurable universal protocol generation method | |
EP3502896A1 (en) | Generation of an adapters configuration user interface | |
JP2000515280A (en) | Object-oriented information transmission method and apparatus | |
CN113238740A (en) | Code generation method, code generation device, storage medium, and electronic apparatus | |
CN112463256A (en) | Method, system, electronic device and storage medium for determining configuration file | |
CN101303646B (en) | Modeling method based on electric communication field capable of performing meta language | |
West | Protocol validation—principles and applications | |
US8700374B1 (en) | System and method of using an active link in a state programming environment to locate an element in a graphical programming environment | |
CN113449224A (en) | Method, device, equipment and storage medium for mapping complex data type data | |
US10606569B2 (en) | Declarative configuration elements | |
Johnsen et al. | Object-oriented specification and open distributed systems | |
CN112235316A (en) | Data communication method for instrument integration | |
Cámara et al. | Composition and Run-time Adaptation of Mismatching Behavioural Interfaces. | |
CN115328679A (en) | Automatic integration method of heterogeneous function library, computing equipment and system thereof | |
US7334015B1 (en) | Integration of legacy mainframe systems through data stream objectification into finite state machines | |
Naik et al. | Testing communication protocols | |
CN112764808A (en) | Method for performing interface communication across systems, languages and hardware components | |
US11805001B2 (en) | Managing data schema differences by path deterministic finite automata | |
Lu | On TESTGEN, an environment for protocol test sequence generation, and its application to the FDDI MAC protocol |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |