A communication verification method for an in-vehicle CAN network and a storage medium

Abstract

The application relates to a communication verification method of an in-vehicle CAN network and a storage medium, and the verification method is used for in-vehicle CAN bus communication, and dynamic verification is carried out on 8 bytes of a data section of a CAN standard frame, and the method comprises the following steps: A, a sending party positions the number of bytes needing verification; B, the sending party calculates a check sum; C, a receiving party first reads the number of bytes needing verification of a received message; and D, the receiving party calculates a check sum and compares the calculated check sum with the number of bytes needing verification. The communication verification method of the in-vehicle CAN network can realize dynamic verification, carries out targeted verification on key information, adopts different verification strategies for different messages, and solves the problem that effective signals cannot be correctly received due to interference, and the method has strong adaptability and does not have requirements on the software architecture of a controller, and can be applied regardless of whether the controller is based on an AUTOSAR software architecture.

Description

Technical Field

[0001] This invention belongs to the field of automotive technology, specifically relating to a communication verification method and storage medium for an in-vehicle CAN network. Background Technology

[0002] Controller Area Network (CAN) is a serial communication protocol bus used in real-time applications. It uses twisted-pair cables to transmit signals and is one of the most widely used fieldbuses in the world. The CAN protocol is widely used for communication between various components in automobiles. Verifying the accuracy of CAN bus signals transmitted between application layers is currently a hot research topic in this field.

[0003] Existing technology discloses an AUTOSAR E2E verification mechanism. In vehicle networks, information exchange typically involves one ECU sending a signal and another ECU receiving it. For E2E, the signal is usually generated from the source SW-C (Software Component), passes through the RTE (Run-Time Environment), BSW (Basic Software), and is transmitted on the physical bus before reaching the target SW-C (Software Component). During this process, signal transmission may fail to reach the target terminal due to fault conditions (such as software errors), or the signal itself may be interfered with or damaged. This poses a significant risk, especially for safety-related signals (vehicle speed, gear position, vehicle / power mode, etc.). E2E employs mechanisms to ensure data consistency between the sending and receiving terminals, guaranteeing information integrity.

[0004] However, the receiving end will discard the message after receiving the verification error. If the key signals related to personal safety (such as vehicle speed, gear, power mode, etc.) in the whole message are not interfered with, but other non-critical signals are interfered with, the whole message will also be discarded. This will cause the receiving end to fail to receive the effective signal in time, thus creating a safety hazard. Summary of the Invention

[0005] The purpose of this invention is to provide a communication verification method and storage medium for an in-vehicle CAN network, so as to solve the problem of dynamically verifying the accuracy of CAN bus signals transmitted between application layers.

[0006] The objective of this invention is achieved through the following technical solution:

[0007] A communication verification method for an in-vehicle CAN network, used for in-vehicle CAN bus communication, dynamically verifies 8 bytes of the data segment of a CAN standard frame, including the following steps:

[0008] A. The number of bytes that the sender needs to verify;

[0009] B. The checksum calculated by the sender;

[0010] C. The receiver first reads the number of bytes that need to be verified in the received message;

[0011] D. The receiver calculates the checksum and compares it with the number of bytes received that need to be checked.

[0012] Further, step A specifically includes the following steps:

[0013] A1. Select the first byte of the data segment in the CAN standard frame as the checksum byte and name it checksum;

[0014] A2. Divide the Checksum byte into two parts: the high 4 bits and the low 4 bits. The high 4 bits are bits 7 to 4, and the low 4 bits are bits 3 to 0.

[0015] A3, the high 4 bits are the calculated checksum, named checksum_compute; the low 4 bits are the number of bytes to be checked, named checksum_number.

[0016] Furthermore, in step A3, the calculated checksum ranges from 0x0 to 0xF, and the number of bytes to be checked ranges from 0x0 to 0x7.

[0017] Furthermore, checksum_number represents the number of bytes that need to be checked. If checksum_number is 0x0, then this message does not need to check the data segment. If checksum_number is 0x7, then the remaining 7 bytes need to be checked. If checksum_number is 0x2, then the two bytes after the checksum need to be checked, and the remaining bytes do not need to be checked, and so on.

[0018] Furthermore, in practical applications, important signals can be placed in the first few bytes after the checksum, and the length can be defined so that only the first few bytes are checked.

[0019] Furthermore, step B specifically involves the sender calculating the checksum of the bytes to be sent that require verification, and then filling the checksum_compute_s into checksum_compute.

[0020] Furthermore, step C specifically involves the recipient reading the checksum_number after receiving the data.

[0021] Furthermore, step D specifically involves: calculating the checksum_compute_r using the same algorithm based on the checksum length; comparing checksum_compute_s with checksum_compute_r; if they match, the message is error-free, and bytes that do not require verification do not need to be considered.

[0022] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement a communication verification method for an in-vehicle CAN network as described in this invention.

[0023] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a communication verification method for an in-vehicle CAN network as described in any of the embodiments of the present invention.

[0024] Compared with the prior art, the beneficial effects of the present invention are:

[0025] The communication verification method for in-vehicle CAN network of the present invention can realize dynamic verification, perform targeted verification of key information, and adopt different verification strategies for different messages to solve the problem of valid signals not being interfered with but being unable to be received correctly. Moreover, this method is highly adaptable and has no requirements on the software architecture of the controller, and can be applied regardless of whether it is based on the AUTOSAR software architecture. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 A flowchart of the communication verification method for the in-vehicle CAN network of the present invention;

[0028] Figure 2 This is a schematic diagram of the structure of a computer device in Embodiment 2 of the present invention. Detailed Implementation

[0029] The present invention will be further described below with reference to embodiments:

[0030] The communication verification method for in-vehicle CAN network of the present invention performs dynamic verification on 8 bytes of the data segment of the CAN standard frame, which is implemented by the software layer and includes the following steps:

[0031] 1. The sender determines the number of bytes that need to be verified;

[0032] 2. The checksum calculated by the sender;

[0033] 3. The receiver first reads the number of bytes that need to be verified in the received message;

[0034] 4. The receiver calculates the checksum and compares it with the number of bytes received that need to be checked.

[0035] Specifically, this method is implemented in the following way:

[0036] In the CAN standard frame, the first byte of the data segment is selected as the checksum byte and named checksum. The checksum byte is divided into two parts: the high 4 bits are bits 7 to 4, and the low 4 bits are bits 3 to 0.

[0037] The high 4 bits represent the calculated checksum, named checksum_compute, with a value range of 0x0 to 0xF; the low 4 bits represent the number of bytes to be checked, named checksum_number, with a value range of 0x0 to 0x7.

[0038] Regarding the dynamic definition of checksum bytes: `checksum_number` represents the number of bytes to be checked. If `checksum_number` is 0x0, the data segment of this message does not need to be checked; if `checksum_number` is 0x7, the remaining 7 bytes need to be checked; if `checksum_number` is 0x2, the two bytes after the checksum need to be checked, and the remaining bytes do not need to be checked, and so on. In practical applications, important signals, such as security signals, can be placed in the first few bytes after the checksum, with a defined length, and only the first few bytes are checked.

[0039] Regarding the checksum algorithm: `checksum_compute` is the calculated checksum. The sender calculates the checksum `checksum_compute_s` for the bytes to be sent that require checksum verification and fills it into `checksum_compute`. After receiving the data, the receiver first reads `checksum_number`, then calculates the checksum `checksum_compute_r` using the same algorithm based on the checksum length. `checksum_compute_s` is then compared with `checksum_compute_r`. If they match, the message is error-free. Bytes that do not require checksum verification do not need to be checked.

[0040] This method can be used for in-vehicle CAN bus communication. The definition of checksum is reflected in the CAN communication matrix. After receiving the communication matrix, the controller verifies the message using this method. In this invention, the message is dynamically verified, and the length of the checksum byte is customizable, which can prevent the receiver from not receiving a valid signal in a timely manner.

[0041] In addition, the length and position of the checksum byte defined in this implementation are just one example; the checksum length can also be defined as different lengths.

[0042] Example 1

[0043] A communication verification method for an in-vehicle CAN network includes the following steps:

[0044] In the CAN standard frame, the first byte of the data segment is selected as the checksum byte and named checksum. The checksum byte is divided into two parts: the high 4 bits are bits 7 to 4, and the low 4 bits are bits 3 to 0.

[0045] The high 4 bits represent the calculated checksum, named checksum_compute, with a value range of 0x0 to 0xF; the low 4 bits represent the number of bytes to be checked, named checksum_number, with a value range of 0x0 to 0x7.

[0046] `checksum_number` represents the number of bytes to be checked. If `checksum_number` is 0x0, the data segment of this message does not need to be checked; if `checksum_number` is 0x7, the remaining 7 bytes need to be checked; if `checksum_number` is 0x2, the two bytes after the checksum need to be checked, and the remaining bytes do not need to be checked, and so on. Security signals are placed in the first few bytes after the checksum, with a defined length, and only the first few bytes are checked.

[0047] `checksum_compute` is the calculated checksum. The sender calculates the checksum `checksum_compute_s` for the bytes to be sent that require verification, and fills it into `checksum_compute`. Upon receiving the data, the receiver first reads `checksum_number`, then calculates the checksum `checksum_compute_r` using the same algorithm based on the checksum length. `checksum_compute_s` is then compared with `checksum_compute_r`. If they match, the message is error-free. Bytes that do not require verification are ignored.

[0048] The verification method is as follows:

[0049] Release a defined check factor = 0x0, split the bytes to be checked into two parts: the high 4 bits and the low 4 bits. Then checksum_compute = 0x0 XOR Byte1_H_4Bit XOR Byte1_L_4Bit XOR Byte2_H_4Bit XOR Byte2_L_4Bit XOR........

[0050] Example 2

[0051] Figure 2 This is a schematic diagram of the structure of a computer device in Embodiment 2 of the present invention. Figure 2 A block diagram of an exemplary computer device 12 suitable for implementing embodiments of the present invention is shown. Figure 2 The computer device 12 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0052] like Figure 2 As shown, the computer device 12 is represented in the form of a general-purpose computing device. The components of the computer device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and a bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0053] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0054] Computer device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by computer device 12, including volatile and non-volatile media, removable and non-removable media.

[0055] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Computer device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (…). Figure 2Not shown; usually referred to as a "hard drive"). Although Figure 2 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. Memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0056] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in memory 28. Such program modules 42 include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0057] The computer device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with the computer device 12, and / or with any device that enables the computer device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via the input / output (I / O) interface 22. Furthermore, in this embodiment, the display 24 of the computer device 12 is not an independent entity, but is embedded in a mirror, so that when the display surface of the display 24 is not displayed, the display surface of the display 24 and the mirror surface visually blend together. Moreover, the computer device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via the network adapter 20. As shown, the network adapter 20 communicates with other modules of the computer device 12 via the bus 18. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with computer device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0058] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing a communication verification method for an in-vehicle CAN network provided in an embodiment of the present invention.

[0059] Example 3

[0060] Embodiment 3 of the present invention provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a communication verification method for an in-vehicle CAN network as provided in all embodiments of the present application.

[0061] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0062] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0063] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0064] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0065] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A communication verification method for an in-vehicle CAN network, characterized in that, For in-vehicle CAN bus communication, dynamic verification is performed on 8 bytes of the data segment of the CAN standard frame, including the following steps: A. The number of bytes that the sender needs to verify; B. The checksum calculated by the sender; C. The receiver first reads the number of bytes that need to be verified in the received message; D. The receiver calculates the checksum and compares it with the number of bytes received that need to be checked; Step A specifically includes the following steps: A1. Select the first byte of the data segment in the CAN standard frame as the checksum byte and name it checksum; A2. Divide the checksum byte into two parts: the high 4 bits and the low 4 bits. The high 4 bits are bits 7 to 4, and the low 4 bits are bits 3 to 0. A3, the high 4 bits are the calculated checksum, named checksum_compute; the low 4 bits are the number of bytes to be checked, named checksum_number.

2. The communication verification method for an in-vehicle CAN network according to claim 1, characterized in that: In step A3, the calculated checksum value ranges from 0x0 to 0xF, and the number of bytes to be checked ranges from 0x0 to 0x7.

3. The communication verification method for an in-vehicle CAN network according to claim 2, characterized in that: The checksum_number represents the number of bytes that need to be checked. If the checksum_number is 0x0, the data segment of this message does not need to be checked. If the checksum_number is 0x7, the remaining 7 bytes need to be checked. If the checksum_number is 0x2, the two bytes after the checksum need to be checked, and the remaining bytes do not need to be checked, and so on.

4. The communication verification method for an in-vehicle CAN network according to claim 3, characterized in that: In practical applications, important signals can be placed in the first few bytes after the checksum, and the length can be defined so that only the first few bytes are checked.

5. The communication verification method for an in-vehicle CAN network according to claim 1, characterized in that: Step B specifically involves the sender calculating the checksum of the bytes to be sent that require verification, and then filling the checksum_compute_s into checksum_compute.

6. The communication verification method for an in-vehicle CAN network according to claim 5, characterized in that: Step C, specifically: After receiving the data, the receiver first reads the checksum_number.

7. The communication verification method for an in-vehicle CAN network according to claim 6, characterized in that: Step D is as follows: Calculate the checksum checksum_compute_r using the same algorithm based on the checksum length. Compare checksum_compute_s with checksum_compute_r. If they match, the message is error-free, and bytes that do not require verification do not need to be checked.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, it implements the communication verification method for the in-vehicle CAN network as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that: It stores a computer program that, when executed by a processor, implements the communication verification method for the in-vehicle CAN network as described in any one of claims 1-7.

Images