Controller reset monitoring method and device, vehicle, system, medium and product

Abstract

The invention relates to the technical field of vehicle monitoring, and discloses a controller reset monitoring method and device, a vehicle, a system, a medium and a product, and the method comprises the steps: obtaining the real-time operation state of the vehicle when it is detected that a vehicle-mounted controller executes reset for abnormity; based on the real-time operation state, determining a reset risk level of the vehicle-mounted controller; wherein the reset risk level is used for representing the influence degree of reset execution of the vehicle-mounted controller on vehicle operation; and uploading the reset risk level to a cloud, so that the cloud sends alarm information to the vehicle when detecting that the reset risk level of the vehicle-mounted controller is higher than a risk level threshold. Therefore, when the controller is reset, the running state of the vehicle is sensed in real time, the reset risk level of the reset event of the vehicle-mounted controller is evaluated, and then the reset risk level is uploaded to the cloud, so that the risk monitoring of the reset event and the real-time safety early warning of the coordination of the cloud are realized.

Description

Technical Field

[0001] This invention relates to the field of vehicle monitoring technology, specifically to controller reset monitoring methods, devices, vehicles, systems, media, and products. Background Technology

[0002] The automotive electrical / electronic (EE) architecture is shifting from a traditional distributed EE architecture to a domain-centralized EE architecture. Centralized controllers integrate and merge multiple functions, reducing the number of hardware controllers, but significantly increasing the complexity of individual controllers and consequently reducing software stability. Resetting the Electronic Control Unit (ECU) after a software anomaly is a common recovery method; however, various software problems can trigger a wide range of resets, and software resets may lead to functional abnormalities.

[0003] Existing technology provides a reset management method that determines the controller's reset type based on reset information and executes a reset processing subroutine matching the reset type. While it can manage numerous reset messages, it lacks effective monitoring of risks caused by software resets, making security difficult to guarantee. Summary of the Invention

[0004] This invention provides a controller reset monitoring method, device, vehicle, system, medium, and product to address the problem that existing technologies lack monitoring of risks after a controller performs a reset, which affects driving safety.

[0005] In a first aspect, the present invention provides a controller reset monitoring method, the method comprising: When the vehicle controller is detected to be performing a reset in response to an anomaly, the real-time operating status of the vehicle is obtained; Based on the real-time operating status, the reset risk level of the vehicle controller is determined; the reset risk level is used to characterize the degree of impact of the vehicle controller performing a reset on vehicle operation. The reset risk level is uploaded to the cloud so that the cloud can send an alarm message to the vehicle when it detects that the reset risk level of the vehicle controller is higher than the risk level threshold.

[0006] This invention senses the vehicle's operating status in real time when the controller resets, assesses the reset risk level of the onboard controller reset event based on this status, and then uploads the reset risk level to the cloud. The cloud, based on preset risk level thresholds and the reset risk level, determines in real time whether the onboard controller reset poses a risk and sends alarm information to the vehicle. This achieves real-time safety early warning through risk monitoring of reset events and cloud-based collaboration, solving the problem that traditional reset management cannot distinguish the risks of reset events and improving the vehicle system's safety monitoring and response capabilities.

[0007] In one optional implementation, the real-time operating status includes communication status, power-on status, and vehicle speed; based on the real-time operating status, the reset risk level of the on-board controller is determined, including: If the communication status is detected as closed, the reset risk level is determined to be Level 1; If the communication status is detected as enabled and the power-on status is detected as disabled, the reset risk level is determined to be Level 2; Level 2 is higher than Level 1. If the communication status is detected as enabled, the power-on status is detected as powered on, and the vehicle speed is lower than the vehicle speed threshold, the reset risk level is determined to be Level 3; Level 3 is higher than Level 2. If the communication status is detected as enabled, the power-on status is detected as powered on, and the vehicle speed is not lower than the vehicle speed threshold, the reset risk level is determined to be Level 4; Level 4 is higher than Level 3.

[0008] This invention combines the multi-dimensional operating status of the vehicle when the on-board controller is reset, including communication status, power-on status, and vehicle speed, to classify the reset risk level of the on-board controller. This enables real-time early warning of high-risk resets in vehicle operation scenarios, thereby ensuring driving safety under high-risk reset conditions. While maintaining system availability, it effectively prevents safety risks that may be caused by reset operations.

[0009] In one alternative implementation, the method further includes: Read the call stack information of the vehicle controller stored in non-volatile memory; the call stack information includes function call information and register values; The call stack information is uploaded to the cloud so that the cloud can determine the reason for the vehicle controller's reset based on the call stack information.

[0010] This invention uploads call stack information to the cloud, enabling the cloud to obtain the function call path in the software code based on the call stack information. This allows for the precise location of reset causes and software defects, which is crucial for debugging and analyzing program operation.

[0011] In an alternative implementation, before reading the call stack information of the vehicle controller stored in non-volatile memory, the method further includes: When an abnormality occurs in the vehicle controller, the call stack information of the vehicle controller is recorded and stored in volatile memory; After detecting that the vehicle controller has performed a reset in response to an anomaly, the call stack information is transferred from volatile memory to non-volatile memory.

[0012] When the vehicle controller malfunctions, this invention first stores its call stack information in volatile memory. After the vehicle controller is reset, the call stack information is transferred to non-volatile memory. This ensures reliable data preservation even in the event of a power outage or network failure, guaranteeing data integrity under various complex conditions and enabling data uploading to the cloud.

[0013] In one alternative implementation, the method further includes: Based on the call stack information, reset risk level, and real-time running status, reset information is generated, and a snapshot of the reset information is also generated. Upload the reset information and snapshot information to the cloud so that the cloud can display the reset information and snapshot information.

[0014] This invention uploads detailed reset information, including call stack information, reset risk level, real-time operating status, and snapshot information, to the cloud, enabling technicians to remotely analyze the reset data of the vehicle controller, thereby tracing the cause of the reset and locating the reset problem.

[0015] In one alternative implementation, the method further includes: The reset information and snapshot information are associated and stored in non-volatile memory, and the number of times the reset information and snapshot information are stored is recorded; If the number of storage attempts is detected to be greater than the storage attempt threshold, delete the earliest reset information and snapshot information stored in non-volatile memory.

[0016] This invention associates and stores reset information and snapshot information in a non-volatile memory to prevent data loss after vehicle power failure or network failure. Furthermore, when the number of times reset and snapshot information are stored exceeds a storage threshold, the most recently stored reset and snapshot information overwrites the earliest stored reset and snapshot information, thereby deleting redundant and invalid data.

[0017] In one optional implementation, the reset information and snapshot information are uploaded to the cloud, including: Package the reset information and snapshot information into a reset data packet; The reset data packet is sent to the gateway device so that the gateway device can upload the reset data packet to the cloud.

[0018] This invention uploads reset data packets to the cloud via a gateway device, which can temporarily store data packets and resume interrupted transmission when the network is unstable, ensuring that critical reset records are not lost and achieving reliable data uploading to the cloud.

[0019] In a second aspect, the present invention provides a controller reset monitoring device, the device comprising: The first processing module is used to obtain the real-time operating status of the vehicle when the vehicle controller is detected to be performing a reset in response to an abnormality. The second processing module is used to determine the reset risk level of the vehicle controller based on the real-time operating status; wherein, the reset risk level is used to characterize the degree of impact of the vehicle controller performing a reset on the vehicle operation; The third processing module is used to upload the reset risk level to the cloud, so that when the cloud detects that the reset risk level of the vehicle controller is higher than the risk level threshold, it sends an alarm message to the vehicle.

[0020] Thirdly, the present invention provides a controller reset monitoring system, the system comprising: The vehicle is used to acquire the real-time operating status of the vehicle when the on-board controller is detected to be performing a reset in response to an abnormality; based on the real-time operating status, the reset risk level of the on-board controller is determined; the reset risk level is used to characterize the degree of impact of the on-board controller's reset on the vehicle's operation; and the reset risk level is uploaded to the cloud. The cloud-based system receives reset risk levels from vehicles and sends alarm information to vehicles when the reset risk level of the on-board controller is detected to be higher than the risk level threshold.

[0021] Fourthly, the present invention provides a vehicle comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the controller reset monitoring method of the first aspect or any corresponding embodiment described above.

[0022] Fifthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the controller reset monitoring method of the first aspect or any corresponding embodiment thereof.

[0023] In a sixth aspect, the present invention provides a computer program product, including computer instructions for causing a computer to execute the controller reset monitoring method described in the first aspect or any corresponding embodiment thereof.

[0024] The beneficial effects of this invention are as follows: This invention senses the vehicle's operating status in real time when the controller resets, assesses the reset risk level of the onboard controller reset event based on this status, and then uploads the reset risk level to the cloud. The cloud, based on preset risk level thresholds and the reset risk level, determines in real time whether the onboard controller reset poses a risk and sends alarm information to the vehicle. This achieves real-time safety early warning through risk monitoring of reset events and cloud-based collaboration, solving the problem that traditional reset management cannot distinguish the risks of reset events and improving the vehicle system's safety monitoring and response capabilities. Attached Figure Description

[0025] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of an application scenario according to an embodiment of the present invention; Figure 2 This is a structural block diagram of a controller reset monitoring system according to an embodiment of the present invention; Figure 3 This is a schematic flowchart of a first method for monitoring controller reset according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a second process for a controller reset monitoring method according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the third process of the controller reset monitoring method according to an embodiment of the present invention; Figure 6 This is a structural block diagram of a controller reset monitoring device according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the hardware structure of a vehicle according to an embodiment of the present invention. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0029] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0030] As an optional application scenario of this invention, such as Figure 1 As shown, the controller reset monitoring system may include at least one terminal device and at least one server. Figure 1 The system is illustrated in the example, which includes a computer 101, a mobile terminal 102, and a server 103, and the terminal devices such as the computer 101 and the mobile terminal 102 are connected to the server 103 through a network 110.

[0031] Specifically, the terminal device can be a smartphone, tablet, laptop, PDA, desktop computer, game console, smart TV, smart wearable device, in-vehicle terminal, VR (Virtual Reality) device, AR (Augmented Reality) device, etc. Server 103 can be a standalone physical server, a server cluster, a distributed system, or a cloud server providing cloud services. Network 110 can be a wired or wireless network, examples of which include, but are not limited to, the Internet, corporate intranet, local area network, wide area network, mobile communication network, and combinations thereof.

[0032] Driven by electrification, intelligent connectivity, changes in electrical / electronic architecture (EEA), and integration in the automotive industry, the electronic and electrical systems of both gasoline-powered and new energy vehicles are undergoing rapid transformation. Software-defined vehicles and intelligentization have become strategic directions for the development of the automotive industry. The automotive electronic and electrical architecture is shifting from a traditional distributed EE architecture to a domain-centralized EE architecture. A widely used solution is the three-domain centralized EE architecture, which consists of three domain controllers (DCUs): the Vehicle Domain Controller (VDC), the Advanced Driver Controller / Advanced Driver Assistance Systems (ADAS / AD) Domain Controller (ADC), and the Cockpit Domain Controller (CDC).

[0033] Centralized controllers integrate multiple functions, reducing the number of hardware controllers, but the complexity of a single controller increases significantly, and software stability decreases accordingly. Resetting an ECU after a software anomaly is a common recovery method, but software resets can produce side effects and functional abnormalities. The types of resets caused by various software problems are numerous, making the tracking, localization, and classification of reset problems a new challenge. This problem is widespread in ECU devices with a microcontroller unit (MCU) as the main control core.

[0034] Related technologies provide a reset management method that determines the reset type of the automotive electronic controller based on reset information and executes a reset processing subroutine matching the reset type, thereby improving the portability and maintainability of the automotive electronic controller software. However, the data acquisition of the above method mainly relies on the internal storage of the controller, requiring technicians to collect data on-site in the actual vehicle. This limits the functional scope and makes remote analysis difficult. Furthermore, the reset data is only stored internally, making it easily overwritten or lost after power failure, hindering long-term traceability. Additionally, the analysis of reset data is relatively simple, lacking monitoring of risks caused by controller resets, which could potentially affect user safety during driving.

[0035] This invention provides a controller reset monitoring method. By sensing the vehicle's operating status in real time during controller reset, assessing the reset risk level of the onboard controller reset event based on this status, and then uploading the reset risk level to the cloud. The cloud, based on a preset risk level threshold and the reset risk level, determines in real time whether there is a risk associated with the onboard controller reset and sends alarm information to the vehicle. This achieves real-time safety early warning through risk monitoring of reset events and cloud-based collaboration, solving the problem that traditional reset management cannot distinguish the risks of reset events, and improving the safety monitoring and response capabilities of the vehicle system.

[0036] According to embodiments of the present invention, a controller reset monitoring system is provided, such as... Figure 2 As shown, the controller reset monitoring system includes a vehicle 201 and a cloud 202. The cloud is a server system located at a remote location. The vehicle may include an embedded controller, which may be an embedded device with a main chip MCU as its core.

[0037] Vehicle 201 is used to acquire the real-time operating status of the vehicle when the vehicle controller is detected to be performing a reset in response to an abnormality; based on the real-time operating status, the reset risk level of the vehicle controller is determined; wherein, the reset risk level is used to characterize the degree of impact of the vehicle controller performing a reset on the vehicle operation; and the reset risk level is uploaded to the cloud 202. Cloud 202 is used to receive the reset risk level sent by vehicle 201. When the reset risk level of the vehicle controller is detected to be higher than the risk level threshold, an alarm message is sent to vehicle 201.

[0038] In some alternative implementations, see again Figure 2 The vehicle controller of vehicle 201 mainly includes a reset data recording module, a reset data storage module, and a reset data upload service. These modules can be deployed within the MCU software on the controller side. Vehicle 201 also includes a gateway device, which can be a TBOX. The TBOX can be a separate controller from the vehicle controller, an independent TBOX controller, or a module integrated into the cockpit domain controller.

[0039] Specifically, when the reset data recording module detects an anomaly in the controller chip, it enters a preset trap handling program and records the reset information from the vehicle controller, including call stack information, reset risk level, and real-time vehicle operating status. This reset information is stored in the controller's soft-reset volatile memory (RAM) so that the vehicle controller can proactively and quickly reset after recording the reset information.

[0040] Furthermore, after the vehicle controller is reset, the reset data storage module analyzes the detailed reset information stored in RAM prior to the controller reset, extracts a summary of the current reset information, and obtains snapshot information. This snapshot information is then added to the previous reset information. If the number of data storage iterations exceeds a threshold (e.g., 3 times), the data is cyclically overwritten, with the latest iteration overwriting the oldest. Both the detailed reset information and the summary snapshot information are then transferred to non-volatile memory (NVM) for storage. This ensures that reset data (including reset and snapshot information) is not lost even after a power outage, achieving data retention under complex operating conditions and guaranteeing the retrieval of NVM storage data from the vehicle to obtain the vehicle controller's previous reset data.

[0041] See you again Figure 2 The reset data upload service packages detailed reset information and brief snapshot information stored in the NVM and transmits them to the TBOX via an in-vehicle Ethernet channel using a preset data channel. The TBOX has 4G or 5G wireless communication capabilities and connects to the cloud server to interact with data, thereby transmitting the reset data from the reset data upload service to the cloud.

[0042] In some alternative implementations, see again Figure 2 The cloud-based system includes a reset database for data storage, a data processing module, and a webpage reset data display module. Upon receiving reset data, the cloud first stores the data in the reset database. This database boasts robust data storage capabilities, allowing for long-term data storage as needed, facilitating data retrieval and traceability.

[0043] The data processing module analyzes and processes the reset data stored in the reset database, performing data cleaning to remove duplicate and unnecessary data. The cleaned data volume is significantly reduced, allowing for the storage of valid data for a longer period. The data processing module generates events according to predetermined rules and can be configured with proactive notification functions. For example, it can be configured to proactively send information to designated personnel upon detecting a high-risk controller reset event.

[0044] The webpage reset data display module can define projects based on cloud data and display the effective data processed by the data processing module. It can also filter data items, such as time range, vehicle type, reset type, etc., to form statistical data and data dashboards.

[0045] The controller reset monitoring system provided in this embodiment allows the system to perceive the vehicle's operating status in real time when the controller resets, assess the reset risk level of the on-board controller reset event based on this status, and then upload the reset risk level to the cloud. The cloud then determines in real time whether there is a risk associated with the on-board controller reset based on a preset risk level threshold and sends alarm information to the vehicle. This achieves real-time safety early warning through risk monitoring of reset events and cloud-based collaboration, improving the vehicle system's safety monitoring and response capabilities.

[0046] According to an embodiment of the present invention, a controller reset monitoring method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0047] This embodiment provides a controller reset monitoring method, which can be used for, for example Figure 2 The vehicle shown, Figure 3 This is a flowchart of a controller reset monitoring method according to an embodiment of the present invention, as follows: Figure 3 As shown, the process includes the following steps: Step S301: When the vehicle controller is detected to be performing a reset in response to an abnormality, the real-time operating status of the vehicle is obtained.

[0048] Specifically, the vehicle controller will actively reset after an abnormality occurs. When the vehicle controller performs a reset operation for software abnormality, it records the real-time operating status of the vehicle at this time. The real-time operating status includes, but is not limited to, information such as the vehicle's communication status, power-on status, and vehicle speed.

[0049] Step S302: Based on the real-time operating status, determine the reset risk level of the vehicle controller; wherein, the reset risk level is used to characterize the degree of impact of the vehicle controller performing a reset on the vehicle operation.

[0050] Specifically, the real-time operating status of the vehicle is analyzed to determine whether the vehicle's communication status, power-on status, and speed meet the predetermined rules, and to determine the impact of the vehicle controller performing a reset operation under the current operating status on the vehicle, thereby obtaining the reset risk level of the vehicle controller.

[0051] In this embodiment, the reset risk level can be divided into four levels in order of increasing impact on the vehicle: Level 1, Level 2, Level 3, and Level 4. The specific level can be adjusted according to the actual needs of the scenario, and this invention is not limited thereto.

[0052] Step S303: Upload the reset risk level to the cloud so that the cloud can send an alarm message to the vehicle when it detects that the reset risk level of the vehicle controller is higher than the risk level threshold.

[0053] Specifically, the cloud receives the reset risk level sent by the vehicle and takes corresponding actions. For example, if the reset risk level is Level 1, no action needs to be taken. When the reset risk level is level two, the reset risk level is recorded and combined with the corresponding reset data to analyze the software defects or reset causes of the vehicle controller. When the reset risk level is level three, a medium-priority alarm message can be sent to the vehicle, and the cause of the reset and software defects can be analyzed. When the reset risk level is level three, a high-priority alarm message can be sent to the vehicle to remind the user to take timely safety measures and analyze the cause of the reset and software defects. The risk level threshold can be level two, and the specific setting can be determined based on the actual scenario.

[0054] The controller reset monitoring method provided in this embodiment senses the vehicle's operating status in real time when the controller resets, assesses the reset risk level of the vehicle controller reset event based on the operating status, and then uploads the reset risk level to the cloud. The cloud, based on a preset risk level threshold and the reset risk level, determines in real time whether there is a risk in the vehicle controller reset and sends alarm information to the vehicle. This achieves real-time safety early warning through risk monitoring of reset events and cloud-based collaboration, solving the problem that traditional reset management cannot distinguish the risks of reset events, and improving the safety monitoring and response capabilities of the vehicle system.

[0055] This embodiment provides a controller reset monitoring method, which can be used for, for example Figure 2 The vehicle shown, Figure 4 This is a flowchart of a controller reset monitoring method according to an embodiment of the present invention, as follows: Figure 4 As shown, the process includes the following steps: Step S401: Upon detecting that the vehicle controller has performed a reset in response to an anomaly, the real-time operating status of the vehicle is acquired. For details, please refer to [link to relevant documentation]. Figure 3 Step S301 of the illustrated embodiment will not be described again here.

[0056] Step S402: Based on the real-time operating status, determine the reset risk level of the vehicle controller; wherein, the reset risk level is used to characterize the degree of impact of the vehicle controller performing a reset on the vehicle operation.

[0057] Specifically, step S402 includes: Step S4021: If the communication status is detected as closed, determine the reset risk level as Level 1.

[0058] For example, if the vehicle's CAN network is detected to be off, i.e., the communication status is off, it indicates that the vehicle controller is performing a static reset. This static reset has little impact on vehicle operation, and the reset risk level of the vehicle controller is confirmed to be Level 1.

[0059] Step S4022: If the communication status is detected as enabled and the power-on status is detected as disabled, the reset risk level is determined to be Level 2; Level 2 is higher than Level 1.

[0060] For example, if it is detected that the vehicle's CAN network is turned on (i.e., the communication status is on) but the vehicle is not in the ON position (i.e., the power-on status is not on), it indicates that the vehicle controller is performing a static reset, which has a relatively minor impact on the vehicle. The reset risk level of the vehicle controller is confirmed to be Level 2.

[0061] Step S4023: If the communication status is detected as enabled, the power-on status is detected as powered on, and the vehicle speed is lower than the vehicle speed threshold, the reset risk level is determined to be Level 3; Level 3 is higher than Level 2.

[0062] For example, if it is detected that the vehicle's CAN network is enabled (i.e., communication is enabled), the vehicle is in the ON position (i.e., power-on), the powertrain is in the READY state, and the vehicle speed is below the vehicle speed threshold (e.g., vehicle speed is 0, below the vehicle speed threshold by 0.1), the vehicle controller performs a static reset, but this may cause some functional failures. Therefore, the reset risk level of the vehicle controller is confirmed to be Level 3. It should be noted that the vehicle speed threshold can be adjusted according to the actual needs of the scenario.

[0063] Step S4024: If the communication status is detected as enabled, the power-on status is detected as powered on, and the vehicle speed is not lower than the vehicle speed threshold, the reset risk level is determined to be Level 4; Level 4 is higher than Level 3.

[0064] For example, if it is detected that the vehicle's CAN network is on, the vehicle is in the ON position, the vehicle is in motion, and the speed exceeds a speed threshold, a controller reset may cause serious problems, confirming that the risk level of the on-board controller reset is Level 4. For instance, if the on-board controller integrates the vehicle control unit (VCU) function, a reset of the on-board controller during vehicle operation may cause vehicle power failure, seriously affecting driving safety.

[0065] This embodiment combines the multi-dimensional operating status of the vehicle when the on-board controller is reset, including communication status, power-on status, and vehicle speed, to classify the reset risk level of the on-board controller. This enables real-time early warning of high-risk resets in vehicle operation scenarios, thereby ensuring driving safety under high-risk reset conditions. While maintaining system availability, it effectively prevents safety risks that may be caused by reset operations.

[0066] Step S403: The reset risk level is uploaded to the cloud so that the cloud can send an alarm message to the vehicle when it detects that the reset risk level of the vehicle controller is higher than the risk level threshold. For details, please refer to [link to relevant documentation]. Figure 3 Step S303 of the illustrated embodiment will not be described again here.

[0067] Step S404: Read the call stack information of the vehicle controller stored in the non-volatile memory, and upload the call stack information to the cloud so that the cloud can determine the reason for the reset of the vehicle controller based on the call stack information.

[0068] Specifically, call stack information includes function call information and register values. In software development, the call stack is a data structure used to record the function call order, function return address, register values, and related information. Registers are used to store runtime environment variables, and register values ​​represent the runtime environment variable parameters of the function.

[0069] It should be noted that the call stack information changes rapidly and dynamically with the software calls during operation. The call stack information varies depending on the chip architecture. The vehicle controller may be single-core or multi-core. If it is multi-core, only the call stack information of the core task or interrupt that first causes the exception is recorded. Up to 10 levels of function call information can be recorded. The specific settings can be adjusted according to the chip structure of the actual vehicle controller.

[0070] In this embodiment, all software calls in the embedded software are in the form of function calls. The call stack information records the function call path of the software operation. By uploading the call stack information to the cloud, the cloud can obtain the function call path in the software code based on the call stack information and the corresponding mapping file compiled by the software, locate the key information of the software bug, and achieve accurate location of the reset cause and software defect. This is crucial for debugging and analyzing the program operation.

[0071] In some optional implementations, when an anomaly occurs in the vehicle controller, the call stack information of the vehicle controller is recorded and stored in volatile memory (RAM). After detecting that the vehicle controller performs a reset in response to the anomaly, the call stack information is transferred from volatile memory (RAM) to non-volatile memory (NVM), thereby reading the call stack information stored in the non-volatile memory (NVM).

[0072] Specifically, since reset information such as call stack information is easily lost if it only exists in RAM, by storing the reset information in NVM after the vehicle controller is reset, the data will not be lost even if power is lost. After a problem occurs, reliable preservation is achieved through NVM storage, and the data can be retrieved again even after power failure.

[0073] In some embodiments, when a network failure occurs in the vehicle's Ethernet or the vehicle's TBOX, reset information such as call stack information cannot be uploaded to the cloud. By storing the reset information in the NVM, the reset data can be retrieved from the NVM and uploaded to the cloud after the vehicle network is restored, ensuring that data is not lost under various complex conditions and realizing data upload to the cloud.

[0074] In this embodiment, when the vehicle controller malfunctions, its call stack information is first stored in volatile memory. After the vehicle controller is reset, the call stack information is transferred to non-volatile memory. This ensures reliable data preservation in the event of a power outage or network failure, guaranteeing data integrity under various complex conditions and enabling data uploading to the cloud.

[0075] Step S405: Based on the call stack information, reset risk level, and real-time running status, generate reset information and a snapshot of the reset information. Upload the reset information and snapshot information to the cloud so that the cloud can display the reset information and snapshot information.

[0076] Specifically, the reset data from the vehicle controller includes detailed reset information (including call stack information, reset risk level, and real-time operating status) and snapshot information collected when an abnormal reset occurs. The snapshot information can include reset snapshots of the three most recent abnormal resets, containing the software version number, reset time (year, month, day, hour, minute, second), reset type (i.e., reset source, corresponding to the software-defined reset type number in the controller), and counters for various reset types (counter data only increments upwards). This allows the cloud to quickly determine whether a reset has occurred once or multiple times by combining the snapshot information, and further pinpoint the cause of the reset. It should be noted that in addition to call stack information, reset risk level, and real-time operating status, the reset information can also include other user-defined information, such as task counters, vehicle gear information, and other necessary vehicle information, thereby assisting in locating complex reset problems.

[0077] In some optional implementations, reset information and snapshot information are associated and stored in non-volatile memory, and the number of times the reset information and snapshot information are stored is recorded. If the number of storage times is detected to be greater than a storage count threshold, the earliest reset information and snapshot information stored in the non-volatile memory are deleted.

[0078] This embodiment stores reset information and snapshot information together in non-volatile memory to prevent data loss after vehicle power failure or network failure. Furthermore, when the number of times reset information and snapshot information are stored exceeds a storage threshold (e.g., 3 times), the most recently stored reset information and snapshot information overwrite the earliest stored reset information and snapshot information, thereby deleting redundant and invalid data.

[0079] In some embodiments, after receiving the reset information and snapshot information, the cloud analyzes and displays the reset details. The reset details display may include the vehicle series, vehicle VIN code, vehicle controller name, reset risk level, reset status, reset time, cumulative number of resets of various types (CNT), current reset name ID, reset snapshot information, and detailed reset information, as shown in Table 1 below.

[0080] Table 1 shows the details of cloud-based reset.

[0081] In some embodiments, the data displayed in the cloud can be filtered to obtain statistical data.

[0082] This embodiment uploads detailed reset information, including call stack information, reset risk level, real-time operating status, and snapshot information, to the cloud, enabling technicians to remotely analyze the reset data of the vehicle controller, thereby tracing the cause of the reset and locating the reset problem.

[0083] In some alternative implementations, the reset information and snapshot information are packaged into a reset data packet, and the reset data packet is sent to the gateway device so that the gateway device uploads the reset data packet to the cloud.

[0084] Specifically, the reset information and snapshot information are packaged and transmitted to the TBOX via an in-vehicle Ethernet channel through a preset data channel. The TBOX has 4G or 5G wireless communication capabilities and connects to a cloud server to interact with data, thereby transmitting the reset data packet to the cloud.

[0085] This embodiment uploads the reset data packet to the cloud through the gateway device. It can temporarily store the data packet when the network is unstable and realize the interruption resume transmission, ensuring that the critical reset record is not lost and realizing reliable data uploading to the cloud.

[0086] The controller reset monitoring scheme of the present invention will be described in detail below with reference to a specific application example.

[0087] like Figure 5As shown, after the vehicle-side controller resets, the reset data recording module enters the exception handling process, records the reset scene information, and then performs a fast active soft reset to restart the controller. After the vehicle-side controller restarts, it transfers the reset data previously stored in RAM to the NVM to achieve non-volatile storage, and sends the reset data to the TBOX via Ethernet. The TBOX then transmits the reset data to the cloud server via a 4G or 5G wireless network.

[0088] After receiving the data, the cloud server first stores it in the corresponding database to ensure reliable data preservation. The reset data processing module deployed in the cloud cleans and parses the reset data, and provides a visualization module for the processed reset data when technicians access it remotely.

[0089] Reset data is generated by the vehicle controller and then transmitted to the cloud, forming a reset database. Technicians can download and analyze the data from the cloud via computer to pinpoint and resolve reset issues. Alternatively, they can receive a notification from the cloud and proactively retrieve the vehicle's reset data for rapid analysis and location.

[0090] This invention addresses reset issues caused by ECU software malfunctions, enabling the tracing, monitoring, and management of controller reset problems. By constructing a fast and efficient reset data acquisition method, it improves the efficiency of analyzing and locating various reset problems, ultimately enhancing software stability.

[0091] This invention accumulates reset data throughout the entire lifecycle of a vehicle by combining edge and cloud technologies, enabling cloud storage and big data processing of reset data. Furthermore, it manages reset data by standardizing the structure definition of reset data and achieving interface standardization.

[0092] This invention solves the problems of inconvenient data collection and difficulty in tracing and locating the problem after an abnormal reset of an automotive MCU, overcoming the limitations of traditional reset data which exists in individual form and has a short lifespan. By cloudifying the reset data, technicians can remotely obtain the data, enabling rapid location of reset problems. Especially in the early stages of product development, the efficiency of problem location can be greatly improved through cloud-based early warning notifications or by proactively acquiring cloud-based reset data.

[0093] This embodiment also provides a controller reset monitoring device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, hardware implementations, or a combination of software and hardware, are also possible and contemplated.

[0094] This embodiment provides a controller reset monitoring device, such as... Figure 6 As shown, it includes: The first processing module 601 is used to obtain the real-time operating status of the vehicle when the vehicle controller is detected to be performing a reset in response to an abnormality. The second processing module 602 is used to determine the reset risk level of the vehicle controller based on the real-time operating status; wherein, the reset risk level is used to characterize the degree of impact of the vehicle controller performing a reset on the vehicle operation; The third processing module 603 is used to upload the reset risk level to the cloud so that when the cloud detects that the reset risk level of the vehicle controller is higher than the risk level threshold, it sends an alarm message to the vehicle.

[0095] In some optional implementations, the real-time operating status includes communication status, power-on status, and vehicle speed; the second processing module 602 is also used for: If the communication status is detected as closed, the reset risk level is determined to be Level 1; If the communication status is detected as enabled and the power-on status is detected as disabled, the reset risk level is determined to be Level 2; Level 2 is higher than Level 1. If the communication status is detected as enabled, the power-on status is detected as powered on, and the vehicle speed is lower than the vehicle speed threshold, the reset risk level is determined to be Level 3; Level 3 is higher than Level 2. If the communication status is detected as enabled, the power-on status is detected as powered on, and the vehicle speed is not lower than the vehicle speed threshold, the reset risk level is determined to be Level 4; Level 4 is higher than Level 3.

[0096] In some optional implementations, the third processing module 603 is further configured to: Read the call stack information of the vehicle controller stored in non-volatile memory; the call stack information includes function call information and register values; The call stack information is uploaded to the cloud so that the cloud can determine the reason for the vehicle controller's reset based on the call stack information.

[0097] In some optional implementations, before reading the call stack information of the vehicle controller stored in non-volatile memory, the third processing module 603 is further configured to: When an abnormality occurs in the vehicle controller, the call stack information of the vehicle controller is recorded and stored in volatile memory; After detecting that the vehicle controller has performed a reset in response to an anomaly, the call stack information is transferred from volatile memory to non-volatile memory.

[0098] In some optional implementations, the third processing module 603 is further configured to: Based on the call stack information, reset risk level, and real-time running status, reset information is generated, and a snapshot of the reset information is also generated. Upload the reset information and snapshot information to the cloud so that the cloud can display the reset information and snapshot information.

[0099] In some optional implementations, the third processing module 603 is further configured to: The reset information and snapshot information are associated and stored in non-volatile memory, and the number of times the reset information and snapshot information are stored is recorded; If the number of storage attempts is detected to be greater than the storage attempt threshold, delete the earliest reset information and snapshot information stored in non-volatile memory.

[0100] In some optional implementations, the third processing module 603 is further configured to: Package the reset information and snapshot information into a reset data packet; The reset data packet is sent to the gateway device so that the gateway device can upload the reset data packet to the cloud.

[0101] The controller reset monitoring device provided in this embodiment of the invention can execute the controller reset monitoring method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0102] Figure 7 This is a structural schematic diagram of a vehicle provided in an embodiment of the present invention.

[0103] The following is a detailed reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing a vehicle according to an embodiment of the present invention. The vehicle may include a processor (e.g., a central processing unit, graphics processor, etc.) 701, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 702 or a program loaded from memory 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for vehicle operation. The processor 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0104] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 708 including, for example, magnetic tapes, hard disks, etc.; and communication devices 709. Communication device 709 allows the vehicle to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7Vehicles with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0105] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 709, or installed from a memory 708, or installed from a ROM 702. When the computer program is executed by the processor 701, it performs the functions defined in the controller reset monitoring method of the embodiments of the present invention.

[0106] Figure 7 The vehicle shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0107] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the controller reset monitoring method shown in the above embodiments is implemented.

[0108] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0109] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A controller reset monitoring method, characterized in that, The method includes: When the vehicle controller is detected to be performing a reset in response to an anomaly, the real-time operating status of the vehicle is obtained; Based on the real-time operating status, the reset risk level of the vehicle controller is determined; wherein, the reset risk level is used to characterize the degree of impact of the vehicle controller performing a reset on vehicle operation; The reset risk level is uploaded to the cloud so that when the cloud detects that the reset risk level of the vehicle controller is higher than the risk level threshold, it sends an alarm message to the vehicle.

2. The controller reset monitoring method according to claim 1, characterized in that, The real-time operating status includes communication status, power-on status, and vehicle speed; determining the reset risk level of the vehicle controller based on the real-time operating status includes: If the communication status is detected as closed, the reset risk level is determined to be Level 1; If the communication status is detected as enabled and the power-on status is detected as disabled, the reset risk level is determined to be level two; level two is higher than level one. If the communication status is detected as enabled, the power-on status is detected as powered on, and the vehicle speed is lower than the vehicle speed threshold, the reset risk level is determined to be level three; the level three is higher than the level two. If the communication status is detected as enabled, the power-on status is detected as powered on, and the vehicle speed is not lower than the vehicle speed threshold, the reset risk level is determined to be level four; level four is higher than level three.

3. The controller reset monitoring method according to claim 1, characterized in that, The method further includes: Read the call stack information of the vehicle controller stored in non-volatile memory; wherein, the call stack information includes function call information and register values; The call stack information is uploaded to the cloud so that the cloud can determine the reason for the reset of the vehicle controller based on the call stack information.

4. The controller reset monitoring method according to claim 3, characterized in that, Before reading the call stack information of the vehicle controller stored in non-volatile memory, the method further includes: When the vehicle controller malfunctions, the call stack information of the vehicle controller is recorded and stored in volatile memory. After detecting that the vehicle controller performs a reset in response to an anomaly, the call stack information is transferred from the volatile memory to the non-volatile memory.

5. The controller reset monitoring method according to claim 3, characterized in that, The method further includes: Based on the call stack information, the reset risk level, and the real-time running status, reset information is generated, and snapshot information of the reset information is generated. The reset information and the snapshot information are uploaded to the cloud so that the cloud can display the reset information and the snapshot information.

6. The controller reset monitoring method according to claim 5, characterized in that, The method further includes: The reset information and the snapshot information are associated and stored in a non-volatile memory, and the number of times the reset information and the snapshot information are stored is recorded; If the number of storage attempts is detected to be greater than the storage attempt threshold, the earliest reset information and snapshot information stored in the non-volatile memory are deleted.

7. The controller reset monitoring method according to claim 5, characterized in that, Uploading the reset information and the snapshot information to the cloud includes: The reset information and the snapshot information are packaged into a reset data packet; The reset data packet is sent to the gateway device, so that the gateway device uploads the reset data packet to the cloud.

8. A controller reset monitoring device, characterized in that, The device includes: The first processing module is used to obtain the real-time operating status of the vehicle when the vehicle controller is detected to be performing a reset in response to an abnormality. The second processing module is used to determine the reset risk level of the vehicle controller based on the real-time operating status; wherein, the reset risk level is used to characterize the degree of impact of the vehicle controller performing a reset on vehicle operation; The third processing module is used to upload the reset risk level to the cloud, so that when the cloud detects that the reset risk level of the vehicle controller is higher than the risk level threshold, it sends an alarm message to the vehicle.

9. A controller reset monitoring system, characterized in that, The system includes: The vehicle is configured to acquire its real-time operating status when an on-board controller is detected to be performing a reset in response to an anomaly; based on the real-time operating status, determine the reset risk level of the on-board controller; wherein the reset risk level characterizes the degree of impact of the on-board controller's reset on vehicle operation; and upload the reset risk level to the cloud. The cloud-based system receives the reset risk level sent by the vehicle and sends an alarm message to the vehicle when it detects that the reset risk level of the vehicle controller is higher than the risk level threshold.

10. A vehicle, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the controller reset monitoring method according to any one of claims 1 to 7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the controller reset monitoring method according to any one of claims 1 to 7.

12. A computer program product, characterized in that, Includes computer instructions for causing a computer to perform the controller reset monitoring method according to any one of claims 1 to 7.

Images