Vehicle diagnosis message processing method and device, equipment and medium

Abstract

The invention discloses a vehicle diagnosis message processing method and device, equipment and a medium, and relates to the technical field of vehicle communication, and the method comprises the steps: receiving a diagnosis request message; determining a target addressing mode of the diagnosis request message based on the diagnosis request message; when the target addressing mode is function addressing, processing the diagnosis request message through a preset callback function of a CAN driver layer of the domain controller to prevent the diagnosis request message from entering an upper layer protocol stack process; and the diagnosis request message is sent to a target controller, and the target controller is a controller in a multi-frame transmission session in the current domain controller. According to the invention, the reliability and stability of the diagnosis communication process are improved, the intra-domain node controller can be ensured to completely receive and respond to the diagnosis request, and the smooth completion of a multi-frame transmission task is ensured.

Description

Technical Field

[0001] This application relates to the field of vehicle communication technology, and in particular to a method, apparatus, device and medium for processing vehicle diagnostic messages. Background Technology

[0002] With the continuous development of automotive electronic architecture, domain controllers play a core role in modern vehicle systems, responsible for coordinating and managing communication and diagnostics among multiple subordinate electronic control units. In systems developed based on the standard AUTOSAR CP platform, diagnostic communication between the diagnostic tool and each controller is typically achieved via a CAN bus. This includes both physical addressing communication for specific controllers and functional addressing communication broadcast across the entire network. During actual diagnostics, when the diagnostic tool initiates multi-frame transmission requests, such as writing VIN codes, the domain controller must route the physical addressing messages to the target controller and maintain the transmission status to complete data exchange. However, if the diagnostic tool simultaneously issues functional addressing diagnostic commands during this process, the domain controller's internal protocol stack often struggles to effectively coordinate the parallel processing requirements of the two addressing modes.

[0003] The existing AUTOSAR CP protocol stack has certain limitations in handling function-addressed messages. These messages are typically delivered to the diagnostic communication management module within the domain controller and the upper-layer transport protocol stack for processing, which can easily trigger resource release and state reset mechanisms. This behavior is particularly detrimental during multi-frame physical addressing transmissions, potentially leading to abnormal clearing of the transport state machine, failure to respond to flow control frames, and failure to send consecutive frames, thus interrupting the entire diagnostic session. Therefore, a vehicle diagnostic message processing method is urgently needed to address the aforementioned problems. Summary of the Invention

[0004] The summary section introduces a series of simplified concepts, which will be further explained in detail in the detailed description section. This summary section is not intended to limit the key and essential technical features of the claimed technical solutions, nor is it intended to determine the scope of protection of the claimed technical solutions.

[0005] Firstly, this application provides a vehicle diagnostic message processing method applied to a domain controller, including: Receive diagnostic request message; Based on the diagnostic request message, determine the target addressing mode of the diagnostic request message; When the target addressing mode is functional addressing, the diagnostic request message is processed by the preset callback function of the CAN driver layer of the domain controller to prevent the diagnostic request message from entering the upper-layer protocol stack process. The diagnostic request message is sent to the target controller, wherein the target controller is the controller in the current domain controller that is in a multi-frame transmission session.

[0006] In some implementations, the target addressing mode includes functional addressing or physical addressing, and determining the target addressing mode of the diagnostic request message based on the diagnostic request message includes: Based on the target address field contained in the diagnostic request message, the target addressing mode of the diagnostic request message is determined to be either the functional addressing or the physical addressing.

[0007] In some implementations, the diagnostic request message is processed by a preset callback function of the CAN driver layer of the domain controller to prevent the diagnostic request message from entering the upper-layer protocol stack process, including: Call the preset callback function of the CAN driver layer; The diagnostic request message is intercepted by the received callback function to prevent it from entering the upper-layer protocol stack process.

[0008] In some implementations, sending the diagnostic request message to the target controller includes: Based on the current diagnostic session state of the domain controller, determine the target controller identifier that is in a multi-frame transmission session; Based on the target controller identifier, the target CAN channel identifier corresponding to the target controller identifier is determined from the preset mapping relationship between the controller identifier and the CAN channel identifier; Based on the target CAN channel identifier, the transmit interface of the CAN driver layer is invoked; The diagnostic request message is sent to the target controller through the sending interface.

[0009] In some implementations, prior to receiving the diagnostic request message, the method further includes: Based on the system configuration information of the domain controller, a preset callback function for processing function addressing messages is determined; Based on the registration interface between the preset callback function and the CAN driver layer, the preset callback function is registered to the CAN driver layer of the domain controller, and the CAN driver layer is configured to perform callback interception processing on the received diagnostic request messages.

[0010] In some implementations, determining the target controller identifier that is in a multi-frame transmission session based on the current diagnostic session state of the domain controller includes: Based on the current diagnostic session status of each controller within the domain controller, determine whether there is a controller currently in a multi-frame transmission session. If the determination result is that it exists, a target controller identifier is generated based on the identifier of the controller that is currently in a multi-frame transmission session.

[0011] In some implementations, the domain controller includes at least one of a driving domain controller, a body domain controller, and a cockpit domain controller.

[0012] Secondly, this application proposes a vehicle diagnostic message processing device, applied to a domain controller, comprising: The diagnostic message acquisition unit is used to receive diagnostic request messages; The addressing mode determination unit is used to determine the target addressing mode of the diagnostic request message based on the diagnostic request message; The callback function processing unit is used to process the diagnostic request message through the preset callback function of the CAN driver layer of the domain controller when the target addressing mode is functional addressing, so as to prevent the diagnostic request message from entering the upper layer protocol stack process. A diagnostic message sending unit is used to send the diagnostic request message to the target controller, wherein the target controller is a controller in the current domain controller that is in a multi-frame transmission session.

[0013] Thirdly, an electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program stored in the memory to implement the steps of the vehicle diagnostic message processing method of any of the first aspects described above.

[0014] Fourthly, this application also proposes a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the vehicle diagnostic message processing method of any one of the first aspects.

[0015] In summary, this application provides a vehicle diagnostic message processing method that, when a domain controller receives a functional addressing diagnostic message, can intercept and process such messages using a pre-defined callback function in the CAN driver layer. This effectively prevents the message from entering the upper-layer protocol stack process, thus avoiding interference with ongoing multi-frame physical addressing transmission sessions due to protocol stack state resets. This method improves the reliability and stability of the diagnostic communication process, ensuring that the domain node controller can fully receive and respond to diagnostic requests, and guaranteeing the smooth completion of multi-frame transmission tasks. It is particularly suitable for various domain controller architectures such as intelligent driving, intelligent cockpit, and body control, and has good versatility and practical value.

[0016] The vehicle diagnostic message processing method proposed in this application, along with other advantages, objectives, and features of this application, will be partly apparent from the following description and partly understood by those skilled in the art through study and practice of this application. Attached Figure Description

[0017] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic flowchart of a vehicle diagnostic message processing method provided in an embodiment of this application; Figure 2 A schematic diagram of a vehicle diagnostic message processing device provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of a vehicle diagnostic message processing electronic device provided in an embodiment of this application. Detailed Implementation

[0018] The terms "first," "second," "third," "fourth," etc. (if present) 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 described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus. The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.

[0019] Please see Figure 1 This is a schematic flowchart of a vehicle diagnostic message processing method provided in an embodiment of this application, applied to a domain controller, and specifically may include: S110, Receive diagnostic request message; For example, during vehicle diagnostic communication, the diagnostic tool sends a diagnostic request message to the domain controller via the CAN bus. This message is physically received and converted by the domain controller's CAN transceiver, and then preliminarily parsed and frame-processed by the CAN driver to form a standardized data format that can be processed by subsequent modules. Receiving the message is the first step in initiating the entire diagnostic process, providing the data foundation for subsequent addressing mode determination and corresponding processing.

[0020] S120. Based on the diagnostic request message, determine the target addressing mode of the diagnostic request message; For example, upon receiving a diagnostic request message, the domain controller needs to parse the message to determine its addressing mode. This determination process mainly relies on a specific address field contained in the message. By identifying the numerical range or predefined encoding of this field, it can distinguish whether the current message is a physical addressing message sent to a specific node in the network or a functional addressing broadcast message directed to all nodes in the network. This provides a basis for determining whether to enable special interception and forwarding mechanisms in the future.

[0021] S130. When the target addressing mode is function addressing, the diagnostic request message is processed by the preset callback function of the CAN driver layer of the domain controller to prevent the diagnostic request message from entering the upper protocol stack process. For example, after identifying a diagnostic request message as a function-addressable type, the system calls a specific callback function pre-registered in the CAN driver layer to process the message. This callback function directly intercepts the message at the driver layer, preventing it from being passed up to upper-layer protocol stack modules such as CANIf, CAN TP, and PDUR. This avoids resource release and state reset operations that might be triggered if the message enters the DCM module. This processing mechanism achieves controlled management of function-addressable messages at the communication layer, ensuring that they do not interfere with the existing physical addressing session state within the domain controller, thus improving the reliability and real-time performance of system communication.

[0022] S140. Send a diagnostic request message to the target controller, wherein the target controller is the controller in the current domain controller that is in a multi-frame transmission session.

[0023] For example, after intercepting and processing the function-addressed message, the domain controller needs to accurately forward the message to the target controller currently in a multi-frame transmission session. This process first identifies the specific controller identifier that is currently in multi-frame transmission based on the domain controller's real-time session state management mechanism. Then, it determines the corresponding physical CAN channel by querying a preset mapping relationship. Finally, it sends the message directly to the target controller through the CAN driver layer's sending interface, thereby maintaining its session state without interruption and ensuring that the previously established physical addressing multi-frame transmission process can continue without interference.

[0024] In summary, this application provides a vehicle diagnostic message processing method that, when a domain controller receives a functional addressing diagnostic request message, can intercept and process the message using a callback function pre-registered in the CAN driver layer. This effectively prevents the message from entering the upper-layer protocol stack process, thus avoiding interference with ongoing multi-frame physical addressing transmission sessions caused by protocol stack state resets. This application significantly improves the reliability and stability of vehicle diagnostic communication, ensuring that the node controller within the domain can fully receive and respond to diagnostic requests, guaranteeing the smooth completion of multi-frame transmission tasks. Furthermore, this application has strong versatility and practicality, applicable to various domain control architectures including intelligent driving domain controllers, body domain controllers, and cockpit domain controllers, providing an effective underlying solution for communication coordination in complex diagnostic scenarios in modern vehicle electronic systems.

[0025] In some instances, the target addressing mode includes functional addressing or physical addressing. Based on the diagnostic request message, the target addressing mode of the diagnostic request message is determined, including: Based on the target address field contained in the diagnostic request message, determine whether the target addressing mode of the diagnostic request message is functional addressing or physical addressing.

[0026] For example, the process of determining the target addressing mode based on a diagnostic request message is specifically achieved by parsing the target address field contained in the message. The target address field is a specific data segment in the diagnostic request message used to identify the target controller or target node type, and its value conforms to a predefined address coding standard. Upon receiving the original diagnostic request message, the domain controller first extracts the value of the target address field. Then, it compares this value with a preset address range or a specific function address value. If the value falls within the physical address range that identifies a single controller, the message is determined to be in physical addressing mode, intended for communication with a specific controller within the domain. If the value equals a preset function addressing broadcast address (e.g., 0x7DF or other standard convention values), the message is determined to be in function addressing mode, intended for broadcasting to all nodes in the network. Through this parsing and judgment mechanism based on the target address field, the domain controller can accurately and reliably distinguish the addressing mode of a diagnostic request message.

[0027] In summary, this application's embodiments, through parsing and matching based on predefined address fields, can accurately distinguish between physical addressing and functional addressing messages without introducing additional processing latency, ensuring the correct triggering of subsequent processing logic. In particular, for functional addressing messages, accurate mode identification is a prerequisite for activating the CAN driver layer callback interception function, effectively avoiding potential state conflicts and transmission interruptions that might occur when such messages enter the upper-layer protocol stack, laying the foundation for ensuring the stability of the vehicle diagnostic communication process.

[0028] In some instances, diagnostic request messages are handled by preset callback functions in the domain controller's CAN driver layer to prevent them from entering the upper-layer protocol stack process, including: Call the preset callback function of the CAN driver layer; By intercepting diagnostic request messages through a callback function, the diagnostic request messages can be prevented from entering the upper-layer protocol stack process.

[0029] For example, after identifying the target addressing mode of the diagnostic request message as functional addressing, the system calls a pre-registered callback function in the CAN driver layer to process the message. This pre-registered callback function is typically the CanLPduReceiveCallout function, which is registered during system initialization through the registration interface provided by the CAN driver layer. This ensures that the callback function is actively triggered when the CAN driver receives a message that meets specific conditions. Calling this pre-registered callback function temporarily transfers the message processing authority from the standard upper-layer protocol stack process to this customized processing function, laying the foundation for subsequent interception operations.

[0030] Diagnostic request messages are intercepted via a pre-defined callback function to prevent them from entering the upper-layer protocol stack. Specifically, within the execution context of this callback function, the system directly judges and processes the original diagnostic request message data. If the message is confirmed to be of the function addressing type that needs to be intercepted (e.g., a session maintenance message with service identifier 0x3E and subfunction 0x80), the transmission of the message to the CAN interface layer (CANIf) and higher-layer protocol modules (such as CAN TP, PDUR, and DCM) is terminated within the function. This function addressing message is restricted to processing within the CAN driver layer, preventing it from triggering calls such as Dcm_ReleaseAllResource and CanTp_TxInitState after entering the upper-layer protocol stack. This eliminates the risk of interruption of ongoing multi-frame physical addressing transmission due to an unexpected reset of the protocol stack state.

[0031] In summary, this application embodiment effectively prevents such messages from entering the upper-layer protocol stack by utilizing a preset callback function in the CAN driver layer to identify and intercept functional addressing messages. This avoids resource release and transmission status interruption issues caused by standard protocol stack processing. This application embodiment significantly improves the reliability and robustness of the system when concurrently processing multi-addressing mode diagnostic requests, ensuring that critical multi-frame transmission tasks are not interfered with, and providing a protection mechanism for domain controller diagnostic communication.

[0032] In some instances, the default callback function is the CanLPduReceiveCallout function.

[0033] For example, the default callback function is the CanLPduReceiveCallout function, which is called when the CAN driver layer receives each frame message. Its receiving parameters include the hardware receive handle Hrh, the CAN identifier CanId, the data length CanDataLegth, and the pointer to the CAN data field CanSduPtr. Inside this function, the CAN identifier is first parsed by performing a bitwise AND operation with 0x00000fff to extract the basic identifier, and then it is determined whether it is equal to the functional address address 0x7df. At the same time, the data length is checked to see if it is 8 bytes. If all the above conditions are met, the received original CAN frame data is used to construct... A local CAN protocol data unit (localPdu) is created, where the id field is assigned the extracted basic identifier, the length field is set to the actual data length, the sdu pointer points to the original data area, and swPduHandle is initialized to 0. Subsequently, by calling the Can_Write function multiple times and using predefined object identifiers (such as DIAGREQ_FUN_RCR_OBJECT_ID) corresponding to different target controllers as parameters, the local protocol data unit is written to multiple different CAN transmit objects. This enables the function addressing message to be forwarded directly to the physical channels of multiple domain controllers at the driver layer, completely bypassing upper-layer protocol stack modules such as CanIf, CAN TP, and PDUR. This ensures that the function addressing message will not trigger resource release and state machine reset operations of the upper-layer diagnostic protocol stack, thus guaranteeing the continuity of ongoing physical addressing multi-frame transmission sessions.

[0034] In some instances, diagnostic request messages are sent to the target controller, including: Based on the current diagnostic session status of each controller within the domain controller, determine whether there is a controller currently in a multi-frame transmission session; If the determination result is that it exists, generate the target controller identifier based on the identifier of the controller that is currently in a multi-frame transmission session; Based on the target controller identifier, the target CAN channel identifier corresponding to the target controller identifier is determined from the preset mapping relationship between the controller identifier and the CAN channel identifier; Based on the target CAN channel identifier, call the transmit interface of the CAN driver layer; The diagnostic request message is sent to the target controller via the sending interface.

[0035] For example, based on the current diagnostic session status of each controller within the domain controller, it determines whether any controller is currently in a multi-frame transmission session. This step is achieved by querying the session status table maintained internally by the domain controller. This status table records the diagnostic session status information of each subordinate controller (such as radar controllers, camera controllers, etc.) in real time, including session type, start and end time, data frame count, and session activity flag. The system sequentially checks the session activity flag of each entry in the table. If an entry's flag is "true" and the session type is multi-frame transmission, it determines that the controller is currently in a multi-frame transmission session.

[0036] If the determination result indicates the existence of a controller currently in a multi-frame transmission session, a target controller identifier is generated based on that controller's identifier. The domain controller extracts the logical identifier of that controller from the session state table. This identifier is typically a pre-assigned unique ID or a controller logical address conforming to the AUTOSAR specification, and is used as the target controller identifier to ensure that the target device receiving the message can be uniquely identified during subsequent forwarding.

[0037] Based on the obtained target controller identifier, the corresponding target CAN channel identifier is determined from a preset mapping relationship between controller identifiers and CAN channel identifiers. This preset mapping relationship is stored in the non-volatile memory of the domain controller in the form of a lookup table, which records the correspondence between the logical identifiers of each controller in the domain and the physical CAN channel identifiers (such as CANControllerId, HOH (Hardware Object Handle), etc.). The system queries this mapping table using the target controller identifier as an index to obtain the target CAN channel identifier used for actual message transmission, realizing the conversion from logical device identifier to physical communication channel.

[0038] Based on the determined target CAN channel identifier, the CAN driver layer's transmit interface is invoked. This transmit interface is typically the Can_Write function or a similar low-level driver service, and its interface parameters include the target CAN channel identifier and the message data to be transmitted. The system passes the target CAN channel identifier along with the diagnostic request message data to be forwarded (including the identifier, data length, and data fields) to this transmit interface, triggering the CAN driver layer to perform hardware preparation for message transmission.

[0039] The diagnostic request message is sent to the target controller via the transmission interface. Based on the input target CAN channel identifier, the CAN driver layer selects the corresponding CAN hardware transmission object and physical channel, assembles the diagnostic request message into a data frame conforming to the CAN protocol specification, and sends it to the bus via the CAN transceiver. This process is entirely completed at the driver layer, ensuring that the message is directly and efficiently transmitted to the target controller in a multi-frame transmission session, avoiding intervention from the upper-layer protocol stack, and guaranteeing the continuity of the physical addressing session.

[0040] In summary, this embodiment of the application ensures that function-addressable messages are efficiently and reliably routed to the specific controller that needs to maintain the session by accurately identifying the target controller based on real-time session state, determining the physical channel using a preset mapping relationship, and finally completing the directed transmission of messages through the driver layer interface. This completely avoids the risk of the message entering the upper-layer protocol stack inside the domain controller. This not only fundamentally prevents interruptions in multi-frame transmission of physical addressing due to protocol stack state resets, ensuring the smooth completion of critical diagnostic operations, but also improves the utilization efficiency of network communication resources and enhances the stability and reliability of the vehicle diagnostic system in complex communication scenarios.

[0041] In some instances, the process of receiving a diagnostic request message also includes: Based on the domain controller system configuration information, determine the preset callback function used to process function addressing messages; Based on the registration interface between the preset callback function and the CAN driver layer, the preset callback function is registered to the CAN driver layer of the domain controller, and the CAN driver layer is configured to perform callback interception processing on the received diagnostic request messages.

[0042] For example, based on the system configuration information of the domain controller, a preset callback function for processing function-addressed messages is determined. The system configuration information is stored in the domain controller's non-volatile memory and contains predefined function-addressed message processing strategies and corresponding callback function identifiers. During the system startup initialization phase, by parsing the configuration items related to function-addressed processing in this configuration information, the predefined function names or function pointers are obtained, thereby determining the preset callback function that needs to be registered with the CAN driver layer. This function is typically a standard driver layer callback interface with a specific parameter list and return value type, such as the CanLPduReceiveCallout function.

[0043] Based on the registration interface between the preset callback function and the CAN driver layer, the preset callback function is registered to the CAN driver layer of the domain controller. This registration process is achieved by calling the standard service interface provided by the CAN driver module (such as Can_Init or driver-specific configuration functions). During registration, a pointer to the preset callback function and its associated configuration parameters (such as the required CAN identifier range or message type filtering conditions) must be passed in. After successful registration, the CAN driver layer records the function and its configuration in its internally maintained callback function list, enabling the driver layer to automatically trigger the invocation of the preset callback function when it receives a CAN message that meets the filtering conditions. Through the above registration operation, the integration between customized processing logic and the standard driver communication stack is completed, laying the operational foundation for the identification and interception of functionally addressed messages at the lowest level of message reception.

[0044] The CAN driver layer is configured to intercept and process received diagnostic request messages via callbacks. After registering the callback function, the CAN driver layer is configured to check the message against the filtering conditions set during registration each time a new CAN message is received, in addition to performing standard receive processing procedures (such as hardware buffer reading and frame verification). If the message meets the preset conditions (e.g., its identifier is the functional address 0x7DF), the driver layer will call the registered preset callback function before delivering the message to the upper-layer module (such as CanIf). This callback function can access, analyze, and even modify the message data within its execution context and has the ability to terminate further upward transmission of the message. Through this configuration, the system achieves early interception and processing of specific diagnostic request messages at the driver layer, completely preventing them from entering the upper-layer protocol stack modules such as CanIf, CANTP, PDUR, and DCM.

[0045] In summary, this embodiment dynamically determines and registers a preset callback function to the CAN driver layer based on configuration information during the system initialization phase. This enables function-addressed messages to be identified and intercepted at the CAN driver layer along the transmission path, thereby completely avoiding a series of state conflicts and resource release issues that might arise if they enter the upper-layer protocol stack. This interception method based on driver layer callbacks not only ensures the continuity and stability of physically addressed multi-frame transmission sessions but also effectively improves the system's ability and reliability in handling parallel diagnostic requests. Furthermore, since this mechanism is implemented at the driver layer, it has minimal impact on the original protocol stack architecture and possesses good compatibility and scalability.

[0046] In some instances, the domain controller includes at least one of the following: intelligent driving domain controller, body domain controller, and cockpit domain controller.

[0047] For example, the vehicle diagnostic message processing method provided in this application has broad applicability. By pre-setting callback functions in the CAN driver layer to intercept and specifically route function-addressed messages, this design does not depend on the type or function of a specific domain controller, but is based on the common communication and diagnostic processing flow under the AUTOSAR CP architecture. Therefore, it can be applied equally to various domain control platforms such as intelligent driving domain controllers, body domain controllers, and cockpit domain controllers. For intelligent driving domain controllers, which need to handle diagnostic requests from a large number of sensors such as radar and cameras, this method can effectively ensure that they are not interfered with by function-addressed broadcasts when performing multi-frame calibration or data writing. For body domain controllers, when managing the diagnosis of body components such as doors and lights, this method can ensure that the session maintenance command of function addressing will not interrupt its long frame transmission of physical addressing to specific ECUs. For cockpit domain controllers, when handling diagnostic services for infotainment systems or instrument panels, a mechanism can also be used to prevent critical data transmission from being accidentally reset. Through a unified and standardized implementation mechanism, a preset callback function is determined and registered to the CAN driver layer based on configuration information during the system initialization phase. When a message is received, the callback function is called to intercept and forward the message based on the addressing mode judgment result. It can run reliably in different types of domain controllers, effectively solving the common problem of physical addressing multi-frame transmission interruption caused by function addressing messages intruding into the upper-layer protocol stack in various domain control scenarios, and improving the robustness and consistency of vehicle diagnostic communication.

[0048] Please see Figure 2 This is a schematic diagram of a vehicle diagnostic message processing device provided in an embodiment of this application, applied to a domain controller, including: Diagnostic message acquisition unit 21 is used to receive diagnostic request messages; Addressing mode determination unit 22 is used to determine the target addressing mode of the diagnostic request message based on the diagnostic request message; The callback function processing unit 23 is used to process the diagnostic request message through the preset callback function of the CAN driver layer of the domain controller when the target addressing mode is functional addressing, so as to prevent the diagnostic request message from entering the upper layer protocol stack process. The diagnostic message sending unit 24 is used to send a diagnostic request message to the target controller, wherein the target controller is the controller in the current domain controller that is in a multi-frame transmission session.

[0049] Please see Figure 3 This application also provides an electronic device 300, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements the steps of the vehicle diagnostic message processing method.

[0050] Since the electronic device described in this embodiment is the device used to implement a vehicle diagnostic message processing device in the embodiments of this application, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in the embodiments of this application. Therefore, how the electronic device implements the method in the embodiments of this application will not be described in detail here. Any device used by those skilled in the art to implement the method in the embodiments of this application is within the scope of protection of this application.

[0051] In practice, when the computer program 311 is executed by the processor, it can implement any of the embodiments corresponding to the first aspect.

[0052] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0053] Those skilled in the art will understand that embodiments of this application can provide methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media containing computer-readable program code.

[0054] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0055] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0056] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0057] This application also provides a computer program product, which includes computer software instructions that, when executed on a processing device, cause the processing device to perform... Figure 1 The flowchart of a vehicle diagnostic message processing method in a corresponding embodiment.

[0058] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, computer instructions may be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium may be any usable medium that a computer can store or a data storage device such as a server or data center that integrates one or more usable media. The usable medium may be a magnetic medium, an optical medium, or a semiconductor medium, etc.

[0059] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0060] In the several embodiments provided in this application, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Furthermore, the mutual couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0061] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0062] 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 units described above can be implemented in the form of hardware and / or software functional units.

[0063] 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 computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device to execute all or part of the steps of the methods in 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, read-only memory, magnetic disks, or optical disks.

[0064] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0065] Although preferred embodiments have been described in this specification, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications that fall outside the scope of this specification.

[0066] Obviously, those skilled in the art can make various modifications to this specification without departing from its spirit and scope. Therefore, this specification also intends to include any modifications that fall within the scope of the claims and their equivalents.

Claims

1. A vehicle diagnostic message processing method applied to a domain controller, characterized in that, The method comprises the following steps: receiving a diagnostic request message; determining a target addressing mode of the diagnostic request message based on the diagnostic request message; when the target addressing mode is functional addressing, processing the diagnostic request message through a preset callback function of a CAN driver layer of the domain controller to prevent the diagnostic request message from entering an upper layer protocol stack process; sending the diagnostic request message to a target controller, wherein the target controller is a controller in a multi-frame transmission session in the current domain controller.

2. The method of claim 1, wherein, The target addressing mode comprises functional addressing or physical addressing, and the step of determining the target addressing mode of the diagnostic request message based on the diagnostic request message comprises: determining the target addressing mode of the diagnostic request message as the functional addressing or the physical addressing based on a target address field contained in the diagnostic request message.

3. The method of claim 1, wherein, The step of processing the diagnostic request message through the preset callback function of the CAN driver layer of the domain controller to prevent the diagnostic request message from entering the upper layer protocol stack process comprises: calling the preset callback function of the CAN driver layer; intercepting the diagnostic request message through the receiving callback function to prevent the diagnostic request message from entering the upper layer protocol stack process.

4. The method of claim 1, wherein, The step of sending the diagnostic request message to the target controller comprises: determining a target controller identifier in a multi-frame transmission session based on a current diagnostic session state of the domain controller; determining a target CAN channel identifier corresponding to the target controller identifier from a preset mapping relationship between controller identifiers and CAN channel identifiers based on the target controller identifier; calling a sending interface of the CAN driver layer based on the target CAN channel identifier; sending the diagnostic request message to the target controller through the sending interface.

5. The method of claim 1, wherein, Before the step of receiving the diagnostic request message, the method further comprises the following steps: determining a preset callback function for processing functional addressing messages based on system configuration information of the domain controller; registering the preset callback function to the CAN driver layer of the domain controller based on a registration interface between the preset callback function and the CAN driver layer, and configuring the CAN driver layer to perform callback interception processing on the received diagnostic request message.

6. The method of claim 4, wherein, The step of determining the target controller identifier in the multi-frame transmission session based on the current diagnostic session state of the domain controller comprises: judging whether there is a controller in the multi-frame transmission session based on current diagnostic session states of the controllers in the domain controller; if the judgment result is that there is, generating the target controller identifier based on an identifier of the controller in the multi-frame transmission session.

7. The method of claim 1, wherein, The domain controller comprises at least one of an intelligent driving domain controller, a vehicle body domain controller and a cockpit domain controller.

8. A vehicle diagnostic message processing apparatus applied to a domain controller, characterized by, The method comprises the following steps: a diagnostic message acquisition unit is configured to receive a diagnostic request message; an addressing mode determination unit is configured to determine a target addressing mode of the diagnostic request message based on the diagnostic request message; The callback function processing unit is configured to, when the target addressing mode is function addressing, process the diagnostic request message by a preset callback function of a CAN driver layer of the domain controller to prevent the diagnostic request message from entering an upper layer protocol stack process. The diagnostic message sending unit is configured to send the diagnostic request message to a target controller, wherein the target controller is a controller in a multi-frame transmission session in the domain controller.

9. An electronic device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor is configured to implement the steps of the vehicle diagnostic message processing method according to any one of claims 1 to 7 when executing the computer program stored in the memory.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executable on the processor to implement the steps of the vehicle diagnostic message processing method according to any one of claims 1 to 7.

Images