A vehicle diagnostic method, system and apparatus

Abstract

The application provides a vehicle diagnosis method, system and device, comprising: identifying a current diagnosis state of a target vehicle based on a diagnosis state of a first core and a diagnosis state of a second core; receiving a diagnosis request initiated to the target vehicle, and performing diagnosis arbitration through the first core and the second core based on the current diagnosis state of the target vehicle to obtain a corresponding diagnosis arbitration result; and diagnosing the target vehicle according to the diagnosis arbitration result. The first core and the second core are two heterogeneous core processors in the same system level chip, and the target vehicle comprises a vehicle determined in advance or in real time. The application correctly responds to each diagnosis mode through diagnosis arbitration, so that the whole vehicle diagnosis does not conflict, the efficiency of the whole vehicle diagnosis is improved, the customer experience during the whole vehicle diagnosis is improved, and the diagnosis mode with strong customer relevance is preferentially ensured to be preferentially accessed.

Description

Technical Field

[0001] This invention relates to the field of vehicle communication technology, and in particular to a vehicle diagnostic method, system and device. Background Technology

[0002] Vehicle diagnostics (including updates) has always been an essential function in modern vehicular network communication applications. In recent years, with the continuous upgrading of in-vehicle electronic and electrical architecture, diagnostic / update methods and sources have become increasingly diversified, such as the increasingly popular OTA (Over-the-Air Technology) and remote diagnostics. Simultaneously, the central gateway controller, the access node (edge ​​node) for in-vehicle diagnostics, has become increasingly complex and functionally centralized. It has evolved from a traditional single MCU (Microcontroller Unit) to an MPU (Microprocessor Unit) + MCU, and further to a heterogeneous multi-core controller across functional domains. Therefore, different diagnostic methods may have different master control nodes on the central gateway controller. This series of changes has placed higher demands on diagnostic access, requiring the deployment of a new multi-diagnostic source management mechanism—a diagnostic arbitration mechanism—based on the overall vehicle diagnostic needs. This mechanism determines which diagnostic source the vehicle can access for diagnosis at any given time, preventing conflicts that could disrupt diagnostic functions or other normally functioning systems, negatively impacting the user experience. Summary of the Invention

[0003] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a vehicle diagnostic method, system and device to solve the technical problems existing in the prior art.

[0004] To achieve the above and other related objectives, the present invention provides a vehicle diagnostic method, comprising the following steps:

[0005] Based on the diagnostic status of the first core and the diagnostic status of the second core, the current diagnostic status of the target vehicle is identified; wherein, the first core and the second core are two heterogeneous core processors located in the same system-on-a-chip; the target vehicle includes vehicles determined in advance or in real time.

[0006] Receive a diagnostic request initiated to the target vehicle, and based on the current diagnostic status of the target vehicle, perform diagnostic arbitration through the first core and the second core to obtain the corresponding diagnostic arbitration result;

[0007] The target vehicle is diagnosed based on the diagnostic arbitration results.

[0008] In one embodiment of the present invention, the process of generating the diagnostic request in the diagnostic source according to the diagnostic behavior and the corresponding priority includes: generating a first diagnostic request received by a first core and a second diagnostic request received by a second core in the diagnostic source according to the diagnostic behavior and the corresponding priority.

[0009] The diagnostic behavior corresponding to the first diagnostic request includes: OBD (On-Board Diagnostics) diagnosis based on the controller domain network protocol;

[0010] The diagnostic actions corresponding to the second diagnostic request include: OTA flashing, OTA information collection mode, OBD diagnosis based on Internet protocol, remote diagnostic standard mode, and remote diagnostic information collection mode.

[0011] In one embodiment of the present invention, the process of receiving a diagnostic request initiated to a target vehicle and, based on the current diagnostic status of the target vehicle, performing diagnostic arbitration through the first core and the second core includes:

[0012] The first core is designated as the master node for diagnosis and arbitration, and the second core is designated as the slave node for diagnosis and arbitration.

[0013] If the current diagnostic status of the target vehicle is idle, when the first core receives the first diagnostic request, it directly agrees to access the first diagnostic request, and sets the diagnostic status of the first core to the first priority according to the diagnostic behavior corresponding to the first diagnostic request, and synchronously sets the diagnostic status of the second core.

[0014] Alternatively, if the current diagnostic status of the target vehicle is idle, when the second core receives the second diagnostic request, the second core identifies the address of the diagnostic source and queries the first core for access to the second diagnostic request according to the inter-core communication method between the second core and the first core; and when the first core replies with a positive response to the second core, agreeing to access the second diagnostic request, the first core identifies the message frame of the second diagnostic request and sets the diagnostic status of the first core to the corresponding priority according to the diagnostic behavior corresponding to the second diagnostic request, and synchronizes the diagnostic status of the second core.

[0015] In one embodiment of the present invention, the process of receiving a diagnostic request initiated to a target vehicle and, based on the current diagnostic status of the target vehicle, performing diagnostic arbitration through the first core and the second core includes:

[0016] The first core is designated as the master node for diagnosis and arbitration, and the second core is designated as the slave node for diagnosis and arbitration.

[0017] If the current diagnostic status of the target vehicle is first priority, then before exiting the current diagnostic, when the first core receives the first diagnostic request, it directly refuses to access the first diagnostic request; and when the first core receives an inquiry from the second core asking whether to access the second diagnostic access request, it replies with a negative response to the second core through the first core, refusing to access the second diagnostic request.

[0018] In one embodiment of the present invention, the process of receiving a diagnostic request initiated to a target vehicle and, based on the current diagnostic status of the target vehicle, performing diagnostic arbitration through the first core and the second core includes:

[0019] The first core is designated as the master node for diagnosis and arbitration, and the second core is designated as the slave node for diagnosis and arbitration.

[0020] If the current diagnostic status of the target vehicle is the second priority, then when the first core receives the first diagnostic request, it directly agrees to access the first diagnostic request, and sets the diagnostic status of the first core to the first priority according to the diagnostic behavior corresponding to the first diagnostic request, and synchronously sets the diagnostic status of the second core.

[0021] Alternatively, if the target vehicle's current diagnostic status is second priority, then when the second core receives the second diagnostic request, it queries the first core for access to the second diagnostic request according to the inter-core communication method between the second core and the first core; and the first core performs message frame identification on the second diagnostic request, and when it is identified that the diagnostic behavior corresponding to the second diagnostic request is based on Internet Protocol OBD diagnosis, Controller Area Network Protocol OBD diagnosis, OTA flashing, or remote diagnostic standard mode, the first core replies with a positive response to the second core, agreeing to access the second diagnostic request, and sets the diagnostic status of the first core to first priority, and synchronizes the diagnostic status of the second core; or, when it is identified that the diagnostic behavior corresponding to the second diagnostic request is OTA information collection mode, the first core replies with a negative response to the second core, refusing to access the second diagnostic request; or, when it is identified that the diagnostic behavior corresponding to the second diagnostic request is remote diagnostic information collection mode, the first core does not respond to the second core and continues to maintain the current diagnostic status.

[0022] In one embodiment of the present invention, the process of receiving a diagnostic request initiated to a target vehicle and, based on the current diagnostic status of the target vehicle, performing diagnostic arbitration through the first core and the second core includes:

[0023] The first core is designated as the master node for diagnosis and arbitration, and the second core is designated as the slave node for diagnosis and arbitration.

[0024] If the current diagnostic status of the target vehicle is the third priority, then when the first core receives the first diagnostic request, it directly agrees to access the first diagnostic request, and sets the diagnostic status of the first core to the first priority according to the diagnostic behavior corresponding to the first diagnostic request, and synchronously sets the diagnostic status of the second core.

[0025] Alternatively, if the current diagnostic status of the target vehicle is the third priority, when the second core receives the second diagnostic request, it queries the first core for access to the second diagnostic request according to the inter-core communication method between the second core and the first core; and the first core performs message frame identification on the second diagnostic request, and when it is identified that the diagnostic behavior corresponding to the second diagnostic request is OBD diagnosis based on Internet Protocol, OBD diagnosis based on Controller Area Network Protocol, OTA flashing, remote diagnostic standard mode, or OTA information collection mode, the first core replies with a positive response to the second core, agreeing to access the second diagnostic request, and sets the diagnostic status of the first core to the corresponding priority, and synchronizes the diagnostic status of the second core; or, when it is identified that the diagnostic behavior corresponding to the second diagnostic request is OTA information collection mode, the first core does not respond to the second core and continues to maintain the current diagnostic status.

[0026] In one embodiment of the present invention, before receiving the diagnostic request, the method further includes:

[0027] Based on the diagnostic methods pre-configured for the target vehicle, a diagnostic behavior adapted to the target vehicle is determined;

[0028] The diagnostic actions are prioritized to determine the priority of each diagnostic action.

[0029] The diagnostic request is generated in the diagnostic source based on the diagnostic behavior and its corresponding priority.

[0030] In one embodiment of the present invention, the diagnostic methods pre-configured for the target vehicle include at least one of the following: OBD diagnostic method, OTA diagnostic method, and remote diagnostic method;

[0031] The diagnostic behavior includes at least one of the following: OBD diagnosis based on Internet Protocol, OBD diagnosis based on Controller Area Network Protocol, OTA flashing, OTA information collection mode, remote diagnostic standard mode, and remote diagnostic information collection mode.

[0032] The priority of the diagnostic behavior includes: OBD diagnosis based on Internet Protocol, OBD diagnosis based on Controller Area Network Protocol, OTA flashing and remote diagnostic standard mode are the first priority, remote diagnostic information collection mode is the second priority, and OTA information collection mode is the third priority; wherein, the first priority is higher than the second priority, and the second priority is higher than the third priority.

[0033] The present invention also provides a vehicle diagnostic system, comprising:

[0034] The diagnostic status module is used to identify the current diagnostic status of the target vehicle based on the diagnostic status of the first core and the second core; wherein the first core and the second core are two heterogeneous core processors located in the same system-on-a-chip; the target vehicle includes vehicles determined in advance or in real time.

[0035] The diagnostic arbitration module is used to receive diagnostic requests initiated to the target vehicle, and based on the current diagnostic status of the target vehicle, to perform diagnostic arbitration through the first core and the second core to obtain the corresponding diagnostic arbitration result;

[0036] The vehicle diagnostic module is used to diagnose the target vehicle based on the diagnostic arbitration result.

[0037] The present invention also provides a vehicle diagnostic device, comprising:

[0038] processor; and,

[0039] A computer-readable medium storing instructions that, when executed by the processor, cause the device to perform a vehicle diagnostic method as described above.

[0040] The present invention also provides a computer-readable medium having instructions stored thereon, the instructions being loaded by a processor and executed as described in any of the above-described vehicle diagnostic methods.

[0041] As described above, the present invention provides a vehicle diagnostic method, system, and device, which have the following beneficial effects: Based on the diagnostic status of the first core and the diagnostic status of the second core, the current diagnostic status of the target vehicle is identified; a diagnostic request initiated to the target vehicle is received, and based on the current diagnostic status of the target vehicle, diagnostic arbitration is performed through the first and second cores to obtain a corresponding diagnostic arbitration result; the target vehicle is diagnosed according to the diagnostic arbitration result. Here, the first and second cores are two heterogeneous core processors located in the same system-on-a-chip, and the target vehicle includes vehicles determined in advance or in real time. Therefore, the present invention, through diagnostic arbitration, provides a correct response to each diagnostic method access, ensuring that vehicle diagnostics do not conflict. This not only improves the efficiency of vehicle diagnostics but also enhances the customer experience during vehicle diagnostics, prioritizing the access of diagnostic methods that are more relevant to on-site diagnosis and customer needs. Attached Figure Description

[0042] Figure 1 This is a schematic flowchart of a vehicle diagnostic method provided in one embodiment of the present invention;

[0043] Figure 2 This is a schematic flowchart of a vehicle diagnostic method provided in another embodiment of the present invention;

[0044] Figure 3 This is a schematic diagram of the hardware structure of a vehicle diagnostic system provided in one embodiment of the present invention;

[0045] Figure 4 This is a schematic diagram illustrating an exemplary system architecture for applying the technical solutions in one or more embodiments of the present invention;

[0046] Figure 5 This is a schematic diagram of the hardware structure of a vehicle diagnostic device suitable for implementing one or more embodiments of the present invention. Detailed Implementation

[0047] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0048] It should be noted that the illustrations provided in this embodiment are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0049] Figure 1 A schematic flowchart of a vehicle diagnostic method according to an embodiment of the present invention is shown. Specifically, in an exemplary embodiment, as follows... Figure 1 As shown, this embodiment provides a vehicle diagnostic method, which includes the following steps:

[0050] S110, based on the diagnostic status of the first core and the diagnostic status of the second core, the current diagnostic status of the target vehicle is identified; wherein, the first core and the second core are two heterogeneous core processors located in the same system-on-a-chip; the target vehicle includes vehicles determined in advance or in real time. As an example, in this embodiment, the first core can be an R core and the second core can be an A core.

[0051] S120, receive a diagnostic request initiated to the target vehicle, and based on the current diagnostic status of the target vehicle, perform diagnostic arbitration through the first core and the second core to obtain the corresponding diagnostic arbitration result;

[0052] S130, diagnose the target vehicle based on the diagnostic arbitration results.

[0053] Therefore, this embodiment uses diagnostic arbitration to provide the correct response when each diagnostic method is accessed, so that there are no conflicts in the whole vehicle diagnosis. This not only improves the efficiency of the whole vehicle diagnosis, but also improves the customer experience during the whole vehicle diagnosis, and prioritizes the access of diagnostic methods that are more relevant to the customer and are on-site diagnosis.

[0054] In an exemplary embodiment, before receiving a diagnostic request, this embodiment may further include: determining diagnostic behaviors adapted to the target vehicle based on diagnostic methods pre-configured for the target vehicle; prioritizing the diagnostic behaviors and determining the priority of each diagnostic behavior; and generating a diagnostic request in the diagnostic source according to the diagnostic behavior and its corresponding priority. The diagnostic methods pre-configured for the target vehicle include, but are not limited to: OBD (On-Board Diagnostics) diagnostic methods, OTA (Over-the-Air Technology) diagnostic methods, and remote diagnostic methods. Diagnostic behaviors include, but are not limited to: OBD diagnostics based on Internet Protocol, OBD diagnostics based on Controller Area Network Protocol, OTA flashing, OTA information collection mode, remote diagnostic standard mode, and remote diagnostic information collection mode. The priorities of the diagnostic behaviors include: OBD diagnostics based on Internet Protocol, OBD diagnostics based on Controller Area Network Protocol, OTA flashing, and remote diagnostic standard mode are the first priority; remote diagnostic information collection mode is the second priority; and OTA information collection mode is the third priority; wherein the first priority is higher than the second priority, and the second priority is higher than the third priority. Specifically, this embodiment, based on three diagnostic methods—OBD diagnostics, OTA diagnostics, and remote diagnostics—further subdivides diagnostic behaviors into six types according to actual application scenarios: OBD DoIP (Diagnostic Over Internet Protocol), OBD DoCAN (Diagnostic Over Controller Area Network), OTA flashing, OTA information collection mode, remote diagnostic standard mode, and remote diagnostic information collection mode. Then, based on the priority during actual use, the six diagnostic behaviors are divided into three levels from high to low, with higher priority behaviors able to preempt and interrupt lower priority behaviors at any time. In this embodiment, the three levels are: first priority, second priority, and third priority; where first priority is higher than second priority, and second priority is higher than third priority. First priority diagnostic behaviors include: OBD DoIP, OBD DoCAN, OTA flashing, and remote diagnostic standard mode; these behaviors are available on a first-come, first-served basis and cannot be preempted. Second priority diagnostic behavior is: remote diagnostic information collection mode. Third priority diagnostic behavior is: OTA information collection mode. Therefore, this embodiment considers six different diagnostic methods from different diagnostic sources to access the vehicle's diagnostic scenarios, which can meet the access response of the six diagnostic methods according to different usage scenarios, and enable the vehicle to access the appropriate diagnostic method according to the three-level definition of usage scenario priority.Furthermore, by employing a three-level diagnostic arbitration method, the system provides the correct response when each diagnostic method is accessed, ensuring that there are no conflicts in the vehicle diagnostics process and improving the efficiency of the vehicle diagnostics process.

[0055] According to the above description, in an exemplary embodiment, the process of generating a diagnostic request in the diagnostic source based on the diagnostic behavior and its corresponding priority includes: generating a first diagnostic request received by a first core and a second diagnostic request received by a second core in the diagnostic source based on the diagnostic behavior and its corresponding priority; wherein, the diagnostic behavior corresponding to the first diagnostic request includes: OBD diagnostics based on the controller domain network protocol; the diagnostic behavior corresponding to the second diagnostic request includes: OTA flashing, OTA information collection mode, OBD diagnostics based on the Internet protocol, remote diagnostic standard mode, and remote diagnostic information collection mode. As an example, in this embodiment, the first core can be an R core, and the second core can be an A core.

[0056] In an exemplary embodiment, the process of receiving a diagnostic request initiated to a target vehicle and arbitrating diagnostics based on the current diagnostic status of the target vehicle through a first core and a second core includes: designating the first core as the diagnostic arbitration master node and the second core as the diagnostic arbitration slave node; if the current diagnostic status of the target vehicle is idle, when the first core receives the first diagnostic request, it directly agrees to access the first diagnostic request, sets the diagnostic status of the first core to the first priority according to the diagnostic behavior corresponding to the first diagnostic request, and synchronizes the diagnostic status of the second core. Alternatively, the first core is designated as the diagnostic arbitration master node and the second core as the diagnostic arbitration slave node; if the current diagnostic status of the target vehicle is idle, when the second core receives the second diagnostic request, it identifies the address of the diagnostic source through the second core, and queries the first core for access to the second diagnostic request according to the inter-core communication method between the second core and the first core; and when the first core replies with a positive response to the second core, agreeing to access the second diagnostic request, the first core identifies the message frame of the second diagnostic request, sets the diagnostic status of the first core to the corresponding priority according to the diagnostic behavior corresponding to the second diagnostic request, and synchronizes the diagnostic status of the second core. In this implementation, when the target vehicle's current diagnostic status is first priority, both the first core and the second core are in first priority status; when the target vehicle's current diagnostic status is second priority, both the first core and the second core are in second priority status; when the target vehicle's current diagnostic status is third priority, both the first core and the second core are in third priority status. As an example, in this embodiment, the first core can be an R core, and the second core can be an A core.

[0057] In an exemplary embodiment, the process of receiving a diagnostic request initiated to a target vehicle and arbitrating diagnostics based on the current diagnostic status of the target vehicle through a first core and a second core includes: designating the first core as the diagnostic arbitration master node and the second core as the diagnostic arbitration slave node; if the current diagnostic status of the target vehicle is of first priority, then before exiting the current diagnosis, when the first core receives the first diagnostic request, it directly rejects access to the first diagnostic request; and when the first core receives an inquiry from the second core asking whether to access the second diagnostic access request, it replies with a negative response to the second core, rejecting access to the second diagnostic request. In this embodiment, when the current diagnostic status of the target vehicle is of first priority, the diagnostic status of both the first core and the second core is of first priority; when the current diagnostic status of the target vehicle is of second priority, both the first core and the second core are of second priority; when the current diagnostic status of the target vehicle is of third priority, both the first core and the second core are of third priority. As an example, the first core in this embodiment can be an R core, and the second core can be an A core.

[0058] In an exemplary embodiment, the process of receiving a diagnostic request initiated to a target vehicle and arbitrating a diagnosis through a first core and a second core based on the current diagnostic status of the target vehicle includes: designating the first core as the diagnostic arbitration master node and the second core as the diagnostic arbitration slave node; if the current diagnostic status of the target vehicle is the second priority, then when the first core receives the first diagnostic request, it directly agrees to access the first diagnostic request, and sets the diagnostic status of the first core to the first priority according to the diagnostic behavior corresponding to the first diagnostic request, and synchronously sets the diagnostic status of the second core. Alternatively, the first core can be designated as the master node for diagnostic arbitration, and the second core as the slave node. If the target vehicle's current diagnostic status is second priority, when the second core receives the second diagnostic request, it queries the first core for access to the second diagnostic request according to the inter-core communication method between the second and first cores. The first core then identifies the message frames of the second diagnostic request. If the diagnostic behavior corresponding to the second diagnostic request is identified as OBD diagnostic based on Internet Protocol, OBD diagnostic based on Controller Area Network Protocol, OTA flashing, or remote diagnostic standard mode, the first core replies with a positive response to the second core, agreeing to access the second diagnostic request. At the same time, the diagnostic status of the first core is set to first priority, and the diagnostic status of the second core is synchronized. Alternatively, if the diagnostic behavior corresponding to the second diagnostic request is identified as OTA information collection mode, the first core replies with a negative response to the second core, refusing to access the second diagnostic request. Alternatively, if the diagnostic behavior corresponding to the second diagnostic request is identified as remote diagnostic information collection mode, the first core does not respond to the second core and continues to maintain the current diagnostic status. In this implementation, when the target vehicle's current diagnostic status is first priority, both the first core and the second core are in first priority status; when the target vehicle's current diagnostic status is second priority, both the first core and the second core are in second priority status; when the target vehicle's current diagnostic status is third priority, both the first core and the second core are in third priority status. As an example, in this embodiment, the first core can be an R core, and the second core can be an A core.

[0059] In an exemplary embodiment, the process of receiving a diagnostic request initiated to a target vehicle and arbitrating a diagnosis through a first core and a second core based on the current diagnostic status of the target vehicle includes: designating the first core as the master node for diagnostic arbitration and the second core as the slave node for diagnostic arbitration; if the current diagnostic status of the target vehicle is the third priority, then when the first core receives the first diagnostic request, it directly agrees to access the first diagnostic request, and sets the diagnostic status of the first core to the first priority according to the diagnostic behavior corresponding to the first diagnostic request, and synchronously sets the diagnostic status of the second core. Alternatively, the first core can be designated as the master node for diagnostic arbitration, and the second core as the slave node. If the target vehicle's current diagnostic status is third priority, when the second core receives the second diagnostic request, it queries the first core for access to the second diagnostic request according to the inter-core communication method between the second and first cores. The first core then identifies the message frames of the second diagnostic request. If the first core identifies that the diagnostic behavior corresponding to the second diagnostic request is OBD diagnostic based on Internet Protocol, OBD diagnostic based on Controller Area Network Protocol, OTA flashing, remote diagnostic standard mode, or OTA information collection mode, it sends a positive response to the second core, agreeing to access the second diagnostic request. The first core's diagnostic status is then set to the corresponding priority, and the second core's diagnostic status is synchronized. Alternatively, if the first core identifies that the diagnostic behavior corresponding to the second diagnostic request is OTA information collection mode, it does not respond to the second core and continues to maintain the current diagnostic status. In this implementation, when the target vehicle's current diagnostic status is first priority, both the first core and the second core are in first priority status; when the target vehicle's current diagnostic status is second priority, both the first core and the second core are in second priority status; when the target vehicle's current diagnostic status is third priority, both the first core and the second core are in third priority status. As an example, in this embodiment, the first core can be an R core, and the second core can be an A core.

[0060] In another exemplary embodiment of the present invention, Figure 2 A flowchart illustrating a vehicle diagnostic method is shown. Figure 2 As shown, this embodiment also provides a vehicle diagnostic method, including the following steps:

[0061] Based on three diagnostic methods—OBD diagnostics, OTA diagnostics, and remote diagnostics—diagnostic behaviors are further subdivided into six types according to actual application scenarios: OBD DoIP, OBD DoCAN, OTA flashing, OTA information collection mode, remote diagnostic standard mode, and remote diagnostic information collection mode. Then, based on their priority during actual use, these six diagnostic behaviors are divided into three levels from high to low, with higher priority behaviors able to preempt and interrupt lower priority behaviors at any time. In this implementation, the three levels are: first priority, second priority, and third priority; where first priority is higher than second priority, and second priority is higher than third priority. First priority diagnostic behaviors include: OBD DoIP, OBD DoCAN, OTA flashing, and remote diagnostic standard mode; these behaviors are available on a first-come, first-served basis and cannot be preempted. Second priority diagnostic behaviors include: remote diagnostic information collection mode. Third priority diagnostic behaviors include: OTA information collection mode. In this embodiment, the first priority diagnostic state can be set to LV1.1, the second priority diagnostic state can be set to LV1.2, and the third priority diagnostic state can be set to LV1.3.

[0062] The R core is used as the master node for diagnostic arbitration, and the A core is used as the slave node for diagnostic arbitration. The master control unit of OBD DoCAN is the R core of the multi-core SoC (System on Chip) chip, while the master control unit of other diagnostic methods usually uses the A core of the SoC chip.

[0063] According to the vehicle diagnostic design, core A acts as the DoIP edge node. OBD DoIP diagnostics, OTA access requests (including Flash and Info modes), and remote diagnostic access requests (including Standard and Info modes) are sent from the diagnostic source to core A. Core R, as the gateway node, sends OBD DoCAN diagnostic requests to its routing module. OTA flashing can also be called OTA Flash, OTA information collection mode can be called OTA Info, remote diagnostic standard mode can be called remote diagnostic Standard, and remote diagnostic information collection mode can be called remote diagnostic Info. At this point:

[0064] 1. When the vehicle's diagnostic status is idle (LV1.0), then:

[0065] If R core receives a diagnostic access request, it will directly agree to the access, set the diagnostic status to 1, and synchronize it to A core, so that the diagnostic status of A core is the same as that of R core.

[0066] If core A receives any diagnostic request, the arbitration slave node identifies the address of the diagnostic source, pre-classifies the diagnostic method (OBD, OTA, or remote diagnostics), and then queries the master node of core R via inter-core communication to inquire whether the diagnostic method can be accessed. Since the diagnostic state is idle at this time, the master node of core R replies to core A that it agrees to the access of the diagnostic method. At the same time, the master node identifies the specific message frame as OTA Flash, OTA Info, Remote Diagnostics Standard, or Remote Diagnostics Info, and sets the current diagnostic state to the corresponding level (LV1.1, LV1.2, or LV1.3) according to the above three priority classifications, and synchronizes the diagnostic state with core A.

[0067] 2. When the vehicle's diagnostic status is LV1.1, before the current diagnostic actively exits, if the R core master node attempts to access OBDDoCAN, the master node will directly reject the diagnostic access request sent from the A core side. The R core master node will then respond with a negative response, rejecting the access request.

[0068] 3. If the vehicle's diagnostic status is currently set to LV1.2, i.e., remote diagnostic information collection mode or remote diagnostic Info, then:

[0069] If the R core connects to OBD DoCAN, it can directly preempt the current diagnostic resources. After preemption, the diagnostic status will be upgraded to LV1.1 and synchronized to the A core, so that the diagnostic status of the A core is the same as that of the R core.

[0070] If access from core A can be requested from the master node of core R, and core R determines from the request message frame whether it is OBD, OTA Flash, or remote diagnostic standard mode, it can directly interrupt the current remote diagnostic Info mode, reply with a positive response to core A, access the diagnostic mode requested by core A, upgrade the diagnostic status to LV1.1, and synchronize it to core A, so that the diagnostic status of core A is the same as that of core R; if core R determines from the request message frame that it is OTA Info mode, it maintains the current remote diagnostic Info mode and the current diagnostic status, replies with a negative response to core A, and rejects OTA Info access.

[0071] 4. If the diagnostic status is set to LV1.3 at this time, i.e., OTA information collection mode or OTA Info, then:

[0072] If the OBD DoCAN on the R core side can directly preempt the current diagnostic resources after access, it will upgrade the diagnostic status to LV1.1 and synchronize it to the A core, so that the diagnostic status of the A core is the same as that of the R core.

[0073] If access on the A core side can query the R core master node via a request, the master node can directly interrupt the current OTAInfo mode, reply with a positive response to the A core, access the diagnostic mode requested by the A core, and upgrade the diagnostic status to LV1.1 or LV1.2 according to the message frame requested by the A core, and synchronize it to the A core, so that the diagnostic status of the A core is the same as that of the R core.

[0074] exist Figure 2 In this context, A Core represents the A core; R Core represents the R core; Arbitration Slave represents the arbitration slave node; Arbitration Master represents the arbitration master node; Request represents a query initiated by the A core to the R core; Response represents the response from the R core to the A core; Diag.Level Status represents the diagnostic status, i.e., Diag.Level Status in A Core represents the diagnostic status of the A core, and Diag.Level Status in R Core represents the diagnostic status of the R core; OBD DoIP represents OBD diagnostics based on Internet Protocol; OTA Flash / Info represents OTA flashing / OTA information collection mode, i.e., OTA Flash represents OTA flashing, and OTA Info represents OTA information collection mode; Remote Diag.Standard / Info represents remote diagnostic standard mode / remote diagnostic information collection mode, i.e., Remote Diag.Standard represents remote diagnostic standard mode, and RemoteDiag.Info represents remote diagnostic information collection mode; OBD DoCAN represents OBD diagnostics based on Controller Area Network Protocol.

[0075] Therefore, this embodiment, through the aforementioned arbitration logic design, can satisfy the access responses of six diagnostic methods based on different usage scenarios, and ensure that the vehicle accesses the appropriate diagnostic method according to a three-level definition of usage scenario priority. Furthermore, this embodiment considers six different diagnostic methods from different diagnostic sources accessing the vehicle's diagnostic scenarios. Through a two-level arbitration approach, it ensures correct responses for each diagnostic method access, preventing conflicts in vehicle diagnostics and improving diagnostic efficiency. Moreover, this embodiment enhances the customer experience during vehicle diagnostics by prioritizing on-site diagnostics and diagnostic methods with strong customer relevance, such as commonly used after-sales OBD diagnostics, OTA updates, and OTA diagnostics.

[0076] In any of the above embodiments, the A core and R core are designed based on the DRA821. Depending on the SoC, there may be cases where the routing node is placed on the M core. In this case, the R core master node can be placed on the M core, and the design logic of the vehicle diagnostic method is still applicable. Furthermore, in any of the above embodiments, remote diagnostics is divided into two modes: Standard and Info. Different manufacturers may use different definitions and names for remote diagnostics. As long as there is a need to differentiate remote diagnostics into two sub-priorities, the vehicle diagnostic method solution can be applied.

[0077] In summary, this invention provides a vehicle diagnostic method that identifies the current diagnostic status of a target vehicle based on the diagnostic status of a first core or R core and the diagnostic status of a second core or A core. It receives diagnostic requests initiated to the target vehicle and, based on the target vehicle's current diagnostic status, performs diagnostic arbitration through the first core or R core and the second core or A core to obtain a corresponding diagnostic arbitration result. The method then diagnoses the target vehicle based on the diagnostic arbitration result. The first core and second core are two heterogeneous core processors located in the same system-on-a-chip, and the target vehicle includes vehicles determined in advance or in real-time. Therefore, this method can satisfy the access response of six diagnostic methods according to different usage scenarios, and enables the vehicle to access the appropriate diagnostic method according to a three-level definition of usage scenario priority. Furthermore, this method, through diagnostic arbitration, provides correct responses to each diagnostic method access, ensuring no conflicts occur during vehicle diagnostics. This not only improves the efficiency of vehicle diagnostics but also enhances the customer experience during vehicle diagnostics, prioritizing diagnostic methods that are more relevant to on-site diagnosis and customer needs.

[0078] In another exemplary embodiment of the present invention, such as Figure 3 As shown, this embodiment provides a vehicle diagnostic system, including:

[0079] The diagnostic status module 310 is used to identify the current diagnostic status of the target vehicle based on the diagnostic status of the R core and the A core; wherein the R core and the A core are two heterogeneous core processors located in the same system-on-a-chip; the target vehicle includes vehicles determined in advance or in real time. As an example, in this embodiment, the first core can be the R core and the second core can be the A core.

[0080] The diagnostic arbitration module 320 is used to receive diagnostic requests initiated to the target vehicle and, based on the current diagnostic status of the target vehicle, to perform diagnostic arbitration through the R core and A core to obtain the corresponding diagnostic arbitration result.

[0081] The vehicle diagnostic module 330 is used to diagnose the target vehicle based on the diagnostic arbitration results.

[0082] Therefore, this embodiment uses diagnostic arbitration to provide the correct response when each diagnostic method is accessed, so that there are no conflicts in the whole vehicle diagnosis. This not only improves the efficiency of the whole vehicle diagnosis, but also improves the customer experience during the whole vehicle diagnosis, and prioritizes the access of diagnostic methods that are more relevant to the customer and are on-site diagnosis.

[0083] In an exemplary embodiment, before receiving a diagnostic request, this embodiment may further include: determining diagnostic behaviors adapted to the target vehicle based on diagnostic methods pre-configured for the target vehicle; prioritizing the diagnostic behaviors and determining the priority of each diagnostic behavior; and generating a diagnostic request in the diagnostic source according to the diagnostic behavior and its corresponding priority. The diagnostic methods pre-configured for the target vehicle include, but are not limited to: OBD (On-Board Diagnostics) diagnostic methods, OTA (Over-the-Air Technology) diagnostic methods, and remote diagnostic methods. Diagnostic behaviors include, but are not limited to: OBD diagnostics based on Internet Protocol, OBD diagnostics based on Controller Area Network Protocol, OTA flashing, OTA information collection mode, remote diagnostic standard mode, and remote diagnostic information collection mode. The priorities of the diagnostic behaviors include: OBD diagnostics based on Internet Protocol, OBD diagnostics based on Controller Area Network Protocol, OTA flashing, and remote diagnostic standard mode are the first priority; remote diagnostic information collection mode is the second priority; and OTA information collection mode is the third priority; wherein the first priority is higher than the second priority, and the second priority is higher than the third priority. Specifically, this embodiment, based on three diagnostic methods—OBD diagnostics, OTA diagnostics, and remote diagnostics—further subdivides diagnostic behaviors into six types according to actual application scenarios: OBD DoIP (Diagnostic Over Internet Protocol), OBD DoCAN (Diagnostic Over Controller Area Network), OTA flashing, OTA information collection mode, remote diagnostic standard mode, and remote diagnostic information collection mode. Then, based on the priority during actual use, the six diagnostic behaviors are divided into three levels from high to low, with higher priority behaviors able to preempt and interrupt lower priority behaviors at any time. In this embodiment, the three levels are: first priority, second priority, and third priority; where first priority is higher than second priority, and second priority is higher than third priority. First priority diagnostic behaviors include: OBD DoIP, OBD DoCAN, OTA flashing, and remote diagnostic standard mode; these behaviors are available on a first-come, first-served basis and cannot be preempted. Second priority diagnostic behavior is: remote diagnostic information collection mode. Third priority diagnostic behavior is: OTA information collection mode. Therefore, this embodiment considers six different diagnostic methods from different diagnostic sources to access the vehicle's diagnostic scenarios, which can meet the access response of the six diagnostic methods according to different usage scenarios, and enable the vehicle to access the appropriate diagnostic method according to the three-level definition of usage scenario priority.Furthermore, by employing a three-level diagnostic arbitration method, the system provides the correct response when each diagnostic method is accessed, ensuring that there are no conflicts in the vehicle diagnostics process and improving the efficiency of the vehicle diagnostics process.

[0084] According to the above description, in an exemplary embodiment, the process of generating a diagnostic request in the diagnostic source based on the diagnostic behavior and its corresponding priority includes: generating a first diagnostic request received by a first core and a second diagnostic request received by a second core in the diagnostic source based on the diagnostic behavior and its corresponding priority; wherein, the diagnostic behavior corresponding to the first diagnostic request includes: OBD diagnostics based on the controller domain network protocol; the diagnostic behavior corresponding to the second diagnostic request includes: OTA flashing, OTA information collection mode, OBD diagnostics based on the Internet protocol, remote diagnostic standard mode, and remote diagnostic information collection mode. As an example, in this embodiment, the first core can be an R core, and the second core can be an A core.

[0085] In an exemplary embodiment, the process of receiving a diagnostic request initiated to a target vehicle and arbitrating diagnostics based on the current diagnostic status of the target vehicle through a first core and a second core includes: designating the first core as the diagnostic arbitration master node and the second core as the diagnostic arbitration slave node; if the current diagnostic status of the target vehicle is idle, when the first core receives the first diagnostic request, it directly agrees to access the first diagnostic request, sets the diagnostic status of the first core to the first priority according to the diagnostic behavior corresponding to the first diagnostic request, and synchronizes the diagnostic status of the second core. Alternatively, the first core is designated as the diagnostic arbitration master node and the second core as the diagnostic arbitration slave node; if the current diagnostic status of the target vehicle is idle, when the second core receives the second diagnostic request, it identifies the address of the diagnostic source through the second core, and queries the first core for access to the second diagnostic request according to the inter-core communication method between the second core and the first core; and when the first core replies with a positive response to the second core, agreeing to access the second diagnostic request, the first core identifies the message frame of the second diagnostic request, sets the diagnostic status of the first core to the corresponding priority according to the diagnostic behavior corresponding to the second diagnostic request, and synchronizes the diagnostic status of the second core. In this implementation, when the target vehicle's current diagnostic status is first priority, both the first core and the second core are in first priority status; when the target vehicle's current diagnostic status is second priority, both the first core and the second core are in second priority status; when the target vehicle's current diagnostic status is third priority, both the first core and the second core are in third priority status. As an example, in this embodiment, the first core can be an R core, and the second core can be an A core.

[0086] In an exemplary embodiment, the process of receiving a diagnostic request initiated to a target vehicle and arbitrating diagnostics based on the current diagnostic status of the target vehicle through a first core and a second core includes: designating the first core as the diagnostic arbitration master node and the second core as the diagnostic arbitration slave node; if the current diagnostic status of the target vehicle is of first priority, then before exiting the current diagnosis, when the first core receives the first diagnostic request, it directly rejects access to the first diagnostic request; and when the first core receives an inquiry from the second core asking whether to access the second diagnostic access request, it replies with a negative response to the second core, rejecting access to the second diagnostic request. In this embodiment, when the current diagnostic status of the target vehicle is of first priority, the diagnostic status of both the first core and the second core is of first priority; when the current diagnostic status of the target vehicle is of second priority, both the first core and the second core are of second priority; when the current diagnostic status of the target vehicle is of third priority, both the first core and the second core are of third priority. As an example, the first core in this embodiment can be an R core, and the second core can be an A core.

[0087] In an exemplary embodiment, the process of receiving a diagnostic request initiated to a target vehicle and arbitrating a diagnosis through a first core and a second core based on the current diagnostic status of the target vehicle includes: designating the first core as the diagnostic arbitration master node and the second core as the diagnostic arbitration slave node; if the current diagnostic status of the target vehicle is the second priority, then when the first core receives the first diagnostic request, it directly agrees to access the first diagnostic request, and sets the diagnostic status of the first core to the first priority according to the diagnostic behavior corresponding to the first diagnostic request, and synchronously sets the diagnostic status of the second core. Alternatively, the first core can be designated as the master node for diagnostic arbitration, and the second core as the slave node. If the target vehicle's current diagnostic status is second priority, when the second core receives the second diagnostic request, it queries the first core for access to the second diagnostic request according to the inter-core communication method between the second and first cores. The first core then identifies the message frames of the second diagnostic request. If the diagnostic behavior corresponding to the second diagnostic request is identified as OBD diagnostic based on Internet Protocol, OBD diagnostic based on Controller Area Network Protocol, OTA flashing, or remote diagnostic standard mode, the first core replies with a positive response to the second core, agreeing to access the second diagnostic request. At the same time, the diagnostic status of the first core is set to first priority, and the diagnostic status of the second core is synchronized. Alternatively, if the diagnostic behavior corresponding to the second diagnostic request is identified as OTA information collection mode, the first core replies with a negative response to the second core, refusing to access the second diagnostic request. Alternatively, if the diagnostic behavior corresponding to the second diagnostic request is identified as remote diagnostic information collection mode, the first core does not respond to the second core and continues to maintain the current diagnostic status. In this implementation, when the target vehicle's current diagnostic status is first priority, both the first core and the second core are in first priority status; when the target vehicle's current diagnostic status is second priority, both the first core and the second core are in second priority status; when the target vehicle's current diagnostic status is third priority, both the first core and the second core are in third priority status. As an example, in this embodiment, the first core can be an R core, and the second core can be an A core.

[0088] In an exemplary embodiment, the process of receiving a diagnostic request initiated to a target vehicle and arbitrating a diagnosis through a first core and a second core based on the current diagnostic status of the target vehicle includes: designating the first core as the master node for diagnostic arbitration and the second core as the slave node for diagnostic arbitration; if the current diagnostic status of the target vehicle is the third priority, then when the first core receives the first diagnostic request, it directly agrees to access the first diagnostic request, and sets the diagnostic status of the first core to the first priority according to the diagnostic behavior corresponding to the first diagnostic request, and synchronously sets the diagnostic status of the second core. Alternatively, the first core can be designated as the master node for diagnostic arbitration, and the second core as the slave node. If the target vehicle's current diagnostic status is third priority, when the second core receives the second diagnostic request, it queries the first core for access to the second diagnostic request according to the inter-core communication method between the second and first cores. The first core then identifies the message frames of the second diagnostic request. If the first core identifies that the diagnostic behavior corresponding to the second diagnostic request is OBD diagnostic based on Internet Protocol, OBD diagnostic based on Controller Area Network Protocol, OTA flashing, remote diagnostic standard mode, or OTA information collection mode, it sends a positive response to the second core, agreeing to access the second diagnostic request. The first core's diagnostic status is then set to the corresponding priority, and the second core's diagnostic status is synchronized. Alternatively, if the first core identifies that the diagnostic behavior corresponding to the second diagnostic request is OTA information collection mode, it does not respond to the second core and continues to maintain the current diagnostic status. In this implementation, when the target vehicle's current diagnostic status is first priority, both the first core and the second core are in first priority status; when the target vehicle's current diagnostic status is second priority, both the first core and the second core are in second priority status; when the target vehicle's current diagnostic status is third priority, both the first core and the second core are in third priority status. As an example, in this embodiment, the first core can be an R core, and the second core can be an A core.

[0089] In another exemplary embodiment of the present invention, this embodiment also provides a vehicle diagnostic system for performing the following steps:

[0090] Based on three diagnostic methods—OBD diagnostics, OTA diagnostics, and remote diagnostics—diagnostic behaviors are further subdivided into six types according to actual application scenarios: OBD DoIP, OBD DoCAN, OTA flashing, OTA information collection mode, remote diagnostic standard mode, and remote diagnostic information collection mode. Then, based on their priority during actual use, these six diagnostic behaviors are divided into three levels from high to low, with higher priority behaviors able to preempt and interrupt lower priority behaviors at any time. In this implementation, the three levels are: first priority, second priority, and third priority; where first priority is higher than second priority, and second priority is higher than third priority. First priority diagnostic behaviors include: OBD DoIP, OBD DoCAN, OTA flashing, and remote diagnostic standard mode; these behaviors are available on a first-come, first-served basis and cannot be preempted. Second priority diagnostic behaviors include: remote diagnostic information collection mode. Third priority diagnostic behaviors include: OTA information collection mode. In this embodiment, the first priority diagnostic state can be set to LV1.1, the second priority diagnostic state can be set to LV1.2, and the third priority diagnostic state can be set to LV1.3.

[0091] The R core is used as the master node for diagnostic arbitration, and the A core is used as the slave node for diagnostic arbitration. The master control unit of OBD DoCAN is the R core of the multi-core SoC (System on Chip) chip, while the master control unit of other diagnostic methods usually uses the A core of the SoC chip.

[0092] According to the vehicle diagnostic design, core A acts as the DoIP edge node. OBD DoIP diagnostics, OTA access requests (including Flash and Info modes), and remote diagnostic access requests (including Standard and Info modes) are sent from the diagnostic source to core A. Core R, as the gateway node, sends OBD DoCAN diagnostic requests to its routing module. OTA flashing can also be called OTA Flash, OTA information collection mode can be called OTA Info, remote diagnostic standard mode can be called remote diagnostic Standard, and remote diagnostic information collection mode can be called remote diagnostic Info. At this point:

[0093] 1. When the vehicle's diagnostic status is idle (LV1.0), then:

[0094] If R core receives a diagnostic access request, it will directly agree to the access, set the diagnostic status to 1, and synchronize it to A core, so that the diagnostic status of A core is the same as that of R core.

[0095] If core A receives any diagnostic request, the arbitration slave node identifies the address of the diagnostic source, pre-classifies the diagnostic method (OBD, OTA, or remote diagnostics), and then queries the master node of core R via inter-core communication to inquire whether the diagnostic method can be accessed. Since the diagnostic state is idle at this time, the master node of core R replies to core A that it agrees to the access of the diagnostic method. At the same time, the master node identifies the specific message frame as OTA Flash, OTA Info, Remote Diagnostics Standard, or Remote Diagnostics Info, and sets the current diagnostic state to the corresponding level (LV1.1, LV1.2, or LV1.3) according to the above three priority classifications, and synchronizes the diagnostic state with core A.

[0096] 2. When the vehicle's diagnostic status is LV1.1, before the current diagnostic actively exits, if the R core master node attempts to access OBDDoCAN, the master node will directly reject the diagnostic access request sent from the A core side. The R core master node will then respond with a negative response, rejecting the access request.

[0097] 3. If the vehicle's diagnostic status is currently set to LV1.2, i.e., remote diagnostic information collection mode or remote diagnostic Info, then:

[0098] If the R core connects to OBD DoCAN, it can directly preempt the current diagnostic resources. After preemption, the diagnostic status will be upgraded to LV1.1 and synchronized to the A core, so that the diagnostic status of the A core is the same as that of the R core.

[0099] If access from core A can be requested from the master node of core R, and core R determines from the request message frame whether it is OBD, OTA Flash, or remote diagnostic standard mode, it can directly interrupt the current remote diagnostic Info mode, reply with a positive response to core A, access the diagnostic mode requested by core A, upgrade the diagnostic status to LV1.1, and synchronize it to core A, so that the diagnostic status of core A is the same as that of core R; if core R determines from the request message frame that it is OTA Info mode, it maintains the current remote diagnostic Info mode and the current diagnostic status, replies with a negative response to core A, and rejects OTA Info access.

[0100] 4. If the diagnostic status is set to LV1.3 at this time, i.e., OTA information collection mode or OTA Info, then:

[0101] If the OBD DoCAN on the R core side can directly preempt the current diagnostic resources after access, it will upgrade the diagnostic status to LV1.1 and synchronize it to the A core, so that the diagnostic status of the A core is the same as that of the R core.

[0102] If access on the A core side can query the R core master node via a request, the master node can directly interrupt the current OTAInfo mode, reply with a positive response to the A core, access the diagnostic mode requested by the A core, and upgrade the diagnostic status to LV1.1 or LV1.2 according to the message frame requested by the A core, and synchronize it to the A core, so that the diagnostic status of the A core is the same as that of the R core.

[0103] Therefore, this embodiment, through the aforementioned arbitration logic design, can satisfy the access responses of six diagnostic methods based on different usage scenarios, and ensure that the vehicle accesses the appropriate diagnostic method according to a three-level definition of usage scenario priority. Furthermore, this embodiment considers six different diagnostic methods from different diagnostic sources accessing the vehicle's diagnostic scenarios. Through a two-level arbitration approach, it ensures correct responses for each diagnostic method access, preventing conflicts in vehicle diagnostics and improving diagnostic efficiency. Moreover, this embodiment enhances the customer experience during vehicle diagnostics by prioritizing on-site diagnostics and diagnostic methods with strong customer relevance, such as commonly used after-sales OBD diagnostics, OTA updates, and OTA diagnostics.

[0104] In any of the above embodiments, the A core and R core are designed based on the DRA821. Depending on the SoC, there may be cases where the routing node is placed on the M core. In this case, the R core master node can be placed on the M core, and the design logic of the vehicle diagnostic system is still applicable. Furthermore, in any of the above embodiments, remote diagnostics is divided into two modes: Standard and Info. Different manufacturers may use different definitions and names for remote diagnostics. As long as there is a need to differentiate remote diagnostics into two sub-priorities, the vehicle diagnostic system solution can be applied.

[0105] In summary, this invention provides a vehicle diagnostic system that identifies the current diagnostic status of a target vehicle based on the diagnostic status of a first core or R core and the diagnostic status of a second core or A core. It receives diagnostic requests initiated to the target vehicle and, based on the target vehicle's current diagnostic status, performs diagnostic arbitration through the first core or R core and the second core or A core to obtain a corresponding diagnostic arbitration result. The system then diagnoses the target vehicle according to the diagnostic arbitration result. The first core and second core are two heterogeneous core processors located in the same system-on-a-chip, and the target vehicle includes vehicles determined in advance or in real-time. Therefore, this system can meet the access response requirements of six diagnostic methods according to different usage scenarios, and allows the vehicle to access the appropriate diagnostic method according to a three-level definition of usage scenario priority. Furthermore, by using diagnostic arbitration, this system provides correct responses to each diagnostic method access, ensuring no conflicts occur during vehicle diagnostics. This not only improves the efficiency of vehicle diagnostics but also enhances the customer experience during vehicle diagnostics, prioritizing diagnostic methods that are more relevant to on-site diagnosis and customer needs.

[0106] It should be noted that the vehicle diagnostic system provided in the above embodiments and the vehicle diagnostic method provided in the above embodiments belong to the same concept. The specific operation methods of each module have been described in detail in the method embodiments and will not be repeated here. In practical applications, the vehicle diagnostic system provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the system can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here. Therefore, the present invention effectively overcomes the various shortcomings of the prior art and has high industrial application value.

[0107] It should be noted that when processing relevant data (such as diagnostic information data) in the above embodiments, such as collecting, storing, using, processing, transmitting, providing, disclosing, and deleting data, it is done with or with the user's consent. For example, diagnostic information data may be obtained with the user's knowledge and consent; or it may be provided voluntarily by the user after reading the relevant instructions; or it may be actively authorized / provided / uploaded by the user when using some or all of the functions described in the above embodiments; or it may be obtained through other means or channels with the user's consent.

[0108] Figure 4 A schematic diagram of an exemplary system architecture that can apply the technical solutions of one or more embodiments of the present invention is shown. Figure 4 As shown, the system architecture 100 may include terminal device 110, network 120, and server 130. Terminal device 110 may include various electronic devices such as smartphones, tablets, laptops, and desktop computers. Server 130 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Network 120 may be a communication medium of various connection types capable of providing a communication link between terminal device 110 and server 130, such as a wired communication link or a wireless communication link.

[0109] Depending on the implementation requirements, the system architecture in this embodiment of the invention can have any number of terminal devices, networks, and servers. For example, server 130 can be a server group composed of multiple server devices. Furthermore, the technical solutions provided in this embodiment of the invention can be applied to terminal device 110, or to server 130, or can be implemented jointly by terminal device 110 and server 130; this invention does not impose any special limitations on these applications.

[0110] In one embodiment of the present invention, the terminal device 110 or server 130 can identify the current diagnostic status of the target vehicle based on the diagnostic status of the first core or R core and the diagnostic status of the second core or A core; receive a diagnostic request initiated to the target vehicle, and based on the current diagnostic status of the target vehicle, perform diagnostic arbitration through the first core or R core and the second core or A core to obtain the corresponding diagnostic arbitration result; and perform diagnosis on the target vehicle according to the diagnostic arbitration result. Here, the first core and the second core are two heterogeneous core processors located in the same system-on-a-chip, and the target vehicle includes vehicles determined in advance or in real time. By using the terminal device 110 or server 130 to execute the vehicle diagnostic method, the system can satisfy the access response of six diagnostic methods according to different usage scenarios, and enable the entire vehicle to access the appropriate diagnostic method according to the three-level definition of usage scenario priority. Moreover, this system, through diagnostic arbitration, provides a correct response when each diagnostic method is accessed, ensuring that the vehicle diagnosis does not conflict. This not only improves the efficiency of the vehicle diagnosis but also enhances the customer experience during vehicle diagnosis, prioritizing the access of diagnostic methods that are more relevant to on-site diagnosis and customer needs. The above sections describe exemplary system architectures that utilize the technical solutions of this invention.

[0111] This invention also provides a vehicle diagnostic device, which may include: one or more processors; and one or more machine-readable media storing instructions thereon, which, when executed by the one or more processors, cause the device to perform... Figure 1 or Figure 2 The vehicle diagnostic method described above. Figure 5 A schematic diagram of a vehicle diagnostic device 1000 is shown. (See attached diagram.) Figure 5 As shown, the vehicle diagnostic device 1000 includes: a processor 1010, a memory 1020, a power supply 1030, a display unit 1040, and an input unit 1060.

[0112] The processor 1010 is the control center of the vehicle diagnostic equipment 1000. It connects various components via interfaces and lines, and executes various functions of the vehicle diagnostic equipment 1000 by running or executing software programs and / or data stored in the memory 1020, thereby providing overall monitoring of the vehicle diagnostic equipment 1000. In this embodiment of the invention, when the processor 1010 calls the computer program stored in the memory 1020, it executes, for example... Figure 1 or Figure 2The vehicle diagnostic method described above. Optionally, the processor 1010 may include one or more processing units; preferably, the processor 1010 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. In some embodiments, the processor and memory can be implemented on a single chip; in some embodiments, they can also be implemented separately on independent chips.

[0113] The memory 1020 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, various applications, etc.; the data storage area may store data created based on the use of the vehicle diagnostic equipment 1000, etc. In addition, the memory 1020 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0114] The vehicle diagnostic equipment 1000 also includes a power supply 1030 (such as a battery) that supplies power to various components. The power supply can be logically connected to the processor 1010 through a power management system, thereby enabling the management of charging, discharging, and power consumption.

[0115] The display unit 1040 can be used to display information input by the user or information provided to the user, as well as various menus of the vehicle diagnostic device 1000. In this embodiment of the invention, it is mainly used to display the display interfaces of various applications in the vehicle diagnostic device 1000, as well as text, images, and other objects displayed on the display interfaces. The display unit 1040 may include a display panel 1050. The display panel 1050 may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like.

[0116] The input unit 1060 can be used to receive information such as numbers or characters input by the user. The input unit 1060 may include a touch panel 1070 and other input devices 1080. The touch panel 1070, also known as a touch screen, can collect touch operations on or near the touch panel 1070 by the user (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel 1070).

[0117] Specifically, the touch panel 1070 can detect user touch operations and the signals generated by these operations, convert them into touch point coordinates, send them to the processor 1010, and receive and execute commands from the processor 1010. Furthermore, the touch panel 1070 can be implemented using various types of touch technologies, including resistive, capacitive, infrared, and surface acoustic wave. Other input devices 1080 can include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0118] Of course, the touch panel 1070 can cover the display panel 1050. When the touch panel 1070 detects a touch operation on or near it, it transmits the information to the processor 1010 to determine the type of touch event. Subsequently, the processor 1010 provides corresponding visual output on the display panel 1050 based on the type of touch event. Although in Figure 5 In this embodiment, the touch panel 1070 and the display panel 1050 are two separate components to realize the input and output functions of the vehicle diagnostic device 1000. However, in some embodiments, the touch panel 1070 and the display panel 1050 can be integrated to realize the input and output functions of the vehicle diagnostic device 1000.

[0119] The vehicle diagnostic device 1000 may also include one or more sensors, such as pressure sensors, gravity acceleration sensors, proximity sensors, etc. Of course, depending on the specific application requirements, the vehicle diagnostic device 1000 may also include other components such as cameras.

[0120] This invention also provides a computer-readable storage medium storing instructions that, when executed by one or more processors, enable the device to perform the functions described in this invention. Figure 1 or Figure 2 The vehicle diagnostic method described above.

[0121] It will be understood by those skilled in the art that Figure 5 This is merely an example of a vehicle diagnostic device and does not constitute a limitation on the device. The device may include more or fewer components than illustrated, or a combination of certain components, or different components. For ease of description, the above parts are divided into modules (or units) according to their functions and described separately. Of course, in implementing this invention, the functions of each module (or unit) can be implemented in one or more software or hardware components.

[0122] Those skilled in the art will understand that the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The present invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention, and it should 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 applied to a processor of a general-purpose computer, special-purpose computer, embedded processor, 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, produce implementations of the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 The 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 operate 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 functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus 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.

[0123] It should be understood that although terms such as first, second, third, etc., may be used in the embodiments of the present invention to describe the preset range, these preset ranges should not be limited to these terms. These terms are only used to distinguish the preset ranges from one another. For example, without departing from the scope of the embodiments of the present invention, the first preset range may also be referred to as the second preset range, and similarly, the second preset range may also be referred to as the first preset range.

[0124] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A vehicle diagnostic method, characterized in that, The method includes the following steps: Based on the diagnostic status of the first core and the diagnostic status of the second core, the current diagnostic status of the target vehicle is identified; wherein, the first core and the second core are two heterogeneous core processors located in the same system-on-a-chip; the target vehicle includes vehicles determined in advance or in real time. The system receives a diagnostic request sent to the target vehicle and, based on the current diagnostic status of the target vehicle, performs diagnostic arbitration through the first core and the second core to obtain a corresponding diagnostic arbitration result. The diagnostic request generation process includes: generating a first diagnostic request received by the first core and a second diagnostic request received by the second core in the diagnostic source according to the diagnostic behavior and its corresponding priority. The diagnostic behavior corresponding to the first diagnostic request includes: OBD diagnostics based on the controller domain network protocol. The diagnostic behavior corresponding to the second diagnostic request includes: OTA flashing, OTA information collection mode, OBD diagnostics based on the Internet protocol, remote diagnostic standard mode, and remote diagnostic information collection mode. The target vehicle is diagnosed based on the diagnostic arbitration results; The process of obtaining a corresponding diagnostic arbitration result by performing diagnostic arbitration through the first core and the second core based on the current diagnostic status of the target vehicle includes: The first core is designated as the master node for diagnosis and arbitration, and the second core is designated as the slave node for diagnosis and arbitration. If the target vehicle's current diagnostic status is idle, then when the first core receives the first diagnostic request, it directly agrees to access the first diagnostic request, and sets the diagnostic status of the first core to the first priority according to the diagnostic behavior corresponding to the first diagnostic request, and synchronizes the diagnostic status of the second core; or, if the target vehicle's current diagnostic status is idle, then when the second core receives the second diagnostic request, it identifies the address of the diagnostic source through the second core, and queries the first core for access to the second diagnostic request according to the inter-core communication method between the second core and the first core; and when the first core replies with a positive response to the second core, agreeing to access the second diagnostic request, it identifies the message frame of the second diagnostic request through the first core, and sets the diagnostic status of the first core to the corresponding priority according to the diagnostic behavior corresponding to the second diagnostic request, and synchronizes the diagnostic status of the second core.

2. The vehicle diagnostic method according to claim 1, characterized in that, Before receiving the diagnostic request, the method further includes: determining a diagnostic behavior adapted to the target vehicle based on a pre-configured diagnostic method of the target vehicle; prioritizing the diagnostic behaviors and determining the priority of each diagnostic behavior; and generating the diagnostic request in the diagnostic source according to the diagnostic behavior and its corresponding priority. And / or, the diagnostic methods pre-configured for the target vehicle include at least one of the following: OBD diagnostic method, OTA diagnostic method, and remote diagnostic method; The diagnostic behavior includes at least one of the following: OBD diagnosis based on Internet Protocol, OBD diagnosis based on Controller Area Network Protocol, OTA flashing, OTA information collection mode, remote diagnostic standard mode, and remote diagnostic information collection mode. The priority of the diagnostic behavior includes: OBD diagnosis based on Internet Protocol, OBD diagnosis based on Controller Area Network Protocol, OTA flashing and remote diagnostic standard mode are the first priority, remote diagnostic information collection mode is the second priority, and OTA information collection mode is the third priority; wherein, the first priority is higher than the second priority, and the second priority is higher than the third priority.

3. A vehicle diagnostic method, characterized in that, The method includes the following steps: Based on the diagnostic status of the first core and the diagnostic status of the second core, the current diagnostic status of the target vehicle is identified; wherein, the first core and the second core are two heterogeneous core processors located in the same system-on-a-chip; the target vehicle includes vehicles determined in advance or in real time. The system receives diagnostic requests initiated to a target vehicle and, based on the current diagnostic status of the target vehicle, performs diagnostic arbitration through the first core and the second core. The generation process of the diagnostic request includes: generating a first diagnostic request received by the first core and a second diagnostic request received by the second core in the diagnostic source according to the diagnostic behavior and its corresponding priority. The diagnostic behavior corresponding to the first diagnostic request includes: OBD diagnostics based on the Controller Area Network Protocol (CAN). The diagnostic behavior corresponding to the second diagnostic request includes: OTA flashing, OTA information collection mode, OBD diagnostics based on the Internet Protocol (IP), remote diagnostic standard mode, and remote diagnostic information collection mode. The target vehicle is diagnosed based on the diagnostic arbitration results; The process of obtaining a corresponding diagnostic arbitration result by performing diagnostic arbitration through the first core and the second core based on the current diagnostic status of the target vehicle includes: The first core is designated as the master node for diagnosis and arbitration, and the second core is designated as the slave node for diagnosis and arbitration. If the current diagnostic status of the target vehicle is first priority, then before exiting the current diagnostic, when the first core receives the first diagnostic request, it directly refuses to access the first diagnostic request; and when the first core receives an inquiry from the second core asking whether to access the second diagnostic request, it replies with a negative response to the second core through the first core, refusing to access the second diagnostic request.

4. The vehicle diagnostic method according to claim 3, characterized in that, Before receiving the diagnostic request, the method further includes: determining a diagnostic behavior adapted to the target vehicle based on a pre-configured diagnostic method of the target vehicle; prioritizing the diagnostic behaviors and determining the priority of each diagnostic behavior; and generating the diagnostic request in the diagnostic source according to the diagnostic behavior and its corresponding priority. And / or, the diagnostic methods pre-configured for the target vehicle include at least one of the following: OBD diagnostic method, OTA diagnostic method, and remote diagnostic method; The diagnostic behavior includes at least one of the following: OBD diagnosis based on Internet Protocol, OBD diagnosis based on Controller Area Network Protocol, OTA flashing, OTA information collection mode, remote diagnostic standard mode, and remote diagnostic information collection mode. The priority of the diagnostic behavior includes: OBD diagnosis based on Internet Protocol, OBD diagnosis based on Controller Area Network Protocol, OTA flashing and remote diagnostic standard mode are the first priority, remote diagnostic information collection mode is the second priority, and OTA information collection mode is the third priority; wherein, the first priority is higher than the second priority, and the second priority is higher than the third priority.

5. A vehicle diagnostic method, characterized in that, The method includes the following steps: Based on the diagnostic status of the first core and the diagnostic status of the second core, the current diagnostic status of the target vehicle is identified; wherein, the first core and the second core are two heterogeneous core processors located in the same system-on-a-chip; the target vehicle includes vehicles determined in advance or in real time. The system receives diagnostic requests initiated to a target vehicle and, based on the current diagnostic status of the target vehicle, performs diagnostic arbitration through the first core and the second core. The generation process of the diagnostic request includes: generating a first diagnostic request received by the first core and a second diagnostic request received by the second core in the diagnostic source according to the diagnostic behavior and its corresponding priority. The diagnostic behavior corresponding to the first diagnostic request includes: OBD diagnostics based on the Controller Area Network Protocol (CAN). The diagnostic behavior corresponding to the second diagnostic request includes: OTA flashing, OTA information collection mode, OBD diagnostics based on the Internet Protocol (IP), remote diagnostic standard mode, and remote diagnostic information collection mode. The target vehicle is diagnosed based on the diagnostic arbitration results; The process of obtaining a corresponding diagnostic arbitration result by performing diagnostic arbitration through the first core and the second core based on the current diagnostic status of the target vehicle includes: The first core is designated as the master node for diagnosis and arbitration, and the second core is designated as the slave node for diagnosis and arbitration. If the target vehicle's current diagnostic status is second priority, then when the first core receives the first diagnostic request, it directly agrees to access the first diagnostic request and sets the first core's diagnostic status to first priority according to the diagnostic behavior corresponding to the first diagnostic request, and synchronizes the diagnostic status of the second core; or, if the target vehicle's current diagnostic status is second priority, then when the second core receives the second diagnostic request, it queries the first core for access to the second diagnostic request according to the inter-core communication method between the second core and the first core; and the first core performs message frame identification on the second diagnostic request, and when the diagnostic behavior corresponding to the second diagnostic request is identified, it determines whether to access the second diagnostic request based on mutual... When performing OBD diagnostics using network protocols, OBD diagnostics based on controller domain network protocols, OTA flashing, or remote diagnostic standard modes, the first core replies with a positive response to the second core, agreeing to access the second diagnostic request, and sets the diagnostic status of the first core to the first priority, and synchronizes the diagnostic status of the second core; or, when it is identified that the diagnostic behavior corresponding to the second diagnostic request is OTA information collection mode, the first core replies with a negative response to the second core, rejecting access to the second diagnostic request; or, when it is identified that the diagnostic behavior corresponding to the second diagnostic request is remote diagnostic information collection mode, the first core does not respond to the second core and continues to maintain the current diagnostic status.

6. The vehicle diagnostic method according to claim 5, characterized in that, Before receiving the diagnostic request, the method further includes: determining a diagnostic behavior adapted to the target vehicle based on a pre-configured diagnostic method of the target vehicle; prioritizing the diagnostic behaviors and determining the priority of each diagnostic behavior; and generating the diagnostic request in the diagnostic source according to the diagnostic behavior and its corresponding priority. And / or, the diagnostic methods pre-configured for the target vehicle include at least one of the following: OBD diagnostic method, OTA diagnostic method, and remote diagnostic method; The diagnostic behavior includes at least one of the following: OBD diagnosis based on Internet Protocol, OBD diagnosis based on Controller Area Network Protocol, OTA flashing, OTA information collection mode, remote diagnostic standard mode, and remote diagnostic information collection mode. The priority of the diagnostic behavior includes: OBD diagnosis based on Internet Protocol, OBD diagnosis based on Controller Area Network Protocol, OTA flashing and remote diagnostic standard mode are the first priority, remote diagnostic information collection mode is the second priority, and OTA information collection mode is the third priority; wherein, the first priority is higher than the second priority, and the second priority is higher than the third priority.

7. A vehicle diagnostic method, characterized in that, The method includes the following steps: Based on the diagnostic status of the first core and the diagnostic status of the second core, the current diagnostic status of the target vehicle is identified; wherein, the first core and the second core are two heterogeneous core processors located in the same system-on-a-chip; the target vehicle includes vehicles determined in advance or in real time. The system receives diagnostic requests initiated to a target vehicle and, based on the current diagnostic status of the target vehicle, performs diagnostic arbitration through the first core and the second core. The generation process of the diagnostic request includes: generating a first diagnostic request received by the first core and a second diagnostic request received by the second core in the diagnostic source according to the diagnostic behavior and its corresponding priority. The diagnostic behavior corresponding to the first diagnostic request includes: OBD diagnostics based on the Controller Area Network Protocol (CAN). The diagnostic behavior corresponding to the second diagnostic request includes: OTA flashing, OTA information collection mode, OBD diagnostics based on the Internet Protocol (IP), remote diagnostic standard mode, and remote diagnostic information collection mode. The target vehicle is diagnosed based on the diagnostic arbitration results; The process of obtaining a corresponding diagnostic arbitration result by performing diagnostic arbitration through the first core and the second core based on the current diagnostic status of the target vehicle includes: The first core is designated as the master node for diagnosis and arbitration, and the second core is designated as the slave node for diagnosis and arbitration. If the target vehicle's current diagnostic status is third priority, then when the first core receives the first diagnostic request, it directly agrees to access the first diagnostic request, and sets the first core's diagnostic status to first priority according to the diagnostic behavior corresponding to the first diagnostic request, and synchronizes the diagnostic status of the second core; or, if the target vehicle's current diagnostic status is third priority, then when the second core receives the second diagnostic request, it queries the first core whether to access the second diagnostic request according to the inter-core communication method between the second core and the first core; and through the first core, it performs message frame identification on the second diagnostic request, and when it identifies that the diagnostic behavior corresponding to the second diagnostic request is OBD diagnosis based on Internet Protocol, OBD diagnosis based on Controller Area Network Protocol, OTA flashing, remote diagnostic standard mode, or OTA information collection mode, it replies with a positive response to the second core through the first core, agreeing to access the second diagnostic request, and sets the first core's diagnostic status to the corresponding priority, and synchronizes the diagnostic status of the second core; or, when it identifies that the diagnostic behavior corresponding to the second diagnostic request is OTA information collection mode, the first core does not respond to the second core and continues to maintain the current diagnostic status.

8. The vehicle diagnostic method according to claim 7, characterized in that, Before receiving the diagnostic request, the method further includes: determining a diagnostic behavior adapted to the target vehicle based on a pre-configured diagnostic method of the target vehicle; prioritizing the diagnostic behaviors and determining the priority of each diagnostic behavior; and generating the diagnostic request in the diagnostic source according to the diagnostic behavior and its corresponding priority. And / or, the diagnostic methods pre-configured for the target vehicle include at least one of the following: OBD diagnostic method, OTA diagnostic method, and remote diagnostic method; The diagnostic behavior includes at least one of the following: OBD diagnosis based on Internet Protocol, OBD diagnosis based on Controller Area Network Protocol, OTA flashing, OTA information collection mode, remote diagnostic standard mode, and remote diagnostic information collection mode. The priority of the diagnostic behavior includes: OBD diagnosis based on Internet Protocol, OBD diagnosis based on Controller Area Network Protocol, OTA flashing and remote diagnostic standard mode are the first priority, remote diagnostic information collection mode is the second priority, and OTA information collection mode is the third priority; wherein, the first priority is higher than the second priority, and the second priority is higher than the third priority.

9. A vehicle diagnostic system applied to the vehicle diagnostic method as described in any one of claims 1 to 8, characterized in that, The system includes: The diagnostic status module is used to identify the current diagnostic status of the target vehicle based on the diagnostic status of the first core and the diagnostic status of the second core; wherein the first core and the second core are two heterogeneous core processors located in the same system-on-a-chip; the target vehicle includes vehicles determined in advance or in real time. The diagnostic arbitration module is used to receive diagnostic requests initiated to the target vehicle, and based on the current diagnostic status of the target vehicle, to perform diagnostic arbitration through the first core and the second core to obtain the corresponding diagnostic arbitration result. The vehicle diagnostic module is used to diagnose the target vehicle based on the diagnostic arbitration result.

10. A vehicle diagnostic device, characterized in that, include: processor; and, A computer-readable medium storing instructions that, when executed by the processor, cause the device to perform the vehicle diagnostic method as described in any one of claims 1 to 8.

Images