CN114043994A

CN114043994A - Vehicle fault processing method, device, equipment and storage medium

Info

Publication number: CN114043994A
Application number: CN202111363068.2A
Authority: CN
Inventors: 马红敏
Original assignee: Guoqi Intelligent Control Beijing Technology Co Ltd
Current assignee: Guoqi Intelligent Control Beijing Technology Co Ltd
Priority date: 2021-11-17
Filing date: 2021-11-17
Publication date: 2022-02-15
Anticipated expiration: 2041-11-17
Also published as: CN114043994B

Abstract

The invention provides a vehicle fault processing method, a device, equipment and a storage medium, which are applied to distributed nodes in an SOA heterogeneous platform and comprise a fault monitoring node, a fault reporting node, a fault information processing node and a fault storage node which sequentially transmit data, wherein specifically, the fault monitoring node acquires running data corresponding to a plurality of running nodes in a vehicle, and extracts vehicle fault information from the running data; analyzing the vehicle fault information through the fault report node to obtain fault reports corresponding to the multiple operating nodes; determining the fault grade of the vehicle according to the fault report through the fault information processing node; and storing the fault grade and the fault report of the vehicle to a nonvolatile storage area through the fault storage node based on the fault type information, wherein the nonvolatile storage area is used for the cloud equipment to access diagnosis communication based on the fault type information. Therefore, the invention can be applied to the fault processing of the high-performance domain, improves the flexibility and reduces the resource waste.

Description

Vehicle fault processing method, device, equipment and storage medium

Technical Field

The invention relates to the technical field of automatic driving, in particular to a vehicle fault processing method, device, equipment and storage medium.

Background

With the development of the automatic Driving technology, the functions of the automobile System become more complex and the safety level becomes higher, more and more automobiles are deployed with Advanced Driving Assistance Systems (ADAS), SoCiety of Automotive Engineers (SAE) have clear division definition for the automatic Driving level, for the intelligent Driving Control part, the L2 level (semi-automatic Driving) and the following distributed Control mode of multi-Electronic Control Unit (ECU) based on Micro Control Unit (MCU) are adopted, and above L3 (automatic Driving) a centralized Control strategy of automobile Domain Control Unit (Domain Control Unit, DCU) based on high performance System on a Chip (SoC) must be adopted, wherein the DCU integrates a plurality of high performance chips including Central Processing Unit (Central Processing Unit, CPU) and a Graphics Processing Unit (GPU).

In the prior art, when a fault diagnosis system in a real-time domain processes a vehicle fault, a multi-ECU distributed control mode based on an MCU is usually used to periodically check the vehicle fault by using a unique program.

However, if the real-time domain fault diagnosis system is used for processing the vehicle fault in the high-performance domain, resources are wasted, the effect is not ideal, and the flexibility is low.

Disclosure of Invention

The invention provides a vehicle fault processing method, a vehicle fault processing device, vehicle fault processing equipment and a storage medium, which are applied to distributed nodes in an SOA heterogeneous platform and used for solving the problems of immature fault processing method, resource waste, undesirable effect and low flexibility of a high-performance domain in the prior art.

In a first aspect, the present invention provides a vehicle fault processing method, which is applied to distributed nodes in an SOA heterogeneous platform, where the distributed nodes include a fault monitoring node, a fault reporting node, a fault information processing node, and a fault storage node, where the fault monitoring node, the fault reporting node, the fault information processing node, and the fault storage node sequentially transmit data, and the method includes:

acquiring running data corresponding to a plurality of running nodes in a vehicle through the fault monitoring node, and extracting vehicle fault information from the running data;

analyzing the vehicle fault information through the fault report node to obtain fault reports corresponding to a plurality of operating nodes; the fault report comprises fault degree information, fault type information and a diagnosis fault code; the fault type information comprises system-on-chip (SoC) end information and microcontroller MCU end information;

determining the fault level of the vehicle according to the fault degree information, the fault type information and the diagnosis fault code through the fault information processing node;

and storing the fault grade of the vehicle, the fault degree information and the diagnosis fault code to a nonvolatile storage area in a file system through the fault storage node based on the fault type information, wherein the nonvolatile storage area is used for accessing the cloud equipment for diagnosis communication based on the fault type information.

Optionally, the plurality of running nodes are nodes registered in advance; the method further comprises the following steps:

creating an instance for subscribing the plurality of nodes through the fault monitoring node, and initiating a subscription request to a plurality of running nodes in the vehicle by calling an interface corresponding to the instance; the subscription request is used for acquiring the operation data of the plurality of operation nodes;

correspondingly, the step of obtaining the operation data corresponding to the plurality of operation nodes in the vehicle through the fault monitoring node comprises the following steps:

and receiving the operation data sent by the plurality of operation nodes according to the subscription request through the fault monitoring node based on a synchronous mode or an asynchronous mode.

Optionally, analyzing the vehicle fault information to obtain fault reports corresponding to the multiple operating nodes, including:

extracting characteristic information in the vehicle fault information, and comparing the characteristic information with a parameter threshold value in a preset fault library to obtain a comparison result;

and obtaining fault reports corresponding to the multiple operating nodes according to the comparison result.

Optionally, determining a fault level of the vehicle according to the fault degree information, the fault type information and the diagnostic fault code, including:

determining a correlation influence degree based on the fault degree information and the diagnostic fault codes corresponding to each operating node; the correlation influence degree is the level of the degree influencing the normal operation of other operation nodes; and determining the fault level of the vehicle according to the correlation influence degree and the fault type information.

Optionally, the method further includes:

dividing a nonvolatile storage area in the file system into two storage areas, namely a first storage area and a second storage area, by the fault storage node based on the fault type information, wherein the first storage area is used for storing information from an SoC (System on chip) end, and the second storage area is used for storing information from an MCU (microprogrammed control Unit) end;

correspondingly, the step of storing the fault grade of the vehicle, the fault degree information and the diagnosis fault code to a nonvolatile storage area in a file system based on the fault type information comprises the following steps:

and respectively storing the fault grade of the vehicle, the fault degree information and the diagnosis fault code into corresponding storage areas according to the corresponding fault type information.

Optionally, the method further includes:

acquiring the state of an electronic ignition switch of a vehicle;

if the state of the electronic ignition switch is a starting state, reading unprocessed historical fault information in the nonvolatile storage area; the historical fault information comprises the fault grade, the fault degree information and the fault type information of the vehicle, which are stored when the last time the electronic ignition switch of the vehicle is in the off state;

and executing corresponding action according to the fault grade in the historical fault information.

Optionally, executing a corresponding action according to the fault level in the historical fault information, including:

judging whether the fault level in the historical fault information reaches a preset level or not;

if at least one of the fault levels reaches a preset level, an engine lock command is sent to an engine electronic controller unit of the vehicle.

Optionally, the method further includes:

calling an https encryption protocol to encrypt first-layer data of each item of data in the nonvolatile storage area;

setting a preset encryption key to encrypt the second layer data of each item of data to generate encrypted data and an encrypted data ID corresponding to the encrypted data;

and sending the encrypted data and the corresponding encrypted data ID to cloud end equipment, and enabling the cloud end equipment to decrypt the encrypted data based on the encrypted data ID and read the encrypted data.

Optionally, the fault levels include at least a first level and a second level; the method further comprises the following steps:

if the fault level of the vehicle is determined to be the first level, sending a first instruction to control the vehicle to park;

and if the fault level of the vehicle is determined to be the second level, sending a second instruction to control the vehicle to travel to a vehicle maintenance point according to a preset travel path or a re-planned travel path.

In a second aspect, the present invention provides a vehicle fault handling apparatus, the apparatus comprising:

the fault monitoring node is used for acquiring operation data corresponding to a plurality of operation nodes in the vehicle and extracting vehicle fault information from the operation data;

the fault report node is used for analyzing the vehicle fault information to obtain fault reports corresponding to the plurality of operating nodes; the fault report comprises fault degree information, fault type information and a diagnosis fault code; the fault type information comprises system-on-chip (SoC) end information and microcontroller MCU end information;

the fault information processing node is used for determining the fault level of the vehicle according to the fault degree information, the fault type information and the diagnosis fault code;

and the fault storage node is used for storing the fault grade of the vehicle, the fault degree information and the diagnosis fault code to a nonvolatile storage area in a file system based on the fault type information, and the nonvolatile storage area is used for accessing the cloud equipment for diagnosis communication based on the fault type information.

In a third aspect, the present invention provides a vehicle failure processing apparatus comprising: at least one processor and memory;

the memory stores computer-executable instructions;

the at least one processor executes computer-executable instructions stored by the memory to cause the at least one processor to perform the vehicle fault handling method of any of the first aspects.

In a fourth aspect, the present invention provides a computer-readable storage medium having stored therein computer-executable instructions that, when executed by a processor, implement the vehicle fault handling method of any one of the first aspects.

In a fifth aspect, the invention provides a computer program product comprising a computer program which, when executed by a processor, implements a vehicle fault handling method as defined in any one of the first aspects.

The vehicle fault processing method, the device, the equipment and the storage medium are applied to distributed nodes in an SOA heterogeneous platform, and comprise a fault monitoring node, a fault reporting node, a fault information processing node and a fault storage node which sequentially transmit data, specifically, the running data corresponding to a plurality of running nodes in a vehicle can be obtained through the fault monitoring node, and the vehicle fault information is extracted from the running data; further, vehicle fault information is sent to a fault reporting node, and correspondingly, the received vehicle fault information is analyzed through the fault reporting node to obtain fault degree information, fault type information and diagnosis fault codes corresponding to the multiple operating nodes; the fault type information comprises system-on-chip (SoC) end information and microcontroller MCU end information; further, the information is sent to a fault information processing node, and correspondingly, the fault grade of the vehicle is determined through the fault information processing node according to the received fault degree information, the fault type information and the diagnosis fault code; further, the failure grade of the vehicle, the failure degree information and the diagnosis failure code are stored into a nonvolatile storage area in the file system by the failure storage node based on the failure type information, the nonvolatile storage area is used for the cloud device to perform diagnostic communication access based on the fault type information, wherein, the vehicle fault information can come from the SoC terminal and the MCU terminal, so that the invention can monitor the vehicle information from either the SoC terminal or the MCU terminal, and a certain amount of vehicle information data is acquired to carry out unified fault analysis on the vehicle information data, so that resources are saved, the fault level can be further determined, the processing flexibility is improved, the vehicle fault information is further respectively stored in the nonvolatile storage areas through the classification of fault types, and the access of cloud diagnosis communication is supported, so that the data is organized, and the data loss can be avoided.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description, serve to explain the principles of the invention.

Fig. 1 is a schematic view of an application scenario of a vehicle fault handling method according to an embodiment of the present invention;

FIG. 2 is a schematic structural diagram of an autonomous vehicle according to an embodiment of the present invention;

FIG. 3 is a schematic flow chart of a vehicle fault handling method according to an embodiment of the present invention;

fig. 4 is a schematic structural diagram of a distributed node in an SOA heterogeneous platform according to an embodiment of the present invention;

FIG. 5 is a schematic diagram of a vehicle fault handling method according to an embodiment of the present invention;

FIG. 6 is a schematic flow chart of another vehicle fault handling method according to an embodiment of the present invention;

fig. 7 is a schematic flow chart illustrating a fault self-check performed when a vehicle is started according to an embodiment of the present invention;

fig. 8 is a schematic flow chart illustrating a fault self-check performed when a vehicle starts according to another embodiment of the present invention;

fig. 9 is a schematic flowchart of a method for storing fault information according to an embodiment of the present invention;

fig. 10 is a schematic structural diagram of a vehicle fault handling device according to an embodiment of the present invention;

fig. 11 is a schematic hardware structure diagram of a vehicle fault processing device according to an embodiment of the present invention.

With the above figures, certain embodiments of the invention have been illustrated and described in more detail below. The drawings and the description are not intended to limit the scope of the inventive concept in any way, but rather to illustrate it by those skilled in the art with reference to specific embodiments.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention.

The terms to which the present invention relates will be explained first:

a System-on-a-chip (SoC) refers to an integrated circuit with a dedicated target that contains the complete System and has the full contents of embedded software. The wireless SoC comprises a system-on-chip control logic module, a microprocessor/microcontroller CPU core module, a Digital signal processor DSP module, an embedded memory module, an interface module for communicating with the outside, an Analog front-end module containing a Digital-to-Digital Converter (ADC)/Digital-to-Analog Converter (DAC), a power supply and power consumption management module, a radio frequency front-end module, user defined logic, a micro-electromechanical module, a basic software module or loadable user software and the like.

A Microcontroller Unit (MCU), which may also be referred to as a microcontrol Unit, refers to an integrated circuit device used to control other parts of an electronic system, which may be comprised of a CPU, non-volatile memory (ROM), volatile memory (RAM), peripheral devices and supporting circuitry.

The following explains an application scenario of the embodiment of the present invention:

fig. 1 is a schematic view of an application scenario of a vehicle fault processing method provided in an embodiment of the present invention, as shown in fig. 1, a vehicle fault detection system is disposed in a vehicle 102, and during a running process of the vehicle 102, operation data of the vehicle 102 may be periodically obtained for determining whether a fault exists in an operation state of the vehicle 102, and fault information encountered by the vehicle 102 may be stored in a nonvolatile storage area in a file system, so that a 4S shop worker may query the fault information from the nonvolatile storage area by using a terminal device or a cloud 101 queries the fault information from the nonvolatile storage area.

It can be understood that the present invention can be applied to an application scenario in which an autonomous vehicle needs to handle a vehicle fault during a driving process, and since the autonomous vehicle is controlled by a computing platform under an unmanned active control, the autonomous vehicle needs a variety of sensors to replace a driver to sense a change in a driving environment, specifically, the variety of sensors may be devices that can collect an external environment, such as a millimeter wave radar, a laser radar, and an image, and may sense a change in the driving environment by using a Global Positioning System (GPS) technology, a navigation technology, a high-precision map technology, an artificial intelligence technology, a monitoring device technology, a vehicle-to-vehicle communication technology, a vehicle-to-infrastructure technology, and a drive-by-wire technology.

For better understanding of the embodiment of the present invention, first, a structure of an autonomous vehicle to which the vehicle failure processing method of the present invention is applied will be briefly described with reference to fig. 2. Fig. 2 is a schematic structural diagram of an autonomous vehicle according to an embodiment of the present invention.

As shown in fig. 2, the autonomous vehicle 200 may include: a Domain Controller (DC) 201, a navigation System 202, a Vehicle display 203, an autopilot Module 204, an Instrument Cluster (IC) 205, a Vehicle Control Unit (VCU) 206, a Micro Control Unit (MCU) 207, a Power Distribution Unit (PDU) 208, a Battery Management System (BMS) 209, and a Body Control Module (BCM) 210, wherein the DC201 is constructed by a System on Chip (SoC).

It should be understood that the above-mentioned components CAN be connected by a Controller Area Network (CAN) bus, a Local Interconnect Network (LIN) bus, a flex ray bus, a Media Oriented Systems Transport (MOST) bus, and the like. Each of the types of buses described above may be used to transfer information between the various parts. It will also be appreciated that the form or format of the signals transmitted over the different buses connected to the different parts described above may be different and that the gateway may convert the signals in the different forms or formats before transmitting them to the receiver of the signals. Here, the gateway is only named one kind, and other processors capable of mutually converting signals of the above parts may be substituted.

Navigation systems may include, for example, but are not limited to, the Global Positioning System (GPS), the BeiDou Satellite Navigation System (BDS), Real-Time Kinematic Positioning (RTK), and Ultra Wide Band (UWB) Positioning systems. In the embodiment of the invention, the navigation system can be used for positioning the position of the automatic driving vehicle, acquiring the running speed of the vehicle, the remaining distance of the automatic driving road section and the like.

It is to be understood that the illustrated configuration of the embodiment of the present invention does not constitute any limitation on the autonomous vehicle 200. In other embodiments, the autonomous vehicle 200 may include more or fewer components than shown, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

It should be noted that, during the automatic driving, various parts of the vehicle 102 may be in failure, and in order to avoid an accident, the vehicle failure that occurs needs to be handled.

In the prior art, when a fault diagnosis system in a real-time domain processes a vehicle fault, a multi-ECU distributed control mode based on an MCU is usually used to periodically check the vehicle fault by using a unique program, and further process the fault generated by the vehicle.

Based on the above problems, the present invention provides a vehicle fault processing method based on a high-performance domain vehicle fault, which defines each node in a fault processing flow as a Service Oriented Architecture (SOA) Service, that is, a distributed node under a heterogeneous platform, under the SOA Architecture of the high-performance domain, where the distributed node includes a fault monitoring node, a fault reporting node, a fault information processing node, and a fault storage node, which sequentially transfer data, and processes the vehicle fault through the node.

The technical solution of the present invention will be described in detail below with specific examples. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present invention will be described below with reference to the accompanying drawings.

Fig. 3 is a schematic flow chart of a vehicle fault handling method according to an embodiment of the present invention, where the method of the present embodiment may be executed by a vehicle fault handling system. As shown in fig. 3, the method of this embodiment may include:

step S301, obtaining operation data corresponding to a plurality of operation nodes in the vehicle through the fault monitoring node, and extracting vehicle fault information from the operation data.

In this step, the fault monitoring node may obtain, through a publish-subscribe mechanism, operation data corresponding to a plurality of operation nodes in the vehicle.

The operational data may include, but is not limited to: vehicle state data, software operating data, and hardware operating data, which may include: tire pressure, electricity usage, motor status, variable-box operating status, vehicle travel speed, etc.; the software running data can comprise state detection data of service modules such as a perception module, a cognition module, a positioning module, a decision control module, a vehicle software control module, a map module and the like; the hardware operational data may include: the state detection data of equipment such as an industrial personal computer, a camera, a radar, a laser radar, an ultrasonic radar, a millimeter wave radar, a global positioning system, an inertia measuring device, an image acquisition module, an inertia sensor, a wheel speed meter, a global navigation satellite system and the like.

It can be understood that the plurality of operation nodes may refer to various sensors and operation components of the vehicle during driving, which is not specifically limited in this embodiment of the present invention, but the plurality of operation nodes are registered in advance in the fault monitoring node, so that the fault monitoring node may monitor operation data of the plurality of operation nodes, and may also artificially add an operation node to the fault monitoring node to monitor the added operation node.

In this embodiment, the vehicle fault information may include an operation state parameter, fault description information, and the like, where the operation state parameter includes an operation parameter when each operation node generates a fault, for example, a driving speed of 100km/h, an oil consumption of 1/km, a driving distance of 1m, and the like; the fault description information includes information describing a fault, for example, a fault occurs when a turn signal is not turned on, an image cannot be acquired by a camera, and the like.

For example, the fault monitoring node may obtain operation data corresponding to a speed sensor in the vehicle, and further extract operation state parameters, fault description information, and the like from the operation data, for example, the running speed is 100km/h, and the speed is too fast.

Step S302, analyzing the vehicle fault information through the fault report node to obtain fault reports corresponding to a plurality of operating nodes; the fault report comprises fault degree information, fault type information and a diagnosis fault code; the fault type information comprises system-on-chip (SoC) end information and microcontroller unit (MCU) end information.

In this embodiment, the failure degree information indicates the severity of a failure of a certain operating node in the vehicle. The fault type information comprises SoC end information and MCU end information, wherein the SoC end information indicates that vehicle fault information of each motion node comes from an SoC end, the MCU end information indicates that the vehicle fault information of each motion node comes from an MCU end, and the SoC end information and the MCU end information can be distinguished in a way of adding identification, for example, the vehicle fault information of each motion node from the SoC end is provided with an identification ID number '1', and the vehicle fault information of each motion node from the MCU end is provided with an identification ID number '2'.

The fault code may indicate what kind of fault the vehicle has in particular occurred, which may be specifically indicated according to a code that is internationally common; for example, when the generated fault code is P019, it indicates that the fuel pressure sensor is faulty and the fuel consumption is too high at this time; when the generated fault code is P021, it indicates that a fault such as overheating of the vehicle engine occurs at this time, and it is understood that the embodiment of the present invention is not particularly limited to the form of the fault code, and may be the above international code or a code specified by a person, for example, when the generated fault code is 010, it indicates that a fault occurs in the fuel pressure sensor at this time.

In this step, the vehicle fault information sent by a certain node may be analyzed through a fault report node, for example, a certain operation parameter in the vehicle fault information is oil consumption 1L/km, the operation parameter has a label "2", further, the certain operation parameter is compared with a normal parameter threshold, the normal parameter threshold is 0.072L/km, it is found that the oil consumption is too high and is greater than 10 times of the normal parameter threshold, the vehicle running may be affected, the level is level 1, meanwhile, a fault code P019 may be obtained, and the label "2" indicates that the operation parameter is the vehicle fault information of a certain moving node from the MCU end, and then it may be known that the fault report of the node is: the fault degree information is 1 level, the fault type information is MCU end information, and the fault code is P019.

It should be understood that the embodiment of the present invention is not limited to the specific method for determining the severity level of the fault level information, and the above is only an example.

And step S303, determining the fault grade of the vehicle according to the fault degree information, the fault type information and the diagnosis fault code through the fault information processing node.

In the step, the degree of influence on the vehicle running can be judged through the fault degree information, the fault type information and the diagnosis fault code, so that the fault level of the vehicle is determined, and if a certain operation node has serious fault and the operation node also influences that a plurality of operation nodes cannot normally operate after the operation node has the fault, the fault level is higher.

Optionally, if a certain operating node has a slight fault, for example, due to shielding of a building or being located in an underground parking lot, so that the communication signal is weak, and after a period of time elapses, the communication signal may be automatically recovered, and the influence on the driving function of the vehicle is not great, which indicates that the fault level is low.

It can be understood that the fault type information and the diagnosed fault code play an auxiliary role in determining the fault level of the vehicle, for example, if the fault type information is SoC side and the diagnosed fault code is P019, but the fault degree information is level 5, which is lower, the fault level is lower, and if the fault type information is SoC side and the diagnosed fault code is P019, which is higher, which also affects the normal operation of other operating nodes, which is higher, the fault level is higher.

Step S304, storing the fault level of the vehicle, the fault degree information and the diagnosis fault code to a nonvolatile storage area in a file system through the fault storage node based on the fault type information, wherein the nonvolatile storage area is used for the cloud equipment to access diagnosis communication based on the fault type information.

In the embodiment of the invention, the nonvolatile storage area in the file system is divided into two storage areas in advance, and the two storage areas are respectively used for storing the SoC side information and the MCU side information, namely the fault information from the SoC side and the fault information from the MCU side are respectively and correspondingly stored in different areas, so that the data classification is more organized, and the cloud end equipment can conveniently read the data.

In this step, the failure storage node may store the failure level of the vehicle, the failure degree information, and the diagnostic failure code in their corresponding storage areas, respectively, based on the failure type information, facilitating data management. For example, the fault level of the vehicle corresponding to the operating node 1 is a high level, the fault degree information is a level 1, the diagnostic fault code is P019, the operating node 1 carries an identifier "2" when sending data, the fault level of the vehicle corresponding to the operating node 2 is a medium level, the fault degree information is a level 5, the diagnostic fault code is P018, and the operating node 2 carries an identifier "1" when sending data, the fault level, the fault degree information and the diagnostic fault code of the vehicle corresponding to the operating node 1 are stored in the storage area 1, the fault level, the fault degree information and the diagnostic fault code of the vehicle corresponding to the operating node 2 are stored in the storage area 2, wherein the storage data type corresponding to the storage area 1 is SoC-side information, and the storage data type corresponding to the storage area 2 is MCU-side information.

It can be understood that when the cloud device accesses data in the nonvolatile storage area in the file system, the cloud device can access the data based on the classification of the fault type information, so that the access rate is improved.

Therefore, the vehicle information monitoring system can monitor the vehicle information from either the SoC terminal or the MCU terminal, acquire a certain amount of vehicle information data and perform unified fault analysis on the vehicle information data, save resources, further determine the fault level, improve the processing flexibility, further store the vehicle fault information into the nonvolatile storage area through the classification of the fault types, support the access of cloud diagnosis communication, enable the data to be organized and further avoid data loss.

It should be noted that the distributed nodes in the SOA heterogeneous platform may be software or hardware, or may be a combination of software and hardware, and the like, which is not specifically limited in this embodiment of the present invention. Specifically, fig. 4 is a schematic diagram of an architecture of a distributed node in an SOA heterogeneous platform according to an embodiment of the present invention, as shown in fig. 4, the distributed node in the SOA heterogeneous platform may include a fault monitoring node, a fault reporting node, a fault information processing node, and a fault storage node, which sequentially transmit data, where the fault monitoring node may receive operating data corresponding to an operating node for processing, and send the processed data to the fault reporting node, and correspondingly, the fault reporting node receives and analyzes the processed data, sends the analyzed data to the fault information processing node, and correspondingly, the fault information processing node receives and processes the analyzed data again, and sends the processed data to the fault storage node for storage.

For example, fig. 5 is a schematic diagram of a vehicle fault processing method according to an embodiment of the present invention, as shown in fig. 5, in order to implement processing of a fault generated by a vehicle, data of each running node may be monitored first, and a specific monitoring manner may be that a subscription mechanism is issued based on a fault monitoring node to receive the data of each running node; after the monitored data are collected, data analysis can be performed, wherein the data analysis refers to analyzing the collected data by a fault report node to obtain required parameter data; after the data analysis is finished, data analysis can be carried out, wherein the data analysis means that the fault information processing node analyzes the acquired parameter data and judges the level of the fault, namely the influence level corresponding to the fault of the vehicle; and finally, storing data according to the data analysis result, wherein the data storage can be classified storage of the analyzed data by a fault storage node and is used for supporting the access of diagnostic communication. The purpose of processing the vehicle fault can be realized based on the principle.

In this embodiment, creating an instance for subscribing to multiple nodes may refer to generating related objects from data produced by subscribing to multiple nodes, i.e., constructing a method for subscribing to data produced by multiple nodes.

The synchronization mode refers to that after the execution data sent by a certain execution node according to the subscription request is called, the execution can be continued after the return result of the call is waited. The asynchronous mode may refer to that after the execution data sent by a certain execution node according to the subscription request is called, subsequent operations can be continuously executed without waiting for a return result of the call, but local buffer refreshing is required.

In this step, the fault monitoring node may first create an instance for subscribing to a certain node, for example, create a proxy instance, and after creating the instance, Subscribe through a proxy interface Event (SWS _ CM _00141), and further, initiate a subscription request to a plurality of operating nodes in the vehicle; the subscription request is used for acquiring the operation data of a certain operation node; as the data receiving mode of the fault monitoring node is divided into a synchronous mode and an asynchronous mode, if the fault monitoring node is in the asynchronous mode, a callback function is transmitted into a SetReceiveHandler (SWS _ CM _00181) interface, an Event is called, an Update (SWS _ CM _00172) interface is called to refresh a buffer area, and finally an Event is executed, a GetCachedSamples (SWS _ CM _00173) interface acquires the operation data sent by a certain operation node according to a subscription request.

Therefore, the running data sent by the plurality of running nodes according to the subscription request can be queried asynchronously or synchronously, and the processing efficiency is improved according to the actual situation.

Optionally, fig. 6 is a schematic flow chart of another vehicle fault processing method provided in the embodiment of the present invention, as shown in fig. 6, the vehicle fault processing method provided in this embodiment further details step S302 on the basis of the vehicle fault processing method provided in the embodiment shown in fig. 3, and then the vehicle fault processing method provided in this embodiment includes the following steps:

step S601, obtaining operation data corresponding to a plurality of operation nodes in the vehicle through the fault monitoring node, and extracting vehicle fault information from the operation data.

Step S602, extracting characteristic information in the vehicle fault information through the fault report node, and comparing the characteristic information with a parameter threshold value in a preset fault library to obtain a comparison result.

In this embodiment, the characteristic information may include information of a failed node ID, information of a failure type, data corresponding to an operating parameter, a type number, and the like. The type number refers to a type number that a certain operation parameter comes from different operation nodes, for example, a certain operation parameter is oil consumption 1L/km, the operation parameter comes from an oil consumption type in a fuel pressure sensor, and the type number corresponding to the operation parameter is P1, it should be noted that each operation node can correspond to multiple types.

The fault library is provided with a mapping table of pre-collected parameter thresholds and type numbers corresponding to operation state parameters of different operation nodes of the vehicle when different faults occur, the mapping table is used for storing the corresponding relation between the type numbers of the different operation nodes of the vehicle and the faults of the operation nodes, and each type number is also corresponding to a parameter threshold and a fault code in a normal range.

In this step, the fault reporting node may extract characteristic information in the vehicle fault information corresponding to a certain operating node, for example, a certain operating parameter in the vehicle fault information of a certain operating node is oil consumption 1L/km, the operating parameter has a label of "2", the fault reporting node may extract that the fault node ID is the operating node 1, the data corresponding to the operating parameter is 1L/km, the fault type information is MCU end information, the type number is P1, further, a corresponding parameter threshold value of 0.072L/km is found based on the type number P1, the 1L/km is compared with the 0.072L/km, it is found that 1L/km is far greater than 0.072L/km and greater than 10 times of the normal parameter threshold value, the oil consumption is too high, it is possible that the fuel pressure sensor fails, further, it is determined that the level is 1, and finding out the corresponding fault code as P019.

It should be noted that, in the present invention, for comparison between the operating parameter and the parameter threshold, a multiple relationship of the difference is also set, and the larger the multiple difference is, the higher the influence degree level is, however, the degree level corresponding to the specific numerical value of the multiple relationship is not specifically limited in the present invention, for example, the degree level corresponding to the 10-fold relationship may be 1 level, or the degree level corresponding to the 10-fold relationship may be 2 levels.

Step S603, obtaining fault reports corresponding to a plurality of operating nodes through the fault reporting nodes according to the comparison result; the fault report comprises fault degree information, fault type information and a diagnosis fault code; the fault type information comprises system-on-chip (SoC) end information and microcontroller unit (MCU) end information.

In this step, the fault report node obtains a fault report corresponding to the operating node 1 based on a comparison result of the operating node 1, for example, the comparison result is: the node with the fault is an operation node 1, and the comparison with a parameter threshold value in a preset fault library shows that 1L/km is far greater than 0.072L/km and greater than 10 times of a normal parameter threshold value, the oil consumption is too high, and a fuel pressure sensor possibly has the fault, further, the grade of the sensor is determined to be grade 1, the fault code corresponding to the sensor is found to be P019, the fault type information is MCU (microprogrammed control unit) end information, and the corresponding fault report is as follows: the fault degree information is 1 level, the fault type information is MCU end information, and the fault code is P019.

And step S604, determining the fault grade of the vehicle according to the fault degree information, the fault type information and the diagnosis fault code through the fault information processing node.

Step S605, storing the fault level of the vehicle, the fault degree information, and the diagnostic fault code to a nonvolatile storage area in a file system by the fault storage node based on the fault type information, where the nonvolatile storage area is used for access of the cloud device for diagnostic communication based on the fault type information.

Therefore, the embodiment of the invention can specifically find the fault report corresponding to each operating node, improve the accuracy of identifying the fault information, further respectively store the vehicle fault information into the nonvolatile storage area through the classification of the fault types, support the access of cloud diagnosis communication, and ensure that the key data in the vehicle can be stably stored and is not easy to lose.

In this embodiment, the association influence degree may refer to an influence degree on other operation nodes after a certain operation node of the vehicle has a fault, where the operation node of the vehicle has an association relationship with some operation nodes. And the influence degree of the operating node on other operating nodes in the vehicle is determined according to the fault degree information and the diagnosis fault codes of the operating node, and if the operating node has serious fault and is associated with a plurality of operating nodes, the fault level is higher.

In this step, the fault reporting node may determine the degree of correlation influence based on the fault degree information and the diagnostic fault code corresponding to each operating node, for example, the operating node 1 is a communication module, the operating parameter is a 4G signal in a 3-grid state, the operating parameter is sent with a flag "1", the fault is a weak communication signal, the degree of influence is relatively slight, and the diagnostic fault code is 002, further, the fault reporting node may determine, based on the above information, that the degree of influence of the operating node 1 on other operating nodes is not large, and the vehicle may continue to run, and then may determine, based on the fault type information, that the fault level of the vehicle is relatively low for the SoC-side information, and is a third level (i.e., a lower level).

Therefore, the fault grade of the vehicle can be determined according to a plurality of data information such as fault degree information, fault type information and diagnosis fault codes, so that the fault grade determination mode is more accurate, and judgment errors are reduced.

Optionally, the method further includes:

For example, since the nonvolatile storage area in the file system can be divided into two storage areas in advance, namely a first storage area for storing information from the SoC side and a second storage area for storing an information failure storage node from the MCU side, further, after the failure storage node receives the failure level, the failure degree information and the diagnostic failure code of the vehicle corresponding to the multiple operating nodes, the information can be stored in the corresponding first storage area and second storage area based on the failure type information, which is convenient for data management. For example, the fault level of the vehicle corresponding to the operation node 1 is a first level, the fault degree information is a level 1, the diagnostic fault code is P019, and the fault type information is an SoC end; the fault grade of the vehicle corresponding to the operation node 2 is medium grade, the fault degree information is 5 grade, the diagnosis fault code is P018, and the fault type information is an SoC terminal; the fault grade of the vehicle corresponding to the operation node 3 is low grade, the fault degree information is 10 grade, the diagnosis fault code is P010, and the fault type information is an MCU end; the data corresponding to the running nodes 1 and 2 are stored in the first storage area, and the data corresponding to the running node 3 is stored in the second storage area.

Therefore, the data from the SoC terminal and the MCU terminal can be processed and then respectively stored, so that the data can be conveniently read and written, and the stored data can be more quickly accessed.

Optionally, the vehicle may process the generated fault during the driving process, but before the vehicle is started, the fault self-checking may be performed first, fig. 7 is a schematic flow diagram of performing the fault self-checking when the vehicle is started according to an embodiment of the present invention, and as shown in fig. 7, the execution method includes:

and step S701, acquiring the state of an electronic ignition switch of the vehicle.

In this step, the operating system in the vehicle may establish a communication connection with the electronic ignition system of the vehicle according to a diagnostic protocol corresponding to the vehicle, and further, may obtain a state of the electronic ignition switch of the vehicle.

For example, when the current ignition state of the vehicle changes from OFF to ON, it indicates that the vehicle is being started, and further, it is possible to acquire that the electronic ignition switch state of the vehicle is ON.

Step S702, if the state of the electronic ignition switch is a starting state, reading unprocessed historical fault information in the nonvolatile storage area; the historical fault information comprises the fault grade, the fault degree information and the fault type information of the vehicle, which are stored when the electronic ignition switch state of the vehicle is in the closed state last time.

In this step, the operating system in the vehicle may read the fault level, the fault degree information, and the fault type information stored at the last time the vehicle stopped running, and determine whether the information in the nonvolatile storage area has been processed.

It can be understood that after the staff member of the 4S store processes the fault in the nonvolatile storage area, the fault information in the nonvolatile storage area can be deleted through the terminal device, that is, which historical fault information in the nonvolatile storage area is resolved, and accordingly, the historical fault information is not available in the nonvolatile storage area.

In a possible implementation manner, historical fault information in the nonvolatile storage area can be read through the cloud device, a worker of a 4S shop can be reserved in advance to repair a vehicle fault, and after the historical fault information is solved, the fault information in the nonvolatile storage area is deleted through the cloud device.

And step S703, executing corresponding action according to the fault grade in the historical fault information.

In this step, the operating system of the vehicle may read a fault level corresponding to unprocessed information in the historical fault information, determine what operation should be performed next according to the level of the fault level, prohibit the vehicle from running if the fault level is high, or generate a prompt message if the fault level is low, send the prompt message to the terminal device of the user, remind the user that a certain operating node has a fault, and ask for timely maintenance and processing.

It can be understood that the invention can preliminarily judge the fault of the vehicle without the need of checking the vehicle by maintenance personnel, thereby improving the fault processing efficiency.

It should be noted that, because there is a requirement for the power-on time of a vehicle, the self-checking process has a high requirement for the implementation efficiency, at this time, when the operating system starts an application program, the fault information processing node is preferentially started to process each running node, and when the operating system passes the detection, the vehicle can be started to perform the service function of the computing platform, so that the intelligent driving computing platform is ensured to run safely.

Therefore, the invention can also preferentially start the self-checking function to carry out self-checking on the vehicle when the vehicle is started, thereby improving the safety performance and ensuring the stable operation of the vehicle.

Optionally, fig. 8 is a schematic flow chart of another fault self-test performed when the vehicle is started according to the embodiment of the present invention, as shown in fig. 8, the method for performing fault self-test when the vehicle is started according to the embodiment of the present invention further details step S703 on the basis of the method for performing fault self-test when the vehicle is started according to the embodiment of fig. 7, and then the method for performing fault self-test when the vehicle is started according to the present embodiment includes the following steps:

and step S801, acquiring the state of an electronic ignition switch of the vehicle.

Step S802, if the state of the electronic ignition switch is a starting state, reading unprocessed historical fault information in the nonvolatile storage area; the historical fault information comprises the fault grade, the fault degree information and the fault type information of the vehicle, which are stored when the electronic ignition switch state of the vehicle is in the closed state last time.

And step S803, judging whether the fault level in the historical fault information reaches a preset level.

In this step, the preset level may refer to a level set by the system to prohibit the vehicle from running after the level is reached, i.e., the fault is serious. The operating system of the vehicle may determine whether a failure level in the history failure information read from the nonvolatile storage area reaches a preset level.

And step S804, if at least one fault level reaches a preset level, sending an engine locking instruction to an engine electronic controller unit of the vehicle.

In this step, since the operating system can establish a communication connection with the engine system of the vehicle according to the diagnostic protocol, after the communication connection is established, if the operating system of the vehicle determines that at least one fault level among the fault levels in the historical fault information reaches a preset level, an engine locking instruction is sent to the engine system, for example, the instruction is 0000001, after the engine system receives the instruction, the engine is locked, and a return instruction of 0000002 indicates that the locking is successful, and the vehicle owner cannot drive.

If the operating system of the vehicle judges that none of the fault levels in the historical fault information reaches the preset level, the fault level can be a prompt message which is sent to the terminal equipment of the user to remind the user that a certain running node has a fault and please overhaul and process the fault in time. The embodiment of the invention does not limit the specific form of the prompt information, and can be used for sending a message prompt box, wherein the message prompt box is provided with buttons such as 'operation node 1 has a fault, and please examine and repair in time and process' message prompt for reminding a vehicle owner of processing the fault in time, and 'later processing, closing the bullet box' and 'reminding again at 2-hour intervals' for selection by a user.

In another possible implementation manner, if the operating system of the vehicle determines that none of the fault levels in the historical fault information reaches the preset level, it may be determined whether the vehicle is locked, and if the vehicle is in a locked state, an unlocking instruction is first sent to the engine system of the vehicle to unlock. Specifically, if the engine is locked due to a vehicle fault, an unlocking instruction is sent to an engine system of the vehicle for unlocking.

Therefore, by acquiring the state of the electronic ignition switch of the vehicle, whether the fault level in the historical fault information reaches the preset level or not can be further judged, if the fault level in the historical fault information reaches the preset level, an engine locking instruction can be sent to limit driving, the fault information of a vehicle owner is prompted in advance, and traffic accidents are avoided.

Optionally, when the failure information is stored in a non-volatile memory of the computing platform, the stored data may also be encrypted, fig. 9 is a flowchart of a method for storing the failure information according to an embodiment of the present invention, and as shown in fig. 9, the executing method includes:

step S901, invoking https encryption protocol to encrypt the first layer data of each item of data in the nonvolatile storage area.

In this embodiment, the https encryption protocol may refer to a secure hypertext transfer protocol, which is a secure communication channel developed based on http for exchanging information between the computing platform and the cloud. The system uses a Secure Socket Layer (SSL) for information exchange, uses an HTTP protocol encrypted by TLS/SSL, namely adds a layer of module for processing encrypted information on HTTP.

In this step, if the vehicle needs to store some sensitive data or data that needs to be encrypted, the failure information processing node sends the encrypted data to the failure storage node, and specifically, the failure information processing node invokes an https encryption protocol to perform first-layer data encryption on some sensitive data or data that needs to be encrypted.

It can be understood that which data in each item of data in the nonvolatile memory area is some sensitive data or data that needs to be encrypted may be set manually, or all data in the nonvolatile memory area may be encrypted, which is not specifically limited in this embodiment of the present invention.

And step S902, setting a preset encryption key to encrypt the second layer data of each item of data to generate encrypted data and an encrypted data ID corresponding to the encrypted data.

In this embodiment, the encryption key may refer to both of the transmitting and receiving data, and may be an encryption string for performing encryption and decryption operations on plaintext using the same or a symmetric key, for example, the encryption key may be a 9-bit cipher.

In this step, the fault information processing node may further set a preset encryption key to perform second-layer data encryption on some sensitive data or data to be encrypted, for example, set a 9-bit initial password to perform second-layer data encryption on the data, and further, may generate a corresponding encrypted data ID.

Step S903, sending the encrypted data and the encrypted data ID corresponding thereto to a cloud device, where the cloud device decrypts the encrypted data based on the encrypted data ID and reads the encrypted data.

In this step, the fault information processing node sends the generated encrypted data ID and the encrypted data to the fault storage node for storage, and correspondingly, the fault storage node can store the encrypted data and the encrypted data ID in a nonvolatile storage area in the file system, and further, the fault storage node sends the encrypted data and the encrypted data ID corresponding to the encrypted data to the cloud end device, so that the cloud end device decrypts the encrypted data based on the encrypted data ID and reads the encrypted data.

It should be noted that, when the failure information processing node encrypts data, the failure information processing node already divides the encrypted data into two types based on the failure type information in advance, and when the failure storage node stores the encrypted data, the failure information processing node stores the encrypted data into the corresponding storage areas respectively.

It can be understood that the cloud device can inquire the encrypted data from the nonvolatile storage area according to the encrypted data ID, and obtain the corresponding encrypted data when inquiring the encrypted data ID, and further, the cloud device can perform second-layer data decryption on the encrypted data by using a preset encryption key, and then call the https encryption protocol to perform first-layer data decryption, so as to obtain the decrypted data.

Therefore, for some sensitive data and data needing encryption, encryption service can be called to carry out two-layer data encryption, and safety and reliability are improved.

In this embodiment, the first level may refer to a level corresponding to a vehicle fault with a high degree of severity, and the second level may refer to a level corresponding to a vehicle fault with a low degree of severity. The setting of the failure level is used to evaluate the severity of the vehicle failure. For example, a first level fault may cause a safety accident, or a first level fault may cause a failure in the driving function of the vehicle; the second level fault does not cause a safety accident, nor does it cause the failure of the driving function of the vehicle. If the oil tank leaks, serious safety accidents can be caused, and the oil tank is classified as a first-level fault; the driving system is in failure, so that the vehicle cannot run, the driving function of the vehicle is failed due to the failure, and the failure is classified as a first-level failure; the network signal is poor, so that safety accidents cannot be caused, the driving function of the vehicle cannot be disabled, and the vehicle is classified as a second-level fault.

In this step, when it is determined that the vehicle has the first-level fault, a first instruction may be sent to the engine system to control the vehicle to perform parking processing, and a 4S shop worker may be reminded of the vehicle to go forward to the parking processing in a short message or telephone manner. When the vehicle is determined to have the second-level fault, a second instruction can be sent to control the vehicle to run to a vehicle maintenance point according to a preset running path or a re-planned running path, and further safety accidents can be avoided.

It can be understood that when the vehicle is controlled to park, the vehicle can search for a safe parking place, decelerate and run until parking, and light up a warning light to remind pedestrians and other vehicles; when the vehicle is controlled to travel to the vehicle maintenance point according to the preset travel path or the re-planned travel path, the vehicle can enter a low-speed travel mode and return to the vehicle maintenance point according to the set travel path, so that pedestrians, other vehicles and the like have sufficient time to avoid in the travel process, and the probability of safety accidents is further reduced.

It should be noted that, in practice, the rating criteria of the fault level may be various, the result of dividing the fault level according to the rating criteria of the fault level may be various, and the fault level may also include other levels, such as a third level, a fourth level, etc., and the classification of the levels is not specifically limited by the present invention, and the above is only an example.

Therefore, the fault levels of the vehicles can be determined to respectively execute different operations, the probability of safety accidents is reduced, and traffic accidents are avoided.

In the foregoing embodiments, the vehicle fault handling method provided by the embodiment of the present invention is described, and in order to implement each function in the method provided by the embodiment of the present invention, the electronic device as an execution subject may include a hardware structure and/or a software module, and each function is implemented in the form of a hardware structure, a software module, or a hardware structure plus a software module. Whether any of the above-described functions is implemented as a hardware structure, a software module, or a hardware structure plus a software module depends upon the particular application and design constraints imposed on the technical solution.

Fig. 10 is a schematic structural diagram of a vehicle fault handling device according to an embodiment of the present invention, and as shown in fig. 10, the vehicle fault handling device 100 includes:

the fault monitoring node 1001 is used for acquiring operation data corresponding to a plurality of operation nodes in a vehicle and extracting vehicle fault information from the operation data;

the fault report node 1002 is configured to analyze the vehicle fault information to obtain fault reports corresponding to the multiple operating nodes; the fault report comprises fault degree information, fault type information and a diagnosis fault code; the fault type information comprises system-on-chip (SoC) end information and microcontroller MCU end information;

a fault information processing node 1003, configured to determine a fault level of the vehicle according to the fault degree information, the fault type information, and the diagnostic fault code;

and the fault storage node 1004 is configured to store the fault level of the vehicle, the fault degree information and the diagnostic fault code to a nonvolatile storage area in a file system based on the fault type information, where the nonvolatile storage area is used for access of the cloud end device for performing diagnostic communication based on the fault type information.

Optionally, the plurality of running nodes are nodes registered in advance; the fault monitoring node 1001 is further configured to create an instance for subscribing to the plurality of nodes, and initiate a subscription request to a plurality of operating nodes in a vehicle by calling an interface corresponding to the instance; the subscription request is used for acquiring the operation data of the plurality of operation nodes;

correspondingly, the fault monitoring node 1001 is specifically configured to:

Optionally, the fault reporting node 1002 is specifically configured to:

Optionally, the failure information processing node 1003 is specifically configured to:

Optionally, the failure storage node 1004 is further configured to divide a nonvolatile storage area in the file system into two storage areas, namely a first storage area and a second storage area, based on the failure type information, where the first storage area is used to store information from the SoC end, and the second storage area is used to store information from the MCU end;

accordingly, the failed storage node 1004 is specifically configured to:

Optionally, the apparatus further includes an obtaining node, a reading node, and an executing node;

specifically, the obtaining node is configured to obtain an electronic ignition switch state of the vehicle;

the reading node is used for reading unprocessed historical fault information in the nonvolatile storage area when the state of the electronic ignition switch is a starting state; the historical fault information comprises the fault grade, the fault degree information and the fault type information of the vehicle, which are stored when the last time the electronic ignition switch of the vehicle is in the off state;

and the execution node is used for executing corresponding actions according to the fault levels in the historical fault information.

Optionally, the execution node is specifically configured to:

Optionally, the apparatus further includes an encryption node, where the encryption node is configured to:

Optionally, the fault levels include at least a first level and a second level; the apparatus further comprises a sending node configured to:

when the fault level of the vehicle is determined to be the first level, sending a first instruction to control the vehicle to carry out parking processing;

and when the fault level of the vehicle is determined to be the second level, sending a second instruction to control the vehicle to run to a vehicle maintenance point according to a preset running path or a re-planned running path.

The vehicle fault processing device provided by the embodiment of the invention can realize the vehicle fault processing method of the embodiment shown in fig. 3 to 9, and the realization principle and the technical effect are similar, and are not described again here.

Fig. 11 is a schematic hardware structure diagram of a vehicle fault processing device according to an embodiment of the present invention. As shown in fig. 11, the present embodiment provides a vehicle failure processing apparatus 110 including: at least one processor 1101 and memory 1102. The processor 1101 and the memory 1102 are connected by a bus 1103.

In a specific implementation, the at least one processor 1101 executes computer-executable instructions stored by the memory 1102, so that the at least one processor 1101 executes the vehicle fault handling method in the above-described method embodiment.

For a specific implementation process of the processor 1101, reference may be made to the above method embodiments, which implement similar principles and technical effects, and details of this embodiment are not described herein again.

In the embodiment shown in fig. 11, it should be understood that the Processor may be a Central Processing Unit (CPU), other general purpose processors, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the present invention may be embodied directly in a hardware processor, or in a combination of the hardware and software modules within the processor.

The memory may comprise high speed RAM memory and may also include non-volatile storage NVM, such as at least one disk memory.

The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, the buses in the figures of the present invention are not limited to only one bus or one type of bus.

The embodiment of the invention also provides a computer-readable storage medium, wherein a computer executing instruction is stored in the computer-readable storage medium, and when a processor executes the computer executing instruction, the vehicle fault processing method of the embodiment of the method is realized.

The computer-readable storage medium may be implemented by any type of volatile or non-volatile memory device or combination thereof, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk. Readable storage media can be any available media that can be accessed by a general purpose or special purpose computer.

An exemplary readable storage medium is coupled to the processor such the processor can read information from, and write information to, the readable storage medium. Of course, the readable storage medium may also be an integral part of the processor. The processor and the readable storage medium may reside in an Application Specific Integrated Circuits (ASIC). Of course, the processor and the readable storage medium may also reside as discrete components in the apparatus.

Those of ordinary skill in the art will understand that: all or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The program may be stored in a computer-readable storage medium. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A vehicle fault processing method is applied to distributed nodes in an SOA heterogeneous platform, wherein the distributed nodes comprise fault monitoring nodes, fault reporting nodes, fault information processing nodes and fault storage nodes which sequentially transmit data, and the method comprises the following steps:

2. The method of claim 1, wherein the plurality of operational nodes are pre-registered nodes; the method further comprises the following steps:

3. The method of claim 1, wherein analyzing the vehicle fault information to obtain fault reports corresponding to a plurality of operating nodes comprises:

4. The method of claim 1, wherein determining a fault level of a vehicle based on the fault extent information, the fault type information, and the diagnostic fault code comprises:

5. The method of claim 1, further comprising:

6. The method of claim 1, further comprising:

acquiring the state of an electronic ignition switch of a vehicle;

7. The method of claim 6, wherein performing corresponding actions based on the fault level in the historical fault information comprises:

8. The method of claim 1, further comprising:

9. The method of any of claims 1-8, wherein the fault levels include at least a first level and a second level; the method further comprises the following steps:

10. A vehicle fault handling device is applied to an SOA heterogeneous platform and comprises:

11. A vehicle failure processing apparatus, characterized by comprising: at least one processor and memory;

the memory stores computer-executable instructions;

the at least one processor executing the computer-executable instructions stored by the memory causes the at least one processor to perform the vehicle fault handling method of any of claims 1-9.

12. A computer-readable storage medium, characterized in that a computer-executable instruction is stored therein, which when executed by a processor, implements the vehicle fault handling method according to any one of claims 1 to 9.

13. A computer program product, characterized by comprising program code for performing the vehicle fault handling method according to any one of claims 1 to 9, when the computer program is run by a computer.