Method for monitoring SOC in vehicle and SOC monitoring system

Abstract

The invention relates to a monitoring method of an SOC in a vehicle and an SOC monitoring system, the SOC comprises a plurality of business modules, and the method comprises the following steps: obtaining a state signal from the business module to be monitored; judging whether the service module is abnormal or not based on the state signal; in response to the abnormality of the service module, judging whether the abnormal service module is a key service module or not; and resetting the SOC in response to the fact that the abnormal service module is a key service module. By acquiring the state signal sent by the service module, the system state can be captured in real time, and continuous observation of the service module is ensured. And secondly, abnormal judgment is carried out and a key business module is arranged, so that differentiated processing strategies are provided, and the stability of key functions and the safe operation of the vehicle are ensured. And finally, the reliability and the stability of the vehicle system are improved, and the user experience is improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle SOC monitoring, and specifically provides a method for monitoring SOC in a vehicle and a SOC monitoring system. Background Art

[0002] Currently, multiple business modules are often deployed in the system-on-chip (SOC) in vehicles to support various functions and services of the vehicle. These business modules are responsible for handling complex tasks ranging from basic vehicle control to advanced driver assistance systems (ADAS).

[0003] However, as the number and complexity of business modules increase, how to effectively monitor these business modules and promptly discover and handle potential anomalies has become a significant technical challenge.

[0004] Accordingly, the art needs a new SOC monitoring solution in a vehicle to solve the above problems. Summary of the invention

[0005] In order to overcome the above-mentioned defects, the present application is proposed to provide a solution or at least partially solve the technical problem of difficulty in discovering and handling abnormalities of business modules in vehicle SOC in the prior art.

[0006] In a first aspect, the present application provides a method for monitoring the SOC in a vehicle, wherein the SOC includes multiple business modules, and the method includes: obtaining a status signal from the business module to be monitored; judging whether the business module is abnormal based on the status signal; in response to the business module being abnormal, judging whether the abnormal business module is a critical business module; in response to the abnormal business module being a critical business module, resetting the SOC.

[0007] Furthermore, the method further includes: in response to the abnormal business module not being a critical business module, setting the output signal of the abnormal business module to a preset safety value.

[0008] Furthermore, before "determining whether the abnormal software module is a key business module", the method further includes: obtaining the key business module, wherein the method for obtaining the key business module includes: obtaining the operation mode of the current vehicle; and obtaining the key business module corresponding to the operation mode of the current vehicle based on the operation mode of the current vehicle.

[0009] Furthermore, the method further includes: in response to determining that the abnormal business module is not a critical business module, broadcasting to other business modules in the SOC, so that the business modules requiring the safety value receive the safety value based on the broadcast.

[0010] Furthermore, the method further includes: in response to determining that the abnormal business module is not a key business module, setting an HMI signal, and displaying a warning through an instrument or a display screen based on the HMI signal.

[0011] Furthermore, the SOC includes an MCU, and at least part of the service modules are arranged on the MCU, wherein when an abnormal service module is arranged on the MCU, resetting the SOC includes resetting the MCU.

[0012] In a second aspect, the present application also provides a SOC monitoring system, wherein the system includes a SOC and a monitoring module, the SOC includes multiple business modules, and the monitoring module is used to monitor at least one of the business modules in the SOC based on any one of the monitoring methods in the above embodiments.

[0013] Furthermore, the monitoring module is arranged on the SOC, and the number is at least one.

[0014] Furthermore, when there are multiple monitoring modules, the multiple monitoring modules are respectively set in at least two cores, wherein the activation of each monitoring module is determined based on the load of the core in which it is located.

[0015] Further, the SOC includes an A core and an MCU, the MCU includes an M master core and at least one M slave core, information is exchanged between the A core, the M master core and at least one M slave core, and the plurality of business modules are respectively arranged on the A core, the M master core and the M slave core;

[0016] The monitoring module includes a first monitoring module arranged on the M master core, so that the M master core monitors the service module on the A core and at least one M slave core based on the first monitoring module;

[0017] And / or, the monitoring module includes a second monitoring module arranged on at least part of the business modules, so that at least part of the business modules monitor the counterparty business module based on the second monitoring module, wherein the counterparty business module is a module that interacts with at least part of the business modules for business information.

[0018] The above one or more technical solutions of this application have at least one or more of the following Beneficial effects:

[0019] In the implementation of the technical solution of the present application, efficient monitoring and exception management of multiple business modules in the vehicle SOC are achieved by implementing a detailed monitoring process. By acquiring the status signal sent by the business module, the system status can be captured in real time to ensure continuous observation of the business module. Secondly, based on these status signals, the business module is judged to be abnormal, so that abnormal business modules can be quickly identified. Furthermore, by distinguishing whether the abnormal business module belongs to a key business module, the technology provides a differentiated processing strategy to ensure the stability of key functions and the safe operation of the vehicle. When an abnormality is identified in a key business module, a reset operation is performed on the SOC. This technology effectively prevents the spread of the abnormality and ensures the rapid recovery of the system, thereby improving the reliability and stability of the vehicle system while improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The disclosure of the present application will become more easily understood with reference to the accompanying drawings. It is easy for those skilled in the art to understand that these drawings are only for illustrative purposes and are not intended to limit the scope of protection of the present application. In addition, similar numbers in the drawings are used to represent similar components, among which:

[0021] Figure 1 is a flow chart of main steps of a method for monitoring SOC in a vehicle according to an embodiment of the present application;

[0022] Figure 2 is a schematic diagram of a structure in which a monitoring module is arranged on an M main core according to an embodiment of the present application;

[0023] Figure 3 is a schematic flow chart of sub-steps of a method for monitoring SOC in a vehicle according to an embodiment of the present application;

[0024] Figure 4 is a schematic diagram of interaction between a software module and a vehicle controller of a method for monitoring SOC in a vehicle according to an embodiment of the present application;

[0025] Figure 5 is a schematic diagram of interaction of signal transmission between software modules of a method for monitoring SOC in a vehicle according to an embodiment of the present application;

[0026] Figure 6 is a schematic diagram of corresponding nodes of a software module of a method for monitoring SOC in a vehicle according to an embodiment of the present application;

[0027] Figure 7 is a schematic diagram of corresponding nodes of a software module of a method for monitoring SOC in a vehicle according to an embodiment of the present application;

[0028] Figure 8It is a flowchart of the steps of a method for monitoring SOC in a vehicle according to an embodiment of the present application. DETAILED DESCRIPTION

[0029] Some embodiments of the present application are described below with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are only used to explain the technical principles of the present application and are not intended to limit the protection scope of the present application.

[0030] In the description of the present application, "module" may include hardware, software or a combination of the two. A module may include hardware circuits, various suitable sensors, communication ports, memories, and may also include software parts, such as computer programs, or a combination of software and hardware. Non-temporary computer-readable storage media include any suitable media that can store computer programs, such as magnetic disks, hard disks, optical disks, flash memory, read-only memory, random access memory, etc. The term "A and / or B" means all possible combinations of A and B, such as just A, just B, or A and B. The term "at least one A or B" or "at least one of A and B" has a similar meaning to "A and / or B" and may include just A, just B, or A and B. The singular terms "one" and "the" may also include plural forms.

[0031] In an example of an application scenario of the present application, the SOC includes multiple business modules. In the vehicle system in which the present invention is located, the business module is responsible for processing complex data, performing specific tasks, managing device communications, and other aspects. Each business module is designed to perform a specific set of functions, such as data acquisition, signal processing, communication protocol management, user interface interaction, etc. They interact with other business modules or other parts of the system (such as the vehicle controller in the vehicle) through predefined interfaces.

[0032] See attached Figure 1 , Figure 1 FIG. 1 is a flow chart of the main steps of a method for monitoring SOC in a vehicle according to an embodiment of the present application. Figure 1 As shown, the method for monitoring SOC in a vehicle in the embodiment of the present application mainly includes the following steps S10 to S40.

[0033] Step S10: Acquire a status signal sent from the service module to be monitored.

[0034] In this embodiment, the status signal is data or instructions sent from the service module to the monitoring module. The current status of the service module to be monitored can be known by analyzing the status signal.

[0035] In one implementation, a variety of methods may be used to monitor the service module, including but not limited to Rolling Counter (RC for short) and heartbeat signal.

[0036] In one embodiment, taking Rolling Counter as an example, it is a counting mechanism used in communication protocols and data exchange, which confirms the continuity and integrity of data by periodically increasing the count value. In this embodiment, further, the business module is responsible for generating a status signal containing an RC value and periodically sending the status signal. The status signal is a data packet generated and sent by the business module, which contains specific information for monitoring, namely the current value of RollingCounter, referred to as RC value. In other words, the status signal acts as a real-time indicator of the operating status of the business module, and reports its activity status to the monitoring module by regularly updating and sending the RC value.

[0037] In this embodiment, the service module uses the Rolling Counter to increment the RC value each time a status signal is sent (for example, incrementing from 0 to a certain maximum value and then returning to 0 to start a new cycle), thereby providing the monitoring module with a mechanism for detecting whether the service module is in a normal working state. Specifically, if the monitoring module finds unexpected behavior of the RC value in the received status signal, such as the count value not increasing as expected, unexpectedly resetting or jumping, this indicates that the service module has encountered an abnormality.

[0038] In this implementation, Rolling Counter is used for monitoring. The advantage of Rolling Counter is that it is relatively simple and convenient. It is relatively simple to deploy and generally has a relatively small computing burden on the business module. In contrast, Rolling Counter cannot effectively diagnose the cause of abnormalities, so a more complex monitoring method with more powerful functions but a greater burden on the core will be chosen.

[0039] Preferably, in one embodiment, the SOC monitoring system includes a monitoring module, wherein the monitoring module is arranged on the SOC, wherein the monitoring module obtains a status signal sent from the business module. Further, the SOC also includes an MCU (microcontroller unit, referred to as M core) and an A core, wherein the MCU includes at least one M master core and multiple M slave cores, and the M master core is provided with a monitoring module. The business modules are distributed on the A core in the SOC and the M master core and M slave core in the MCU.

[0040] In this embodiment, the monitoring module is only set on the M main core. Figure 2 As shown, Figure 2It is a schematic diagram of the structure in which the monitoring module in this embodiment is set on the M main core. Figure 2 The relationship between the business module and the monitoring module is shown in FIG. 1 , and the business module sends a status signal to the monitoring module. In this embodiment, when the monitoring module is set on the M main core, the monitoring module can make full use of the central position of the M main core to achieve efficient monitoring of the entire SOC business module. Among them, the M main core, due to its core position in the SOC, can provide sufficient processing power to analyze and process complex monitoring data from the business module. In addition, since the M main core directly communicates with all business modules, it can quickly receive status signals to ensure the real-time and accuracy of the monitoring data.

[0041] In this embodiment, the advantages of setting the monitoring module on the M main core include: 1. When encountering multiple business module anomalies. Since the monitoring module can monitor all business modules in the module at the same time, the M main core can make the best judgment and operation based on the actual situation of the business module anomaly. For example, if there are problems with multiple business modules at the same time, the monitoring module can immediately identify and evaluate the overall impact, and take more refined control measures based on the overall impact. This more refined control measure relies on the global monitoring brought by the monitoring module being set on the M main core. 2. The monitoring module is integrated on the M main core. Since the subsequent tasks of responding to the anomalies will also fall on the M main core, when encountering business module anomalies, the monitoring module integrated on the M main core can respond quickly, execute the necessary abnormal diagnosis and recovery procedures, and minimize the system downtime. Thereby improving the safety of the vehicle and the driving experience.

[0042] In one implementation, the monitoring module is only set on the M main core. At this time, the monitoring module in the M main core assumes the monitoring responsibility of all business modules in the entire SOC. The monitoring module will effectively collect and process the status signals from each business module, and judge the business module corresponding to the status signal based on the collected status signals.

[0043] Step S20: Determine whether the service module is abnormal based on the status signal.

[0044] In one embodiment, the monitoring module parses and analyzes the status signals from the service module. The monitoring module usually identifies any anomalies or deviations by comparing these signals with expected values ​​or ranges of normal operating conditions, thereby determining whether the service module is in an abnormal state.

[0045] Specifically, the monitoring module adopts corresponding strategies to evaluate the health status of the business module based on the monitoring method used by the business module. For example, taking the Rolling Counter as an example, the monitoring module verifies whether the business module is abnormal by checking the order of the RC values ​​in the received status signal. If the monitoring module finds that the RC values ​​are discontinuous or repeated, it indicates that the business module corresponding to the status signal is abnormal.

[0046] Step S30: In response to a service module abnormality, determining whether the abnormal service module is a key service module.

[0047] In this embodiment, if the result of the judgment in step S20 is that the service module is abnormal, it is then judged whether the abnormal service module is a critical service module. A critical service module refers to one or more service modules that are critical to the normal operation of the vehicle and the safety of the passengers.

[0048] In one implementation, the key business module is usually responsible for processing the core functions of the vehicle, such as power control, brake system management, and vehicle communication system, etc. However, in the present invention, the key business module is not an absolute setting.

[0049] The reason for determining whether the abnormal module is a key business module is that different types of business module abnormalities have different impacts on the vehicle system. Therefore, in this embodiment, different countermeasures are taken according to the impact, such as Figure 8 As shown. For abnormalities in business modules that are critical business modules, the system must immediately restart the SOC to quickly restore the normal operation of the vehicle. For example, while the vehicle is driving, if an abnormality occurs in the business module of the power control, the vehicle may need to immediately reset the SOC to restore control of the power system; and if an abnormality occurs in the business module of the infotainment system, the system may only need to record the abnormal information and notify the driver without having to immediately restart the entire SOC. In this example, the business module of the power control is a critical business module, while the business module of the infotainment system is not a critical business module.

[0050] The judgment process involves comparing the abnormal business module judged by the monitoring module with the list of key business modules. The monitoring module identifies the abnormal module based on the received status signal and checks whether the module is listed in the list of key business modules. The next step is performed based on the judgment result.

[0051] In this embodiment, different processing strategies are implemented based on the differentiated importance of abnormal business modules, so that the vehicle system can minimize the impact of abnormalities on the normal operation of the vehicle while ensuring core functions and occupant safety.

[0052] In one embodiment, the business modules included in the key business module are fixed and preset based on experience. This means that the key business modules have been clearly defined in the system design phase, which are usually determined based on the functional importance of the business modules, their contribution to safety, and their irreplaceability in vehicle operation.

[0053] In another implementation, before step S30, step S03 is further included. Step S03: acquiring a key business module.

[0054] In this embodiment, the key business module is determined based on the current vehicle operation mode to determine which business modules are specifically included in the key business module. That is, in this embodiment, the business modules included in the key business module are not fixed.

[0055] In this embodiment, the method for obtaining the key business module includes steps S301-S302. Figure 3 As shown, the details are as follows:

[0056] Step S301: Obtain the current operating mode of the vehicle.

[0057] In this embodiment, the current operating mode of the vehicle refers to the mode in which the vehicle is operating at the current time point.

[0058] In one embodiment, the vehicle's operating modes may include: charging mode, driving mode, entertainment mode when parked, etc.

[0059] Step S302: Based on the current operation mode of the vehicle, a key business module corresponding to the current operation mode of the vehicle is obtained.

[0060] In this embodiment, the business modules in the key business module correspond to the current operation mode of the current vehicle. In this embodiment, considering that the safety, performance and user experience requirements of the vehicle are different in different operation modes, which business modules are regarded as key business modules also change accordingly.

[0061] For example, when the vehicle is in charging mode, the key business modules are business modules related to charging process management, such as battery management system (BMS) business module, charging status monitoring business module and energy conversion control business module. This is because during the charging process, ensuring the safe charging of the battery and avoiding overcharging or overheating are the priority parts of the vehicle charging process. On the contrary, modules such as the vehicle's power control system are not so important at this time and are not selected as key business modules in the current mode.

[0062] For another example, when the vehicle is in driving mode, the key business modules are the power control system business module, the brake system business module, and business modules directly related to safe driving. The normal operation of these business modules is crucial to ensuring the driving safety and performance of the vehicle, and any abnormality may directly affect driving safety.

[0063] In summary, it can be seen that in this embodiment, by closely integrating key business modules with the current operating mode of the vehicle, the system can accurately reflect the real-time status and needs of the vehicle. This method allows the system to flexibly identify which business modules are critical in any specific operating mode, ensuring that the reliability of the most critical business modules can be prioritized for the core needs of the vehicle's current mode. This design not only improves the intelligence of the vehicle system, but also provides a higher level of safety protection for the vehicle and will bring a better user experience to users.

[0064] Step S40: In response to determining that the abnormal service module is a key service module, resetting the SOC.

[0065] In this embodiment, if the result of determination in step S30 is that the abnormal service module is a critical service module, the SOC is reset.

[0066] In one implementation, resetting the SOC means restarting the SOC, that is, initializing the SOC. In one implementation, the SOC cannot reset a single service module or a single sub-core.

[0067] In this embodiment, when the abnormal service module is a key service module, timely resetting the SOC can minimize the impact of the abnormal service module on vehicle safety and occupant safety.

[0068] After step S40, step S50 or step S60 is selectively performed.

[0069] Step S50: In response to determining that the abnormal service module is not a critical service module, setting the output signal of the abnormal service module to a preset safety value.

[0070] In this embodiment, the safety value is usually a set of predefined parameters or data used to control the vehicle to take safe operation behavior when an abnormality occurs in the business module. The safety value is usually designed to maintain or guide the vehicle into a state with minimum risk to prevent accidents or dangerous situations caused by abnormalities in the business module. From the results of sending the safety value, the safety value will be sent to the corresponding vehicle controller or the business module that needs the safety value.

[0071] In one implementation, the output signal of the abnormal business module is set to a preset safety value, which indicates that the role of the safety value is to eliminate the abnormal effect caused by the output signal of the abnormal business module.

[0072] In order to make it easier to understand this technology, an example is given here. Figure 4 As shown, the details are as follows: Here, taking business module A and vehicle controller B as an example, it is assumed that business module A is responsible for sending an acceleration control signal to vehicle controller B to adjust the speed of the vehicle. In the case of automatic following, module A is responsible for calculating and sending the corresponding acceleration or deceleration instructions to controller B according to the distance from the front vehicle to achieve the effect of following the vehicle. Furthermore, business module A will send the acceleration control signal to RAM, and then vehicle controller B will obtain the acceleration control signal from RAM.

[0073] Assume that at a certain moment, due to some reason, business module A becomes abnormal and cannot continue to send new acceleration control signals. In the absence of a preset safety value, the vehicle controller B will continue to execute the last acceleration control signal sent before the business module A becomes abnormal, even if this instruction may no longer be suitable for the current driving conditions. In this example, the acceleration control signal at this time is called an error signal. For example, if the instruction is to increase the vehicle's speed by 1km per second, then when business module A is abnormal, the vehicle controller will still execute the instruction brought by the acceleration control signal of accelerating by 1km per second.

[0074] At this time, the role of the safety value is that when an abnormality is detected in the business module A, the system will generate a safety value and send this safety value to the vehicle controller B. This safety value also represents an acceleration control signal. This safety value is a new and safer acceleration control signal, which replaces the signal that the abnormal module A should have sent. For example, the acceleration control signal represented by this safety value instructs the vehicle controller to adjust the acceleration to 0. This avoids the dangerous situation caused by continuous improper acceleration caused by the abnormality of the business module A.

[0075] In this example, the safety value is used to replace the signal that the abnormal module should have sent. This example details the situation where the safety value is sent to the corresponding vehicle controller. The business module is similar to the situation where the safety value is sent to the vehicle controller, except that the safety value is sent to the required business module. Take the example of sending the safety value to the business module that requires the safety value. Figure 5 As shown:

[0076] Business module A, business module B, and business module C. Business module A is responsible for outputting the acceleration control signal. Business module A is part of the autonomous driving system and is used to automatically calculate the acceleration required by the vehicle. The acceleration control signal is an acceleration value, and the acceleration control signal will be sent to business module B. Business module B is an arbitration module, and business module B will arbitrate according to the current operating mode of the vehicle. For example, if the vehicle is in autonomous driving mode, it will accept the acceleration value corresponding to the acceleration control signal of module A and send the acceleration value as the arbitration result to business module C. Module C is responsible for sending the arbitration result to the vehicle's CAN bus, so that the vehicle can execute the acceleration value sent by business module B.

[0077] In the prior art, assuming that an abnormality occurs in business module A at this time, business module B will still send the acceleration value corresponding to the last acceleration control signal from business module A before the abnormality to business module C. Obviously, this is very dangerous. However, if a safety value is used, then this safety value will be sent directly to business module C to replace the arbitration result originally sent by module B. The safety value at this time has the same physical properties as the arbitration result that business module B is going to send to business module C. As mentioned above, the arbitration result is an acceleration value. For example, the safety value at this time is acceleration value = 0, to ensure that the vehicle can safely decelerate or maintain the current speed when business module A is abnormal, to prevent unsafe conditions caused by continuing to drive according to the acceleration control signal before the abnormality.

[0078] In this embodiment, the vehicle controller is one of the core components in the vehicle system, which is responsible for receiving control signals from various business modules and controlling multiple functions of the vehicle such as the power system, braking system, steering system, etc. By obtaining control instructions issued by the internal business modules of the vehicle SOC, the vehicle controller can achieve precise vehicle behavior control, thereby supporting advanced functions including automatic driving and dynamic stability control.

[0079] In one implementation, when it is determined that the abnormal service module is not a critical service module, there is no need to restart the SOC.

[0080] Preferably, in one embodiment, whether a safety value is needed is determined according to the current operating mode of the vehicle. The establishment of the safety value is to protect the safety of the vehicle by controlling the vehicle controller, but this method is not needed in some operating modes of the vehicle. For example, when the vehicle is in charging mode, the vehicle remains stationary, so a safety value is not needed. The need for a safety value here refers to the need to use the method of generating a safety value and using the safety value to control the vehicle.

[0081] Furthermore, the vehicle determines whether to change the operating mode based on the current operating mode of the vehicle and the abnormal business module. For example, if the operating mode of the vehicle is the automatic driving mode, and the abnormal business module is also the business module of the automatic driving mode, the vehicle will exit the automatic driving mode and switch to another preset mode, such as the manual driving mode.

[0082] Further, in response to determining that the abnormal business module is not a key business module, an HMI (human-machine interface) signal is set, and a warning display is performed through an instrument or a display screen based on the HMI signal. In this embodiment, the business module generates an HMI signal to notify the user of the abnormal function for a function of the corresponding vehicle.

[0083] Step S60: In response to determining that a safety value is needed, generating a safety value for a business module corresponding to the abnormality, and controlling vehicle operation based on the safety value.

[0084] In one implementation, if it is determined that a security value is required, a corresponding security value is generated.

[0085] In this embodiment, when the monitoring module determines that a certain service module is abnormal and the module is not a critical service module, the vehicle operation is controlled based on the safety value.

[0086] Preferably, in one embodiment, a security value corresponding to the abnormal business module is generated and sent to a corresponding vehicle controller, wherein the corresponding vehicle controller refers to the object to which the abnormal business module originally intended to send a control instruction.

[0087] In one implementation, the safety value is generated by the monitoring module of the M main core and is directly sent to the corresponding vehicle controller via the M main core.

[0088] In summary, the mechanism of generating and sending safety values ​​is a reliable safety measure in the vehicle control system. It not only improves the safety and reliability of the vehicle when an abnormality occurs in the business module, but also enhances the system's ability to respond to abnormal situations, ensuring the safety of the vehicle and passengers.

[0089] In step S60, "controlling vehicle operation based on safety value" includes: sending the safety value of the business module corresponding to the abnormality to the business module requiring the safety value.

[0090] In this implementation manner, the service module requiring a safety value is at least one of the service modules located at a subsequent node position of the abnormal service module.

[0091] In order to better understand what at least one of the business modules located at the subsequent node position of the abnormal business module means, an example is given in this application for explanation, that is, the example of business module A, business module B and business module C mentioned above. In this embodiment, each of business module A, business module B and business module C represents a node.

[0092] In the above example, it has been explained that the signals are transmitted between service modules A, B and C in a certain order. It is easy to understand that the nodes corresponding to the three service modules also have a certain order. Figure 6 As shown in , if business module B is selected as the current node, then business module A is the business module corresponding to the previous node, and business module C is the business module corresponding to the next node. Figure 7 As shown, if the business module located at the subsequent node of the business module A, in the example of the three modules, includes the business module B and the business module C.

[0093] Furthermore, in this embodiment, the service module requiring a safety value is one of the service modules located at a subsequent node position of the abnormal service module.

[0094] In one embodiment of the present invention, a monitoring module is provided on the M main core, and the monitoring module monitors the business modules in the SOC for abnormalities. In response to determining that the abnormal business module is not a critical business module, the monitoring module broadcasts to the business modules in the SOC, wherein the broadcast is used to notify the business modules in the SOC, and the content of the notification is that the abnormal business module has an abnormality, so that the business module that needs the safety value receives the safety value based on the broadcast. Specifically, the business module located at the next node of the abnormal business module receives the broadcast and sends the safety value to the business module that needs the safety value. In this embodiment, the safety value is generated by the M main core or the business module that monitors the abnormal business module.

[0095] In this embodiment, the broadcast is used to inform the service module located at the next node of the abnormal service module that the service module communicating with it has become abnormal and needs to receive the safety value sent by the monitoring module.

[0096] Step S70: In response to determining that the safety value is not needed, other service modules except the abnormal service module are maintained to continue to operate.

[0097] In one embodiment, there are some situations where it is not necessary to use the safety value, such as when the vehicle is in charging mode.

[0098] In this embodiment, through the above steps S10-S70, effective monitoring of the service module, abnormality judgment, and appropriate handling after the abnormality are achieved. The present invention ensures that the vehicle can maintain the stability and safety of its key functions when facing a service module abnormality through a series of orderly steps, while minimizing the impact on vehicle operation and passenger experience.

[0099] In this embodiment, a SOC monitoring system is proposed, wherein the system includes a monitoring module, the monitoring module is used to monitor at least one business module in the SOC, and wherein the monitoring module can execute and run the above-mentioned method for monitoring the SOC in the vehicle.

[0100] Most of the technologies in this embodiment are the same as those in Embodiment 1. The difference lies in the setting mode of the monitoring module in this embodiment. In this embodiment, there is not only one monitoring module on the M master core, but also a monitoring module is deployed on the slave core. Other than that, the rest of the technologies are the same as those in Embodiment 1, and will not be described in detail here.

[0101] In this embodiment, at least one slave core is provided with a monitoring module, and the monitoring module includes a first monitoring module. Therefore, in the SOC at this time, not only the M master cores are provided with the first monitoring module, but also at least one slave core is provided with the first monitoring module. When processing complex or resource-intensive tasks, the first monitoring module deployed on the slave core can effectively share the load of the M master cores, thereby optimizing the performance of the entire system.

[0102] In this embodiment, the first monitoring module deployed on the slave core can independently perform monitoring tasks, including collecting and analyzing status signals from other business modules. This independent monitoring mechanism ensures that the monitoring process does not interfere with the normal operation of the M master core, while ensuring the real-time and accuracy of monitoring. In addition, in this embodiment, the deployment of the first monitoring module on the slave core also increases the redundancy and reliability of the system, because even if an abnormality occurs in the monitoring module on the M master core, the monitoring module located on the slave core can still continue to run and provide system status monitoring and reporting.

[0103] Furthermore, in one embodiment, the activation of the monitoring module is determined based on the load of the core in which it is located. In this embodiment, when the load of the M main cores reaches a preset load condition, the first monitoring module on the M main cores is turned off.

[0104] For example, when the M main core processes highly complex computing tasks or manages a large amount of data exchange, its performance may become a bottleneck for system operation. In this case, if the M main core continues to undertake monitoring tasks, especially when the monitoring tasks use monitoring methods that require relatively high computing power, the performance bottleneck problem may be further aggravated. At this time, when the load of the M main core reaches the preset load condition, the first monitoring module on the M main core is turned off. The preset condition here can be the occupancy ratio threshold of the M main core. For example, when the occupancy ratio of the M main core is greater than the preset occupancy ratio threshold, the first monitoring module on the M main core is turned off, thereby releasing the computing power of the M main core while maintaining the monitoring function.

[0105] Furthermore, the first monitoring module on the M main core will monitor the slave core. Specifically, the slave core will send monitoring information to the first monitoring module of the M main core. The M main core determines whether the slave core is abnormal based on the monitoring information. If abnormal, determine whether the slave core is a key slave core. If so, restart the SOC; if not, set a safety value and send it to the vehicle controller corresponding to the abnormal slave core. In this embodiment, the monitoring information is set to distinguish the status signal. The monitoring information is generally similar to the status signal, and can be monitored using monitoring methods such as heartbeat.

[0106] Further, the first monitoring module on the M main core monitors other cores in the SOC except the MCU, such as the A core, etc. The first monitoring module on the M main core obtains monitoring information of other cores except the MCU, and determines whether the core corresponding to the monitoring information is abnormal based on the monitoring information.

[0107] It should be noted that the monitoring method adopted by the M master core when monitoring the slave core and other cores except the MCU may be different, and the monitoring information at this time is set according to the corresponding monitoring method. For example, the M master core may use the heartbeat when monitoring the slave core, and the monitoring information sent by the slave core to the first monitoring module of the M master core is the heartbeat information; while the M master core uses RC monitoring to monitor other cores except the MCU, the monitoring information sent by other cores except the MCU to the first monitoring module of the M master core is the RC value.

[0108] Furthermore, the monitoring module in the slave core monitors the M master core and other slave cores. Specifically, the core in the SOC sends monitoring information back to the monitoring module of the slave core. The advantage of this setting is that it increases the redundancy and reliability of the system.

[0109] Embodiment 3:

[0110] Most of the techniques in this embodiment are the same as those in Embodiment 1. The difference lies in the setting method of the monitoring module and the generation method of the security value in this embodiment. In this embodiment, a monitoring module is provided in the business module instead of providing the monitoring module on the M main core. Other than that, the remaining techniques are the same as those in Embodiment 1 and will not be described in detail here.

[0111] In one embodiment, the monitoring module includes a second monitoring module disposed on at least part of the business modules, so that at least part of the business modules monitor the counterparty business modules based on the second monitoring module.

[0112] In this embodiment, the counterparty service module is a module that interacts with at least some service modules in terms of service information.

[0113] like Figure 6 As shown, for example, if business module B monitors business module A, then business module B is the counterparty module of business module A.

[0114] In this embodiment, the monitoring module includes at least a second monitoring module, wherein the second monitoring module is arranged in each service module, and the service module of the current node obtains the status signal sent by the service module of the previous node and monitors the service module of the previous node.

[0115] In step S10, specifically, the service module at the current node obtains the status signal sent from the service module of the previous node. The monitoring module in the service module of the current node is responsible for analyzing the received status information to determine whether there is an abnormality in the service module of the previous node.

[0116] Accordingly, the service module of the current node sends a status signal to the service module of the next node. The monitoring module in the service module of the next node is responsible for analyzing the received status information to determine whether there is an abnormality in the service module of the current node.

[0117] Furthermore, in one implementation, the business module requiring a safety value is a business module located two nodes after the abnormal business module. The business module located two nodes after the abnormal business module is to use the abnormal business module as the current node, and the business module located at the next node under the business module of the current node is the business module located two nodes after the abnormal business module.

[0118] An example given in this application is used for illustration, that is, the example of service module A, service module B, and service module C mentioned above. If service module A is an abnormal service module, then the service module at the next two nodes is service module C.

[0119] It should be pointed out that although the various steps in the above embodiments are described in a specific order, those skilled in the art can understand that in order to achieve the effect of the present application, different steps do not have to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders. These changes are within the scope of protection of the present application.

[0120] Furthermore, the present application also provides a SOC monitoring system, wherein the system includes a SOC and a monitoring module, the SOC includes multiple business modules, and the monitoring module is used to monitor at least one business module in the SOC based on any one of the monitoring methods in the above embodiments.

[0121] Furthermore, the monitoring module is arranged on the SOC, and the number is at least one.

[0122] Furthermore, when there are multiple monitoring modules, the multiple monitoring modules are respectively set in at least two cores, wherein the activation of each monitoring module is determined based on the load of the core in which it is located.

[0123] Further, the SOC includes an A core and an MCU, the MCU includes an M master core and at least one M slave core, the A core, the M master core and the at least one M slave core interact with each other, and the multiple business modules are respectively arranged on the A core, the M master core and the M slave core;

[0124] The monitoring module includes a first monitoring module arranged on the M master core, so that the M master core monitors the service modules on the A core and at least one M slave core based on the first monitoring module;

[0125] And / or, the monitoring module includes a second monitoring module arranged on at least part of the business module, so that at least part of the business module monitors the counterparty business module based on the second monitoring module, wherein the counterparty business module is a module that interacts with at least part of the business module for business information.

[0126] The relevant user personal information that may be involved in the various embodiments of this application is strictly in accordance with the requirements of laws and regulations, following the principles of legality, legitimacy and necessity, based on the reasonable purposes of business scenarios, to process the personal information that users actively provide during the use of products / services or generated due to the use of products / services, as well as the personal information obtained with the user's authorization.

[0127] The user personal information processed by the applicant will vary depending on the specific product / service scenario, and shall be based on the specific scenario in which the user uses the product / service, which may involve the user's account information, device information, driving information, vehicle information or other related information. The applicant will treat the user's personal information and its processing with a high degree of diligence.

[0128] The Applicant attaches great importance to the security of user personal information and has adopted reasonable and feasible security protection measures that comply with industry standards to protect user information and prevent personal information from being accessed, disclosed, used, modified, damaged or lost without authorization.

[0129] So far, the technical solutions of the present application have been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it is easy for those skilled in the art to understand that the protection scope of the present application is obviously not limited to these specific embodiments. Without departing from the principles of the present application, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will fall within the protection scope of the present application.

Claims

1. A method for monitoring SOC in a vehicle, wherein the SOC includes a plurality of service modules, characterized in that: The method comprises: Acquiring a status signal from the service module to be monitored; Determining whether the service module is abnormal based on the status signal; In response to the business module being abnormal, determining whether the abnormal business module is a key business module; In response to the abnormal service module being a critical service module, the SOC is reset.

2. The method for monitoring SOC in a vehicle according to claim 1, characterized in that: The method further comprises: In response to the abnormal service module not being a critical service module, an output signal of the abnormal service module is set to a preset safety value.

3. The method for monitoring SOC in a vehicle according to claim 1, characterized in that: Before "determining whether the abnormal software module is a key business module", the method further includes: Acquire the key business module, wherein the method for acquiring the key business module includes: Get the current vehicle operating mode; Based on the current operating mode of the vehicle, the key service module corresponding to the current operating mode of the vehicle is obtained.

4. The SOC monitoring method according to any one of claims 1 to 3, characterized in that: The method further comprises: In response to determining that the abnormal service module is not a critical service module, broadcasting is performed to other service modules in the SOC, so that the service modules that need the safety value receive the safety value based on the broadcast.

5. The SOC monitoring method according to any one of claims 1 to 3, characterized in that: The method further comprises: In response to determining that the abnormal business module is not a critical business module, an HMI signal is set, and a warning display is performed through an instrument or a display screen based on the HMI signal.

6. The SOC monitoring method according to claim 1, characterized in that: The SOC includes an MCU, and at least part of the service modules are arranged on the MCU. When an abnormal service module is set on the MCU, resetting the SOC includes resetting the MCU.

7. A SOC monitoring system, comprising a SOC and a monitoring module, wherein the SOC comprises a plurality of service modules, and the monitoring module is used to monitor at least one of the service modules in the SOC based on any one of the monitoring methods in claims 1-6.

8. The SOC monitoring system according to claim 7, characterized in that: The monitoring module is arranged on the SOC, and the number of the monitoring module is at least one.

9. The SOC monitoring system according to claim 7, characterized in that: When there are multiple monitoring modules, the multiple monitoring modules are respectively set in at least two cores, wherein the activation of each monitoring module is determined based on the load of the core where it is located.

10. The SOC monitoring system according to claim 7, characterized in that: The SOC includes an A core and an MCU, the MCU includes an M master core and at least one M slave core, the A core, the M master core and the at least one M slave core exchange information, and the plurality of business modules are respectively arranged on the A core, the M master core and the M slave core; The monitoring module includes a first monitoring module arranged on the M master core, so that the M master core monitors the service module on the A core and at least one M slave core based on the first monitoring module; And / or, the monitoring module includes a second monitoring module arranged on at least part of the business modules, so that at least part of the business modules monitor the counterparty business module based on the second monitoring module, wherein the counterparty business module is a module that interacts with at least part of the business modules for business information.

Images