A Wireless Diagnostic Method for Motorcycles Based on a Vehicle Controller Safety Architecture
By combining the vehicle controller (VCM) with the hardware security module (HSM), the security vulnerabilities and hardware costs of motorcycle wireless diagnostic systems have been addressed, achieving efficient and secure wireless diagnostics and reducing ECU software customization and overall vehicle maintenance costs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHONGQING SHINERAY MOTORCYCLE
- Filing Date
- 2026-04-28
- Publication Date
- 2026-06-26
AI Technical Summary
Existing wireless diagnostic systems for motorcycles have security vulnerabilities, are susceptible to attacks, and increase additional hardware costs and complexity, failing to achieve efficient and secure wireless diagnostics.
By using the vehicle controller (VCM) as a security gateway and combining it with the hardware security module (HSM) for encryption verification, a secure and compatible wireless diagnostic method is established through protocol mapping and conversion, avoiding replay attacks and reducing hardware costs.
It improves the security and efficiency of wireless diagnostics, reduces additional hardware costs and vehicle resource consumption, ensures the confidentiality and real-time nature of diagnostic data, and simplifies the ECU development process.
Smart Images

Figure CN122284575A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of motorcycle safety control technology, and more specifically to a wireless diagnostic method for motorcycles based on a vehicle controller safety architecture. Background Technology
[0002] With the rapid development of automotive technology, motorcycles have gradually transformed from traditional purely mechanical transportation tools to electronic, intelligent, and connected vehicles. Modern motorcycles are generally equipped with complex electronic control units (ECUs), such as vehicle controllers (VCMs), battery management systems (BMSs), and anti-lock braking systems (ABS), to achieve precise control over vehicle power, energy consumption, and safety.
[0003] Traditional motorcycle diagnostic methods mainly rely on wired connections, meaning that repair personnel need to use dedicated diagnostic equipment to connect to the vehicle's pre-installed diagnostic interface (such as the OBD interface) via physical cables to read data and troubleshoot faults. While this method meets the needs of after-sales maintenance to some extent, it has obvious limitations: (1) It is cumbersome to operate, and users cannot complete the diagnosis themselves and must go to a professional repair station; (2) The wired connection limits the time and space range of the diagnosis, making it impossible to achieve real-time monitoring of the vehicle's status and remote health management.
[0004] To address the aforementioned issues, wireless diagnostic technology based on the mobile internet has emerged. By connecting the motorcycle to the user's mobile app (such as a smartphone) via wireless communication methods such as WiFi and Bluetooth, users can monitor the vehicle's health anytime, anywhere, and it also supports remote fault warnings, parameter calibration, and software upgrades. This is of paramount importance for improving user experience, reducing after-sales maintenance costs, and promoting the intelligentization of motorcycles.
[0005] The applicant found that the existing technical solutions still have the following urgent technical problems to be solved: (1) Most of the existing motorcycle wireless diagnostic systems directly use the traditional wired diagnostic logic and lack a dedicated security architecture for the open wireless environment. Wireless signals have broadcast characteristics and are easily intercepted or interfered with by third parties. Existing diagnostic connections usually lack strict identity authentication and encrypted handshake processes, or only use simple static password verification, which are easily susceptible to replay attacks, man-in-the-middle attacks or malicious access by illegal devices. Once an attacker invades the vehicle’s internal network through the wireless channel, he may steal sensitive vehicle information (such as VIN code, driving data) or even tamper with control commands, seriously threatening vehicle driving safety and user privacy. (2) In order to realize the wireless diagnostic function, the existing technical solutions usually need to install an independent wireless communication module (T-Box) or a dedicated diagnostic gateway on the vehicle. These additional hardware devices not only increase the material cost of the whole vehicle and the complexity of the wiring harness layout, but also occupy valuable vehicle body space. In addition, independent gateway devices often require independent power supply and management, which increases the static power consumption of the whole vehicle. Summary of the Invention
[0006] To address the shortcomings of the existing technologies, the technical problem to be solved by this invention is: how to provide a motorcycle wireless diagnostic method based on the vehicle controller security architecture, which, without increasing additional hardware costs, utilizes the vehicle controller to construct a safe, efficient, and highly compatible motorcycle wireless diagnostic method, and solves the problems of security vulnerabilities, protocol incompatibility, and low transmission efficiency existing in current motorcycle wireless diagnostic methods.
[0007] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:
[0008] A wireless diagnostic method for motorcycles based on a vehicle controller safety architecture includes:
[0009] S1: Obtain the wireless diagnostic connection request and private protocol diagnostic instructions sent by the mobile APP;
[0010] S2: Perform HSM verification on the wireless diagnostic connection request of the mobile APP through the motorcycle VCM and establish a two-way data communication channel;
[0011] S3: Send the private protocol diagnostic commands from the mobile APP to the motorcycle VCM through a two-way data communication channel; perform protocol mapping and UDS conversion on the private protocol diagnostic commands through the motorcycle VCM to generate a UDS diagnostic request message.
[0012] S4: The UDS diagnostic request message is sent to the target ECU via the motorcycle VCM, so that the target ECU performs the corresponding diagnosis based on the UDS diagnostic request message and generates UDS diagnostic response data;
[0013] S5: The motorcycle VCM performs private protocol conversion and encryption on the UDS diagnostic response data of the target ECU, and sends it back to the mobile APP through a two-way data communication channel to obtain the results of the motorcycle wireless diagnostics.
[0014] Preferably, step S2 specifically includes the following processing steps:
[0015] S201: Generate a random challenge code through the motorcycle VCM based on the wireless diagnostic connection request of the mobile APP, and send it to the mobile APP, so that the mobile APP generates an encrypted response data packet based on the random challenge code;
[0016] S202: Extract the data from the encrypted response data packet returned by the mobile APP through the motorcycle VCM, and send it to the HSM along with the random challenge code generated in step S201 and the pre-stored mobile APP public key;
[0017] S203: Verify the legitimacy of the encrypted response data packet by executing an encryption algorithm based on the mobile APP's public key using HSM: If the legitimacy verification passes, proceed to step S204; if the legitimacy verification fails, directly disconnect the wireless connection with the mobile APP.
[0018] S204: Send a confirmation message of successful HSM verification to the mobile APP via the motorcycle VCM, and activate the bidirectional data communication channel between the motorcycle VCM and the mobile APP.
[0019] Preferably, in step S201, the process of the mobile app generating an encrypted response data packet based on the random challenge code includes:
[0020] S2011: Obtain the device's unique identifier, current timestamp, session ID, and dynamic random number through the mobile app, and combine them with a random challenge code to generate response data;
[0021] S2012: Use the private key of the mobile APP to sign the response data and generate a digital signature as encrypted response data;
[0022] S2013: Encapsulate the encrypted response data with the device's unique identifier, current timestamp, session ID, and dynamic random number into a standard protocol data packet to generate an encrypted response data packet.
[0023] Preferably, in step S202, the encrypted response data, device unique identifier, current timestamp, session ID and dynamic random number in the encrypted response data packet returned by the mobile APP are extracted by the motorcycle VCM, and sent to the HSM together with the random challenge code and the pre-stored mobile APP public key;
[0024] In step S203, the process of verifying the legitimacy of the encrypted response data packet by executing the encryption algorithm based on the mobile APP's public key using HSM includes:
[0025] S2031: Decrypt the encrypted response data using the public key of the mobile APP via HSM to perform signature verification;
[0026] S2032: Verify whether the extracted random challenge code is consistent with the original generated random challenge code;
[0027] S2033: Verify whether the extracted current timestamp is within its validity period;
[0028] S2034: Verify whether the extracted device unique identifier matches an authorized device;
[0029] S2035: Verify whether the extracted session ID is within its validity period;
[0030] S2036: Verify that the extracted dynamic random numbers have not been used and are within their validity period;
[0031] S2037: If the verification in steps S2031 to S2036 all pass, the legality verification passes; otherwise, the legality verification fails.
[0032] Preferably, in step S204, if the legality verification passes, a temporary session key is generated using an encryption algorithm based on a random challenge code, the current timestamp, the device's unique identifier, the session ID, and a dynamic random number; all data transmitted through the bidirectional data communication channel is encrypted using this temporary session key.
[0033] Preferably, step S3 specifically includes the following processing steps:
[0034] S301: Receives the ciphertext of the private protocol diagnostic command encrypted by the mobile APP using a temporary session key via the motorcycle VCM, and decrypts it using the temporary session key to obtain the original private protocol diagnostic command.
[0035] S302: After performing integrity verification on the private protocol diagnostic command, extract the private service ID and diagnostic command parameters from the private protocol diagnostic command;
[0036] S303: Load the protocol mapping configuration table and match the corresponding UDS service ID and UDS parameter conversion rule from the protocol mapping configuration table based on the private service ID;
[0037] S304: Based on the UDS service ID and UDS parameter conversion rules, the diagnostic command parameters are mapped to UDS format to generate UDS diagnostic service metadata that conforms to UDS semantics;
[0038] S305: Construct the UDS diagnostic service metadata into a UDS diagnostic request message.
[0039] Preferably, in step S301, the processing steps for the mobile APP to generate private protocol diagnostic instructions include:
[0040] S3011: A private protocol data structure containing command headers, service IDs, diagnostic command parameters, and message authentication codes is pre-built via a mobile app;
[0041] S3012: Access selected diagnostic functions via mobile app;
[0042] S3013: The selected diagnostic function is mapped to a predefined private protocol data structure via a mobile APP, and the corresponding private protocol diagnostic instructions are generated.
[0043] Preferably, in step S305, a physical addressing or functional addressing mode is selected according to the type of the target ECU, a source address and a target address are generated, and the source address and target address are filled into the UDS diagnostic request message.
[0044] Preferably, in step S4, the processing steps for the target ECU to perform corresponding diagnostics based on the UDS diagnostic request message include:
[0045] S401: The target ECU determines the type of diagnostic service to be performed based on the UDS service ID in the UDS diagnostic request message;
[0046] S402: Employs a priority queue mechanism to dynamically schedule diagnostic tasks based on the urgency of the diagnostic service and system load;
[0047] S403: Invoke the corresponding diagnostic service routine to perform the diagnosis based on the diagnostic service type, and generate diagnostic service execution result data;
[0048] S404: Convert the diagnostic service execution result data into the standard UDS format to obtain diagnostic service execution result data in UDS format;
[0049] S405: Select the optimal compression method based on data characteristics to compress the diagnostic service execution result data and generate UDS diagnostic response data.
[0050] Preferably, in step S5, the process of protocol conversion and encryption of the UDS diagnostic response data of the target ECU via the motorcycle VCM includes:
[0051] S501: Parse the UDS diagnostic response data of the target ECU through the motorcycle VCM to extract the UDS service ID and diagnostic response parameters;
[0052] S502: Load the protocol mapping configuration table and match the corresponding private service ID and private parameter conversion rules from the protocol mapping configuration table based on the UDS service ID;
[0053] S503: Based on the private service ID and private parameter conversion rules, the diagnostic response parameters are mapped to the private protocol format of the mobile APP, and the corresponding diagnostic response metadata is generated.
[0054] S504: Construct the diagnostic response metadata into corresponding private protocol diagnostic response data according to the private protocol specification of the mobile APP;
[0055] S505: After encrypting the private protocol diagnostic response data based on the temporary session key, it is sent to the mobile APP through a two-way data communication channel.
[0056] Compared with existing technologies, the wireless diagnostic method for motorcycles based on the vehicle controller safety architecture of this invention has the following advantages:
[0057] This invention utilizes the VCM (Vehicle Controller) as a security gateway, introducing hardware-level encryption verification based on HSM (Hardware Security Module) at the initial stage of wireless connection establishment. Combined with a multi-factor authentication mechanism using random challenge codes, digital signatures, and timestamps, it effectively prevents replay attacks and unauthorized device access, ensuring the uniqueness and immutability of the diagnostic channel. Simultaneously, the security authentication scheduling mechanism introduced by the VCM dynamically adjusts the priority of diagnostic requests based on the current system load, avoiding diagnostic lag or communication timeouts caused by high background load tasks in traditional wireless diagnostics. This achieves isolation and coordination between diagnostic services and core vehicle control services. This invention's solution achieves a high level of security protection using the existing computing power of the VCM without adding additional independent security gateway hardware, ensuring both the security of wireless diagnostics and improving the resource utilization efficiency of the vehicle's electronic architecture.
[0058] This invention establishes a mapping mechanism between a proprietary protocol and the standard UDS (Unified Diagnostic Service) protocol within the VCM (Vehicle Management Module). This allows mobile apps to communicate using a lightweight, high-compression proprietary protocol without directly handling complex transport layer protocols. This design enables mobile apps to send commands in simple JSON or binary format, which are then uniformly converted into standard UDS messages by the VCM. This not only reduces the development complexity and adaptation costs of mobile apps but also results in smaller data packets for wireless transmission, significantly improving transmission efficiency in bandwidth-constrained environments such as WiFi / BLE. Furthermore, protocol conversion via the VCM allows aftermarket ECUs or older ECUs to support new wireless diagnostic functions without firmware upgrades, greatly reducing the maintenance costs and hardware upgrade barriers of the entire vehicle system and achieving backward compatibility of the diagnostic system.
[0059] In the design of this invention, the target ECU (such as BMS) only needs to perform diagnostic tasks according to the standard UDS protocol specification, without requiring special software modifications or protocol adaptations for wireless diagnostic scenarios. The VCM handles all the complex wireless handshake, security verification, and protocol conversion. For the target ECU, the diagnostic request is equivalent to coming from a standard in-vehicle wired diagnostic tool. This design shields the instability risks of wireless communication, simplifies the development process for each ECU, and eliminates the need to develop separate interfaces for wireless functions. This significantly reduces the software customization cost of the ECU and the overall wireless diagnostic cost of the vehicle, while ensuring the real-time performance and accuracy of diagnostic execution.
[0060] This invention utilizes VCM to convert standard UDS response data (containing a lot of redundant information) into a simplified private protocol format and encrypts it with a session key in the data backhaul path. This reduces the amount of data transmitted back to the mobile app via the wireless link, effectively reducing the probability of wireless channel congestion. Simultaneously, the encryption mechanism based on temporary session keys ensures the confidentiality of diagnostic data during air interface transmission, preventing sensitive vehicle data (such as VIN code and battery status) from being sniffed or stolen by third parties. The solution designed in this invention optimizes user experience while ensuring data security and privacy, achieving an efficient and secure wireless diagnostic closed loop. Attached Figure Description
[0061] To make the objectives, technical solutions, and advantages of the invention clearer, the invention will now be described in further detail with reference to the accompanying drawings, wherein:
[0062] Figure 1 This is a logic block diagram of a motorcycle wireless diagnostic method based on a vehicle controller safety architecture.
[0063] Figure 2 This is a network structure diagram of a motorcycle wireless diagnostic method based on a vehicle controller safety architecture. Detailed Implementation
[0064] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but only to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.
[0065] The following detailed explanation illustrates the specific implementation methods:
[0066] Example:
[0067] This embodiment discloses a wireless diagnostic method for motorcycles based on a vehicle controller security architecture.
[0068] like Figure 1 and Figure 2 As shown, a wireless diagnostic method for motorcycles based on a vehicle controller safety architecture includes:
[0069] S1: Obtain the wireless diagnostic connection request (including device identity information and encrypted handshake packet) and private protocol diagnostic instructions sent by the mobile APP;
[0070] In this embodiment, the mobile APP transmits the wireless diagnostic connection request to the vehicle management platform (TSP), which then transmits it to the motorcycle VCM. The transmitted data can use CAN communication format or a custom data format and verification between the VCM and TSP, and data transmission verification is performed via SPI / I2C / UART.
[0071] S2: The motorcycle VCM (vehicle controller) performs security authentication scheduling and HSM (hardware security module) verification on the wireless diagnostic connection request of the mobile APP, and establishes a bidirectional data communication channel that passes the HSM verification and is mapped to the internal diagnostic bus.
[0072] S3: Send the private protocol diagnostic command of the mobile APP to the motorcycle VCM through the bidirectional data communication channel; After the motorcycle VCM performs protocol mapping and UDS (Unified Diagnostic Service) conversion on the private protocol diagnostic command, a UDS diagnostic request message is generated.
[0073] S4: The UDS diagnostic request message is sent to the target ECU via the motorcycle VCM, so that the target ECU performs the corresponding diagnosis based on the UDS diagnostic request message and generates UDS diagnostic response data;
[0074] In this embodiment, the motorcycle VCM sends the UDS diagnostic request message to the vehicle local area network bus in the form of a level signal through the CAN controller driver; after the target ECU (such as BMS) connected to the vehicle local area network bus recognizes its own CANID, it receives the corresponding UDS diagnostic request message.
[0075] S5: The motorcycle VCM performs private protocol conversion and encryption on the UDS diagnostic response data of the target ECU, and sends it back to the mobile APP through a two-way data communication channel to obtain the results of the motorcycle wireless diagnostics.
[0076] In this embodiment, the UDS diagnostic response data of the target ECU is converted and encrypted using a private protocol by the motorcycle VCM and then sent to the TSP. The TSP transmits the data to the mobile APP via WiFi / BLE. The mobile APP decrypts the encrypted data and then displays the diagnostic information after parsing it using the built-in data protocol parsing packet.
[0077] To better illustrate the technical solution of the present invention, this embodiment will be described in more detail through the following parts.
[0078] I. HSM verification of motorcycle VCM
[0079] Step S2 specifically includes the following processing steps:
[0080] S201: Generate a random challenge code through the motorcycle VCM based on the wireless diagnostic connection request of the mobile APP, and send it to the mobile APP, so that the mobile APP generates an encrypted response data packet based on the random challenge code;
[0081] In this embodiment, the motorcycle VCM first determines the priority of the wireless diagnostic connection request, and then checks the current system load and diagnostic task queue status. If the system is in a high-priority task (such as riding control), the connection request is placed in the waiting queue; if it is idle, the security authentication scheduling process is triggered immediately.
[0082] S202: Extract the data from the encrypted response data packet returned by the mobile APP through the motorcycle VCM, and send it to the HSM along with the random challenge code generated in step S201 and the pre-stored mobile APP public key;
[0083] S203: Verify the legitimacy of the encrypted response data packet by executing an encryption algorithm based on the mobile APP's public key using HSM: If the legitimacy verification passes, proceed to step S204; if the legitimacy verification fails, directly disconnect the wireless connection with the mobile APP, trigger a security alarm, and record the failure log.
[0084] S204: Send a confirmation message confirming successful HSM verification to the mobile app via the motorcycle VCM, and activate the bidirectional data communication channel between the motorcycle VCM and the mobile app. Specifically, first, an internal authentication token is generated and marked as valid, while recording the validity period; then, the isolation relay (or electronic switch) of the internal diagnostic bus interface is activated; finally, the wireless diagnostic channel is physically connected to the internal diagnostic bus, and the internal authentication token is written into the security context of the communication link for timeliness verification of subsequent data interactions.
[0085] In this embodiment, all subsequent diagnostic data (such as fault code readings and parameter calibrations) are transmitted on the mapped internal diagnostic bus through this bidirectional data communication channel. During communication, the motorcycle VCM monitors the validity period of the safety context in real time, and automatically disconnects the bus mapping if the timeout occurs.
[0086] Specifically, the processing steps for a mobile app to generate an encrypted response data packet based on a random challenge code include:
[0087] S2011: Obtain the device's unique identifier (such as VIN code), current timestamp, session ID, and dynamic random number through the mobile APP, and combine them with the random challenge code to generate response data;
[0088] S2012: Use the private key of the mobile APP to sign the response data (such as the national cryptographic SM2 digital signature algorithm) and generate a digital signature as encrypted response data;
[0089] In other preferred embodiments, a digital signature can be generated using an asymmetric RSA algorithm, where the mobile app's private key is an RSA private key. The hash value (such as SHA-256) of the response data is encrypted using the RSA private key to generate an RSA digital signature.
[0090] S2013: Encapsulate the encrypted response data with the device's unique identifier, current timestamp, session ID, and dynamic random number into a standard protocol data packet to generate an encrypted response data packet.
[0091] Specifically, the encrypted response data, device unique identifier, current timestamp, session ID, and dynamic random number are extracted from the encrypted response data packet returned by the mobile APP through the motorcycle VCM, and sent to the HSM along with the random challenge code and the pre-stored mobile APP public key;
[0092] The steps involved in verifying the legitimacy of the encrypted response data packet by executing an encryption algorithm based on the mobile app's public key using HSM include:
[0093] S2031: Decrypt the encrypted response data using the public key of the mobile APP via HSM to perform signature verification;
[0094] S2032: Verify whether the extracted random challenge code is consistent with the original generated random challenge code;
[0095] S2033: Verify whether the extracted current timestamp is within its validity period;
[0096] S2034: Verify whether the extracted device unique identifier matches an authorized device;
[0097] S2035: Verify whether the extracted session ID is within its validity period;
[0098] S2036: Verify that the extracted dynamic random numbers have not been used and are within their validity period;
[0099] S2037: If the verification in steps S2031 to S2036 all pass, the legality verification passes; otherwise, the legality verification fails.
[0100] Specifically, if the legitimacy verification passes, a temporary session key is generated using an encryption algorithm based on a random challenge code, the current timestamp, the device's unique identifier, the session ID, and a dynamic random number; all data transmitted through the bidirectional data communication channel is encrypted using this temporary session key.
[0101] This invention utilizes the VCM (Vehicle Controller) as a security gateway, introducing hardware-level encryption verification based on HSM (Hardware Security Module) at the initial stage of wireless connection establishment. Combined with a multi-factor authentication mechanism using random challenge codes, digital signatures, and timestamps, it effectively prevents replay attacks and unauthorized device access, ensuring the uniqueness and immutability of the diagnostic channel. Simultaneously, the security authentication scheduling mechanism introduced by the VCM dynamically adjusts the priority of diagnostic requests based on the current system load, avoiding diagnostic lag or communication timeouts caused by high background load tasks in traditional wireless diagnostics. This achieves isolation and coordination between diagnostic services and core vehicle control services. This invention's solution achieves a high level of security protection using the existing computing power of the VCM without adding additional independent security gateway hardware, ensuring both the security of wireless diagnostics and improving the resource utilization efficiency of the vehicle's electronic architecture.
[0102] II. Protocol Mapping and UDS Conversion
[0103] Step S3 specifically includes the following processing steps:
[0104] S301: Receives the ciphertext of the private protocol diagnostic command encrypted by the mobile APP using a temporary session key via the motorcycle VCM, and decrypts it using the temporary session key to obtain the original private protocol diagnostic command; wherein the temporary session key can be an SM4 key, and the corresponding encryption algorithm adopts the SM4 symmetric encryption algorithm.
[0105] It should be noted that the SM4 symmetric encryption algorithm can also be applied to vehicle control interaction.
[0106] S302: After performing integrity verification on the message authentication code (MAC) and magic number of the private protocol diagnostic command (filtering out illegal or corrupt messages), extract the private service ID and diagnostic command parameters from the private protocol diagnostic command.
[0107] S303: Load the protocol mapping configuration table stored in Flash, and match the corresponding UDS service ID and UDS parameter conversion rule from the protocol mapping configuration table based on the private service ID; wherein, the protocol mapping configuration table defines the mapping relationship between the private protocol service ID and the UDS service ID, as well as the private or UDS parameter conversion rule (such as parameter scaling factor, byte order conversion).
[0108] S304: Based on the UDS service ID and UDS parameter conversion rules, the diagnostic command parameters are mapped to the standard UDS format to generate UDS diagnostic service metadata that conforms to UDS semantics (the UDS diagnostic service metadata includes UDS service ID, sub-function, DID / RoutineID, and request data).
[0109] S305: Construct UDS diagnostic service metadata into a UDS diagnostic request message according to ISO15765-2 (transmission protocol) or directly according to the CAN frame format.
[0110] Specifically, in step S301, the processing steps for the mobile APP to generate private protocol diagnostic instructions include:
[0111] S3011: A private protocol data structure is pre-built via a mobile APP, which includes a command header (containing a magic number identifier), a service ID (clearly identifying the diagnostic service type, such as "0x01" indicating reading battery voltage), diagnostic command parameters (specific parameter values stored in JSON or binary format), and a message authentication code (used for integrity verification).
[0112] S3012: Obtain the diagnostic function selected by the user on the APP interface (such as "read fault codes") through the mobile APP.
[0113] S3013: The diagnostic function selected by the user is mapped to a predefined private protocol data structure through the mobile APP, and the corresponding private protocol diagnostic instructions are generated.
[0114] Specifically, based on the type of the target ECU, select the physical addressing or functional addressing mode, generate the source address (TesterAddress) and the target address, and fill the source address and target address into the UDS diagnostic request message.
[0115] In this embodiment, if the data length of the UDS diagnostic request message is less than the standard frame length, it is automatically padded with 0x00, and a CRC checksum is calculated and inserted.
[0116] This invention establishes a mapping mechanism between a proprietary protocol and the standard UDS (Unified Diagnostic Service) protocol within the VCM (Vehicle Management Module). This allows mobile apps to communicate using a lightweight, high-compression proprietary protocol without directly handling complex transport layer protocols. This design enables mobile apps to send commands in simple JSON or binary format, which are then uniformly converted into standard UDS messages by the VCM. This not only reduces the development complexity and adaptation costs of mobile apps but also results in smaller data packets for wireless transmission, significantly improving transmission efficiency in bandwidth-constrained environments such as WiFi / BLE. Furthermore, protocol conversion via the VCM allows aftermarket ECUs or older ECUs to support new wireless diagnostic functions without firmware upgrades, greatly reducing the maintenance costs and hardware upgrade barriers of the entire vehicle system and achieving backward compatibility of the diagnostic system.
[0117] III. ECU Diagnosis
[0118] In the specific implementation process, the target ECU performs the corresponding diagnostic processing steps based on the UDS diagnostic request message, including:
[0119] S401: The target ECU determines the type of diagnostic service to be performed based on the UDS service ID in the UDS diagnostic request message;
[0120] S402: Employs a priority queue mechanism to dynamically schedule diagnostic tasks based on the urgency of the diagnostic service and system load;
[0121] S403: Based on the diagnostic service type, call the corresponding diagnostic service routine to perform the diagnosis (such as reading internal sensor data, executing a self-test program, or modifying control parameters) and generate diagnostic service execution result data;
[0122] S404: Convert the diagnostic service execution result data into a standard UDS format (e.g., convert binary status codes into a standard response format) to obtain diagnostic service execution result data in UDS format;
[0123] S405: Adaptive data compression algorithm is used to select the optimal compression method based on data characteristics to compress the diagnostic service execution result data in UDS format and generate UDS diagnostic response data.
[0124] In the design of this invention, the target ECU (such as BMS) only needs to perform diagnostic tasks according to the standard UDS protocol specification, without requiring special software modifications or protocol adaptations for wireless diagnostic scenarios. The VCM handles all the complex wireless handshake, security verification, and protocol conversion. For the target ECU, the diagnostic request is equivalent to coming from a standard in-vehicle wired diagnostic tool. This design shields the instability risks of wireless communication, simplifies the development process for each ECU, and eliminates the need to develop separate interfaces for wireless functions. This significantly reduces the software customization cost of the ECU and the overall wireless diagnostic cost of the vehicle, while ensuring the real-time performance and accuracy of diagnostic execution.
[0125] IV. Protocol Conversion and Encryption
[0126] In the specific implementation process, the steps of protocol conversion and encryption of the UDS diagnostic response data of the target ECU through the motorcycle VCM include:
[0127] S501: Parse the UDS diagnostic response data of the target ECU through the motorcycle VCM to extract the UDS service ID, sub-function, data identifier (DID) and diagnostic response parameters;
[0128] S502: Load the protocol mapping configuration table stored in Flash, and match the corresponding private service ID and private parameter conversion rule from the protocol mapping configuration table based on the UDS service ID;
[0129] S503: Based on the private service ID and private parameter conversion rules, the diagnostic response parameters are mapped to the private protocol format of the mobile APP, and the corresponding diagnostic response metadata is generated.
[0130] S504: Construct the diagnostic response metadata into corresponding private protocol diagnostic response data according to the private protocol specification of the mobile APP, and add magic number identifier and service identifier.
[0131] S505: After encrypting the private protocol diagnostic response data based on the temporary session key, it is sent to the mobile APP through a two-way data communication channel.
[0132] This invention utilizes VCM to convert standard UDS response data (containing a lot of redundant information) into a simplified private protocol format and encrypts it with a session key in the data backhaul path. This reduces the amount of data transmitted back to the mobile app via the wireless link, effectively reducing the probability of wireless channel congestion. Simultaneously, the encryption mechanism based on temporary session keys ensures the confidentiality of diagnostic data during air interface transmission, preventing sensitive vehicle data (such as VIN code and battery status) from being sniffed or stolen by third parties. The solution designed in this invention optimizes user experience while ensuring data security and privacy, achieving an efficient and secure wireless diagnostic closed loop.
[0133] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit the technical solutions. Those skilled in the art should understand that any modifications or equivalent substitutions to the technical solutions of the present invention without departing from the spirit and scope of the present invention should be covered within the scope of the claims of the present invention.
Claims
1. A wireless diagnostic method for motorcycles based on a vehicle controller safety architecture, characterized in that, include: S1: Obtain the wireless diagnostic connection request and private protocol diagnostic instructions sent by the mobile APP; S2: Perform HSM verification on the wireless diagnostic connection request of the mobile APP through the motorcycle VCM and establish a two-way data communication channel; S3: Send the private protocol diagnostic commands from the mobile APP to the motorcycle VCM through a two-way data communication channel; perform protocol mapping and UDS conversion on the private protocol diagnostic commands through the motorcycle VCM to generate a UDS diagnostic request message. S4: The UDS diagnostic request message is sent to the target ECU via the motorcycle VCM, so that the target ECU performs the corresponding diagnosis based on the UDS diagnostic request message and generates UDS diagnostic response data; S5: The motorcycle VCM performs private protocol conversion and encryption on the UDS diagnostic response data of the target ECU, and sends it back to the mobile APP through a two-way data communication channel to obtain the results of the motorcycle wireless diagnostics.
2. The motorcycle wireless diagnostic method based on a vehicle controller security architecture as described in claim 1, characterized in that: Step S2 specifically includes the following processing steps: S201: Generate a random challenge code through the motorcycle VCM based on the wireless diagnostic connection request of the mobile APP, and send it to the mobile APP, so that the mobile APP generates an encrypted response data packet based on the random challenge code; S202: Extract the data from the encrypted response data packet returned by the mobile APP through the motorcycle VCM, and send it to the HSM along with the random challenge code generated in step S201 and the pre-stored mobile APP public key; S203: Verify the legitimacy of the encrypted response data packet by executing an encryption algorithm based on the mobile APP's public key using HSM: If the legitimacy verification passes, proceed to step S204; if the legitimacy verification fails, directly disconnect the wireless connection with the mobile APP. S204: Send a confirmation message of successful HSM verification to the mobile APP via the motorcycle VCM, and activate the bidirectional data communication channel between the motorcycle VCM and the mobile APP.
3. The motorcycle wireless diagnostic method based on a vehicle controller safety architecture as described in claim 2, characterized in that: In step S201, the processing steps for the mobile app to generate an encrypted response data packet based on the random challenge code include: S2011: Obtain the device's unique identifier, current timestamp, session ID, and dynamic random number through the mobile app, and combine them with a random challenge code to generate response data; S2012: Use the private key of the mobile APP to sign the response data and generate a digital signature as encrypted response data; S2013: Encapsulate the encrypted response data with the device's unique identifier, current timestamp, session ID, and dynamic random number into a standard protocol data packet to generate an encrypted response data packet.
4. The motorcycle wireless diagnostic method based on a vehicle controller safety architecture as described in claim 3, characterized in that: In step S202, the encrypted response data, device unique identifier, current timestamp, session ID and dynamic random number in the encrypted response data packet returned by the mobile APP are extracted by the motorcycle VCM and sent to HSM along with the random challenge code and the pre-stored mobile APP public key. In step S203, the process of verifying the legitimacy of the encrypted response data packet by executing the encryption algorithm based on the mobile APP's public key using HSM includes: S2031: Decrypt the encrypted response data using the public key of the mobile APP via HSM to perform signature verification; S2032: Verify whether the extracted random challenge code is consistent with the original generated random challenge code; S2033: Verify whether the extracted current timestamp is within its validity period; S2034: Verify whether the extracted device unique identifier matches an authorized device; S2035: Verify whether the extracted session ID is within its validity period; S2036: Verify that the extracted dynamic random numbers have not been used and are within their validity period; S2037: If the verification in steps S2031 to S2036 all pass, the legality verification passes; otherwise, the legality verification fails.
5. A motorcycle wireless diagnostic method based on a vehicle controller safety architecture as described in claim 2, characterized in that: In step S204, if the legality verification passes, a temporary session key is generated using an encryption algorithm based on a random challenge code, the current timestamp, the device's unique identifier, the session ID, and a dynamic random number. All data transmitted through the two-way data communication channel is encrypted using this temporary session key.
6. The motorcycle wireless diagnostic method based on a vehicle controller safety architecture as described in claim 5, characterized in that: Step S3 specifically includes the following processing steps: S301: Receives the ciphertext of the private protocol diagnostic command encrypted by the mobile APP using a temporary session key via the motorcycle VCM, and decrypts it using the temporary session key to obtain the original private protocol diagnostic command. S302: After performing integrity verification on the private protocol diagnostic command, extract the private service ID and diagnostic command parameters from the private protocol diagnostic command; S303: Load the protocol mapping configuration table and match the corresponding UDS service ID and UDS parameter conversion rule from the protocol mapping configuration table based on the private service ID; S304: Based on the UDS service ID and UDS parameter conversion rules, the diagnostic command parameters are mapped to UDS format to generate UDS diagnostic service metadata that conforms to UDS semantics; S305: Construct the UDS diagnostic service metadata into a UDS diagnostic request message.
7. The motorcycle wireless diagnostic method based on a vehicle controller safety architecture as described in claim 6, characterized in that: In step S301, the processing steps for the mobile APP to generate private protocol diagnostic instructions include: S3011: A private protocol data structure containing command headers, service IDs, diagnostic command parameters, and message authentication codes is pre-built via a mobile app; S3012: Access selected diagnostic functions via mobile app; S3013: The selected diagnostic function is mapped to a predefined private protocol data structure via a mobile APP, and the corresponding private protocol diagnostic instructions are generated.
8. A motorcycle wireless diagnostic method based on a vehicle controller security architecture as described in claim 6, characterized in that: In step S305, physical addressing or functional addressing mode is selected according to the type of the target ECU, source address and target address are generated, and the source address and target address are filled into the UDS diagnostic request message.
9. A motorcycle wireless diagnostic method based on a vehicle controller safety architecture as described in claim 6, characterized in that: In step S4, the target ECU performs the corresponding diagnostic processing steps based on the UDS diagnostic request message, including: S401: The target ECU determines the type of diagnostic service to be performed based on the UDS service ID in the UDS diagnostic request message; S402: Employs a priority queue mechanism to dynamically schedule diagnostic tasks based on the urgency of the diagnostic service and system load; S403: Invoke the corresponding diagnostic service routine to perform the diagnosis based on the diagnostic service type, and generate diagnostic service execution result data; S404: Convert the diagnostic service execution result data into the standard UDS format to obtain diagnostic service execution result data in UDS format; S405: Select the optimal compression method based on data characteristics to compress the diagnostic service execution result data and generate UDS diagnostic response data.
10. The motorcycle wireless diagnostic method based on a vehicle controller security architecture as described in claim 1, characterized in that: Step S5, the process of protocol conversion and encryption of the UDS diagnostic response data of the target ECU via the motorcycle VCM, includes: S501: Parse the UDS diagnostic response data of the target ECU through the motorcycle VCM to extract the UDS service ID and diagnostic response parameters; S502: Load the protocol mapping configuration table and match the corresponding private service ID and private parameter conversion rules from the protocol mapping configuration table based on the UDS service ID; S503: Based on the private service ID and private parameter conversion rules, the diagnostic response parameters are mapped to the private protocol format of the mobile APP, and the corresponding diagnostic response metadata is generated. S504: Construct the diagnostic response metadata into corresponding private protocol diagnostic response data according to the private protocol specification of the mobile APP; S505: After encrypting the private protocol diagnostic response data based on the temporary session key, it is sent to the mobile APP through a two-way data communication channel.