A vehicle bus development environment monitoring method, device, medium and product

Abstract

This application discloses a method, device, medium, and product for monitoring a vehicle bus development environment, comprising: collecting multi-dimensional monitoring data during testing in the vehicle bus development environment; establishing a correlation between the multi-dimensional monitoring data based on timestamp information and test case identifiers to obtain multi-dimensional fused data; performing rule judgment on the multi-dimensional fused data based on preset rules to generate alarm events; and sending the alarm events and the multi-dimensional fused data to a monitoring center according to preset priority rules. This improves the monitoring effect and efficiency of the vehicle bus development environment.

Description

Technical Field

[0001] This application relates to the field of vehicle development technology, and in particular to a method, device, medium and product for monitoring a vehicle bus development environment. Background Technology

[0002] Existing vehicle bus development environment monitoring solutions typically collect relatively simple types of data to achieve monitoring, resulting in fragmented and isolated monitoring data. Furthermore, they lack automated alarms, leading to untimely problem detection and impacting monitoring effectiveness, resulting in low monitoring efficiency in vehicle bus development environments.

[0003] Therefore, improving the monitoring effect and efficiency of the vehicle bus development environment is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a method, device, medium, and product for monitoring a vehicle bus development environment, which can improve the monitoring effect and efficiency of the vehicle bus development environment. The specific solution is as follows: Firstly, this application provides a method for monitoring a vehicle bus development environment, including: During testing in the vehicle bus development environment, multi-dimensional monitoring data is collected. Based on timestamp information and test case identifiers, a correlation is established between the multidimensional monitoring data to obtain multidimensional fused data; Based on preset rules, rule judgment is performed on the multi-dimensional fused data to generate alarm events; The alarm events and the multi-dimensional fused data are sent to the monitoring center according to a preset priority rule.

[0005] Optional, also includes: The state of the vehicle bus development environment is tracked using a finite state machine. When the finite state machine undergoes a state change, a state change event is generated; Accordingly, sending the alarm event and the multi-dimensional fused data to the monitoring center according to a preset priority rule includes: The alarm events, the status change events, and the multi-dimensional fused data are sent to the monitoring center according to a preset priority rule.

[0006] Optionally, the multidimensional monitoring data includes multidimensional data in the vehicle bus development environment, including target signal and target variable dimension data, simulation node operating status dimension data, device resource dimension data, and log file dimension data.

[0007] Optionally, collect target signal and target variable dimension data, including: Based on the fast data exchange protocol, data exchange commands are sent to the vehicle bus development environment according to the frequency corresponding to the data exchange group, and the signals and variables contained in the data exchange group are read to obtain the target signal and target variable dimension data.

[0008] Optionally, collect simulation node runtime status data, including: The system establishes a connection with the vehicle bus development environment through the component object model automation interface, registers event listeners, and periodically polls the simulation node collection object to collect simulation node running status dimension data.

[0009] Optionally, the alarm event, the status change event, and the multi-dimensional fused data are sent to the monitoring center according to a preset priority rule, including: Alarm events and status change events are placed in the critical priority queue, target signals and target variable dimension data in the multi-dimensional fused data are placed in the high priority queue, device resource dimension data in the multi-dimensional fused data are placed in the normal priority queue, and log file dimension data in the multi-dimensional fused data are placed in the low priority queue. The queue priorities from high to low are: critical priority queue, high priority queue, normal priority queue, and low priority queue. The alarm events, the status change events, and the multi-dimensional fused data are sent to the monitoring center through key priority queues, high priority queues, normal priority queues, and low priority queues.

[0010] Optionally, alarm events and status change events are placed in the critical priority queue, target signal and target variable dimension data from the multi-dimensional fused data are placed in the high priority queue, device resource dimension data from the multi-dimensional fused data are placed in the normal priority queue, and log file dimension data from the multi-dimensional fused data are placed in the low priority queue before the alarm events and status change events are placed in the critical priority queue, target signal and target variable dimension data from the multi-dimensional fused data are placed in the high priority queue. The alarm events, the status change events, and the numerical data in the multidimensional fused data are compressed to obtain compressed data. The compressed data, the alarm events, the status change events, and the uncompressed data in the multidimensional fused data are serialized.

[0011] Secondly, this application provides a vehicle bus development environment monitoring device, comprising: The data acquisition module is used to collect multi-dimensional monitoring data during testing in the vehicle bus development environment; The data fusion module is used to establish a correlation between the multidimensional monitoring data based on timestamp information and test case identifiers to obtain multidimensional fused data; The alarm generation module is used to perform rule judgment on the multi-dimensional fused data based on preset rules and generate alarm events; The data sending module is used to send the alarm events and the multi-dimensional fused data to the monitoring center according to a preset priority rule.

[0012] Thirdly, this application provides an electronic device, including a memory and a processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to implement the aforementioned vehicle bus development environment monitoring method.

[0013] Fourthly, this application provides a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned vehicle bus development environment monitoring method.

[0014] Fifthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the aforementioned vehicle bus development environment monitoring method.

[0015] As can be seen from the above scheme, the present invention provides a vehicle bus development environment monitoring method, including: collecting multi-dimensional monitoring data during the testing process in the vehicle bus development environment; establishing a correlation between the multi-dimensional monitoring data based on timestamp information and test case identifiers to obtain multi-dimensional fused data; performing rule judgment on the multi-dimensional fused data based on preset rules to generate alarm events; and sending the alarm events and the multi-dimensional fused data to the monitoring center according to preset priority rules.

[0016] As can be seen, the beneficial effects of this application are as follows: During the testing process in the vehicle bus development environment, multi-dimensional monitoring data can be collected, and a correlation relationship can be established between the multi-dimensional monitoring data based on timestamp information and test case identifiers to obtain multi-dimensional fused data, avoiding data fragmentation and facilitating rapid problem location. Furthermore, based on preset rules, the multi-dimensional fused data can be judged to generate alarm events, enabling timely alarms. The alarm events and multi-dimensional fused data are sent to the monitoring center according to preset priority rules so that the monitoring center can handle them in a timely manner and locate the problem. This can improve the monitoring effect and efficiency of the vehicle bus development environment.

[0017] Correspondingly, the vehicle bus development environment monitoring device, equipment, and readable storage medium provided in this application also have the above-mentioned technical effects. Attached Figure Description

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

[0019] Figure 1 A flowchart of a vehicle bus development environment monitoring method provided in this application embodiment; Figure 2 A schematic diagram of a vehicle bus development environment monitoring method provided in this application embodiment; Figure 3 A schematic diagram of a vehicle bus development environment monitoring device provided in this application embodiment; Figure 4 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] Traditional monitoring technologies based on the CANoe (CAN Open Environment, a bus development environment developed for automotive buses) Automation Interface rely on CANoe's COM (Component Object Model)-based automation interface, allowing external programs to control CANoe programmatically. CAN (Controller Area Network, an internationally standardized serial communication protocol) provides this interface. However, it can only acquire the macroscopic state (running / stopping) of the CANoe, failing to capture the fine-grained state of simulation nodes; it cannot monitor real-time bus load trends; it cannot obtain the execution status and variable values ​​of the CAPL (CAN Access Programming Language) program; and its polling interval is typically on the order of seconds, resulting in poor real-time performance. Vector hardware status monitoring technology (VH6501 / VN series) suffers from several drawbacks: monitoring data is disconnected from test business logic; interfaces of various hardware devices are inconsistent (VN1630, VN1640, VH6501, etc.); a unified time synchronization mechanism is lacking; and it cannot monitor the test execution status at the software level. Currently, remote desktop / virtual network computing monitoring technology is based on RDP (Remote Desktop Protocol) or VNC (Virtual Network Computing) to achieve remote viewing through image transmission. However, this requires manual observation and judgment and cannot achieve automated monitoring and alarms.

[0022] Currently, there are issues with fragmented and isolated monitoring data, a lack of unified format for various monitoring data types, and the inability to obtain log traces. Real-time performance bottlenecks also exist due to significant latency in real-time communication caused by COM automation, and other polling methods incurring substantial overhead and costs. Furthermore, CANoe professional status monitoring lacks certain details. This application provides a method, device, medium, and product for monitoring vehicle bus development environments, which can improve the monitoring effect and efficiency of vehicle bus development environments.

[0023] See Figure 1 As shown in the figure, this application discloses a vehicle bus development environment monitoring method, including: Step S11: During the testing process in the vehicle bus development environment, collect multi-dimensional monitoring data.

[0024] The vehicle bus development environment monitoring method provided in this application is applied to a monitoring agent. The vehicle bus development environment can be CANoe, and the monitoring agent can be deployed on the same computer device as the vehicle bus development environment. This embodiment can be applied to HIL (Hardware-in-the-Loop) scenarios. Hardware-in-the-Loop simulation connects a real controller to a fake controlled object, performing comprehensive testing of the controller in an efficient and low-cost manner. It is a development and testing technology for complex device controllers. By connecting to a real controller, it uses or partially uses a real-time simulation model to simulate the controlled object and system operating environment, achieving simulation testing of the entire system. Scenario description files in XML (Extensible Markup Language) format, defined by .xosc (OpenScenario standard), can be used.

[0025] In this embodiment, the multidimensional monitoring data includes multidimensional data in the vehicle bus development environment, including target signal and target variable dimension data, simulation node operating status dimension data, device resource dimension data, and log file dimension data.

[0026] In other words, this application embodiment collects multi-dimensional monitoring data through a monitoring agent. The multi-dimensional monitoring data includes multi-dimensional data in the vehicle bus development environment, including target signal and target variable dimension data, simulation node operating status dimension data, device resource dimension data, and log file dimension data. Specifically, the target signal and target variable dimension data can be bus signal values ​​and system variable values ​​read from CANoe. The simulation node operating status dimension data can be simulation node status data read from CANoe. The device resource dimension data is the CPU (Central Processing Unit), memory, disk, and network resource utilization rates read from a bench PC (i.e., a Personal Computer). The bench PC is the computer device on which CANoe runs. The log file dimension data can be test events and result records parsed from CANoe log files.

[0027] Furthermore, acquiring target signal and target variable dimension data may include: sending data exchange commands to the vehicle bus development environment according to the frequency corresponding to the data exchange group based on a fast data exchange protocol, reading the signals and variables contained in the data exchange group, and obtaining target signal and target variable dimension data.

[0028] This embodiment utilizes an FDX (Fast Data Exchange) data collector: based on the official SDK (Software Development Kit), it periodically sends DataExchange commands to the CANoe according to FDXDescription.xml (FDX description XML configuration file) to read groups of signals and variables. The frequency is configurable (e.g., 10ms for high-speed signals, 1s for ordinary variables). In this context, a group is a predefined data exchange group in the FDX protocol. Based on the FDX protocol, data exchange commands are periodically sent to the CANoe at a configured frequency according to the predefined data exchange groups. The signals and variables contained in each group are read respectively. Signals can include physical signals actually transmitted on the bus, such as CAN, LIN (Local Interconnect Network), FlexRay, and Ethernet signals, which are defined in database files such as DBC (Database CAN, CAN bus database file), such as EngineSpeed ​​and VehicleSpeed. Variables can include system variables, environment variables, CAPL variables, and software variables that run inside the CANoe, used to pass status between CAPL programs or test modules, such as TestCaseStatus and ErrorCounter.

[0029] FDX is an advanced feature module in the CANoe software, focusing on efficient data capture and analysis. FDX enables rapid data stream processing, improving communication efficiency while simplifying the data capture and parsing process. When handling large volumes of data transmission, FDX provides real-time visualization and monitoring of the data stream, helping engineers quickly locate problems and optimize system performance.

[0030] The process of collecting simulation node running status data may include: establishing a connection with the vehicle bus development environment through the component object model automation interface, registering an event listener and periodically polling the simulation node collection object to collect simulation node running status data.

[0031] This application embodiment uses a COM listener to obtain simulation node runtime status dimension data. Specifically, it establishes a connection with the CANoe COM automation interface using win32com, registers event listeners (such as OnMeasurementStart and OnTraceWrite), and periodically polls objects like CANoe.Application.Configuration.Simulation.Nodes to obtain deep states that FDX cannot reach. CANoe.Application.Configuration.Simulation.Nodes is a key access path in the CANoe COM API object model, used to traverse the runtime status of simulation nodes (i.e., software-simulated virtual electronic control units). This information cannot be obtained through the FDX data channel and is obtained through active querying via the COM interface.

[0032] Furthermore, a system monitor can be established to collect data such as hardware resource utilization, process lists, and network connection status of the rack PC using libraries like psutil. Additionally, a log tracker can be set up to track (tail -f) the .asc and .blf logs or test report files generated by CANoe in real time, using regular expressions or a parser to extract key test events and results. Key test events can include landmark events during bus communication such as diagnostic fault code triggering, error frame generation, message timeout, bus shutdown, and changes in node start / stop status. Key test results can include test case execution conclusions (pass or fail), comparisons of expected and actual assertion values, test failure descriptions, and test coverage metrics.

[0033] Step S12: Establish a correlation between the multidimensional monitoring data based on the timestamp information and the test case identifier to obtain multidimensional fused data.

[0034] The timestamp information can be the timestamp of the data itself. If the data itself does not have a timestamp, it can be the timestamp marked during data collection, or all timestamps marked during data collection can be used. Data with the same timestamp and the same test case can be associated, or a time window can be set to associate data of the same test case within the same time window. This embodiment can acquire data collected by all collectors and associate it with the same context (such as the test case ID) through unified timestamp alignment (using a high-precision clock source). For example, the EngineSpeed ​​drop signal read by FDX can be associated with the fault node status change event captured by COM, and the DTC (Diagnostic Trouble Code) trigger record in the system log.

[0035] Step S13: Perform rule judgment on the multidimensional fused data based on preset rules and generate alarm events.

[0036] This embodiment can create preset rules for target data types to determine whether an alarm is needed. This embodiment can create a rule engine to perform lightweight, low-latency rule judgments. For example: if the CPU temperature > 85°C for 5 seconds, the data is immediately marked as a high-temperature alarm and the reporting priority is increased; if the bus error frame rate > 100 / s, a local snapshot is triggered to save the context data and generate an alarm.

[0037] In an optional implementation, the method further includes: tracking the state of the vehicle bus development environment through a finite state machine; and generating a state change event when the finite state machine undergoes a state change.

[0038] This application embodiment's monitoring agent also includes a finite state machine for tracking the state of the vehicle bus development environment. The state machine maintains the current state of the agent and CANoe (e.g., IDLE, MEASUREMENT_RUNNING, TEST_CASE_EXECUTING, ERROR). Any data input may trigger a state transition; for example, the finite state machine performs state transitions based on state-related events in multi-dimensional fused data, with state change times being high-priority reporting events. The idle state indicates that the CANoe application has started, but measurement has not yet begun. The measurement running state indicates that CANoe has started bus measurement, the simulation node is active, and FDX data is flowing in normally, but the test module has not yet executed test cases. The test case execution state indicates that, based on bus measurement operation, the test module is executing test cases. The error state indicates that the monitoring agent detects an anomaly in CANoe.

[0039] When a finite state machine undergoes a state change, a state change event is generated. This event can include the state before the change, the state after the change, the reason for the change, and a timestamp of the change. State change events are assigned high priority so that they are sent to the monitoring center immediately after generation, allowing testers to promptly understand changes in the operational status of the test system.

[0040] Furthermore, in this embodiment, the alarm events, the state change events, and the numerical data in the multidimensional fused data can be compressed to obtain compressed data; the compressed data, along with the uncompressed data in the alarm events, the state change events, and the multidimensional fused data, can then be serialized. That is, the data sent to the monitoring center can be the serialized data. In an optional embodiment, only the change amount can be transmitted for the numerical data.

[0041] Step S14: Send the alarm event and the multi-dimensional fused data to the monitoring center according to the preset priority rules.

[0042] This embodiment maintains one primary WebSocket connection and one backup HTTP / 2 (Hypertext Transfer Protocol / 2) stream with the monitoring center. It implements a complete handshake, authentication, heartbeat, and automatic reconnection mechanism. A persistent bidirectional communication connection with the monitoring center can be established via the WebSocket protocol, supporting real-time push notifications of alarm events. During connection establishment, a complete handshake, token authentication, and heartbeat detection mechanism are performed. When the WebSocket connection becomes unavailable, it automatically switches to the HTTP / 2 protocol as the backup transmission channel.

[0043] In an optional manner, sending the alarm event and the multidimensional fused data to the monitoring center according to a preset priority rule includes: sending the alarm event, the status change event, and the multidimensional fused data to the monitoring center according to a preset priority rule.

[0044] Furthermore, sending the alarm events, the status change events, and the multidimensional fused data to the monitoring center according to a preset priority rule may include: placing the alarm events and status change events in a critical priority queue, placing the target signal and target variable dimension data in the multidimensional fused data in a high priority queue, placing the device resource dimension data in the multidimensional fused data in a normal priority queue, and placing the log file dimension data in the multidimensional fused data in a low priority queue, wherein the queue priorities from high to low are critical priority queue, high priority queue, normal priority queue, and low priority queue; and sending the alarm events, the status change events, and the multidimensional fused data to the monitoring center through the critical priority queue, high priority queue, normal priority queue, and low priority queue.

[0045] In addition, in the event of network connectivity issues or unreachability of the monitoring center, unacknowledged data packets are persistently stored in a local cache (such as an SQLite database or a memory-mapped file). Once the network is restored, the cached data is resent according to the above priority order to ensure the integrity and continuity of monitoring data.

[0046] As can be seen, during the testing process in the vehicle bus development environment, this embodiment of the application can collect multi-dimensional monitoring data, establish correlations between the multi-dimensional monitoring data based on timestamp information and test case identifiers, and obtain multi-dimensional fused data, avoiding data fragmentation and facilitating rapid problem location. Furthermore, based on preset rules, the multi-dimensional fused data is used to perform rule judgments to generate alarm events, enabling timely alarms. The alarm events and multi-dimensional fused data are sent to the monitoring center according to preset priority rules so that the monitoring center can handle them in a timely manner and locate the problem. This can improve the monitoring effect and efficiency of the vehicle bus development environment.

[0047] Further, see Figure 2 As shown, Figure 2 This application provides a schematic diagram of a vehicle bus development environment monitoring method. The collaborative relationships and data flow paths of the various modules within the monitoring agent are shown below. Figure 2 As shown. The monitoring agent can include a data acquisition layer, a core processing layer, and a communication management layer. The CANoe project is the CANoe simulation test configuration file, which contains network configuration, database references, simulation node settings, test modules, and measurement configurations. After the project is loaded and run, CANoe enters the measurement state, and the FDX collector and COM listener can collect bus signals, listen for node status, and test events in its operating environment.

[0048] The data acquisition layer includes: FDX Collector: Based on the official SDK, it periodically sends DataExchange commands to CANoe according to FDXDescription.xml, reading groups of signals and variables. The frequency is configurable (e.g., 10ms for high-speed signals, 1s for ordinary variables). COM Listener: Uses win32com to establish a connection with CANoe's COM automation interface, registers event listeners (e.g., OnMeasurementStart, OnTraceWrite), and periodically polls objects such as CANoe.Application.Configuration.Simulation.Nodes to obtain deep states that FDX cannot reach. System Monitor: Uses libraries such as psutil to collect hardware resource utilization, process lists, and network connection status of the test bench PC. Log Tracker: Tails (tail-f) .asc and .blf logs or test report files generated by CANoe in real time, using regular expressions or parsers to extract key test events and results. It collects information such as specific signals sent during the test, node start and stop timestamps, actual execution cycle values, test execution results, and process monitoring.

[0049] In the core processing layer, the data fusion engine receives data from all collectors, aligns it using a unified timestamp (using a high-precision clock source), and associates it with the same context (such as a test case ID). For example, it associates the EngineSpeed ​​drop signal read by FDX with the state change event of the fault node captured by COM, and the DTC trigger record in the system log. The state machine maintains the current state of the agent and CANoe (such as IDLE, MEASUREMENT_RUNNING, TEST_CASE_EXECUTING, ERROR). Any data input can trigger a state transition, and state changes themselves are high-priority reporting events. The rules engine (edge ​​side) performs lightweight, low-latency rule judgments. For example: "If the CPU temperature > 85°C for 5 seconds, immediately mark the data as a high-temperature alarm and increase the reporting priority"; "If the bus error frame rate > 100 / s, trigger local snapshot saving." Data compression and serialization: Apply Delta Encoding (transmitting only changes) or simple lossy compression (e.g., retaining 2 decimal places) to periodically collected numerical data. Then use Protobuf (optimal performance) or JSON (good readability) for serialization.

[0050] In the communication management layer, the uplink connection manager maintains and monitors one primary WebSocket connection and one backup HTTP / 2 stream. It implements a complete handshake, authentication (token), heartbeat, and automatic reconnection mechanism. The priority transmission queue is a multi-level queue (e.g., CRITICAL, HIGH, NORMAL, LOW). Alarm events and state changes enter the CRITICAL queue, real-time signal data enters the HIGH queue, resource monitoring enters the NORMAL queue, and log content enters the LOW queue. The queue manager ensures that high-priority data is sent first. Local caching and resuming transmission after disconnection: Unacknowledged data packets are persisted using SQLite or memory-mapped files. After network recovery, they are retransmitted according to priority. A recent complete context snapshot is also cached for fault diagnosis.

[0051] This approach significantly improves testing efficiency and real-time performance. By replacing the traditional polling mode with a push mode based on the FDX protocol, and implementing an event-driven mechanism in the CANoe monitoring agent, fault detection time is shortened, resource optimization is achieved, host resources are saved, and resource allocation is optimized, improving utilization. Furthermore, there's no need to handle the low-level details of FDX (such as framing, timeouts, and retries); high-level APIs such as subscribing to variables and sending commands can be used directly, improving development efficiency and elevating system reliability from simply delivering as much as possible with FDX to ensuring delivery. It also solves the data silo problem in traditional monitoring. When a test fails, it simultaneously provides bus signal anomaly curves (FDX), node crash stack traces (COM), CPU and memory peaks (system), and test log error information (log), drastically reducing the average time to locate the root cause of the fault.

[0052] See Figure 3 As shown, this application embodiment provides a vehicle bus development environment monitoring device, including: Data acquisition module 11 is used to collect multi-dimensional monitoring data during the testing process in the vehicle bus development environment; Data fusion module 12 is used to establish a correlation between the multidimensional monitoring data based on timestamp information and test case identifiers to obtain multidimensional fused data; Alarm generation module 13 is used to perform rule judgment on the multi-dimensional fused data based on preset rules and generate alarm events; The data sending module 14 is used to send the alarm event and the multi-dimensional fused data to the monitoring center according to a preset priority rule.

[0053] The device may further include a state tracking module for tracking the state of the vehicle bus development environment through a finite state machine; generating a state change event when the finite state machine undergoes a state change; correspondingly, the data sending module 14 is also used to send the alarm event, the state change event, and the multi-dimensional fusion data to the monitoring center according to a preset priority rule.

[0054] Furthermore, the multidimensional monitoring data includes multidimensional data in the target signal and target variable dimension data, simulation node operating status dimension data, device resource dimension data, and log file dimension data within the vehicle bus development environment.

[0055] The data acquisition module 11 can be specifically used to send data exchange commands to the vehicle bus development environment according to the frequency corresponding to the data exchange group based on the fast data exchange protocol, read the signals and variables contained in the data exchange group, and obtain the target signal and target variable dimension data.

[0056] The data acquisition module 11 can be specifically used to establish a connection with the vehicle bus development environment through the component object model automation interface, register an event listener and periodically poll the simulation node collection object to collect simulation node running status dimension data.

[0057] The data sending module 14 can be specifically used to: place alarm events and status change events in a critical priority queue, place target signal and target variable dimension data in the multi-dimensional fused data in a high priority queue, place device resource dimension data in the multi-dimensional fused data in a normal priority queue, and place log file dimension data in the multi-dimensional fused data in a low priority queue, wherein the queue priorities from high to low are critical priority queue, high priority queue, normal priority queue, and low priority queue; and send the alarm events, the status change events, and the multi-dimensional fused data to the monitoring center through the critical priority queue, high priority queue, normal priority queue, and low priority queue.

[0058] The device further includes a data processing module, configured to place alarm events and state change events in a critical priority queue, place target signal and target variable dimension data from the multidimensional fused data in a high priority queue, place device resource dimension data from the multidimensional fused data in a normal priority queue, and place log file dimension data from the multidimensional fused data in a low priority queue before compressing the alarm events, state change events, and numerical data from the multidimensional fused data to obtain compressed data; and serialize the compressed data, the alarm events, state change events, and uncompressed data from the multidimensional fused data.

[0059] As can be seen, the beneficial effects of this application are as follows: During the testing process in the vehicle bus development environment, multi-dimensional monitoring data can be collected, and a correlation relationship can be established between the multi-dimensional monitoring data based on timestamp information and test case identifiers to obtain multi-dimensional fused data, avoiding data fragmentation and facilitating rapid problem location. Furthermore, based on preset rules, the multi-dimensional fused data can be judged to generate alarm events, enabling timely alarms. The alarm events and multi-dimensional fused data are sent to the monitoring center according to preset priority rules so that the monitoring center can handle them in a timely manner and locate the problem. This can improve the monitoring effect and efficiency of the vehicle bus development environment.

[0060] See Figure 4 As shown in the figure, this application discloses an electronic device 20, including a processor 21 and a memory 22; wherein, the memory 22 is used to store a computer program; the processor 21 is used to execute the computer program, the vehicle bus development environment monitoring method disclosed in the foregoing embodiment.

[0061] The specific process of the above-mentioned vehicle bus development environment monitoring method can be found in the relevant content disclosed in the foregoing embodiments, and will not be repeated here.

[0062] Furthermore, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, and the storage method can be temporary storage or permanent storage.

[0063] In addition, the electronic device 20 also includes a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26; wherein, the power supply 23 is used to provide operating voltage for the various hardware devices on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0064] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the vehicle bus development environment monitoring method disclosed in the foregoing embodiments.

[0065] The specific process of the above-mentioned vehicle bus development environment monitoring method can be found in the relevant content disclosed in the foregoing embodiments, and will not be repeated here.

[0066] Furthermore, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the vehicle bus development environment monitoring method disclosed in the foregoing embodiments.

[0067] The specific process of the above-mentioned vehicle bus development environment monitoring method can be found in the relevant content disclosed in the foregoing embodiments, and will not be repeated here.

[0068] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0069] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0070] The above provides a detailed description of a vehicle bus development environment monitoring method, device, medium, and product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for monitoring a vehicle bus development environment, characterized in that, include: During testing in the vehicle bus development environment, multi-dimensional monitoring data is collected. Based on timestamp information and test case identifiers, a correlation is established between the multidimensional monitoring data to obtain multidimensional fused data; Based on preset rules, rule judgment is performed on the multi-dimensional fused data to generate alarm events; The alarm events and the multi-dimensional fused data are sent to the monitoring center according to a preset priority rule.

2. The vehicle bus development environment monitoring method according to claim 1, characterized in that, Also includes: The state of the vehicle bus development environment is tracked using a finite state machine. When the finite state machine undergoes a state change, a state change event is generated; Accordingly, sending the alarm event and the multi-dimensional fused data to the monitoring center according to a preset priority rule includes: The alarm events, the status change events, and the multi-dimensional fused data are sent to the monitoring center according to a preset priority rule.

3. The vehicle bus development environment monitoring method according to claim 1, characterized in that, The multidimensional monitoring data includes multidimensional data in the target signal and target variable dimension data, simulation node operating status dimension data, device resource dimension data, and log file dimension data within the vehicle bus development environment.

4. The vehicle bus development environment monitoring method according to claim 3, characterized in that, Collect target signal and target variable dimension data, including: Based on the fast data exchange protocol, data exchange commands are sent to the vehicle bus development environment according to the frequency corresponding to the data exchange group, and the signals and variables contained in the data exchange group are read to obtain the target signal and target variable dimension data.

5. The vehicle bus development environment monitoring method according to claim 3, characterized in that, Collect simulation node runtime status data, including: The system establishes a connection with the vehicle bus development environment through the component object model automation interface, registers event listeners, and periodically polls the simulation node collection object to collect simulation node running status dimension data.

6. The vehicle bus development environment monitoring method according to claim 2, characterized in that, The alarm events, the status change events, and the multi-dimensional fused data are sent to the monitoring center according to a preset priority rule, including: Alarm events and status change events are placed in the critical priority queue, target signals and target variable dimension data in the multi-dimensional fused data are placed in the high priority queue, device resource dimension data in the multi-dimensional fused data are placed in the normal priority queue, and log file dimension data in the multi-dimensional fused data are placed in the low priority queue. The queue priorities from high to low are: critical priority queue, high priority queue, normal priority queue, and low priority queue. The alarm events, the status change events, and the multi-dimensional fused data are sent to the monitoring center through key priority queues, high priority queues, normal priority queues, and low priority queues.

7. The vehicle bus development environment monitoring method according to claim 6, characterized in that, Before placing alarm events and status change events in the critical priority queue, placing target signal and target variable dimension data from the multi-dimensional fused data in the high priority queue, placing device resource dimension data from the multi-dimensional fused data in the normal priority queue, and placing log file dimension data from the multi-dimensional fused data in the low priority queue, the method further includes: The alarm events, the status change events, and the numerical data in the multidimensional fused data are compressed to obtain compressed data. The compressed data, the alarm events, the status change events, and the uncompressed data in the multidimensional fused data are serialized.

8. An electronic device, characterized in that, Includes memory and processor, wherein: The memory is used to store computer programs; The processor is configured to execute the computer program to implement the vehicle bus development environment monitoring method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, Used to store a computer program, wherein the computer program, when executed by a processor, implements the vehicle bus development environment monitoring method as described in any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the vehicle bus development environment monitoring method as described in any one of claims 1 to 7.

Images