Method and system for monitoring automobile ECU (Electronic Control Unit) node loss

Abstract

The invention relates to the technical field of vehicle fault detection, in particular to a monitoring method and system for automobile ECU node loss. The system comprises a gateway controller which is used for acquiring loss information of at least one electronic control unit (ECU) node in a vehicle and uploading the loss information to a server in real time; the server is used for storing and counting the lost information to obtain at least one data index; and the visualization equipment is used for carrying out visualization display on the data indexes. The invention provides an automobile ECU node loss monitoring scheme which is low in cost, simple and convenient to operate and intuitive.

Description

Technical Field

[0001] The present application relates to the technical field of vehicle fault detection, and in particular to a monitoring method and system for automobile ECU node loss. Background Art

[0002] In modern cars, Electronic Control Units (ECUs) are core components responsible for various vehicle functions. These ECUs communicate and coordinate their work through the vehicle's internal network, such as the CAN bus. When an ECU node is lost, it means that the node cannot communicate properly with other nodes or the central system. This may result in reduced vehicle performance, fault lights turning on, or other abnormal behavior.

[0003] Most modern cars use a Controller Area Network (CAN) bus to enable communication between ECUs. Each ECU sends and receives information via the CAN bus. If a certain ECU node suddenly stops sending or receiving messages, the other nodes will notice the change and register it as a fault. Once an anomaly is detected, the ECU will generate a Diagnostic Trouble Code (DTC) and store it in the fault memory. Each DTC corresponds to a specific component or system within the vehicle, such as the engine, transmission, or exhaust system. When a problem occurs, the onboard computer will store the relevant DTC in its memory, which can be accessed using a scan tool or through the onboard diagnostic system.

[0004] Currently, the main way to check DTC is through the on-board diagnostic system (OBD-II) and professional automotive diagnostic tools (such as scan tools). However, these devices and tools are usually expensive and inconvenient to carry, the operation steps are cumbersome, and the loss of ECU cannot be displayed intuitively. Summary of the invention

[0005] The purpose of the present application is to provide a method and system for monitoring automobile ECU node loss, so as to provide a low-cost, easy-to-operate and intuitive automobile ECU node loss monitoring solution.

[0006] In order to achieve the above objectives, this application adopts the following technical solutions: In a first aspect, the present application provides a monitoring system for automobile ECU node loss, comprising: A gateway controller, used to obtain loss information of at least one electronic control unit ECU node in the vehicle, and upload the loss information to a server in real time; The server is used to store and count the loss information to obtain at least one data indicator; A visualization device is used to visualize the data indicators.

[0007] In a second aspect, the present application provides a method for monitoring automobile ECU node loss, comprising: Obtaining loss information of at least one electronic control unit ECU node in the vehicle; Storing and counting the lost information to obtain at least one data indicator; The data indicators are displayed visually.

[0008] Compared with the prior art, the beneficial effects of this application are: After obtaining the loss information of at least one electronic control unit ECU node in the vehicle, the application stores and counts the loss information to obtain at least one data indicator; the data indicator is then visualized without the need to use diagnostic equipment to diagnose the ECU; through the visual display, there is no need to correspond the fault code to the ECU where the node loss occurs according to the protocol, and the operation is simple; real-time monitoring of the ECU loss information and storage and analysis can discover patterns and trends in the data, which helps to promptly discover potential problems and avoid failures. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0010] Figure 1 It is a structural schematic diagram of a monitoring system for automobile ECU node loss provided in an embodiment of the present application; Figure 2 is a schematic diagram of a flow chart for determining whether an ECU node is lost provided in this embodiment; Figure 3 It is a flowchart of determining whether an ECU node is lost and recovered provided in this embodiment; Figure 4 It is a structural schematic diagram of another automobile ECU node loss monitoring system provided by this embodiment; Figure 5 It is a flow chart of a method for monitoring automobile ECU node loss provided in an embodiment of the present application. DETAILED DESCRIPTION

[0011] The following is a description of exemplary embodiments of the present application in conjunction with the accompanying drawings, including various details of the embodiments of the present application to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Similarly, for the sake of clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0012] In order to solve the technical problems in the background technology, the present application provides a monitoring system for automobile ECU node loss, which automatically collects the loss information of each ECU and performs storage, statistics and visualization. Figure 1 It is a structural diagram of a monitoring system for automobile ECU node loss provided in an embodiment of the present application, which is suitable for detecting and monitoring the loss of each ECU node in the vehicle.

[0013] See also Figure 1 The system provided in this embodiment includes: a gateway controller, a server and a visualization device. The gateway controller (gateway, GW) is a bridge for communication between ECUs. These ECUs (including ECU1~ECUn) are connected to the GW through the CAN bus, which is called the lower pendant of the GW. The GW is connected to the server in communication, and the server can be deployed locally or in the cloud. The server is connected to the visualization device in communication. Optionally, the visualization device is a user-oriented device that is remotely connected to the server.

[0014] The gateway controller is used to obtain the loss information of at least one ECU node in the vehicle and upload the loss information to the server in real time. When these ECUs do not communicate with the GW at the specified time, a node loss failure occurs. Therefore, the GW can deploy a node loss detection algorithm to detect and upload the loss information of all ECU nodes.

[0015] Optional, see Figure 1 , GW is connected to the server via Ethernet, so that GW obtains the loss information of at least one electronic control unit ECU node in the vehicle, and uploads the loss information to the server via Ethernet in real time.

[0016] The server is used to store and count the loss information to obtain at least one data indicator. Optionally, a database, such as a time series database (such as InfluxDB), is deployed in the server. The loss information of each ECU at each moment is stored through the time series database, that is, the loss information of the ECU node is saved in the form of time series data. The loss information of all ECU nodes on the vehicle is saved in the time series database through the dot interface deployed on the GW. Among them, time series data refers to a set of data arranged at a certain time interval. These data can reflect the state or degree of change of a thing or phenomenon over time, such as the number of times the loss fault code occurs, the frequency, the vehicle state when it occurs (such as the speed), and other information.

[0017] Optionally, this embodiment saves the loss information of the ECU node into a time series database, so that the amount of data can be greatly increased, thereby saving the loss information of the ECU node at each moment; and by integrating the loss information at each moment in the past, the loss information of each ECU node can be integrated into a dashboard, and the loss information of each ECU at each moment can be replayed through the time series database. For example, with time as the horizontal axis, the loss information of each ECU node and other information (such as CAN bus status) are displayed in different colors of scattered points and status bars, which greatly facilitates engineers to capture node loss information and analyze the reasons for node loss.

[0018] The server reads data from the time series database and performs statistical analysis on the data to obtain data indicators, such as the loss rate within a set time period, the total number of losses, the frequency of losses, etc. Those skilled in the art can perform statistics based on the information in the time series database to obtain the required data indicators.

[0019] The visualization device is used to visualize data indicators. Optionally, a Grafana-based data visualization interface is deployed in the visualization device and displayed to any user who accesses the visualization interface in the form of charts. Grafana is an open source program for visualizing large measurement data, providing a powerful and elegant way to create, share, and browse data.

[0020] Among them, Grafana's data visualization interface can display various types of charts to meet the needs of different data presentations. The specific introduction is as follows: 1. Instrument panel: Displays data in the form of an arc pointer, which is suitable for showing the ratio of a certain metric to the maximum value. In this embodiment, the instrument panel is used to display the real-time vehicle speed.

[0021] 2. Histogram: Use height to represent frequency, which is suitable for displaying data distribution. This dashboard uses a histogram to display the number of ECUs with ECU node loss at each moment.

[0022] 3. Scatter plot: Use points to represent data, and the horizontal and vertical coordinates are two numerical variables respectively, which is suitable for viewing the relationship between two variables. In this histogram, multiple scatter plots are used to show the number of ECUs lost at each time node.

[0023] Through a variety of chart types and rich configuration options, Grafana can flexibly display data from various data sources, helping engineers better monitor and analyze the loss of ECU nodes.

[0024] After obtaining the loss information of at least one ECU node in the vehicle, the present application stores and counts the loss information to obtain at least one data indicator; the data indicator is then visualized without the need to use diagnostic equipment to diagnose the ECU; through the visual display, there is no need to correspond the fault code to the ECU where the node loss occurs according to the protocol, and the operation is simple; real-time monitoring of the ECU's loss information and storage and analysis can discover patterns and trends in the data, which helps to promptly discover potential problems and avoid failures.

[0025] Next, the software and hardware architecture of GW is described in detail based on the above embodiments.

[0026] GW is responsible for collecting the loss information of each ECU node of the vehicle from the CAN bus and sending the loss information to the database on the server. GW is deployed with the following key modules: 1) Data acquisition agent: The agent software installed on the GW is responsible for monitoring the CAN bus messages. When the ECU node loss detection algorithm detects the node loss, it calls the dot API (Application Programming Interface) to upload the node loss information to the database. 2) Dot API: The API provided to the data acquisition agent in the GW is used to send the captured loss information to the server in a specific format. Optionally, the loss information includes the ECU identifier (used to indicate the identity of the ECU), the fault code, the ECU status information (including normal status, fault status, etc.) and the vehicle status information (such as vehicle speed, power consumption, etc.). 3) Loss information acquisition component of each ECU node: Monitor the communication messages of each ECU hanging under the GW through the CAN bus. When the ECU sends a DTC to the GW, the database dot API is called to complete the storage of the DTC of the ECU.

[0027] A node loss detection algorithm is deployed in GW, which mainly monitors the ECU loss and recovery status in a timely and accurate manner by configuring the fault code structure and timeout information table.

[0028] Specifically, according to the specification requirements, the id of the MRR (Measurement Result Recording) message is 0x1B0, and the occurrence cycle of the MRR message is 20ms. Several preconditions for the occurrence of a fault must be met. The judgment condition for the occurrence of a node loss fault is that the MRR (0x1B0) message is lost 10 times in a row, that is, if there is no communication with the MPP message within 200ms, the MRR node's lost fault data is reported. Its recovery condition is to receive fault recovery information (0x1B0 message bit 0 is 0, bit3 remains 1) and all messages are received in the correct cycle. The following is a detailed description of the process of the node loss detection algorithm.

[0029] First, register the ECU node lost fault code, including the value of the fault code when the ECU node is lost, the value of the CANID of the communication message with the GW, the cycle value of the communication message with the GW, the communication message timeout status, the communication message timeout count, the channel number of the communication message with the GW, the fault level, the ECU's effective flag, the fault status, the recovery count and other information.

[0030] Register the lost fault codes of the above ECUs into the timeout information table.

[0031] Then, the node loss fault detection function is called to perform ECU node loss detection. The node loss fault detection function is a 10ms periodic function, which periodically traverses the information of each ECU node in the timeout information table can_timeout when running.

[0032] For ECU node loss failure, the prerequisites according to the specification include: 1) ECU is powered on, the ignition switch is placed in the ON position for a delay of 2s; 2) the diagnostic function is restored after 500ms; 3) non-bus-off state; 4) each ECU node is within the normal voltage range. Among them, the bus-off state is a state in which the ECU node is forcibly isolated from the CAN network after a serious error is detected. When the ECU node is in the bus-off state, it will not be able to send or receive any messages, which is equivalent to the ECU node being disconnected from the bus network.

[0033] See also Figure 2 , determine whether the ECU node is lost through the following operations.

[0034] S120: Execute a node loss monitoring timer, wherein the period of the timer is 10 ms, which is referred to as the first period in this embodiment.

[0035] After the timer counts for 10ms, it triggers the entry into the following steps S122~S1291.

[0036] S121. Traverse the timeout information table of each ECU node.

[0037] S122, determine whether the timeout information table has been traversed. If yes, execute S127, return to the main program, wait for the next 10ms before executing the diagnostic operation using the timeout information table. If no, execute S123.

[0038] S123, determine whether the communication message of the ECU node is received, if not, execute S124; if received, return to S121 and continue to traverse the timeout information table of the next ECU node.

[0039] S124, count of lost messages +1.

[0040] The number of lost messages is recorded in the timeout information table. When messages are lost continuously, the operation of accumulating ++1 is performed. The size of the continuous count value and the preset value (for example, 10) needs to be judged in real time. In the process of continuous counting of lost messages, the gateway needs to determine whether the message is recorded in the timeout information table s_can_timeout after receiving the message. If so, the counting is interrupted and the continuous count value is judged again.

[0041] S125, determine whether the continuous count value is greater than or equal to the preset value. If yes, execute S126; if not, return to S121.

[0042] S126, determining that the controller node is in a lost state, and recording the lost state in a timeout information table; uploading the lost information of the ECU node to the database through the dot API.

[0043] The message count value is cleared and the count is restarted; at the same time, the ECU node is set to be lost and the system returns to S121.

[0044] S127. Return to the main program.

[0045] See also Figure 3 ,In the process of losing counting of ECU nodes, the following operations are used to determine whether the ECU node is lost and recovered.

[0046] S130. In the process of continuously counting lost messages, if a message is received, the timeout information table of the ECU node is traversed.

[0047] S131. Determine whether the received message exists in the timeout information table. If yes, execute S132; otherwise, execute S133.

[0048] S132, clear the count value in the timeout information table, determine that the ECU node is in a non-lost state, and record the non-lost state in the timeout information table. Execute S133.

[0049] If the message exists in the timeout information table, the count value is cleared and the count starts again; it is set that the ECU node is not lost.

[0050] S133. Return to the main program.

[0051] This embodiment implements fault judgment of node loss and recovery through counting operations and interruption operations in the timeout information table. The implementation is simple, effective and low-cost.

[0052] After detecting a loss failure of an ECU node, the dot API will be called once to save the loss information of the ECU node to the database. When the loss failure occurs again, the dot API will be called again. In this way, the loss information of all ECU nodes can be saved. When the loss is restored, the dot API will stop being called.

[0053] In some cases, in order to prevent false alarms when the ECU node is in sleep state, self-upgrade and debugging, in this embodiment, when the GW determines that the ECU is currently in sleep state, self-upgrade state or debugging state, it filters the current loss information of the ECU node.

[0054] Add an effective flag bit to the fault code structure of each ECU. If the effective flag bit is 1, the loss information of the ECU is sent to the database. If the effective flag bit is 0, the loss information of the ECU is filtered. Add an interface to the self-upgrade program of each ECU node to obtain the self-upgrade status and debugging status of the ECU node.

[0055] Optionally, the current sleep state of the ECU is obtained through the CAN bus. The current self-upgrade state and debugging state of the ECU are obtained through the ECU interface; the effective flag is determined according to the sleep state, self-upgrade state or debugging state; and the current loss information of the ECU is filtered according to the effective flag.

[0056] This embodiment adds a vehicle status judgment function, and obtains the vehicle status through the CAN bus. If the vehicle is in a low-power state, each ECU enters a dormant state and does not send communication messages. It is a normal vehicle state. At this time, the effective flag position of all ECU nodes should be 0, and no node loss is reported. When the ECU node is self-upgrading, it needs to load the upgraded firmware or program, and the ECU will restart. When it restarts, it will stop sending communication messages. It is also a normal vehicle state. The effective flag position of the ECU node should be 0, and no node loss is reported. After the self-upgrade is completed, the effective flag position is set to 1, so that the invalid node loss information during the upgrade is not recorded. In some cases, the ECU node can be debugged through code or remote diagnostic functions. For example, the data of the ECU is read through the code or remote diagnostic function, and the data is analyzed and adjusted. The adjusted data is saved in the ECU to ensure that the adjustment effect is maintained. The ECU node may be closed during the debugging process, resulting in node loss. Therefore, when the ECU is currently in the debugging state obtained through the ECU interface, the effective flag position is set to 0, and the node loss is not reported; after the debugging is completed, the effective flag position is set to 1.

[0057] Optionally, the method of "filtering the current loss information of the ECU" includes but is not limited to: deleting the current loss information of the ECU node and not sending the current loss information of the ECU node to the database.

[0058] Optionally, when the GW determines that a communication failure (such as bus-off) occurs on the CAN bus of the vehicle, the GW obtains the CAN bus status of the vehicle and uploads the CAN bus status to the server.

[0059] When a communication failure occurs on the CAN bus, the node loss condition is not met, and the loss information of the ECU node is not reported. Instead, the dot API is called to report the current CAN bus status through Ethernet to save the current CAN bus status to the database. This embodiment can record the CAN bus status through Ethernet communication when the CAN bus fails and loses communication capability. Differentiated recording of CAN bus communication failure and node loss failure is achieved.

[0060] Next, the software and hardware architecture of the server is described in detail based on the above embodiments.

[0061] The server is responsible for receiving loss information from the GW and storing the loss information in the time series database. The server includes the following key modules: 1) Time series database: a high-performance time series database used to store loss information and other information (such as CAN bus status) from the GW. 2) Data reception service: a service running on the server, responsible for receiving loss information and other information from the GW and writing it into the time series database.

[0062] Next, the software and hardware architecture of the visualization device is described in detail based on the above embodiment. The visualization device includes a visualization panel and a node loss fault report automatic generation tool.

[0063] The visualization panel provides a data visualization interface, allowing users to configure and view the visualization of data. The key modules of the visualization panel include: 1) an open source monitoring and alarm tool (such as Prometheus), which is used to query and display data from the time series database. 2) The visualization panel uses Grafana to connect to Prometheus. By configuring the Grafana dashboard, data indicators are displayed.

[0064] Among them, the node loss fault report automatic generation tool is used to generate a fault report based on the lost information and send the fault report to the designated terminal. Among them, the designated terminal includes the terminal equipment of professionals, such as mobile phones and computers. If the type of ECU node of the lost information meets the set requirements, an alarm will be automatically sent to the designated terminal. For example, the data of node loss failures that occurred within a set time period (such as a week or a month) will be counted, and an online fault report will be automatically generated, including the number, severity, frequency of occurrence, etc. of the faults. The fault occurrence will be displayed in a concise manner on the web page, and fault reports can be sent to user terminals (such as mobile phones) on a regular basis. If the ECU node of the power, braking, etc. type is lost, an alarm will be automatically sent to the user terminal.

[0065] The key modules of the node loss fault report automatic generation tool include: 1) Fault report typesetting design component, such as HTML (HyperText Markup Language) template, which is used to design an HTML template suitable for displaying the vehicle's ECU node loss data. 2) Back-end development component: Use Python's Web framework such as Flask framework to build back-end services. The Flask framework can implement functions such as routing, time series database connection and report sending API to generate and send fault reports. 3) Report generation code: Write Python code to classify the severity according to the collected ECU node loss information, count the number and frequency of ECU node loss, and dynamically fill in the designed report template to generate a report. 4) Report push component: Write code to periodically send fault reports to the specified terminal and count the fault occurrence information within the period. 5) Tool deployment component: Deploy the fault report automatic generation tool to the server and connect the tool to the time series database.

[0066] Optionally, when sending the fault report to the designated terminal, the visualization device determines the severity of the vehicle fault according to the fault code; determines the sending method of the fault report according to the severity; and sends the fault report to the designated terminal according to the sending method. The designated terminal includes terminal devices of professionals, such as mobile phones and computers.

[0067] For example, if the fault code determines that the vehicle has brake failure, insufficient power, or a vehicle collision, the severity levels are vehicle collision, brake failure, and insufficient power. Select different communication methods with different speeds according to the severity level, and notify engineers and other professionals through office software group chat, email, mobile phone text messages, and phone calls. For example, after a vehicle collision, the fastest way to notify professionals is by phone.

[0068] In order to ensure the data transmission between GW and server is safe and reliable, the following key modules of Ethernet are set: 1) Ethernet communication hardware and software: An ECU supporting Ethernet communication should have Ethernet MAC (Media Access Control) and PHY (Physical Layer) chips, MII / RMII / GMII / RGMII interfaces, necessary software protocol stacks, and related network tests and security mechanisms. 2) Network environment components: Configure the network protocol stack for the running environment of the FreeRTOS operating system on the ECU, such as lwIP (Lightweight IP), which is a small open source TCP / IP protocol stack. 3) Ethernet connection components: GW is connected to the server via Ethernet to ensure stable network communication. For ordinary Ethernet gateways, it is connected to the server through T-BOX; for central gateways, it is connected to the server through its own 4G / 5G communication function. 4) Data transmission protocol, defines the communication protocol between GW and the server, using the http protocol.

[0069] See also Figure 4 The system also includes a management device for managing the editing, viewing and management rights of different personnel on the visualization panel and configuring the lost information that needs to trigger an automatic alarm. Next, the hardware and software architecture of the management device is described in detail based on the above embodiment.

[0070] The management device needs to protect the security of the entire system and prevent unauthorized access. The key modules of the management device include: 1) Authentication mechanism setting module: ensure that only authenticated users can access the system's data visualization interface URL (Uniform Resource Locator). 2) Authorization policy setting module: define the permissions of different users, such as viewing, editing or managing the visualization panel.

[0071] Several user permissions are listed below, but not limited to them. Technical personnel in this field can edit permissions through the authorization policy setting module. For example, development engineers have the permission to view, edit or manage lost information on the visualization panel. Test engineers have the permission to view lost information on the visualization panel. Maintenance personnel have the permission to view lost information on the visualization panel. Emergency response personnel have the permission to view lost information on the visualization panel. Car companies can provide login accounts for visualization panels to regular 4S stores, repair shops, and professionals. Professionals can configure: when a specific ECU node is lost (such as brake, power-related ECU loss, etc.), an alarm will be automatically and directly reported to the car company's customer service. Ordinary users have the permission to view the visualization panel and have editing permissions for some data.

[0072] The structure and construction process of the monitoring system are described in detail below.

[0073] Step 1: Install and configure the InfluxDB database on the server.

[0074] Step 2: Install Prometheus and configure it to connect to influxdb.

[0075] Step 3: Develop the management API of the influxdb database on the server.

[0076] Step 4: Configure the network environment to ensure that the GW can communicate with the server through Ethernet.

[0077] Step 5: Develop or integrate a data collection agent on GW, and implement the integration and compilation of the InfluxDB API code.

[0078] Step 6: Ensure that the key ECU nodes (ECU1~ECUn) of the vehicle can communicate with the GW through the CAN bus.

[0079] Step 7: Integrate the node loss detection algorithm in the GW. When the node loss is detected by the node loss detection algorithm, save the dot data and call the dot API of the influxdb database to complete the dot saving of the node loss information of the downstream ECU.

[0080] Step 8: Connect Grafana to Prometheus, create a visualization panel, and configure the data indicators of interest. For example, configure a vehicle speed panel, a bar chart of the total number of ECU node losses, and a scatter plot of n ECU node loss information, where each scatter point represents a node loss in the ECU.

[0081] Step 9: Implement security measures through management equipment, including user authentication and authorization. For example, users are divided into administrators and ordinary users. Administrators can view and configure the data indicators they are concerned about at any time, and users can view these data indicators at any time. Open the URL of the Grafana data visualization panel to facilitate all development engineers, test engineers, users, maintenance personnel, and emergency response personnel to observe the real-time loss information of the vehicle.

[0082] Step 10: Configure the real-time alarm system through the management device, and configure the instant alarm service through Alertmanager in Prometheus. Configure the data indicator risk level classification. When the monitored fault code has a specific abnormality (such as braking, power, and vehicle collision status), select different ways to notify engineers, car company customer service personnel and other professionals based on the risk level.

[0083] Step 11: Deploy the fault report automatic generation tool to the server.

[0084] Step 12: Conduct system testing to ensure data accuracy and visualization correctness.

[0085] When it is necessary to maintain and upgrade the monitoring system for lost automotive ECU nodes, perform the following operations: 1) Regularly check system performance and optimize database and query efficiency. 2) Update data collection points and visualization panels according to test requirements. 3) Open the Grafana data visualization panel URL to account applications, so that all practitioners (such as 4S stores and repair shops) can obtain an account that can view the visualization panel through formal channels.

[0086] In some embodiments, the monitoring system for lost automotive ECU nodes supports the function of remotely diagnosing ECU nodes. Vehicle remote diagnosis (DoIP, Diagnostic over Internet Protocol) is a technology for remote diagnosis of vehicles via the Internet. The vehicle remote diagnosis function allows technicians to diagnose and troubleshoot the vehicle's ECU without direct contact with the vehicle. The following is the process of diagnosing each ECU node through the GW: The first step is to establish a network connection between the diagnostic tool and the vehicle GW. For example, the diagnostic tool needs to obtain the GW's IP address (Internet Protocol Address) and diagnostic port number in advance. When establishing the connection, the diagnostic tool initiates a diagnosis on the IP address and diagnostic port. Once the connection is established, communication with the GW can begin.

[0087] In the second step, the diagnostic tool sends a diagnostic request to the GW. For example, a technician sends a diagnostic request to the GW through a diagnostic tool. The request contains the identifier of the specific ECU node that needs to be diagnosed and the required diagnostic operation (such as reading fault codes, clearing fault codes, etc.). The diagnostic request message is constructed based on the UDS (Unified Diagnostic Services) unified diagnostic service protocol.

[0088] In the third step, the GW forwards the diagnostic request to the ECU node. For example, after receiving the diagnostic request, the GW will forward it to the corresponding ECU. According to the vehicle communication protocol, different ECU nodes are assigned different physical addresses, and the GW distributes the diagnostic message to the corresponding ECU according to the physical addressing.

[0089] In the fourth step, the ECU node responds to the diagnostic request. For example, the ECU node that receives the diagnostic request will perform corresponding operations according to the UDS request and generate response data, including but not limited to: fault code, real-time data stream and ECU status information.

[0090] In the fifth step, the GW returns the response data to the diagnostic tool. For example, the ECU node sends the response data back to the GW, and then the GW converts the response data into an Ethernet DoIP message and sends it back to the remote diagnostic tool. In this process, the GW acts as an intermediary for data transmission, ensuring that the data can be correctly transmitted from the ECU node to the diagnostic tool.

[0091] The sixth step is to analyze and diagnose the response data through the diagnostic tool. For example, the technician uses the diagnostic tool to analyze the response data received from the ECU node to determine if there are any problems or abnormalities. Based on the analysis results, the technician can take further actions, such as clearing the fault code, adjusting the settings, or recommending the owner to send the vehicle to a repair shop for inspection and repair.

[0092] Step 7: Disconnect the diagnostic tool from the GW. After completing the diagnostic process, the technician will disconnect the GW from the diagnostic tool, for example, by shutting down the diagnostic tool or disconnecting the physical connection.

[0093] The monitoring system for automobile ECU node loss provided by the embodiment of the present application has the following technical effects: the display of ECU node loss is intuitive. The ECU node loss is displayed through a visual interface, and there is no need to correspond the fault code to the ECU node where the node loss occurs according to the protocol. By real-time monitoring of the operating status of the ECU node and visual analysis of a large amount of node loss information, the rules and trends in the data can be found, which helps to timely discover potential problems and avoid failures. By saving a large amount of node loss information in the database, it is convenient to replay all historical faults by time nodes when analyzing the problem, and view the node loss of each ECU at each moment. The loss of all ECU nodes can be viewed by accessing the URL of the visual interface, anywhere, without professional diagnostic equipment, wiring harnesses and professional diagnostic engineers. By managing the account permissions of the visual interface, different permissions are distributed to different personnel, which improves the security of node loss data. When a serious fault occurs in the vehicle, the monitoring system can notify the customer service personnel of the car company and professional emergency handling personnel to improve the response speed of fault diagnosis, especially when a serious fault occurs in the vehicle, such as braking, collision, etc., which affects the life safety of passengers, and can be discovered and responded to in the first time. The integrated remote diagnosis function enables remote diagnosis when checking the loss of ECU nodes, and troubleshoots and solves some problems.

[0094] The present application also provides a method for monitoring the loss of an automobile ECU node, which is suitable for detecting and monitoring the loss of each ECU node in the vehicle. Figure 5 , the method provided in this embodiment includes the following operations: S110. Obtain loss information of at least one ECU node in the vehicle.

[0095] S111. Store and count the lost information to obtain at least one data indicator.

[0096] S112. Visualize the data indicators.

[0097] Optionally, after acquiring loss information of at least one electronic control unit ECU node in the vehicle, if the ECU is currently in a sleep state, a self-upgrade state or a debugging state, the current loss information of the ECU node is filtered.

[0098] Optionally, storing the loss information includes: storing the loss information of each ECU at each moment through a time series database; playing back the loss information of each ECU at each moment through the time series database, for example, displaying the loss information of the ECU at each moment in chronological order.

[0099] Optionally, when acquiring the loss information of at least one electronic control unit ECU node in the vehicle, if a communication failure occurs in the CAN bus of the vehicle, the CAN bus status of the vehicle is acquired.

[0100] Optionally, after obtaining at least one data indicator, it also includes generating a fault report based on the lost information and sending the fault report to a designated terminal; if the ECU node type of the lost information meets the set requirements, an alarm is automatically sent to the designated terminal.

[0101] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this application can be executed in parallel, sequentially or in different orders, as long as the expected results of the technical solution disclosed in this application can be achieved, and this document is not limited here.

[0102] The above specific implementations do not constitute a limitation on the protection scope of this application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of this application should be included in the protection scope of this application.

Claims

1. A monitoring system for automobile ECU node loss, characterized in that: include: A gateway controller, used to obtain loss information of at least one electronic control unit ECU node in the vehicle, and upload the loss information to a server in real time; The server is used to store and count the loss information to obtain at least one data indicator; A visualization device is used to visualize the data indicators.

2. The system according to claim 1, characterized in that The lost information includes ECU identification, fault code, ECU status information and vehicle status information.

3. The system according to claim 1, characterized in that The server is used to filter the current loss information of the ECU node if the ECU is currently in a dormant state, a self-upgrade state or a debugging state.

4. The system according to claim 3, characterized in that When the server filters the current lost information of the ECU if the ECU is currently in a dormant state, a self-upgrade state or a debugging state, it is used to: Get the current sleep state of ECU through CAN bus; Obtain the current self-upgrade status and debugging status of the ECU through the ECU interface; Determine a valid flag bit according to the sleep state, self-upgrade state or debugging state; According to the validation flag, the current loss information of the ECU is filtered.

5. The system according to claim 1, characterized in that When storing the lost information, the server is used to: The loss information of each ECU at each moment is stored in the time series database; The lost information of each ECU at each moment is replayed through the timing database.

6. The system according to claim 1, characterized in that The gateway controller is further used for: If a communication failure occurs in the CAN bus of the vehicle, the CAN bus status of the vehicle is acquired and the CAN bus status is uploaded to the server.

7. The system according to claim 1, characterized in that The visualization device is also used for: Generate a fault report according to the loss information, and send the fault report to a designated terminal; If the ECU node type of the lost information meets the set requirements, an alarm is automatically sent to the designated terminal.

8. The system according to claim 7, characterized in that When sending the fault report to a designated terminal, the visualization device is used to: Determine the severity of the vehicle failure based on the fault code; Determining a method for sending the fault report according to the severity; The fault report is sent to a designated terminal according to the sending mode.

9. The system according to any one of claims 1 to 8, characterized in that: The gateway controller is connected to the server via Ethernet; wherein the gateway controller is used to obtain loss information of at least one electronic control unit ECU node in the vehicle, and upload the loss information to the server in real time via Ethernet; The system also includes a management device for managing the editing, viewing and management rights of different personnel on the visualization panel; and configuring the loss information that needs to trigger an automatic alarm.

10. A method for monitoring automobile ECU node loss, characterized in that: include: Obtaining loss information of at least one electronic control unit ECU node in the vehicle; Storing and counting the lost information to obtain at least one data indicator; The data indicators are displayed visually.

Images