CN117475530A

CN117475530A - Vehicle diagnosis method, system and equipment

Info

Publication number: CN117475530A
Application number: CN202311296572.4A
Authority: CN
Inventors: 庾昂; 李丽彬; 廖宏; 李成飞; 魏辉
Original assignee: United Automotive Electronic Systems Co Ltd
Current assignee: United Automotive Electronic Systems Co Ltd
Priority date: 2023-10-08
Filing date: 2023-10-08
Publication date: 2024-01-30

Abstract

The invention provides a vehicle diagnosis method, a system and equipment, comprising the following steps: identifying a current diagnostic state of the target vehicle based on the diagnostic state of the first core and the diagnostic state of the second core; receiving a diagnosis request initiated to a target vehicle, and performing diagnosis arbitration through a first core and a 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 located in the same system-on-chip, and the target vehicle comprises a vehicle determined in advance or in real time. According to the invention, each diagnosis mode is accessed in a diagnosis arbitration mode, so that the whole vehicle diagnosis is not in conflict, the efficiency of the whole vehicle diagnosis is improved, the customer experience of the whole vehicle diagnosis is improved, and the priority access of the diagnosis modes with stronger site diagnosis and customer relevance is ensured.

Description

Vehicle diagnosis method, system and equipment

Technical Field

The present invention relates to the field of vehicle-mounted communication technologies, and in particular, to a vehicle diagnosis method, system and device.

Background

Vehicle diagnostics (including refresh) has been one of the indispensable functions in modern on-board network communication applications. In recent years, with the continuous upgrade of the vehicle-mounted electronic and electric architecture, the diagnostic/refreshing modes and diagnostic sources are also continuously diversified, such as Over-the-Air Technology (OTA), remote diagnosis, and the like, which are very popular in recent years. At the same time, the access node (edge node) central gateway controller for in-vehicle diagnosis is also increasingly complicated and centralized in function. From traditional single MCU (Microcontroller Unit, microcontroller, MCU for short) to MPU (Microprocessor Unit, microprocessor, MPU) +MCU for short, upgrade to cross-domain heterogeneous multi-core controller, so the main control node of the central gateway controller in different diagnostic modes may be different main bodies. The series of changes all put forward higher demands on diagnosis access, a new set of multi-diagnosis source management mechanism, namely a diagnosis arbitration mechanism, needs to be deployed based on the whole vehicle diagnosis demands to judge which diagnosis source can be accessed for diagnosis at a certain moment of the vehicle, so that the problem that the diagnosis function and even other normal operation functions cannot be normally performed due to conflict is avoided, and negative influence is caused on user experience.

Disclosure of Invention

In view of the above-mentioned drawbacks of the prior art, an object of the present invention is to provide a vehicle diagnosis method, system and apparatus for solving the technical problems in the prior art.

To achieve the above and other related objects, the present invention provides a vehicle diagnostic method comprising the steps of:

identifying a current diagnostic state of the target vehicle based on the diagnostic state of the first core and the diagnostic state of the second core; the first core and the second core are two heterogeneous core processors positioned in the same system-in-chip; the target vehicle comprises a vehicle determined in advance or in real time;

receiving a diagnosis request initiated to a 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.

In one embodiment of the present invention, the process of generating the diagnostic request in the diagnostic source according to the diagnostic actions and the corresponding priorities includes: generating a first diagnosis request received by a first core and a second diagnosis request received by a second core in a diagnosis source according to the diagnosis behaviors and the corresponding priorities;

Wherein, the diagnosis actions corresponding to the first diagnosis request include: OBD (On-Board Diagnostics, on-board self-diagnosis system, OBD for short) diagnosis based On controller area network protocol;

the diagnostic actions corresponding to the second diagnostic request include: OTA swipe, OTA information gathering mode, internet protocol based OBD diagnostics, remote diagnostic standard mode, and remote diagnostic information gathering mode.

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

the first core is used as a diagnosis arbitration master node, and the second core is used as a diagnosis arbitration slave node;

if the current diagnosis state of the target vehicle is idle, directly agreeing to access the first diagnosis request when the first core receives the first diagnosis request, setting the diagnosis state of the first core as a first priority according to the diagnosis behavior corresponding to the first diagnosis request, and synchronously setting the diagnosis state of the second core;

or if the current diagnosis state of the target vehicle is idle, identifying an address of a diagnosis source through the second core when the second core receives a second diagnosis request, and inquiring whether the second diagnosis request is accessed to the first core according to an inter-core communication mode of the second core and the first core; and when the first core replies positive response to the second core and agrees to access the second diagnosis request, carrying out message frame identification on the second diagnosis request through the first core, setting the diagnosis state of the first core as a corresponding priority according to the diagnosis behavior corresponding to the second diagnosis request, and synchronously setting the diagnosis state of the second core.

if the current diagnosis state of the target vehicle is a first priority, before exiting the current diagnosis, directly refusing to access the first diagnosis request when the first core receives the first diagnosis request; and when the first core receives the inquiry sent by the second core whether to access the second diagnosis access request, replying a negative response to the second core through the first core, and refusing to access the second diagnosis request.

if the current diagnosis state of the target vehicle is the second priority, directly agreeing to access the first diagnosis request when the first core receives the first diagnosis request, setting the diagnosis state of the first core as the first priority according to the diagnosis behavior corresponding to the first diagnosis request, and synchronously setting the diagnosis state of the second core;

Or if the current diagnosis state of the target vehicle is the second priority, inquiring whether the second diagnosis request is accessed to the first core according to the inter-core communication mode of the second core and the first core when the second core receives the second diagnosis request; the first core is used for checking the second diagnosis request to carry out message frame identification, and when the diagnosis behavior corresponding to the second diagnosis request is identified to be OBD diagnosis based on an Internet protocol, OBD diagnosis based on a controller area network protocol, OTA (over the air) flashing or remote diagnosis standard mode, the first core is used for replying a positive response to the second core, and when the second diagnosis request is agreed to be accessed, the diagnosis state of the first core is set to be a first priority, and the diagnosis state of the second core is synchronously set; or when the diagnosis behavior corresponding to the second diagnosis request is identified to be an OTA information collection mode, replying a negative response to the second core through the first core, and refusing to access the second diagnosis request; or when the diagnosis behavior corresponding to the second diagnosis request is identified to be a remote diagnosis information collection mode, the first core does not respond and reply to the second core, and the current diagnosis state is kept continuously.

if the current diagnosis state of the target vehicle is the third priority, directly agreeing to access the first diagnosis request when the first core receives the first diagnosis request, setting the diagnosis state of the first core as the first priority according to the diagnosis behavior corresponding to the first diagnosis request, and synchronously setting the diagnosis state of the second core;

or if the current diagnosis state of the target vehicle is the third priority, inquiring whether to access the second diagnosis request to the first core according to the inter-core communication mode of the second core and the first core when the second core receives the second diagnosis request; the first core replies a positive response to the second core when identifying that the diagnosis behavior corresponding to the second diagnosis request is OBD diagnosis based on an Internet protocol, OBD diagnosis based on a controller area network protocol, OTA refreshing, remote diagnosis standard mode or OTA information collection mode, and sets the diagnosis state of the first core as corresponding priority and synchronously sets the diagnosis state of the second core when agreeing to access the second diagnosis request; or when the diagnosis behavior corresponding to the second diagnosis request is identified to be an OTA information collection mode, the first core does not respond and reply to the second core, and the current diagnosis state is kept continuously.

In an embodiment of the invention, before receiving the diagnostic request, the method further comprises:

determining a diagnosis behavior adapted to the target vehicle based on a pre-configured diagnosis mode of the target vehicle;

prioritizing the diagnostic behaviors to determine the priority of each diagnostic behavior;

the diagnostic request is generated in a diagnostic source according to the diagnostic behavior and the corresponding priority.

In an embodiment of the present invention, the pre-configured diagnostic mode of the target vehicle includes at least one of the following: OBD diagnostic mode, OTA diagnostic mode, remote diagnostic mode;

the diagnostic behavior includes one of the following less: OBD diagnosis based on Internet protocol, OBD diagnosis based on controller area network protocol, OTA refreshing, OTA information collection mode, remote diagnosis standard mode, remote diagnosis information collection mode;

the priorities of the diagnostic actions include: OBD diagnosis based on an Internet protocol, OBD diagnosis based on a controller area network protocol, OTA (over the air) refreshing and remote diagnosis standard modes are the first priority, the remote diagnosis information collection mode is the second priority, and the 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.

The invention also provides a vehicle diagnosis system, which comprises:

a diagnostic status module for identifying a current diagnostic status of the target vehicle based on the diagnostic status of the first core and the diagnostic status of the second core; the first core and the second core are two heterogeneous core processors positioned in the same system-in-chip; the target vehicle comprises a vehicle determined in advance or in real time;

the diagnosis arbitration module is used for receiving a diagnosis request initiated to a 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 the vehicle diagnosis module is used for diagnosing the target vehicle according to the diagnosis arbitration result.

The present invention also provides a vehicle diagnostic apparatus including:

a processor; and, a step of, in the first embodiment,

a computer readable medium storing instructions that, when executed by the processor, cause the apparatus to perform a vehicle diagnostic method as described in any one of the above.

The present invention also provides a computer readable medium having instructions stored thereon, the instructions being loaded by a processor and executing a vehicle diagnostic method as described in any one of the above.

As described above, the invention provides a vehicle diagnosis method, system and device, which have the following beneficial effects: identifying a current diagnostic state of the target vehicle based on the diagnostic state of the first core and the diagnostic state of the second core; receiving a diagnosis request initiated to a target vehicle, and performing diagnosis arbitration through a first core and a 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 located in the same system-on-chip, and the target vehicle comprises a vehicle determined in advance or in real time. Therefore, the invention can correctly answer each diagnosis mode when accessing, so that the whole vehicle diagnosis does not conflict, not only the efficiency of the whole vehicle diagnosis is improved, but also the customer experience is improved when the whole vehicle diagnosis is performed, and the priority of the on-site diagnosis and the diagnosis mode with stronger customer relevance is ensured.

Drawings

FIG. 1 is a flow chart of a vehicle diagnostic method according to an embodiment of the present invention;

FIG. 2 is a flow chart of a vehicle diagnostic method according to another embodiment of the present invention;

FIG. 3 is a schematic hardware diagram of a vehicle diagnostic system according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of an exemplary system architecture to which the teachings of one or more embodiments of the present invention may be applied;

fig. 5 is a schematic hardware configuration of a vehicle diagnostic apparatus suitable for implementing one or more embodiments of the present invention.

Detailed Description

Other advantages and effects of the present invention will become apparent to those skilled in the art from the following disclosure, which describes the embodiments of the present invention with reference to specific examples. The invention may be practiced or carried out in other embodiments that depart from the specific details, and the details of the present description may be modified or varied from the spirit and scope of the present invention. It should be noted that the following embodiments and features in the embodiments may be combined with each other without conflict.

It should be noted that, the illustrations provided in the present embodiment merely illustrate the basic concept of the present invention by way of illustration, and only the components related to the present invention are shown in the drawings and are not drawn according to the number, shape and size of the components in actual implementation, and the form, number and proportion of the components in actual implementation may be arbitrarily changed, and the layout of the components may be more complex.

Fig. 1 shows a schematic flow chart of a vehicle diagnosis method according to an embodiment of the invention. Specifically, in an exemplary embodiment, as shown in fig. 1, the present embodiment provides a vehicle diagnosis method including the steps of:

s110, identifying the current diagnosis state of the target vehicle based on the diagnosis state of the first core and the diagnosis state of the second core; the first core and the second core are two heterogeneous core processors positioned in the same system-in-chip; the target vehicle comprises a vehicle that is determined in advance or in real time. As an example, the first core in the present embodiment may be an R core and the second core may be an a core.

S120, receiving a diagnosis request initiated to a target vehicle, and performing diagnosis arbitration through a first core and a second core based on the current diagnosis state of the target vehicle to obtain a corresponding diagnosis arbitration result;

and S130, diagnosing the target vehicle according to the diagnosis arbitration result.

Therefore, in this embodiment, by means of diagnosis and arbitration, a correct response is performed when each diagnosis mode is accessed, so that the whole vehicle diagnosis does not collide, the efficiency of the whole vehicle diagnosis is improved, the customer experience is improved when the whole vehicle diagnosis is performed, and the priority access of the diagnosis modes with stronger site diagnosis and customer relevance is ensured.

In an exemplary embodiment, before receiving the diagnosis request, the present embodiment may further include: determining a diagnosis behavior of the adaptive target vehicle based on a pre-configured diagnosis mode of the target vehicle; prioritizing the diagnostic behaviors to determine the priority of each diagnostic behavior; a diagnostic request is generated in the diagnostic source based on the diagnostic behavior and the corresponding priority. Among the diagnostic methods preconfigured for the target vehicle include, but are not limited to: OBD (On-Board Diagnostics, on-board self-diagnostic system, OBD for short), OTA (Over-the-Air Technology, OTA for short), remote diagnosis. Diagnostic actions include, but are not limited to: OBD diagnosis based on Internet protocol, OBD diagnosis based on controller area network protocol, OTA flashing, OTA information collection mode, remote diagnosis standard mode, remote diagnosis information collection mode. The priorities of the diagnostic actions include: OBD diagnosis based on an Internet protocol, OBD diagnosis based on a controller area network protocol, OTA (over the air) refreshing and remote diagnosis standard modes are the first priority, the remote diagnosis information collection mode is the second priority, and the 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, in this embodiment, based on three diagnostic modes, i.e., OBD diagnosis, OTA diagnosis, and remote diagnosis, the diagnostic behaviors are subdivided into 6 types according to the actual application scenario: OBD DoIP (Diagnostic Over Internet Protocol, diagnosis based on internet protocol, abbreviated as DoIP), OBD DoCAN (Diagnostic over Controller Area Network, diagnosis based on controller area network protocol, abbreviated as DoCAN), OTA flashing, OTA information collection mode, remote diagnosis standard mode, and remote diagnosis information collection mode. Then, the 6 diagnosis behaviors are divided into three levels from high to low according to the priority levels in actual use, and the high priority level can preempt and interrupt the diagnosis behaviors with low priority level at any time. In this implementation, the specific three classes are: a first priority, a second priority, and a third priority; wherein the first priority is higher than the second priority, and the second priority is higher than the third priority. Diagnostic actions of first priority: OBD DoIP, OBD DoCAN, OTA swipe, remote diagnostic standard mode; wherein, the diagnostic actions of the first priority are obtained first and not preempted. Diagnostic actions of the second priority: remote diagnostic information collection mode. Diagnostic actions of the third priority: OTA information collection mode. Therefore, the embodiment considers that 6 different diagnosis modes from different diagnosis sources are accessed to the diagnosis scene of the whole vehicle, can meet the access response of the 6 diagnosis modes according to different use scenes, and enables the whole vehicle to be accessed to the proper diagnosis mode according to the three-level definition of the priority of the use scene. And the correct response is carried out when each diagnosis mode is accessed in a three-level diagnosis arbitration mode, so that the whole vehicle diagnosis is free from conflict, and the efficiency of the whole vehicle diagnosis is improved.

In accordance with the foregoing, in an exemplary embodiment, a process for generating a diagnostic request in a diagnostic source based on diagnostic behavior and corresponding priority includes: generating a first diagnosis request received by the first core and a second diagnosis request received by the second core in the diagnosis source according to the diagnosis behaviors and the corresponding priorities; the diagnosis behavior corresponding to the first diagnosis request comprises: OBD diagnostics based on controller area network protocol; the diagnostic actions corresponding to the second diagnostic request include: OTA swipe, OTA information gathering mode, internet protocol based OBD diagnostics, remote diagnostic standard mode, and remote diagnostic information gathering mode. As an example, the first core in the present embodiment may be an R core and the second core may be an a core.

In an exemplary embodiment, a process of receiving a diagnostic request initiated to a target vehicle and performing diagnostic arbitration by a first core and a second core based on a current diagnostic state of the target vehicle includes: the first core is used as a diagnosis arbitration master node, and the second core is used as a diagnosis arbitration slave node; if the current diagnosis state of the target vehicle is idle, directly agreeing to access the first diagnosis request when the first core receives the first diagnosis request, setting the diagnosis state of the first core to be a first priority according to the diagnosis behavior corresponding to the first diagnosis request, and synchronously setting the diagnosis state of the second core. Or the first core is used as a diagnosis arbitration master node, and the second core is used as a diagnosis arbitration slave node; if the current diagnosis state of the target vehicle is idle, when the second core receives a second diagnosis request, identifying the address of a diagnosis source through the second core, and inquiring whether the second diagnosis request is accessed to the first core according to the inter-core communication mode of the second core and the first core; and when the first core replies positive response to the second core and agrees to access the second diagnosis request, carrying out message frame identification on the second diagnosis request through the first core, setting the diagnosis state of the first core to be a corresponding priority according to the diagnosis behavior corresponding to the second diagnosis request, and synchronously setting the diagnosis state of the second core. In the present embodiment, when the current diagnostic state of the target vehicle is the first priority, the diagnostic state of the first core is the first priority, and the diagnostic state of the second core is the first priority; when the current diagnostic state of the target vehicle is the second priority, the diagnostic state of the first core is the second priority, and the diagnostic state of the second core is the second priority; when the current diagnostic state of the target vehicle is the third priority, the diagnostic state of the first core is the third priority, and the diagnostic state of the second core is the third priority. As an example, the first core in the present embodiment may be an R core and the second core may be an a core.

In an exemplary embodiment, a process of receiving a diagnostic request initiated to a target vehicle and performing diagnostic arbitration by a first core and a second core based on a current diagnostic state of the target vehicle includes: the first core is used as a diagnosis arbitration master node, and the second core is used as a diagnosis arbitration slave node; if the current diagnosis state of the target vehicle is the first priority, before exiting the current diagnosis, directly rejecting the first diagnosis request when the first core receives the first diagnosis request; and when the first core receives the inquiry sent by the second core whether to access the second diagnosis access request, replying a negative response to the second core through the first core, and rejecting to access the second diagnosis request. In the present embodiment, when the current diagnostic state of the target vehicle is the first priority, the diagnostic state of the first core is the first priority, and the diagnostic state of the second core is the first priority; when the current diagnostic state of the target vehicle is the second priority, the diagnostic state of the first core is the second priority, and the diagnostic state of the second core is the second priority; when the current diagnostic state of the target vehicle is the third priority, the diagnostic state of the first core is the third priority, and the diagnostic state of the second core is the third priority. As an example, the first core in the present embodiment may be an R core and the second core may be an a core.

In an exemplary embodiment, a process of receiving a diagnostic request initiated to a target vehicle and performing diagnostic arbitration by a first core and a second core based on a current diagnostic state of the target vehicle includes: the first core is used as a diagnosis arbitration master node, and the second core is used as a diagnosis arbitration slave node; if the current diagnosis state of the target vehicle is the second priority, directly agreeing to access the first diagnosis request when the first core receives the first diagnosis request, setting the diagnosis state of the first core as the first priority according to the diagnosis behavior corresponding to the first diagnosis request, and synchronously setting the diagnosis state of the second core. Or the first core is used as a diagnosis arbitration master node, and the second core is used as a diagnosis arbitration slave node; if the current diagnosis state of the target vehicle is the second priority, inquiring whether the second diagnosis request is accessed to the first core according to the inter-core communication mode of the second core and the first core when the second core receives the second diagnosis request; the method comprises the steps that a first core replies positive response to a second core when a first diagnosis request is checked, a second diagnosis request is checked through the first core, a diagnosis state of the first core is set to be a first priority, and a diagnosis state of the second core is synchronously set when the diagnosis behavior corresponding to the second diagnosis request is identified to be OBD diagnosis based on an Internet protocol, OBD diagnosis based on a controller area network protocol, OTA (over the air) flashing or a remote diagnosis standard mode; or when the diagnosis behavior corresponding to the second diagnosis request is identified to be in the OTA information collection mode, replying a negative response to the second core through the first core, and refusing to access the second diagnosis request; or when the diagnosis behavior corresponding to the second diagnosis request is identified to be the remote diagnosis information collection mode, the first core does not respond and reply to the second core, and the current diagnosis state is kept. In the present embodiment, when the current diagnostic state of the target vehicle is the first priority, the diagnostic state of the first core is the first priority, and the diagnostic state of the second core is the first priority; when the current diagnostic state of the target vehicle is the second priority, the diagnostic state of the first core is the second priority, and the diagnostic state of the second core is the second priority; when the current diagnostic state of the target vehicle is the third priority, the diagnostic state of the first core is the third priority, and the diagnostic state of the second core is the third priority. As an example, the first core in the present embodiment may be an R core and the second core may be an a core.

In an exemplary embodiment, a process of receiving a diagnostic request initiated to a target vehicle and performing diagnostic arbitration by a first core and a second core based on a current diagnostic state of the target vehicle includes: the first core is used as a diagnosis arbitration master node, and the second core is used as a diagnosis arbitration slave node; if the current diagnosis state of the target vehicle is the third priority, when the first core receives the first diagnosis request, the first core directly agrees to access the first diagnosis request, the diagnosis state of the first core is set to be the first priority according to the diagnosis behavior corresponding to the first diagnosis request, and the diagnosis state of the second core is synchronously set. Or the first core is used as a diagnosis arbitration master node, and the second core is used as a diagnosis arbitration slave node; if the current diagnosis state of the target vehicle is the third priority, inquiring whether the second diagnosis request is accessed to the first core according to the inter-core communication mode of the second core and the first core when the second core receives the second diagnosis request; the method comprises the steps that a first core is used for checking a second diagnosis request, carrying out message frame identification, and when the diagnosis behavior corresponding to the second diagnosis request is identified to be OBD diagnosis based on an Internet protocol, OBD diagnosis based on a controller area network protocol, OTA (over the air) flashing, a remote diagnosis standard mode or an OTA information collection mode, responding to a second core through the first core, and setting the diagnosis state of the first core to be corresponding priority and synchronously setting the diagnosis state of the second core when the first core agrees to access the second diagnosis request; or when the diagnosis behavior corresponding to the second diagnosis request is identified to be the OTA information collection mode, the first core does not respond and reply to the second core, and the current diagnosis state is kept. In the present embodiment, when the current diagnostic state of the target vehicle is the first priority, the diagnostic state of the first core is the first priority, and the diagnostic state of the second core is the first priority; when the current diagnostic state of the target vehicle is the second priority, the diagnostic state of the first core is the second priority, and the diagnostic state of the second core is the second priority; when the current diagnostic state of the target vehicle is the third priority, the diagnostic state of the first core is the third priority, and the diagnostic state of the second core is the third priority. As an example, the first core in the present embodiment may be an R core and the second core may be an a core.

In another exemplary embodiment of the invention, FIG. 2 shows a flow chart diagram of a vehicle diagnostic method. As shown in fig. 2, this embodiment also provides a vehicle diagnosis method including the steps of:

based on three diagnostic modes of OBD diagnosis, OTA diagnosis and remote diagnosis, the diagnosis behaviors are subdivided into 6 types according to actual application scenes: OBD DoIP, OBD DoCAN, OTA swipe, OTA information collection mode, remote diagnostic standard mode, and remote diagnostic information collection mode. Then, the 6 diagnosis behaviors are divided into three levels from high to low according to the priority levels in actual use, and the high priority level can preempt and interrupt the diagnosis behaviors with low priority level at any time. In this implementation, the specific three classes are: a first priority, a second priority, and a third priority; wherein the first priority is higher than the second priority, and the second priority is higher than the third priority. Diagnostic actions of first priority: OBD DoIP, OBD DoCAN, OTA swipe, remote diagnostic standard mode; wherein, the diagnostic actions of the first priority are obtained first and not preempted. Diagnostic actions of the second priority: remote diagnostic information collection mode. Diagnostic actions of the third priority: OTA information collection mode. In this embodiment, the diagnostic status of the first priority may be set to lvl.1, the diagnostic status of the second priority may be set to lvl.2, and the diagnostic status of the third priority may be set to lvl.3.

The R core is used as a diagnosis arbitration master node, and the A core is used as a diagnosis arbitration slave node. The main control unit of the OBD DoCAN is an R core of a multi-core SoC (System on Chip, abbreviated as SoC) Chip, and the main control units of the other diagnostic modes generally select an a core of the SoC Chip.

According to the whole vehicle diagnosis design, the A core is used as a DoIP edge node, OBD DoIP diagnosis, OTA access requests (comprising two modes of Flash and Info) and remote diagnosis access requests (comprising two modes of Standard and Info) are sent from a diagnosis source to the A core, and the R core is used as a gateway node, and OBD DoCAN diagnosis requests are sent to an R core routing module. The OTA Flash may be referred to as OTA Flash, the OTA information collection mode may be referred to as OTA Info, the remote diagnosis Standard mode may be referred to as remote diagnosis Standard, and the remote diagnosis information collection mode may be referred to as remote diagnosis Info. At this time:

1. when the diagnostic status of the vehicle is idle (lvl.0), then there are:

if the R core receives the diagnosis access request, directly agreeing to access, setting the diagnosis state to be 1, and synchronizing to the A core, so that the diagnosis state of the A core is identical with that of the R core.

If the A core receives any diagnosis request, the arbitrating slave node classifies the diagnosis modes (OBD, OTA or remote diagnosis) in advance by identifying the address of the diagnosis source, and then inquires the master node of the R core whether the diagnosis modes can be accessed or not by the mode of inter-core communication request. Because the diagnosis state is idle at this time, the R core main node replies that the A core agrees to the diagnosis mode to be accessed, and meanwhile, the main node judges that the diagnosis mode is specifically OTA Flash, OTA Info, remote diagnosis Standard and remote diagnosis Info through the identification of the message frame, sets the current diagnosis state as corresponding level (LVl.1, LVl.2 or LVl.3) according to the division of the three priorities, and synchronizes the diagnosis state with the A core.

2. When the diagnosis state of the vehicle is LVl.1, the R core main node is accessed to the OBD DoCAN before the current diagnosis actively exits, the main node directly refuses the diagnosis access request sent by the A core side, and the R core main node replies a negative response and refuses to request access.

3. If the diagnostic status of the vehicle is set to lvl.2, i.e. remote diagnostic information collection mode or remote diagnostic Info, then there are:

if the R core side is accessed to the OBD DoCAN, the current diagnosis resource can be directly preempted, and the diagnosis state is updated to LVl.1 after the preemption and synchronized to the A core, so that the diagnosis state of the A core is the same as that of the R core.

If the access of the A core side can inquire the R core main node in a request mode, when the R core is judged to be an OBD, OTA Flash or remote diagnosis standard mode according to the identification of the requested message frame, the current remote diagnosis Info mode can be directly interrupted, positive response is replied to the A core, the diagnosis mode of the A core request is accessed, the diagnosis state is updated to LVl.1, and the A core is synchronized, so that the diagnosis state of the A core is identical with the diagnosis state of the R core; when the R core judges the mode to be the OTA Info mode according to the identification of the requested message frame, the current remote diagnosis Info mode and the current diagnosis state are maintained, a negative response is replied to the A core, and the OTA Info access is refused.

4. If the diagnostic status is set to lvl.3, i.e. OTA information collection mode or OTA Info, then there are:

if the OBD DoCAN on the R core side is accessed, the current diagnosis resource can be directly preempted, and the diagnosis state is updated to LVl.1 after the preemption and synchronized to the A core, so that the diagnosis state of the A core is the same as the diagnosis state of the R core.

If the access of the A core side can inquire the R core main node in a request mode, the main node directly interrupts the current OTA Info mode, replies positive response to the A core, accesses the diagnosis mode of the A core request, upgrades the diagnosis state into LVl.1 or LVl.2 according to the message frame of the A core request, and synchronizes to the A core, so that the diagnosis state of the A core is identical with the diagnosis state of the R core.

In fig. 2, acore represents an a Core; RCore represents an R Core; arbitration Slave denotes an arbitrating slave node; arbitration Master represents an arbitration master; the Request represents an inquiry initiated by the A core to the R core; response represents the Response that the R core feeds back to the A core; the diag.level Status represents the diagnostic Status, i.e. the diag.level Status in A Core represents the diagnostic Status of A Core, the diag.level Status in R Core represents the diagnostic Status of R Core; OBD DoIP represents OBD diagnostics based on internet protocol; the OTA Flash/Info represents an OTA refreshing/OTA information collecting mode, namely the OTA Flash represents the OTA refreshing and the OTA Info represents the OTA information collecting mode; remote diag. Standard/Info indicates Remote diagnostic Standard mode/Remote diagnostic information collecting mode, i.e. Remote diag. Standard indicates Remote diagnostic Standard mode, remote diag. Info indicates Remote diagnostic information collecting mode; OBD DoCAN represents OBD diagnostics based on controller area network protocols.

Therefore, according to the embodiment, through the arbitration logic design, the access response of 6 diagnosis modes according to different use scenes can be met, and the whole vehicle can be accessed into a proper diagnosis mode according to the three-level definition of the priority of the use scenes. In addition, in the embodiment, 6 different diagnosis modes from different diagnosis sources are considered to be accessed into the diagnosis scene of the whole vehicle, and correct response is carried out when each diagnosis mode is accessed in a two-stage arbitration mode, so that collision does not occur in the diagnosis of the whole vehicle, and the diagnosis efficiency of the whole vehicle is improved. In addition, the embodiment improves the customer experience during the whole vehicle diagnosis, and preferentially ensures the preferential access of the diagnosis modes with stronger site diagnosis and customer relevance, such as the diagnosis of an OBD diagnostic instrument, OTA refreshing, OTA diagnosis and the like which are commonly used after sales.

In any of the embodiments, the a core and the R core are designed based on the DRA821, and according to the SoC, there may be a case where the routing node is placed in the M core, and at this time, the R core main node may be placed in the M core, which is also applicable to the design logic of the vehicle diagnostic method. Further, in any of the above embodiments, the remote diagnosis is classified into two modes of Standard mode Standard and remote diagnosis Info mode. The remote diagnosis definition and name of different manufacturers may be different, so long as the remote diagnosis needs to be divided into two sub-priority scenes, the scheme of the vehicle diagnosis method can be applicable.

In summary, the present invention provides a vehicle diagnostic method, which identifies a current diagnostic state of a target vehicle based on a diagnostic state of a first core or R core and a diagnostic state of a second core or a core; receiving a diagnosis request initiated to a target vehicle, and performing diagnosis arbitration through a first core or an R core and a second core or an A 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 located in the same system-on-chip, and the target vehicle comprises a vehicle determined in advance or in real time. Therefore, the method can meet the requirement of 6 diagnosis modes according to the access response of different use scenes, and enables the whole vehicle to access to the proper diagnosis modes according to the three-level definition of the priority of the use scenes. In addition, the method carries out correct response when each diagnosis mode is accessed in a diagnosis arbitration mode, so that the whole vehicle diagnosis does not conflict, the efficiency of the whole vehicle diagnosis is improved, the customer experience is improved when the whole vehicle diagnosis is carried out, and the priority access of the diagnosis modes with stronger site diagnosis and customer relevance is ensured.

In another exemplary embodiment of the present invention, as shown in fig. 3, the embodiment provides a vehicle diagnostic system including:

a diagnostic status module 310, configured to identify a current diagnostic status of the target vehicle according to the diagnostic status of the R core and the diagnostic status of the a core; wherein, the R core and the A core are two heterogeneous core processors positioned in the same system-in-chip; the target vehicle comprises a vehicle that is determined in advance or in real time. As an example, the first core in the present embodiment may be an R core and the second core may be an a core.

The diagnosis arbitration module 320 is configured to receive a diagnosis request initiated to the target vehicle, and perform diagnosis arbitration through the R core and the a core based on the current diagnosis state of the target vehicle, so as to obtain a corresponding diagnosis arbitration result;

the vehicle diagnosis module 330 is configured to diagnose the target vehicle according to the diagnosis arbitration result.

In another exemplary embodiment of the present invention, the embodiment further provides a vehicle diagnostic system for performing the steps of:

1. when the diagnostic status of the vehicle is idle (lvl.0), then there are:

In any of the embodiments, the a core and the R core are designed based on the DRA821, and according to the SoC, there may be a case where the routing node is placed in the M core, and at this time, the R core main node may be placed in the M core, which is also applicable to the design logic of the vehicle diagnostic system. Further, in any of the above embodiments, the remote diagnosis is classified into two modes of Standard mode Standard and remote diagnosis Info mode. The remote diagnosis definition and name of different manufacturers may be different, so long as the remote diagnosis needs to be divided into two sub-priority scenes, the scheme of the vehicle diagnosis system can be applicable.

In summary, the present invention provides a vehicle diagnostic system that identifies a current diagnostic state of a target vehicle based on a diagnostic state of a first core or R core and a diagnostic state of a second core or a core; receiving a diagnosis request initiated to a target vehicle, and performing diagnosis arbitration through a first core or an R core and a second core or an A 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 located in the same system-on-chip, and the target vehicle comprises a vehicle determined in advance or in real time. Therefore, the system can meet the requirement of 6 diagnosis modes according to the access response of different use scenes, and enables the whole vehicle to access to the proper diagnosis modes according to the three-level definition of the priority of the use scenes. In addition, the system responds correctly when each diagnosis mode is accessed in a diagnosis arbitration mode, so that the whole vehicle diagnosis does not conflict, the efficiency of the whole vehicle diagnosis is improved, the customer experience is improved when the whole vehicle diagnosis is performed, and the priority access of the diagnosis modes with stronger site diagnosis and customer relevance is ensured.

It should be noted that, the vehicle diagnostic system provided in the above embodiment and the vehicle diagnostic method provided in the above embodiment belong to the same concept, and the specific manner in which each module performs the operation has been described in detail in the method embodiment, which is not repeated here. In practical application, the vehicle diagnostic system provided in the above embodiment may be configured to distribute the functions by different functional modules according to needs, that is, the internal structure of the system is divided into different functional modules to complete all or part of the functions described above, which is not limited herein. Therefore, the invention effectively overcomes various defects in the prior art and has high industrial utilization value.

The above embodiments are performed with or without user consent when processing related data (e.g., diagnostic information data, etc.), such as collecting, storing, using, processing, transmitting, providing, disclosing, deleting, etc. For example, the diagnostic information data is authorized in the case that the user knows and agrees; either the user is actively provided after reading the relevant description, or the user is actively authorized/provided/uploaded, or otherwise obtained through or informed of the user's consent, while using some or all of the functions described in the above embodiments.

Fig. 4 shows a schematic diagram of an exemplary system architecture to which the technical solution of one or more embodiments of the present invention may be applied. As shown in fig. 4, system architecture 100 may include a terminal device 110, a network 120, and a server 130. Terminal device 110 may include various electronic devices such as smart phones, tablet computers, notebook computers, desktop computers, and the like. The server 130 may be an independent physical server, a server cluster or a distributed system formed by a plurality of 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, and may be, for example, a wired communication link or a wireless communication link.

The system architecture in embodiments of the present invention may have any number of terminal devices, networks, and servers, as desired for implementation. For example, the server 130 may be a server group composed of a plurality of server devices. In addition, the technical solution provided in the embodiment of the present invention may be applied to the terminal device 110, or may be applied to the server 130, or may be implemented by the terminal device 110 and the server 130 together, which is not limited in particular.

In one embodiment of the present invention, the terminal device 110 or the server 130 of the present invention may 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; receiving a diagnosis request initiated to a target vehicle, and performing diagnosis arbitration through a first core or an R core and a second core or an A 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 located in the same system-on-chip, and the target vehicle comprises a vehicle determined in advance or in real time. The vehicle diagnosis method is executed by using the terminal device 110 or the server 130, so that 6 diagnosis modes can be satisfied according to the access response of different use scenes, and the whole vehicle can be accessed into a proper diagnosis mode according to the three-level definition of the priority of the use scenes. In addition, the system responds correctly when each diagnosis mode is accessed in a diagnosis arbitration mode, so that the whole vehicle diagnosis does not conflict, the efficiency of the whole vehicle diagnosis is improved, the customer experience is improved when the whole vehicle diagnosis is performed, and the priority access of the diagnosis modes with stronger site diagnosis and customer relevance is ensured. The foregoing presents a simplified summary of an exemplary system architecture employing the teachings of the present invention.

The embodiment of the invention also provides vehicle diagnosis equipment, which can comprise: one or more processors; and one or more machine readable media having instructions stored thereon, which when executed by the one or more processors, cause the apparatus to perform the vehicle diagnostic method described in fig. 1 or fig. 2. Fig. 5 shows a schematic structural diagram of a vehicle diagnostic apparatus 1000. Referring to fig. 5, a vehicle diagnostic apparatus 1000 includes: processor 1010, memory 1020, power supply 1030, display unit 1040, and input unit 1060.

The processor 1010 is a control center of the vehicle diagnostic apparatus 1000, connects the respective components using various interfaces and lines, and performs various functions of the vehicle diagnostic apparatus 1000 by running or executing software programs and/or data stored in the memory 1020, thereby performing overall monitoring of the vehicle diagnostic apparatus 1000. In an embodiment of the present invention, the processor 1010 executes the vehicle diagnostic method described in fig. 1 or fig. 2 when it invokes a computer program stored in the memory 1020. In the alternative, processor 1010 may include one or more processing units; preferably, the processor 1010 may integrate an application processor that primarily handles operating systems, user interfaces, applications, etc., with a modem processor that primarily handles wireless communications. In some embodiments, the processor, memory, may be implemented on a single chip, and in some embodiments, they may be implemented separately on separate chips.

The memory 1020 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, various applications, etc.; the storage data area may store data created according to the use of the vehicle diagnostic apparatus 1000, or the like. In addition, memory 1020 may include high-speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state memory device, among others.

The vehicle diagnostic device 1000 also includes a power supply 1030 (e.g., a battery) for powering the various components, which may be logically connected to the processor 1010 via a power management system so as to perform functions such as managing charge, discharge, and power consumption via the power management system.

The display unit 1040 may be used to display information input by a user or information provided to the user, various menus of the vehicle diagnostic apparatus 1000, and the like, and is mainly used to display a display interface of each application in the vehicle diagnostic apparatus 1000 and objects such as text and pictures displayed in the display interface in the embodiment of the present invention. 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 (Liquid Crystal Display, LCD), an Organic Light-Emitting Diode (OLED), or the like.

The input unit 1060 may be used to receive information such as numbers or characters input by a user. The input unit 1060 may include a touch panel 1070 and other input devices 1080. Wherein the touch panel 1070, also referred to as a touch screen, may collect touch operations thereon or thereabout by a user (e.g., operations of the user on the touch panel 1070 or thereabout by using any suitable object or accessory such as a finger, a stylus, etc.).

Specifically, the touch panel 1070 may detect a touch operation by a user, detect signals resulting from the touch operation, convert the signals into coordinates of contacts, send the coordinates to the processor 1010, and receive and execute commands sent from the processor 1010. In addition, the touch panel 1070 may be implemented in various types such as resistive, capacitive, infrared, and surface acoustic wave. Other input devices 1080 may include, but are not limited to, one or more of a physical keyboard, function keys (e.g., volume control keys, power on and off keys, etc.), a trackball, mouse, joystick, etc.

Of course, the touch panel 1070 may overlay the display panel 1050, and when a touch operation is detected on or near the touch panel 1070, the touch operation is transmitted to the processor 1010 to determine the type of touch event, and then the processor 1010 provides a corresponding visual output on the display panel 1050 according to the type of touch event. Although in fig. 5, the touch panel 1070 and the display panel 1050 implement the input and output functions of the vehicle diagnostic apparatus 1000 as two separate components, in some embodiments, the touch panel 1070 and the display panel 1050 may be integrated to implement the input and output functions of the vehicle diagnostic apparatus 1000.

The vehicle diagnostic device 1000 may also include one or more sensors, such as a pressure sensor, a gravitational acceleration sensor, a proximity light sensor, and the like. Of course, the vehicle diagnostic apparatus 1000 described above may also include other components such as cameras, as desired in a particular application.

Embodiments of the present invention also provide a computer-readable storage medium having instructions stored therein that, when executed by one or more processors, enable the above-described apparatus to perform a vehicle diagnostic method of the present invention as described in fig. 1 or fig. 2.

It will be appreciated by those skilled in the art that fig. 5 is merely an example of a vehicle diagnostic device and is not limiting of the device, and that the device may include more or fewer components than shown, or certain components may be combined, or different components. For convenience of description, the above parts are described as being functionally divided into modules (or units) respectively. Of course, in implementing the present invention, the functions of each module (or unit) may be implemented in the same piece or pieces of software or hardware.

It will be appreciated by those skilled in the art that the invention can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. 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, which are desirably implemented by computer program instructions, each flowchart and/or block diagram illustration, and combinations of flowchart illustrations and/or block diagrams. These computer program instructions may 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, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks. 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 such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The above embodiments are merely illustrative of the principles of the present invention and its effectiveness, and are not intended to limit the invention. Modifications and variations may be made to the above-described embodiments by those skilled in the art without departing from the spirit and scope of the invention. Accordingly, it is intended that all equivalent modifications and variations of the invention be covered by the claims, which are within the ordinary skill of the art, be within the spirit and scope of the present disclosure.

Claims

1. A vehicle diagnostic method, characterized in that the method comprises the steps of:

2. The vehicle diagnostic method of claim 1, wherein generating the diagnostic request in a diagnostic source based on the diagnostic behavior and the corresponding priority comprises: generating a first diagnosis request received by a first core and a second diagnosis request received by a second core in a diagnosis source according to the diagnosis behaviors and the corresponding priorities;

wherein, the diagnosis actions corresponding to the first diagnosis request include: OBD diagnostics based on controller area network protocol;

3. The vehicle diagnostic method of claim 2, wherein the process of receiving a diagnostic request initiated to a target vehicle and performing diagnostic arbitration by the first core and the second core based on a current diagnostic state of the target vehicle comprises:

4. The vehicle diagnostic method of claim 2, wherein the process of receiving a diagnostic request initiated to a target vehicle and performing diagnostic arbitration by the first core and the second core based on a current diagnostic state of the target vehicle comprises:

5. The vehicle diagnostic method of claim 2, wherein the process of receiving a diagnostic request initiated to a target vehicle and performing diagnostic arbitration by the first core and the second core based on a current diagnostic state of the target vehicle comprises:

6. The vehicle diagnostic method of claim 2, wherein the process of receiving a diagnostic request initiated to a target vehicle and performing diagnostic arbitration by the first core and the second core based on a current diagnostic state of the target vehicle comprises:

7. The vehicle diagnostic method according to any one of claims 1 to 6, characterized in that before receiving the diagnostic request, the method further comprises:

8. The vehicle diagnostic method of claim 7, wherein the pre-configured diagnostic mode of the target vehicle comprises at least one of: OBD diagnostic mode, OTA diagnostic mode, remote diagnostic mode;

9. A vehicle diagnostic system, the system comprising:

10. A vehicle diagnostic apparatus, characterized by comprising:

a processor; and, a step of, in the first embodiment,

a computer readable medium storing instructions that, when executed by the processor, cause the apparatus to perform the vehicle diagnostic method of any one of claims 1 to 8.