CN113225232B - Hardware testing method and device, computer equipment and storage medium - Google Patents

Detailed Description

The present invention will be described in further detail with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be further noted that, for the convenience of description, only some of the structures related to the present invention are shown in the drawings, not all of the structures.

Example one

Fig. 1 is a flowchart of a hardware testing method in a first embodiment of the present invention, where this embodiment is applicable to a situation of testing a controller, and the method may be executed by a hardware testing apparatus provided in the first embodiment of the present invention, and the apparatus may be implemented in a software and/or hardware manner, and may be generally integrated into a computer device. As shown in fig. 1, the method of this embodiment specifically includes:

s110, analyzing the test instruction message to obtain the detection type corresponding to the test instruction message.

The test command message may be information carried by an input signal received by the controller, where the controller may be a chassis domain controller. The test instruction message is used for instructing the controller to execute corresponding test operation so as to test whether the corresponding function of the controller is normal. The test instruction message is analyzed, and data included in the test instruction message can be extracted from the test instruction message according to a predefined data format of the test instruction message. Usually hardware devices are mounted on a bus, and the data carriers communicating on the bus are data frames, usually including a frame start, an arbitration segment, a control segment, a data segment, a cycle check segment, an acknowledgement segment, and a frame end. And analyzing the test instruction message, and actually extracting data of the data section from the data frame. Typically a maximum of 8 bytes are included in a data segment. One data bit represents one byte. The detection type is used to determine the task type for the controller to perform the test task, i.e., determine what type of test to perform on the hardware.

Illustratively, the test instruction message is a controller area network message in the chassis domain controller.

The test instruction message is a Controller Area Network (CAN) message. CAN is a high performance, high reliability, easy to develop, and low cost field bus for the detection and control of various processes or devices. The method can be widely applied to detection of each device in the automobile controller domain, such as detection of an automobile chassis domain controller.

And S120, inquiring and calling the matched test program according to the detection type.

The test program is used to detect one or a class of functions of the hardware device. The test program is matched with the detection type.

For example, the test programs may include an analog quantity reading program, a digital quantity reading program, a frequency quantity reading program, a digital quantity output program, an Integrated Circuit bus (I2C) reading and writing program, a Serial Peripheral Interface (SPI) reading and writing program, a CAN transceiver program, and the like. In addition, the test programs can be increased or decreased according to the needs, only the test programs need to be specified, and the matched detection types are established.

S130, obtaining the test result of the matched test program, and generating a feedback message for responding.

The test results are used to describe the test results of the hardware test, and for example, the test results may include: test normal, test failed, or invalid commands. And generating a feedback message according to the test result, wherein the feedback message has the same data structure as the test instruction message. And adding the test result to the specified data bit of the message to form a feedback message.

The embodiment of the invention determines the detection type by analyzing the test instruction message, calls the test program matched with the detection type, and feeds the test result back to the requesting party, thereby solving the problems of multiple signal types, high test difficulty and high test labor cost in the prior art, and carrying out different types of tests through message indication, improving the efficiency and accuracy, reducing the test difficulty and reducing the test labor cost.

Example two

Fig. 2a is a flowchart of a hardware testing method according to a second embodiment of the present invention, which is embodied on the basis of the above embodiments. Analyzing the test instruction message to obtain a detection type corresponding to the test instruction message, which is embodied as follows: analyzing the test instruction message to obtain data of at least one data bit of the test instruction message; in the data of each of the data bits, a detection type is determined based on the data of the designated data bit.

The method of the embodiment specifically includes:

s210, analyzing the test instruction message to obtain data of at least one data bit of the test instruction message.

The test instruction message can be analyzed according to the transmission protocol, the data section is inquired in the test instruction message, and the data of at least one data bit is obtained in the data section.

Reference may be made to the description of the embodiments above without specific recitation to embodiments of the invention.

Optionally, the analyzing the test instruction packet includes: according to a preset check rule, carrying out validity detection on the test instruction message; and when the detection result of the test instruction message is an effective result, analyzing the test instruction message.

The check rule is used for detecting whether the data of each data bit in the test instruction message is correct and complete. Illustratively, the Check rule may be a Cyclic Redundancy Check (CRC) Check rule. The validity check is used to determine whether the data of each data bit in the test command message is correct and complete. The detection result of the validity detection includes a valid result or an invalid result. The valid result shows that the data of each data bit in the test instruction message is correct and complete; the invalid result indicates that the data bits in the test instruction message are erroneous and/or incomplete. The correctness and completeness of each data bit in the test instruction message can mean that the data of each data bit in the test instruction message is consistent with the data of each data bit when the test instruction message is sent, that is, the test instruction message is not interfered in the transmission process so as to cause data loss or change; an error and/or an incomplete state of each data bit in the test instruction message may mean that the data of each data bit in the test instruction message is different from the data of each data bit in the test instruction message when the test instruction message is sent. When the detection result of the test instruction message is a valid result, it is indicated that the data of each data bit in the test instruction message is correct and complete, so that the result obtained by analysis is correct and complete.

By checking the test instruction message in advance and analyzing the test instruction message when the detection result is a valid result, a correct analysis result is obtained, the analysis accuracy is improved, and the analysis cost is reduced.

Optionally, the determining, in the data of each data bit, the detection type according to the data of the designated data bit includes: carrying out XOR logic calculation on data in other data bits except the last data bit in sequence according to bits; comparing the logic calculation result with the data of the last data bit; when the comparison result is the same result, inquiring the data of the appointed data bit in the data of each data bit; and determining the detection type according to the data of the specified data bit.

The data in the last data bit is used to verify the data of each data bit in the data segment. The other data bits are data bits except the last data bit in the data segment of the test instruction message. The sequential exclusive-or logic may be that the exclusive-or logic calculation is performed on the other data bits sequentially according to the order of each other data bit. Wherein, the XOR algorithm is as follows: exclusive OR of a and b, using the formula: and a ≦ b. If the two values of a and b are not the same, the XOR result is 1. If the values of a and b are the same, the XOR result is 0. The Byte0 is the first data bit. Byte7 is the last data bit.

The format of the data frame in the test instruction message is shown in table 1 below:

TABLE 1

Wherein the data in the leading data bit Byte0 identifies the detection type. Illustratively, the data of Byte0 is 0, and the corresponding detection type is an analog quantity reading test type; the data of the Byte0 is 1, and the corresponding detection type is a digital quantity reading test type; the data of Byte0 is 2 (e.g., 10 in 2-ary), the corresponding detection type is a frequency quantity reading test type, and other cases can be configured as required. The last bit Byte7 is used as a check bit to check whether the Byte0-Byte7 data is correct and complete. The second Byte1 is used as a signal sequence number to identify which pin the test command message is received from and/or to identify which peripheral the test command message is received from. The Byte2-Byte6 is used for carrying valid data.

Whether the calculation results of the sequential exclusive or logics of the Byte7 and the Byte0-Byte6 are the same or not is calculated based on the following formula:

Byte7？＝Byte0⊕Byte1⊕Byte2⊕Byte3⊕Byte4⊕Byte5⊕Byte6

the comparison result is used to describe whether the data of each data bit is correct and complete. The comparison results may include the same result or different results. Wherein, the same result indicates that the data of each data bit in the test instruction message is correct and complete; different results indicate data errors and/or incompleteness of data bits in the test instruction message. When the comparison result is the same, it can be shown that the data of each data bit in the test instruction message is correct and complete, and at this time, the data of the specified data bit can be queried and the detection type can be determined to obtain the correct detection type.

The method comprises the steps of carrying out XOR logic calculation on data of data bits except the last data bit in sequence according to bits in advance, comparing a logic calculation result with the last data bit, and determining a detection type according to the data of the specified data bit when the comparison result is an effective result so as to obtain a correct detection type, improve the detection accuracy of the detection type and reduce the determination cost of the detection type.

Optionally, before analyzing the test instruction packet, the method further includes: receiving an original message; detecting the original message according to a preset transmission protocol; and when the data format of the original message is the data format specified by the transmission protocol, determining the message as a test instruction message.

The original message is a message received by the local device. In fact, different types of messages may be received by the native device. The preset transmission protocol is used for screening the messages to screen out the test instruction messages, and the transmission protocol may include a data format of the test instruction messages. The data format of the original message is the data format specified by the transmission protocol, which indicates that the data format of the original message meets the data format requirement specified by the transmission protocol, so that the original message can be determined to be the test instruction message. Illustratively, the transmission protocol is the CAN transmission protocol.

By configuring the transmission protocol and detecting the original message according to the transmission protocol, the test instruction message can be quickly and accurately screened out, so that the hardware is tested according to the test instruction message, and the test accuracy and efficiency are improved.

S220, in the data of each data bit, the detection type is determined according to the data of the appointed data bit.

The data of the data bits in different orders may specify the represented function in the transport protocol. For example, one data bit, i.e., a designated data bit, may be selected from a plurality of data bits as a criterion for determining the detection type. The corresponding relation between the data in the data bits and the detection type can be established, and the detection type corresponding to the data of the specified data bits can be inquired according to the data of the specified data bits and the corresponding relation.

Optionally, the test instruction packet includes 8 data bits, and the specified data bit is a first data bit.

The test command message includes 8 data bits, each of which is a Byte. The 8 data bits are arranged according to a preset sequence, and in each data bit, the first data bit is determined as a designated data bit, wherein the data in the designated data bit is used for identifying the detection type.

By configuring the first data bit into the designated data bit in the test instruction message, the data bit for identifying the detection type can be designated quickly, so that the connection between the test instruction message and the detection type is established quickly, the detection type is determined according to the test instruction message, and the test accuracy is improved.

And S230, inquiring and calling the matched test program according to the detection type.

S240, obtaining the test result of the matched test program, and generating a feedback message for responding.

The structure of the data segment in the data frame of the feedback packet is shown in table 2:

TABLE 2

Wherein, the data in the first data bit Byte0 identifies the command response result, i.e. the test result of the test operation corresponding to the identification detection type, exemplarily, the data of Byte0 is 0, and the corresponding test result is a success result; the data of Byte0 is 1, and the corresponding test result is a failure result; the data of Byte0 is 2 (e.g., 10 in 2-ary), and the corresponding test result is an invalid result of the test instruction. The last bit Byte7 is used as a check bit to check whether the Byte0-Byte7 data is correct and complete. The second Byte1 is used as a signal sequence number to identify the test command message. The Byte2-Byte6 is used for carrying valid data.

In a specific example, the chassis domain controller hardware provided by the embodiment of the present invention is shown in fig. 2b, wherein the hardware system includes 24 analog input signals (air compressor temperature sensor, five-way valve pressure sensor, vehicle body acceleration sensor signal, Printed Circuit Board (PCB) Board temperature, high-side driving diagnosis, low-side driving diagnosis, power driving power voltage acquisition, power chip output voltage acquisition, battery voltage acquisition, compressor relay output voltage acquisition, reserved power output voltage acquisition, etc.), 10 digital input signals (key gate signal acquisition, CAN wake-up signal, CAN error signal, high-side switching value input, low-side switching value input, etc.), 32 digital output signals (five-way valve air bag valve control signal, compressor valve pressurization control signal, compressor relay control signal, etc.), 32 digital output signals (five-way valve air bag valve control signal, compressor valve pressurization control signal, compressor relay control signal, etc.), and the like, A power chip control signal, a low-side drive output enable signal, a low-side drive output control signal, a high-side drive output notification signal), 4 channels of frequency quantity input signals (vehicle height Sensor signals), 5 channels of SPI communication signals (power, solenoid valve drive, low-side drive, Electrically Erasable Programmable Read Only Memory (EEPROM), a Sensor based on a Sensor Peripheral Interface 5 (PSI 5), 1 channel of I2C signals (6-axis acceleration Sensor chip), 4 channels of CAN communication signals (chassis CAN, calibration CAN, and 2 channels of reserved CAN signals).

Actually, the hardware test provided by the embodiment of the present invention receives the CAN message through the calibration CAN communication interface, that is, the calibration CAN communication interface of the chassis domain controller is used as the communication interface of the test software. Accordingly, a structure diagram of the test software for hardware testing provided by the embodiment of the present invention is shown in fig. 2 c. The top software interface is associated with the calibrated CAN communication interface and is used for processing the message received from the calibrated CAN communication interface. Generally, a chassis domain controller receives a plurality of different types of messages, and a hardware pin of the controller can be configured in advance to which type of peripheral or which peripheral corresponds, so that the message received from the pin is the message received by the peripheral of the corresponding type. For example, as shown in table 1 and table 2, a signal sequence number may be configured in the message to correspond to the target pin, and thus to the target peripheral. And the CAN message filtering and checking program is used for detecting whether the message is a CAN message and detecting the validity of the CAN message. And the CAN protocol layer software is used for detecting whether the received message is a CAN message or not based on the CAN protocol. The bottom driver (MCAL) is used to configure which type of peripheral or which peripheral the controller hardware pins correspond to. And the signal classification processing program is used for inquiring and calling the testing program matched with the detection type according to the detection type so as to execute the test on the chassis domain controller. The hardware interface may refer to a calibrated CAN communication interface for receiving or transmitting a CAN message. The MCAL can visually edit and configure functions such as pins, the difficulty of pin function configuration is reduced, the situation of manually editing codes is reduced, and the accuracy and efficiency of pin function configuration are improved.

In a specific application scenario, as shown in fig. 2d, the hardware testing method may include:

and S251, receiving the CAN message.

And S252, calibrating CAN message filtering.

And filtering identification Information (ID) of the message through a CAN message filtering and checking program. And judging whether the ID is valid, if so, executing S253, otherwise, discarding the message, and ending.

And S253, judging whether the message accords with the CRC rule, and if so, executing S254-S261 respectively.

And simultaneously, the microcontroller analyzes the CAN message and determines the detection type according to the first byte, namely the data in the first data bit. And judging which processing program should be called according to the detection type.

If the message does not accord with the CRC rule, the message is discarded, and the process is finished.

S254, judging whether the Byte0 command value is an analog quantity reading command, if so, executing S262.

Otherwise, S255 is executed.

S255, determine whether the Byte0 command value is a digital quantity reading command, if yes, execute S263.

Otherwise, S256 is executed.

S256, judging whether the command value of Byte0 is a frequency reading command, if so, executing S264.

Otherwise, S257 is performed.

S257, it is determined whether the Byte0 command value is a digital quantity output command, and if so, S265 is executed. Otherwise, S258 is executed.

S258, judging whether the command value of the Byte0 is the I2C communication command, if so, executing S266. Otherwise, S259 is performed.

S259, determine whether the Byte0 command value is an SPI communication command, if so, execute S267. Otherwise, S260 is performed.

S260, judging whether the command value of the Byte0 is a CAN communication command or not, and if so, executing S268. Otherwise, S261 is executed.

S261, judging whether the command value of Byte0 is an invalid command, if yes, executing S269.

Otherwise, discarding the message, and ending.

And S262, calling an analog quantity reading program.

The analog quantity reading program is used for reading the analog quantity signal.

And S263, calling a digital quantity reading program.

The digital quantity reading program is used for reading the digital quantity signal.

S264, a frequency reading program is called.

The frequency quantity reading program is used for reading the frequency quantity signal.

And S265, calling a digital quantity output program.

The digital quantity output program is used for outputting a digital quantity signal.

And S266, calling the I2C read-write program.

The I2C read-write program is used to read or write the I2C transmission signal.

And S267, calling the SPI read-write program.

The SPI read-write program is used for reading or writing the SPI transmission signal.

And S268, calling a CAN transceiving program.

The CAN read-write program is used for reading or writing CAN transmission signals.

S269, 100ms task calibrates the CAN transmission program.

The 100ms task is a timing task of 100ms, and whether a feedback message is generated or not needs to be detected within 100ms and sent to a request party. And replying a response CAN message in the task of the 100ms period.

An Autorix series single chip microcomputer can be adopted, a Micro Control Unit (MCU) is configured by using an MCAL programming tool supporting an Autosar architecture, the MCU resource is used for producing a bottom layer drive code conforming to the Autosar architecture, and the signal processing of the software of the chassis domain controller is classified according to the signal type, so that the hardware test software of the chassis domain controller is easy to read and maintain. The top-level logic programming of the chassis domain controller hardware test program is realized by using a data transmission method based on a CAN protocol with data verification, so that the problem of data failure caused by factors such as Electromagnetic Compatibility (EMC) interference of communication equipment or a test environment is avoided, and the safe and effective transmission of data is ensured. In fact, the embodiment of the invention realizes the hardware classification test of the chassis domain controller. Meanwhile, the hardware test program of the chassis domain controller is programmed by using an MCAL configuration tool through a bottom driver, and the test logic of top software realizes a method for classifying and processing according to signal types. And, the hardware test program CAN protocol of the chassis domain controller increases check bits, and the check of CAN data is realized by carrying out XOR operation according to the bits. The test platform can support manual test, environmental test, EMC test and the like of chassis domain controller hardware, and has flexible expandability. The method of classification processing according to the types of the input and output signals of the MCU can flexibly adapt to the increase and decrease of the input quantity and the output quantity; meanwhile, CRC (cyclic redundancy check) is carried out on CAN bus receiving and sending data, and the correctness and the safety of data transmission are ensured.

The embodiment of the invention analyzes the test instruction message to obtain the data of a plurality of data bits, configures the appointed data bits in the plurality of data bits, and determines the detection type according to the data of the appointed data bits, can accurately determine the detection type according to the test instruction message, and improves the detection accuracy of the detection type, thereby indicating different types of tests by appointing the detection type through the test instruction message, improving the test efficiency and accuracy, reducing the test difficulty, and reducing the test labor cost.

EXAMPLE III

Fig. 3 is a schematic diagram of a hardware testing apparatus according to a third embodiment of the present invention. The third embodiment is a corresponding device for implementing the hardware testing method provided by the above embodiments of the present invention, and the device can be implemented in a software and/or hardware manner, and can be generally integrated into a computer device.

Accordingly, the apparatus of the present embodiment may include:

The embodiment of the invention determines the detection type by analyzing the test instruction message, calls the test program matched with the detection type, and feeds the test result back to the requesting party, thereby solving the problems of multiple signal types, high test difficulty and high test labor cost in the prior art, and carrying out different types of tests through message indication, improving the efficiency and accuracy, reducing the test difficulty and reducing the test labor cost.

Further, the test instruction packet includes 8 data bits, and the specified data bit is a first data bit.

Further, the hardware testing apparatus further includes: the message screening module is used for receiving an original message before analyzing the test instruction message; detecting the original message according to a preset transmission protocol; and when the data format of the original message is the data format specified by the transmission protocol, determining the message as a test instruction message.

Further, the test instruction message is a controller area network message in the chassis domain controller.

The device can execute the method provided by the embodiment of the invention and has corresponding functional components and beneficial effects of the execution method.

Example four

Fig. 4 is a schematic structural diagram of a computer device according to a fourth embodiment of the present invention. FIG. 4 illustrates a block diagram of an exemplary computer device 12 suitable for use in implementing embodiments of the present invention. The computer device 12 shown in FIG. 4 is only one example and should not bring any limitations to the functionality or scope of use of embodiments of the present invention.

Computer device 12 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer device 12 and includes both volatile and nonvolatile media, removable and non-removable media.

EXAMPLE five

Fifth, an embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the hardware testing method provided in all the inventive embodiments of the present application:

that is, the program when executed by the processor implements: analyzing the test instruction message to obtain a detection type corresponding to the test instruction message; inquiring and calling a matched test program according to the detection type; and acquiring the test result of the matched test program, and generating a feedback message for responding.

Computer storage media for embodiments of the invention may employ any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a RAM, a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM), a flash Memory, an optical fiber, a portable CD-ROM, an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, Radio Frequency (RF), etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a LAN or a WAN, or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

It is to be noted that the foregoing is only illustrative of the preferred embodiments of the present invention and the technical principles employed. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, although the present invention has been described in greater detail by the above embodiments, the present invention is not limited to the above embodiments, and may include other equivalent embodiments without departing from the spirit of the present invention, and the scope of the present invention is determined by the scope of the appended claims.