Controller data display method and system

Abstract

The invention discloses a controller data display method and system. The method comprises the following steps: obtaining version reading results obtained by executing a version reading task by a plurality of electronic controllers (ECU) in a vehicle; under the condition that a first ECU node of the ECU network topology has child nodes, the connection state of a connection link where the first ECU node is located is determined according to the version reading result of the first ECU node and the version reading result of at least one child node, and the ECU network topology comprises the ECU node corresponding to each ECU and the connection link connected with the ECU node; the first ECU node is an ECU node corresponding to a first ECU, and the first ECU is any one of the multiple ECUs; according to the version reading result and the connection state, the display state of the first ECU node and the display state of the connection link where the first ECU node is located are updated. According to the scheme provided by the embodiment of the invention, the accuracy of the version reading result of the ECU in the ECU network topology can be improved, and a basis is provided for accurate positioning of the abnormal ECU.

Description

Technical Field

[0001] This application belongs to the technical field of vehicles, and particularly relates to a method and system for displaying controller data. Background Art

[0002] With the progress of technology and the development of society, the technical field of vehicles has gradually become diversified, laying a foundation for the development of vehicle electrification, networking, intelligence, and sharing. At present, the number of ECUs (Electronic Control Units) on vehicles is gradually increasing. How to accurately obtain and display the version reading results of the vehicle's ECUs is of great significance for accurately identifying abnormal ECUs. Summary of the Invention

[0003] Embodiments of this application provide a method and system for displaying controller data, which can improve the accuracy of the version reading results of ECUs in the ECU network topology and provide a basis for accurately locating abnormal ECUs.

[0004] In a first aspect, embodiments of this application provide a method for displaying controller data. The method includes: obtaining the version reading results obtained by multiple electronic control units (ECUs) in a vehicle when performing version reading tasks; when the first ECU node in the ECU network topology has at least one sub-node, determining the connection status of the connection link where the first ECU node is located according to the version reading result of the first ECU node and the version reading results of at least one sub-node, where the ECU network topology includes ECU nodes corresponding to each ECU and connection links connecting the ECU nodes, the first ECU node is the ECU node corresponding to the first ECU, and the first ECU is any one of the multiple ECUs; updating the display status of the first ECU node and the display status of the connection link where the first ECU node is located respectively according to the version reading result and the connection status.

[0005] In a second aspect, embodiments of this application provide a system for displaying controller data. The system includes: a server, configured to receive an ECU version reading instruction sent by a client, send an ECU version reading task to multiple ECUs, and return the version reading results fed back by the multiple ECUs to the client; a client, configured to receive the version reading results returned by the server and, using the method for displaying controller data as described in the first aspect, update and display the display status of the ECU node corresponding to each ECU in the ECU network topology and the display status of the connection link where the ECU node is located, where the ECU network topology includes ECU nodes corresponding to each ECU and connection links connecting the ECU nodes.

[0006] In a third aspect, an embodiment of the present application provides an electronic device, which includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the display method of the controller data as described in the first aspect is implemented.

[0007] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the display method of the controller data as described in the first aspect is implemented.

[0008] In a fifth aspect, an embodiment of the present application provides a computer program product. When the instructions in the computer program product are executed by the processor of an electronic device, the electronic device is caused to execute the display method of the controller data as described in the first aspect.

[0009] As can be seen from the above, in the embodiment of the present application, according to the version reading result of each ECU, the display state of the corresponding ECU node in the ECU network topology is shown, so that the version reading result of each ECU node can be determined through the ECU network topology, and the abnormal ECU nodes can be accurately located. In addition, in the embodiment of the present application, the ECU network topology can not only show the version reading result corresponding to each ECU, but also determine the display state of the connection link according to the version reading results of the ECU node and the sub-nodes of the ECU node. That is, in the embodiment of the present application, the ECU network topology can not only display the version reading result of each ECU, but also display the state of the connection link connected to the ECU node, thus making the positioning of abnormal ECUs more accurate. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required to be used in the embodiments of the present application. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative efforts.

[0011] Figure 1 is a schematic diagram of an ECU network topology provided by an embodiment of the present application;

[0012] Figure 2 is a timing diagram for constructing an ECU network topology provided by an embodiment of the present application;

[0013] Figure 3 is a timing diagram for reading an ECU version provided by an embodiment of the present application;

[0014] Figure 4 is an overall architecture diagram of the communication topology for reading an ECU version provided by an embodiment of the present application;

[0015] Figure 5 It is a schematic flowchart of a method for displaying controller data provided by an embodiment of the present application;

[0016] Figure 6 It is an overall flowchart of the communication topology for an ECU to read the version provided by an embodiment of the present application;

[0017] Figure 7 It is a schematic diagram of the communication topology architecture for an ECU to read the version provided by an embodiment of the present application;

[0018] Figure 8 It is a flowchart for an ECU network topology to display the version reading result provided by an embodiment of the present application;

[0019] Figure 9 It is an ECU network topology diagram provided by an embodiment of the present application;

[0020] Figure 10 It is a schematic diagram of the communication topology architecture based on a configuration file provided by an embodiment of the present application;

[0021] Figure 11 It is a schematic diagram of the weight of a communication topology domain provided by an embodiment of the present application;

[0022] Figure 12 It is a schematic diagram of the structure of an electronic device provided by another embodiment of the present application. Detailed implementation manners

[0023] The features and exemplary embodiments of various aspects of the present application will be described in detail below. To make the purpose, technical solutions and advantages of the present application clearer and more understandable, the present application will be further described in detail below in combination with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than limiting the present application. For those skilled in the art, the present application can be implemented without some of these specific details. The following description of the embodiments is only intended to provide a better understanding of the present application by showing examples of the present application.

[0024] It should be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising..." does not exclude the presence of additional identical elements in the process, method, article or device comprising the said element.

[0025] For ease of understanding, before explaining the solution provided by this application, the background of the solution provided by this application will be explained first.

[0026] With the progress of technology and the development of society, the vehicle technology field has gradually become diversified, laying a foundation for the development of vehicle electrification, networking, intelligence, and sharing. Currently, the vehicle networking industry is developing rapidly, and the ECU load of vehicles is also gradually increasing. Upgrading the installation version of the ECU enables the ECU to adapt to other components of the vehicle, thereby improving the performance of the vehicle. Therefore, reading the installation version of the ECU is an important task.

[0027] In practical applications, the cloud server can issue a version reading task to the vehicle-side T-BOX (Telematics BOX, in-vehicle electrical component) in the form of a task. After receiving the version reading task issued by the cloud server, the vehicle-side T-BOX makes a program call internally to read the installation version of the ECU under the current vehicle, so that the cloud server can decide whether to issue an upgrade package to the ECU and perform a flashing upgrade operation based on the ECU version data returned by the vehicle-side T-BOX.

[0028] Currently, for reading the version of the ECU, usually based on the establishment of communication between the server and the vehicle-side T-BOX, an ECU version reading task is created on the client side. After completing a series of operations, the ECU version reading task is sent to the server; after receiving it, the server obtains the data source (including data such as vehicle identification, ECU representation, task type, etc.) from the ECU version reading task, encrypts and verifies the signature of the data source, and sends the processed data source to the vehicle-side T-BOX, and then the T-BOX controls each ECU on the vehicle to execute the version reading task.

[0029] With the increasing complexity of business scenarios and the diversification of user requirements, problems such as how to construct a topology architecture diagram based on a configuration file matching the vehicle type, how to correctly match the version reading results reported by the vehicle end with the network topology, how to handle the display problems of topology nodes in three scenarios (successful version reading, failed version reading, not reported), and how to implement the granularity of topology lines in the network topology based on topology domain weights need to be urgently solved.

[0030] To solve the problems of the existing technology, the embodiments of the present application provide a method and a system for displaying controller data.

[0031] The embodiments of the present application provide a system for displaying controller data. The display system at least includes a server, a client, a database, and a vehicle end. Among them, the user can perform human-computer interaction with the client and send a version reading task to each ECU through the client.

[0032] Specifically, in the embodiments of the present application, the server can receive the ECU version reading instruction sent by the client, send the ECU version reading task to multiple ECUs, and return the version reading results fed back by the multiple ECUs to the client;

[0033] The client can receive the version reading results returned by the server and use the method for displaying controller data provided by the embodiments of the present application to update and display the display status of the ECU node corresponding to each ECU in the ECU network topology and the display status of the connection link where the ECU node is located, respectively.

[0034] In the above embodiment, the ECU network topology includes an ECU node corresponding to each ECU and a connection link connecting the ECU nodes. For example, in Figure 1 the shown ECU network topology, the T-BOX communicates with different ECUs through multiple gateways. Among them, the T-BOX issues commands and receives version reading results through the gateway GW1 with the VFC (Vehicle Front Controller) and multiple FRs (Front Radars) (such as Figure 1 FR1 and FR2 in); the T-BOX issues commands and receives version reading results through the gateway GW2 with the VMC (Vehicle Middle Controller) and multiple MRs (Middle Radars) (such as Figure 1 MR3 and MR4 in); the T-BOX issues commands and receives version reading results through the gateway GW3 with the VBC (Vehicle Back Controller) and multiple BRs (Back Radars) (such as Figure 1Commands are issued to BR5 and BR6 in it and the reception of the version reading result is carried out. That is, in Figure 1 VFC, VMC, VBC, FR1, FR2, MR3, MR4, BR5, and BR6 are the ECUs of the vehicle.

[0035] In addition, in the above embodiment, the version reading results corresponding to the ECUs include the following three types: the ECU does not read version data, the ECU version reading is successful, and the ECU version reading fails. Among them, when the ECU does not execute the version reading task, the message returned by the ECU to the gateway does not contain the identifier of the ECU, that is, the version reading result at this time is that the ECU does not read version data.

[0036] For different version reading results, they are displayed in different forms in the ECU network topology, such as using different colors to represent different version reading results. In Figure 1 In the shown ECU network topology, for example, if the version data of a certain ECU is successfully read, then in the ECU network topology, the topology node corresponding to the ECU is highlighted in the first color (such as green); if the version data of a certain ECU is read fails, then in the ECU network topology, the topology node corresponding to the ECU is highlighted in the second color (such as red); if a certain ECU does not report data, then in the ECU network topology, the topology node corresponding to the ECU is displayed in the third color (such as white).

[0037] For the display of the connection links connecting the ECU nodes, it is similar to the display of the ECU nodes, and no further examples will be given here.

[0038] It can be seen that by associating the version reading results of the ECUs with the display status of the nodes of the ECUs in the ECU network topology and presenting them in the client, the user can obtain the version reading results of each ECU in the vehicle through the client, view the version reading data, perform version upgrades or locate abnormal ECUs.

[0039] In one embodiment, the display system of the controller data further includes a database. Through the interaction between the client, the server, the database, and the vehicle-side T-BOX, the ECU network topology can be constructed.

[0040] Specifically, the database stores configuration files of multiple vehicle types. The configuration file at least includes the ECU identifiers of the ECUs included in the vehicle and the source nodes of the ECUs. The server can receive the file acquisition instruction issued by the client, determine the vehicle identifier of the vehicle, and obtain the target configuration file corresponding to the vehicle identifier from the database; then, the client obtains the target configuration file returned by the server, obtains the ECU identifiers and source nodes of the ECUs included in the vehicle from the target configuration file, and constructs the ECU network topology according to the ECU identifiers and source nodes of the ECUs.

[0041] The following uses Figure 2 the construction timing diagram of the ECU network topology shown as an example to introduce the construction of the ECU network topology. As Figure 2 shown, the interaction process of this timing diagram is as follows:

[0042] Step S20, the user performs a file acquisition operation on the client to cause the client to generate a file acquisition instruction;

[0043] Step S21, the client sends the file acquisition instruction to the server;

[0044] Step S22, the server obtains the vehicle identifier from the file acquisition instruction and queries the configuration file from the database through the vehicle identifier;

[0045] Step S23, the database queries the configuration file matching the vehicle identifier and returns the configuration file to the server;

[0046] Step S24, the server returns the configuration file to the client;

[0047] Step S25, the client obtains the ECU-related data from the configuration file, performs secondary processing on the ECU-related data in the configuration file to convert the ECU-related data in the configuration file into a data structure recognizable by the communication topology, and performs topology rendering on the converted data to obtain a network topology diagram;

[0048] Step S26, display the network topology diagram to the user.

[0049] The following uses Figure 3 the read timing diagram of the ECU version shown as an example to introduce the read process of the ECU version. As Figure 3 shown, the interaction process of this timing diagram is as follows:

[0050] Step S300, the user performs a task distribution operation on the client to cause the client to generate a task distribution instruction;

[0051] Step S301, the client sends the task distribution instruction to the server by means of a network request;

[0052] Step S302, the server obtains the data source from the task distribution instruction, performs processing such as splicing and encryption on the data source, and issues a version read task to the vehicle end in the form of a message;

[0053] Step S303, the vehicle end verifies the identity of the message header of the message corresponding to the version read task, and after successful matching, analyzes the content of the message body. Under the internal program of the vehicle end, the version of the ECU is read;

[0054] Step S304: Notify the server of the reading result (i.e., the status of version reading or failure) and the execution status (i.e., the status of whether the ECU executes the version reading task), that is, send the message processing result to the server in the form of a message.

[0055] Step S305: The server analyzes and processes the message containing the reading result and the execution status. For example, it discriminates the message header, and after successful matching, analyzes the corresponding message body content.

[0056] Step S306: The server sends the parsed data to the client via WebSocket. Here, WebSocket is a protocol for full-duplex communication over a single TCP (Transmission Control Protocol) connection.

[0057] Step S307: The server stores the parsed data in the database.

[0058] Step S308: The client performs ECU matching in the ECU network topology and feeds back the version reading result corresponding to each ECU in the ECU network topology, that is, presents the version reading result of the ECU in the corresponding ECU node in the ECU network topology through the ECU identifier. For example, if the version reading of a certain ECU is successful, the corresponding ECU node in the ECU network topology is highlighted in green; if the version reading of a certain ECU fails, the corresponding ECU node in the ECU network topology is highlighted in red; if the message corresponding to a certain ECU is not reported, the corresponding ECU node in the ECU network topology is displayed normally (for example, displayed in white).

[0059] Step S309: The client presents the ECU network topology to the user.

[0060] Step S310: The client returns the topology data of the ECU network topology to the server.

[0061] Step S311: The server stores the topology data in the server.

[0062] In one embodiment, Figure 4 shows the overall communication topology architecture diagram of ECU version reading. Among them, the modules of the overall communication architecture diagram are Figure 2 and Figure 3 shown in the Figure 1 time sequence. The difference is that Figure 4 the architecture diagram shown focuses on introducing the data flow during communication between modules, the processing mechanisms of each module, and the communication flow between modules at different stages. As Figure 4As shown, the overall architecture diagram of the communication topology is mainly divided into three stages: ① The communication flow of the communication topology architecture diagram based on the configuration file; ② The communication flow of the version reading task distribution; ③ The communication flow of the communication topology diagram based on ECU version reading (report message parsing). The following will introduce the above three stages respectively:

[0063] The first stage is the communication flow of the communication topology architecture diagram based on the configuration file. In this stage, it is mainly the communication interaction between the client and the server, and the server queries the database. The user issues a file acquisition operation through the client, the server queries the database, and returns the query result to the client in the form of a file stream. The client receives and parses it into a fileArray array. Each object in the fileArray array contains the following attributes: eucId (the unique primary key for the client to match and report the ECU under the network topology), ecuName (the node name in the network topology), source (the upper-level node of the current node), target (the current node), x, y (the position of the current node in the network topology), and size (the size of the current node). After the client obtains the above data, it processes and renders the obtained data to obtain the network topology as shown in Figure 1 the figure.

[0064] The second stage is the communication flow of the version reading task distribution. In this stage, it is mainly that the client issues a task request to the server, and the server splices and encrypts the data to be distributed under the task scheduling module and pushes the processed task data to the vehicle end; in addition, the server also stores the distributed task in the database. The internal program of the vehicle end decrypts and analyzes the task message content and performs the process of reading the version of the ECU.

[0065] The third stage is the communication flow of the communication topology diagram based on ECU version reading (report message parsing). In this stage, it is mainly that the vehicle end reports the ECU version reading result in the form of a message. After the server receives the reported message, it discriminates the message header. After successful discrimination, it analyzes the content of the message body. After successful analysis of the message body, the server stores the analysis result in task-service of the database and also sends the analysis result to the client through WebSocket. The client receives and parses it into a reportArray array. Each object in the reportArray array contains the following attributes (such as the topology matching and reporting ECU mechanism in Figure 4 the figure): reportEcuId (the unique identifier of the reported ECU to match the ECU node in the network topology), reportVersion (the version of the reported ECU reading), and errorReason (the abnormal reason for the failure of version reading).

[0066] Through the above three stages, the version reading results corresponding to the ECU can be displayed in the ECU network topology. Additionally, in Figure 4 In Figure 4 , in the ECU network topology, the connection lines connecting the ECU nodes are topology lines. In the embodiments of the present application, the display state of the topology line can be determined by the weights of the ECU nodes. In practical applications, the user can set whether to display the connection state between two ECUs through the topology line via the client. For example, the user can set it through the actived parameter.

[0067] So far, the introduction of the display system for controller data provided by the embodiments of the present application is completed. The following is the introduction of the display method for controller data provided by the embodiments of the present application in combination with the above display system and the working logic of the display system.

[0068] In the embodiments of the present application, the display method for controller data can be executed by the client. Figure 5 FIG. shows a schematic flowchart of the display method for controller data provided by an embodiment of the present application. As Figure 5 shown, the method includes the following steps S501 to step S503:

[0069] Step S501, obtain the version reading results obtained by multiple electronic control units (ECUs) in the vehicle when performing the version reading task.

[0070] In step S501, when the user needs to obtain the version data of the ECU in the vehicle, the client sends a version reading task for the vehicle's ECU to the server through the server. Thus, the ECU performs the version reading task, and returns the execution status and reading results of the version reading task to the client through the server. Among them, in the embodiments of the present application, the version reading results received by the client include the execution status and reading results of the version reading task, that is, the version reading results include whether the ECU sends a message, and the message data (including the data of failed version reading and the data of successful version reading).

[0071] Step S502, when the first ECU node in the ECU network topology has at least one child node, determine the connection state of the connection link where the first ECU node is located according to the version reading result of the first ECU node and the version reading results of at least one child node.

[0072] In step S502, the ECU network topology includes ECU nodes corresponding to each ECU and connection links connecting the ECU nodes. For example, in Figure 1 the shown ECU network topology, T-BOX, VFC, VMC, VBC, FR1, FR2, MR3, MR4, BR5, BR6 are all ECU nodes, and the topology line connecting any two ECUs is the connection link.

[0073] In step S502, the first ECU node is the ECU node corresponding to the first ECU, and the first ECU is any one of multiple ECUs.

[0074] In one embodiment, when the first ECU node has child nodes, it indicates that there is a connection relationship between the first ECU node and other ECU nodes. Therefore, it is necessary to obtain the connection status between these two ECU nodes. For example, when the first ECU node is a VFC node, the child nodes corresponding to the VFC node include FR1 and FR2; for another example, when the first ECU node is a T-BOX node, the child nodes corresponding to the T-BOX node include GW1, GW2, GW3, VFC, VMC, VBC, FR1, FR2, MR3, MR4, BR5, BR6.

[0075] In step S502, the client determines the display status of the ECU nodes corresponding in the ECU network topology according to the version reading status corresponding to each ECU. The client also determines the connection status of the connection links in the ECU network topology according to the version reading results of each ECU and the version reading results of the child nodes. For example, when the T-BOX successfully reads the version data, in the ECU network topology, the T-BOX node is highlighted in green; when the T-BOX does not read the version data, but it is detected that there are nodes that have read the version data among its corresponding multiple child nodes, then the version reading results of the nodes at the next level having a connection relationship with the T-BOX node will continue to be detected. For example, the GW1, GW2, and GW3 nodes are detected; if it is detected that GW1 does not read the version data, but it is detected that there are nodes that have read the version data among its corresponding multiple child nodes, then the connection link between the GW1 node and the T-BOX node is highlighted in green, indicating that the connection link between the GW1 node and the T-BOX node is in a conducting state.

[0076] Step S503, update the display status of the first ECU node and the display status of the connection link where the first ECU node is located respectively according to the version reading result and the connection status.

[0077] In step S503, after determining the version reading results of each ECU and the connection status of the connection links, it is displayed through the ECU network topology, so that the user can view the version reading results of each ECU through this ECU network topology, which is convenient for accurately locating abnormal ECU nodes.

[0078] Based on the solution defined in the above steps S501 to S503, it can be known that in the embodiment of the present application, the display status of the corresponding ECU node in the ECU network topology is shown according to the version reading result of each ECU, so that the version reading result of each ECU node can be determined through the ECU network topology, and the abnormal ECU nodes can be accurately located. In addition, in the embodiment of the present application, the ECU network topology not only shows the version reading result corresponding to each ECU, but also determines the display status of the connection link according to the version reading results of the ECU node and the sub-nodes of the ECU node. That is, in the embodiment of the present application, the ECU network topology can not only display the version reading result of each ECU, but also display the status of the connection link connected to the ECU node, so that the positioning of the abnormal ECU is more accurate.

[0079] The implementation process of the method provided by the embodiment of the present application will be introduced below.

[0080] In one embodiment, the client first needs to obtain the version reading results obtained by multiple electronic control units (ECUs) in the vehicle when performing the version reading task.

[0081] Specifically, the client responds to the ECU version reading instruction, sends the ECU version reading task to multiple ECUs through the server, so that the server controls the multiple ECUs to perform the version reading task; after the ECUs on the vehicle side complete the version reading task, the client receives the version reading results returned by the multiple ECUs through the server.

[0082] In one example, Figure 6 shows the overall communication topology flowchart for ECU version reading, as Figure 6 shown, the client obtains the configuration file, renders it into the ECU network topology, and stores the data in the configuration file and the data fileArray corresponding to the ECU network topology in Vuex. Among them, Vuex is a state management mode developed for Vue.js applications. It centrally stores and manages the states of all components of the application, and ensures that the states change in a predictable manner according to corresponding rules. In the embodiment of the present application, Vuex is deployed in the client, and the data in the configuration file matching the vehicle is temporarily stored in the client for subsequent matching with the message data reported by the vehicle side.

[0083] As Figure 6As shown, after the user issues a version reading task through the client, the vehicle terminal is in a state of waiting for task push until the vehicle terminal finishes executing the version reading task and then notifies the server to send a message. The server analyzes and reports the task result to the client through WebSocket. After the client obtains the task message result reportArray (including the task execution status and version reading data), it matches the topology data fileArray of the ECU network topology and the task message result reportArray with the ecuId as the unique identifier of the ECU. If the matching fails, it means that the ecuId in the topology nodes of the ECU network topology does not exist in the reported message, that is, the ECU node is not highlighted and is displayed using the default configuration; if the matching is successful and the ECU version reading is successful, the topology nodes in the ECU network topology are highlighted in green; if the matching fails and the ECU version reading fails, the topology nodes in the ECU network topology are highlighted in red.

[0084] Figure 7 shows a schematic diagram of the communication topology structure for ECU version reading. In Figure 7 Vuex stores the topology data read by the client from the configuration file, including information such as the ECU name and identifier of each ECU. This topology data is used for subsequent construction of the ECU network topology. For example, in Figure 7 VFC (ecuName: 'VFC', ecuId: '0xDF-8989') and TBOX (ecuName: 'TBOX, ecuId: '0xXX-XXXX') and other remaining node information ( Figure 7 represented by ellipsis in Figure 7 The data of the reported task message result contains the ECU identifier, version, and version reading result of each ECU version. For example, in

[0085] In the above example, two types of data sets, namely message data and topology data, are placed in the main function to perform the topology node matching and report the ECU mechanism and the read version result, thereby obtaining the following three results: The ecuId of node gateway GW1 is not in the reported message, that is, the version is not read, and the current node is in the default state; The ecuId of node VFC exists in the reported message, but the version reading fails, and the current node is in the red highlighted state. When the mouse is moved over this node, the client shows the user the reason for the version reading failure, "Component failure, unable to read version"; The ecuId of node TBOX exists in the reported message, and the version reading is successful. The current node is in the green highlighted state. When the mouse is moved over this node, the client shows the user the version number corresponding to this ECU, "1.0.0".

[0086] In one embodiment, after obtaining the version reading results obtained by multiple electronic control units (ECUs) in a vehicle performing version reading tasks, when the version reading result of the first ECU node indicates that the first ECU performs a version reading task, the client determines that the connection link connected to the first ECU node is in a connected state; when the version reading result of the first ECU node indicates that the first ECU does not perform a version reading task, it is detected whether the first ECU node has at least one child node; when the first ECU node does not have a child node, it is determined that the connection link between the first ECU node and the previous ECU node of the first ECU node is in a disconnected state; when there is a child node that performs a version reading task among at least one child node, it is determined that the connection link between the first ECU node and the previous ECU node of the first ECU node is in a connected state; when none of the at least one child node performs a version reading task, it is determined that the connection link between the first ECU node and the previous ECU node of the first ECU node is in a disconnected state.

[0087] In one example Figure 8 shows a flowchart of displaying the version reading result of the ECU network topology. In Figure 8 it, the client first determines whether the current node performs a version reading task, regardless of whether the version is successfully read; if the current node performs a version reading task, then in the ECU network topology, the connection link between the current node and the upper-level node is highlighted in green. If the current node does not perform a version reading task, that is, the current node does not report a message, the client executes the getChildrenNodes function, which can output all the descendant child nodes of the source node by inputting the source node. For example, for Figure 1For the network topology shown, when the source: GW1 is input to the getChildrenNodes function, the output of this function is [VFC, FR1, FR2]. If the current node has no child nodes, the connection link between the current node and the superior node is not highlighted (for example, shown in black); if the current node has child nodes and at least one child node has executed the version reading task (regardless of whether the version reading is successful), the connection link between the current node and the superior node is highlighted in green; otherwise, this connection link is not highlighted.

[0088] The following takes Figure 9 the ECU network topology shown as an example to introduce Figure 8 the process shown. In Figure 9 , taking the connection link TBOX - GW1 - VFC - FR1 / FR2 as an example, this connection link is divided into 6 link segments, and the status display for each link segment needs to be executed according to the Figure 8 process shown. The specific analysis process is as follows:

[0089] For link segment ①, input source: TBOX, output the child node set of TBOX [GW1, GW2, GW3, VFC, VMC, VBC, FR1, FR2, MR3, MR4, BR5, BR6], traverse the circular array in sequence, and if the child node FR2 reads the version successfully, then this link segment ① is highlighted in green ( Figure 9 shown by a dotted line in

[0090] For link segment ②, first determine whether the current node GW1 reads the version. If not, execute the getChildrenNodes function. By inputting source: GW1, output the child node set of GW1 [VFC, FR1, FR2]; if the child node FR2 reads the version successfully, then this link segment ② is highlighted in green.

[0091] For link segment ③, first determine whether the current node VFC reads the version. If not, execute the getChildrenNodes function. By inputting source: VFC, output the child node set of VFC [FR1, FR2]; if the child node FR2 reads the version successfully, then this link segment ③ is highlighted in green.

[0092] For link segment ④, execute the getChildrenNodes function. By inputting source: VFC, output the child node set of VFC [FR1, FR2]; if the child node FR2 reads the version successfully, then this link segment ④ is highlighted in green.

[0093] For link segment ⑤, first determine whether the current node FR1 has read the version. If not, execute the getChildrenNodes function. By inputting source: FR1, the set of child nodes of VFC, [], is output, that is, there is no descendant set, so this link segment ⑤ is not highlighted.

[0094] For link segment ⑥, first determine whether the current node FR2 has read the version. If the read is successful, this link segment ⑥ is highlighted in green.

[0095] It should be noted that the solution provided in the embodiments of the present application can visually display the version reading results corresponding to each ECU in the ECU network topology. For different types of vehicles, the number, type of ECUs included, and the communication connection relationships between each ECU are different. Therefore, before executing the solution provided in the embodiments of the present application, an ECU network topology matching the vehicle type needs to be rendered. Among them, for the same vehicle type, only the ECU network topology needs to be rendered once, and in subsequent use, it can be directly loaded.

[0096] In one embodiment, the client first obtains the vehicle identifier corresponding to the vehicle type of the vehicle, then reads the configuration file corresponding to the vehicle identifier through the server, and then renders the ECU network topology corresponding to the vehicle according to the configuration file.

[0097] In the above embodiment, the configuration file at least includes the ECU identifier of the ECUs included in the vehicle and the source node of the ECU.

[0098] After the client obtains the configuration file, it obtains the source node corresponding to each ECU from the configuration file, determines the connection relationships between multiple ECUs according to the source node corresponding to each ECU, and then connects multiple ECUs according to the connection relationships between multiple ECUs to obtain the ECU network topology.

[0099] In one example, take Figure 10 the schematic diagram of the communication topology architecture based on the configuration file shown as an example. First, obtain the configuration file from the database. For example, in Figure 7 , this configuration file includes the name of VFC, ecuId, source, target, x, y, size, etc. The client processes the data in the configuration file to obtain topology data, and stores the topology data in Vuex for subsequent comparison and reporting of the ECU of the message; in addition, the client also uses a rendering tool (for example, G6) to render the topology data into the client and present the ECU network topology as shown in Figure 10 .

[0100] Such as Figure 10As shown, the T-BOX, as an in-vehicle communication terminal, is an important part of the Internet of Vehicles. In Figure 10 In the ECU network topology shown, three network gateway nodes are set, namely gateway GW1, gateway GW2, and gateway GW3, which respectively carry the communication between the vehicle front controller VFC and the front radar FR1, front radar FR2, the communication between the vehicle middle controller VMC and the middle radar MR3, middle radar MR4, and the communication between the vehicle rear controller VBC and the rear radar BR5, rear radar BR6.

[0101] In addition, in Figure 10 , the hierarchical division of the ECU network topology is based on the source and target attributes of each ECU node in the configuration file. For example, in Figure 10 , the relationship between the GW1 and VFC nodes is as follows: the source of node GW1: ’TBOX’, target: ‘GW1’, that is, the GW1 node is a child node of TBOX; the source of node VFC: ’GW1’, target: ’VFC’, that is, VFC is a child node of GW1.

[0102] Furthermore, in Figure 10 , the position of the topology node VFC in the network topology is determined by the x value and y value, and the node size of VFC is determined by size. After reading the configuration file, the client maps the display status corresponding to the version reading result of the corresponding ECU node according to the ecuId to the ECU network topology.

[0103] It should be noted that in the above embodiment, the node weight of the previous ECU node is less than the node weight of the first ECU node. Here, the node weight of the ECU node is used to represent the level of the ECU node in the ECU network topology, and the node weight can be positively correlated with the level, that is, the deeper the level, the greater the node weight.

[0104] In one embodiment, after rendering the ECU network topology corresponding to the vehicle according to the configuration file, the client divides the ECU network topology into multiple levels according to the control relationship between multiple ECUs. Among them, the ECUs located in the same level have the same node weight.

[0105] In one example, Figure 11 shows the weight of the communication topology domain. In Figure 11 , the display status of the topology node represents the result of the ECU reading version; the display status of the topology line represents the communication status between nodes. The black solid line indicates that the communication between nodes is in a disconnected state; the black dashed line indicates that the communication between nodes is in a connected state (regardless of whether the version reading is successful or failed, the current link is in a connected state).

[0106] The topological domain weights increase in level from top to bottom. The first level: TBOX; the second level: GW1, GW2, GW3; the third level: VFC, VMC, VBC; the fourth level: FR1, FR2, MR3, MR4, BR5, BR6.

[0107] It should be noted that by setting the topological domain weights and drawing the topological lines based on whether the ECU with the highest weight level reads the version, the logical complexity of the node status display in the ECU network topology can be reduced, thereby improving the real-time performance and efficiency of the ECU network topology display.

[0108] When the first ECU executes the version reading task and the node weight corresponding to the first ECU node is greater than the node weight corresponding to the second ECU node, the connection status of the connection link between the first ECU node and the second ECU node is determined to be the connected state, where the first ECU node is the child node of the second ECU node.

[0109] Take Figure 11 the communication link of TBOX-GW1-VFC-FR2 in as an example. The weight of FR2 is the fourth-level weight (the highest level). Currently, FR2 has successfully read the version, proving that the network communication of the entire link is normal, that is, the entire link status of TBOX-GW1-VFC-FR2 is in the conducting state.

[0110] So far, the introduction of the method provided by the embodiments of the present application is completed.

[0111] As can be seen from the above, the solution provided by the embodiments of the present application can realize the visual display of the communication topology of ECU version reading, and can intuitively show the user the topology in two scenarios: the ECU version read successfully reported by the vehicle end and the error reason for the read failure, providing a convenient, efficient, and accurate visualization method to help users quickly locate and diagnose the problem source of the fault. In addition, in the embodiments of the present application, the development of the topological line granularity based on the topological domain weights can also be realized, so as to better help users troubleshoot and locate the problems of the ECU itself, greatly reducing the failure rate of reading the ECU version.

[0112] Figure 12 The schematic hardware structure diagram of the electronic device provided by the embodiments of the present application is shown.

[0113] The electronic device may include a processor 1201 and a memory 1202 storing computer program instructions.

[0114] Specifically, the above-mentioned processor 1201 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured as one or more integrated circuits for implementing the embodiments of the present application.

[0115] The memory 1202 may include a mass memory for data or instructions. By way of example and not limitation, the memory 1202 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disc, a magneto-optical disc, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. In a suitable case, the memory 1202 may include a removable or non-removable (or fixed) medium. In a suitable case, the memory 1202 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 1202 is a non-volatile solid state memory.

[0116] The memory may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage media device, an optical storage media device, a flash memory device, an electrical, optical, or other physical / tangible memory storage device. Thus, generally, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described in reference to the method according to an aspect of the present disclosure.

[0117] The processor 1201 reads and executes the computer program instructions stored in the memory 1202 to implement any one of the controller data display methods in the above embodiments.

[0118] In one example, the electronic device may further include a communication interface 1203 and a bus 1210. Among them, as Figure 12 shown, the processor 1201, the memory 1202, and the communication interface 1203 are connected through the bus 1210 and complete communication with each other.

[0119] The communication interface 1203 is mainly used to implement communication between various modules, devices, units, and / or devices in the embodiments of the present application.

[0120] Bus 1210 includes hardware, software, or both, and couples components of an electronic device to each other. By way of example and not limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a MicroChannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable bus or a combination of two or more of these. Where appropriate, bus 1210 may include one or more buses. Although embodiments of the present application describe and illustrate specific buses, the present application contemplates any suitable bus or interconnect.

[0121] In addition, in combination with the method for displaying controller data in the above embodiments, embodiments of the present application can be implemented by providing a computer-readable storage medium. Computer program instructions are stored on the computer-readable storage medium; when the computer program instructions are executed by a processor, any one of the methods for displaying controller data in the above embodiments is implemented.

[0122] In addition, in combination with the method for displaying controller data in the above embodiments, embodiments of the present application can be implemented by providing a computer program product. When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device is caused to execute any one of the methods for displaying controller data as in the above embodiments.

[0123] It should be clear that the present application is not limited to the specific configurations and processes described above and illustrated in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and illustrated as examples. However, the method process of the present application is not limited to the specific steps described and illustrated, and those skilled in the art can make various changes, modifications, and additions, or change the order between steps after understanding the spirit of the present application.

[0124] The functional modules shown in the above structural block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a functional card, and so on. When implemented in software, the elements of the present application are programs or code segments for performing the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted via a data signal carried in a carrier wave over a transmission medium or a communication link. A "machine-readable medium" can include any medium that can store or transmit information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical discs, hard disks, fiber optic media, radio frequency (RF) links, and so on. The code segment can be downloaded via a computer network such as the Internet, an intranet, and so on.

[0125] It should also be noted that the exemplary embodiments mentioned in the present application describe some methods or systems based on a series of steps or devices. However, the present application is not limited to the order of the above steps, that is, the steps can be executed in the order mentioned in the embodiments, or different from the order in the embodiments, or several steps can be executed simultaneously.

[0126] Aspects of the present disclosure have been described above with reference to the flowcharts and / or block diagrams of the method and system for displaying controller data according to embodiments of the present disclosure. It should be understood that each block in the flowcharts and / or block diagrams, and the combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the functions / actions specified in one or more blocks of the flowcharts and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field programmable logic circuit. It can also be understood that each block in the block diagrams and / or flowcharts, and the combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware for performing the specified functions or actions, or by a combination of dedicated hardware and computer instructions.

[0127] As described above, this is only the specific implementation manner of the present application. Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, modules, and units described above can refer to the corresponding processes in the foregoing method embodiments, and will not be elaborated herein. It should be understood that the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present application can easily think of various equivalent modifications or substitutions, and these modifications or substitutions should all be covered within the protection scope of the present application.

Claims

1. A method for displaying controller data, characterized in that: include: Obtaining version reading results obtained by executing version reading tasks by multiple electronic controllers ECU in the vehicle; In a case where a first ECU node in an ECU network topology has at least one child node, determining a connection state of a connection link where the first ECU node is located according to a version reading result of the first ECU node and a version reading result of at least one of the child nodes, wherein the ECU network topology includes ECU nodes corresponding to each of the ECUs and connection links connecting the ECU nodes, the first ECU node is an ECU node corresponding to the first ECU, and the first ECU is any one of the plurality of ECUs; According to the version reading result and the connection status, the display status of the first ECU node and the display status of the connection link where the first ECU node is located are updated respectively.

2. The method according to claim 1, characterized in that Obtain the version reading results obtained by executing the version reading task on multiple electronic controllers (ECUs) in the vehicle, including: In response to the ECU version reading instruction, the server sends an ECU version reading task to the plurality of ECUs, so that the server controls the plurality of ECUs to execute the version reading task; Receive version reading results returned by the plurality of ECUs through the server.

3. The method according to claim 1, characterized in that After obtaining version reading results obtained by executing version reading tasks by multiple electronic controllers ECU in the vehicle, the method further includes: When the version reading result of the first ECU node indicates that the first ECU executes the version reading task, determining that the connection link connected to the first ECU node is in a connected state; If the version reading result of the first ECU node indicates that the first ECU has not executed the version reading task, detecting whether the first ECU node has at least one of the child nodes; In a case where the first ECU node does not have the child node, it is determined that a connection link between the first ECU node and an upper ECU node of the first ECU node is in a disconnected state.

4. The method according to claim 3, characterized in that Determining, according to a version reading result of the first ECU node and a version reading result of at least one of the child nodes, a connection state of a connection link where the first ECU node is located, including: When there is a child node that performs the version reading task in at least one of the child nodes, determining that a connection link between the first ECU node and an ECU node previous to the first ECU node is in a connected state, wherein a node weight of the previous ECU node is less than a node weight of the first ECU node; When the version reading task is not executed in at least one of the child nodes, it is determined that a connection link between the first ECU node and an upper ECU node of the first ECU node is in a disconnected state.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: Obtaining a vehicle identification corresponding to the vehicle type of the vehicle; Reading a configuration file corresponding to the vehicle identifier through a server, wherein the configuration file includes at least an ECU identifier of an ECU included in the vehicle and a source node of the ECU; Rendering an ECU network topology corresponding to the vehicle according to the configuration file.

6. The method according to claim 5, characterized in that Rendering an ECU network topology corresponding to the vehicle according to the configuration file includes: Determining a connection relationship between the plurality of ECUs according to a source node corresponding to each ECU; According to the connection relationship between the multiple ECUs, the multiple ECUs are connected to obtain the ECU network topology.

7. The method according to claim 5, characterized in that After rendering the ECU network topology corresponding to the vehicle according to the configuration file, the method further includes: According to the control relationship between the multiple ECUs, the ECU network topology is divided into multiple levels, wherein ECUs at the same level have the same node weight.

8. The method according to claim 7, characterized in that The method further comprises: When the first ECU executes the version reading task and the node weight corresponding to the first ECU node is greater than the node weight corresponding to the second ECU node, the connection state of the connection link between the first ECU node and the second ECU node is determined to be a connected state, wherein the first ECU node is a child node of the second ECU node.

9. A controller data display system, characterized in that: include: The server is configured to receive an ECU version reading instruction sent by a client, issue an ECU version reading task to multiple ECUs, and return the version reading results fed back by the multiple ECUs to the client; The client is used to receive the version reading result returned by the server, and adopt the method described in any one of claims 1 to 8 to update and display the display status of the ECU node corresponding to each ECU in the ECU network topology and the display status of the connection link where the ECU node is located, wherein the ECU network topology includes the ECU node corresponding to each ECU and the connection link connecting the ECU nodes.

10. The system according to claim 9, characterized in that The system further comprises: A database for storing profiles of multiple vehicle types; The server is further configured to receive a file acquisition instruction issued by the client, determine the vehicle identification of the vehicle, and acquire a target configuration file corresponding to the vehicle identification from the database; The client is further configured to obtain a target configuration file returned by the server, obtain the ECU identifiers and source nodes of the ECUs included in the vehicle from the target configuration file, and construct the ECU network topology based on the ECU identifiers and source nodes of the ECUs.

Images