Vehicle diagnosis method, device, equipment and storage medium

Abstract

The application provides a vehicle diagnosis method, device and equipment and a storage medium. The method is applied to a vehicle. The vehicle is provided with a first chip and a second chip. Each chip is provided with a synchronization module for synchronizing data with other chips. In the method, the vehicle receives a diagnosis request sent by a diagnosis instrument through the first chip. The diagnosis request carries a service to be diagnosed. The first chip is provided with a UDS. Then, a mapping relationship between the service stored in the first chip and the chip is determined to determine the second chip corresponding to the service to be diagnosed. Further, the diagnosis request is synchronized to the second chip through the first synchronization module of the first chip. Then, the diagnosis request is processed by the second chip to obtain a diagnosis result. Finally, the diagnosis result is synchronized to the first chip through the second synchronization module of the second chip. The development cycle and maintenance cost are reduced, and the development efficiency and code quality are improved.

Description

Technical Field

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

[0002] With the increasing popularity of vehicles, they have become a common means of transportation, greatly facilitating people's daily travel.

[0003] Vehicles inevitably experience malfunctions during use. When a malfunction occurs, a diagnostic tool can be used to diagnose it, and the diagnostic results can be displayed on the tool's LCD screen, allowing users to quickly identify the location and cause of the malfunction. Specifically, during the diagnostic process, the diagnostic tool can send a diagnostic request to a chip equipped with Unified Diagnostic Services (UDS) (such as a System-on-Chip (SOC) or Microcontroller Unit (MCU)) to obtain the diagnostic results returned by that chip.

[0004] However, existing technologies suffer from long development cycles, low development efficiency, and high maintenance costs. Summary of the Invention

[0005] This application provides a vehicle diagnostic method, apparatus, device, and storage medium to address the problems of long development cycles, low development efficiency, and high maintenance costs in existing technologies.

[0006] In a first aspect, embodiments of this application provide a vehicle diagnostic method applied to a vehicle, wherein the vehicle is equipped with a first chip and a second chip, the first chip being a System-on-a-Chip (SoC) or an MCU, and the second chip being a SoC or an MCU, each chip being equipped with a synchronization module for data synchronization with other chips, the method comprising:

[0007] The first chip receives diagnostic requests sent by the diagnostic instrument, the diagnostic requests carrying diagnostic services to be diagnosed, and the first chip is equipped with UDS.

[0008] The second chip corresponding to the service to be diagnosed is determined by the mapping relationship between services and chips stored in the first chip;

[0009] The diagnostic request is synchronized to the second chip via the first synchronization module of the first chip;

[0010] The diagnostic request is processed by the second chip to obtain a diagnostic result, which is used to indicate whether the service to be diagnosed has a fault.

[0011] The diagnostic results are synchronized to the first chip via the second synchronization module of the second chip.

[0012] In one possible design of the first aspect, synchronizing the diagnostic request to the second chip via a first synchronization module of the first chip includes:

[0013] The chip identifier in the diagnostic request is replaced by the first identifier of the first chip with the first identifier of the second chip through the first synchronization module;

[0014] The first synchronization module synchronizes the replaced diagnostic request to the second chip in the form of an SOA service.

[0015] Optionally, synchronizing the diagnostic results to the first chip via the second synchronization module of the second chip includes:

[0016] The second synchronization module replaces the chip identifier in the diagnostic result with the second identifier of the second chip and the second identifier of the first chip.

[0017] The second synchronization module synchronizes the replaced diagnostic results to the first chip in the form of SOA service.

[0018] Optionally, before receiving the diagnostic request sent by the diagnostic instrument through the first chip, the method further includes:

[0019] A chip identifier configuration table is configured for the synchronization module of each chip to perform data synchronization between chips. The chip identifier configuration table includes a first identifier and a second identifier for each chip.

[0020] In another possible design of the first aspect, prior to receiving the diagnostic request sent by the diagnostic instrument via the first chip, the method further includes:

[0021] Based on the services deployed on each chip, the DCM of each chip is configured separately; among them, each service is deployed on the corresponding chip in accordance with the UDS diagnostic protocol specification.

[0022] Optionally, before replacing the chip identifier in the diagnostic request from the first identifier of the first chip to the first identifier of the second chip via the first synchronization module, the method further includes:

[0023] The diagnostic request is synchronized to the first synchronization module through the first DTC module and the first PDU Router of the first chip, and the chip used to process the diagnostic request is indicated to be the second chip.

[0024] Accordingly, before replacing the chip identifier in the diagnostic result with the second identifier of the second chip via the second synchronization module, the method further includes:

[0025] The diagnostic result request is synchronized to the second synchronization module via the second DTC module and the second PDU Router of the second chip, and the chip used to process the diagnostic result is indicated to be the first chip.

[0026] Optionally, the method further includes:

[0027] The diagnostic results are returned to the diagnostic instrument via the DoIP module of the first chip.

[0028] Secondly, embodiments of this application provide a vehicle diagnostic device applied to a vehicle, wherein the vehicle is equipped with a first chip and a second chip, the first chip being a SOC or an MCU, and the second chip being a SOC or an MCU, each chip being equipped with a synchronization module for data synchronization with other chips, the device comprising:

[0029] The receiving module is used to receive a diagnostic request sent by the diagnostic instrument through the first chip, wherein the diagnostic request carries a diagnostic service to be diagnosed.

[0030] The first processing module is used to determine the second chip corresponding to the service to be diagnosed by means of the mapping relationship between services and chips stored in the first chip, wherein the first chip is deployed with UDS;

[0031] The first synchronization module is used to synchronize the diagnostic request to the second chip;

[0032] The second processing module is used to process the diagnostic request through the second chip and obtain a diagnostic result, which is used to indicate whether the service to be diagnosed has a fault.

[0033] The second synchronization module is used to synchronize the diagnostic results to the first chip.

[0034] In one possible design of the second aspect, the first synchronization module is specifically used for:

[0035] The chip identifier in the diagnostic request is replaced by the first identifier of the first chip with the first identifier of the second chip through the first synchronization module;

[0036] The first synchronization module synchronizes the replaced diagnostic request to the second chip in the form of an SOA service.

[0037] Optional, a second synchronization module, specifically used for:

[0038] The second synchronization module replaces the chip identifier in the diagnostic result with the second identifier of the second chip and the second identifier of the first chip.

[0039] The second synchronization module synchronizes the replaced diagnostic results to the first chip in the form of SOA service.

[0040] Optionally, before receiving the diagnostic request sent by the diagnostic instrument through the first chip, the device further includes:

[0041] The third processing module is used to configure a chip identifier configuration table for the synchronization module of each chip to perform data synchronization between chips. The chip identifier configuration table includes a first identifier and a second identifier for each chip.

[0042] In another possible design of the second aspect, before receiving the diagnostic request sent by the diagnostic instrument through the first chip, the third processing module is further configured to configure the DCM of each chip according to the services deployed on each chip; wherein each service is deployed on the corresponding chip according to the UDS diagnostic protocol specification.

[0043] Optionally, before replacing the chip identifier in the diagnostic request from the first identifier of the first chip to the first identifier of the second chip via the first synchronization module, the apparatus further includes:

[0044] A first DTC module and a first PDU Router, wherein the first DTC module and the first PDU Router are used to synchronize the diagnostic request to the first synchronization module and indicate that the chip used to process the diagnostic request is the second chip;

[0045] Accordingly, before the second synchronization module replaces the chip identifier in the diagnostic result with the second identifier of the second chip and then with the second identifier of the first chip, the device further includes:

[0046] The second DTC module and the second PDU Router are used to synchronize the diagnostic result request to the second synchronization module and indicate that the chip used to process the diagnostic result is the first chip.

[0047] Optionally, the device further includes:

[0048] The DoIP module is used to return the diagnostic results to the diagnostic instrument.

[0049] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and computer program instructions stored in the memory and executable on the processor, wherein the processor executes the computer program instructions to implement the methods provided in the first aspect and various possible designs.

[0050] Fourthly, embodiments of this application may provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the first aspect and various possible designs.

[0051] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, is used to implement the methods provided in the first aspect and various possible designs.

[0052] This application provides a vehicle diagnostic method, apparatus, device, and storage medium. The method is applied to a vehicle equipped with a first chip and a second chip. The first chip is either a System-on-a-Chip (SoC) or an MCU, and the second chip is also either an SoC or an MCU. Each chip has a synchronization module for data synchronization with other chips. In this method, the vehicle receives a diagnostic request from a diagnostic tool via the first chip. The diagnostic request carries a service to be diagnosed. The first chip has a UDS (User-Defined Service). The mapping relationship between services and chips stored in the first chip is used to determine the second chip corresponding to the service to be diagnosed. The diagnostic request is then synchronized to the second chip via the first synchronization module of the first chip. The second chip processes the diagnostic request to obtain a diagnostic result. Finally, the diagnostic result is synchronized back to the first chip via the second synchronization module of the second chip. This technical solution uses synchronization modules in each chip for data synchronization, replacing the custom communication interface used in the prior art. This saves the workload of developing a large amount of hand-written code for a custom communication interface, thereby reducing development cycle and maintenance costs, and improving development efficiency and code quality. Attached Figure Description

[0053] 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.

[0054] Figure 1 A schematic diagram of the AUTOSAR software architecture related to UDS in an existing SOC or MCU;

[0055] Figure 2 A schematic diagram of the AUTOSAR software architecture related to UDS in a SOC or MCU provided in the embodiments of this application;

[0056] Figure 3 A schematic flowchart of Embodiment 1 of the vehicle diagnostic method provided in this application;

[0057] Figure 4 This is a schematic diagram of the structure of the vehicle diagnostic device provided in the embodiments of this application;

[0058] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0059] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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 some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0061] Before introducing the embodiments of this application, the application background of the embodiments of this application will be explained first:

[0062] To ensure that users can promptly identify the location and cause of vehicle malfunctions, existing vehicles' Electrical Control Units (ECUs) are equipped with a User-Defined System (UDS). The UDS includes internal diagnostic and service processing functions. The internal diagnostic functions include self-detection of faults during ECU initialization or shutdown, and continuous fault self-detection. The service processing functions include fault code acquisition, input / output control, secure access, data acquisition, routine control, and refresh processing.

[0063] Currently, most autonomous driving domain controllers adopt a hardware architecture solution of single SoC plus single MCU (or dual MCU) or multiple SoCs plus single MCU (or dual MCU). The UDS-related parts of the SoC or MCU can be implemented through the Automotive Open System Architecture (AUTOSAR) software architecture. Figure 1 To express. Figure 1 A schematic diagram of the AUTOSAR software architecture related to UDS in an existing SOC or MCU. For example... Figure 1As shown, the AUTOSAR software architecture includes: a Running System (RTE) layer, a Basic Software (BSW) layer, an Ethernet Interface (EthIf) layer, and an Ethernet Driver layer. The BSW layer includes a Data Communication Module (DCM), a Power Distribution Unit (PDU) router, a Diagnostic Communication over Internet Protocol (DoIP) module, a Socket Adaptor (SOAd) module, and a Transmission Control Protocol / Internet Protocol (TCP / IP) module.

[0064] Currently, standard solutions for autonomous driving domain controllers using adaptive AUTOSAR and classic AUTOSAR can only implement UDS solutions for single SOCs and single MCUs. That is, using a tester as a client, diagnostic operations can only be performed on a single SOC or MCU with a UDS deployed.

[0065] Among them, the SOC or MCU with UDS deployed is a Class A ECU, and the others are Class B ECUs. Since OEMs treat the SOC and MCU as a whole autonomous driving domain controller, they typically only provide one diagnostic protocol specification. Class A and Class B ECUs need to use a custom communication interface based on the User Datagram Protocol (UDP) to handle the reading and writing of Data Identifiers (DIDs) for services 0x22 and 0x2E, fault-related operations for services 0x14 and 0x19, and other service-related operations. In other words, the Class A ECU, based on the diagnostic request sent by the diagnostic tool, obtains the information needed to process the service from the Class B ECU, centrally processes this information, and then responds to the UDS service.

[0066] Class A ECUs can determine whether a vehicle has a fault based on self-test results, store the corresponding fault information, and support a diagnostic communication protocol for interaction with the diagnostic tool. This diagnostic communication protocol is the UDS diagnostic protocol based on the Ethernet (ETH) bus. Class B ECUs can determine whether a fault has occurred based on self-test results and send the fault information to the Class A ECU. Class B ECUs do not support the diagnostic communication protocol for interaction with the diagnostic tool, but their input / output status information should be readable and input / output controlled by the Class A ECU. Their functional configuration requirements should be achieved by configuring the Class A ECU, and their logistics data information (including part numbers, hardware numbers, software numbers, etc.) should be obtainable by the Class A ECU. If a Class B ECU is connected to the ETH bus, it must support the "quiet mode" function (i.e., it must support diagnostic services $10 (sub-functions: default session and refresh session), $11 (sub-function: hard reset), and $3E in function addressing mode).

[0067] However, existing technologies increase the workload of developing and testing custom communication interfaces and centralized processing of Class A ECUs, and require the development of a large amount of handwritten code, which greatly reduces code quality and results in long development cycles, low development efficiency, and high maintenance costs.

[0068] Based on this, the technical concept of this application is as follows: In existing technologies, to achieve data interaction between Class A ECUs and Class B ECUs, a custom communication interface between them is added, requiring the development of a large amount of hand-written code, reducing development efficiency, increasing development cycle, and maintenance costs. Therefore, this application proposes a vehicle diagnostic method. Compared with existing technologies, the AUTOSAR software architecture used in this method adds a synchronization module, which can synchronize data with other chips. Thus, after a Class A ECU receives a diagnostic request from a diagnostic tool, it can synchronize the diagnostic request to the chip used to process the request through this synchronization module, eliminating the need to add a custom communication interface between chips, thereby reducing development cycle and maintenance costs, and improving development efficiency.

[0069] For example, the vehicle diagnostic method provided in this application embodiment can be applied to Figure 2 The diagram shows the AUTOSAR software architecture. Figure 2 This is a schematic diagram of the AUTOSAR software architecture related to UDS in the SOC or MCU provided in the embodiments of this application. Figure 2 As shown, the AUTOSAR software architecture includes: the rte layer, the Ethernet Interface layer, and the Ethernet Driver layer. The BSW layer includes the DCM, PDU Router, DoIP module, synchronization module, SoAd module, and TCP / IP module.

[0070] The synchronization module is used to synchronize data with other chips, such as SOCs or MCUs. In other words, this synchronization module can synchronize data to the synchronization modules of other chips, or it can retrieve data synchronized by other chips through their synchronization modules.

[0071] It should be understood that Figure 2 The AUTOSAR software architecture shown is deployed in a vehicle.

[0072] In practical applications, this synchronization module can be implemented as the DoIP_SOA_GateWay module. The DoIP_SOA_GateWay module is used to identify and process the distributed services of UDS, that is, to synchronize data with other chips.

[0073] The technical solution of this application will now be described in detail through specific embodiments.

[0074] It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0075] Figure 3 This is a schematic flowchart of an embodiment of the vehicle diagnostic method provided in this application. Figure 3 As shown, this vehicle diagnostic method is applied to a vehicle. The vehicle is equipped with a first chip and a second chip. The first chip is a System-on-a-Chip (SoC) or an MCU, and the second chip is also a SoC or an MCU. Each chip has a synchronization module for data synchronization with other chips. The vehicle diagnostic method may include the following steps:

[0076] S301, Receive diagnostic requests sent by the diagnostic instrument through the first chip.

[0077] When a circuit in a vehicle's electronic control system generates a signal exceeding the specified limit, the fault information reflected by that circuit and related sensors is stored in the ECU's internal memory in the form of a fault code. Users or repair personnel can use a diagnostic tool to send a diagnostic request to the vehicle so that the diagnostic tool can read the fault code and display it on its LCD screen.

[0078] It should be understood that because the first chip contains a UDS, it can interact with the diagnostic tool. In other words, the vehicle can receive diagnostic requests from the diagnostic tool through the first chip.

[0079] The diagnostic request carries a service to be diagnosed, which is the service corresponding to the aforementioned signal.

[0080] Optionally, diagnostic requests sent by the diagnostic instrument can be received through the DoIP module of the first chip.

[0081] S302. Determine the second chip corresponding to the service to be diagnosed by using the mapping relationship between services and chips stored in the first chip.

[0082] The mapping relationship between services and chips can be generated in advance by relevant personnel after allocating each service to each chip according to the UDS diagnostic protocol specification. For example, after relevant personnel allocate service 1 to chip 1, service 2 to chip 2, and service 3 to chip 3 according to the UDS diagnostic protocol specification, the vehicle can generate the mapping relationship between services and chips based on the above allocation relationship.

[0083] It should be understood that the above allocation relationship is only an example. In practical applications, multiple services can be allocated to the same chip. For example, services 1, 2, and 3 can all be allocated to chip 1, service 4 can be allocated to chip 2, and service 5 can be allocated to chip 3. That is to say, the relationship between services and chips can be one-to-one or many-to-one.

[0084] Optionally, in a specific example, the mapping relationship between the above services and chips can be represented by Table 1.

[0085] Table 1

[0086] serial number Serve chip 1 Service 1 Chip 1 2 Service 2 Chip 2 3 Service 3 Chip 3

[0087] As shown in Table 1, assuming the service to be diagnosed is service 1, the second chip corresponding to this service can be determined as chip 1 based on the mapping relationship shown in Table 1. Similarly, assuming the service to be diagnosed is service 3, the second chip corresponding to this service can be determined as chip 3 based on the mapping relationship shown in Table 1.

[0088] It should be understood that the above mapping relationship may also include other content and representation methods, which can be determined according to actual needs. This application embodiment does not specifically limit this.

[0089] It should be understood that when the aforementioned diagnostic services are deployed in the first chip, the second chip determined according to the above mapping relationship is the first chip itself. That is to say, the second chip can be any other SOC or MCU besides the first chip, or it can be the first chip itself.

[0090] S303. The diagnostic request is synchronized to the second chip through the first synchronization module of the first chip.

[0091] When the second chip is a different SOC or MCU than the first chip, the first chip does not have a diagnostic service deployed, so it cannot directly process the diagnostic request and needs to be synchronized to the second chip that has the diagnostic service deployed.

[0092] Optionally, the diagnostic request can be synchronized to the DCM of the second chip through the first synchronization module of the first chip, so that it can be processed by the DCM of the second chip.

[0093] Optionally, if the second chip is the first chip, this step is not required. That is, if the second chip is the first chip, S304 is executed directly after S302.

[0094] S304. The diagnostic request is processed through the second chip to obtain the diagnostic results.

[0095] Optionally, diagnostic processing can be performed on the service to be diagnosed via the DCM of the second chip and the diagnostic request, thereby generating diagnostic results.

[0096] The diagnostic results indicate whether the service to be diagnosed is faulty. Optionally, when the diagnostic results indicate that the service to be diagnosed is faulty, the cause of the fault can also be obtained.

[0097] Optionally, the diagnostic result can also be the above fault code.

[0098] S305. The diagnostic results are synchronized to the first chip through the second synchronization module of the second chip.

[0099] When the second chip is a different SOC or MCU than the first chip, since the second chip does not have a UDS, it cannot directly interact with the diagnostic instrument. Therefore, the diagnostic results need to be synchronized to the first chip so that the diagnostic results can be returned to the diagnostic instrument through the first chip.

[0100] Optionally, the diagnostic results can be synchronized to the first synchronization module of the first chip via the second synchronization module of the second chip.

[0101] Optionally, this step is not required if the second chip is the first chip.

[0102] The vehicle diagnostic method provided in this application involves a vehicle equipped with a first chip and a second chip. The first chip is either a System-on-a-Chip (SoC) or an MCU, and the second chip is also either an SoC or an MCU. Each chip has a synchronization module for data synchronization with other chips. The vehicle receives a diagnostic request from a diagnostic tool via the first chip. This diagnostic request carries a service to be diagnosed. The first chip has a UDS (User-Defined Service). The mapping relationship between services and chips stored in the first chip is used to determine the second chip corresponding to the service to be diagnosed. The diagnostic request is then synchronized to the second chip via the first chip's first synchronization module. The second chip processes the diagnostic request to obtain a diagnostic result, and finally, the diagnostic result is synchronized back to the first chip via the second synchronization module of the second chip. In this technical solution, data synchronization is performed through the synchronization modules in each chip, replacing the custom communication interface used in the prior art. This saves the workload of developing a large amount of hand-written code for a custom communication interface, thereby reducing development cycle and maintenance costs, and improving development efficiency and code quality.

[0103] Furthermore, the Service-Oriented Architecture (SOA) provided in this application is not limited to middleware type and is compatible with existing technical solutions, thus improving the compatibility of this technical solution. For example, the middleware type can be a Data Distribution Service (DDS) or a Scalable service-oriented middleware over IP (SOME / IP), etc.

[0104] Optionally, the functions of synchronization modules for different chips can be integrated into a single module.

[0105] In one possible implementation, S303 above can be achieved through the following steps:

[0106] The first synchronization module replaces the chip identifier in the diagnostic request with the first identifier of the first chip and the first identifier of the second chip; the first synchronization module then synchronizes the replaced diagnostic request to the second chip in the form of an SOA service.

[0107] Optionally, the first chip can have one or more identifiers. Similarly, the second chip can have one or more identifiers.

[0108] Optionally, the data exchanged between the first chip and the diagnostic instrument, or between the first chip and the second chip, should carry the identifier of the data recipient. When there are multiple identifiers for the first chip and / or the second chip, the specific identifier of the data recipient to be carried can be determined according to the data type of the exchange.

[0109] Optionally, the mapping relationship between identifiers and data types can be represented by Table 2.

[0110] Table 2

[0111]

[0112] As shown in Table 2, assuming the diagnostic instrument sends a diagnostic request to chip 1, the identifier carried in the diagnostic request is 0x0011. Optionally, the mapping relationship between the identifier and the data type may also include other content and forms, which can be determined according to the actual situation. This application embodiment does not impose specific limitations on this.

[0113] Since the diagnostic tool can only interact with the first chip, the identifier carried in the diagnostic request is the identifier of the first chip. When the second chip is a different SOC or MCU than the first chip, in order to process the diagnostic request through the second chip, the identifier of the first chip carried in the diagnostic request needs to be updated to the identifier of the second chip.

[0114] Optionally, referring to Table 2, assuming the first chip is chip 1 and the second chip is chip 2, the first identifier of the first chip can be 0x0011 and the first identifier of the second chip can be 0x0012.

[0115] In the above method, by replacing the first identifier of the first chip in the diagnostic request with the first identifier of the second chip, the diagnostic request is synchronized to the second chip, so that the diagnostic request can be processed by the second chip.

[0116] In one possible implementation, S305 above can be achieved through the following steps:

[0117] The second synchronization module replaces the chip identifier in the diagnostic results with the second identifier of the first chip, and then synchronizes the replaced diagnostic results to the first chip in the form of SOA service.

[0118] Since the diagnostic tool can only interact with the first chip, when the second chip is a different SOC or MCU than the first chip, the second chip cannot directly send the acquired diagnostic results to the diagnostic tool. Instead, it needs to synchronize the diagnostic results to the first chip so that the first chip can forward them to the diagnostic tool.

[0119] Optionally, referring to Table 2, assuming the first chip is chip 1 and the second chip is chip 2, the second identifier of the second chip can be 0x0022 and the second identifier of the first chip can be 0x0021.

[0120] In the above method, the diagnostic results are synchronized to the first chip by replacing the second identifier of the second chip in the diagnostic results with the second identifier of the first chip, so that the diagnostic results can be forwarded to the diagnostic instrument through the first chip in the future.

[0121] In one possible implementation, prior to S301 above, the vehicle diagnostic method may further include the following steps:

[0122] Configure a chip identifier configuration table for the synchronization module of each chip to enable data synchronization between chips. The chip identifier configuration table includes a first identifier and a second identifier for each chip.

[0123] Optionally, the chip identification configuration table can be represented by Table 2.

[0124] In practical applications, the synchronization modules of each chip can be configured during the vehicle development phase to enable data synchronization after the vehicle enters production. The diagnostic tool is unaware of this configuration; that is, in this technical solution, the way the diagnostic tool sends diagnostic requests to the vehicle and receives diagnostic results is consistent with existing technologies, requiring no changes to the diagnostic tool's configuration and making it easy to implement.

[0125] In one possible implementation, prior to S301 above, the vehicle diagnostic method may further include the following steps:

[0126] Based on the services deployed on each chip, the DCM for each chip is configured separately. Each service is deployed on its corresponding chip according to the UDS diagnostic protocol specification.

[0127] Optionally, services can be deployed on each chip according to the UDS diagnostic protocol specification. After deployment, the DCM of each chip can be configured according to the services deployed on each chip. There is a one-to-one correspondence between services and chips.

[0128] Optionally, the DID and Diagnostic Trouble Code (DTC) of each chip can also be configured.

[0129] Optionally, DCM, DID, and DTC can be configured according to the AUTOSAR methodology, or according to other existing configuration methods. The specific configuration method can be determined according to actual needs, and this application embodiment does not impose any specific restrictions on this.

[0130] In practical applications, the DCM of each chip can be configured during the vehicle development phase to facilitate subsequent processing of diagnostic requests. This technical solution achieves the same effect as existing technologies without requiring changes to the diagnostic tool's configuration, making it easy to implement.

[0131] In one possible implementation, before replacing the chip identifier in the diagnostic request from the first identifier of the first chip to the first identifier of the second chip via the first synchronization module, the vehicle diagnostic method may further include the following steps:

[0132] The diagnostic request is synchronized to the first synchronization module through the first DTC module of the first chip and the first PDU Router, and the chip used to process the diagnostic request is indicated to be the second chip.

[0133] Accordingly, before replacing the chip identifier in the diagnostic result with the second identifier of the first chip via the second synchronization module, the vehicle diagnostic method may further include the following steps:

[0134] The diagnostic result request is synchronized to the second synchronization module via the second DTC module and the second PDU Router of the second chip, and the chip used to process the diagnostic result is indicated to be the first chip.

[0135] In the above method, data can be synchronized to the chip's synchronization module via the chip's PDU Router, and then the synchronization module can be used to synchronize the data to other chips.

[0136] In one possible implementation, following S305 above, the vehicle diagnostic method may further include the following steps:

[0137] The diagnostic results are returned to the diagnostic instrument through the first DTC module of the first chip.

[0138] In the above method, the first DTC module, which is capable of data interaction with the diagnostic instrument, returns the diagnostic results to the diagnostic instrument so that the diagnostic instrument can display the diagnostic results so that users or maintenance personnel can intuitively obtain the diagnostic results.

[0139] Based on the vehicle diagnostic methods in the above embodiments, the following is a specific example to illustrate the method.

[0140] For example, the vehicle diagnostic method may include the following steps:

[0141] The diagnostic request sent by the diagnostic instrument is received through the DoIP module of the first chip, and the first DCM of the first chip determines whether the diagnostic request belongs to the first chip.

[0142] If so, the diagnostic request will be processed directly through the first DCM module of the first chip to generate a diagnostic result, and the diagnostic result will be returned to the diagnostic instrument through the DoIP module.

[0143] If not, the second chip corresponding to the diagnostic request is determined based on the service-chip mapping relationship stored in the first chip. The diagnostic request is then synchronized to the first synchronization module of the first chip, and the chip used to process the diagnostic request is designated as the second chip. Next, the chip identifier in the diagnostic request is replaced with the first identifier of the second chip using the first synchronization module and the chip identifier configuration table. The replaced diagnostic request is then synchronized to the second chip in the form of an SOA service. Further, the second chip processes the diagnostic request to obtain the diagnostic result. The second synchronization module then replaces the chip identifier in the diagnostic result with the second identifier of the first chip, and the replaced diagnostic result is synchronized to the first DCM of the first chip in the form of an SOA service. Finally, the diagnostic result is returned to the diagnostic instrument via the DoIP module of the first chip.

[0144] The following are embodiments of the apparatus of this application, which can be used to execute the embodiments of the method of this application. For details not disclosed in the embodiments of the apparatus of this application, please refer to the embodiments of the method of this application.

[0145] Figure 4 This is a schematic diagram of the vehicle diagnostic device provided in an embodiment of this application. Figure 4 As shown, this vehicle diagnostic device is applied to a vehicle. The vehicle has a first chip and a second chip deployed thereon. The first chip is a System-on-a-Chip (SoC) or an MCU, and the second chip is also a SoC or an MCU. Each chip has a synchronization module deployed for data synchronization with other chips. The vehicle diagnostic device includes:

[0146] The receiving module 41 is used to receive a diagnostic request sent by the diagnostic instrument through the first chip. The diagnostic request carries the diagnostic service to be diagnosed.

[0147] The first processing module 42 is used to determine the second chip corresponding to the service to be diagnosed by the mapping relationship between services and chips stored in the first chip. The first chip is equipped with UDS.

[0148] The first synchronization module 43 is used to synchronize diagnostic requests to the second chip;

[0149] The second processing module 44 is used to process the diagnostic request through the second chip and obtain the diagnostic result. The diagnostic result is used to indicate whether there is a fault in the service to be diagnosed.

[0150] The second synchronization module 45 is used to synchronize the diagnostic results to the first chip.

[0151] In one possible design of this application embodiment, the first synchronization module 43 is specifically used for:

[0152] The first synchronization module 43 replaces the chip identifier in the diagnostic request with the first identifier of the first chip and the first identifier of the second chip.

[0153] The replacement diagnostic request is synchronized to the second chip in the form of an SOA service through the first synchronization module 43.

[0154] Optional, the second synchronization module 45 is specifically used for:

[0155] The second synchronization module 45 replaces the chip identifier in the diagnostic result with the second identifier of the first chip.

[0156] The second synchronization module 45 synchronizes the replaced diagnostic results to the first chip in the form of SOA service.

[0157] Optionally, before receiving the diagnostic request sent by the diagnostic instrument via the first chip, the device further includes:

[0158] The third processing module is used to configure a chip identifier configuration table for the synchronization module of each chip to perform data synchronization between chips. The chip identifier configuration table includes a first identifier and a second identifier for each chip.

[0159] In another possible design of this application embodiment, before receiving the diagnostic request sent by the diagnostic instrument through the first chip, the third processing module is further configured to configure the DCM of each chip according to the services deployed on each chip; wherein, each service is deployed on the corresponding chip according to the UDS diagnostic protocol specification.

[0160] Optionally, before the chip identifier in the diagnostic request is replaced by the first identifier of the first chip with the first identifier of the second chip via the first synchronization module 43, the device further includes:

[0161] The first DTC module and the first PDU Router are used to synchronize diagnostic requests to the first synchronization module 43 and indicate that the chip used to process the diagnostic requests is the second chip.

[0162] Accordingly, before the second synchronization module 45 replaces the chip identifier in the diagnostic result from the second identifier of the second chip to the second identifier of the first chip, the device further includes:

[0163] The second DTC module and the second PDU Router are used to synchronize diagnostic result requests to the second synchronization module 45 and indicate that the chip used to process the diagnostic results is the first chip.

[0164] Optionally, the device may also include:

[0165] The DoIP module is used to return diagnostic results to the diagnostic instrument.

[0166] The vehicle diagnostic device provided in this application embodiment can be used to execute the vehicle diagnostic method in any of the above embodiments. Its implementation principle and technical effect are similar, and will not be described again here.

[0167] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. Additionally, these modules can be fully or partially integrated together, or implemented independently. The processing element mentioned here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed through the integrated logic circuits in the hardware of the processor element or through software instructions.

[0168] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device may include: a processor 51, a memory 52, and computer program instructions stored in the memory 52 and executable on the processor 51. When the processor 51 executes the computer program instructions, it implements the vehicle diagnostic method provided in any of the foregoing embodiments.

[0169] Optionally, the various components of the electronic device can be connected via a system bus.

[0170] The memory 52 can be a separate memory unit or a memory unit integrated into the processor. The number of processors can be one or more.

[0171] Optionally, the electronic device may also include an interface for interacting with other devices.

[0172] It should be understood that processor 51 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0173] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0174] All or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

[0175] The electronic device provided in this application embodiment can be used to execute the vehicle diagnostic method provided in any of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described again here.

[0176] This application provides a computer-readable storage medium storing computer-executable instructions that, when executed on a computer, cause the computer to perform the aforementioned vehicle diagnostic method.

[0177] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory, electrically erasable programmable read-only memory, erasable programmable read-only memory, programmable read-only memory, read-only memory, magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0178] Optionally, a readable storage medium can be coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Alternatively, the readable storage medium can be an integral part of the processor. Both the processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components within the device.

[0179] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the above-described vehicle diagnostic method.

[0180] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A vehicle diagnosis method characterized by, The application is applied to a vehicle, the vehicle is provided with a first chip and a second chip, the first chip is a system on chip (SOC) or a micro control unit (MCU), the second chip is a SOC or an MCU, each chip is provided with a synchronization module for synchronizing data with other chips, the synchronization module is a DoIP_SOA_GateWay module, and the method comprises the following steps: receiving a diagnosis request sent by a diagnosis instrument through the first chip, the diagnosis request carrying a service to be diagnosed, and the first chip being provided with a unified diagnosis service (UDS); determining the second chip corresponding to the service to be diagnosed through a mapping relationship between services and chips stored in the first chip, the mapping relationship between services and chips being generated after each service is allocated to each chip according to a UDS diagnosis protocol specification; synchronizing the diagnosis request to the second chip through a first synchronization module of the first chip; processing the diagnosis request through the second chip to obtain a diagnosis result, the diagnosis result being used to indicate whether the service to be diagnosed has a fault; synchronizing the diagnosis result to the first chip through a second synchronization module of the second chip; the step of synchronizing the diagnosis request to the second chip through the first synchronization module of the first chip comprises the following steps: replacing a chip identifier in the diagnosis request from a first identifier of the first chip to a first identifier of the second chip through the first synchronization module; synchronizing the replaced diagnosis request to the second chip in the form of a service-oriented architecture (SOA) service through the first synchronization module; the step of synchronizing the diagnosis result to the first chip through the second synchronization module of the second chip comprises the following steps: replacing a chip identifier in the diagnosis result from a second identifier of the second chip to a second identifier of the first chip through the second synchronization module; synchronizing the replaced diagnosis result to the first chip in the form of a SOA service through the second synchronization module.

2. The method of claim 1, wherein, Before the step of receiving the diagnosis request sent by the diagnosis instrument through the first chip, the method further comprises the following steps: configuring a chip identifier configuration table for the synchronization module of each chip to synchronize data between chips, the chip identifier configuration table comprising a first identifier and a second identifier of each chip.

3. The method according to claim 1 or 2, characterized in that, Before the step of receiving the diagnosis request sent by the diagnosis instrument through the first chip, the method further comprises the following steps: configuring a data communication module (DCM) of each chip according to services deployed on the chip; wherein each service is deployed on the corresponding chip according to a UDS diagnosis protocol specification.

4. The method of claim 3, wherein, Before the step of replacing the chip identifier in the diagnosis request from the first identifier of the first chip to the first identifier of the second chip through the first synchronization module, the method further comprises the following steps: synchronizing the diagnosis request to the first synchronization module through a first DTC module and a first power distribution unit (PDU) router of the first chip, and indicating that the chip for processing the diagnosis request is the second chip. Correspondingly, before the chip identifier in the diagnostic result is replaced by the second identifier of the first chip through the second synchronization module, the method further comprises: synchronizing the diagnostic result request to the second synchronization module through the second DTC module and the second PDU Router of the second chip, and indicating that the chip for processing the diagnostic result is the first chip.

5. The method of claim 4, wherein, The method further comprises: returning the diagnostic result to the diagnostic instrument through the DoIP module of the first chip.

6. A vehicle diagnostic apparatus characterized by comprising: The vehicle is applied to a vehicle, and the vehicle is deployed with a first chip and a second chip, the first chip is a system on chip (SOC) or a micro control unit (MCU), and the second chip is an SOC or an MCU. Each chip is deployed with a synchronization module for synchronizing data with other chips, the synchronization module is a DoIP_SOA_GateWay module, and the device comprises: a receiving module configured to receive a diagnostic request sent by a diagnostic instrument through the first chip, the diagnostic request carrying a to-be-diagnosed service; a first processing module configured to determine the second chip corresponding to the to-be-diagnosed service through a mapping relationship between services and chips stored in the first chip, the first chip being deployed with a unified diagnostic service (UDS), and the mapping relationship between services and chips being generated after each service is allocated to each chip according to a UDS diagnostic protocol specification; a first synchronization module configured to synchronize the diagnostic request to the second chip; a second processing module configured to process the diagnostic request through the second chip to obtain a diagnostic result, the diagnostic result being used to indicate whether the to-be-diagnosed service has a fault; a second synchronization module configured to synchronize the diagnostic result to the first chip; the first synchronization module is specifically configured to replace a chip identifier in the diagnostic request by a first identifier of the second chip through the first synchronization module; synchronize the replaced diagnostic request to the second chip in the form of a service-oriented architecture (SOA) service through the first synchronization module; the second synchronization module is specifically configured to replace a chip identifier in the diagnostic result by a second identifier of the first chip through the second synchronization module; synchronize the replaced diagnostic result to the first chip in the form of an SOA service through the second synchronization module.

7. A vehicle comprising: A processor, a memory, and computer program instructions stored on the memory and executable on the processor, wherein the processor is configured to implement the vehicle diagnostic method according to any one of claims 1 to 5 when executing the computer program instructions.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are configured to implement the vehicle diagnostic method according to any one of claims 1 to 5 when executed by the processor.

Images