Control device, method, and vehicle

Abstract

This application relates to the field of vehicle technology, and more particularly to the field of vehicle control technology, specifically to a control device, method, and vehicle, the purpose of which is to be compatible with the transmission and processing of messages of different formats. The device includes: a CANTP module, a PDUR module, and a DCM module; the CANTP module is configured to: in response to an acquired diagnostic request message, identify the message type of the diagnostic request message; store the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message; the message type includes CAN type or CANFD type; the same message identifier of the diagnostic request message supports both CAN type and CANFD type; the PDUR module is configured to: read the diagnostic request message from the shared buffer; transmit the diagnostic request message to the DCM module; the DCM module is configured to: based on the message identifier of the diagnostic request message, schedule the diagnostic service corresponding to the message identifier to diagnose the diagnostic request message; thereby improving the processing efficiency of the diagnostic request message.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more particularly to the field of vehicle control technology, specifically to a control device, method, and vehicle. Background Technology

[0002] Currently, with the accelerated development of vehicle intelligence and electrification, the number of vehicle electronic control units (ECUs) is surging. This has led to complex diagnostic communication needs that do not rely on ECUs, characterized by high bandwidth, low latency, and the coexistence of multiple protocols. In actual vehicle diagnostics, two diagnostic services are generally used: UDS and OBD. Both services are compatible with CAN and CANFD message types.

[0003] However, in the application messages of a vehicle's CAN network, a single ID typically only identifies one message type, namely either CAN-type messages or CANFD-type messages. Therefore, when the same message identifier is reused by different protocols, inaccurate message type identification can easily occur, leading to diagnostic service mismatch issues. Summary of the Invention

[0004] This application provides a control device, method, and vehicle to at least address the technical problem of insufficient accuracy in scheduling diagnostic services in related technologies. The technical solution adopted in this application is as follows: In a first aspect, this application provides a control device comprising: a CANTP module, a PDUR module, and a DCM module; the CANTP module is configured to: in response to an acquired diagnostic request message, identify the message type of the diagnostic request message; store the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message; the message type includes CAN type or CANFD type; the same message identifier of the diagnostic request message supports both CAN type and CANFD type; the PDUR module is configured to: read the diagnostic request message from the shared buffer; transmit the diagnostic request message to the DCM module; the DCM module is configured to: based on the message identifier of the diagnostic request message, schedule a diagnostic service corresponding to the message identifier to diagnose the diagnostic request message; the diagnostic service includes UDS diagnostic service or OBD diagnostic service.

[0005] Based on the aforementioned technical means, the CANTP module of this application can enhance the compatibility of message processing by accurately identifying the message type of the diagnostic request message and storing diagnostic request messages of different message types in the corresponding shared buffer. Based on this, the PDUR module reads the diagnostic request message from the shared buffer and transmits it to the DCM module for scheduling the diagnostic service corresponding to the diagnostic request message, which can realize the response to the diagnostic request message more quickly and improve the processing efficiency of the diagnostic request message.

[0006] In one possible implementation, the CANTP module is configured to store diagnostic request messages in a shared buffer corresponding to the message identifier and message type of the diagnostic request message, including: if the type of the diagnostic request message is CAN, storing the diagnostic request message in a first shared buffer corresponding to the message identifier and CAN type of the diagnostic request message; or, if the type of the diagnostic request message is CANFD, storing the diagnostic request message in a second shared buffer corresponding to the message identifier and CANFD type of the diagnostic request message.

[0007] Based on the above technical means, this application can avoid mutual interference between different types of diagnostic request messages by storing different types of diagnostic request messages in different shared cache areas, ensure the data accuracy of diagnostic request messages, and avoid data reading errors caused by mixed storage.

[0008] In one possible implementation, the CANTP module is further configured to: identify the control bit identifier of the diagnostic request message in response to the acquired diagnostic request message; determine the type of the diagnostic request message based on the control bit identifier; wherein, when the control bit identifier is a first value, the type of the diagnostic request message is CAN type; and when the control bit identifier is a second value, the type of the diagnostic request message is CANFD type.

[0009] Based on the above technical means, this application uses different control bit identifiers to determine the type of diagnostic request message, which can more accurately and effectively distinguish diagnostic request messages.

[0010] In one possible implementation, the control device further includes a DEM module; the DCM module is configured to schedule diagnostic services corresponding to the message identifier based on the message identifier of the diagnostic request message, including: feeding back the message identifier to the DEM module, obtaining a diagnostic service table corresponding to the message identifier from the DEM module; and calling the corresponding diagnostic service to diagnose the diagnostic request message based on the diagnostic service table.

[0011] Based on the above technical means, this application schedules diagnostic services by using a diagnostic service table corresponding to the message identifier of the diagnostic request message, which can achieve fast and accurate matching and improve service scheduling efficiency.

[0012] In one possible implementation, the DEM module is configured to: obtain the message identifier of the diagnostic request message fed back by the DCM module, compare the message identifier with a preset identifier threshold, determine the diagnostic service table corresponding to the diagnostic request message based on the comparison result; the diagnostic service table includes a UDS diagnostic service table and an OBD diagnostic service table; and send the diagnostic service table corresponding to the diagnostic request message to the DCM module.

[0013] Based on the above technical means, this application compares the message identifier of the diagnostic request message with a preset identifier threshold, and can determine the diagnostic service table corresponding to the diagnostic request message based on the relative size of the message identifier and the preset identifier threshold. This can more efficiently locate the diagnostic service table corresponding to the diagnostic request message and improve the processing efficiency of the diagnostic request message.

[0014] In one possible implementation, the DEM module is configured to determine the diagnostic service table corresponding to the diagnostic request message based on the comparison result, including: if the message identifier is greater than a preset identifier threshold, determining the diagnostic service table corresponding to the diagnostic request message as the UDS diagnostic service table; or, if the message identifier is not greater than the preset identifier threshold, determining the diagnostic service table corresponding to the diagnostic request message as the OBD diagnostic service table.

[0015] Based on the aforementioned technical means, this application, by using a preset identification threshold as a boundary, can more quickly and clearly distinguish diagnostic service types, greatly improving the efficiency of determining the diagnostic service table; it also increases the flexibility of determining diagnostic services, and in the case of adding or adjusting diagnostic service types, it can be quickly achieved simply by modifying the preset identification threshold.

[0016] In one possible implementation, the CANTP module is configured to store the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message, including: segmenting the diagnostic request message into multiple fragments when the data length of the diagnostic request message is greater than a preset data length; storing each fragment of the diagnostic request message into the shared buffer corresponding to the message identifier and message type of the diagnostic request message; the PDUR module is configured to read the diagnostic request message from the shared buffer, including: reading multiple fragments of the diagnostic request message from the shared buffer; and concatenating the multiple fragments of the diagnostic request message to obtain the diagnostic request message.

[0017] Based on the above technical means, this application can reduce the amount of data stored at one time by segmenting the diagnostic request message and storing it in the shared cache area, thereby avoiding excessive cache resources occupied due to excessive message length and improving storage efficiency; based on this, the integrity of the message can be guaranteed by reading the diagnostic request message from the shared cache area and then splicing the message.

[0018] Secondly, this application provides a control method applied to the CANTP module of the control device described in the first aspect. The control method includes: receiving a diagnostic request message; identifying the message type of the diagnostic request message in response to the diagnostic request message; and storing the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message, so that the PDUR module can read the diagnostic request message from the shared buffer. The message type includes CAN type or CANFD type; the same message identifier of the diagnostic request message supports both CAN type and CANFD type; the diagnostic request message is applied to the DCM module; the DCM module is configured to schedule a diagnostic service corresponding to the message identifier to diagnose the diagnostic request message based on the message identifier of the diagnostic request message; the diagnostic service includes UDS diagnostic service or OBD diagnostic service.

[0019] Based on the aforementioned technical means, this application enhances the compatibility of message processing by accurately identifying the message type of the diagnostic request message and storing diagnostic request messages of different message types in the corresponding shared buffer. Based on this, the PDUR module reads the diagnostic request message from the shared buffer and transmits it to the DCM module for scheduling the diagnostic service corresponding to the diagnostic request message, which can realize the response to the diagnostic request message more quickly and improve the processing efficiency of the diagnostic request message.

[0020] In one possible implementation, storing the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message includes: if the type of the diagnostic request message is CAN, storing the diagnostic request message in a first shared buffer corresponding to the message identifier and CAN type of the diagnostic request message; or, if the type of the diagnostic request message is CANFD, storing the diagnostic request message in a second shared buffer corresponding to the message identifier and CANFD type of the diagnostic request message.

[0021] In one possible implementation, in response to a diagnostic request message, identifying the message type of the diagnostic request message includes: in response to the acquired diagnostic request message, identifying the control bit identifier of the diagnostic request message; determining the type of the diagnostic request message based on the control bit identifier; wherein, when the control bit identifier is a first value, the type of the diagnostic request message is CAN type; and when the control bit identifier is a second value, the type of the diagnostic request message is CANFD type.

[0022] In one possible implementation, based on the message identifier of the diagnostic request message, the diagnostic service corresponding to the message identifier is scheduled, including: the DCM module feeding back the message identifier to the DEM module, obtaining the diagnostic service table corresponding to the message identifier from the DEM module; and based on the diagnostic service table, calling the corresponding diagnostic service to diagnose the diagnostic request message.

[0023] In one possible implementation, the DCM module sends a message identifier back to the DEM module and obtains the diagnostic service table corresponding to the message identifier from the DEM module. This includes: obtaining the message identifier of the diagnostic request message sent back by the DCM module, comparing the message identifier with a preset identifier threshold, and determining the diagnostic service table corresponding to the diagnostic request message based on the comparison result; the diagnostic service table includes a UDS diagnostic service table and an OBD diagnostic service table; and sending the diagnostic service table corresponding to the diagnostic request message to the DCM module.

[0024] In one possible implementation, determining the diagnostic service table corresponding to the diagnostic request message based on the comparison result includes: if the message identifier is greater than a preset identifier threshold, determining the diagnostic service table corresponding to the diagnostic request message as the UDS diagnostic service table; or, if the message identifier is not greater than the preset identifier threshold, determining the diagnostic service table corresponding to the diagnostic request message as the OBD diagnostic service table.

[0025] In one possible implementation, storing the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message includes: if the data length of the diagnostic request message is greater than a preset data length, segmenting the diagnostic request message into multiple fragments of the diagnostic request message; storing each fragment of the diagnostic request message into the shared buffer corresponding to the message identifier and message type of the diagnostic request message, so that the PDUR module can read the multiple fragments of the diagnostic request message from the shared buffer; and concatenating the multiple fragments of the diagnostic request message to obtain the diagnostic request message.

[0026] Thirdly, this application provides a vehicle that includes the control device described in the first aspect.

[0027] Fourthly, this application provides an electronic device, including: a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the method described in the first aspect and any possible implementation thereof.

[0028] Fifthly, this application provides a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the methods described in the first aspect and any possible implementation thereof.

[0029] In a sixth aspect, this application provides a computer program product comprising computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect and any of its possible implementations.

[0030] It should be noted that the technical effects of any of the implementation methods in aspects two through six can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here.

[0031] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0032] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application, and do not constitute an undue limitation of this application.

[0033] Figure 1 This is a schematic diagram of the structure of a vehicle shown in an embodiment of this application; Figure 2 This is a block diagram illustrating a control device according to an embodiment of this application; Figure 3 This is a block diagram of another control device shown in the embodiments of this application; Figure 4 This is a flowchart illustrating a control method according to an embodiment of this application; Figure 5 This is a schematic diagram illustrating the control principle of a control method according to an embodiment of this application; Figure 6 This is a schematic diagram illustrating the control principle of another control method shown in the embodiments of this application; Figure 7 This is a block diagram illustrating an electronic device according to an embodiment of this application. Detailed Implementation

[0034] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0035] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0036] In the embodiments of this application, the words "exemplary," "for example," or "for instance" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the words "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a specific manner.

[0037] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0038] The control device provided in this application embodiment is used to process diagnostic request messages received by a vehicle (especially an intelligent driving vehicle). A vehicle can also be referred to as a vehicle, mobile carrier, electric vehicle (EV), hybrid electric vehicle (HEV), plug-in hybrid electric vehicle (PHEV), fuel cell vehicle (FCV), autonomous vehicle, intelligent and connected vehicle (ICV), driverless vehicle, etc.

[0039] In this application, the vehicle can be a sedan, a sport utility vehicle (SUV), a truck, a special vehicle (such as an ambulance, fire truck, police car, etc.), a driverless taxi, a smart connected bus, an autonomous logistics vehicle, an electric truck, etc. Furthermore, this method is also applicable to various special-purpose vehicles, such as agricultural vehicles, mining vehicles, forestry vehicles, airport vehicles, and port vehicles. This application does not impose specific limitations in this regard.

[0040] Figure 1 This is a schematic diagram of the structure of a vehicle shown in an embodiment of this application.

[0041] In one possible implementation, such as Figure 1 As shown, the vehicle 100 includes a control device 101 and a message receiving device 102.

[0042] The message receiving device 102 is used to receive data messages containing vehicle status information, fault information and other information continuously generated and sent by various controllers during vehicle operation, and to transmit various types of data messages to the control device 101.

[0043] The aforementioned message receiving device 102 is compatible with different message types in the vehicle, including Controller Area Network (CAN), CAN with Flexible Data Rate (CAN FD), Local Interconnect Network (LIN), etc.

[0044] The vehicle status information mentioned above includes engine status, transmission status, and body status. Engine status includes engine speed, coolant temperature, intake air temperature, intake air pressure, and throttle position. Transmission status includes transmission position, gear information, and shift shock level. Body status includes door open / closed status, window operation status, and light status.

[0045] The aforementioned fault information includes fault codes and extended fault codes. When a system or component of the vehicle malfunctions, the corresponding controller generates a corresponding fault code and stores it in memory. After receiving the fault code, the message receiving device 102 transmits it to the control device 101, which can quickly locate the location and cause of the fault based on the fault code.

[0046] The above extended fault codes are used to describe the actual fault conditions of a specific vehicle model or system in more detail.

[0047] The control device 101 includes a Controller Area Network Transport Protocol Module (CANTP), a Protocol Data Unit Router Module (PDUR), and a Data Communication Module (DCM).

[0048] The CANTP module of the control device 101 is configured to identify the message type of the diagnostic request message in response to the diagnostic request message transmitted by the message receiving device 102, and store the diagnostic request message in different shared buffers according to the different message types.

[0049] The PDUR module of the control device 101 is configured to read diagnostic request messages from different shared buffers and transmit the diagnostic request messages to the DCM module of the control device 101.

[0050] The DCM module of the control device 101 is configured to schedule a diagnostic service corresponding to the message identifier to diagnose the diagnostic request message based on the message identifier of the diagnostic request message.

[0051] The aforementioned diagnostic services include Unified Diagnostic Services (UDS), On-Board Diagnostics (OBD), safety performance diagnostic services, comprehensive performance diagnostic services, and vehicle fault diagnostic services.

[0052] In practical applications, the message receiving device 102 can communicate with one or more control devices 101.

[0053] For ease of understanding, this application uses the communication connection between a message receiving device 102 and a control device 101 as an example for illustration.

[0054] As a feasible approach, Figure 1 The control device 101 and message receiving device 102 can be installed inside or outside the vehicle. The control device 101 and message receiving device 102 are functional modules integrated into the same device. This application does not impose any limitations on the comparison.

[0055] It is easy to understand that when the control device 101 and the message receiving device 102 are functional modules integrated into the same device, the communication method between the control device 101 and the message receiving device 102 is the communication between modules within the device.

[0056] As a feasible approach, Figure 1 The control device 101 can be installed on a terminal, a server, or other types of electronic devices.

[0057] When the control device 101 is located at a terminal, the terminal can be a device providing data connectivity to vehicle users or vehicle owners, a handheld device with wireless connectivity, or other processing devices connected to a wireless modem. The terminal can communicate with one or more core networks via a radio access network (RAN). The terminal can be a mobile terminal, such as a computer with a mobile terminal, or a mobile device that exchanges voice and / or data with the radio access network, such as a mobile phone, tablet, laptop, netbook, or personal digital assistant (PDA). This application does not impose any limitations on this.

[0058] When the control device 101 is located on a server, the server can be a single server or a server cluster consisting of multiple servers. In some embodiments, the server cluster can also be a distributed cluster. This application does not impose any limitations on this.

[0059] It should be noted that the structure illustrated in the embodiments of this application does not constitute a limitation on the control device 101. It may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of both.

[0060] For ease of understanding, the control device provided in this application will be described in detail below with reference to the accompanying drawings.

[0061] Figure 2 This is a schematic diagram of the structure of a control device shown in an embodiment of this application, with reference to... Figure 2 The control device includes: CANTP module 201, PDUR module 202 and DCM module 203.

[0062] The CANTP module 201 is configured to: in response to the acquired diagnostic request message, identify the message type of the diagnostic request message; and store the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message.

[0063] The aforementioned diagnostic request message is a standardized instruction defined in the vehicle's diagnostic protocol. It is used to read the fault diagnostic codes in the vehicle's controller, obtain the actual data of the controller, and request the controller to execute a self-test program.

[0064] The aforementioned diagnostic request message includes message identifier, service identifier, service function, and parameters.

[0065] From a protocol perspective, the above message types can be categorized into CAN, CANFD, and LIN types, etc. From a functional perspective, they can be categorized into diagnostic request messages and diagnostic response messages, etc.

[0066] The aforementioned message identifier is a data field used to identify messages in the vehicle communication network. It is a unique identifier for the message and determines key attributes such as message priority, routing path, and message type.

[0067] In some embodiments, diagnostic request messages in the CAN bus have an 11-bit message identifier if they are standard frames, and a 29-bit message identifier if they are extended frames.

[0068] In some embodiments, the smaller the value of the message identifier, the higher the message priority. For example, a message with a value of 0x000 has a higher priority than a message with a value of 0x7FF.

[0069] The aforementioned shared cache area is a temporary storage area in memory divided according to message identifier and message type, used to store diagnostic request messages and actual information content generated or transmitted during the diagnostic process.

[0070] In one possible implementation, the CANTP module is configured to store diagnostic request messages in a shared buffer corresponding to the message identifier and message type of the diagnostic request message, including: if the diagnostic request message type is CAN, storing the diagnostic request message in a first shared buffer corresponding to the message identifier and CAN type of the diagnostic request message; or, if the diagnostic request message type is CANFD, storing the diagnostic request message in a second shared buffer corresponding to the message identifier and CANFD type of the diagnostic request message.

[0071] The first shared buffer is configured to match the format of a CAN-type diagnostic request message. The second shared buffer is configured to match the format of a CANFD-type diagnostic request message.

[0072] In some embodiments, in memory-based cache management, the first shared cache and the second shared cache can be data, linked lists, lists, or hash tables, etc. In bus-based cache management, the first shared cache and the second shared cache can be CAN cache and CANFD cache, which are divided according to message identifier and message type.

[0073] In some embodiments, the same message identifier for a diagnostic request message can simultaneously support multiple message types, including CAN, CANFD, and LIN.

[0074] As an implementation method, to distinguish between the different types of diagnostic request messages mentioned above, the CANTP module is also configured to: in response to the acquired diagnostic request message, identify the control bit identifier of the diagnostic request message; and determine the type of the diagnostic request message based on the control bit identifier.

[0075] In some embodiments, when the control bit identifier is set to a first value, the diagnostic request message type of the message data frame is CAN type. CAN type diagnostic request messages and their corresponding data follow the frame format of the traditional CAN protocol. Even using 11-bit or 29-bit identifiers, the maximum data length is 8 bytes, and the transmission rate is constant (typically not exceeding 1 Mbps).

[0076] In some embodiments, when the control bit identifier is set to the second value, the diagnostic request message type of the message data frame is CANFD. CANFD type messages and their corresponding data follow the frame format of the CANFD protocol. CANFD format message data frames add BRS (Bit Rate Switch) and ESI (Error State Indicator) bits to the control segment, supporting data length extension to 64 bytes and allowing switching of transmission rates between the arbitration segment and the data segment; that is, the arbitration segment rate is constant while the data segment rate is variable.

[0077] As one possible approach, when the diagnostic request message is of type LIN, LIN messages do not have control bit identifiers and the message type needs to be implicitly distinguished by a 6-bit identifier. For example, 0x3C is a diagnostic request and 0x3D is a diagnostic response.

[0078] As another possible approach, to distinguish between the different types of diagnostic request messages mentioned above, the CANTP module is also configured to: in response to the acquired diagnostic request message, identify the data length of the diagnostic request message; and determine the type of the diagnostic request message based on the data length.

[0079] In some embodiments, the maximum data length of a CAN type diagnostic request message is 8 bytes, and the data length of a CANFD type diagnostic request message can be extended to 64 bytes. That is, if the maximum data length of a diagnostic request message is greater than 8 bytes, it is a CANFD type diagnostic request message.

[0080] As another feasible approach, diagnostic request messages of different types can be distinguished based on factors such as the rate switching method between CAN and CANFD types, CRC check bits, padding rules, and application scenarios. For example, CAN type diagnostic request messages are generally used for traditional controller communication, while CANFD type diagnostic request messages are generally used for applications such as automatic acceleration and high-speed sensor data transmission.

[0081] PDUR module 202 is configured to: read diagnostic request messages from the shared buffer; and transmit diagnostic request messages to the DCM module.

[0082] In one possible implementation, the CANTP module is configured to store diagnostic request messages in a shared buffer corresponding to the message identifier and message type of the diagnostic request message, including: if the data length of the diagnostic request message is greater than a preset data length, segmenting the diagnostic request message to obtain multiple fragments of the diagnostic request message; and storing each fragment of the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message.

[0083] The aforementioned data length refers to the length of the valid data contained in the data field of the diagnostic request message. The data field is the portion of the diagnostic request message used to carry the actual data content. This data field is located after the header of the diagnostic request message.

[0084] The data length mentioned above refers to the number of bytes of valid data in the data field. The specific meaning and range of the data length vary depending on the diagnostic service. For example, the data field length on the CAN bus is usually limited to 8 bytes (for a standard CAN frame), while CAN FD supports longer data fields (up to 64 bytes).

[0085] The aforementioned preset data length refers to the maximum data length limit set in the shared buffer area. The preset data length is determined based on the storage capacity, communication protocol requirements, and the system's consideration of communication efficiency.

[0086] The aforementioned segmentation refers to segmenting the valid data contained in the data field of the diagnostic request message into segments to adapt to the capacity limitations of the shared buffer and avoid data loss.

[0087] The PDUR module is configured to read diagnostic request messages from a shared buffer, including: reading multiple fragments of the diagnostic request message from the shared buffer; and concatenating the multiple fragments of the diagnostic request message to obtain the diagnostic request message.

[0088] As one possible approach, the PDUR module uses the information transmitted by the I-PDU to call the corresponding interface of the shared buffer in the DCM module, and calls the configured path according to the corresponding interface to read the data.

[0089] Each of the above segments contains a portion of the original diagnostic request message data and segment identification information, etc.

[0090] The aforementioned data splicing refers to the process of reassembling multiple fragments of a diagnostic request message into a complete diagnostic request message based on the segmentation identifier information of these fragments after receiving them.

[0091] As one feasible approach, the data concatenation process described above includes: reading multiple fragments of the diagnostic request message from the shared buffer; parsing the segment identifier information in each fragment to determine the sequence number of each fragment and the total number of fragments; sorting the fragments according to their sequence numbers to ensure the correct order of data concatenation; and merging the sorted fragment data in sequence to form a complete diagnostic request message.

[0092] DCM module 203 is configured to: based on the message identifier of the diagnostic request message, schedule the diagnostic service corresponding to the message identifier to diagnose the diagnostic request message; the diagnostic service includes UDS diagnostic service or OBD diagnostic service.

[0093] The aforementioned UDS diagnostic service is a standardized diagnostic communication protocol that defines the communication rules and services between various diagnostic tools and the vehicle's electronic control unit (ECU).

[0094] In some embodiments, the main functions of the UDS diagnostic service include communication management, data transmission, input / output control, and remote wake-up. Data transmission includes reading message identifiers and reading fault diagnostic codes.

[0095] The aforementioned OBD diagnostic service is an on-board automatic diagnostic system primarily used for monitoring and diagnosing vehicle emission-related components and systems.

[0096] In some embodiments, the main functions of OBD diagnostic services include monitoring the operating status of components such as the engine, catalytic converter, particulate filter, oxygen sensor, emission control system, and fuel system; fault indication; fault storage and information output.

[0097] Based on the aforementioned technical means, the CANTP module of this application can enhance the compatibility of message processing by accurately identifying the message type of the diagnostic request message and storing diagnostic request messages of different message types in the corresponding shared buffer. Based on this, the PDUR module reads the diagnostic request message from the shared buffer and transmits it to the DCM module for scheduling the diagnostic service corresponding to the diagnostic request message, which can realize the response to the diagnostic request message more quickly and improve the processing efficiency of the diagnostic request message.

[0098] In one possible implementation, the control device also includes a Diagnostic Event Manager (DEM). Figure 3 This is a block diagram of another control device shown in the embodiments of this application, combined with Figure 2 and Figure 3 The control device includes a CANTP module 201, a PDUR module 202, a DCM module 203, and a DEM module 204.

[0099] The DCM module 203 is configured to schedule diagnostic services corresponding to the message identifier based on the message identifier of the diagnostic request message, including: feeding back the message identifier to the DEM module 204, obtaining the diagnostic service table corresponding to the message identifier from the DEM module 204; and scheduling the corresponding diagnostic service to diagnose the diagnostic request message based on the diagnostic service table.

[0100] As one possible approach, scheduling the diagnostic service corresponding to the message identifier also includes feeding back the diagnostic service level by level, for example, feeding back the diagnostic service from PDUR→CANTP→CANIF→CAN bus.

[0101] The aforementioned diagnostic service table is stored in the DEM module. This table represents the correspondence between message identifiers and different diagnostic services. It also represents the vehicle fault condition corresponding to each message identifier within its respective diagnostic service.

[0102] In one possible implementation, the DEM module 204 is configured to: obtain the message identifier of the diagnostic request message fed back by the DCM module 203, compare the message identifier with a preset identifier threshold, determine the diagnostic service table corresponding to the diagnostic request message based on the comparison result; the diagnostic service table includes a UDS diagnostic service table and an OBD diagnostic service table; and send the diagnostic service table corresponding to the diagnostic request message to the DCM module. This enables fast and accurate matching, improving service scheduling efficiency.

[0103] In one possible implementation, the aforementioned preset identifier threshold is used to distinguish the diagnostic service type corresponding to the diagnostic request message. If the message identifier of the diagnostic request message is greater than the preset identifier threshold, the diagnostic service table corresponding to the diagnostic request message is determined to be the UDS diagnostic service table; or, if the message identifier is not greater than the preset identifier threshold, the diagnostic service table corresponding to the diagnostic request message is determined to be the OBD diagnostic service table.

[0104] For example, if 0x000-0x7FF is the message identifier range for OBD diagnostic services and 0x800-0xFFF is the message identifier range for UDS diagnostic services, then the preset identifier threshold is set to 0x800. If the message identifier is greater than 0x800, the diagnostic service table corresponding to the diagnostic request message is determined to be the UDS diagnostic service table. Alternatively, if the message identifier is not greater than 0x800, the diagnostic service table corresponding to the diagnostic request message is determined to be the OBD diagnostic service table.

[0105] As one feasible approach, the fault diagnosis code of the diagnostic request message is determined based on the message identifier. If the fault diagnosis code is greater than a preset fault diagnosis threshold, the diagnostic service table corresponding to the diagnostic request message is determined to be the UDS diagnostic service table; or, if the fault diagnosis code is not greater than the preset fault diagnosis threshold, the diagnostic service table corresponding to the diagnostic request message is determined to be the OBD diagnostic service table.

[0106] For example, if the preset fault diagnosis threshold is 0x010000, then if the fault diagnosis code of the diagnosis request message is greater than 0x010000, the diagnosis service table corresponding to the diagnosis request message is determined to be the UDS diagnosis service table. If the fault diagnosis code of the diagnosis request message is not greater than 0x010000, the diagnosis service table corresponding to the diagnosis request message is determined to be the OBD diagnosis service table.

[0107] Figure 4 This is a flowchart illustrating a control method according to an embodiment of this application, with reference to... Figure 4 The method includes: S401-S403.

[0108] S401, Receive diagnostic request message.

[0109] S402. In response to a diagnostic request message, identify the message type of the diagnostic request message.

[0110] S403. Store the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message, so that the PDUR module can read the diagnostic request message from the shared buffer.

[0111] The above message types include CAN type or CANFD type. The same message identifier for a diagnostic request message supports both CAN type and CANFD type.

[0112] The aforementioned diagnostic request message is applied to the DCM module. The DCM module is configured to schedule the diagnostic service corresponding to the message identifier to diagnose the diagnostic request message based on the message identifier of the diagnostic request message; the diagnostic service includes UDS diagnostic service or OBD diagnostic service.

[0113] Based on the aforementioned technical means, this application enhances the compatibility of message processing by accurately identifying the message type of the diagnostic request message and storing diagnostic request messages of different message types in the corresponding shared buffer. Based on this, the PDUR module reads the diagnostic request message from the shared buffer and transmits it to the DCM module for scheduling the diagnostic service corresponding to the diagnostic request message, which can realize the response to the diagnostic request message more quickly and improve the processing efficiency of the diagnostic request message.

[0114] In one possible implementation, storing the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message includes: if the type of the diagnostic request message is CAN, storing the diagnostic request message in a first shared buffer corresponding to the message identifier and CAN type of the diagnostic request message; or, if the type of the diagnostic request message is CANFD, storing the diagnostic request message in a second shared buffer corresponding to the message identifier and CANFD type of the diagnostic request message.

[0115] In one possible implementation, in response to a diagnostic request message, identifying the message type of the diagnostic request message includes: in response to the acquired diagnostic request message, identifying the control bit identifier of the diagnostic request message; determining the type of the diagnostic request message based on the control bit identifier; wherein, when the control bit identifier is a first value, the type of the diagnostic request message is CAN type; and when the control bit identifier is a second value, the type of the diagnostic request message is CANFD type.

[0116] In one possible implementation, based on the message identifier of the diagnostic request message, the diagnostic service corresponding to the message identifier is scheduled, including: the DCM module feeding back the message identifier to the DEM module, obtaining the diagnostic service table corresponding to the message identifier from the DEM module; and based on the diagnostic service table, calling the corresponding diagnostic service to diagnose the diagnostic request message.

[0117] In one possible implementation, the DCM module sends a message identifier back to the DEM module and obtains the diagnostic service table corresponding to the message identifier from the DEM module. This includes: obtaining the message identifier of the diagnostic request message sent back by the DCM module, comparing the message identifier with a preset identifier threshold, and determining the diagnostic service table corresponding to the diagnostic request message based on the comparison result; the diagnostic service table includes a UDS diagnostic service table and an OBD diagnostic service table; and sending the diagnostic service table corresponding to the diagnostic request message to the DCM module.

[0118] In one possible implementation, determining the diagnostic service table corresponding to the diagnostic request message based on the comparison result includes: if the message identifier is greater than a preset identifier threshold, determining the diagnostic service table corresponding to the diagnostic request message as the UDS diagnostic service table; or, if the message identifier is not greater than the preset identifier threshold, determining the diagnostic service table corresponding to the diagnostic request message as the OBD diagnostic service table.

[0119] In one possible implementation, storing the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message includes: if the data length of the diagnostic request message is greater than a preset data length, segmenting the diagnostic request message into multiple fragments of the diagnostic request message; storing each fragment of the diagnostic request message into the shared buffer corresponding to the message identifier and message type of the diagnostic request message, so that the PDUR module can read the multiple fragments of the diagnostic request message from the shared buffer; and concatenating the multiple fragments of the diagnostic request message to obtain the diagnostic request message.

[0120] In some embodiments, when the above method is applied to control a vehicle, the control principle is as follows: Figure 5 , Figure 5 This is a schematic diagram illustrating the control principle of a control method according to an embodiment of this application.

[0121] For example, the implementation of control methods typically employs physical addressing.

[0122] First, the diagnostic request message on the CAN bus is obtained based on physical addressing, and the UDS identifier and OBD identifier are parsed from the message identifier of the diagnostic request message.

[0123] Secondly, using the acquired physical address message identifier, the CANIF module performs CAN / CANFD message receive (TX) and transmit (RX) operations. The CANTP module segments the data and sends the segmented diagnostic request messages (CAN or CANFD data types) to the PDUR module. The CAN format diagnostic request messages within the segmented messages are stored in the first shared buffer of the CAN format; or the CANFD format diagnostic request messages are stored in the second shared buffer of the CANFD format.

[0124] The PDUR module calls the configured path to read diagnostic request messages from either the first or second shared buffer.

[0125] The first shared buffer or the second shared buffer will also send a notification of successful reading after reading the diagnostic request message, such as notifying CAN-OK or CANFD-OK.

[0126] Next, the segmented diagnostic request messages obtained by the PDUR module are reassembled (e.g., message splicing). Based on the message type, the diagnostic request messages are classified as either CAN type or CANFD type for the corresponding diagnostic service call.

[0127] Based on the UDS and OBD identifiers in the diagnostic request message, the system invokes the UDS or OBD diagnostic service. After invoking the UDS or OBD diagnostic service, it also provides feedback based on the diagnostic service information in the UDS or OBD diagnostic service table.

[0128] When performing diagnostic services, the DCM module accesses the UDS diagnostic service table UDS_Service_Table or the OBD diagnostic service table OBD_Service_Table to obtain the specific implementation and configuration information of the diagnostic service for the diagnostic request message.

[0129] If a vehicle malfunction is detected during the diagnostic process, the DEM module will promptly mark the diagnostic code attribute and report it to the corresponding list.

[0130] In some embodiments, when the above method is applied to control a vehicle, the control principle is as follows: Figure 6 , Figure 6 This is a flowchart illustrating the control principle of another control method shown in the embodiments of this application.

[0131] For example, the implementation of control methods typically employs functional addressing.

[0132] First, the diagnostic request message on the CAN bus is obtained based on the function addressing method, and the function addressing identifier is parsed from the message identifier of the diagnostic request message.

[0133] Secondly, using the acquired function-addressed message identifier, the CANIF module performs CAN / CANFD message receive (TX) and transmit (RX) operations. The CANTP module then segments the data and sends the segmented diagnostic request messages (CAN or CANFD data types) to the PDUR module. The CAN format diagnostic request messages within the segmented messages are stored in the first shared buffer of the CAN format; or the CANFD format diagnostic request messages are stored in the second shared buffer of the CANFD format.

[0134] The PDUR module calls the configured path to read diagnostic request messages from either the first or second shared buffer.

[0135] The first shared buffer or the second shared buffer will also send a notification of successful reading after reading the diagnostic request message, such as notifying CAN-OK or CANFD-OK.

[0136] Next, the segmented diagnostic request messages obtained by the PDUR module are reassembled (e.g., message splicing). Based on the message type, the diagnostic request messages are classified as either CAN type or CANFD type for the corresponding diagnostic service call.

[0137] Based on the UDS and OBD identifiers in the diagnostic request message, the system invokes the UDS or OBD diagnostic service. After invoking the UDS or OBD diagnostic service, it also provides feedback based on the diagnostic service information in the UDS or OBD diagnostic service table.

[0138] When performing diagnostic services, the DCM module accesses the UDS diagnostic service table UDS_Service_Table or the OBD diagnostic service table OBD_Service_Table to obtain the specific implementation and configuration information of the diagnostic service for the diagnostic request message.

[0139] If a vehicle malfunction is detected during the diagnostic process, the DEM module will promptly mark the diagnostic code attribute and report it to the corresponding list.

[0140] Regarding the methods in the above embodiments, the specific manner in which each step is executed has been described in detail in the embodiments of the control device, and will not be elaborated here.

[0141] Figure 7 This is a block diagram illustrating an electronic device according to an embodiment of this application. Figure 7 As shown, the electronic device includes, but is not limited to, a processor 701 and a memory 702.

[0142] The memory 702 described above is used to store the executable instructions of the processor 701. It is understood that the processor 701 is configured to execute instructions to implement the control method described in the above embodiments.

[0143] It should be noted that those skilled in the art will understand that Figure 7 The electronic device structure shown does not constitute a limitation on the electronic device; the electronic device may include, but is not limited to, other electronic devices. Figure 7 This may indicate more or fewer components, or combinations of certain components, or different component arrangements.

[0144] Processor 701 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in memory 702, and by calling data stored in memory 702, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Processor 701 may include one or more processing units. Processor 701 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into processor 701.

[0145] The memory 702 can be used to store software programs and various data. The memory 702 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required by at least one functional module (such as deterministic components, integrated components, etc.), etc. Furthermore, the memory 702 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0146] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 702 including instructions, which can be executed by a processor 701 of an electronic device to implement the methods in the above embodiments.

[0147] In actual implementation, Figure 2 The functions of the CANTP module 201, PDUR module 202, and DCM module 203 can all be provided by... Figure 7 The processor 701 calls the computer program stored in the memory 702 to implement the process. The specific execution process can be found in the description of the method section in the previous embodiment, and will not be repeated here.

[0148] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device. In an exemplary embodiment, this application also provides a computer program product including one or more instructions, which can be executed by the processor 701 of an electronic device to perform the methods in the above embodiments.

[0149] It should be noted that when one or more instructions in the computer-readable storage medium or computer program product are executed by the processor of the electronic device, they implement the various processes of the above method embodiments and achieve the same technical effect as the above method. To avoid repetition, they will not be described again here.

[0150] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0151] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0152] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0153] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0154] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0155] This application provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the methods described in the above method embodiments.

[0156] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method in the method flow shown in the above method embodiments.

[0157] The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, a register, a hard disk, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof, or any other form of computer-readable storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an application-specific integrated circuit (ASIC). In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0158] Since the control method, computer-readable storage medium, and computer program product in the embodiments of this application can be applied to the above methods, the technical effects they can achieve can also be referred to the above method embodiments. The embodiments of this application will not be repeated here.

[0159] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A control device, characterized in that, The control device includes: a Controller Area Network Transmission Protocol (CANTP) module, a Protocol Data Unit Router (PDUR) module, and a Data Communication (DCM) module; The CANTP module is configured to: in response to an acquired diagnostic request message, identify the message type of the diagnostic request message; store the diagnostic request message in a shared buffer corresponding to the message identifier of the diagnostic request message and the message type; the message type includes Controller Area Network (CAN) type or Flexible Data Rate Controller Area Network (CANFD) type; the same message identifier of the diagnostic request message supports both CAN type and CANFD type; The PDUR module is configured to: read the diagnostic request message from the shared buffer; and transmit the diagnostic request message to the DCM module. The DCM module is configured to: based on the message identifier of the diagnostic request message, schedule the diagnostic service corresponding to the message identifier to diagnose the diagnostic request message; the diagnostic service includes Unified Diagnostic Service (UDS) or On-Board Diagnostic Service (OBD).

2. The control device according to claim 1, characterized in that, The CANTP module is configured to store the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message, including: If the diagnostic request message is of type CAN, the diagnostic request message is stored in a first shared buffer corresponding to the message identifier and CAN type of the diagnostic request message; or, If the diagnostic request message is of type CANFD, the diagnostic request message is stored in a second shared buffer corresponding to the message identifier and CANFD type of the diagnostic request message.

3. The control device according to claim 1, characterized in that, The CANTP module is also configured to: In response to the acquired diagnostic request message, the control bit identifier of the diagnostic request message is identified; The type of the diagnostic request message is determined based on the control bit identifier; wherein, when the control bit identifier is a first value, the type of the diagnostic request message is CAN type; when the control bit identifier is a second value, the type of the diagnostic request message is CANFD type.

4. The control device according to claim 1, characterized in that, The control device also includes a diagnostic event processing (DEM) module; The DCM module is configured to schedule diagnostic services corresponding to the message identifier based on the message identifier of the diagnostic request message, including: feeding back the message identifier to the DEM module and obtaining a diagnostic service table corresponding to the message identifier from the DEM module; Based on the diagnostic service table, the corresponding diagnostic service is invoked to diagnose the diagnostic request message.

5. The control device according to claim 4, characterized in that, The DEM module is configured to: obtain the message identifier of the diagnostic request message fed back by the DCM module, compare the message identifier with a preset identifier threshold, determine the diagnostic service table corresponding to the diagnostic request message based on the comparison result; the diagnostic service table includes a UDS diagnostic service table and an OBD diagnostic service table; and send the diagnostic service table corresponding to the diagnostic request message to the DCM module.

6. The control device according to claim 5, characterized in that, The DEM module is configured to determine the diagnostic service table corresponding to the diagnostic request message based on the comparison results, including: If the message identifier is greater than a preset identifier threshold, the diagnostic service table corresponding to the diagnostic request message is determined to be the UDS diagnostic service table; or, If the message identifier is not greater than a preset identifier threshold, the diagnostic service table corresponding to the diagnostic request message is determined to be the OBD diagnostic service table.

7. The control device according to claim 1, characterized in that, The CANTP module is configured to store the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message, including: when the data length of the diagnostic request message is greater than a preset data length, segmenting the diagnostic request message to obtain multiple fragments of the diagnostic request message; and storing each fragment of the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message. The PDUR module is configured to read the diagnostic request message from the shared buffer, including: reading multiple fragments of the diagnostic request message from the shared buffer; and concatenating the multiple fragments of the diagnostic request message to obtain the diagnostic request message.

8. A control method, characterized in that, The CANTP module applied in the control device according to any one of claims 1-7, the control method comprising: Receive diagnostic request message; In response to the diagnostic request message, identify the message type of the diagnostic request message; The diagnostic request message is stored in a shared buffer corresponding to the message identifier and message type of the diagnostic request message, so that the PDUR module can read the diagnostic request message from the shared buffer and transmit the diagnostic request message to the DCM module; the message type includes CAN type or CANFD type; the same message identifier of the diagnostic request message supports both CAN type and CANFD type; the DCM module is configured to schedule the diagnostic service corresponding to the message identifier to diagnose the diagnostic request message based on the message identifier of the diagnostic request message; the diagnostic service includes UDS diagnostic service or OBD diagnostic service.

9. The control method according to claim 8, characterized in that, The step of storing the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message includes: If the diagnostic request message is of type CAN, the diagnostic request message is stored in a first shared buffer corresponding to the message identifier and CAN type of the diagnostic request message; or, If the diagnostic request message is of type CANFD, the diagnostic request message is stored in a second shared buffer corresponding to the message identifier and CANFD type of the diagnostic request message.

10. The control method according to claim 8, characterized in that, The step of identifying the message type of the diagnostic request message in response to the diagnostic request message includes: In response to the acquired diagnostic request message, the control bit identifier of the diagnostic request message is identified; The type of the diagnostic request message is determined based on the control bit identifier; wherein, when the control bit identifier is a first value, the type of the diagnostic request message is CAN type; when the control bit identifier is a second value, the type of the diagnostic request message is CANFD type.

11. The control method according to claim 8, characterized in that, The step of storing the diagnostic request message in a shared buffer corresponding to the message identifier and message type of the diagnostic request message includes: If the data length of the diagnostic request message is greater than the preset data length, the diagnostic request message is segmented to obtain multiple fragments of the diagnostic request message. The multiple fragments of the diagnostic request message are stored one by one in a shared buffer corresponding to the message identifier and message type of the diagnostic request message, so that the PDUR module can read the multiple fragments of the diagnostic request message from the shared buffer; and the multiple fragments of the diagnostic request message are concatenated to obtain the diagnostic request message.

12. A vehicle, characterized in that, The vehicle includes the control device according to any one of claims 1-7.

Images