CAN (Controller Area Network) message data flow direction visualization method, CAN message data flow direction visualization device and computer program product

Abstract

The invention relates to the technical field of automobile electronic communication, and provides a CAN message data flow direction visualization method and device and a computer program product, and the method comprises the steps: analyzing a database description file to obtain CAN message node information, and pre-constructing an electronic control unit mapping node based on the CAN message node information; analyzing the CAN message data file, and recording communication pair information of the CAN message based on the electronic control unit mapping node; determining electronic control units participating in communication and a center node with the maximum communication traffic according to the communication pair information, and determining a visual interface layout mode based on the number of the electronic control units; and according to the visual interface layout mode, the communication pair information and the central node, generating a visual animation representing the flow direction of the CAN message data. According to the method, abstract message data can be converted into visual animation demonstration, so that an engineer can visually check the flow direction of the message, error frame generation nodes are quickly positioned through highlight identifiers, and the efficiency of CAN network debugging and troubleshooting is remarkably improved.

Description

CAN message data flow visualization methods, devices, and computer program products Technical Field

[0001] This application relates to the field of automotive electronic communication technology, specifically to a method, device, and computer program product for visualizing the flow of CAN message data. Background Technology

[0002] Controller Area Network (CAN) is a fieldbus technology widely used in automotive electronics, industrial automation, aerospace, and marine industries. With its high reliability, real-time performance, and multi-master communication capabilities, CAN has become the core communication network for data exchange between Electronic Control Units (ECUs) in complex embedded systems. With the development of intelligent and connected vehicles, modern cars have evolved from traditional transportation tools into intelligent mobile terminals integrating various controllers. The number of ECUs integrated into vehicles is rapidly increasing, leading to massive and dense message traffic on the CAN network.

[0003] Currently, engineers primarily rely on traditional analysis tools such as PCAN-View when performing CAN message analysis. These tools typically only display raw message data in tabular form, simply listing CAN messages according to time sequence or message identifiers. When a vehicle system integrates dozens or even hundreds of ECUs, the amount of message data in the CAN network reaches massive levels, requiring engineers to manually search through dense data tables for each message. This presentation method cannot intuitively show the flow of messages between ECU nodes, nor can it quickly locate the source of communication anomalies or error frames.

[0004] Therefore, existing CAN message analysis technologies have clear limitations, namely, a lack of visualization techniques that can intuitively display the flow of CAN message data and quickly identify communication anomalies. When engineers need to trace the transmission path of specific messages, troubleshoot network faults, or analyze the points where error frames occur, they must manually sift and compare massive amounts of tabular data, which is inefficient and prone to missing crucial information. Developing an analysis method that can intuitively present the flow of CAN message data in the form of visual animation and efficiently locate the nodes where error frames occur has become an urgent technical problem to be solved. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, apparatus and electronic device for visualizing CAN message data flow, in order to solve the technical problems that traditional CAN message analysis tools cannot intuitively display message flow and are difficult to quickly locate communication anomalies.

[0006] A first aspect of this application provides a method for visualizing CAN message data flow, comprising: in one embodiment, parsing a database description file to obtain CAN message node information, including: loading a database description file in DBC format; and extracting the electronic control unit node name and the corresponding CAN message identifier from the database description file.

[0007] In one embodiment, parsing the CAN message data file, based on the communication pair information of the CAN messages recorded by the electronic control unit mapping node, includes: loading the CAN message data file, wherein the format of the CAN message data file includes at least one of TXT format, CSV format, or BLF format; parsing the messages in the CAN message data file according to the electronic control unit mapping node, identifying the sending node and receiving node of the message; recording the sending node and the receiving node as a communication pair, and caching the communication pair information.

[0008] In one embodiment, determining the layout of the visualization interface based on the number of electronic control units includes: counting the number of electronic control units participating in the communication; if the number of electronic control units is greater than a preset threshold, then a grid layout is adopted; if the number of electronic control units is less than or equal to the preset threshold, then a star-shaped layout centered on the central node is adopted.

[0009] In one embodiment, generating a visualization animation representing the flow of CAN message data includes: assigning different line colors to each communication pair; drawing the communication routes between each electronic control unit node according to the visualization interface layout; and displaying the flow of CAN message signals along the communication routes in animation form according to the timing of the CAN messages.

[0010] In one embodiment, before generating the visual animation representing the flow of CAN message data, the method further includes: selecting a target electronic control unit from the parsed electronic control units in response to a received filtering instruction; and displaying only other electronic control unit nodes that have a communication relationship with the target electronic control unit in the visual animation.

[0011] In one embodiment, generating a visual animation representing the flow of CAN message data further includes: detecting error frames in the CAN message data file; if the error frame is detected, displaying the location of the communication node corresponding to the error frame in the visual animation with a highlighted and flashing visual identifier.

[0012] In one embodiment, during the playback of the visual animation, the playback control operation is further performed in response to the user's playback control command, wherein the playback control operation includes at least one of pause, continue, reset, stop, and speed-up playback.

[0013] A second aspect of this application provides a CAN message data flow visualization device, comprising: a database parsing unit, configured to parse a database description file to obtain CAN message node information, and pre-construct an electronic control unit (ECU) mapping node based on the CAN message node information; a message parsing unit, configured to parse a CAN message data file, and record communication pair information of the CAN message based on the ECU mapping node; a layout determination unit, configured to determine the ECUs participating in the communication and the central node with the largest communication volume according to the communication pair information, and determine the visualization interface layout method based on the number of ECUs; and an animation generation unit, configured to generate a visualization animation representing the CAN message data flow according to the visualization interface layout method, the communication pair information, and the central node.

[0014] A third aspect of this application provides a vehicle including a CAN message data flow visualization device as provided in the second aspect of this application.

[0015] A fourth aspect of this application provides a computer program product including a computer program that, when run, causes the method described in the first aspect of this application to be performed.

[0016] The first aspect of this application provides a CAN message data flow visualization method that, by jointly parsing the DBC database description file and the CAN message data file, constructs an ECU node mapping relationship and records communication pair information. Then, it adaptively selects the layout method based on the number of ECUs, generating an intuitive visual animation to demonstrate the entire process of CAN message production, transmission, and consumption. This method transforms abstract message data into a visual animation demonstration, enabling engineers to intuitively view the message flow and quickly locate error frame generating nodes through highlighted markers, significantly improving the efficiency of CAN network debugging and fault diagnosis.

[0017] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 is a flowchart illustrating a CAN message data flow visualization method according to an embodiment of this application; Figure 2 is a flowchart illustrating a CAN message data flow visualization method according to another embodiment of this application; Figure 3 is a flowchart illustrating a CAN message data flow visualization method according to another embodiment of this application; Figure 4 is a flowchart illustrating a CAN message data flow visualization method according to another embodiment of this application; Figure 5 is a schematic diagram of a star-shaped layout visualization interface according to an embodiment of this application; Figure 6 is a structural schematic diagram of a CAN message data flow visualization device according to an embodiment of this application. Detailed Implementation

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0021] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0022] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0024] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0026] As shown in Figure 1, the CAN message data flow visualization method provided in this application embodiment includes the following steps S101 to S104: Step S101: Parse the database description file to obtain CAN message node information, and pre-build electronic control unit mapping nodes based on the CAN message node information.

[0027] Step S102: Parse the CAN message data file and record the communication pair information of the CAN message based on the electronic control unit mapping node.

[0028] Step S103: Determine the electronic control units participating in the communication and the central node with the largest communication volume based on the communication pair information, and determine the layout of the visualization interface based on the number of electronic control units.

[0029] Step S104: Generate a visual animation representing the flow of CAN message data based on the layout of the visualization interface, the communication pair information, and the central node.

[0030] In applications, parsing the database description file to obtain CAN message node information refers to reading the structured content of the CAN database file using a parser and extracting node definition information related to CAN communication. The database description file typically uses the DBC format, an industry-standard file format in the CAN communication field, used to describe each ECU node, message definition, signal definition, and their interrelationships in the CAN network. CAN message node information includes the name identifier of each ECU, the message identifier (Message ID) that the ECU is responsible for sending or receiving, and the signal definitions contained in the message. Pre-constructing an electronic control unit mapping node based on the obtained node information involves establishing a data structure in memory that maps each ECU to its associated message identifier, enabling quick subsequent lookups of which ECU sent or received a particular message. This mapping structure provides the foundational data support for subsequent message parsing and communication identification.

[0031] In applications, parsing CAN message data files refers to reading the actual acquired CAN bus communication log file, which records all message data transmitted by the CAN network within a specific time period. Message data files typically contain message timestamps, message identifiers, Data Length Codes (DLCs), and data field contents. Recording communication pair information based on the electronic control unit mapping node refers to using the mapping relationship constructed in step S101 to identify the sending ECU and receiving ECU for each message and recording this send-receive relationship as a communication pair. The recording of communication pair information employs a caching mechanism, storing all identified communication pairs in a memory structure for easy subsequent statistical analysis and visualization.

[0032] In application, determining the electronic control units (ECUs) participating in communication based on communication pair information involves traversing all recorded communication pairs and counting all ECU nodes appearing throughout the communication process. Identifying the central node with the highest communication volume involves counting the number of communication pairs each ECU participates in and identifying the ECU with the highest communication frequency as the network's central node, which will occupy a core position in the visualization layout. Determining the visualization interface layout based on the number of ECUs is an adaptive strategy; it selects the most suitable graphical layout algorithm based on the total number of participating ECUs to ensure the clarity and readability of the visualization interface.

[0033] In application, generating visual animations based on the layout of the visual interface, communication pairs, and central nodes refers to transforming abstract CAN message communication data into a graphical and dynamic display. First, the positions of each ECU node are bound on the interface according to the selected layout. Then, different line colors are assigned to different communication pairs for differentiation. Finally, according to the message's chronological order, the animation shows the process of the message signal flowing from the sending ECU along the communication route to the receiving ECU, realizing a visual presentation of the entire process of CAN message production, transmission, and consumption.

[0034] Specifically, taking a vehicle CAN network containing multiple ECUs such as the Body Control Module (BCM), Engine Control Module (ECM), Transmission Control Module (TCM), Instrument Panel Control Module (ICM), and Anti-lock Braking System (ABS) as an example, the process begins by loading the DBC file corresponding to the vehicle model. The parser identifies all ECU nodes defined in the file and their associated message IDs. For example, BCM sends message IDs from 0x100 to 0x10F, and ECM sends message IDs from 0x200 to 0x20F. Next, the CAN message log file collected from the vehicle is loaded. Each message record is traversed, and the sending ECU is found through a mapping table based on the message ID. The receiving ECU is then determined according to the signal receiver definition in the DBC, forming communication pairs such as BCM to ICM and ECM to TCM, which are then cached. A total of 5 ECUs participate in the communication, with the ECM having the most communication pairs, thus it is identified as the central node. As shown in Figure 5, since the number of ECUs is less than 6, a star-shaped layout is chosen, placing the ECM in the center of the interface, with the remaining ECUs evenly distributed around it. Finally, the animation is played in chronological order to observe the flow of message signals between nodes, providing a visual representation of the communication status of the entire CAN network.

[0035] The parsing of the database description file can employ regular expression-based text parsing to read and match key fields line by line, or it can use a dedicated DBC parsing library such as Python's cantools library for structured parsing. The generation of visual animations can utilize Canvas-based 2D graphics rendering technology, or a WebGL-based 3D visualization engine to achieve richer display effects.

[0036] This application's embodiments automate the mapping of CAN message nodes and the identification of communication pairs by jointly parsing the DBC database description file and the CAN message data file. This transforms the task of manually comparing data line by line in massive tables into an automated process. By adaptively selecting the layout method and generating visual animations, engineers can intuitively observe the flow of CAN messages in the network, avoiding the information overload problem of traditional table analysis methods and significantly improving the efficiency of CAN network analysis and debugging.

[0037] In one embodiment, step S101 includes the following steps S201 to S202: Step S201, Loading a database description file in DBC format.

[0038] Step S202: Extract the electronic control unit node name and the corresponding CAN message identifier from the database description file.

[0039] In applications, loading a DBC format database description file refers to reading the DBC file stored locally or on the network into memory for processing. The DBC file is the standard format for CAN databases, defined by Vector Systems, and has become a universal standard in the automotive electronics industry. The DBC file is stored in text format and contains multiple paragraphs such as VERSION, NS_, BS_, BU_, BO_, and SG_, which define version information, namespaces, baud rates, network nodes, messages, and signals, respectively. The loading process requires parsing according to the DBC file's syntax specifications to identify the start and end positions and content structure of each paragraph.

[0040] In applications, extracting the electronic control unit (ECU) node names and corresponding CAN message identifiers from the database description file involves parsing the BU_ and BO_ segments in the DBC file. The BU_ segment lists all ECU node names defined in the CAN network, such as BU_: BCM ECM TCM ICM ABS, indicating that the network contains five ECU nodes. The BO_ segment defines detailed information for each message, including the message identifier, message name, data length, and sending node, such as BO_ 256EngineStatus: 8 ECM, indicating that the message ID is 256 (decimal), the name is EngineStatus, the length is 8 bytes, and it is sent by an ECM node. By parsing this information, a mapping table between ECU nodes and message identifiers is established.

[0041] Specifically, assume the DBC file contains the following definitions: the BU_ segment defines three nodes: BCM, ECM, and TCM; the BO_ segment defines the message BO_ 0x100 DoorStatus: 8 BCM, BO_ 0x200 EngineRPM: 8 ECM, and BO_ 0x300 GearPosition: 4 TCM. The parser first reads the BU_ segment and stores the names of the three nodes BCM, ECM, and TCM in the node list. Then it reads the BO_ segment line by line, and for each message definition, it extracts the message ID (0x100, 0x200, 0x300) and the sending node (BCM, ECM, TCM) to establish a mapping relationship: BCM corresponds to 0x100, ECM corresponds to 0x200, and TCM corresponds to 0x300. This mapping table is stored in a hash structure in memory, supporting fast lookup with O(1) time complexity.

[0042] The loading of DBC files can be achieved by synchronously loading the file content into memory all at once, or by streaming and processing line by line to reduce memory usage. Extraction of ECU node information can be achieved by using a finite state machine method to parse the DBC syntax character by character, or by using parser generation tools such as ANTLR to automatically generate a parser after defining the DBC syntax.

[0043] A database description file in DBC format is used as the source of node information, leveraging mature standards in the automotive electronics industry to ensure compatibility with existing toolchains. By extracting the correspondence between node names and message identifiers, an accurate mapping foundation is provided for subsequent message parsing, giving the node names in the visualization results clear engineering meanings and facilitating engineers' quick understanding and problem localization.

[0044] In one embodiment, as shown in FIG2, step S102 includes the following steps S301 to S303: Step S301, loading a CAN message data file, wherein the format of the CAN message data file includes at least one of TXT format, CSV format or BLF format.

[0045] Step S302: Parse the messages in the CAN message data file according to the electronic control unit mapping node, and identify the sending node and receiving node of the message.

[0046] Step S303: Record the sending node and the receiving node as a communication pair, and cache the communication pair information.

[0047] In applications, loading CAN message data files refers to reading message recording files output by CAN analyzers, vehicle data loggers, or simulation tools. Different acquisition devices and software tools output data files in different formats. Common formats include: TXT format (plain text, one message per line, fields separated by spaces or tabs); CSV format (comma-separated values, easy to import into spreadsheet software for analysis); and BLF format (Binary Log Format defined by Vector, an industry standard for CAN data recording, characterized by high storage efficiency and complete information). The system needs to be compatible with these formats to adapt to data files from different sources.

[0048] In applications, parsing messages based on the electronic control unit (ECU) mapping node refers to using the mapping relationship established during the DBC parsing phase to determine the sender and receiver of each message. For each record in the message data file, the message identifier field is first extracted, and then the sending node corresponding to that identifier is looked up in the ECU mapping table. Identifying the receiving node requires combining the signal definitions in the DBC file. The signal definitions contain a list of signal receivers; parsing them determines which ECUs will receive the message. If a message may have multiple receivers, multiple communication pairs need to be generated and recorded separately.

[0049] In applications, recording and caching sending and receiving nodes as communication pairs involves establishing a data structure to store all identified send-receive relationships. The data structure for a communication pair typically includes the sender's ECU name, the receiver's ECU name, the corresponding message identifier, and a count of the number of times the communication pair appears. The purpose of the caching mechanism is to temporarily store the parsing results in memory, avoiding duplicate parsing, and providing a fast data source for subsequent statistical analysis and visualization rendering. The caching structure can be implemented using a hash table, with the sender-receiver strings as keys, ensuring that records of the same communication pair can be merged and counted.

[0050] Specifically, assume the CAN message data file uses CSV format, containing fields: timestamp, message ID, data length, and data content. The file records the following messages: timestamp 0.001 seconds, message ID 0x100; timestamp 0.002 seconds, message ID 0x200; timestamp 0.003 seconds, message ID 0x100. According to the DBC mapping, 0x100 is sent by the BCM and received by the ICM, and 0x200 is sent by the ECM and received by the TCM. The system reads the CSV file line by line. For the first record, it queries the mapping table to obtain the sender BCM and receiver ICM, creates a communication pair from BCM to ICM, and counts it as 1. The second record creates a communication pair from ECM to TCM, and counts it as 1. The third record is the same as the first, but the count for the communication pair from BCM to ICM increases to 2. Finally, the cache stores the two communication pairs and their frequencies.

[0051] The loading of multi-format files can employ a factory pattern to automatically select the corresponding parser based on the file extension, or a unified interface can be used to abstract the parsing logic for different formats. The caching of communication pairs can utilize in-memory hash tables for fast lookups and updates, or a database can be used for storage to support the persistence of large-scale data and complex queries.

[0052] Supporting multiple common CAN message data formats, this method is adaptable to acquisition devices and analysis tools from different manufacturers, improving its versatility and practicality. By automatically identifying sending and receiving nodes and recording communication pairs, it transforms massive amounts of message records into structured communication relationship data, laying the data foundation for visualization and avoiding the tedious work of manually analyzing message flow.

[0053] In one embodiment, as shown in FIG3, the step S103 of determining the layout of the visualization interface based on the number of electronic control units includes the following steps S401 to S403: Step S401, count the number of electronic control units participating in communication.

[0054] Step S402: If the number of electronic control units is greater than a preset threshold, a grid layout method is adopted.

[0055] Step S403: If the number of electronic control units is less than or equal to the preset threshold, a star-shaped layout centered on the central node is adopted.

[0056] In application, counting the number of electronic control units (ECUs) involved in communication involves traversing all communication pairs cached in step S102, extracting all unique ECU nodes, and calculating the total number. This statistical process requires removing duplicates to ensure that each ECU is counted only once. The statistical results directly influence the selection of subsequent layout methods and are a key input parameter for adaptive layout strategies.

[0057] In applications, if the number of electronic control units exceeds a preset threshold, a grid layout is adopted. This means that when there are a large number of ECUs participating in communication, a regular row and column arrangement is used to organize the node positions on the interface. The grid layout divides the visualization interface into uniform grid cells, with each ECU node occupying one grid position and maintaining equal spacing between nodes. This layout method can effectively utilize interface space and avoid nodes being too dense, causing overlap or occlusion, making it suitable for displaying complex CAN networks containing a large number of ECUs.

[0058] In applications, if the number of electronic control units (ECUs) is less than or equal to a preset threshold, a star topology centered on a central node is adopted. This means that when the number of ECUs participating in communication is small, the central node with the highest communication volume is placed in the center of the interface, and the remaining ECU nodes are evenly distributed on the circumference of the central node. The star topology clearly shows the communication relationship between the central node and each peripheral node, with the communication routes distributed radially. The visual effect is intuitive and aesthetically pleasing, making it suitable for displaying a typical CAN network topology centered on a core ECU.

[0059] Specifically, assuming that after the analysis in step S102, a total of 8 ECUs are counted from the communication pair cache to participate in the communication. Since 8 is greater than the preset threshold of 6, the system selects a grid layout. The interface width is set to 800 pixels and the height is set to 600 pixels, using a 3x3 grid, with each grid cell measuring approximately 267 x 200 pixels. The 8 ECU nodes are placed sequentially at the center of the grid cell, leaving one empty space. If the number of ECUs is 5, which is less than the threshold of 6, a star layout is selected, placing the ECU with the highest communication volume at the center of the interface at coordinates (400, 300), and the remaining 4 ECUs are evenly distributed at 90-degree intervals on a circle with a radius of 200 pixels, with coordinates (600, 300), (400, 500), (200, 300), and (400, 100), respectively.

[0060] The grid layout can be implemented using a coordinate calculation method based on row and column indices, or by using a force-directed graph algorithm to automatically optimize node spacing. The star layout can be implemented using a polar coordinate transformation method to calculate the position of each node, or by using a ring layout algorithm to support multi-layered nested star structures.

[0061] An adaptive layout strategy based on the number of ECUs is adopted, which can automatically select the most suitable visualization method according to the actual network size, avoiding the poor display effect caused by a fixed layout. The grid layout ensures a clear display of large-scale networks, while the star layout highlights the central position of core nodes. The combination of the two layout methods enables this approach to adapt to the analysis needs of CAN networks of varying complexity.

[0062] In one embodiment, the preset threshold is six electronic control units.

[0063] In this application, setting the preset threshold to six electronic control units (ECUs) is based on a comprehensive consideration of both the readability of the visual interface and the user experience. When the number of ECUs is no more than six, the star layout can clearly display each node and its communication lines on the standard display interface, without significant overlap or obstruction between nodes. When the six outer nodes are distributed on the circumference at 60-degree intervals, sufficient visual spacing is maintained between adjacent nodes, and communication routes can be clearly distinguished. When the number of ECUs exceeds six, the star layout can lead to overly dense nodes and increased intersections of communication lines. In this case, switching to a grid layout can better organize and display the network structure.

[0064] Specifically, taking a standard 1920x1080 resolution display as an example, the effective image binding area of ​​the visual interface is approximately 1600x900 pixels. In a star-shaped layout, the central node is located at (800, 450), and the outer nodes are distributed on a circle with a radius of 300 pixels. When there are 5 outer nodes, the arc length between adjacent nodes is approximately 377 pixels, providing ample display space for node icons and labels. When the number of outer nodes increases to 7, the arc length between adjacent nodes decreases to 269 pixels, and node labels begin to overlap. Therefore, using six ECUs as a threshold is a reasonable choice to maximize the advantages of the star-shaped layout while ensuring display clarity.

[0065] The preset threshold can be selected using an empirical method based on user test feedback, or an adaptive method based on dynamic calculation of interface resolution. Threshold parameters can be stored in a configuration file to support user customization, or they can be built-in program constants to simplify system design.

[0066] The threshold setting of six ECUs is well-suited for analyzing real-world vehicle CAN networks. Typical functional domain subnetworks (such as powertrain and chassis domains) usually contain 3 to 6 core ECUs, which can be clearly displayed using a star topology. For cross-domain network analysis at the vehicle level, the number of ECUs often exceeds ten. In this case, the network automatically switches to a grid layout to ensure effective visualization of large-scale networks.

[0067] In one embodiment, as shown in FIG4, the step S104 generates a visual animation representing the data flow of CAN messages, including the following steps S601 to S603: Step S601, assign different line colors to each communication pair.

[0068] Step S602: Bind the communication routes between each electronic control unit node according to the visual interface layout method.

[0069] Step S603: According to the timing of the CAN message, display the flow process of the CAN message signal along the communication route in the form of animation.

[0070] In applications, assigning different line colors to each communication pair means establishing a mapping relationship between the communication pair and color values, enabling users to quickly distinguish different communication paths by color. Color allocation strategies need to consider color discernibility, selecting high-contrast, easily distinguishable color combinations while avoiding overly similar colors that could cause confusion. Typical color allocation methods include uniform sampling according to the HSV color space and using predefined color palettes. Each communication pair corresponds to a fixed color, which remains consistent throughout the entire animation demonstration.

[0071] In applications, binding communication routes between electronic control unit (ECU) nodes according to the visual interface layout refers to binding the connections between node pairs that have communication relationships after determining the location of each ECU node. For a star topology, communication routes mainly connect the central node and the peripheral nodes radially; for a grid topology, communication routes may span multiple grid cells to form a crisscrossing network structure. The binding of routes needs to consider visual clarity and can use straight-line connections or Bézier curve connections. The latter can reduce visual clutter at route intersections through variations in curvature.

[0072] In applications, displaying the flow of CAN message signals along the communication route in animation according to the timing of the messages refers to triggering the animation effects of each message sequentially based on the timestamp information recorded in the message data file. Each message's animation is represented by a signal marker (such as a dot or a ball) moving from the sending node along the communication route to the receiving node; the duration of this movement can be adjusted according to the playback speed. By continuously playing the animations of multiple messages, a dynamic and visual display of the entire process of CAN message production, transmission, and consumption can be achieved.

[0073] Specifically, suppose the system needs to display the message flow of three communication pairs: BCM to ICM, ECM to TCM, and ABS to ICM. The color allocation module selects red (#FF0000), green (#00FF00), and blue (#0000FF) sequentially from a predefined color palette, corresponding to the three communication pairs respectively. On the star-shaped layout interface, ECM is the central node, with BCM, ICM, TCM, and ABS distributed around it. The system binds three communication routes: a red line from BCM to ICM, a green line from ECM to TCM, and a blue line from ABS to ICM. During animation playback, according to the message timestamp order, a red dot is first generated at the BCM node. The dot moves at a constant speed along the red route to the ICM node and disappears; then the green dot moves from ECM to TCM; and finally the blue dot moves from ABS to ICM. The entire animation loops, visually demonstrating the flow of messages in the network.

[0074] The allocation of line colors can employ a uniform sampling algorithm based on the HSV color space to ensure maximum color difference, or predefined color schemes such as the ColorBrewer palette can be used to ensure color harmony. Animation effects can be achieved using frame animation technology based on requestAnimationFrame, or smooth motion effects can be achieved using CSS transition animations or SVG SMIL animations.

[0075] By combining color coding and animation, abstract CAN message data is transformed into intuitive visual information, enabling engineers to quickly identify different communication paths and observe message flow. Animated displays, compared to static charts, more easily capture the timing relationships and frequency characteristics of communication, helping to identify abnormal communication patterns or potential network bottlenecks.

[0076] In one embodiment, before step S104, the following steps S701 to S702 are further included: Step S701: In response to the received filtering instruction, a target electronic control unit is selected from the parsed electronic control units.

[0077] Step S702: In the visualization animation, only other electronic control unit nodes that have a communication relationship with the target electronic control unit are displayed.

[0078] In application, selecting a target ECU from the parsed electronic control units in response to a received filtering command means the system provides an ECU filtering interface. Users can select one or more ECUs of interest as analysis targets from a list of identified ECUs. Filtering commands can be triggered interactively via drop-down menus, checkboxes, or list clicks. After selecting a target ECU, the system records the selection result for subsequent visualization and filtering processing. This function allows users to focus on the communication behavior analysis of a specific ECU, avoiding interference from irrelevant information.

[0079] In this application, displaying only other electronic control unit (ECU) nodes that communicate with the target ECU in the visualization animation means filtering the visualization content based on the user's selections. The system traverses the cached communication pair information, filters out all communication pairs containing the target ECU, and extracts all relevant ECU nodes (including the target ECU itself and its communication partners) from these communication pairs. When generating the visualization interface, only these relevant nodes and their communication routes are bound, while other nodes that do not communicate with the target ECU are hidden, thereby simplifying the interface and highlighting key points.

[0080] Specifically, assuming a CAN network contains seven ECUs (BCM, ECM, TCM, ICM, ABS, ESP, and EPS), the interface would be quite complex when fully displayed. The user wants to specifically analyze the communication behavior of the BCM, so they select BCM as the target in the ECU list in the filter bar. The system queries the communication pair cache and finds three communication pairs containing BCM: BCM to ICM, BCM to ESP, and ABS to BCM. Based on this, it is determined that only four nodes—BCM, ICM, ESP, and ABS—need to be displayed. The visualization interface is redesigned to only display these four nodes and their communication routes; the ECM, TCM, and EPS nodes are hidden. The animation also only shows the message flow related to BCM, allowing the user to focus on analyzing the BCM's communication status.

[0081] The ECU filtering interface can be implemented using a drop-down multi-select component to support multi-target filtering, or a search box with auto-completion to quickly locate a specific ECU. The layout update after filtering can use incremental redrawing to update only the changed nodes, or a full redrawing method to ensure layout consistency.

[0082] The ECU filtering function allows users to flexibly control the visualization scope according to their analysis needs. When faced with a complex vehicle network, it allows for a step-by-step approach, focusing on the communication analysis of specific ECUs. This function significantly enhances the tool's usability, enabling engineers to quickly switch from a macroscopic, overall network view to microscopic, single-point analysis, improving the targeting and efficiency of troubleshooting.

[0083] In one embodiment, generating a visual animation representing the flow of CAN message data in step S104 further includes the following steps S801 to S802: Step S801, detecting error frames in the CAN message data file.

[0084] Step S802: If the error frame is detected, the location of the communication node corresponding to the error frame is displayed in the visualization animation with a highlighted and flashing visual identifier.

[0085] In applications, detecting error frames in CAN message data files refers to identifying message entries marked as having an error status during message record parsing. The CAN protocol defines various error types, including bit errors, stuffing errors, CRC errors, format errors, and acknowledgment errors. These errors are detected and recorded by the CAN controller during message transmission. In the message data file, error frames are typically identified through special flag fields or message type fields; for example, in BLF format files, the ErrorFrame object type is used to record error frame information. When parsing the message file, the system needs to identify these error flags and extract the timestamps and associated information of the error frames.

[0086] In the application, if an error frame is detected, the location of the corresponding communication node is displayed as a highlighted, flashing visual marker in the visualization animation. This means that when the animation reaches the point where the error frame occurred, a prominent visual cue is displayed at the relevant ECU node. The highlighting and flashing effect is achieved by periodically changing the transparency or color of the marker element, with a flashing frequency typically set to 2 to 4 times per second to ensure user attention. The location of the visual marker corresponds to the ECU node associated with the error frame; this could be the node that sent the frame or the node that detected the error, depending on the information provided in the log file. This visual cue allows engineers to quickly locate the source of the error frame without having to search through tabular data line by line.

[0087] Specifically, suppose the CAN message data file records an error frame with a timestamp of 1.234 seconds, an error type of CRC checksum error, and an associated message ID of 0x200 (corresponding to a message sent by the ECM node). The system identifies this error frame and records its information during the parsing phase. When the visual animation reaches 1.234 seconds, the system overlays a red dot at the ECM node location, which flashes 3 times per second for 2 seconds. Simultaneously, the animation can be paused or slowed down, giving the user sufficient time to observe the error location. After the flashing ends, the red dot disappears or becomes a static marker, and the animation continues playing subsequent messages. If multiple error frames exist in the file, each error will trigger a corresponding highlight.

[0088] Error frame detection can be achieved through direct judgment based on the message type field, or through indirect inference based on error counter analysis. The highlight blinking effect can be implemented using a timer-based periodic change in transparency, or through CSS animation keyframes to achieve richer blinking styles.

[0089] One of the core values ​​of this method is the visual highlighting of error frames. It presents error information, originally hidden within massive amounts of message records, in a prominent manner, enabling engineers to pinpoint the problem at a glance. Compared to traditional table-based search methods, this intuitive fault location approach significantly improves the efficiency of CAN network debugging and troubleshooting, representing a crucial improvement over existing tools.

[0090] In one embodiment, the visual identifier is a flashing red dot.

[0091] In this application, using a flashing red dot as the visual identifier for error frames is based on considerations of human-computer interaction design and visual psychology. Red has a strong warning meaning in human visual perception and is a universal warning color in scenarios such as traffic signals, safety signs, and emergency prompts, quickly attracting the observer's attention. The dot's shape is simple and clear, avoiding confusion with other elements in the interface (such as node icons and communication routes), and it is clearly displayed in any layout. The flashing effect further enhances visual appeal; dynamically changing elements are more easily captured by the human eye than static elements, ensuring that error prompts are not ignored.

[0092] Specifically, the visual parameters for the red dot are set as follows: The dot diameter is 20 pixels to ensure clear visibility at standard resolution without excessively obscuring node information; the color value is pure red #FF0000 or a warning red with moderate saturation #E53935; the blinking period is 333 milliseconds, i.e., blinking 3 times per second, ensuring visibility while avoiding excessive blinking that could cause eye strain; the transparency range is 30% to 100%, giving the dot an alternating light and dark visual effect during blinking. The dot is positioned at the exact center of the incorrectly associated ECU node icon, ensuring the error location is clear and unambiguous.

[0093] The visual identifier's color can be chosen using different shades of red to suit various interface background colors, or user-defined color schemes can be used to meet specific needs. The blinking parameters of the dots can use fixed preset values ​​to ensure a consistent user experience, or configurable parameters can be used to allow users to adjust them according to their preferences.

[0094] The design of the red flashing dot follows general interface design guidelines, using a combination of color and dynamic effects to achieve efficient information delivery. This standardized visual language allows users to understand its meaning without learning, lowering the barrier to entry for the tool. At the same time, the simple dot form does not increase the visual burden of the interface, maintaining the overall clarity of the visual animation.

[0095] In one embodiment, during the playback of the visual animation, the playback control operation is further performed in response to the user's playback control command, wherein the playback control operation includes at least one of pause, continue, reset, stop, and speed-up playback.

[0096] In applications, responding to user playback control commands and executing corresponding playback control operations refers to the visual animation player providing a set of interactive controls that allow users to control the playback status of the animation in real time. Playback control commands are triggered by users clicking interface buttons, pressing keyboard shortcuts, or calling program interfaces. The pause operation freezes the animation at the current frame, maintaining the position and state of all elements, allowing users to carefully observe the network status at a particular moment. The resume operation resumes playback from the paused position. The reset operation reverts the animation to its starting state, clearing all played visual effects and preparing for a new round of playback. The stop operation terminates animation playback and closes the player or returns to the initial interface. The speed adjustment operation adjusts the playback speed of the animation, supporting acceleration (e.g., 2x, 4x) or deceleration (e.g., 0.5x) playback, allowing users to quickly browse long recordings or slowly analyze key moments.

[0097] Specifically, the bottom of the visual animation playback interface features a control bar containing the following controls: a pause / continue button with icons of double vertical lines (paused state) or a triangle (playing state), toggling between the two states; a reset button with an icon of a back arrow, returning the animation to its initial state at time 0; a stop button with an icon of a square, ending playback and returning to the file selection interface; and a speed selection dropdown menu offering speed options of 0.5x, 1x, 2x, and 4x, taking effect immediately upon selection. A playback progress bar displays the current playback position, allowing users to quickly jump to any point in time. For example, if a user is playing a 30-second CAN message record and detects an anomaly after 15 seconds, clicking the pause button freezes the screen, allowing for careful observation of each node's status; after confirming the problem, clicking continue resumes playback; if further observation is needed, clicking reset returns to the beginning; and if the analysis is complete, clicking stop exits playback.

[0098] The playback control function can be implemented using a state machine-based player architecture to manage the transitions between various playback states, or using an event-driven responsive design to decouple controls from animations. Playback speed adjustment can be achieved by adjusting the animation frame interval, or by adjusting the scaling factor of the message timestamp.

[0099] The comprehensive playback control features allow users to flexibly and independently manipulate the animation playback process, pausing, rewinding, or adjusting the speed at any time as needed for analysis. This interactivity is an indispensable feature of professional analysis tools, upgrading this method from a simple display tool to an operational analysis platform, significantly improving user experience and actual analysis efficiency.

[0100] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0101] This application also provides a CAN message data flow visualization device for performing the steps described in the above-described CAN message data flow visualization method embodiments. The CAN message data flow visualization device can be a virtual appliance within an electronic device, run by the electronic device's processor, or it can be the electronic device itself.

[0102] As shown in Figure 6, the CAN message data flow visualization device 100 provided in this embodiment includes: a database parsing unit 101, used to parse a database description file to obtain CAN message node information, and pre-construct electronic control unit mapping nodes based on the CAN message node information; a message parsing unit 102, used to parse a CAN message data file, and record the communication pair information of the CAN message based on the electronic control unit mapping nodes; a layout determination unit 103, used to determine the electronic control units participating in the communication and the central node with the largest communication volume according to the communication pair information, and determine the visualization interface layout method based on the number of electronic control units; and an animation generation unit 104, used to generate a visualization animation representing the CAN message data flow according to the visualization interface layout method, the communication pair information and the central node.

[0103] In applications, the modules in the CAN message data flow visualization device can be software program modules, or they can be implemented through different logic circuits integrated in the processor, or they can be implemented through multiple distributed processors.

[0104] This application also provides a vehicle, including the CAN message data flow visualization device provided in the above embodiments.

[0105] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0106] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0107] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps described in the various method embodiments above.

[0108] This application provides a computer program product, including a computer program, which, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0109] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / electronic device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0110] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0111] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0112] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0113] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0114] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for visualizing the data flow of CAN messages, characterized in that, include: Parse the database description file to obtain CAN message node information, and pre-construct electronic control unit mapping nodes based on the CAN message node information; The CAN message data file is parsed, and the communication pair information of the CAN message is recorded based on the electronic control unit mapping node. The electronic control units participating in the communication and the central node with the largest communication volume are determined according to the communication pair information, and the layout of the visualization interface is determined based on the number of electronic control units. Based on the layout of the visualization interface, the communication pair information and the central node, a visualization animation representing the flow of CAN message data is generated.

2. The CAN message data flow visualization method as described in claim 1, characterized in that, The process of parsing the database description file to obtain CAN message node information includes: loading a database description file in DBC format; and extracting the electronic control unit node name and the corresponding CAN message identifier from the database description file.

3. The CAN message data flow visualization method as described in claim 1, characterized in that, The parsing of the CAN message data file, based on the communication pair information of the CAN messages recorded by the electronic control unit mapping node, includes: loading the CAN message data file, wherein the format of the CAN message data file includes at least one of TXT format, CSV format, or BLF format; parsing the messages in the CAN message data file according to the electronic control unit mapping node, identifying the sending node and receiving node of the message; recording the sending node and the receiving node as a communication pair, and caching the communication pair information.

4. The CAN message data flow visualization method as described in claim 1, characterized in that, The method of determining the layout of the visualization interface based on the number of electronic control units includes: counting the number of electronic control units participating in communication; if the number of electronic control units is greater than a preset threshold, a grid layout is adopted; if the number of electronic control units is less than or equal to the preset threshold, a star layout centered on the central node is adopted.

5. The CAN message data flow visualization method as described in claim 1, characterized in that, The process of generating a visual animation representing the flow of CAN message data includes: assigning different line colors to each communication pair; drawing the communication routes between each electronic control unit node according to the layout of the visualization interface; and displaying the flow of CAN message signals along the communication routes in animation form according to the timing of the CAN messages.

6. The CAN message data flow visualization method as described in claim 1, characterized in that, Before generating the visualization animation representing the CAN message data flow, the method further includes: in response to the received filtering instruction, selecting a target electronic control unit from the parsed electronic control units; and displaying only other electronic control unit nodes that have a communication relationship with the target electronic control unit in the visualization animation.

7. The CAN message data flow visualization method as described in claim 1, characterized in that, The method of generating a visual animation representing the flow of CAN message data further includes: detecting error frames in the CAN message data file; if the error frame is detected, displaying the location of the communication node corresponding to the error frame in the visual animation with a highlighted and flashing visual identifier.

8. The CAN message data flow visualization method as described in claim 1, characterized in that, During the playback of the visual animation, the system also includes responding to the user's playback control command by executing a corresponding playback control operation, wherein the playback control operation includes at least one of pause, continue, reset, stop, and speed-up playback.

9. A CAN message data flow visualization device, characterized in that, include: The database parsing unit is used to parse the database description file to obtain CAN message node information, and pre-build electronic control unit mapping nodes based on the CAN message node information; The message parsing unit is used to parse the CAN message data file and record the communication pair information of the CAN message based on the electronic control unit mapping node; The layout determination unit is used to determine the electronic control units participating in the communication and the central node with the largest communication volume based on the communication pair information, and to determine the layout mode of the visualization interface based on the number of electronic control units; the animation generation unit is used to generate a visualization animation representing the flow direction of CAN message data based on the visualization interface layout mode, the communication pair information and the central node.

10. A computer program product, characterized in that, Includes a computer program, which, when run, causes the method as described in any one of claims 1-8 to be performed.

Images