A message transmission method and system based on CAN bus

Abstract

This application discloses a message transmission method and system based on a CAN bus. The method includes: a first ECU node generating a node message according to predetermined rules and uploading it to the CAN bus for transmission; when a second ECU node receives a node message at a predetermined node address, it reads the message request identifier to see if it is a verification request. If so, it searches for the random number carried by the message, selects a matching encryption algorithm based on the random number, and verifies the generation time carried by the node message based on vehicle time data. After successful verification, it generates a second dynamic key based on the generation time and the random number using the selected encryption algorithm, and compares it with the first dynamic key carried by the node message. If they match, it uses the second dynamic key to decrypt the ciphertext carried by the node message to obtain valid data, generates a response message, and uploads it to the CAN bus to provide feedback to the sending ECU node. This application can achieve secure encryption and verification of messages on the CAN bus, improving transmission security and reliability.

Description

Technical Field

[0001] This application relates to the field of vehicle electronic control system technology, specifically to the technical fields of CAN bus control and secure message transmission for commercial vehicles, and particularly to a message transmission method and system based on CAN bus. Background Technology

[0002] In the field of electronic control systems for commercial vehicles, the CAN (Controller Area Network) bus, with its advantages of high real-time performance, high reliability and low cost, has become the core communication network connecting various vehicle controllers such as engine controller, transmission controller, braking system ECU (electronic control unit), and body management module. It undertakes the key task of information transmission and signal interaction between vehicle controllers and is the "nerve center" that ensures the stable operation of functions such as power control, driving safety and body management of commercial vehicles.

[0003] The current CAN bus message transmission mechanism in commercial vehicles relies on "message ID recognition" for data reception control. During system design, each onboard node is predefined with a specific message ID to receive. During bus communication, nodes only receive messages matching the predefined ID, filtering out those with mismatched IDs. While this fixed-ID-based transmission method meets basic communication needs, it cannot verify the actual source of the message or determine if it has been tampered with during transmission, posing a significant security vulnerability. If an external source sends a forged message with the same predefined ID to the bus using vehicle simulation equipment, the corresponding receiving node may mistakenly identify the forged message as legitimate data, leading to interference and potentially causing controller malfunctions, thus threatening vehicle safety.

[0004] To compensate for this deficiency, some commercial vehicles on the market have added a certain security algorithm mechanism on the basis of fixed ID transmission; however, this transmission mechanism results in low security and poor reliability in the message exchange transmission process; the fixed security algorithm used throughout the vehicle is easy to crack and has weak security protection capabilities; and there is no verification feedback mechanism, making it difficult to locate faults after verification failure. Summary of the Invention

[0005] This application provides a message transmission method and system based on CAN bus to achieve secure encryption and verification of messages on CAN bus, thereby improving transmission security and reliability.

[0006] The technical solution is as follows: Firstly, a message transmission method based on the CAN bus is provided, including: The first ECU node constructs at least one node message in the following manner: generating a message request identifier and a random number, and selecting a matching encryption algorithm based on the random number; generating a first dynamic key using the encryption algorithm based on the generation time of the message request identifier and the random number; encrypting valid data using the first dynamic key to obtain ciphertext, and generating a node message according to a predetermined rule using the node address of the current first ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext. The first ECU node uploads at least one generated node message to the CAN bus for transmission; The second ECU node monitors the CAN bus in real time and only receives node messages carrying pre-agreed node addresses. After the second ECU node receives the node message, if it reads that the message request identifier is a verification request from the node message, it further searches for a random number from the node message and selects a matching encryption algorithm based on the found random number; it verifies the generation time carried in the node message based on the vehicle time data, and after the verification is successful, it generates a second dynamic key using the encryption algorithm based on the generation time and the found random number; it compares the second dynamic key with the first dynamic key carried in the node message, and if they match, it uses the second dynamic key to decrypt the ciphertext to obtain valid data; The second ECU node sends a response message to the CAN bus indicating that the message transmission was successful.

[0007] In one possible implementation, the message request identifier is used to indicate whether the current message requires verification; If the message request identifier is 0, it indicates that there is no verification request for this message; If the message request identifier is 1, it indicates that this message has a verification request.

[0008] In one possible implementation, the random number is any integer between 0 and 7, and each random number is pre-matched with an encryption algorithm; and each generated random number is unique compared to the previous generated random number.

[0009] In one possible implementation, the node address of the current ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext are used to generate a node message according to a predetermined rule, specifically including: The node address of the current ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext are arranged in a predetermined order with their respective different bits or bytes to generate a node message; wherein, the request identifier occupies 1 bit, the generation time occupies 4 bits, the random number occupies 3 bits, the first dynamic key occupies 8 bits, and the ciphertext and node address occupy the remaining 6 bytes.

[0010] In one possible implementation, the generation time carried in the node's message is verified based on the vehicle's overall time data, specifically including: Obtain the vehicle time data and find the sending time of the message at that node. Compare the sending time of the node message with the generation time; If the difference between the two is within the threshold range, then the generation time verification is considered successful.

[0011] Secondly, a message transmission system based on a CAN bus is provided, comprising: multiple first ECU nodes for sending node messages, multiple second ECU nodes for receiving node messages, and a CAN bus; wherein, The first ECU node constructs at least one node message in the following manner: generating a message request identifier and a random number, and selecting a matching encryption algorithm based on the random number; generating a first dynamic key based on the generation time of the message request identifier and the random number using the encryption algorithm; encrypting valid data using the first dynamic key to obtain ciphertext, and generating a node message by combining the node address of the current ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext according to a predetermined rule; The first ECU node uploads at least one generated node message to the CAN bus for transmission; The second ECU node monitors the CAN bus in real time and only receives node messages carrying pre-agreed node addresses. After the second ECU node receives the node message, if it reads that the message request identifier is a verification request from the node message, it further searches for a random number from the node message and selects a matching encryption algorithm based on the found random number; it verifies the generation time carried in the node message based on the vehicle time data, and after the verification is successful, it generates a second dynamic key using the encryption algorithm based on the generation time and the found random number; it compares the second dynamic key with the first dynamic key carried in the node message, and if they match, it uses the second dynamic key to decrypt the ciphertext to obtain valid data; The second ECU node sends a response message to the CAN bus indicating that the message transmission was successful.

[0012] Thirdly, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods described above and any possible implementations.

[0013] Fourthly, a computer-readable storage medium is provided, wherein at least one instruction is stored therein, the at least one instruction being loaded and executed by a processor to implement the aspects described above and any possible implementation thereof.

[0014] Fifthly, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the aspects and any possible implementations described above.

[0015] Sixthly, a new energy heavy-duty vehicle is provided, including the electronic equipment described above.

[0016] The beneficial effects of the technical solution provided in this application include at least the following: As can be seen from the above technical solution, in this embodiment, the ECU node located on the CAN bus can generate node messages according to predetermined rules and then upload them to the CAN bus for transmission. When the receiving ECU node receives the node message at the agreed node address, it first reads whether the message request identifier is a verification request. If so, it searches for the random number carried in the node message, selects a matching encryption algorithm based on the random number, and then verifies the generation time carried in the node message based on the vehicle time data. After successful verification, it generates a second dynamic key based on the generation time and the random number using the selected encryption algorithm and compares it with the first dynamic key carried in the node message. If they match, it uses the second dynamic key to decrypt the ciphertext carried in the node message to obtain valid data. Finally, it generates a response message and uploads it to the CAN bus to provide feedback to the sending ECU node. This application can achieve secure encryption and verification of messages on the CAN bus, improving transmission security and reliability.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram illustrating the applicable scenario for the CAN bus-based message transmission scheme of this application; Figure 2 This is a schematic diagram illustrating the applicable scenario of the CAN bus-based message transmission scheme provided in the embodiments of this application; Figure 3 This is a structural block diagram of a CAN bus-based message transmission system provided in one embodiment of this application; Figure 4 This is a block diagram of an electronic device used to implement the message transmission method of the embodiments of this application. Detailed Implementation

[0020] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0021] Obviously, the described embodiments are only some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0022] It should be noted that the terminal devices involved in the embodiments of this application may include, but are not limited to, smart devices such as mobile phones, personal digital assistants (PDAs), wireless handheld devices, and tablet computers; the display devices may include, but are not limited to, personal computers, televisions, and other devices with display functions.

[0023] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0024] Given the shortcomings of existing transmission mechanisms, such as low security and poor reliability in message exchange transmission, the use of universal fixed security algorithms for the entire vehicle which are easily cracked, weak security protection capabilities, lack of verification feedback mechanisms, and difficulty in fault location after verification failure, this application proposes a message transmission scheme based on the CAN bus. The main inventive concept is as follows: ECU nodes located on the CAN bus can generate node messages according to predetermined rules and then upload them to the CAN bus for transmission. When the receiving ECU node receives a node message at a predetermined node address, it first reads the message request identifier to see if it is a verification request. If so, it searches for the random number carried in the node message, selects a matching encryption algorithm based on the random number, and then verifies the generation time carried in the node message based on the vehicle's time data. After successful verification, it generates a second dynamic key using the selected encryption algorithm based on the generation time and the random number, and compares it with the first dynamic key carried in the node message. If they match, it uses the second dynamic key to decrypt the ciphertext carried in the node message to obtain valid data. Finally, it generates a response message and uploads it to the CAN bus to provide feedback to the sending ECU node. This application can achieve secure encryption and verification of messages on the CAN bus, thereby improving transmission security and reliability.

[0025] First, combined Figure 1 The schematic diagram shown illustrates the applicable scenarios for the CAN bus-based message transmission scheme and provides a brief description of the system architecture of this message transmission scheme.

[0026] Reference Figure 1 As shown, the system architecture includes one or more CAN buses and multiple ECU nodes located on the CAN buses. Message transmission between these ECU nodes is achieved through the CAN bus. Each ECU node's node message is pre-agreed to be sent to an ECU node; that is, all node messages have agreed-upon sending and receiving nodes. Specifically, the node address of the receiving node can be carried in the node message. In this system architecture, each ECU node can both act as a sending node to send node messages to other ECU nodes and as a receiving node to receive node messages sent from other ECU nodes. Furthermore, this application can also connect the buses of various network segments of the vehicle to a data acquisition unit, meaning the data acquisition unit can collect data from each network segment. The data acquisition unit can store the data from various network segments of the vehicle locally and upload it to the cloud.

[0027] Combination Figure 2The diagram illustrates the applicable scenario for the CAN bus-based message transmission scheme provided in this application embodiment. The execution entities of this method are two ECU nodes engaging in message interaction: a first ECU node and a second ECU node. In this message transmission task, the first ECU node acts as the sending node, and the second ECU node acts as the receiving node; the response message return process is ignored here. In the next message transmission task, the first ECU node can act as the receiving node, and the second ECU node as the sending node. In short, the ECU nodes can interchange roles; their roles are not fixed. If a node acts as a sending node in one message transmission, it may act as a receiving node in the next message transmission.

[0028] It should be understood that when the first ECU node and the second ECU node interact with messages in the scheme of this application, the message transmission scheme of this application can achieve both secure handshake and message interaction at the same time, without the need for additional secure handshake processing. Secure handshake and message interaction can be achieved simultaneously in one message transmission, thereby improving message transmission security and transmission speed, and increasing message interaction efficiency.

[0029] like Figure 2 As shown, the message transmission method may include the following steps: Step 202: The first ECU node constructs at least one node message in the following manner: generates a message request identifier and a random number, and selects a matching encryption algorithm based on the random number; generates a first dynamic key using the encryption algorithm based on the generation time of the message request identifier and the random number; encrypts the valid data using the first dynamic key to obtain ciphertext, and generates a node message by combining the node address of the current first ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext according to a predetermined rule.

[0030] Since the same data from each ECU node may need to be transmitted to different ECU nodes, and different data may need to be transmitted to different ECU nodes, the first ECU node here can construct one or more node messages at different time nodes or at some of the same time nodes.

[0031] In this application, node messages and response messages can be defined in advance. For example, the byte length of the messages, the data fields they contain, and the rules for combining these fields into a single message can be defined. In one example, the length of node messages transmitted between CAN buses can be set to 8 bytes. Each node message can contain 5 data fields: a message request identifier field, a random number field, a generation time field, a dynamic key field, and a valid data field. The byte length of response messages can be shorter, such as 5 bytes or less. Each response message can contain 4 data fields: an unlock status field, a random number field, an unlock failure reason field, and valid data.

[0032] The message request identifier field occupies one bit, indicating whether the message requires verification. A request identifier of 0 indicates no verification is required, while a request identifier of 1 indicates verification is required. In other words, this request identifier determines whether a handshake verification is performed to ensure secure message transmission. Therefore, not all node messages require a handshake; handshake verification is only performed on node messages carrying a request identifier marked as 1.

[0033] The random number field can occupy 3 digits, with a value range of 0-7, for a total of 8 integer values. Random numbers are selected from these 8 values ​​during calculation, and each selected random number cannot be the same as the previous one, thus improving randomness and enhancing handshake security. Furthermore, each random number can correspond to an encryption algorithm, providing 8 different encryption algorithms for use. This generates a database of correspondences between random numbers and encryption algorithms, further increasing the randomness of dynamic key generation and the reliability of verification.

[0034] The generation time field can occupy 4 digits. This generation time can be used as the message request time because it is the actual time when the current request is sent. The algorithm needs to combine the value of this field to calculate the generation of the dynamic key field. Here, the default is the time when the node message is generated.

[0035] The dynamic key field can occupy 8 bits. The specific value of the dynamic key is calculated based on a random number field, a generation time field, and an encryption algorithm. Since the random number changes dynamically, the generation time may be different, and the encryption algorithm is also dynamically adjusted, the calculated dynamic key is almost never repeated, thus increasing the uniqueness of the dynamic key and the reliability of verification.

[0036] The valid data field can occupy the remaining bytes. This valid data can be the detailed content of the message, such as vehicle-related information: time, command, status, etc. This application does not limit this. All vehicle-related information that can be transmitted via the CAN bus can be efficiently and securely transmitted between ECU nodes through this message transmission method.

[0037] In the specific construction process, a message request identifier and a random number can be generated first. The message request identifier can be set according to the transmission requirements of this node message. If handshake verification is required, a message request identifier of 1 can be generated; if handshake verification is not required, or has already been performed, and only message transmission is needed, a message request identifier of 0 can be generated. The random number can be generated using a random number generator, with the range and generation rules set according to the above requirements. Then, based on the generated random number, a matching encryption algorithm can be searched from a pre-defined database of random number-encryption algorithm correspondences. Then, using this encryption algorithm, a first dynamic key is generated based on the generation time and the random number. After generating the first dynamic key, valid data can be encrypted using this key to obtain ciphertext of the valid data. Then, according to the sorting or generation method in the predetermined message generation rules, a node message is generated using the node address, request identifier, generation time, random number, first dynamic key, and ciphertext.

[0038] Optionally, the node address of the current ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext are arranged in a predetermined order with different bits or bytes to generate a node message; wherein, the request identifier occupies 1 bit, the generation time occupies 4 bits, the random number occupies 3 bits, the first dynamic key occupies 8 bits, and the ciphertext and node address occupy the remaining 6 bytes.

[0039] Step 204: The first ECU node uploads at least one generated node message to the CAN bus for transmission.

[0040] Step 206: The second ECU node monitors the CAN bus in real time and only receives node messages carrying pre-agreed node addresses.

[0041] The second ECU node can monitor the messages coming and going on the CAN bus in real time. Once it finds the node address of an ECU node that has been agreed upon with this ECU node (the second ECU node) in advance, it can receive the message from that node.

[0042] Step 208: After the second ECU node receives the node message, if the message request identifier is read from the node message as a verification request, then a random number is further searched in the node message, and a matching encryption algorithm is selected based on the found random number; the generation time carried in the node message is verified based on the vehicle time data, and after the verification is successful, a second dynamic key is generated using the encryption algorithm according to the generation time and the found random number; the second dynamic key is compared with the first dynamic key carried in the node message, and if they match, the second dynamic key is used to decrypt the ciphertext to obtain valid data.

[0043] In this application's scheme, after the second ECU node receives the node message, it first parses the message to extract different data fields. Then, it checks if the request identifier in the message request identifier field indicates a verification request. If so, it further searches for a random number and then searches for a matching encryption algorithm from a pre-defined database of random number and encryption algorithm correspondences. Furthermore, it can obtain vehicle time data and verify the generation time carried in the node message based on this data, for example, verifying whether the generation time is valid and reasonable. After successful verification, it generates a second dynamic key using the generation time and the found random number, employing an encryption algorithm. Thus, the second ECU node uses the information from the data fields carried in the node message to generate the second dynamic key. It then compares this second dynamic key with the first dynamic key carried in the node message. If the two dynamic keys match, the handshake verification is successful, and either the second or first dynamic key is used to decrypt the ciphertext to obtain the valid data of the node message.

[0044] Optionally, when verifying the generation time carried in the node message based on the whole vehicle time data, this application can obtain the whole vehicle time data and find the sending time of the node message from it; compare the sending time of the node message with the generation time; if the difference between the two is within the threshold range, then it is determined that the generation time verification is successful.

[0045] Step 210: The second ECU node sends a response message to the CAN bus indicating that the message transmission was successful.

[0046] After successful verification and receipt of valid data, the second ECU node can return a response message in a fixed format. This response message can include an unlock status field, a random number field, an unlock failure reason status, and valid data. The unlock status field can occupy 2 bits, where the unlock status identifier represents different states, for example: 0: normal response; 1: request in progress; 2: response failed; 3: reserved. The random number field occupies 3 bits, 0~7, and must be the same as the random value in the current handshake request message. That is, the random number in the request message and the random number in the response message must be the same during a handshake process, indicating the corresponding handshake round. The unlock failure reason status field occupies 3 bits. For example, if the unlock status field = 2: response failed, the reason for failure must be explained; different values ​​correspond to different failure reasons.

[0047] For example, let's take the message interaction between the request node and the response node as an example.

[0048] The request and response nodes have defined fixed handshake message IDs during the design phase, such as 0x18FEEE01. The request and response nodes have also defined fixed security verification algorithms based on random number segments during the design phase, such as random number 0 corresponding to algorithm 0, random number 1 corresponding to algorithm 1, and so on.

[0049] On the requesting side: When the requesting node needs to perform handshake verification, it sends a node message with message ID 0x18FEEE01, setting the request identifier field to 1, indicating a handshake request. The random number field is randomly generated, e.g., 3; that is, the random number field is filled with 3, and in this handshake, verification algorithm 3 is used to generate the final first dynamic key. The request time field is obtained from the vehicle's overall time and is fixedly filled in, used in the verification algorithm. The dynamic key field is generated using verification algorithm 3 combined with the previous fixed fields. The remaining bytes carry valid data. This generates a complete handshake request message and sends it to the CAN bus.

[0050] On the response side: When the response node identifies the 0x18FEEE01 message sent by the requesting node on the CAN bus, it determines it to be a handshake message and receives it. If the identification field signal of the request message is set to 1, indicating a handshake request, a handshake interaction is required. If the identified random number field is 3, the random number field of the response message is also filled with 3, and verification algorithm 3 is required in this handshake. The vehicle time is obtained and verified to ensure the correctness of the requested time field, and this is added to the verification algorithm. The response node combines the fixed fields identified in the request message and uses verification algorithm 3 to generate a second dynamic key. This first dynamic key is compared with the first dynamic key in the request message. If they match, the handshake is successful, and a successful handshake feedback is sent, allowing normal unlocking. If they do not match, the handshake fails, and a failure feedback and the reason for the failure are sent.

[0051] The technical solution of this application can realize secure encryption and verification of messages on the CAN bus, thereby improving transmission security and reliability.

[0052] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0053] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0054] Figure 3 This application provides a structural block diagram of a CAN bus-based message transmission system according to an embodiment of the present application. Figure 3 As shown. The CAN bus-based message transmission system 300 of this embodiment includes: multiple first ECU nodes 301 for sending node messages, multiple second ECU nodes 302 for receiving node messages, and a CAN bus 303; wherein, the first ECU nodes 301 construct at least one node message in the following manner: generating a message request identifier and a random number, and selecting a matching encryption algorithm based on the random number; generating a first dynamic key based on the generation time of the message request identifier and the random number using the encryption algorithm; encrypting valid data using the first dynamic key to obtain ciphertext, and generating a node message according to a predetermined rule using the node address of the current ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext; the first ECU nodes 301 upload the generated at least one node message to the CAN bus 303. 03. Transmission is performed; the second ECU node 302 monitors the CAN bus 303 in real time and only receives node messages carrying pre-agreed node addresses; after receiving a node message, if the second ECU node 302 reads a message request identifier as a verification request from the node message, it further searches for a random number from the node message and selects a matching encryption algorithm based on the found random number; it verifies the generation time carried in the node message based on the vehicle time data, and after successful verification, it generates a second dynamic key using the encryption algorithm based on the generation time and the found random number; it compares the second dynamic key with the first dynamic key carried in the node message, and if they match, it uses the second dynamic key to decrypt the ciphertext to obtain valid data; the second ECU node 302 sends a response message to the CAN bus 303 indicating successful message transmission.

[0055] Optionally, the message request identifier is used to indicate whether the current message requests verification; if the message request identifier is 0, it indicates that the current message does not request verification; if the message request identifier is 1, it indicates that the current message requests verification.

[0056] Optionally, the random number is any integer between 0 and 7, and each random number is pre-matched with an encryption algorithm; and each generated random number is not the same as the previous generated random number.

[0057] Optionally, when the first ECU node 301 generates a node message by combining the node address of the current ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext according to a predetermined rule, it specifically arranges the node address of the current ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext in a predetermined order with their respective different bits or bytes to generate the node message; wherein, the request identifier occupies 1 bit, the generation time occupies 4 bits, the random number occupies 3 bits, the first dynamic key occupies 8 bits, and the ciphertext and the node address occupy the remaining 6 bytes.

[0058] Optionally, when the second ECU node 302 verifies the generation time carried in the node message based on the vehicle time data, it specifically acquires the vehicle time data and finds the sending time of the node message from it; compares the sending time of the node message with the generation time; if the difference between the two is within the threshold range, it is determined that the generation time verification is successful.

[0059] In this embodiment, ECU nodes located on the CAN bus can generate node messages according to predetermined rules and then upload them to the CAN bus for transmission. When the receiving ECU node receives a node message at a predetermined node address, it first reads the message request identifier to see if it is a verification request. If so, it searches for the random number carried in the node message, selects a matching encryption algorithm based on the random number, and then verifies the generation time carried in the node message based on vehicle time data. After successful verification, it generates a second dynamic key using the selected encryption algorithm based on the generation time and the random number, and compares it with the first dynamic key carried in the node message. If they match, it uses the second dynamic key to decrypt the ciphertext carried in the node message to obtain valid data. Finally, it generates a response message and uploads it to the CAN bus to provide feedback to the sending ECU node. This application can achieve secure encryption and verification of messages on the CAN bus, improving transmission security and reliability.

[0060] One embodiment of this application provides a computer-readable storage medium storing at least one instruction, which is loaded and executed by a processor to implement the CAN bus-based message transmission method as described above.

[0061] One embodiment of this application provides an electronic device, which includes a processor and a memory. The memory stores at least one instruction, which is loaded and executed by the processor to implement the CAN bus-based message transmission method as described above.

[0062] One embodiment of this application provides a new energy heavy-duty vehicle, including the electronic equipment described above. Specifically, the new energy heavy-duty vehicle can be an L2 level or higher intelligent driving vehicle.

[0063] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0064] Figure 4 A schematic block diagram of an example electronic device 400 that can be used to implement embodiments of this application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0065] like Figure 4 As shown, the electronic device 400 includes a computing unit 401, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 402 or a computer program loaded from a storage unit 408 into a random access memory (RAM) 403. The RAM 403 may also store various programs and data required for the operation of the electronic device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0066] Multiple components in electronic device 400 are connected to I / O interface 405, including: input unit 406, such as keyboard, mouse, etc.; output unit 407, such as various types of displays, speakers, etc.; storage unit 408, such as disk, optical disk, etc.; and communication unit 409, such as network card, modem, wireless transceiver, etc. Communication unit 409 allows electronic device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0067] The computing unit 401 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the various methods and processes described above, such as the CAN bus-based message transmission method. For example, in some embodiments, the CAN bus-based message transmission method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 400 via ROM 402 and / or communication unit 409. When the computer program is loaded into RAM 403 and executed by the computing unit 401, one or more steps of the CAN bus-based message transmission method described above can be performed. Alternatively, in other embodiments, the computing unit 401 may be configured to perform a method of CAN bus-based message transmission by any other suitable means (e.g., by means of firmware).

[0068] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, at least one input device, and at least one output device.

[0069] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0070] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0071] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0072] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0073] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0074] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0075] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A message transmission method based on CAN bus, characterized in that, include: The first ECU node constructs at least one node message in the following manner: generates a message request identifier and a random number, and selects a matching encryption algorithm based on the random number; Based on the generation time of the message request identifier and the random number, the encryption algorithm is used to generate the first dynamic key; The first dynamic key is used to encrypt the valid data to obtain ciphertext, and the node address of the current first ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext are used to generate a node message according to a predetermined rule; The first ECU node uploads at least one generated node message to the CAN bus for transmission; The second ECU node monitors the CAN bus in real time and only receives node messages carrying pre-agreed node addresses. After the second ECU node receives the node message, if it reads that the message request identifier is a request for verification from the node message, it further searches for a random number from the node message and selects a matching encryption algorithm based on the found random number; it verifies the generation time carried in the node message based on the whole vehicle time data, and after the verification is passed, it generates a second dynamic key using the encryption algorithm based on the generation time and the found random number. The second dynamic key is compared with the first dynamic key carried in the node message. If they match, the second dynamic key is used to decrypt the ciphertext to obtain valid data. The second ECU node sends a response message to the CAN bus indicating that the message transmission was successful.

2. The method as described in claim 1, characterized in that, The message request identifier is used to indicate whether this message requires verification. If the message request identifier is 0, it indicates that there is no verification request for this message; If the message request identifier is 1, it indicates that this message has a verification request.

3. The method as described in claim 1, characterized in that, The random number is any integer between 0 and 7, and each random number is pre-matched with an encryption algorithm; and each generated random number is unique from the previous generated random number.

4. The method as described in claim 3, characterized in that, The node message is generated by combining the node address of the current ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext according to a predetermined rule. Specifically, it includes: The node address of the current ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext are arranged in a predetermined order with their respective different bits or bytes to generate a node message; wherein, the request identifier occupies 1 bit, the generation time occupies 4 bits, the random number occupies 3 bits, the first dynamic key occupies 8 bits, and the ciphertext and node address occupy the remaining 6 bytes.

5. The method as described in claim 3, characterized in that, The generation time carried in the node's message is verified based on the vehicle's overall time data, specifically including: Obtain the vehicle time data and find the sending time of the message at that node. Compare the sending time of the node message with the generation time; If the difference between the two is within the threshold range, then the generation time verification is considered successful.

6. A message transmission system based on a CAN bus, characterized in that, include: Multiple first ECU nodes for sending node messages, multiple second ECU nodes for receiving node messages, and a CAN bus; wherein, The first ECU node constructs at least one node message in the following manner: generating a message request identifier and a random number, and selecting a matching encryption algorithm based on the random number; generating a first dynamic key based on the generation time of the message request identifier and the random number using the encryption algorithm; encrypting valid data using the first dynamic key to obtain ciphertext, and generating a node message by combining the node address of the current ECU node, the request identifier, the generation time, the random number, the first dynamic key, and the ciphertext according to a predetermined rule; The first ECU node uploads at least one generated node message to the CAN bus for transmission; The second ECU node monitors the CAN bus in real time and only receives node messages carrying pre-agreed node addresses. After the second ECU node receives the node message, if it reads that the message request identifier is a verification request from the node message, it further searches for a random number from the node message and selects a matching encryption algorithm based on the found random number; it verifies the generation time carried in the node message based on the vehicle time data, and after the verification is successful, it generates a second dynamic key using the encryption algorithm based on the generation time and the found random number; it compares the second dynamic key with the first dynamic key carried in the node message, and if they match, it uses the second dynamic key to decrypt the ciphertext to obtain valid data; The second ECU node sends a response message to the CAN bus indicating that the message transmission was successful.

7. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-5.

8. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-5.

9. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-5.

10. A new energy heavy-duty vehicle, including the electronic equipment as described in claim 7.

Images