Vehicle fault data online monitoring system and method
By collecting and storing CAN bus data in real time through an online monitoring system, the problem of difficulty in obtaining data on intermittent vehicle faults is solved, enabling efficient fault analysis and maintenance support.
Patent Information
- Application Number
- CN202211048944.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-08-30
- Publication Date
- 2025-11-28
- Estimated Expiration
- 2042-08-30
AI Technical Summary
Existing technologies are insufficient for effectively monitoring and analyzing CAN bus data from intermittent vehicle faults, resulting in low efficiency in fault diagnosis.
The vehicle fault data online monitoring system is adopted. Through the gateway, vehicle-mounted intelligent terminal and cloud platform server, the central processor and buffer are used to collect and store CAN bus data in real time. The buffer monitors the fault alarm request signal in real time and transmits the data to the cloud platform for analysis via Ethernet protocol.
It enables complete recording and analysis of CAN communication data before and after a fault, improving fault diagnosis efficiency, especially the ability to diagnose intermittent faults, and enhancing the accuracy and efficiency of maintenance.
Smart Images
Figure CN115328096B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of automotive electronic systems, and particularly relates to a vehicle fault data online monitoring system and method. BACKGROUND
[0002] With the development of automobile electrification, intelligentization and informatization, the number of automobile controllers is increasing, the function implementation logic is gradually complex, and the interactive information amount between systems is also gradually increasing. In the new network architecture, the gateway connects multiple CAN buses and is responsible for the real-time routing of data between CAN buses. When a vehicle fault occurs, each ECU (controller) sends a fault light request signal to the CAN bus, and the ICM (instrument) lights the corresponding fault warning light after receiving the fault light request signal, so as to prompt the driver of the vehicle system fault and ensure the safety of the vehicle.
[0003] The signals exchanged between the systems of the CAN bus when the vehicle fault occurs are particularly important for troubleshooting. At present, the troubleshooting method for the instrument fault light problem fed back by the market mainly records the vehicle data by carrying a signal recording device or monitoring device (such as CANoe) on the fault vehicle after the fault occurs, and then removes the recording device after the fault recurs, and exports the recorded CAN bus data for problem analysis. This method is suitable for monitoring and analyzing persistent fault problems. For the case of occasional vehicle faults, the fault occurrence time and working conditions are uncontrollable, so it is not easy to monitor and obtain effective data for fault recurrence by using this method.
[0004] Therefore, there is an urgent need for a vehicle fault data online monitoring system and method. SUMMARY
[0005] The purpose of the present application is to provide a vehicle fault data online monitoring system and method to solve the above-mentioned problems in the prior art, which can completely obtain CAN communication data before and after the fault, facilitate rapid analysis of the problem, and improve the troubleshooting efficiency.
[0006] The present application provides a vehicle fault data online monitoring system, comprising:
[0007] A gateway, a vehicle intelligent terminal and a cloud platform server, the vehicle intelligent terminal is connected with the gateway and the cloud platform server respectively, the gateway comprises a central processor and an EPROM memory, the central processor is connected with each CAN node, and the central processor comprises a monitoring module, the EPROM memory comprises a first buffer, a second buffer and a third buffer, wherein:
[0008] The central processor is used for collecting CAN bus data information, and sending the CAN bus data information to the monitoring module, and sending the CAN bus data information to the vehicle intelligent terminal through Ethernet protocol after packaging.
[0009] The monitoring module is used for monitoring the fault light reporting request signals sent by each CAN node on the CAN bus, and sending a trigger signal to the first buffer, the second buffer and the third buffer when the fault light reporting request signal is monitored.
[0010] The first buffer, the second buffer and the third buffer are used for storing the communication message data of each network segment within a preset time before and after the monitoring module monitors the fault light reporting request signal in response to the trigger signal.
[0011] The vehicle intelligent terminal is used for sending the received CAN bus data information to the cloud platform server.
[0012] The cloud platform server is used for analyzing the received CAN bus data information to obtain vehicle fault analysis results.
[0013] The vehicle fault data online monitoring system as described above, wherein preferably, the CAN bus data information collected by the central processor includes CAN message identification data, CAN message period data and CAN data.
[0014] The vehicle fault data online monitoring system as described above, wherein preferably, in the process of sending the packaged CAN bus data information to the vehicle intelligent terminal through Ethernet protocol, the Ethernet data message format of the CAN bus data information includes a header field, an information field and a data field, wherein:
[0015] The header field includes a serial number and Δt, the serial number is used to represent the sending order between data frames, and Δt is used to represent the time interval between adjacent two data frames.
[0016] The information field includes data field attributes and data field frame numbers, and the data field attributes are used to represent whether the data packet record content contains data when the fault occurs.
[0017] The vehicle fault data online monitoring system as described above, wherein preferably, the data field attributes include first data field attributes, second data field attributes, third data field attributes, fourth data field attributes and fifth data field attributes,
[0018] The first data field attribute is used to represent the data within one half of the preset time before the fault, and the data of the entire one half of the preset time does not contain any fault signal.
[0019] The second data field attribute is used to indicate that the first half of the set of data is pre-fault data and the second half is post-fault data.
[0020] The third data field attribute is used to indicate data within a full half of the preset time after the fault.
[0021] The fourth data field attribute is used to indicate that the first half is data within a half of the preset time after the fault and the second half is data outside the half of the preset time after the fault and no new fault is generated.
[0022] The fifth data field attribute is used to indicate that the first half of the set of data is post-fault data after the last fault and the second half is post-fault data after the last fault and is also pre-fault data before the next fault.
[0023] The vehicle fault data online monitoring system as described above, preferably, the first buffer is specifically used for: in the case that no fault light request is received, writing each CAN bus data in a cyclic manner, and when the first buffer is full, starting to overwrite the initial data, so that the first buffer can store data within a preset time, at this time the data field attribute is set to the first data field attribute; when the first buffer is not full, the monitoring module detects that there is a fault light request, at this time the buffer area is not switched, and the first buffer continues to be written full, at this time the data field attribute is set to the second data field attribute; and the data written by the first buffer is sent to the vehicle-mounted intelligent terminal through Ethernet, and the vehicle-mounted intelligent terminal uploads the received data to the cloud platform server.
[0024] The vehicle fault data online monitoring system as described above, preferably, the second buffer is specifically used for: in the case that the monitoring module detects that there is a fault light request when the first buffer is not full, after the first buffer is written full, writing each CAN bus data in the second buffer; in the case that the first buffer is full and the monitoring module detects that there is a fault light request, writing each post-fault CAN bus data in the second buffer; in the case that the time of writing data to the second buffer does not reach the preset time and the monitoring module does not detect that there is a fault light request, continuing to write the second buffer full, at this time the data field attribute is set to the third data field attribute; in the case that the time of writing data to the second buffer does not reach the preset time and the monitoring module detects that there is a new fault light request, at this time the buffer is not switched, and the second buffer continues to be written full until the second buffer is full, at this time the data field attribute is set to the fifth data field attribute; and the data written by the second buffer is sent to the vehicle-mounted intelligent terminal through Ethernet, and the vehicle-mounted intelligent terminal uploads the received data to the cloud platform server.
[0025] The vehicle fault data online monitoring system as described above, preferably, the third buffer is specifically used for: starting to write the CAN bus data into the third buffer in a cycle after the second buffer is full of data, for recording the data before the next fault occurs; in the case that the time for writing the data into the second buffer does not reach the preset time and the monitoring module monitors that there is a new fault light request, writing the CAN bus data into the third buffer after the second buffer is full of data.
[0026] The application further provides a vehicle fault data online monitoring method using the system.
[0027] The central processor of the gateway collects CAN bus data information and sends the CAN bus data information to the monitoring module;
[0028] The monitoring module monitors the fault light request signals sent by the CAN nodes on the CAN bus in real time, and sends a trigger signal to the first buffer, the second buffer and the third buffer when the fault light request signal is monitored;
[0029] In response to the trigger signal, the first buffer, the second buffer and the third buffer store the communication message data of each network segment within the preset time before and after the monitoring module monitors the fault light request signal, and send the stored data to the central processor;
[0030] The central processor packs the CAN bus data information written by the first buffer, the second buffer and the third buffer and sends the CAN bus data information to the vehicle intelligent terminal through the Ethernet protocol;
[0031] The vehicle intelligent terminal sends the received CAN bus data information to the cloud platform server;
[0032] The cloud platform server analyzes the received CAN bus data information to obtain a vehicle fault analysis result.
[0033] The vehicle fault data online monitoring method as described above, preferably, the monitoring module monitors the fault light request signals sent by the CAN nodes on the CAN bus in real time, and sends a trigger signal to the first buffer, the second buffer and the third buffer when the fault light request signal is monitored, and specifically includes:
[0034] The monitoring module monitors the fault light request signals sent by the CAN nodes on the CAN bus in real time;
[0035] The monitoring module judges whether a node sends a fault light request signal;
[0036] If the monitoring module judges that a node sends a fault light reporting request signal, a trigger signal is sent to the first buffer, the second buffer and the third buffer;
[0037] If the monitoring module judges that no node sends a fault light reporting request signal, the step of monitoring the fault light reporting request signal in real time is returned to, and each CAN bus data is written into the first buffer in a loop, and when the first buffer is full, the initial data is overwritten to enable the first buffer to store data within a preset time, at this time the data field attribute is set to a first data field attribute, and the first data field attribute is used to represent data within a first half of the preset time before a fault, and the entire half of the preset time does not contain any fault signal.
[0038] The vehicle fault data online monitoring method as described above, preferably, in response to the trigger signal, the first buffer, the second buffer and the third buffer store communication message data of each network segment within a preset time before and after the monitoring module detects a fault light reporting request signal, and send the stored data to the central processor, and specifically includes:
[0039] In response to the trigger signal, and when the first buffer is not full, the buffer area is not switched, and the first buffer is continued to be written full, at this time the data field attribute is set to a second data field attribute, and the second data field attribute is used to represent that the first half of the group of data is pre-fault data and the second half is post-fault data;
[0040] When the first buffer is not full, and the monitoring module detects a fault light reporting request, after the first buffer is continued to be written full, each CAN bus data is written into the second buffer;
[0041] When the first buffer is full, and the monitoring module detects a fault light reporting request, each post-fault CAN bus data is written into the second buffer;
[0042] After the first buffer is written full, the data stored in the first buffer is sent to the central processor;
[0043] When the time of writing data into the second buffer does not reach a preset time, and the monitoring module does not detect a fault light reporting request, the second buffer is continued to be written full, at this time the data field attribute is set to a third data field attribute, and the third data field attribute is used to represent data within a complete half of the preset time after a fault;
[0044] When the time for writing data into the second buffer does not reach the preset time and the monitoring module monitors a new fault lamp request, the buffer is not switched at this time, and the second buffer is continuously written until it is full, at which time the data field attribute is set to a fifth data field attribute, and the fifth data field attribute is used to indicate that the first half of the group of data is data after the last fault, and the second half is data after the last fault and also data before the next fault;
[0045] After the second buffer is full, the data stored in the second buffer is sent to the central processor;
[0046] After the second buffer is full, the first buffer and the second buffer are emptied, and each CAN bus data is written into the third buffer for recording data before the next fault occurs;
[0047] When the time for writing data into the second buffer does not reach the preset time and the monitoring module monitors a new fault lamp request, the buffer is not switched at this time, and the second buffer is continuously written until it is full, at which time the data field attribute is set to a fifth data field attribute, and the fifth data field attribute is used to indicate that the first half of the group of data is data after the last fault, and the second half is data after the last fault and also data before the next fault;
[0048] The vehicle fault data online monitoring system and method of the application, the gateway determines whether the vehicle sends a fault by monitoring the state of the fault lamp request signal sent by each node; the recording function of the first buffer, the second buffer and the third buffer is triggered only after the monitoring module monitors the fault lamp request signal sent by each CAN node on the CAN bus, compared with the real-time recording and uploading data mode after power-on, the data transmission amount is small, and the data processing capacity requirement of the gateway, the vehicle intelligent terminal and the cloud platform server is not high; the three buffers can completely and effectively obtain the vehicle CAN communication data before and after the fault occurs, prevent data transmission disorder or loss caused by buffer overflow, and store and send the vehicle CAN communication data in a period of time before and after the fault occurs to the vehicle intelligent terminal and the cloud platform server when the vehicle fault occurs, so that the data before and after the fault occurs is recorded in real time and accurately, the problem is analyzed quickly, the troubleshooting efficiency is improved, a data basis is provided for vehicle fault code troubleshooting, especially troubleshooting of occasional faults, and the correctness and efficiency of maintenance are improved. BRIEF DESCRIPTION OF DRAWINGS
[0049] In order to make the purpose, technical scheme and advantages of the application more clear, the application will be further described below with reference to the drawings, in which:
[0050] Figure 1 An architecture diagram of an embodiment of the vehicle fault data online monitoring system provided by the application;
[0051] Figure 2 A flowchart of the vehicle fault data online monitoring method provided by the application;
[0052] Figure 3 A logic diagram of the vehicle fault data online monitoring method provided by the present application. DETAILED DESCRIPTION
[0053] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. The description of the exemplary embodiments is merely illustrative in nature and is in no way intended to limit the disclosure, its application or uses, except as described by the appended claims. The present disclosure can be implemented in numerous different forms, as is desired for specific applications; it is therefore not
[0054] The terms "first", "second", and similar terms used in the present disclosure do not denote any order, quantity, or importance, but are used to distinguish different parts. The terms "include" or "comprise" and similar terms mean that the elements before the word encompass the elements listed after the word, and do not exclude the possibility of also encompassing other elements. "Up", "down", and the like are used only to indicate relative positional relationships, and when the absolute positions of the described objects are changed, the relative positional relationships can also be changed accordingly.
[0055] In the present disclosure, when it is described that a specific component is located between a first component and a second component, there can be an intervening component between the specific component and the first component or the second component, or there can be no intervening component. When it is described that a specific component is connected to other components, the specific component can be directly connected to the other components without an intervening component, or can not be directly connected to the other components with an intervening component.
[0056] All terms used in the present disclosure, including technical or scientific terms, have the same meanings as those understood by a person of ordinary skill in the art to which the present disclosure pertains, unless otherwise specifically defined. It should also be understood that terms defined in commonly used dictionaries should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and should not be interpreted in an idealized or overly formal sense, unless specifically so defined herein.
[0057] Techniques, methods, and devices known to those of ordinary skill in the relevant art can not be discussed in detail, but where appropriate, the techniques, methods, and devices should be considered as part of the specification.
[0058] When the vehicle fails, the 4S shop maintenance personnel need to use special equipment to spend a lot of time and effort to reproduce the fault to obtain the CAN communication data at the time of failure, however, some occasional faults are difficult to reproduce, resulting in low maintenance efficiency, causing great complaints from customers.
[0059] As Figure 1 shown, the vehicle fault data online monitoring system provided by the embodiment comprises a gateway, a vehicle-mounted intelligent terminal (TBOX) and a cloud platform server, the vehicle-mounted intelligent terminal (TBOX) is connected with the gateway and the cloud platform server respectively, the gateway comprises a central processing unit (CPU) and an EPROM memory, the central processing unit is connected with each CAN node, and the central processing unit comprises a monitoring module, the EPROM memory comprises a first buffer, a second buffer and a third buffer, wherein:
[0060] The central processing unit is used for collecting CAN bus data information, and sending the CAN bus data information to the monitoring module, and sending the CAN bus data information to the vehicle-mounted intelligent terminal (TBOX) through an Ethernet protocol after the CAN bus data information is packaged;
[0061] The monitoring module is used for monitoring the fault light request signals sent by each CAN node on the CAN bus, and sending a trigger signal to the first buffer, the second buffer and the third buffer when the fault light request signal is monitored;
[0062] The first buffer, the second buffer and the third buffer are used for storing the communication message data of each network segment within a preset time (for example, 2s) before and after the fault light request signal monitored by the monitoring module in response to the trigger signal;
[0063] The vehicle-mounted intelligent terminal (TBOX) is used for sending the received CAN bus data information to the cloud platform server;
[0064] The cloud platform server is used for analyzing the received CAN bus data information to obtain a vehicle fault analysis result.
[0065] In work, when the gateway monitors the fault light signal trigger, the communication message data of each network segment within a preset time (for example, t=2s) before and after the fault light request is collected and processed, and the collected data is packaged and sent to the vehicle-mounted intelligent terminal (TBOX) through the Ethernet and uploaded to the cloud platform server, the cloud platform server analyzes the received CAN bus data information to obtain a vehicle fault analysis result. It should be noted that the preset time is not limited in the application.
[0066] Further, the CAN bus data information collected by the central processor includes CAN message identification (CAN ID) data, CAN message cycle data, and CAN data, wherein the CAN message identification data occupies 2 bytes, the CAN message cycle data occupies 2 bytes, and the CAN data occupies 8 bytes, and the total occupies 12 bytes.
[0067] Further, the gateway needs to package all the received CAN message data into Ethernet data. Specifically, in the process of sending the packaged CAN bus data information to the vehicle-mounted intelligent terminal through the Ethernet protocol, the central processor of the gateway, as shown in Table 1, the Ethernet data message format of the CAN bus data information includes a header field (Head), an information field (Info), and a data field (Data), wherein:
[0068] The header field includes a serial number and Δt, wherein the serial number is used to represent the sending order between data frames, and Δt is used to represent the time interval between adjacent two data frames. As shown in Table 1, the header field occupies 4 bytes of space, the serial number and Δt each occupy 2 bytes of space, the sending node packages data according to the data message format, and the receiving node unpacks data according to the message format, so as to ensure the ordered transmission and unpacking correctness of the data; the serial number ranges from 0 to 6535, starts from 0, and increases cyclically, indicating the message packaging order number; if the current data packet is the first data packet, Δt is 0; otherwise, it is the time difference between the packaging time of the current data packet and the packaging time of the previous data packet;
[0069] The information field includes data field attributes and data field frame numbers, and the data field attributes are used to represent whether the data packet record content contains data when a fault occurs. As shown in Table 1, the information field occupies 4 bytes of space, and the data field attributes and the data field frame numbers each occupy 2 bytes of space.
[0070] Table 1 - Ethernet data message format
[0071]
[0072] Further, the data field attributes are used to represent whether the data packet record content contains data when a fault occurs. Specifically, the data field attributes include a first data field attribute, a second data field attribute, a third data field attribute, a fourth data field attribute, and a fifth data field attribute. As shown in Table 1, the data field frame number ranges from 0 to 121, that is, the data field contains at most 121 frames of CAN message data, 0 indicates that the data field is empty, and each frame of CAN message data occupies 12 bytes. Specifically,
[0073] The first data field attribute is used to represent data in the first half of the preset time (e.g. 1s) before failure, and the data in the whole half of the preset time (e.g. 1s) does not contain any failure signal;
[0074] The second data field attribute is used to represent that the first half of the data is pre-failure data and the second half is post-failure data.
[0075] The third data field attribute is used to represent data in the whole half of the preset time (e.g. 1s) after failure.
[0076] The fourth data field attribute is used to represent that the first half is data in the half of the preset time (e.g. 1s) after failure, the second half is data outside the half of the preset time (e.g. 1s) after failure, and no new failure occurs.
[0077] The fifth data field attribute is used to represent that the first half of the data is post-failure data after the last failure, and the second half is post-failure data after the last failure and pre-failure data before the next failure.
[0078] Furthermore, the size of each of the first buffer, the second buffer and the third buffer is set according to the size of the data packet in the recording time. Specifically,
[0079] The first buffer is specifically configured to: when no failure light request is received, write CAN bus data in a circular manner, and when the first buffer is full, start to overwrite the initial data, so that the first buffer can store data in a preset time (e.g. 2s), at this time the data field attribute is set to the first data field attribute; when the first buffer is not full, the monitoring module detects that there is a failure light request, at this time the buffer area is not switched, the first buffer is continued to be written full, at this time the data field attribute is set to the second data field attribute; and the data written in the first buffer is sent to the vehicle-mounted intelligent terminal through Ethernet, and the vehicle-mounted intelligent terminal uploads the received data to the cloud platform server.
[0080] Further, the second buffer is specifically configured to: when the first buffer is not full, the monitoring module monitors that there is a fault light request, and then writes the CAN bus data into the second buffer after the first buffer is full; when the first buffer is full, and the monitoring module monitors that there is a fault light request, then writes the CAN bus data after the fault into the second buffer; when the time of writing data into the second buffer does not reach a preset time (for example, 2s), and the monitoring module does not monitor that there is a fault light request, the second buffer continues to be full, and at this time, the data field attribute is set to a third data field attribute; when the time of writing data into the second buffer does not reach a preset time (for example, 2s), and the monitoring module monitors that there is a new fault light request, at this time, the buffer is not switched, and the second buffer continues to be full until then, at this time, the data field attribute is set to a fifth data field attribute; and the data written in the second buffer is sent to the vehicle intelligent terminal through Ethernet, and the vehicle intelligent terminal uploads the data to the cloud platform server after receiving the data.
[0081] Further, the third buffer is specifically configured to: after the second buffer is full of data, start to write the CAN bus data into the third buffer in a cycle, for recording the data before the next fault occurs; when the time of writing data into the second buffer does not reach a preset time (for example, 2s), and the monitoring module monitors that there is a new fault light request, after the second buffer is full of data, write the CAN bus data into the third buffer.
[0082] The vehicle fault data online monitoring system provided by the embodiment of the application, the gateway determines whether the vehicle sends a fault by monitoring the state of the fault light request signal sent by each node; the recording functions of the first buffer, the second buffer and the third buffer are triggered only after the monitoring module monitors the fault light request signal sent by each CAN node on the CAN bus, compared with the way of recording and uploading data in real time after power-on, the data transmission amount is small, and the data processing capacity requirement of the gateway, the vehicle intelligent terminal and the cloud platform server is not high; the three buffers can completely and effectively obtain the whole vehicle CAN communication data before and after the fault occurs, prevent the overflow of the buffer to cause disorder or loss of data transmission, when the vehicle fault occurs, the gateway stores and sends the whole vehicle CAN communication data in a period of time before and after the fault to the vehicle intelligent terminal to upload to the cloud platform server, records the data before and after the fault in real time and accurately, facilitates the rapid analysis of problems, improves the troubleshooting efficiency, provides a data basis for the troubleshooting of vehicle fault codes, especially the troubleshooting of occasional faults, and improves the correctness and efficiency of maintenance.
[0083] As Figure 2 and Figure 3As shown, the vehicle fault data online monitoring method provided by the embodiment specifically includes the following steps.
[0084] In step S1, the central processor of the gateway collects CAN bus data information and sends the CAN bus data information to the monitoring module.
[0085] In step S2, the monitoring module monitors the fault lamp request signals sent by each CAN node on the CAN bus in real time, and sends a trigger signal to the first buffer, the second buffer and the third buffer when the fault lamp request signal is monitored.
[0086] In an embodiment of the vehicle fault data online monitoring method, the step S2 specifically can include:
[0087] In step S21, the monitoring module monitors the fault lamp request signals sent by each CAN node on the CAN bus in real time.
[0088] In step S22, the monitoring module judges whether there is a node sending the fault lamp request signal.
[0089] In step S23, if the monitoring module judges that there is a node sending the fault lamp request signal, a trigger signal is sent to the first buffer, the second buffer and the third buffer.
[0090] In step S24, if the monitoring module judges that there is no node sending the fault lamp request signal, the step of monitoring the fault lamp request signal in real time is returned, and each CAN bus data is written into the first buffer in a loop, and when the first buffer is full, the initial data is overwritten, so that the first buffer can store data within a preset time (for example, 2s), at this time, the data field attribute is set to the first data field attribute, and the first data field attribute is used to represent data within one half of the preset time (for example, 1s) before the fault, and the data within the whole one half of the preset time does not contain any fault signal.
[0091] In step S3, in response to the trigger signal, the first buffer, the second buffer and the third buffer store the communication message data of each network segment within a preset time (for example, 2s) before and after the monitoring module monitoring the fault lamp request signal, and send the stored data to the central processor.
[0092] In an embodiment of the vehicle fault data online monitoring method, the step S3 specifically can include:
[0093] Step S31, in response to the trigger signal, and the first buffer is not full, then do not switch the buffer, continue to write the first buffer full, at this time the data field attribute is set to the second data field attribute, the second data field attribute is used to indicate that the first half of the group of data is pre-fault data, and the second half is post-fault data.
[0094] Step S32, when the first buffer is not full, the monitoring module monitors that there is a fault lamp request, and after continuing to write the first buffer full, writes each CAN bus data in the second buffer.
[0095] Step S33, when the first buffer is full, and the monitoring module monitors that there is a fault lamp request, then writes each post-fault CAN bus data in the second buffer.
[0096] Step S34, after the first buffer is full, the data stored in the first buffer is sent to the central processor.
[0097] Step S35, when the time of writing data to the second buffer does not reach the preset time (for example, 2s), and the monitoring module does not monitor that there is a fault lamp request, continue to write the second buffer full, at this time the data field attribute is set to the third data field attribute, the third data field attribute is used to indicate the data within one half of the preset time (for example, 1s) after the fault.
[0098] Step S36, when the time of writing data to the second buffer does not reach the preset time (for example, 2s), and the monitoring module monitors that there is a new fault lamp request, at this time do not switch the buffer, continue to write the second buffer full, at this time the data field attribute is set to the fifth data field attribute, the fifth data field attribute is used to indicate that the first half of the group of data is the last post-fault data, and the second half is also the next pre-fault data.
[0099] Step S37, after the second buffer is full, the data stored in the second buffer is sent to the central processor.
[0100] Step S38, after the second buffer is full, empty the first buffer and the second buffer, and cycle each CAN bus data to the third buffer for recording the data before the next fault occurs.
[0101] Step S39, when the time of writing data to the second buffer does not reach the preset time (for example, 2s), and the monitoring module monitors that there is a new fault lamp request, after the second buffer is full of data, write each CAN bus data to the third buffer.
[0102] Step S4, the central processor packages the CAN bus data information written by the first buffer, the second buffer and the third buffer and sends to the vehicle intelligent terminal through the Ethernet protocol.
[0103] Step S5, the vehicle intelligent terminal sends the received CAN bus data information to the cloud platform server.
[0104] Step S6, the cloud platform server analyzes the received CAN bus data information to obtain a vehicle fault analysis result.
[0105] The vehicle fault data online monitoring method provided by the embodiment of the application, the gateway determines whether the vehicle sends a fault by monitoring the state of the fault lamp request signal sent by each node; the recording function of the first buffer, the second buffer and the third buffer is triggered only after the monitoring module monitors the fault lamp request signal sent by each CAN node on the CAN bus, compared with the real-time recording and uploading data mode after power-on, the data transmission amount is small, the data processing capacity requirement of the gateway, the vehicle intelligent terminal and the cloud platform server is not high; the three buffers are adopted to completely and effectively obtain the whole vehicle CAN communication data before and after the fault occurs, prevent the data transmission disorder or loss caused by buffer overflow, when the vehicle fault occurs, the gateway stores the whole vehicle CAN communication data in a period of time before and after the fault occurs and sends to the vehicle intelligent terminal to upload the cloud platform server, the data before and after the fault occurs is recorded in real time and accurately, which facilitates the rapid analysis of problems and improves the troubleshooting efficiency, provides a data basis for vehicle fault code troubleshooting, especially the troubleshooting of occasional faults, and improves the correctness and efficiency of maintenance.
[0106] So far, the embodiments of the present disclosure have been described in detail. In order to avoid obscuring the concept of the present disclosure, some details known in the art are not described. Those skilled in the art can fully understand how to implement the technical solutions disclosed herein according to the above description.
[0107] Although some specific embodiments of the present disclosure have been described in detail through examples, those skilled in the art should understand that the above examples are only for illustration, not for limiting the scope of the present disclosure. Those skilled in the art should understand that the above embodiments can be modified or some technical features can be replaced equivalently without departing from the scope and spirit of the present disclosure. The scope of the present disclosure is defined by the appended claims.
Claims
1. A vehicle fault data online monitoring system, characterized in that, The application relates to a gateway, a vehicle-mounted intelligent terminal and a cloud platform server, wherein the vehicle-mounted intelligent terminal is connected with the gateway and the cloud platform server, the gateway comprises a central processor and an EPROM memory, the central processor is connected with CAN nodes, the central processor comprises a monitoring module, the EPROM memory comprises a first buffer, a second buffer and a third buffer, wherein the central processor is used for collecting CAN bus data information and sending the CAN bus data information to the monitoring module, and the CAN bus data information is packaged and sent to the vehicle-mounted intelligent terminal through an Ethernet protocol; the monitoring module is used for monitoring fault light reporting request signals sent by the CAN nodes on a CAN bus, and sending a trigger signal to the first buffer, the second buffer and the third buffer when the fault light reporting request signals are monitored; the first buffer, the second buffer and the third buffer are used for storing communication message data of each network segment within a preset time before and after the monitoring module monitoring the fault light reporting request signals in response to the trigger signal; the vehicle-mounted intelligent terminal is used for sending the received CAN bus data information to the cloud platform server; the cloud platform server is used for analyzing the received CAN bus data information to obtain vehicle fault analysis results; in the process of sending the packaged CAN bus data information to the vehicle-mounted intelligent terminal through the Ethernet protocol, an Ethernet data message format of the CAN bus data information comprises a head domain, an information domain and a data domain, wherein the head domain comprises a serial number and Delta t, the serial number is used for representing the sending sequence between data frames, and Delta t is used for representing the time interval between adjacent two data frames; the information domain comprises data domain attributes and data domain frame numbers, the data domain attributes are used for representing whether the data packet record content contains data when a fault occurs; the data domain attributes comprise a first data domain attribute, a second data domain attribute, a third data domain attribute and a fourth data domain attribute, the first data domain attribute is used for representing data within a first half of a preset time before a fault, and the data within the whole first half of the preset time does not contain any fault signal; the second data domain attribute is used for representing that a front half of data is data before a fault, and a rear half of data is data after the fault; the third data domain attribute is used for representing data within a second half of the preset time after the fault; and the fourth data domain attribute is used for representing that a front half of a group of data is data after a previous fault, a rear half of the group of data is data after the previous fault, and the rear half of the group of data is also data before a next fault. The second buffer is specifically used for: when the first buffer is not full, the monitoring module monitors that there is a fault light reporting request, and after the first buffer is full, each CAN bus data is written in the second buffer; when the first buffer is full, and the monitoring module monitors that there is a fault light reporting request, each CAN bus data after the fault is written in the second buffer; when the time of writing data into the second buffer does not reach a preset time, and the monitoring module does not monitor that there is a fault light reporting request, the second buffer is continuously filled, and at this time, the data field attribute is set as a third data field attribute; when the time of writing data into the second buffer does not reach the preset time, and the monitoring module monitors that there is a new fault light reporting request, the buffer is not switched, and the second buffer is continuously filled until the second buffer is full, and at this time, the data field attribute is set as a fourth data field attribute; and the data written in the second buffer is sent to the vehicle-mounted intelligent terminal through Ethernet, and the vehicle-mounted intelligent terminal uploads the data to the cloud platform server after receiving the data.
2. The vehicle fault data online monitoring system of claim 1, wherein, The CAN bus data information collected by the central processor includes CAN message identification data, CAN message cycle data and CAN data.
3. The online monitoring system for vehicle fault data of claim 1, wherein, The first buffer is specifically used for: when no fault light reporting request is received, each CAN bus data is written in a cyclic manner, and when the first buffer is full, the initial data is overwritten, so that the first buffer can store data within a preset time, and at this time, the data field attribute is set as a first data field attribute; when the first buffer is not full, the monitoring module monitors that there is a fault light reporting request, the buffer is not switched, and the first buffer is continuously filled until the first buffer is full, and at this time, the data field attribute is set as a second data field attribute; and the data written in the first buffer is sent to the vehicle-mounted intelligent terminal through Ethernet, and the vehicle-mounted intelligent terminal uploads the data to the cloud platform server after receiving the data.
4. The online monitoring system for vehicle fault data of claim 1, wherein, The third buffer is specifically used for: after the second buffer is full of data, each CAN bus data is written into the third buffer in a cyclic manner, for recording data before the next fault occurs; when the time of writing data into the second buffer does not reach a preset time, and the monitoring module monitors that there is a new fault light reporting request, after the second buffer is full of data, each CAN bus data is written into the third buffer.
5. A method for online monitoring of vehicle failure data using the system of any one of claims 1-4, characterized in that, The method comprises the following steps: The central processor of the gateway collects CAN bus data information, and sends the CAN bus data information to the monitoring module; The monitoring module monitors the fault light reporting request signals sent by each CAN node on the CAN bus in real time, and sends a trigger signal to the first buffer, the second buffer and the third buffer when the fault light reporting request signal is monitored; In response to the trigger signal, the first buffer, the second buffer and the third buffer store the communication message data of each network segment within a preset time before and after the monitoring module monitors the fault light reporting request signal, and send the stored data to the central processor; The central processor packages the CAN bus data information written by the first buffer, the second buffer and the third buffer and sends the information to the vehicle intelligent terminal through an Ethernet protocol; The vehicle intelligent terminal sends the received CAN bus data information to a cloud platform server; The cloud platform server analyzes the received CAN bus data information and obtains a vehicle fault analysis result.
6. The method of online monitoring of vehicle fault data of claim 5, wherein, The monitoring module monitors the fault light request signals sent by each CAN node on the CAN bus in real time, and sends a trigger signal to the first buffer, the second buffer and the third buffer when a fault light request signal is monitored, and specifically includes: The monitoring module monitors the fault light request signals sent by each CAN node on the CAN bus in real time; The monitoring module determines whether a node sends a fault light request signal; If the monitoring module determines that a node sends a fault light request signal, a trigger signal is sent to the first buffer, the second buffer and the third buffer; If the monitoring module determines that no node sends a fault light request signal, the monitoring module monitors the fault light request signal in real time, and each CAN bus data is written into the first buffer in a loop, and when the first buffer is full, the initial data is overwritten, so that the first buffer can store data within a preset time, at this time, the data field attribute is set to a first data field attribute, and the first data field attribute is used to represent data within a first half of the preset time before a fault, and the entire half of the preset time does not contain any fault signal.
7. The method of claim 5, wherein, In response to the trigger signal, the first buffer, the second buffer and the third buffer store the communication message data of each network segment within a preset time before and after the monitoring module monitors the fault light request signal, and send the stored data to the central processor, and specifically includes: In response to the trigger signal, and when the first buffer is not full, the buffer area is not switched, and the first buffer is continued to be written full, at this time, the data field attribute is set to a second data field attribute, and the second data field attribute is used to represent that the first half of the group data is pre-fault data and the second half is post-fault data; When the first buffer is not full, the monitoring module monitors that there is a fault light request, and after the first buffer is continued to be written full, each CAN bus data is written into the second buffer; When the first buffer is full and the monitoring module monitors that there is a fault light request, each CAN bus data after the fault is written into the second buffer; After the first buffer is written full, the data stored in the first buffer is sent to the central processor; When the time for writing data into the second buffer does not reach a preset time and the monitoring module does not monitor that there is a fault light request, the second buffer is continued to be written full, at this time, the data field attribute is set to a third data field attribute, and the third data field attribute is used to represent data within a complete half of the preset time after a fault. In the case that the time of writing data into the second buffer does not reach the preset time and the monitoring module monitors a new failure lamp request, the buffer is not switched at this time, and the second buffer is continuously written until it is full. At this time, the data field attribute is set to a fourth data field attribute, and the fourth data field attribute is used to indicate that the first half of the group of data is data after the last failure, and the second half is data after the last failure and also data before the next failure; After the second buffer is full, the data stored in the second buffer is sent to the central processor; After the second buffer is full, the first buffer and the second buffer are emptied, and each CAN bus data is written into the third buffer in a loop, for recording data before the next failure occurs; In the case that the time of writing data into the second buffer does not reach the preset time and the monitoring module monitors a new failure lamp request, after the second buffer is full of data, each CAN bus data is written into the third buffer.
Citation Information
Patent Citations
Vehicle data collection method and system, vehicle and readable storage medium
CN111552273A