A method, system, device and vehicle for monitoring the operating state of a vehicle SoC

Abstract

The application provides a kind of running state monitoring method, system, equipment and vehicle of vehicle-mounted SoC, it is related to vehicle-mounted chip technical field, this scheme is by deploying monitoring agent in target SoC application layer, and is combined with independent monitoring unit, realize all-around real-time monitoring to chip running state.System periodically acquires multidimensional state parameter transmission to independent unit and carries out comparison analysis: when parameter exceeds primary threshold value, generate early warning signal and save log to realize early risk early warning;When parameter exceeds secondary threshold value, trigger fault response and send forced reading instruction to target SoC.The mechanism ensures that when a serious fault occurs, the key data in the SoC memory can be forced to save to the storage unit powered by the vehicle constant power KL30.The present scheme effectively solves the defects of single monitoring dimension, log loss and early warning lag in the prior art, significantly improves the fault diagnosis capability and functional safety level of the vehicle system.

Description

Technical Field

[0001] This invention relates to the field of automotive chip technology, and in particular to a method, system, device, and vehicle for monitoring the operating status of an automotive SoC. Background Technology

[0002] With the development of automotive intelligence and connectivity, in-vehicle infotainment systems, advanced driver assistance systems, and even autonomous driving systems are increasingly reliant on high-performance system-on-a-chip (SoC). Currently, the industry mainly uses external microcontroller units as watchdogs, utilizing heartbeat signals or simple timeout mechanisms to determine if the chip has crashed. Some solutions also involve monitoring specific parameters such as voltage or temperature. However, this traditional monitoring method has significant drawbacks, including limited monitoring dimensions, easy log loss, and delayed warnings. Specifically, existing technologies mainly rely on external watchdogs for monitoring chip health, making it difficult to detect sub-health states such as performance degradation, local logic disorder, or critical path timing drift within the chip. Furthermore, when a serious chip failure leads to a sudden power-off or crash, the logs recording key information before and after the failure in memory are often lost in time, greatly hindering subsequent fault location and root cause analysis. In addition, traditional monitoring methods often generate interrupt or reset signals only after a failure occurs, lacking early warning mechanisms for potential risks and failing to provide valuable processing time for the system to perform degraded operation or safe takeover. Summary of the Invention

[0003] The purpose of this invention is to provide a method, system, device, and vehicle for monitoring the operating status of an in-vehicle SoC, in order to solve one or more technical problems existing in the prior art, and at least provide a beneficial option or create conditions to achieve full-dimensional perception and hierarchical early warning of the operating status of the in-vehicle SoC, and to preserve key operating data through a hardware forced reading mechanism independent of the SoC when a serious chip failure occurs, thereby improving the fault diagnosis capability and functional safety level of the whole vehicle system.

[0004] On the one hand, this application provides a method for monitoring the operating status of an automotive SoC, including: By deploying a monitoring agent at the application layer of the target SoC, multi-dimensional status parameters of the target SoC are periodically collected. These multi-dimensional status parameters include system-level data, chip-level data, and application-level data. The collected multidimensional state parameters are sent to an independent monitoring unit that is separate from the target SoC; In the independent monitoring unit, the received multidimensional state parameters are compared and analyzed with the pre-stored multi-level thresholds; If a parameter is detected to exceed the Level 1 warning threshold but not the Level 2 fault threshold, a Level 1 warning signal is generated and the warning log is saved; if a parameter is detected to exceed the Level 2 fault threshold, a Level 2 fault response is triggered. When a level 2 fault response is triggered, a forced read command is sent to the target SoC through the independent monitoring unit to save the key operating data in the target SoC's memory to the log storage unit powered by the vehicle's constant power supply KL30.

[0005] Furthermore, the periodic collection of multi-dimensional state parameters of the target SoC through a monitoring agent deployed at the application layer of the target SoC specifically includes: The monitoring agent program collects system-level and application-level data through the standard API interface provided by the operating system. The monitoring agent program accesses the power management chip or on-chip sensors through the target SoC's internal bus, I2C interface, or SPI interface to collect chip-level data.

[0006] Furthermore, the generation of a first-level early warning signal and the saving of the early warning log include: Bind the currently received multi-dimensional status parameters with real-time timestamps to generate early warning logs; The independent monitoring unit sends a performance degradation warning to the vehicle controller via the vehicle bus, so that the vehicle controller can perform frequency reduction or limit non-core functions.

[0007] Furthermore, the collection of multidimensional status parameters is sent to an independent monitoring unit separate from the target SoC, specifically via vehicle Ethernet, CAN FD, FlexRay, or PCIe bus.

[0008] Furthermore, when a secondary fault response is triggered, issuing a forced read command to the target SoC through the independent monitoring unit includes: When the independent monitoring unit determines that the target SoC is still responsive but is in an abnormal state, it sends a high-priority interrupt request to the monitoring agent program through a dedicated hardware interrupt line. The monitoring agent responds to the interruption request by skipping non-critical task scheduling in the interrupt service routine and directly reading predefined emergency snapshot data. The emergency snapshot data is transmitted to the independent monitoring unit via Direct Memory Access (DMA).

[0009] Furthermore, the step of issuing a forced read command to the target SoC through the independent monitoring unit when a secondary fault response is triggered also includes: When the independent monitoring unit determines that the target SoC has crashed or communication has been interrupted, it activates a preset backdoor access channel. The independent monitoring unit directly reads the memory data of the target SoC through the backdoor access channel, which includes a hardware debugging link that does not rely on the target SoC's operating system. The hardware debugging link includes a JTAG interface, an SWD interface, or a dedicated diagnostic physical pin reserved by the chip.

[0010] Furthermore, the key operational data includes: current task stack information, CPU register status, software watchdog counter value, and circular buffer log within a preset time window before the fault.

[0011] On the other hand, this application provides an in-vehicle SoC operating status monitoring system for performing the in-vehicle SoC operating status monitoring method as described in any one of claims 1 to 7; The system includes a target SoC chip and an independent monitoring unit; The target SoC chip is used to run a monitoring agent program to collect multi-dimensional status parameters and output data through a communication interface. The independent monitoring unit includes a microcontroller and a memory connected thereto; The microcontroller includes a data receiving module, a fault analysis module, and a hierarchical processing module, which are respectively configured to perform the following functions: The data receiving module is used to receive the multidimensional state parameters; The fault analysis module is used to store multi-level thresholds and analyze the received data; The hierarchical processing module is used to generate a first-level early warning signal or a second-level fault signal based on the analysis results. The system also includes a log storage unit, which is powered by the vehicle's constant power supply KL30, which is independent of the target SoC power supply domain, and is used to preserve the target SoC's critical operating data when a secondary fault signal is triggered. The independent monitoring unit and the target SoC chip belong to different power domains and clock domains.

[0012] On the other hand, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the aforementioned vehicle SoC operation status monitoring method.

[0013] On the other hand, this application provides a vehicle including the aforementioned vehicle SoC operating status monitoring system, wherein the independent monitoring unit is connected to the vehicle controller via the vehicle bus to drive the vehicle to execute safety strategies when a secondary fault is detected.

[0014] The beneficial effects of this invention are as follows: This application provides a method for monitoring the operating status of an in-vehicle SoC. This technical solution achieves comprehensive real-time monitoring of the operating status of the in-vehicle system-on-a-chip by deploying a monitoring agent program at the application layer of the target SoC and combining it with an independent monitoring unit independent of the target SoC. This method can periodically collect multi-dimensional status parameters, including system-level, chip-level, and application-level parameters, and transmit them to the independent monitoring unit for comparison and analysis. When a parameter exceeds the first-level warning threshold but does not reach the second-level fault threshold, the system generates a first-level warning signal and performs warning log saving, achieving early warning of potential risks. When a parameter exceeds the second-level fault threshold, a second-level fault response is triggered, and a forced read command is issued to the target SoC through the independent monitoring unit. This mechanism ensures that when a second-level fault response is triggered, key operating data in the target SoC's memory can be saved to a log storage unit powered by the vehicle's constant-power KL30, thereby effectively solving the problems of single monitoring dimensions, easy log loss, and delayed warnings in the prior art, significantly improving the fault diagnosis capability and functional safety level of the entire vehicle system. This application also provides systems, devices, and vehicles corresponding to the above methods. The beneficial effects of the systems, devices, and vehicles are similar to those of the above methods, and will not be described in detail here.

[0015] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0016] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0017] Figure 1 This is a flowchart of the method for monitoring the operating status of the in-vehicle SoC provided in this application; Figure 2 This is a schematic diagram of the operating status monitoring method for the in-vehicle SoC provided in this application; Figure 3 This is a structural diagram of the vehicle SoC operation status monitoring system provided in this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0020] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] With the rapid development of automotive intelligence and connectivity technologies, the electronic and electrical architecture of modern vehicles is becoming increasingly complex. Core functions such as in-vehicle infotainment systems, advanced driver assistance systems, and autonomous driving systems increasingly rely on the stable operation of high-performance system-on-a-chip (SoC). These SoCs typically integrate complex computing units and a vast software ecosystem, and their operational status directly affects the safety and reliability of the entire vehicle. However, with the increase in chip computing power and software complexity, the risk of chip failure or performance degradation also rises, placing higher demands on fault monitoring and diagnostic technologies for in-vehicle systems.

[0023] In current automotive system designs, monitoring the operational status of system-on-a-chip (SoC) typically relies on an external microcontroller unit (MCU) as a watchdog, using heartbeat signals or simple timeout mechanisms to determine if the chip is in a frozen state. This traditional monitoring method primarily focuses on the chip's on / off state, i.e., determining whether the chip is still functioning normally. Furthermore, some existing monitoring solutions also involve monitoring specific physical parameters, such as using external sensors to monitor the chip's surface temperature or supply voltage, to prevent hardware overheating or power supply anomalies.

[0024] Although the aforementioned existing technologies have ensured the security of the system to a certain extent, there are still obvious defects and shortcomings in practical applications, mainly reflected in three aspects: monitoring dimensions, log storage mechanism, and early warning timeliness.

[0025] First, existing monitoring technologies have a limited scope, making it difficult to uncover deep-seated problems within the chip. Traditional monitoring methods primarily rely on external microcontroller units for monitoring their lifespan. This approach can only determine if the chip has completely stopped responding, failing to detect sub-health states within the system-on-a-chip, such as performance degradation, localized logic disorder, and critical path timing drift. This single-dimensional monitoring method prevents the system from identifying potential risks in the early stages of a failure, only reacting after a failure has occurred and caused system crashes, lacking a comprehensive understanding of the system's operational status.

[0026] Secondly, existing technologies suffer from a significant drawback: logs are easily lost. When a system-on-a-chip (SoC) experiences a severe failure leading to a sudden power outage or complete system crash, the logs recording crucial information before and after the failure in memory often fail to be saved to non-volatile memory through normal software processes, resulting in log data loss. This log loss phenomenon greatly complicates subsequent fault location and cause analysis, making it difficult for OEMs to reproduce the fault scenario and accurately analyze the root cause of the failure, thus affecting the continuous improvement of system reliability.

[0027] Finally, existing early warning mechanisms are lagging and lack the ability to intervene in potential risks early. Traditional monitoring methods often generate interruption or reset signals only after a fault occurs, and this reactive response mechanism lacks early warning capabilities for potential risks. Because the system cannot issue warnings within the window before a fault occurs, it lacks sufficient time to perform degraded operations, save critical data, or initiate safe takeover. This delayed warning not only increases the risk of system loss of control but also limits the vehicle's ability to adopt proactive safety strategies when faced with potential faults.

[0028] In summary, the limitations of existing technologies in terms of monitoring dimensions, log preservation, and early warning timeliness make it difficult to meet the growing demands of increasingly complex vehicle systems for functional safety and fault diagnosis. There is an urgent need for a new monitoring solution that can achieve full-dimensional perception, zero log loss, and hierarchical early warning.

[0029] To address the aforementioned issues, this application proposes an innovative method and related equipment for monitoring the operational status of an onboard SoC. It constructs a comprehensive perception and hierarchical early warning architecture that coordinates a monitoring agent deployed at the application layer of the target SoC with an independent monitoring unit separate from the SoC. This solution periodically collects multi-dimensional status parameters covering system, chip, and application levels through the monitoring agent and transmits them to the independent monitoring unit for real-time comparison and analysis. Based on preset multi-level thresholds, the system can distinguish between Level 1 warnings and Level 2 faults, thereby achieving hierarchical response: a warning signal is generated and a log is saved when a Level 1 warning is detected; a forced fault response is triggered when a Level 2 fault is detected. Crucially, during the Level 2 fault response, the independent monitoring unit issues a forced read command to save critical operational data from the target SoC's memory to a log storage unit powered by the vehicle's constant-power KL30, ensuring the integrity and traceability of the fault data.

[0030] It's important to note that KL30 is a constant power supply directly connected to the car's low-voltage battery. It's unaffected by the vehicle's running status; it provides power as long as the battery has charge. It primarily powers devices that require 24 / 7 standby or data storage, such as anti-theft systems, in-vehicle clocks, and the Body Control Module (BCM)'s memory function. KL15, on the other hand, is the ignition / wake-up power supply managed by the vehicle controller. It only powers on when the vehicle is activated (e.g., when the brakes are applied to enter Ready mode). It specifically powers core devices directly related to driving, such as the instrument panel, central control screen, air conditioning, and drive motor management system. This on-demand activation logic effectively prevents the vehicle from being drained by high-power electrical appliances while parked, and also ensures the high-voltage system is safely powered only when the vehicle is ready.

[0031] First, the method for monitoring the operating status of the vehicle SoC provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0032] Reference Figure 1 The implementation of the vehicle SoC operation status monitoring method provided in this application embodiment includes, but is not limited to, the following steps.

[0033] Step S101: Periodically collect multi-dimensional status parameters of the target SoC by a monitoring agent program deployed at the application layer of the target SoC.

[0034] The multidimensional state parameters include system-level data, chip-level data, and application-level data.

[0035] Step S101 achieves comprehensive and in-depth perception of the chip's operating status. Unlike traditional technologies that rely solely on external hardware watchdogs for simple life-or-death checks, this step embeds a monitoring agent into the application layer, enabling direct acquisition of internal chip operating data. The collected multi-dimensional status parameters cover system-level, chip-level, and application-level data. This multi-dimensional acquisition method overcomes the limitations of traditional single-dimensional monitoring, not only determining whether the chip has crashed but also revealing sub-health conditions such as performance degradation, local logic disorder, or critical path timing drift within the chip. This provides a solid data foundation for subsequent accurate analysis and tiered early warning.

[0036] Step S102: The collected multidimensional state parameters are sent to an independent monitoring unit that is independent of the target SoC.

[0037] In step S102, a secure and reliable data analysis environment is constructed. Because the monitoring unit is independent of the target SoC, even if the target SoC experiences a serious failure or complete system crash, the independent monitoring unit can still function normally, receiving and processing the last status information from the target SoC. This design completely changes the traditional model of strong coupling between monitoring functions and the target chip, effectively avoiding the problem of monitoring function failure due to target chip failure, ensuring the stability and reliability of the monitoring system, and creating the preconditions for achieving critical data preservation in the event of a failure.

[0038] Step S103: In the independent monitoring unit, the received multidimensional state parameters are compared and analyzed with the pre-stored multi-level thresholds.

[0039] In step S103, a precise assessment and risk classification of the target SoC's operating status are achieved. Through preset multi-level thresholds, the system can quantitatively analyze the collected multi-dimensional data to accurately determine the chip's current operating status. This comparative analysis mechanism is the core logic for achieving graded early warning and response. It transforms complex operating states into clear warning levels, enabling the system to take corresponding countermeasures based on different risk levels, thereby improving the intelligence level and targeted response of the monitoring system.

[0040] Step S104: If the detected parameter exceeds the first-level warning threshold but does not exceed the second-level fault threshold, generate a first-level warning signal and save the warning log; if the detected parameter exceeds the second-level fault threshold, trigger the second-level fault response.

[0041] In step S104, a tiered response mechanism was established, realizing a shift from passive response to proactive prevention. The generation of the Level 1 warning signal provides the system with valuable early warning, allowing sufficient time for the system to perform degraded operation, save critical data, or initiate safe takeover, avoiding the warning lag defects of traditional technologies. The triggering of the Level 2 fault response ensures that the system can immediately take mandatory measures in the event of a serious fault, safeguarding the safety of the entire vehicle.

[0042] In step S105, when a level 2 fault response is triggered, a forced read command is sent to the target SoC through the independent monitoring unit to save the key operating data in the target SoC memory to the log storage unit powered by the vehicle's constant power supply KL30.

[0043] Step S105 addresses the problem of fault log loss in existing technologies. By issuing a forced read command from an independent monitoring unit, critical operational data in the target SoC's memory can be salvaged and retrieved in the extremely short time before the SoC completely loses response or power. Since the log storage unit is powered by the vehicle's constant-power KL30, the data is fully preserved even if the target SoC is powered off. This provides complete and reliable data support for subsequent fault location, root cause analysis, and system improvement, significantly enhancing the vehicle system's fault diagnosis capabilities and functional safety level.

[0044] In some embodiments of this application, step S101 involves periodically collecting multi-dimensional state parameters of the target SoC through a monitoring agent deployed at the application layer of the target SoC, specifically including the following steps.

[0045] Step S201: The monitoring agent collects system-level data and application-level data through the standard API interface provided by the operating system.

[0046] Step S201 implements non-intrusive, standardized monitoring of the software-level operational status. This step utilizes interfaces natively supported by the operating system for data collection, ensuring not only the compatibility and stability of the monitoring process and avoiding interference with the normal business logic of the target SoC, but also efficiently acquiring key indicators reflecting the overall system load and application health status.

[0047] In this way, the system can monitor core information such as CPU utilization, memory usage, disk read / write speed, and the running status of critical application processes in real time. This provides accurate data for judging whether the software system has resource bottlenecks, infinite loops, or service anomalies, thus transforming the blind spots of traditional monitoring into observable quantitative parameters.

[0048] In step S202, the monitoring agent program accesses the power management chip or on-chip sensors through the target SoC's internal bus, I2C interface, or SPI interface to collect chip-level data.

[0049] In step S202, a cross-level monitoring bridge from software to hardware is constructed, enabling precise perception of the physical hardware status. Utilizing these low-level hardware communication interfaces, the monitoring agent program can directly read the power supply voltage and current intensity provided by the power management chip, as well as hard indicators such as chip junction temperature and key module clock frequency fed back by on-chip sensors.

[0050] This method of directly accessing hardware sensors breaks through the limitations of relying solely on software heartbeat signals to determine faults. It can promptly detect hardware vulnerabilities caused by power fluctuations, overheating, or clock anomalies, ensuring that the system can immediately capture relevant signals when performance degradation or potential faults occur at the hardware level. This provides solid physical layer data support for achieving full-dimensional state perception and early warning.

[0051] In some embodiments of this application, in step S102, the collected multidimensional state parameters are sent to an independent monitoring unit independent of the target SoC. Specifically, the transmission is carried out through vehicle Ethernet, CAN FD, FlexRay or PCIe bus, thus constructing a high-speed, stable and reliable heterogeneous data transmission channel.

[0052] Because the independent monitoring unit is physically independent of the target SoC, utilizing these mature vehicle communication buses for data interaction not only achieves physical isolation between monitoring data and vehicle business data, preventing monitoring tasks from consuming the target SoC's core computing resources, but also ensures that status parameters can still be transmitted in real time and completely even when the target SoC experiences severe lag or partial failure. This design completely breaks the silo effect of data being confined to a single chip in traditional monitoring solutions, providing a solid data link foundation for independent monitoring units to perform real-time external analysis and arbitration.

[0053] Specifically, using bus technologies such as CAN FD and automotive Ethernet can fully meet the stringent requirements for bandwidth and real-time performance in the transmission of multi-dimensional status parameters. For example, the CAN FD protocol supports data transmission rates of up to 5Mbps or even 8Mbps, and the data capacity per frame is significantly increased, making it very suitable for transmitting diagnostic and status data with high real-time requirements, such as fault codes and sensor values; while PCIe or automotive Ethernet can provide extremely high bandwidth, suitable for the rapid transfer of large volumes of system logs or application-level data.

[0054] Through these automotive-grade communication protocols, the system can ensure that the massive amounts of multi-dimensional data (covering system, chip, and application levels) collected by the monitoring agent can be delivered to the independent monitoring unit with low latency. This allows the independent monitoring unit to perform accurate threshold comparisons and risk assessments based on the latest and most comprehensive data, greatly improving the response speed and accuracy of the vehicle system status monitoring.

[0055] In some embodiments of this application, step S104, generating a first-level warning signal and saving the warning log, includes the following steps.

[0056] Step S301: Bind the currently received multidimensional status parameters with the real-time timestamp to generate an early warning log.

[0057] In step S301, a traceable operational profile with precise timing characteristics is established for the system. By combining the collected system-level, chip-level, and application-level data with strict timestamp information, the system can not only record the specific state when the fault occurred, but also reconstruct the sequence and evolution trajectory of abnormal parameter changes.

[0058] This time-based logging method greatly improves the efficiency of subsequent fault review and root cause analysis, enabling technicians to accurately pinpoint the initial moment of the problem. It effectively avoids the problems of ambiguous fault location or difficulty in correlating log data caused by the lack of time sequence information in traditional monitoring, and provides detailed and reliable data support for continuous system optimization.

[0059] In step S302, the independent monitoring unit sends a performance degradation prompt to the vehicle controller via the vehicle bus, so that the vehicle controller can perform frequency reduction or limit non-core functions.

[0060] In step S302, an active system safety protection and fault mitigation mechanism is established. When abnormal parameters are detected but have not yet reached the level 2 fault threshold for complete failure, the independent monitoring unit can quickly intervene and notify the vehicle controller, enabling it to proactively take preventative measures such as reducing the frequency of operation and shutting down the entertainment system.

[0061] This mechanism not only effectively reduces the load and heat generation of the target SoC, preventing the sub-healthy state from further deteriorating into a serious failure, but also maximizes the safety and stability of the vehicle's core driving functions, achieving a qualitative leap from passively waiting for failures to occur to actively intervening in risk management, and significantly improving the functional safety level of the entire vehicle system.

[0062] In some embodiments of this application, step S105, when a secondary fault response is triggered, sends a forced read command to the target SoC through an independent monitoring unit, including the following steps.

[0063] Step S401: When the independent monitoring unit determines that the target SoC can still respond but is in an abnormal state, it sends a high-priority interrupt request to the monitoring agent program through a dedicated hardware interrupt line.

[0064] In step S401, an emergency intervention channel is established that bypasses conventional software scheduling and directly reaches the underlying layer. A dedicated hardware interrupt line is used to send high-priority requests, ensuring that monitoring commands are captured and responded to immediately even in abnormal states such as extreme resource constraints on the target SoC, task queue congestion, or minor deadlock. This mechanism overcomes the potential delays and omissions associated with traditional software polling or ordinary message passing, providing the most reliable triggering guarantee for rescuing critical data in a very short time, demonstrating the real-time and mandatory nature of hardware-level monitoring.

[0065] Step S402: Monitor the agent program's response to the interrupt request, skip non-critical task scheduling in the interrupt service routine, and directly read the predefined emergency snapshot data.

[0066] In step S402, data preservation under fault scenarios is implemented. During the critical moment of triggering a level-two fault response, system time is extremely valuable. The monitoring agent program, by directly shielding or skipping all non-core business logic and task scheduling within the interrupt service routine, can minimize response latency and concentrate precious CPU computing power and time on reading the most critical predefined emergency snapshot data. This "prioritize the big picture" strategy ensures that, within the millisecond window before a complete system crash or power outage, the most valuable core operational information for fault root cause analysis can be extracted first, effectively avoiding the problem of critical logs not being saved in time due to system freezes.

[0067] Step S403: Transfer the emergency snapshot data to the independent monitoring unit via Direct Memory Access (DMA).

[0068] In step S403, the critical data transfer across chips was completed with maximum efficiency and minimum CPU utilization. Utilizing direct memory access (DMI) technology, the data transfer process no longer relies on instruction intervention from the target SoC's central processing unit (CPU). Instead, the DMA controller directly establishes a high-speed path between memory and the communication interface. This not only significantly improves data transfer speed, ensuring that massive amounts of snapshot data can be completely exported in a very short time, but also further frees up the CPU resources of the target SoC, which is already under extremely high load. This prevents the risk of system crashes from being exacerbated by excessive data copying tasks, thus providing a robust hardware-level transmission guarantee for independent monitoring units to receive fault site data completely and without loss.

[0069] In some embodiments of this application, step S105, when triggering a level 2 fault response, sends a forced read command to the target SoC through an independent monitoring unit, and also includes the following steps.

[0070] Step S501: When the independent monitoring unit determines that the target SoC has crashed or communication has been interrupted, the preset backdoor access channel is activated.

[0071] In step S501, in extreme cases where the target SoC experiences a severe failure leading to a complete system crash, inability to respond to any regular software commands, or a complete interruption of vehicle bus communication, the independent monitoring unit can quickly identify this fatal state and automatically trigger a preset physical-level backdoor access channel. This mechanism breaks the deadlock of traditional monitoring methods being helpless after the chip has completely crashed, ensuring that even if the main control program of the target SoC has stopped running, the system still has the ability to forcibly intervene from the outside and obtain the internal state of the chip, providing a crucial prerequisite for subsequently salvaging valuable fault scene data.

[0072] In step S502, the independent monitoring unit directly reads the memory data of the target SoC through the backdoor access channel, which includes a hardware debugging link that does not depend on the target SoC operating system.

[0073] The hardware debugging link includes a JTAG interface, an SWD interface, or a dedicated diagnostic physical pin reserved on the chip.

[0074] In step S502, lossless extraction of the internal operating data of the faulty chip is achieved. Since hardware debugging interfaces such as JTAG and SWD are physical testing and debugging interfaces at the chip's lowest level, they possess supreme access to CPU core registers, memory address space, and peripherals, and are completely independent of the target SoC's upper-level operating system and applications. This means that even if the automotive SoC's operating system has crashed or its kernel is completely frozen, the independent monitoring unit can still utilize these hardware debugging interfaces to bypass the failed software layer and directly penetrate to the hardware layer, completely reading the key register states, stack information, and core variables recorded in memory at the moment the fault occurred.

[0075] This hardware-level forced read method, which does not rely on the operating system, completely solves the industry problem of easy loss of memory data and difficulty in tracing the root cause of failure caused by chip crashes in existing technologies, and greatly improves the fault diagnosis capability and functional safety level of the whole vehicle system.

[0076] In some embodiments of this application, in step S105, the key operational data includes: current task stack information, CPU register status, software watchdog counter value, and circular buffer log within a preset time window before the fault.

[0077] When an onboard SoC triggers a Level 2 fault response, the system is often in a highly unstable critical state, making it crucial to accurately salvage the most diagnostically valuable data. By saving this specific critical data to a log storage unit powered by the vehicle's constant-power KL30, it is possible to ensure that even after a complete power outage or restart, technicians can still obtain a complete snapshot of the scene at the moment the fault occurred. This completely solves the pain points of traditional technologies, such as the ease of losing fault logs and the difficulty in reproducing problems, providing solid data support for improving the functional safety level of the entire vehicle system.

[0078] Specifically, saving the current task stack information and CPU register state allows developers to accurately reconstruct the program execution context at the time of the failure. By analyzing the program counter in the registers, the link register, and the function call chain in the stack, the specific line of code and instruction address that caused the crash or exception can be quickly located, determining whether there are underlying software errors such as null pointer references, stack overflows, or illegal instruction jumps. Recording the software watchdog counter value helps analyze the system's task scheduling health, determining whether the failure was caused by a high-priority task occupying the CPU for an extended period, preventing the watchdog from being fed in time, thus revealing internal resource contention or deadlock issues within the system.

[0079] Furthermore, extracting the circular buffer logs within a preset time window prior to the failure allows for a complete retrospective analysis of the system's operational trajectory and key event sequences during the period leading up to the crash. This time-series log data provides valuable contextual information for analyzing the triggering factors and evolution of the failure, enabling technicians not only to know "where things went wrong" but also to clearly understand "how things went wrong step by step," thereby significantly shortening the troubleshooting cycle for complex and intermittent failures.

[0080] In some embodiments of this application, reference is made to Figure 2 This paper demonstrates the implementation principle of the vehicle SoC operating status monitoring method provided in this application. First, the vehicle system is powered on and initialized, and the monitoring agent begins collecting multi-dimensional status data. Then, the system determines whether the data exceeds a primary threshold (warning threshold). If it does not exceed the threshold, monitoring continues; if it does exceed the threshold, it further determines whether a secondary threshold (fault threshold) is also exceeded. If only the primary threshold is exceeded, the system generates a primary warning signal and executes a primary response (such as saving a warning log or issuing a warning notification). If the secondary threshold is also exceeded, the system performs secondary fault detection and trigger mode determination, selecting either "interrupt forced export mode" or "debugging interface direct read mode" to acquire data based on whether the SoC has crashed or communication has been interrupted. The acquired data is written to the log storage unit powered by the KL30, and then the system issues an emergency fault warning, ultimately leading to the vehicle controller executing safety policies.

[0081] Secondly, this application provides an in-vehicle SoC operating status monitoring system for executing the aforementioned in-vehicle SoC operating status monitoring method. The system includes a target SoC chip and an independent monitoring unit. The target SoC chip runs a monitoring agent program to collect multi-dimensional status parameters and outputs data through a communication interface. The independent monitoring unit includes a microcontroller and a memory connected thereto.

[0082] Specifically, the target SoC chip, as the core processing unit of the in-vehicle computing platform, bears the crucial responsibility of comprehensive state perception and data output in this system. It not only carries and runs the monitoring agent program, which periodically collects multi-dimensional state parameters covering system, chip, and application levels, but also, as the monitored entity, transmits the collected real-time data externally through communication interfaces such as in-vehicle Ethernet and CAN FD. The normal operation of the target SoC chip is fundamental to the intelligent functions of the entire vehicle, and in this system, it is the initiator of the proactive monitoring mechanism, providing the most basic and critical operational data support for subsequent fault warnings and diagnosis.

[0083] The independent monitoring unit, with its built-in microcontroller and connected memory, forms a monitoring and analysis environment completely independent of the target SoC chip. This unit receives multi-dimensional status parameters from the target SoC and performs real-time comparison and analysis based on pre-stored multi-level thresholds to accurately determine the system status and trigger corresponding first-level early warnings or second-level fault responses. In the event of a serious fault, it can also forcibly read and preserve the target SoC's critical operational data through hardware interrupts or backdoor debugging links.

[0084] In some embodiments of this application, the independent monitoring unit and the target SoC chip belong to different power and clock domains. This physical isolation design is the cornerstone of the high reliability and functional safety of the entire monitoring system. This means that even if the target SoC chip is completely paralyzed due to power failure, clock drift, or severe crash, the independent monitoring unit can still maintain normal operation by relying on its own independent power supply and clock signal, unaffected by the cascading failure of the target chip. This design ensures that the monitoring system still has independent judgment and data recovery capabilities under extreme failure scenarios, completely solving the problem of synchronous loss of monitoring functions due to common cause failure in traditional monitoring solutions, and providing a solid hardware guarantee for the safety of the entire vehicle system.

[0085] In some embodiments of this application, the microcontroller includes a data receiving module, a fault analysis module, and a hierarchical processing module, which are respectively configured to perform the following functions: The data receiving module receives multi-dimensional status parameters. Specifically, it continuously and stably receives multi-dimensional status parameters periodically collected and sent by the target SoC chip's application-layer monitoring agent via high-speed communication buses such as automotive Ethernet, CAN FD, FlexRay, or PCIe. This module ensures that massive amounts of monitoring data at the system, chip, and application levels can be accurately transmitted across chip boundaries to the independent monitoring unit, providing a solid and continuous data flow foundation for subsequent in-depth analysis and fault diagnosis.

[0086] The fault analysis module stores multi-level thresholds and analyzes received data. Internally, this module pre-stores multi-level thresholds set for different state parameters. Upon receiving real-time multi-dimensional state parameters from the data receiving module, it quickly and accurately compares this dynamic data with the pre-stored standard thresholds. Through this quantitative comparison mechanism, the fault analysis module can accurately determine whether the target SoC is currently in a state of normal fluctuation, sub-health warning, or severe fault, thus providing an objective and accurate decision-making basis for the system's graded response.

[0087] The tiered processing module generates either a Level 1 warning signal or a Level 2 fault signal based on the analysis results. When the analysis results show that the parameter anomaly exceeds the Level 1 warning threshold but does not reach the Level 2 fault threshold, the module immediately generates a Level 1 warning signal and triggers preventative operations such as saving the warning log, prompting the vehicle system to implement degradation strategies such as frequency reduction or limiting non-core functions. Conversely, when the detected parameter deterioration exceeds the Level 2 fault threshold, it decisively triggers a Level 2 fault signal, initiating an emergency fault response process that includes forced memory reads and activation of backdoor access channels. This tiered processing mechanism effectively achieves comprehensive coverage from proactive defense to reactive fallback, maximizing the functional safety of the vehicle when facing different levels of risk.

[0088] In some embodiments of this application, the system further includes a log storage unit, which is powered by a constant vehicle power supply KL30 independent of the target SoC power supply domain, and is used to preserve the critical operating data of the target SoC when a secondary fault signal is triggered.

[0089] Regardless of whether the target SoC chip is powered off, reset, or completely paralyzed due to a serious fault, the memory unit can always maintain a stable operating state. This independent and uninterrupted power supply design fundamentally solves the industry pain point of data loss due to sudden power outages in traditional embedded systems, providing the most reliable hardware environment guarantee for subsequent in-depth fault diagnosis.

[0090] When the system triggers a Level 2 fault signal, the core function of the log storage unit becomes the emergency preservation of critical operational data of the target SoC. Under the scheduling of the independent monitoring unit, whether it is an emergency snapshot transferred at high speed via DMA or memory data (such as CPU register status, task stack information, etc.) forcibly read through hardware debugging links such as JTAG and SWD, it will be quickly written into this unit. Thanks to the constant power supply of the KL30, even if the entire vehicle subsequently experiences a complete power outage, this data recording the core situation at the moment of the fault can still be permanently saved completely and without loss. It is equivalent to leaving a digital black box for the vehicle system that can be backtracked and analyzed at any time, which greatly improves the efficiency of troubleshooting complex and intermittent faults and the functional safety level of the system.

[0091] In some embodiments of this application, reference is made to Figure 3 This section demonstrates the implementation principles and structure of the aforementioned system, specifically including the following content.

[0092] First, the target SoC chip 100 is selected from commercially available smart cockpit or intelligent driving SoCs used in vehicles. It runs the vehicle's operating system and applications internally without any modifications to the chip's internal design. After the KL15 ignition / wake-up power is applied, the monitoring agent program 110, running as a lightweight software daemon at the application layer of the SoC chip 100, periodically collects multi-dimensional status data through the standard API interfaces provided by the SoC operating system. This includes system-level CPU core load, memory usage, and task scheduling latency; chip-level core voltage and temperature read through the power management IC or on-chip sensors; application-level critical task execution time, timeout counts, and software watchdog counters; and bus error counts obtained through peripheral interfaces such as PCIe or Ethernet. The collected data is then sent to an external monitoring unit via the SoC's Ethernet, CAN, or SPI communication interfaces.

[0093] Secondly, the independent monitoring unit 200 is deployed in the vehicle domain controller or as an independent hardware module based on an ASIL-D level MCU, and is connected to the target SoC chip 100 via the vehicle bus. Its internal data receiving module 210 receives status data sent by the monitoring agent program 110 through CAN, FlexRay or Ethernet physical layer interfaces, providing a basis for subsequent analysis.

[0094] Furthermore, the fault analysis module 220 has multiple levels of thresholds pre-stored to analyze and judge the received data. The first level threshold is a warning threshold. When the data exceeds this threshold, it indicates that the SoC has entered a sub-healthy state and has potential risks. The second level threshold is a fault threshold. When the data exceeds this threshold, it indicates that the SoC has experienced a clear functional failure, thereby achieving hierarchical fault identification.

[0095] Then, the hierarchical processing module 230 generates corresponding control signals based on the results of the fault analysis module 220. At the same time, the log storage unit 240 uses a non-volatile memory such as eMMC, SD card or large-capacity Flash that is powered by the vehicle's constant power supply and is independent of the SoC power supply to save the fault log, ensuring that the data is not lost after the SoC loses power, and providing a basis for subsequent fault tracing.

[0096] Finally, the communication interface module 250 is connected to the vehicle controller 300 and the cloud server 400 via the vehicle CAN or FlexRay bus. The vehicle controller 300 receives the warning signal issued by the monitoring unit 200 and executes the vehicle-level safety strategy, while the cloud server 400 is an optional module used for remote monitoring and data analysis, forming a complete fault monitoring and response closed loop.

[0097] In some embodiments of this application, the target SoC chip 100 is a Qualcomm SA8295 cockpit chip running the Android Automotive OS system. The monitoring agent program 110 runs on the chip as a system service, obtaining system status data through API interfaces such as PowerManager and ThermalManager provided by the Android system, and simultaneously accessing the power management IC through the I2C interface to obtain voltage and current data.

[0098] The independent monitoring unit 200 uses a Renesas RH850 MCU as its core processor and connects to the target SoC chip 100 via a PCIe bus for high-speed data transmission. It also connects to the vehicle network via a CAN FD bus. The log storage unit 240 uses a UFS storage chip powered by a KL30 to ensure data integrity even after the SoC loses power.

[0099] Since the Qualcomm SA8295 chip does not support direct external memory access, this embodiment uses a communication-based data storage method to handle fault data. When the independent monitoring unit 200 detects a level-two fault, such as a critical UI rendering task timing out three times consecutively, it sends a high-priority interrupt to the target SoC chip 100 via the PCIe bus. In its interrupt service routine, the monitoring agent program 110 directly writes predefined snapshot data, including the current display frame buffer, the last 10 touch events, and the system log buffer, into the UFS memory of the independent monitoring unit 200 via PCIe DMA. After writing is complete, the independent monitoring unit 200 sends a fault code to the gateway via the CAN bus and records the fault information.

[0100] In some embodiments of this application, the method by which the monitoring agent 110 collects multi-dimensional state parameters can be adapted to the hardware characteristics of the target SoC chip 100. Specifically, there are two alternative solutions: one is based on PMU hardware monitoring, which utilizes the existing performance monitoring unit inside the SoC and configures hardware performance counters so that the monitoring agent periodically reads low-level indicators such as CPU cycles and cache hit rates. This method directly utilizes hardware logic and can significantly reduce CPU usage caused by software polling. The other is based on hardware probes. For target SoCs that cannot run software agents (such as certain dedicated acceleration chips or FPGAs), the system adopts an external hardware probe solution, which directly collects the chip's physical parameters through sensors such as current probes and temperature probes, and reads them by the analog-to-digital converter of the independent monitoring unit 200, thereby realizing physical layer monitoring of "dumb resources".

[0101] In some embodiments of this application, the deployment location of the independent monitoring unit 200 can be flexibly adjusted according to the complexity and cost requirements of the vehicle's electronic and electrical architecture. Specifically, the following three alternatives can be adopted: First, integration into the domain controller, that is, integrating the function of the monitoring unit into the existing intelligent driving domain controller or cockpit domain controller's safety core, utilizing the redundant computing resources inside the domain controller to perform monitoring tasks, thereby eliminating the need to deploy an additional independent hardware module and effectively reducing system hardware costs; Second, deployment on the gateway, that is, integrating the function of the monitoring unit into the vehicle's central gateway, utilizing the gateway's advantage as the vehicle's communication hub to centrally monitor multiple SoC chips such as intelligent driving, cockpit, and connectivity, and uniformly process and summarize the fault logs of each node; Third, distributed deployment, that is, deploying an independent monitoring unit for each key SoC. Although the hardware cost is higher, it can achieve the highest degree of isolation and reliability at the physical level, avoiding the spread of single-point failures.

[0102] In some embodiments of this application, when the hierarchical processing module 230 detects an anomaly, an arbitration mechanism or a degradation mode can be used to optimize the vehicle's safety response strategy. One is the arbitration mechanism: when communication between the independent monitoring unit 200 and the target SoC chip 100 is interrupted, the highest-level safety strategy is not immediately triggered. Instead, a "comprehensive evaluation arbitration mechanism" is introduced, combining other sensor data (such as vehicle speed and IMU inertial measurement unit data) from the vehicle controller 300 for comprehensive judgment. If the vehicle is stationary or at low speed, the emergency braking is delayed to avoid false triggering due to communication interruption. The second is the degradation mode: for a Level 1 warning signal, the system prioritizes executing a local degradation strategy within the monitoring unit. For example, it sends a command to the target SoC via the communication interface, requesting it to automatically shut down non-core tasks (such as video playback and voice assistant). Only when the degradation is found to be ineffective or the fault level is upgraded to a Level 2 fault is the system reported to the vehicle controller 300 and a request is made to execute hard safety strategies such as forced power-off or restart.

[0103] In some embodiments of this application, critical operational data can be stored using dual-channel redundant storage or cloud backup mechanisms to adapt to different fault recovery needs. One approach is dual-channel redundant storage, where the monitoring agent 110 continuously writes critical data to a small non-volatile memory (such as serial Flash) external to the target SoC chip 100, powered by the vehicle's constant power supply KL30. When a secondary fault response is triggered, the independent monitoring unit 200 only needs to confirm that the data has been written to disk, without needing to urgently read the memory via a high-bandwidth bus; it only needs to send a "log exists" signal, significantly reducing the data transmission pressure during a fault. The second approach is cloud backup, where before a fault occurs, the monitoring agent 110 uses the vehicle-mounted T-Box module to upload critical status data to the cloud server 400 in real time via a cellular network. When the local storage medium is damaged, the system supports remotely downloading historical data from the cloud for analysis after fault recovery, achieving off-site disaster recovery.

[0104] Furthermore, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the aforementioned vehicle SoC operation status monitoring method.

[0105] In addition, this application provides a vehicle including the aforementioned vehicle SoC operating status monitoring system. The independent monitoring unit is connected to the vehicle controller via the vehicle bus to drive the vehicle to execute safety policies when a secondary fault is detected.

[0106] Specifically, in this vehicle architecture, the independent monitoring unit establishes a tight communication connection with the vehicle controller via the onboard bus, constructing a safety command channel spanning the chip and vehicle levels. When the independent monitoring unit accurately detects a serious anomaly in the onboard SoC and triggers a secondary fault signal, it immediately sends a highest-priority safety alarm to the vehicle controller via this onboard bus. As the highest-level decision-making center of the vehicle, the vehicle controller quickly takes over vehicle control upon receiving the alarm, driving the vehicle to execute preset safety strategies, including power downgrading, pulling over, activating redundant systems, or emergency braking. This mechanism ensures that even when the core computing platform faces the risk of collapse, the vehicle can still react correctly and promptly, minimizing the occurrence of dangerous accidents.

[0107] In summary, the vehicle SoC operation status monitoring method, system, device, and vehicle provided in this application have the following technical effects.

[0108] This technical solution introduces an independent monitoring unit powered by constant power, enabling hardware-level bypass monitoring of the onboard SoC's operating status. This overcomes the limitations of traditional methods that rely on internal chip software self-tests, which cannot obtain data during system crashes or severe malfunctions. The solution effectively distinguishes between sub-healthy and severe malfunction states through a tiered threshold judgment mechanism and innovatively switches data export modes intelligently based on the SoC's crash state. In the event of extreme power outages, it utilizes interrupt-forced export or direct reading via debug interfaces to ensure the complete preservation and traceability of critical operational logs prior to the fault. This application not only significantly improves the fault diagnosis coverage and functional safety level of onboard computing platforms, addressing industry pain points such as difficulty in post-incident review and liability determination, but also effectively prevents data loss due to sudden power outages through its constant-power log storage design, providing reliable technical assurance and data support for the safe operation of intelligent vehicles.

[0109] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards of the relevant countries and regions. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data for the proper functioning of the embodiments of this application obtained.

[0110] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0111] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of ordinary skill of an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary skill. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0112] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0113] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable programs for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can retrieve and execute a program from or in conjunction with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit a program for use by or in conjunction with a program execution system, apparatus, or device.

[0114] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or, if necessary, processing in a suitable manner, and then stored in computer memory.

[0115] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable program execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0116] In the foregoing description of this specification, the reference to terms such as "one embodiment / implementation," "another embodiment / implementation," or "certain embodiments / implementations," etc., indicates that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in an embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0117] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0118] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. A method for monitoring the operating status of an in-vehicle SoC, characterized in that, include: By deploying a monitoring agent program at the application layer of the target SoC, multi-dimensional status parameters of the target SoC are periodically collected. These multi-dimensional status parameters include system-level data, chip-level data, and application-level data. The collected multidimensional state parameters are sent to an independent monitoring unit that is separate from the target SoC; In the independent monitoring unit, the received multidimensional state parameters are compared and analyzed with the pre-stored multi-level thresholds; If the detected parameter exceeds the first-level warning threshold but does not exceed the second-level fault threshold, a first-level warning signal is generated and the warning log is saved. If the monitored parameters exceed the level 2 fault threshold, a level 2 fault response is triggered; When a level 2 fault response is triggered, a forced read command is sent to the target SoC through the independent monitoring unit to save the key operating data in the target SoC's memory to the log storage unit powered by the vehicle's constant power supply KL30.

2. The method for monitoring the operating status of an in-vehicle SoC according to claim 1, characterized in that, The monitoring agent program deployed at the application layer of the target SoC periodically collects multi-dimensional status parameters of the target SoC, specifically including: The monitoring agent program collects system-level and application-level data through the standard API interface provided by the operating system. The monitoring agent program accesses the power management chip or on-chip sensors through the target SoC's internal bus, I2C interface, or SPI interface to collect chip-level data.

3. The method for monitoring the operating status of an in-vehicle SoC according to claim 1, characterized in that, The generation of a Level 1 warning signal and the saving of the warning log include: Bind the currently received multi-dimensional status parameters with real-time timestamps to generate early warning logs; The independent monitoring unit sends a performance degradation warning to the vehicle controller via the vehicle bus, so that the vehicle controller can perform frequency reduction or limit non-core functions.

4. The method for monitoring the operating status of an in-vehicle SoC according to claim 1, characterized in that, The collected multidimensional status parameters are sent to an independent monitoring unit separate from the target SoC, specifically via vehicle Ethernet, CANFD, FlexRay, or PCIe bus.

5. The method for monitoring the operating status of an in-vehicle SoC according to claim 1, characterized in that, When a level-two fault response is triggered, the independent monitoring unit sends a forced read command to the target SoC, including: When the independent monitoring unit determines that the target SoC is still responsive but is in an abnormal state, it sends a high-priority interrupt request to the monitoring agent program through a dedicated hardware interrupt line. The monitoring agent responds to the interruption request by skipping non-critical task scheduling in the interrupt service routine and directly reading predefined emergency snapshot data. The emergency snapshot data is transmitted to the independent monitoring unit via Direct Memory Access (DMA).

6. The method for monitoring the operating status of an in-vehicle SoC according to claim 5, characterized in that, When a level-two fault response is triggered, the independent monitoring unit sends a forced read command to the target SoC, which further includes: When the independent monitoring unit determines that the target SoC has crashed or communication has been interrupted, it activates a preset backdoor access channel. The independent monitoring unit directly reads the memory data of the target SoC through the backdoor access channel, which includes a hardware debugging link that does not rely on the target SoC operating system. The hardware debugging link includes a JTAG interface, an SWD interface, or a dedicated diagnostic physical pin reserved by the chip.

7. The method for monitoring the operating status of an in-vehicle SoC according to claim 1, characterized in that, The key operational data includes: current task stack information, CPU register status, software watchdog counter value, and circular buffer log within a preset time window before the fault.

8. A vehicle-mounted SoC operating status monitoring system, characterized in that, A method for monitoring the operating status of an in-vehicle SoC as described in any one of claims 1 to 7; The system includes a target SoC chip and an independent monitoring unit; The target SoC chip is used to run a monitoring agent program to collect multi-dimensional status parameters and output data through a communication interface. The independent monitoring unit includes a microcontroller and a memory connected thereto; The microcontroller includes a data receiving module, a fault analysis module, and a hierarchical processing module, which are respectively configured to perform the following functions: The data receiving module is used to receive the multidimensional state parameters; The fault analysis module is used to store multi-level thresholds and analyze the received data; The hierarchical processing module is used to generate a first-level early warning signal or a second-level fault signal based on the analysis results. The system also includes a log storage unit, which is powered by the vehicle's constant power supply KL30, which is independent of the target SoC power supply domain, and is used to preserve the target SoC's critical operating data when a secondary fault signal is triggered. The independent monitoring unit and the target SoC chip belong to different power domains and clock domains.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the vehicle SoC operation status monitoring method as described in any one of claims 1 to 7.

10. A vehicle, characterized in that, The system includes the vehicle SoC operating status monitoring system as described in claim 8, wherein the independent monitoring unit is connected to the vehicle controller via the vehicle bus to drive the vehicle to execute safety policies when a secondary fault is detected.

Images