Monitoring device, method and apparatus

Abstract

The embodiment of the present application relates to the technical field of vehicles, and discloses a monitoring device, method and equipment, the monitoring device is arranged in a removable storage device, the monitoring device comprises a processing module, a monitoring module and a storage module; the processing module is in communication connection with the monitoring module and the storage module respectively; the processing module is used for: under the condition that a first condition is met, sending a monitoring instruction to the monitoring module, so that the monitoring module acquires and returns CAN bus data of a target domain controller in response to the monitoring instruction; wherein the first condition is used to indicate that the removable storage device is plugged into the target domain controller with a display interface, and the monitoring device is started; and forwarding the CAN bus data to the storage module, so that the storage module converts the CAN bus data into a DDS message for storage. Thus, the present application can realize plug-and-play monitoring without special diagnostic hardware, and reduces deployment cost and equipment dependence.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more particularly to the field of vehicle fault handling technology, specifically to a monitoring device, method, and equipment. Background Technology

[0002] As the electronic and electrical architecture of new energy vehicles becomes increasingly complex and the number of vehicle controllers continues to increase, the debugging and testing work during the R&D phase places higher demands on diagnostic tools. R&D engineers need to monitor Controller Area Network (CAN) bus signals in real time, read fault codes, analyze communication status, and view data when a fault occurs or review historical data after a fault occurs.

[0003] However, these technologies primarily rely on dedicated acquisition equipment to collect fault codes and real-time data, resulting in strong hardware dependence, high equipment costs, the need for cabling, and reduced work efficiency. Therefore, these technologies suffer from inconvenient hardware deployment and outdated interaction methods in R&D diagnostic scenarios, necessitating an effective method for fault monitoring and handling. Summary of the Invention

[0004] This application provides a monitoring device, method, and equipment to at least address the technical problems of inconvenient hardware deployment and outdated interaction methods in R&D diagnostic scenarios. The technical solution adopted in this application is as follows: In a first aspect, this application provides a monitoring device deployed on a removable storage device. The monitoring device includes: a processing module, a monitoring module, and a storage module. The processing module is communicatively connected to both the monitoring module and the storage module. The processing module is configured to: send a monitoring command to the monitoring module when a first condition is met, so that the monitoring module responds to the monitoring command by collecting and returning CAN bus data from a target domain controller; wherein the first condition is used to instruct the removable storage device to be plugged into a target domain controller with a display interface and the monitoring device to be started; and forward the CAN bus data to the storage module, so that the storage module converts the CAN bus data into DDS messages for storage.

[0005] Based on the aforementioned technical means, this application can deploy a monitoring device using a removable storage device, interacting with the target domain controller's own display interface. After the device is connected and started, it automatically collects CAN bus data from the target domain controller and converts the data into DDS message storage, achieving plug-and-play monitoring without dedicated diagnostic hardware, reducing deployment costs and device dependence. Furthermore, the structured storage in DDS format improves data organization efficiency, facilitating subsequent rapid retrieval and functional-level correlation analysis. Simultaneously, relying on the domain controller's local resources for data acquisition and processing avoids additional wiring and external device intervention, improving deployment flexibility and real-time data acquisition during the R&D and testing phases.

[0006] In one possible implementation, the monitoring device further includes an interaction module and an export module; a processing module, communicatively connected to both the interaction module and the export module; a storage module, communicatively connected to the export module; the processing module is further configured to: determine the target CAN bus data to be exported in response to a first export command sent by the interaction module; issue a second export command to the export module; the second export command is used to instruct the export of the target CAN bus data; the export module is configured to retrieve the target DDS message from the storage module in response to the second export command; restore the DDS message to the target CAN bus data; and return the target CAN bus data to the processing module; the processing module is further configured to: return the target CAN bus data to the interaction module for display.

[0007] Based on the above technical means, this application receives export instructions through an interactive module, the processing module determines the target data and drives the export module to retrieve the corresponding DDS message from storage, and after restoring it to the original CAN bus data, it returns it to the interactive module for display. It can directly complete the accurate extraction, format restoration and visualization of historical data on the domain controller without relying on external professional analysis tools, simplifying the operation process of fault diagnosis and data analysis, and improving the immediacy and convenience of problem location in the R&D and testing phase.

[0008] In one possible implementation, the DDS message carries a collection timestamp; the storage module retains DDS messages whose collection timestamp is within the most recent preset time period; the first export instruction is used to indicate the export time period; the export time period is a time period within the storage time period; the processing module is specifically used to: determine the CAN bus data within the export time period as the target CAN bus data.

[0009] Based on the aforementioned technical means, this application can efficiently reuse key historical data within limited storage space by carrying a collection timestamp in the DDS message and using a storage module to retain only data within the most recent preset time period, combined with the specific time period specified in the export command. Simultaneously, it supports the precise extraction of CAN bus data within a specific time window as needed. This avoids the storage pressure caused by unlimited data accumulation while ensuring the traceability of data in case of occasional failures or critical testing scenarios, thus improving the economy of data management and the targeted nature of the analysis process.

[0010] In one possible implementation, the CAN bus data includes the signal values ​​of at least one monitoring signal emitted by the controller in the target domain controller; one monitoring signal corresponds to one signal name; the first derived instruction is also used to indicate the target function; the monitoring device further includes a linkage monitoring module; the processing module is communicatively connected to the linkage monitoring module; the processing module is specifically used to: send the target function to the linkage monitoring module so that the linkage monitoring module returns the associated signal names that have a mapping relationship with the target function in the mapping relationship set; wherein, the mapping relationship set is used to characterize the correspondence between the signal name and the function; and determine the CAN bus data corresponding to the associated signal names within the derived time period as the target CAN bus data.

[0011] Based on the aforementioned technical means, this application introduces a mapping relationship set between functions and signal names, and automatically parses the signal names associated with the target function using a linkage monitoring module. This elevates the exported instructions from a single signal level to a functional logic level, enabling the automatic aggregation of relevant CAN bus data based on business intent, eliminating the need for manual retrieval and piecing together of scattered signals. Furthermore, it significantly simplifies the operation process of cross-signal correlation analysis, improving the efficiency and accuracy of data backtracking and problem troubleshooting for specific functions.

[0012] In one possible implementation, the monitoring device further includes a diagnostic module; a processing module is communicatively connected to the diagnostic module; the processing module is further configured to forward a first diagnostic instruction sent by the interaction module to the diagnostic module in response to the first diagnostic instruction; the first diagnostic instruction is used to instruct the generation of a fault code list using CAN bus data; wherein, the CAN bus data includes the signal value of at least one monitoring signal emitted by the controller in the target domain controller, fault flag status information, and communication status; the fault code includes a fault code number, a fault description indicating the fault, the fault occurrence time, the fault severity level, and fault-related signals; the diagnostic module is configured to generate and return a fault code list to the processing module in response to the first diagnostic instruction; the processing module is further configured to return the fault code list to the interaction module for display.

[0013] Based on the aforementioned technical means, this application triggers diagnostic commands through an interactive module. The diagnostic module then parses CAN bus data containing signal values, fault flags, and communication status, automatically generating a structured fault code list covering fault number, description, occurrence time, severity level, and associated signals. This list is then presented intuitively through the interactive module. This allows for the automated extraction and visualization of multi-dimensional fault information locally, without relying on external professional diagnostic equipment. Consequently, it simplifies the fault diagnosis process and improves the timeliness and completeness of problem location during the R&D and testing phases.

[0014] In one possible implementation, when displaying the fault code list, the interaction module displays a report generation control and a fault code clearing control corresponding to each fault code in the fault code list; the processing module is further configured to: forward a second diagnostic instruction to the diagnostic module in response to a second diagnostic instruction; wherein the second diagnostic instruction is issued by the interaction module to the processing module when the report generation control is triggered, and is used to instruct the generation of a diagnostic report using candidate fault codes that have not been triggered by the fault code clearing control; the diagnostic module is further configured to generate and return a diagnostic report to the processing module in response to the second diagnostic instruction; wherein the diagnostic report includes candidate fault codes and troubleshooting suggestions; the processing module is further configured to return the diagnostic report to the interaction module for display.

[0015] Based on the aforementioned technical means, this application can integrate a report generation control and a separate clearing control for each fault code into the fault code list interface, allowing users to flexibly filter and exclude processed or non-interested items, and generate customized diagnostic reports containing troubleshooting suggestions only for candidate fault codes that have not been cleared. This enables the automated transformation from raw fault information to executable maintenance solutions, reduces the workload of manual sorting and repetitive analysis, and improves the pertinence of fault handling and the efficiency of operation and maintenance decisions.

[0016] In one possible implementation, the monitoring device further includes a log acquisition module; a processing module is communicatively connected to the log acquisition module; the processing module is also configured to: send a log acquisition instruction to the log acquisition module in response to a log export instruction sent by the interaction module; wherein the log export instruction is used to indicate the log export time period; the log acquisition module is configured to, in response to the log acquisition instruction, acquire log data of the target domain controller during the log export time period and return the log data to the processing module; the processing module returns the log data to the interaction module for display.

[0017] Based on the aforementioned technical means, this application can specify the log export time period through the interactive module, drive the log collection module to accurately extract the log data of the target domain controller within the corresponding time window, and present it intuitively through the interactive module. This achieves accurate alignment of the underlying scattered log information with the upper-layer business operations in the time dimension, avoids the inefficiency and redundancy of full log retrieval, and greatly improves the efficiency of context tracing and the accuracy of problem location during software and hardware integration and complex fault troubleshooting.

[0018] In one possible implementation, the interaction module is further configured to: package the target data into a file and store it in a removable storage device; wherein the target data includes at least one of the following: target CAN bus data, log data, or diagnostic report.

[0019] Based on the aforementioned technical means, this application can integrate a removable storage device interface into the interaction module to support the unified packaging and persistent storage of heterogeneous information such as target CAN bus data, log data, or diagnostic reports to external media. This achieves offline retention and physical migration of key test data and diagnostic results, meeting the needs of data archiving and cross-device transfer in network-free environments, and providing a complete and independent data carrier for subsequent offline in-depth analysis, fault review, and compliance auditing.

[0020] In one possible implementation, the monitoring device further includes: an installation and deployment module; a communication connection between the installation and deployment module and the processing module; the installation and deployment module being configured to, in response to detecting that a removable storage device is plugged into the target domain controller, pop up an access interface of the monitoring device in the display interface; and, in response to determining that the access control of the access interface is triggered and the access key is successfully verified, send a start command to the processing module; wherein the start command is used to instruct the monitoring device to start; and pop up an interactive interface of the interactive module in the display interface.

[0021] Based on the aforementioned technical means, this application can automatically trigger an access interface pop-up when a removable storage device is connected, and combine the dual security mechanisms of access control triggering and key verification to achieve secure authorization and one-click start of the monitoring device on the domain controller, effectively avoiding the risk of unauthorized device access; at the same time, after successful verification, an interactive interface automatically pops up, eliminating the cumbersome manual installation and configuration process of traditional monitoring tools, and greatly improving the convenience, security and response efficiency of device deployment during the engineering debugging phase.

[0022] In one possible implementation, the interactive interface includes a text input box; the interactive module is further configured to: use a natural language fuzzy algorithm to determine semantic terms in a local semantic term library that match the text instruction input into the text input box; and issue instructions to the processing module based on the semantic terms.

[0023] Based on the aforementioned technical means, this application can automatically match non-standard text commands input by users to standard semantic entries in the local semantic term library by combining the text input box of the interactive interface with natural language fuzzy algorithms, and issue instructions to the processing module accordingly. This reduces the memory threshold for operators of specific command syntax, realizes command interaction based on natural language intuition, and improves the fault tolerance and ease of use of monitoring operations.

[0024] In a second aspect, this application provides a monitoring method, comprising: a processing module applied in a monitoring device as described in the first aspect; the method comprising: the processing module sending a monitoring instruction to a monitoring module when a first condition is met, so that the monitoring module, in response to the monitoring instruction, collects and returns CAN bus data of a target domain controller; wherein the first condition is used to indicate that a removable storage device is plugged into a target domain controller with a display interface and the monitoring device is started; and forwarding the CAN bus data to a storage module so that the storage module converts the CAN bus data into DDS messages for storage.

[0025] In one possible implementation, in response to a first export command sent by the interaction module, the target CAN bus data to be exported is determined; a second export command is issued to the export module; the second export command is used to indicate the export of the target CAN bus data; the target CAN bus data returned by the export module is received; wherein, in response to the second export command, the export module retrieves the target DDS message from the storage module; restores the DDS message to the target CAN bus data; and returns the target CAN bus data to the interaction module for display.

[0026] In one possible implementation, the DDS message carries a collection timestamp; the storage module retains the DDS message whose collection timestamp is within the most recent preset duration of the storage period; the first export instruction is used to indicate the export time period; the export time period is a time period within the storage period; the method further includes: determining the CAN bus data within the export time period as the target CAN bus data.

[0027] In one possible implementation, the CAN bus data includes the signal values ​​of at least one monitoring signal emitted by the controller in the target domain controller; one monitoring signal corresponds to one signal name; the first derived instruction is also used to indicate the target function; the monitoring device further includes a linkage monitoring module; the processing module is communicatively connected to the linkage monitoring module; the method further includes: sending the target function to the linkage monitoring module, so that the linkage monitoring module returns the associated signal names that have a mapping relationship with the target function in the mapping relationship set; wherein, the mapping relationship set is used to characterize the correspondence between the signal names and functions; and determining the CAN bus data corresponding to the associated signal names within the derived time period as the target CAN bus data.

[0028] In one possible implementation, the monitoring device further includes a diagnostic module; the processing module is communicatively connected to the diagnostic module; the method further includes: forwarding the first diagnostic instruction to the diagnostic module in response to a first diagnostic instruction sent by the interaction module; the first diagnostic instruction is used to instruct the generation of a fault code list using CAN bus data; wherein, the CAN bus data includes the signal value of at least one monitoring signal issued by the controller in the target domain controller, fault flag status information, and communication status; the fault code includes a fault code number, a fault description of the fault code, the fault occurrence time, the fault severity level, and the fault associated signal; receiving the fault code list generated and returned by the diagnostic module in response to the first diagnostic instruction; and returning the fault code list to the interaction module for display.

[0029] In one possible implementation, when displaying the fault code list, the interaction module displays a report generation control and a fault code clearing control corresponding to each fault code in the fault code list; the method further includes: in response to a second diagnostic instruction, forwarding the second diagnostic instruction to the diagnostic module; wherein the second diagnostic instruction is issued by the interaction module to the processing module when the report generation control is triggered, for instructing the generation of a diagnostic report using candidate fault codes that have not been triggered by the fault code clearing control; receiving the diagnostic report generated and returned by the diagnostic module in response to the second diagnostic instruction; wherein the diagnostic report includes candidate fault codes and troubleshooting suggestions; the processing module is also used to return the diagnostic report to the interaction module for display.

[0030] In one possible implementation, the monitoring device further includes a log acquisition module; the processing module is communicatively connected to the log acquisition module; the method further includes: in response to a log export instruction sent by the interaction module, sending a log acquisition instruction to the log acquisition module; wherein the log export instruction is used to indicate the log export time period; receiving log data of the target domain controller collected and returned by the log acquisition module in response to the log acquisition instruction during the log export time period; and returning the log data to the interaction module for display.

[0031] In one possible implementation, the method further includes: the interaction module packages the target data into a file and stores it in a removable storage device; wherein the target data includes at least one of the following: target CAN bus data, log data, or diagnostic report.

[0032] In one possible implementation, the monitoring device further includes: an installation and deployment module; the installation and deployment module and the processing module are communicatively connected; the method further includes: the installation and deployment module, in response to detecting that a removable storage device is plugged into the target domain controller, pops up an access interface of the monitoring device in the display interface; and in response to determining that the access control of the access interface is triggered and the access key is successfully verified, sends a start command to the processing module; wherein the start command is used to instruct the monitoring device to start; and pops up an interactive interface of the interaction module in the display interface.

[0033] In one possible implementation, the interactive interface includes a text input box; the method further includes: an interaction module that uses a natural language fuzzy algorithm to determine semantic terms in a local semantic term library that match the text command input into the text input box; and issuing commands to the processing module based on the semantic terms.

[0034] Thirdly, this application provides an electronic device, including: a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the method described in the second aspect above and any possible implementation thereof.

[0035] Fourthly, this application provides a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the methods described in the second aspect and any of its possible embodiments.

[0036] Fifthly, this application provides a computer program product including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the second aspect and any of its possible implementations.

[0037] It should be noted that the technical effects of any of the implementation methods in aspects two through five can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here.

[0038] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0039] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application, and do not constitute an undue limitation of this application.

[0040] Figure 1 This is a schematic diagram of the structure of a monitoring device shown in an embodiment of this application; Figure 2 This is a schematic diagram illustrating a data export interface according to an embodiment of this application; Figure 3 This is a schematic diagram of a linkage monitoring interface shown in an embodiment of this application; Figure 4 This is a schematic diagram of a fault code diagnosis interface shown in an embodiment of this application; Figure 5 This is a schematic diagram of a log collection interface shown in an embodiment of this application; Figure 6This is a schematic diagram illustrating an access interface according to an embodiment of this application; Figure 7 This is a schematic diagram illustrating an interactive interface according to an embodiment of this application; Figure 8 This is a schematic diagram illustrating yet another interactive interface shown in an embodiment of this application; Figure 9 This is a flowchart of a monitoring method provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of another monitoring device shown in the embodiments of this application; Figure 11 This embodiment of the application illustrates a schematic diagram of a hardware deployment architecture provided by this application. Figure 12 This is a block diagram illustrating an electronic device according to an embodiment of this application. Detailed Implementation

[0041] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0042] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0043] In the embodiments of this application, the words "exemplary," "for example," or "for instance" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the words "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a specific manner.

[0044] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0045] In some embodiments, Figure 1This is a schematic diagram of a monitoring device provided in an embodiment of this application. The monitoring device is deployed on a portable storage device. The monitoring module may include a processing module 11, a monitoring module 12, and a storage module 13. The processing module 11 is communicatively connected to both the monitoring module 12 and the storage module 13. The processing module 11 can send a monitoring command to the monitoring module 12 when a first condition is met, so that the monitoring module 12 responds to the monitoring command, collects and returns CAN bus data from the target domain controller. The storage module 13 is used to convert the CAN bus data into DDS (Data Distribution Service) messages for storage, thereby completing a complete closed loop from data collection to persistence of vehicle data.

[0046] The first condition is used to indicate that the removable storage device is plugged into the target domain controller with a display interface and that the monitoring device is started.

[0047] Optionally, the target domain controller can be the vehicle's central control unit or a test bench controller in a research and development engineering mode. The CAN bus data in the target domain controller can include signal values ​​emitted by each controller, fault flag status information, and communication status, among other information.

[0048] It should be understood that the embodiments of this application do not limit the specific architecture of the target domain controller or the communication protocol used by the CAN bus. The monitoring device can be applied to various vehicle diagnostic scenarios, such as CAN-based vehicle diagnostic systems, CAN FD (CAN with Flexible Data-Rate)-based vehicle diagnostic systems, or other diagnostic architectures that support vehicle Ethernet communication. The electronic and electrical architecture of new energy vehicles typically includes multiple domain controllers, such as the vehicle control unit (VCU), battery management system (BMS), and motor control unit (MCU). Different domain controllers interact with each other via the CAN bus. Each domain controller can be divided into application layer, communication layer, and driver layer. The communication layer is responsible for encapsulating the diagnostic requests issued by the application layer according to the Unified Diagnostic Services (UDS) and transmitting and receiving them via the CAN bus.

[0049] In this embodiment, the monitoring device can be deployed on a removable storage device. The removable storage device can be a USB flash drive, external hard drive, or other hot-swappable storage medium supporting a USB interface. The monitoring device establishes a physical connection and data communication with the target domain controller through the USB interface of the removable storage device. This application does not impose specific limitations in this regard.

[0050] As a feasible implementation method, the data communication channel can be established on the USB interface between the removable storage device and the target domain controller. After being processed by the USB driver layer and file system layer of the target domain controller, it appears as a logical data path at the application layer.

[0051] As a feasible implementation, the processing module 11 can support multiple data acquisition modes based on user-configured parameters, enabling the monitoring device to adapt to the CAN bus data acquisition needs of different vehicle models and test scenarios. The storage module 13 can convert CAN data into DDS messages for storage, and then utilize the unified data model and structured storage characteristics of DDS to achieve fast signal-level retrieval and multi-module reuse of structured data, reducing the parsing overhead of subsequent data analysis and export.

[0052] As can be seen, this application can deploy a monitoring device through a removable storage device, interact with the target domain controller's own display interface, and automatically collect CAN bus data from the target domain controller after the device is connected and started, converting the data into DDS message storage. This achieves plug-and-play monitoring without the need for dedicated diagnostic hardware, reducing deployment costs and device dependence. Furthermore, the structured storage in DDS format improves data organization efficiency, facilitating subsequent rapid retrieval and functional-level correlation analysis. Simultaneously, relying on the domain controller's local resources for data acquisition and processing avoids additional wiring and external device intervention, improving deployment flexibility and real-time data acquisition during the R&D and testing phases.

[0053] In some embodiments, when the storage module 13 converts CAN bus data into DDS messages for storage, the following conversion process can be performed: First, storage module 13 can load a predefined data model. The data model records the correspondence between data variables and data types between CAN signals and DDS messages. For example, for the CAN signal "motor speed," its variable name in the data model is defined as "MotorSpeed," with a data type of uint16 (16-bit unsigned integer), corresponding to the same variable and type in the DDS message. This data model can be pre-stored in the monitoring device as a configuration file, or it can be dynamically updated during use via the configuration file.

[0054] Secondly, the storage module 13 can read the basic data type mapping table to map the original data type of the CAN signal to the data type supported by the DDS protocol. For example, the uint8 type (8-bit unsigned integer) in the CAN signal is mapped to the octet type (8-bit byte type) in DDS, the int16 type (16-bit signed integer) is mapped to the short type (16-bit signed short integer) in DDS, and the float type (32-bit single-precision floating-point number) is mapped to the floating-point (float) type (32-bit single-precision floating-point number) in DDS, thereby ensuring the matching and compatibility of data types between different protocols.

[0055] Then, the storage module 13 can call the automatically generated converter code to serialize the acquired CAN signal data. The converter code is program code automatically generated based on the above data model, used to convert raw data organized according to the CAN protocol into structured data organized according to the DDS protocol. According to the variable names and types defined in the data model, the converter code assigns each CAN signal value to the corresponding DDS message field in sequence, forming a complete DDS message structure.

[0056] Finally, storage module 13 can write the serialized DDS messages to the local storage space of the target domain controller according to the acquisition timestamp. Storage module 13 uses a circular overwrite mechanism to retain data up to the nearest preset duration (e.g., 72 hours): when the storage space is insufficient to accommodate new DDS messages, storage module 13 automatically deletes the DDS message with the earliest acquisition timestamp to ensure that data up to the nearest preset duration is always retained. Simultaneously, storage module 13 can also employ a hash-based service signal parsing method to extract service names, method names, and parameter names from the DDS messages, establishing an association index between signals and functional states for easy subsequent rapid retrieval. A hash value is used to convert input data of arbitrary length into a fixed-length output value using a hash algorithm, and is commonly used for fast data lookup and unique identification.

[0057] Specifically, storage module 13 can perform hash calculations on the service name field in the DDS message, and use the calculated hash value as an index key. This hash value, along with the signal name and function status information contained in the DDS message, is stored in an associated index table, thereby establishing a mapping relationship between signals and functions. By converting CAN data to DDS format for storage, and leveraging the unified data model and structured storage characteristics of DDS, the technical effects of fast signal-level retrieval, multi-module reuse of structured data, and reduced parsing overhead are achieved, providing a data foundation for subsequent signal and function linkage monitoring and rapid export.

[0058] In some embodiments, to enable users to easily view and export the collected data, the monitoring device may further include an interaction module and an export module. The processing module 11 is communicatively connected to both the interaction module and the export module, and the storage module 13 is communicatively connected to the export module.

[0059] In one possible implementation, the processing module 11 can also be used to determine the target CAN bus data to be exported in response to the first export command sent by the interaction module, and issue a second export command to the export module.

[0060] The first export command is triggered by the user through the interaction module and indicates which data needs to be exported. The second export command is issued by the processing module 11 to the export module and is used to specifically perform the data export operation. This second export command can be used to indicate the export of target CAN bus data, that is, to instruct the export module to retrieve the target CAN bus data from the storage module 13.

[0061] Furthermore, the export module can respond to the second export command by retrieving the target DDS message from the storage module 13, restoring the target DDS message to target CAN bus data, and returning the restored target CAN bus data to the processing module 11. Subsequently, the processing module 11 is also used to return the target CAN bus data to the interaction module for display, so that the user can directly preview the exported data content or perform further operations on the vehicle's infotainment system.

[0062] For example, the interaction module can provide a graphical user interface (GUI), allowing users to interact with the monitoring device through controls such as buttons, drop-down menus, or text input boxes. For instance, when a user clicks the "Export Data" button on the interaction interface, the interaction module can generate a first export instruction and send it to the processing module 11. After parsing the first export instruction, the processing module 11 can determine the target data required by the user from the storage module 13 based on the export conditions (such as time range, signal type, etc.) carried in the instruction, and complete the reverse conversion and extraction of the data through the export module. This design allows users to view and perform preliminary analysis of data on the vehicle-mounted system without relying on external computers and specialized software, significantly reducing the equipment threshold for research and development testing.

[0063] As a feasible implementation method, after the export module retrieves the target DDS message from the storage module 13, it can perform the reverse operation, which is the opposite of the conversion process of the storage module 13, that is, restore the DDS format data to the original CAN bus data format. The specific reverse conversion process will be described in detail later.

[0064] Specifically, the export module can deserialize each DDS message. Deserialization is the reverse process of serialization, that is, extracting the values ​​of each field from structured data organized according to the DDS protocol. Based on the variable definitions in the data model, the export module extracts signal values ​​one by one from the DDS message, restoring them to the original CAN signal data.

[0065] Secondly, the export module restores the DDS data types to the original data types of the CAN signals according to the basic data type mapping table. For example, the DDS octet type is restored to the CAN uint8 type, the DDS short type is restored to the CAN int type, and the DDS float type is restored to the CAN float type, thus ensuring that the data format is consistent with the original acquired data.

[0066] Finally, the export module encapsulates the restored CAN signal data according to the standard CAN format, generating a standard CAN format file. The encapsulation process includes: writing file header information (including sampling frequency, number of channels, signal definitions, and other metadata) according to the standard CAN format file specifications, and then writing each CAN data frame (including frame ID, data length, data content, etc.) in timestamp order. This reverse conversion process ensures the consistency between the exported data and the original acquired data, enabling the exported standard CAN format file to be correctly recognized and played back by professional tools.

[0067] As can be seen, this application can receive export instructions through the interaction module, and the processing module determines the target data and drives the export module to retrieve the corresponding DDS message from the storage. After being restored to the original CAN bus data, it is returned to the interaction module for display. This enables the accurate extraction, format restoration and visualization of historical data directly on the domain controller without relying on external professional analysis tools, simplifying the operation process of fault diagnosis and data analysis, and improving the immediacy and convenience of problem location during the R&D and testing phase.

[0068] In some embodiments, to support retrospective analysis of historical data, the DDS message may carry a collection timestamp. Specifically, when the monitoring module 12 collects each CAN bus data, the processing module 11 or the monitoring module 12 adds a collection timestamp to the data. Subsequently, the storage module 13 can encapsulate the timestamp and the data content together into a DDS message for storage, so that the storage module 13 retains DDS messages whose collection timestamps are within the most recent preset storage period.

[0069] For example, the storage module 13 can employ a cyclic overwrite mechanism to retain the CAN bus data of the most recent 72 hours. That is, when storage space is insufficient, the system automatically deletes the earliest acquired DDS message to ensure that the data of the most recent 72 hours is always retained. Optionally, this preset duration can be configured according to actual test requirements, such as 24 hours, 48 ​​hours, or 8 hours (7 days). This application does not impose any restrictions on this.

[0070] Optionally, the first export instruction can also be used to indicate an export time period, which is a time period within a stored time period. For example, the user can select "past 30 minutes," "past 1 hour," or specify a specific start and end time as the export time period through the interactive module. Furthermore, the processing module 11 can specifically be used to determine the CAN bus data within the export time period as the target CAN bus data. This application does not impose any specific limitations on this.

[0071] For example, to facilitate users in intuitively setting the export time period and triggering the data export operation, the interactive module can also provide a data export interface. For instance... Figure 2 As shown, in the data export interface, the time period setting area provides a selection control for the log export time period. Users can specify the specific start and end times of collection using the date and time selector (e.g., 09:00:00 to 10:00:00), or quickly set the collection period using shortcut selection buttons (e.g., past 30 minutes / hours, past 1 hour, past 6 hours). After confirming the time period, users can select the format of the export file in the CAN format selection area, such as format 1, format 2, or format 3, to adapt to different offline analysis tools. The file name area automatically generates a filename containing time information (e.g., file1.format1), facilitating subsequent identification and management by the user. The export progress bar displays the completion progress of the current export operation, such as 80%. The storage location area indicates the insertion status of the removable storage device. Users can trigger a second export command to start data export using the "Start Export" button, or stop the ongoing export operation using the "Cancel Export" button. The storage location is indicated as: removable storage device (inserted).

[0072] As a feasible implementation, after the user sets the export time period through the interactive module, the processing module 11 can retrieve and extract all DDS messages whose acquisition timestamps fall within the export time period from the storage module 13 based on the acquisition timestamps carried in the DDS messages. Through this timestamp-based retrieval mechanism, users can accurately locate data segments before and after the fault occurs, avoiding storage waste and analysis burden caused by exporting irrelevant data.

[0073] For example, if the vehicle experiences an intermittent functional malfunction at 09:23 on the same day, the user can insert a USB flash drive into the vehicle's infotainment system afterward and set the export time period to "09:00:00 to 09:30:00" on the interactive interface. The processing module 11 can then extract all CAN data for that time period from the circular storage for the user to export and analyze, solving the technical pain point of "missed data is lost" in traditional solutions. With this design, even if the data cannot be viewed in time when an intermittent fault occurs, the user can still review the historical data at the time of the fault afterward for offline analysis.

[0074] In some embodiments, the CAN bus data may also include the signal values ​​of at least one monitoring signal emitted by the controller in the target domain controller, with each monitoring signal corresponding to a signal name. For example, monitoring signals may include "motor speed," "motor torque," "IGBT temperature," "battery state of charge," and "battery current," etc. Each monitoring signal can be uniquely identified by its signal name.

[0075] Optionally, the first export instruction can also be used to indicate a target function. The target function refers to the vehicle function corresponding to the data the user wishes to export. For example, if the user wishes to export all signal data related to the "motor system," then the target function is "motor system"; similarly, if the user wishes to export all signal data related to "BMS signal transmission status," then the target function is "BMS signal transmission status." This application does not impose specific limitations on this.

[0076] In one possible implementation, the monitoring device may further include a linkage monitoring module, with the processing module 11 communicatively connected to the linkage monitoring module. The linkage monitoring module has a built-in mapping set, which represents the correspondence between signal names and functions. The mapping set can be pre-built into the monitoring device or dynamically updated via a configuration file during use to adapt to the needs of different vehicle models and different testing phases.

[0077] As a feasible implementation, processing module 11 can specifically be used to: send the target function to the linkage monitoring module, so that the linkage monitoring module returns the associated signal names that have a mapping relationship with the target function in the mapping relationship set. Then, processing module 11 determines the CAN bus data corresponding to the above-mentioned associated signal names within the exported time period as the target CAN bus data.

[0078] For example, when a user selects the "BMS signal transmission status" function through the interactive module, the linkage monitoring module can automatically associate relevant signal names such as BMS signal reception status, battery function status, and CAN bus load rate based on the mapping relationship set. The processing module 11 can then determine all CAN bus data within the export time period for these associated signal names as the target data. Through this function-level data export method, users do not need to manually add signal identifiers one by one; they can obtain all signal data related to a specific function with a single click, thereby improving the efficiency of data export and analysis.

[0079] As a feasible implementation method, the interactive module can also provide a linkage monitoring interface to facilitate users to intuitively view the real-time status of each associated signal.

[0080] For example, such as Figure 3 As shown, in the linked monitoring interface, the function selection area displays the user's selected function, such as BMS signal transmission status. Users can trigger linked monitoring by selecting a function (e.g., "BMS signal transmission status") and clicking the "Confirm Selection" button. The associated signal display area automatically displays associated signals that are mapped to the selected function and their current status based on the mapping relationship set. For example, when the user selects the "BMS signal transmission status" function, it automatically displays the BMS signal reception status, battery function status, and CAN bus load rate, respectively, and labels the current status of each signal as "normal" or "abnormal." Furthermore, when a signal abnormality is detected, the associated signal display area can display the abnormal signal. For example, when a signal interruption occurs in the BMS signal transmission status, the associated signal display area displays the abnormality type "signal interruption" and the occurrence time "09:23:15," helping engineers quickly locate communication link problems and determine whether it is a transmitter fault, receiver fault, or bus transmission fault.

[0081] As a feasible implementation method, the mapping relationship set in the linkage monitoring module can be established through the service signal parsing method based on hash values ​​described above. During the conversion of CAN data to DDS messages in the storage module 13, the processing module 11 can extract the service name, method name, and parameter name from the DDS message and establish an association index between the signal and the functional status. This association index constitutes the mapping relationship set.

[0082] For example, in the DDS protocol, data is published in units of "topics," each containing information such as service name, method name, and parameter list. When the storage module 13 converts CAN signal data into DDS messages, it simultaneously extracts the topic information to which the DDS message belongs, thereby determining which service, method, and parameter the CAN signal belongs to. By associating signal names with this topic information, a mapping relationship between signals and functions can be established. Through this mapping relationship set, when the user selects any function (e.g., selecting the "BMS signal transmission status" function), the processing module 11 automatically associates and displays all signal statuses related to that function. This signal-function linkage monitoring method reduces the communication link problem location time from hours in traditional solutions to minutes, improving R&D testing efficiency.

[0083] In some embodiments, in order to read and diagnose vehicle fault codes on the in-vehicle terminal, the monitoring device may further include a diagnostic module. The processing module 11 is communicatively connected to the diagnostic module.

[0084] In one possible implementation, the processing module 11 can also be used to forward the first diagnostic instruction to the diagnostic module in response to the first diagnostic instruction sent by the interaction module.

[0085] The first diagnostic command can be used to instruct the generation of a fault code list using CAN bus data. CAN bus data can include the signal values ​​of at least one monitoring signal emitted by the controller in the target domain controller, fault flag status information, and communication status. A fault code can include a fault code number, a fault description representing the fault, the time of fault occurrence, the severity level of the fault, and associated signals. The fault code number is a code used to uniquely identify a fault type, such as "XXX:35". The fault description is a textual description of the fault phenomenon represented by the fault code, such as "high-voltage interlock circuit abnormality". The time of fault occurrence is the moment the fault was first detected; the severity level indicates the degree of impact of the fault on vehicle safety or function, for example, divided into three levels: "severe", "moderate", and "minor"; and the associated signals refer to a list of monitoring signal names related to the fault.

[0086] In one possible implementation, after receiving a first diagnostic command, the diagnostic module can send diagnostic requests via the CAN bus to each Electronic Control Unit (ECU) in the target domain controller. Each ECU responds to the diagnostic request by returning its stored fault code information. The diagnostic module collects all responses and integrates them to generate a fault code list. Then, in response to the first diagnostic command, the diagnostic module can generate and return the fault code list to the processing module 11. The processing module 11 is also used to return the fault code list to the interactive module for display.

[0087] As a feasible implementation, the diagnostic module can be implemented based on the Unified Diagnostic Services (UDS) protocol stack. The diagnostic module sends diagnostic request messages conforming to the UDS protocol specification to each electronic control unit (ECU) in the target domain controller via the CAN bus. Each ECU responds to the request by returning a diagnostic response message containing fault code information. After collecting the responses from all ECUs, the diagnostic module parses each response message according to the UDS protocol specification, extracts information such as fault code number, fault status, and occurrence time, and integrates them to generate a fault code list. Subsequently, the processing module 11 can return this fault code list to the interaction module for display.

[0088] As can be seen, the embodiments of this application realize the reading and diagnosis of vehicle fault codes by integrating a diagnostic module into the monitoring device, so that users can directly obtain fault code information on the vehicle terminal without relying on external dedicated diagnostic instruments, thereby reducing the equipment threshold and operational complexity of diagnostic operations.

[0089] In some embodiments, in order to achieve refined diagnostic report generation and fault code management, the interactive module can also display report generation controls and fault code clearing controls corresponding to each fault code in the fault code list when displaying the fault code list.

[0090] For example, each fault code entry in the interactive interface has a clear checkbox or clear button next to it, and a "Generate Diagnostic Report" button is located at the bottom of the interface. Users can select fault codes to be cleared by checking the clear checkboxes, and unchecked fault codes are retained as candidate fault codes in the diagnostic report.

[0091] In one possible implementation, the processing module 11 can also be configured to forward the second diagnostic instruction to the diagnostic module in response to the second diagnostic instruction. Furthermore, the diagnostic module can also be configured to generate and return a diagnostic report to the processing module 11 in response to the second diagnostic instruction. The processing module 11 is further configured to return the diagnostic report to the interaction module for display.

[0092] The second diagnostic instruction is issued by the interaction module to the processing module 11 when the report generation control is triggered. This instruction instructs the generation of a diagnostic report using candidate fault codes that have not been triggered by the fault code clearing control. In other words, the user can select fault codes to be cleared by checking a box, and unselected fault codes are included as candidate fault codes in the diagnostic report. The diagnostic report can include detailed information on the aforementioned candidate fault codes and troubleshooting suggestions. These suggestions can be pre-stored text containing troubleshooting steps associated with the fault code number in the diagnostic module. For example, for fault code "XXX:35" (high-voltage interlock circuit abnormality), the troubleshooting suggestions could include checking if the high-voltage connector is loose, checking if the high-voltage interlock circuit is open, and checking if the BMS controller power supply is normal.

[0093] For example, after reading the fault code list, the user can select the fault clearing control corresponding to the confirmed repaired fault code to perform the clearing operation (at which point the fault code will be removed from the fault code list), and then click the "Generate Diagnostic Report" button. The processing module 11 can integrate the remaining uncleared fault codes, their associated signal curves, and suggested troubleshooting steps into a single diagnostic report and export it to a removable storage device. The report format supports multiple formats such as CSV and PDF, facilitating archiving and sharing. Through this design, users can flexibly manage fault codes, avoiding the risk of accidentally clearing unconfirmed fault codes while generating targeted diagnostic reports, thus improving the standardization and traceability of diagnostic work.

[0094] For example. As Figure 4 As shown, the fault code diagnostic interface provided by the interactive module displays fault code information in list format. Each row in the fault code list corresponds to one fault code, containing the following fields: Electronic Control Unit (e.g., VCU, BCU), Fault Code Number (a code used to uniquely identify the fault type, e.g., 402, 230, 35), Fault Status (e.g., high-voltage interlock circuit abnormality, node loss abnormality), Severity Level (e.g., high), and Occurrence Time (the time the fault was detected, e.g., 09:23:15). The fault code diagnostic interface can also display statistical information, such as the current total number of faults (3) and the historical number of faults (5), allowing users to quickly understand the overall fault status of the vehicle. Users can trigger the first diagnostic command to refresh the fault code list by clicking the "Read Fault Codes" button, perform the fault code clearing operation by selecting fault code entries and clicking the "Clear Fault Codes" button, and trigger the second diagnostic command to generate and export the diagnostic report by clicking the "Export Diagnostic Report" button.

[0095] Optionally, the fault code clearing operation itself is also implemented by the diagnostic module based on the UDS protocol. When the user selects the clearing control corresponding to a fault code and confirms, the processing module 11 can send a clearing command to the diagnostic module. The diagnostic module sends a UDS 0x14 service (clear diagnostic information) request to the corresponding electronic control unit via the CAN bus to clear the corresponding fault code stored in the electronic control unit.

[0096] In some embodiments, to support on-demand collection of vehicle system logs, the monitoring device may further include a log collection module. The processing module 11 is communicatively connected to the log collection module.

[0097] In one possible implementation, the processing module 11 can also be used to send a log collection instruction to the log collection module in response to the log export instruction sent by the interaction module. Furthermore, the log collection module can be used to collect log data from the target domain controller during the log export period in response to the log collection instruction, and return the collected log data to the processing module 11, so that the processing module 11 can return the log data to the interaction module for display.

[0098] The log export command can be a user-triggered command triggered through an interactive module to instruct the collection of system logs. The log export command can also specify the time period for log export.

[0099] For example, to facilitate users in intuitively setting log collection parameters and triggering collection operations, the interactive module can provide a log collection interface. For instance... Figure 5 As shown, the time period setting area provides a selection control for the log export time period. Users can specify the specific start and end time of collection by customizing the time period (e.g., 09:00:00 to 10:00:00), or quickly set the collection time period by using shortcut selection buttons (e.g., "Past 1 Hour", "Past 6 Hours", "Past 24 Hours"). After confirming the time period, the log time range to be collected can be locked.

[0100] The log type selection area provides checkboxes for various log types, such as system logs, application runtime logs, and system kernel logs. Users can flexibly select the log types to collect based on their actual analysis needs, avoiding storage waste and analysis burden caused by full collection. The collection status area displays collection information, collection status, current collection progress (e.g., 80%), the name of the collected file (e.g., file2.format), and file size. The storage location area indicates the insertion status of the removable storage device (e.g., USB flash drive) and the storage path of the collected files (e.g., USB flash drive / path1 / ). After confirming the collection time period and log type, the user can trigger the log collection command by clicking the start collection button. The log collection module can respond to the log collection command to start collecting log data of the specified time period and type. After collection is complete, the log data is packaged into a compressed file and stored on the removable storage device.

[0101] Optionally, log data may include system logs, application runtime logs, and system kernel logs, etc. This application does not impose specific limitations on this.

[0102] As a feasible implementation, the log collection module can extract corresponding log entries from the system log cache or log files based on the user-specified time period by calling the system log interface of the target domain controller. After collection, the log collection module can compress the log data and set a filename that includes time information, facilitating subsequent analysis and archiving. Compared to the traditional full-data collection method that requires creating a specially named folder to trigger, this time-based log collection method avoids storage waste and analysis burden, improving the targeting and efficiency of log collection. For example, in the traditional solution, the user needs to create a special folder on a USB drive, and the vehicle system will only trigger full-data collection after detecting the folder. In this embodiment, the user can directly select the time period for precise collection through the interactive interface.

[0103] In some embodiments, to uniformly export various types of data selected by the user to a removable storage device, the interaction module can also be used to package the target data into a file and store it in the removable storage device. The target data includes at least one of the following: target CAN bus data, log data, or diagnostic report data. For example, after the user completes the data export, log collection, or diagnostic report generation operation, the interaction module writes the corresponding data file to the root directory or a specified folder of the removable storage device.

[0104] For example, for CAN bus data, the export module can generate standard CAN format files. Users can connect a removable storage device to a computer and use specialized tools to open these standard CAN format files for offline playback analysis. For log data, the interaction module can save the compressed files returned by the log acquisition module to the removable storage device. For diagnostic reports, the interaction module can save the diagnostic reports generated by the diagnostic module to the removable storage device. Through this unified data export mechanism, users can complete the acquisition and export of various types of data with a single plug-and-play operation of the removable storage device, simplifying the operation process and improving R&D testing efficiency.

[0105] In some embodiments, to ensure that the monitoring device operates only in an authorized environment and to prevent unauthorized access, the monitoring device may also include an installation and deployment module. The installation and deployment module and the processing module 11 are communicatively connected.

[0106] The installation and deployment module can be used to respond to the detection of a removable storage device being plugged into a target domain controller, and to display a pop-up window on the target domain controller's display interface to show the access interface for the monitoring device. The access interface can prompt the user that a monitoring device has been detected and ask whether to install it, for example, displaying a prompt message such as "Research and development diagnostic tool installation package detected, do you want to install it?" and two buttons: "Install" and "Cancel".

[0107] The installation and deployment module can also be used to send a startup command to the processing module 11 in response to the activation of an access control (such as the "Install" button) on the access interface and successful access key verification. This startup command instructs the monitoring device to start. The installation and deployment module can also be used to display a pop-up window on the interactive interface of the module, allowing the user to begin using the various functions of the monitoring device.

[0108] As a feasible implementation, the monitoring device's application can be packaged as an Android Package Kit (APK) file and stored on a removable storage device. An APK file is the application installation package format for the Android operating system, containing the application's code, resources, certificates, and manifest file. When the removable storage device is inserted into the target domain controller, the target domain controller's operating system (e.g., Android Automotive) automatically recognizes the removable storage device and detects the APK file within, subsequently displaying an access interface.

[0109] After clicking the "Install" button on the access interface, the user is prompted to enter the engineering mode password or perform a specific gesture to verify the access key. Upon successful verification, the monitoring device can begin installation and will automatically start upon completion, displaying the interactive interface. If verification fails, installation and startup will be refused.

[0110] For example, the APK file of the monitoring device is signed using a signing certificate consistent with the target domain controller system. In engineering mode, the target domain controller allows the installation of this signed application via removable storage devices. Installation is not possible in normal user mode, ensuring the security of the engineering solution. This design effectively prevents unauthorized personnel from accidentally or maliciously installing diagnostic tools in normal user mode, protecting the security and stability of the vehicle system.

[0111] For example, in the case where the removable storage device is a USB flash drive, such as Figure 6 As shown, after the removable storage device is inserted into the USB flash drive interface of the target domain controller, a USB flash drive recognition prompt appears on the display screen, indicating that the USB flash drive has been detected and displaying the connection interface. The user can initiate the installation operation by clicking the install button on the connection interface, or exit the installation by clicking the cancel button. The display interface also shows APK file information, such as the application name, version number, and file size, for user confirmation. During the installation process, the connection interface can also display the installation progress or installation completion indicator to inform the user of the current installation status.

[0112] It is understood that the above access key verification method is only an example. In practical applications, other verification methods may be used, such as fingerprint verification, facial recognition verification, or dynamic verification code verification. This application does not impose any restrictions on these methods.

[0113] In some embodiments, to support users in quickly invoking various functions of the monitoring device using natural language, the interactive interface provided by the interaction module may include a text input box. Users can enter natural language commands or keyword commands in the text input box. The interaction module can also be used to use a natural language fuzzy algorithm to determine semantic terms in the local semantic term library that match the text commands entered in the text input box, and issue corresponding commands to the processing module 11 based on the semantic terms.

[0114] The local semantic term library is a database pre-stored in the monitoring device, containing commonly used instruction templates and their corresponding function mappings. This local semantic term library can operate without a network, ensuring that the monitoring device can still be used normally in network-free environments during the early stages of development.

[0115] Specifically, the natural language fuzzy algorithm may include the following processing steps: First, the interaction module performs word segmentation on the user-input text command and extracts keywords (such as signal names, operation verbs, etc.). Second, the interaction module calculates the text similarity between the extracted keywords and each semantic term in the local semantic term library (for example, using an edit distance algorithm or a cosine similarity algorithm). Then, the interaction module selects the semantic term with the highest similarity as the matching result; finally, the interaction module issues corresponding operation commands to the processing module 11 based on the functional mapping relationship recorded in the matched semantic terms.

[0116] For example, such as Figure 7 As shown, the user types the natural language statement "Display motor temperature curve" into the text input box. The interaction module can call the local semantic term library and identify the user's intent through keyword extraction and fuzzy matching algorithms. The local semantic term library has built-in commonly used command templates, such as displaying motor temperature curve, reading fault codes, collecting logs, displaying battery voltage, and exporting diagnostic reports. When the user enters "Display motor temperature curve," the interaction module matches the term "display signal curve," extracts the signal name as "motor temperature," and determines that the command parsing status is a successful match. Then, it issues the command to the processing module 11 to display the real-time motor temperature curve. Subsequently, after the processing module 11 completes its processing, the motor temperature curve returned by the processing module 11 after executing the command is displayed in the operation result display area. This text command interaction method can parse commonly used commands without a network, reducing interaction steps, lowering the operational threshold for R&D engineers in offline environments, and improving testing efficiency.

[0117] In one possible implementation, the interactive interface can also display search results via a display screen, allowing users to view and analyze them.

[0118] For example, such as Figure 8As shown, users can enter the signal name (e.g., "motor temperature") in the text input box and click the search button for quick location. The signal list in the display interface shows all monitorable CAN signals and their corresponding graphs, such as motor speed, motor torque, motor temperature, IGBT temperature, and rear motor A-phase current. Users can select the signals to be displayed by checking the checkboxes corresponding to each signal. The signal group selection drop-down menu allows users to filter signals by function module, such as selecting "High Voltage System," "Battery System," or "Thermal Management System," to automatically display the real-time curves of all signals in that group. The curve display area can show the curves of each signal changing over time (e.g., torque, speed, temperature). The horizontal axis (X) can be time (unit: seconds), and the vertical axis (Y) can be the signal value, supporting multi-signal overlay comparison analysis. Users can also save the current curve as an image or data file using the "Save Curve" button and simultaneously compare and view multiple signals using the "Overlay Analysis" button. This allows users to flexibly view and analyze the changing trends of each CAN signal, improving the intuitiveness and efficiency of signal monitoring.

[0119] It is understood that, in specific implementation, the specific implementation methods of the above modules can be adapted and adjusted according to the operating system type of the target domain controller, the CAN bus interface type, and the user's actual testing requirements. This application embodiment does not impose any restrictions on this.

[0120] It should be noted that the above Figure 1 The structure shown does not constitute a limitation on the monitoring device. The monitoring device may include fewer or more components than shown, or combine certain components, or have different component arrangements. This application embodiment does not impose any limitations in this regard.

[0121] The monitoring method provided in this application embodiment can be applied to... Figure 1 The processing module 11 in the monitoring device shown can also be used in monitoring devices and other electronic devices; this application embodiment does not limit this application. For ease of description, this application embodiment uses a monitoring method applied to... Figure 1 The processing module 11 shown is used as an example for illustration. Please refer to [link / reference]. Figure 9 , Figure 9 This is a flowchart of a monitoring method provided in an embodiment of this application. Figure 9 As shown, the monitoring method includes: S901-S902.

[0122] S901. If the first condition is met, a monitoring command is sent to the monitoring module so that the monitoring module responds to the monitoring command, collects and returns CAN bus data of the target domain controller.

[0123] The first condition is used to indicate that the removable storage device is plugged into the target domain controller with a display interface and that the monitoring device is started.

[0124] S902: Forward the CAN bus data to the storage module so that the storage module can convert the CAN bus data into DDS messages for storage.

[0125] Understandable Figure 9 The specific implementation of the monitoring method can be found in the description of the monitoring device in the embodiments of this application, and will not be repeated here.

[0126] Based on the above technical solution, this application can deploy a monitoring device using a removable storage device, interacting with the target domain controller's own display interface. After the device is connected and started, it automatically collects CAN bus data from the target domain controller and converts the data into DDS message storage, achieving plug-and-play monitoring without dedicated diagnostic hardware, reducing deployment costs and device dependence. Furthermore, the structured storage in DDS format improves data organization efficiency, facilitating subsequent rapid retrieval and functional-level correlation analysis. Simultaneously, relying on the domain controller's local resources for data acquisition and processing avoids additional wiring and external device intervention, improving deployment flexibility and real-time data acquisition during the R&D and testing phases.

[0127] In some embodiments, the monitoring device provided in this application is deployed in a removable storage device (e.g., a USB flash drive). When R&D engineers are conducting vehicle debugging or integration testing, they can use the monitoring device to achieve CAN network monitoring, diagnostics, and data playback functions for the target domain controller (e.g., the vehicle infotainment system) through the following steps: S1. The removable storage device is plugged into the target domain controller, and the installation and deployment module is detected and a pop-up access interface appears.

[0128] S2. Install and deploy the module to verify the access key. After successful verification, start the monitoring device.

[0129] S3. If the first condition is met, the processing module sends a monitoring instruction to the monitoring module.

[0130] S4. The monitoring module responds to the monitoring command, collects the CAN bus data of the target domain controller, and returns it to the processing module.

[0131] S5. The processing module forwards the CAN bus data to the storage module.

[0132] S6. The storage module converts CAN bus data into DDS messages for storage.

[0133] S7. The storage module establishes an index linking signals and functional states.

[0134] S8. The user triggers the first diagnostic command through the interaction module, and the processing module forwards the first diagnostic command to the diagnostic module.

[0135] S9. The diagnostic module responds to the first diagnostic command, generates a list of fault codes, and returns it to the processing module.

[0136] S10. The processing module returns the list of fault codes to the interactive module for display.

[0137] S11, the interactive module displays the report generation control and the fault code clearing control.

[0138] S12, The user triggers the report generation control, and the processing module responds to the second diagnostic instruction and forwards it to the diagnostic module.

[0139] S13. The diagnostic module responds to the second diagnostic command, generates a diagnostic report, and returns it to the processing module.

[0140] S14. The user triggers the log export command through the interaction module, and the processing module sends the log collection command to the log collection module.

[0141] S15. The log collection module responds to the log collection command and collects log data from the target domain controller during the log export period.

[0142] S16. The processing module returns the log data to the interactive module for display.

[0143] S17. The user triggers the first export command through the interaction module, and the processing module determines the target CAN bus data to be exported.

[0144] S18. The processing module issues a second export command to the export module.

[0145] S19. The export module responds to the second export instruction by retrieving the target DDS message from the storage module.

[0146] S20. The export module restores the target DDS message to the target CAN bus data.

[0147] S21. The export module returns the restored target CAN bus data to the processing module.

[0148] S22. The processing module returns the target CAN bus data to the interaction module for display and / or export.

[0149] S23. The user enters a text command through the text input box, and the interaction module uses a natural language fuzzy algorithm for matching.

[0150] S24. The interaction module issues instructions to the processing module based on the matched semantic terms.

[0151] The specific implementation methods of each module in steps S1 to S24 above can be referred to the relevant descriptions in the aforementioned monitoring device corresponding module structure embodiments, and will not be repeated here.

[0152] It is understood that, in practice, the specific implementation of the above steps can be adapted and adjusted according to the operating system type of the target domain controller, the CAN bus interface type, and the user's actual testing requirements. This application embodiment does not impose any restrictions on this.

[0153] In some embodiments, such as Figure 10 As shown, Figure 10 This is a schematic diagram of the structure of another monitoring device shown in the embodiments of this application.

[0154] Figure 10 The monitoring devices include: installation and deployment module, monitoring module, linkage monitoring module, diagnostic module, storage module, export module, log collection module, and interaction module.

[0155] The installation and deployment module stores the APK installation package and sends deployment commands to the vehicle's core processing unit. The monitoring module collects raw CAN / CANFD / Ethernet data and sends the collected signal values, fault codes, and communication status to the vehicle's core processing unit. The diagnostic module sends the collected data and function mapping relationships to the vehicle's core processing unit and receives the linked monitoring results and abnormal signal markers returned by the vehicle's core processing unit.

[0156] The storage module is used to send diagnostic commands and fault code data to the vehicle's core processing unit and to receive diagnostic reports returned by the core processing unit. The storage module is also used to interact with the core processing unit for DDS-formatted stored data and has a cyclic overwrite feature to store historical data.

[0157] The export module is used to receive standard CAN format files sent by the vehicle's core processing unit.

[0158] The log collection module is used to receive the log collection time period instruction sent by the vehicle's core processing unit, and to send vehicle log data and compressed log files to the vehicle's core processing unit.

[0159] The interaction module is used to send operation commands (including graphical and text operations) to the vehicle's core processing unit and to receive monitoring, diagnostic, and export results returned by the core processing unit. This interaction module is also used to receive installation packages via a removable storage device and to export diagnostic reports, CAN data, and log files to the removable storage device.

[0160] The vehicle's core processing unit communicates with each of the aforementioned modules to coordinate the data and instruction flows between them.

[0161] It should be understood that the connections between the modules shown in the figure are merely illustrative. In actual implementation, the communication connections between the modules can be increased or decreased according to actual needs, and this application embodiment does not impose any restrictions on this.

[0162] In some embodiments, such as Figure 11 As shown, Figure 11 This is a schematic diagram of a hardware deployment architecture provided in an embodiment of this application. The monitoring device provided in this embodiment is deployed in a removable storage device (e.g., a USB flash drive), which stores the application installation package of the monitoring device. The hardware deployment architecture includes at least a removable storage device, a target domain controller, a vehicle CAN bus, and an external processing device.

[0163] In one possible implementation, the removable storage device and the target domain controller establish a physical connection and data communication via a USB interface. The removable storage device stores the application installation package for the monitoring device. When the removable storage device is plugged into the target domain controller, the target domain controller reads and installs the application installation package via the USB interface, thereby deploying the monitoring device within the target domain controller. The target domain controller has a built-in CAN controller or Ethernet interface, which connects to the vehicle's CAN bus to collect raw CAN data (e.g., raw data in CAN / CANFD / vehicle Ethernet formats) from the vehicle's CAN bus. During the data export phase, the target domain controller writes user-selected data (e.g., standard CAN format files, compressed log files, or diagnostic reports) to the removable storage device via the USB interface. The user connects the removable storage device to an external processing device (e.g., a personal computer) to use the professional analysis tools installed on the external processing device for offline playback analysis of the exported standard CAN format files.

[0164] Figure 12 This is a block diagram illustrating an electronic device according to an embodiment of this application. Figure 12 As shown, the electronic device includes, but is not limited to, a processor 1201 and a memory 1202.

[0165] The memory 1202 described above is used to store the executable instructions of the processor 1201. It is understood that the processor 1201 is configured to execute instructions to implement the network maintenance method described in the above embodiments.

[0166] It should be noted that those skilled in the art will understand that Figure 12 The electronic device structure shown does not constitute a limitation on the electronic device; the electronic device may include, but is not limited to, other electronic devices. Figure 12 This may indicate more or fewer components, or combinations of certain components, or different component arrangements.

[0167] Processor 1201 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in memory 1202, and by calling data stored in memory 1202, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Processor 1201 may include one or more processing units. Processor 1201 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into processor 1201.

[0168] The memory 1202 can be used to store software programs and various data. The memory 1202 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required by at least one functional module (such as deterministic components, integrated components, etc.), etc. Furthermore, the memory 1202 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0169] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1202 including instructions, which can be executed by a processor 1201 of an electronic device to implement the methods in the above embodiments.

[0170] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device. In an exemplary embodiment, this application also provides a computer program product including one or more instructions, which can be executed by the processor 1201 of the electronic device to perform the methods in the above embodiments.

[0171] It should be noted that when one or more instructions in the computer-readable storage medium or computer program product are executed by the processor of an electronic device, they implement the various processes of the above method embodiments and achieve the same technical effect as the above method. To avoid repetition, they will not be described again here.

[0172] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0173] In the several 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 apparatus, or some features may be ignored or not executed. Furthermore, the mutual 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.

[0174] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0175] Furthermore, the functional units in the various embodiments of this application 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.

[0176] 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 readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0177] This application provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the methods described in the above method embodiments.

[0178] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method in the method flow shown in the above method embodiments.

[0179] The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, a register, a hard disk, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof, or any other form of computer-readable storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an application-specific integrated circuit (ASIC). In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0180] Since the network maintenance device, computer-readable storage medium, and computer program product in the embodiments of this application can be applied to the above method, the technical effects that can be obtained can also be referred to the above method embodiments. The embodiments of this application will not be repeated here.

[0181] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A monitoring device, wherein the monitoring device is deployed on a portable storage device, characterized in that, The monitoring device includes: a processing module, a monitoring module, and a storage module; the processing module is communicatively connected to both the monitoring module and the storage module; the processing module is used for: If the first condition is met, a monitoring command is sent to the monitoring module so that the monitoring module responds to the monitoring command, collects and returns the CAN bus data of the target domain controller; wherein, the first condition is used to instruct the removable storage device to be plugged into the target domain controller with the display interface, and the monitoring device is started. In addition, the CAN bus data is forwarded to the storage module so that the storage module converts the CAN bus data into DDS messages for storage.

2. The monitoring device according to claim 1, characterized in that, The monitoring device further includes an interaction module and an export module; the processing module is communicatively connected to both the interaction module and the export module; the storage module is communicatively connected to the export module. The processing module is further configured to: determine the target CAN bus data to be exported in response to the first export command sent by the interaction module; A second export command is issued to the export module; the second export command is used to instruct the export of the target CAN bus data. The export module is configured to, in response to the second export instruction, retrieve the target DDS message from the storage module; restore the DDS message to the target CAN bus data; and return the target CAN bus data to the processing module. The processing module is also used to: return the target CAN bus data to the interaction module for display.

3. The monitoring device according to claim 2, characterized in that, The DDS message carries a collection timestamp; the storage module stores DDS messages whose collection timestamp is within the most recent preset storage period; The first export instruction is used to indicate the export time period; the export time period is a time period within the storage time period; The processing module is specifically used to: determine the CAN bus data within the exported time period as the target CAN bus data.

4. The monitoring device according to claim 3, characterized in that, The CAN bus data includes the signal value of at least one monitoring signal emitted by the controller in the target domain controller; one monitoring signal corresponds to one signal name; the first derived instruction is also used to indicate the target function; the monitoring device further includes a linkage monitoring module; the processing module is communicatively connected to the linkage monitoring module; the processing module is specifically used for: The target function is sent to the linkage monitoring module so that the linkage monitoring module returns the associated signal names that have a mapping relationship with the target function from the mapping relationship set; wherein, the mapping relationship set is used to represent the correspondence between signal names and functions; The CAN bus data corresponding to the associated signal name within the exported time period is determined as the target CAN bus data.

5. The monitoring device according to any one of claims 2-4, characterized in that, The monitoring device further includes a diagnostic module; the processing module is communicatively connected to the diagnostic module. The processing module is further configured to respond to a first diagnostic instruction sent by the interaction module by forwarding the first diagnostic instruction to the diagnostic module; the first diagnostic instruction is configured to instruct the generation of a fault code list using the CAN bus data; wherein, the CAN bus data includes the signal value of at least one monitoring signal issued by the controller in the target domain controller, fault flag status information, and communication status; the fault code includes a fault code number, a fault description of the fault code, the fault occurrence time, the fault severity level, and fault-related signals; The diagnostic module is configured to generate and return the fault code list to the processing module in response to the first diagnostic command; The processing module is also used to return the list of fault codes to the interaction module for display.

6. The monitoring device according to claim 5, characterized in that, When the interaction module displays the fault code list, it displays a report generation control and a fault code clearing control corresponding to each fault code in the fault code list. The processing module is further configured to: in response to a second diagnostic instruction, forward the second diagnostic instruction to the diagnostic module; wherein the second diagnostic instruction is issued by the interaction module to the processing module when the report generation control is triggered, for instructing the generation of a diagnostic report using the candidate fault codes that have not been triggered by the fault code clearing control; The diagnostic module is further configured to, in response to the second diagnostic instruction, generate and return the diagnostic report to the processing module; wherein the diagnostic report includes the candidate fault codes and troubleshooting suggestions; The processing module is also used to return the diagnostic report to the interaction module for display.

7. The monitoring device according to claim 5, characterized in that, The monitoring device further includes a log acquisition module; the processing module is communicatively connected to the log acquisition module. The processing module is further configured to: in response to the log export instruction sent by the interaction module, send a log collection instruction to the log collection module; wherein the log export instruction is used to indicate the log export time period; The log collection module is used to respond to the log collection command, collect log data of the target domain controller during the log export time period, and return the log data to the processing module; The processing module returns the log data to the interaction module for display.

8. The monitoring device according to claim 7, characterized in that, The interaction module is also used to: package the target data into a file and store it in the removable storage device; The target data includes at least one of the target CAN bus data, the log data, or the diagnostic report.

9. The monitoring device according to claim 2, characterized in that, The monitoring device further includes: an installation and deployment module; the installation and deployment module and the processing module are communicatively connected; The installation and deployment module is used to pop up the access interface of the monitoring device in the display interface in response to detecting that the removable storage device is plugged into the target domain controller; In response to the determination that the access control of the access interface is triggered and the access key verification is successful, a start command is sent to the processing module; wherein, the start command is used to instruct the monitoring device to start. And, the interactive interface of the interactive module is popped up in the display interface.

10. The monitoring device according to claim 9, characterized in that, The interactive interface includes a text input box; the interactive module is further used for: A natural language fuzzy algorithm is used to determine the semantic terms in the local semantic term library that match the text command entered in the text input box; Based on the semantic terms, instructions are issued to the processing module.

11. A monitoring method, characterized in that, The method is applied to the processing module in the monitoring device as described in any one of claims 1-10; the method includes: If the first condition is met, a monitoring command is sent to the monitoring module so that the monitoring module responds to the monitoring command, collects and returns the CAN bus data of the target domain controller; wherein, the first condition is used to instruct the removable storage device to be plugged into the target domain controller with the display interface, and the monitoring device is started. In addition, the CAN bus data is forwarded to the storage module so that the storage module converts the CAN bus data into DDS messages for storage.

12. An electronic device, characterized in that, include: A processor and a memory, wherein the memory stores at least one computer program, which is loaded and executed by the processor to implement the monitoring method as described in claim 11.

Images