Abnormality processing method and device, embedded system, vehicle and storage medium
By using spare processing units and nonvolatile memory in the vehicle embedded system, the problem of rapid recovery and function maintenance in the event of system abnormalities is solved, ensuring the safety and stability of the vehicle.
Patent Information
- Application Number
- CN202510540539.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-27
- Publication Date
- 2025-08-01
AI Technical Summary
The car embedded system cannot quickly resume normal operation under abnormal conditions and may interrupt system functions.
The backup processing unit is used to replace the exception processing unit, and the exception information and vehicle control information are saved through non-volatile memory to ensure the system is recovered quickly and the function is stable.
It realizes rapid recovery of the vehicle-mounted embedded system in abnormal situations, avoids interruption of system functions, and ensures safe driving of the vehicle.
Smart Images
Figure CN120406401A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of vehicle control technology, and more specifically, to a method for handling exceptions, a device for handling exceptions, an in-vehicle embedded system, a vehicle, and a computer-readable storage medium. Background Art
[0002] With the development of automotive technology, in-vehicle embedded systems play an increasingly important role in modern vehicles. With the help of in-vehicle embedded systems, a more intelligent, safe, and comfortable driving experience can be provided for users. However, in some cases, in-vehicle embedded systems may encounter exceptions. After an exception occurs, how to quickly restore the system to normal operation and how not to interrupt the functions of the system during the process of restoring normal operation are technical problems that need to be solved. Summary of the Invention
[0003] The present application provides a method for handling exceptions, a device for handling exceptions, an in-vehicle embedded system, a vehicle, and a computer-readable storage medium, so as to quickly restore the system to normal operation when an in-vehicle embedded system encounters an exception and not to interrupt the functions of the system during the process of restoring normal operation.
[0004] In a first aspect, a method for handling exceptions is provided. The method is applied to an in-vehicle embedded system. The in-vehicle embedded system includes a first processing unit and a second processing unit, and the second processing unit is a backup processing unit of the first processing unit. The method includes: during the running of the vehicle, controlling the in-vehicle embedded system by using the first processing unit; if the in-vehicle embedded system encounters an exception, storing the exception information of the in-vehicle embedded system from the internal memory to an external memory by using the first processing unit, where both the internal memory and the external memory are non-volatile memories; storing vehicle control information to a first storage area by using the first processing unit, where the first storage area is a shared storage area of the first processing unit and the second processing unit; after the second processing unit is started up successfully, controlling the in-vehicle embedded system by using the second processing unit instead of the first processing unit.
[0005] As a possible implementation, the vehicle control information includes port-related information of at least one hardware port. The method further includes: after the second processing unit is started up successfully, the second processing unit obtains the port-related information from the first storage area and sets the port states of the at least one hardware port according to the port-related information.
[0006] As a possible implementation manner, the method further includes: after the first processing unit restarts, the first processing unit determines whether the exception information is successfully saved to the external memory; if the exception information is not successfully saved to the external memory, the exception information in the internal memory is re-stored to the external memory.
[0007] As a possible implementation manner, for the first processing unit to determine whether the exception information is successfully saved to the external memory, it includes: the first processing unit performs an integrity check on the exception information stored in the external memory; if the integrity check fails, the first processing unit determines that the exception information is not successfully saved to the external memory.
[0008] As a possible implementation manner, the internal memory is a non-volatile random access memory (RAM); and / or, the external memory is a flash memory (FLASH).
[0009] As a possible implementation manner, the method further includes: after an exception occurs in the vehicle-mounted embedded system, the second processing unit obtains the running information of the first processing unit when the exception occurs; after obtaining the running information, the second processing unit transmits the running information to an external device through the vehicle-mounted communication system.
[0010] As a possible implementation manner, the running information includes at least one of the following: the information stored in the internal memory of the vehicle-mounted embedded system, the information stored in the external memory of the vehicle-mounted embedded system, and the information stored in the registers of the vehicle-mounted embedded system.
[0011] As a possible implementation manner, before starting the second processing unit, the method further includes: if the version of the program running on the first processing unit is a debug version, an exception handler is called to handle the exception of the vehicle-mounted embedded system.
[0012] Second aspect, a device for handling exceptions is provided. The device is located in an in-vehicle embedded system, which includes a first processing unit and a second processing unit, and the second processing unit is a backup processing unit of the first processing unit. The device includes: a first control module, configured to control the in-vehicle embedded system by using the first processing unit during the running of the vehicle; a first storage module, configured to, if an exception occurs in the in-vehicle embedded system, use the first processing unit to store the exception information of the in-vehicle embedded system from an internal memory to an external memory through the internal memory, where both the internal memory and the external memory are non-volatile memories; a second storage module, configured to use the first processing unit to store vehicle control information in a first storage area, and the first storage area is a shared storage area of the first processing unit and the second processing unit; a second control module, configured to, after the second processing unit is started up, use the second processing unit to replace the first processing unit to control the in-vehicle embedded system.
[0013] Third aspect, an in-vehicle embedded system is provided. The in-vehicle embedded system includes: a memory, configured to store program instructions; at least two processing units, including a first processing unit and a second processing unit, where the second processing unit is a backup processing unit of the first processing unit, and the at least two processing units are configured to call the program instructions to execute the method according to the first aspect or any one of the implementation manners in the first aspect.
[0014] Fourth aspect, a vehicle is provided, including the in-vehicle embedded system according to the third aspect.
[0015] Fifth aspect, a computer-readable storage medium is provided, on which program code for executing the method according to the first aspect or any one of the implementation manners in the first aspect is stored.
[0016] Sixth aspect, a computer program product is provided, including program code for executing the method according to the first aspect or any one of the implementation manners in the first aspect.
[0017] In the embodiments of the present application, when an exception occurs in the in-vehicle embedded system, the non-volatile internal memory is used to save the exception information to the non-volatile external memory, and the vehicle control information is stored in the shared storage area of the first processor and the second processor, so that the loss of the exception information can be avoided, and the second processor can quickly obtain the vehicle control information from the shared storage area, thereby enabling the system to quickly recover. Description of the Drawings
[0018] To more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the related art. Obviously, the accompanying drawings in the following description are only some embodiments of the present application, and all other accompanying drawings obtained by those of ordinary skill in the art fall within the scope of the present application.
[0019] Figure 1 It is a structural example diagram of a vehicle-mounted embedded system to which the embodiments of the present application can be applied.
[0020] Figure 2 It is a schematic flowchart of a method for handling exceptions provided by an embodiment of the present application.
[0021] Figure 3 It is a schematic flowchart of a method for handling exceptions provided by another embodiment of the present application.
[0022] Figure 4 It is a schematic flowchart of a method for handling exceptions provided by another embodiment of the present application.
[0023] Figure 5 It is a schematic flowchart of a method for handling exceptions provided by another embodiment of the present application.
[0024] Figure 6 It is a schematic flowchart of a method for handling exceptions provided by another embodiment of the present application.
[0025] Figure 7 It is a schematic flowchart of a method for handling exceptions provided by another embodiment of the present application.
[0026] Figure 8 It is a schematic flowchart of a method for handling exceptions provided by another embodiment of the present application.
[0027] Figure 9 It is a structural example diagram of a device for handling exceptions provided by the embodiments of the present application.
[0028] Figure 10 It is a structural example diagram of a vehicle-mounted embedded system provided by the embodiments of the present application. Detailed implementation manners
[0029] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are some, but not all, of the embodiments of the present application. All other embodiments obtained based on the embodiments in the present application fall within the scope of protection of the present application.
[0030] In the embodiments of the present application, words such as "exemplary" or "for example" are used to represent examples, illustrations, or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the embodiments of the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.
[0031] It should be understood that the specific embodiments described below are only used to explain the present application and are not used to limit the present application.
[0032] The embodiments of the present application can be applied to in-vehicle embedded systems. For the convenience of understanding, the in-vehicle embedded systems mentioned in the embodiments of the present application will be introduced first.
[0033] An in-vehicle embedded system is a dedicated computer system integrated in an automobile and is used to control and manage various functions of the vehicle. With the development of automotive technology, modern automobiles are no longer just traditional mechanical devices but highly integrated electronic and information technology platforms. The in-vehicle embedded system covers multiple aspects from basic engine control to advanced driver assistance systems. For example, the in-vehicle embedded system can be used to control the engine management system, braking system, steering system, airbag system, etc. With the help of the in-vehicle embedded system, a safer, more comfortable, and more efficient driving experience can be provided for users.
[0034] The following will be combined with Figure 1 to introduce the hardware structure of the in-vehicle embedded system.
[0035] Figure 1 FIG. shows a structural example diagram of an in-vehicle embedded system 10 to which the embodiments of the present application can be applied. As Figure 1 shown, the in-vehicle embedded system 10 may include one or more of an electronic control unit (ECU) 110, a sensor 120, an actuator 130, a power supply system (not shown in the figure), etc. It should be noted that Figure 1 only one ECU is shown in
[0036] The ECU 110 may include one or more of a processor 1101, a memory 1102, and a hardware port 1103. The processor 1101 is used to process input signals, execute control logic, and output control instructions. The processor 1101 may be, for example, a central processing unit (CPU). The memory 1102 is used to store program code, data, and configuration information. The memory 1102 includes, but is not limited to, read-only memory (ROM), RAM, FLASH, etc. The hardware port 1103 is used to receive signals input by the sensor 120 and output signals to the actuator 130. The hardware port 1103 may include, but is not limited to, input / output (I / O) interfaces, controller area network (CAN) interfaces, local interconnect network (LIN) interfaces, etc.
[0037] The sensor 120 is used to collect vehicle internal and external environment data. The sensor 120 includes one or more of, but is not limited to, pressure sensors, position sensors, acceleration sensors, gyroscopes, collision sensors, cameras, radars, etc.
[0038] The actuator 130 is used to perform corresponding actions according to instructions issued by the ECU 110. The actuator 130 may include one or more of, but is not limited to, electric motors, solenoid valves, relays, ignition systems, braking systems, steering systems, etc.
[0039] The power supply system is used to supply power to the in-vehicle embedded system.
[0040] To make the in-vehicle embedded system work and complete the functions required by the user, in addition to the above-mentioned hardware system, a corresponding software system also needs to be equipped. The two complement each other to make the entire in-vehicle embedded system work effectively. The software system of the in-vehicle embedded system is used to implement data processing and control logic. The following combines Figure 1 , taking the headlight control as an example, to describe in detail how the in-vehicle embedded system realizes the headlight control function through the combination of hardware and software. In the following example, the sensor 120 is a photosensitive sensor, the actuator 130 is a headlight drive circuit and a relay, the processor 1101 is a CPU, and the hardware port 1103 is an I / O interface.
[0041] The photosensitive sensor 120 of the in-vehicle embedded system detects the external light intensity. The I / O interface 1103 transmits the data detected by the photosensitive sensor 120 to the processor 1101. The software system processes the data collected by the photosensitive sensor 120 and determines whether the light intensity is lower than a preset threshold. If the light intensity is lower than the preset threshold, the software system determines that the vehicle lights need to be turned on, and controls the vehicle light drive circuit and the relay through the actuator driver program, thereby turning on the vehicle lights. Through the above steps, the hardware and software of the in-vehicle embedded system are closely combined to realize the automatic control function of the vehicle lights.
[0042] In summary, the in-vehicle embedded system plays a crucial role in vehicle control. However, in some cases, the in-vehicle embedded system may malfunction. After a malfunction occurs, if the system continues to run, the problem may become more and more serious and eventually lead to a complete failure of the entire system. Therefore, after a malfunction occurs in the in-vehicle embedded system, the malfunction needs to be handled in a timely manner.
[0043] In the related art, after a malfunction occurs in the in-vehicle embedded system, the general method is to restart the system. However, restarting the system usually takes some time to complete and cannot quickly restore the system to a normal state. Moreover, the functions of the system may be interrupted during the restart process.
[0044] To solve the above technical problems, an embodiment of the present application provides a method for handling malfunctions. This method is applied to an in-vehicle embedded system, which includes a first processing unit and a second processing unit, and the second processing unit is a standby processing unit of the first processing unit. The method includes: during the operation of the vehicle, using the first processing unit to control the in-vehicle embedded system; if a malfunction occurs in the in-vehicle embedded system, starting the second processing unit; after the second processing unit is started successfully, using the second processing unit to replace the first processing unit to control the in-vehicle embedded system. This method uses a standby processing unit to replace the malfunctioning processing unit to control the in-vehicle embedded system when a malfunction occurs in the in-vehicle embedded system, which can quickly restore the system to normal operation and does not interrupt the functions of the system during the process of restoring normal operation.
[0045] The following will be combined with Figures 2 to 7 to describe in detail the method for handling malfunctions provided by the embodiment of the present application.
[0046] [[ID=I7]]The method for handling malfunctions provided by the embodiment of the present application can be applied to an in-vehicle embedded system, which may include a first processing unit and a second processing unit.
[0047] The embodiments of the present application do not limit the type of in-vehicle embedded system. The in-vehicle embedded system here can be a power control system, a chassis control system, a safety system, an assisted driving system, an infotainment system, a body control system, etc. The power control system can be, for example, an engine control system, a transmission control system, etc. The chassis control system can be, for example, an anti-lock braking system, a steering system, etc. The safety system can be, for example, a safety airbag control system, a tire pressure monitoring system, etc. The assisted driving system can be, for example, a lane keeping assist system, an adaptive cruise control system, etc. The infotainment system can be, for example, a navigation system, a voice control system, etc. The body control system can be, for example, a vehicle lamp control system, a window / door control system, etc. The in-vehicle embedded system here can have a hardware structure as shown in Figure 1 For details, reference can be made to the description of the corresponding part in Figure 1 which will not be elaborated here.
[0048] The first processing unit and the second processing unit can be two processors. Alternatively, the first processing unit and the second processing unit can also be two processor cores in the processor of the in-vehicle embedded system. The first processing unit can be used as the processing unit that the in-vehicle embedded system uses by default, or the currently used processing unit. The second processing unit can be used as a backup processing unit for the first processing unit.
[0049] When the first processing unit and the second processing unit are processor cores, the first processing unit can be referred to as the current core or the running core of the in-vehicle embedded system, and the second processing unit can be referred to as the backup core of the in-vehicle embedded system.
[0050] Figure 2 is a schematic flowchart of the method for handling exceptions provided by the embodiments of the present application. As shown in Figure 2 the method for handling exceptions provided by the embodiments of the present application can include the following steps S201 to S204.
[0051] In step S201, during the running of the vehicle, the in-vehicle embedded system is controlled by the first processing unit.
[0052] Taking the in-vehicle embedded system as a vehicle lamp control system and the first processing unit as the running core of the in-vehicle embedded system as an example. During the running of the vehicle, the running core can read sensor data through the I / O interface, judge whether to turn on or off the vehicle lamps according to the read data, and control the vehicle lamp drive circuit or relay through the actuator driver to turn on or off the vehicle lamps.
[0053] In steps S202 - S203, if an exception occurs in the in-vehicle embedded system, the first processing unit is used to store the exception information of the in-vehicle embedded system to the external memory through the internal memory, and the first processing unit is used to store the vehicle control information to the first storage area;
[0054] Both the internal memory and the external memory mentioned above are non-volatile memories, and the first storage area is a shared storage area for the first processing unit and the second processing unit. The non-volatile memory can be, for example, non-volatile RAM. The external memory can be, for example, FLASH, disk drive, network storage, etc. In this way, when the external memory fails to successfully save the exception information, the exception information can still be obtained from the non-volatile memory, thus avoiding the loss of exception information.
[0055] The embodiments of the present application do not limit the manifestation forms of exceptions. Here, the exception can be manifested as the sensor not responding or having inaccurate readings, the system response speed being significantly slower, the system being unable to respond to input, the system's fault indicator light being on, the system emitting an alarm sound, the system displaying text prompt information, etc. When an exception occurs in the vehicle-mounted embedded system, the second processing unit can be started. Optionally, in some embodiments, when starting the second processing unit, the operation of the first processing unit can be paused synchronously, that is, stop a certain task or process that the second processing unit is currently executing. Taking the first processing unit as the running core and the second processing unit as the standby core as an example. An exception in the vehicle-mounted embedded system can also be considered as an exception in the running core, and the running core when the exception occurs can be called the exception core. At this time, the standby core can be started. During the process of starting the standby core, the running core can be frozen, that is, pause the task or process that the running core is currently executing.
[0056] In step S204, after the second processing unit is started up, the second processing unit is used to control the vehicle-mounted embedded system instead of the first processing unit.
[0057] Before the second processing unit is started up, the first processing unit controls the vehicle-mounted embedded system to perform corresponding functions. After the second processing unit is started up, the second processing unit is used to control the vehicle-mounted embedded system to perform corresponding functions instead of the first processing unit to ensure the normal operation of the functions. Taking the vehicle-mounted embedded system as a headlight control system and the first processing unit and the second processing unit as the cores of the processor as an example. Before the standby core is started up, the running core reads the sensor data, judges whether to turn on or off the headlights, and controls the headlight drive circuit or relay to turn on or off the headlights. After the standby core is started up, the above steps are executed by the standby core.
[0058] As described in the foregoing description of the hardware structure of the vehicle-mounted embedded system, the vehicle-mounted embedded system may include hardware ports. The hardware ports may include, but are not limited to, I / O ports, CAN ports, LIN ports, etc. During the process of the second processing unit replacing the first processing unit to control the vehicle-mounted embedded system, the first processing unit will transfer the control right of the above-mentioned hardware ports to the second processing unit. If the second processing unit directly initializes the above-mentioned hardware ports after taking over the control of the above-mentioned hardware ports, it may cause unexpected changes in the external signals, thereby triggering a safety accident. Take the vehicle-mounted embedded system as a headlight control system as an example. When the vehicle is driving at night, the first processing unit of the headlight control system controls the hardware port to output a high-level signal to the headlight drive circuit or relay, so that the headlights are in the on state. When an abnormality occurs in the headlight control system, after the second processing unit takes over the control right of the above-mentioned hardware port, if the hardware port is directly initialized, it may cause the hardware port to output a low-level signal to the headlight drive circuit or relay, resulting in the headlights suddenly turning off, and thus triggering a safety accident.
[0059] To further solve the above problems, the method for handling exceptions provided in the embodiments of the present application may further include the following steps S301 (corresponding to Figure 2 step S203 in) and S302.
[0060] In step S301, after an exception occurs in the vehicle-mounted embedded system, the first processing unit stores the port-related information of at least one hardware port (corresponding to the vehicle control information mentioned above) in the first storage area.
[0061] The hardware ports here include, but are not limited to, the CAN ports, LIN ports, I / O ports, etc. mentioned above. The port-related information may be key information related to vehicle control. The embodiments of the present application do not limit the specific type of the port-related information. When the vehicle-mounted embedded system is a brake control system, the port-related information may be, for example, brake control information. When the vehicle-mounted embedded system is a cruise control system, the port-related information may be, for example, vehicle speed information. When the vehicle-mounted embedded system is a headlight control system, the port-related information may be, for example, headlight control information.
[0062] In step S302, after the second processing unit is started up, the second processing unit obtains the port-related information from the first storage area and sets the port status of at least one hardware port according to the port-related information.
[0063] After the second processing unit finishes starting up, the second processing unit can obtain the port-related information stored by the first processing unit from the first storage area, and set the port status of the hardware port according to the obtained port-related information. Taking the in-vehicle embedded system as a headlight control system as an example. When the vehicle is driving at night, the first processing unit controls the hardware port to continuously output a high level to control the headlights to be in the on state. After an abnormality occurs in the headlight control system, the first processing unit can store the high-level state of the hardware port in the first storage area. After the second processing unit finishes starting up, the second processing unit obtains the port information of the hardware port, that is, the high-level state, from the first storage area. Then, the second processing unit sets the port status of the hardware port to the high-level state, so that when the second processing unit replaces the first processing unit to control the headlights, the headlights are always in the on state.
[0064] Through the above steps S301 and S302, when the second processing unit replaces the first processing unit to control the in-vehicle embedded system, the signal output by the hardware port to the outside can be kept unchanged, thereby ensuring the stability of the control function of the in-vehicle embedded system and not affecting the normal driving of the vehicle.
[0065] Optionally, in some embodiments, the first storage area may be a shared storage area of the first processing unit and the second processing unit. The first processing unit and the second processing unit can quickly access the data in the shared storage area. Therefore, storing the port-related information in the shared storage area enables the first processing unit to quickly store the port-related information, and the second processing unit can quickly obtain the port-related information from the shared storage area. In this way, the speed of exception handling can be improved. The specific type of the shared storage area is not limited in the embodiments of the present application. The shared storage area may be, for example, a shared RAM area.
[0066] For an in-vehicle embedded system, the running information at the time of an exception is crucial for locating the cause of the exception. The running information at the time of an exception may include exception information, or may also include other running information related to the exception information. The exception information may include, for example, error logs, error codes, etc. generated by the system. Other running information related to the exception may include the register status information at the time of the exception, etc. Compared with only retaining the exception information, if the running information at the time of the exception can be comprehensively retained when an exception occurs, it helps to improve the efficiency of the maintenance and testing personnel in locating the cause of the exception.
[0067] To better save the above running information at the time of an exception, the method for handling exceptions provided in the embodiments of the present application may further include the following steps S401 and S402.
[0068] In step S401, after an exception occurs in the in-vehicle embedded system, the second processing unit obtains the running information of the first processing unit at the time of the exception.
[0069] The running information of the first processing unit when an exception occurs may include at least one of the following information: the information stored in the internal memory of the vehicle-mounted embedded system, the information stored in the external memory of the vehicle-mounted embedded system, and the information stored in the registers of the vehicle-mounted embedded system. The registers may be, for example, instruction registers, status registers, control registers, etc. As a more specific example, the first processing unit is a running core and the second processing unit is a standby core. After an exception occurs in the vehicle-mounted embedded system, the standby core may obtain all the running information stored by the exception core in the RAM, ROM, FLASH, registers, etc.
[0070] In step S402, after obtaining the running information, the second processing unit may transmit the running information to an external device through the vehicle-mounted communication system.
[0071] The vehicle-mounted communication system here may communicate with the external device using a cellular network or a satellite network. The external device may be, for example, a personal computer, a smart phone, a dedicated monitoring device, etc. Optionally, in some embodiments, the external device may be a cloud server. After the second processing unit obtains the running information of the first processing unit, it may transmit the running information to the external device in various ways. For example, the second processing unit may read the above running information into the file system and transmit the above running information to the external device (such as a cloud server) through the file system. As a more specific example, the first processing unit is a running core and the second processing unit is a standby core. After the standby core obtains all the running information of the exception core, it may read all the running information of the exception core into the file system and upload all the running information of the exception core to the cloud server subsequently.
[0072] Through the above steps S401 and S402, the running information when an exception occurs can be effectively recorded, avoiding the low efficiency of locating the cause of the exception caused by only a small amount of exception information.
[0073] After an exception occurs, the first processing unit may store the exception information in the external memory through the internal memory, so as to be used to locate the cause of the exception. However, when the exception is relatively serious or the driver of the external memory is damaged, it may cause the exception information to fail to be successfully saved in the external memory, resulting in the loss of the exception information and making it impossible to locate the cause of the exception. To solve this problem, the embodiments of the present application provide two possible implementation manners.
[0074] In some other implementations, in addition to using a non-volatile memory as the internal memory, it is also possible to verify whether the external memory has successfully saved the exception information. If the verification result indicates that the external memory has not successfully saved the exception information, the exception information can be saved from the internal memory to the external memory again, thereby increasing the probability that the exception information is successfully saved to the external memory. The following will be described in detail in conjunction with Figure 5 for detailed illustration.
[0075] As Figure 5 shown, the method for processing exceptions provided by the embodiments of the present application may further include the following steps S501 to S503.
[0076] In step S501, after an exception occurs in the vehicle-mounted embedded system, the first processing unit stores the exception information of the vehicle-mounted embedded system to the external memory through the internal memory.
[0077] The internal memory can be a non-volatile memory, such as a non-volatile RAM, to ensure that the exception data saved after power-off will not be lost. The external memory can be, for example, a FLASH. The internal memory usually has a higher access speed than the external memory. Storing the exception information in the internal memory first can quickly save the exception information. And, some external memories (such as FLASH) may require a driver when storing data. Storing the exception information in the internal memory first and then in the external memory can avoid the problem that the exception information cannot be saved normally due to problems with the driver of the external memory.
[0078] In step S502, after the first processing unit restarts, the first processing unit determines whether the exception information has been successfully saved to the external memory.
[0079] In step S501, the exception information can be transferred from the internal memory to the external memory. During the transfer process, the exception information may be lost or incorrect. Therefore, after the first processing unit restarts, it can be determined whether the exception information has been successfully saved in the external memory. If the exception information is successfully saved in the external memory, the exception information saved in the external memory can be directly provided to the maintenance and testing personnel.
[0080] In step S503, if the exception information has not been successfully saved to the external memory, the exception information in the internal memory is re-stored to the external memory.
[0081] In step S502, the first processing unit can determine whether the exception information has been successfully transferred to the external memory. If the exception information has not been successfully saved to the external memory, the exception information in the internal memory can be transferred to the external memory again until the exception information is successfully saved to the external memory.
[0082] As a more specific example, the internal memory is non-volatile RAM and the external memory is FLASH. After an exception occurs in the in-vehicle embedded system, the exception information can be first stored in the non-volatile RAM, and then the exception information stored in the non-volatile RAM can be stored in the FLASH. After the first processing unit restarts, it determines whether the exception information has been successfully saved to the FLASH. If the exception information has been successfully saved to the FLASH, the exception information in the FLASH can be directly provided to the maintenance and testing personnel. If the exception information has not been successfully saved to the FLASH, the exception information is moved from the non-volatile RAM to the FLASH again until the exception information is successfully saved to the FLASH.
[0083] It should also be noted that multiple embodiments are introduced above. Without conflict, these embodiments can be implemented independently or in combination. For example, some of the above embodiments mention that when an exception occurs in the in-vehicle embedded system, a spare second processing unit can be used to control the in-vehicle embedded system instead of the abnormal first processing unit. Another example, some of the above embodiments mention that after an exception occurs in the in-vehicle embedded system, the exception information of the in-vehicle embedded system can be first saved in the internal memory, and then the exception information can be stored from the internal memory to the external memory. The above two embodiments can be implemented independently or in combination. For example, when an exception occurs in the in-vehicle embedded system, a spare second processing unit can be used to control the in-vehicle embedded system instead of the abnormal first processing unit, but it is not necessary to first save the exception information in the internal memory and then store it in the external memory. Another example, when an exception occurs in the in-vehicle embedded system, the exception information can be first saved in the internal memory and then stored in the external memory, but it is not necessary to use a spare second processing unit to control the in-vehicle embedded system instead of the abnormal first processing unit. Another example, when an exception occurs in the in-vehicle embedded system, a spare second processing unit is used to control the in-vehicle embedded system instead of the abnormal first processing unit, and the exception information is first saved in the internal memory and then stored in the external memory. In this way, the system can quickly resume normal operation and the exception information can be well saved, which helps to locate the cause of the exception.
[0084] It is mentioned in step S502 that the first processing unit can determine whether the exception information has been successfully saved in the external memory. As Figure 6 shown, the first processing unit can determine whether the exception information has been successfully saved in the external memory by performing the following steps S601 and S602.
[0085] In step S601, the first processing unit performs an integrity check on the exception information stored in the external memory.
[0086] Optionally, in some embodiments, the integrity check of the exception information stored in the external memory can be performed through an exception information flag. Optionally, in some other embodiments, the integrity check of the exception information stored in the external memory can be performed through a cyclic redundancy check (CRC) code. The above-mentioned exception information flag and CRC check code can be used alone for integrity check, or can be used in combination for integrity check.
[0087] In step S602, if the integrity check fails, the first processing unit determines that the exception information has not been successfully saved to the external memory.
[0088] If the integrity check for the exception information in step S601 fails, the first processing unit can determine in step S602 that the exception information has not been successfully saved to the external memory.
[0089] As a more specific example, the internal memory is a non-volatile RAM, and the external memory is a FLASH. The integrity check of the exception information in the FLASH is performed by combining the above-mentioned exception information flag and CRC check code. An exception information flag can be preset. Here, the exception information flag can be, for example, a string of randomly generated numbers. During the process of storing the exception information to the non-volatile RAM and the FLASH, the exception information flag will also be stored in the non-volatile RAM and the FLASH following the exception information. After the first processing unit restarts, it can check whether the exception information flags in the RAM and the FLASH are complete. If the exception information flag in the RAM is incomplete, it indicates that the exception information has not been completely saved to the RAM. If the exception information flag in the RAM is complete while the exception information flag in the FLASH is incomplete, it indicates that the exception information has been completely saved to the RAM but not completely saved to the FLASH. If the exception information flags in both the RAM and the FLASH are complete, it indicates that the exception information has been completely saved to the FLASH. In addition, before transferring the exception information in the RAM to the FLASH, a CRC code (which can be called CRC code 1) can be generated based on the exception information by performing a series of mathematical operations, and then the CRC code 1 is appended to the exception information and sent to the FLASH together. After the FLASH receives the information sent by the RAM, it generates a CRC code 2 based on the exception information by performing the same mathematical operations. If CRC code 2 does not match CRC code 1, it indicates that the exception information has not been completely saved to the FLASH.
[0090] In some implementations, the first processing unit determines whether the exception information is successfully saved to the external memory, which may further include: the first processing unit performs an accuracy verification on the exception information stored in the external memory; if the accuracy verification fails, the first processing unit determines that the exception information is not successfully saved to the external memory.
[0091] When testing an in-vehicle embedded system during the R & D stage, it is generally tested by using actual hardware and simulating the actual operating environment in a laboratory environment. In the laboratory environment, after an exception occurs in the in-vehicle embedded system, R & D personnel may be more concerned about how to obtain first-hand exception information and operating status information, rather than being overly concerned about how to quickly restore the system to its normal state.
[0092] To solve the above problems, the method for handling exceptions provided by the embodiments of the present application may further include the following step S701.
[0093] As Figure 7 shown, in step S701, if the version of the program running on the first processing unit is a debug version, an exception handler is called to handle the exception of the in-vehicle embedded system.
[0094] If the version of the program running on the first processing unit is a debug version, that is, the version of the program running on the first processing unit is not a release version, an exception handler can be called before starting the second processing unit. Under the exception handler, developers can quickly obtain the information of all current memories, thereby greatly improving the efficiency of locating the cause of the exception. Here, the exception handler can be hooked on the above debug version program. The exception handler can be, for example, a shell program.
[0095] Optionally, in some embodiments, when calling the exception handler, all other processes and interrupts can also be stopped to protect the exception scene and prevent data generated by other processes and interrupts from interfering with developers' location of the cause of the exception.
[0096] The following combines Figure 8 , and provides a more detailed description of the method for handling exceptions provided by the embodiments of the present application. In the following example, the first processing unit and the second processing unit are the running core and the standby core in the in-vehicle embedded system processor, respectively.
[0097] As Figure 8 shown, in step S801, after an exception occurs, the key information of vehicle control is saved to the shared RAM area.
[0098] In step S802, the exception information is stored in the non-volatile RAM.
[0099] In step S803, the exception information stored in the RAM is transferred to the FLASH.
[0100] In step S804, it is determined whether the program running on the current core is a release version.
[0101] In step S805, if the program running on the current core is not a release version, the shell program is entered for exception handling.
[0102] In step S806, if the program running on the current core is a release version, the current core is frozen and the standby core is enabled.
[0103] In step S807, all the running information (stored in the FLASH, RAM, registers, etc.) on the exception core is read into the file system and uploaded to the cloud.
[0104] In step S808, the hardware ports are initialized according to the key information of vehicle control stored in the shared RAM.
[0105] In step S809, it is determined whether the exception flag in the FLASH is complete and whether the CRC code matches.
[0106] In step S8010, if the exception flag is incomplete or the CRC code does not match, the exception information stored in the non-volatile RAM is transferred to the FLASH again.
[0107] In step S8011, if the exception flag is complete and the CRC code matches, the exception information saved in the FLASH is directly provided.
[0108] The above is combined with Figures 2 to 8 ... to describe in detail the embodiments of the method for handling exceptions provided by the present application. The device embodiments of the present application are described in detail below. It should be understood that the description of the device embodiments corresponds to the description of the method embodiments. Therefore, the parts not described in detail can refer to the description of the previous method embodiments.
[0109] The embodiments of the present application also provide a device 900 for handling exceptions. The device 900 is used to execute the method for handling exceptions described above. The device 900 is located in the vehicle-mounted embedded system, and the vehicle-mounted embedded system includes a first processing unit and a second processing unit, and the second processing unit is a standby processing unit of the first processing unit.
[0110] Figure 9 Fig. shows a schematic block diagram of the device 900 for handling exceptions provided by the embodiments of the present application. As Figure 9 shown, the device 900 includes a first control module 910, a first storage module 920, a second storage module 930, and a second control module 940.
[0111] The first control module 910 is configured to control the in-vehicle embedded system by using the first processing unit during the running of the vehicle.
[0112] The first storage module 920 is configured to, if an exception occurs in the in-vehicle embedded system, store the exception information of the in-vehicle embedded system to an external memory through an internal memory by using the first processing unit, where both the internal memory and the external memory are non-volatile memories;
[0113] The second storage module 930 is configured to store vehicle control information to a first storage area by using the first processing unit, where the first storage area is a shared storage area of the first processing unit and the second processing unit;
[0114] The second control module 940 is configured to, after the second processing unit is started up, control the in-vehicle embedded system by using the second processing unit instead of the first processing unit.
[0115] An embodiment of the present application further provides an in-vehicle embedded system 100. Figure 10 A schematic block diagram of the in-vehicle embedded system 100 provided by an embodiment of the present application is shown. As Figure 10 shown, the in-vehicle embedded system 100 includes a memory 1010 and at least two processing units. The at least two processing units include a first processing unit 1020 and a second processing unit 1030, and the second processing unit 1030 is a backup processing unit of the first processing unit 1020.
[0116] The memory 1010 is configured to store program instructions.
[0117] The at least two processing units are configured to call the program instructions to execute the method for processing exceptions described above.
[0118] An embodiment of the present application further provides a vehicle, including the in-vehicle embedded system 100 described above.
[0119] An embodiment of the present application further provides a computer-readable storage medium. Program code is stored on the computer-readable storage medium, and the program code can be used to execute the method for processing exceptions in any of the above embodiments.
[0120] An embodiment of the present application further provides a computer program product. The computer program product includes program code for executing the method for processing exceptions in any of the above embodiments.
[0121] It should be understood that in the embodiments of the present application, determining B according to A does not mean determining B only according to A, and B can also be determined according to A and / or other information.
[0122] It should be understood that in the embodiments of the present application, "B corresponding to A" means that B is associated with A, and B can be determined according to A. However, it should also be understood that determining B according to A does not mean determining B only according to A, and B can also be determined according to A and / or other information.
[0123] It should be understood that the term "and / or" in this article is merely a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this article generally represents an "or" relationship between the associated objects before and after.
[0124] It should be understood that in various embodiments of the present application, the magnitudes of the sequence numbers of the above processes do not mean the order of execution. The order of execution of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.
[0125] In several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of devices or units can be in electrical, mechanical, or other forms.
[0126] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0127] In addition, the functional units in various embodiments of the present application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit.
[0128] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be read by a computer or a data storage device such as a server or a data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a digital video disc (DVD)), or a semiconductor medium (such as a solid state disk (SSD)), etc.
[0129] The above are only the specific implementation manners of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present application, and all of them should be covered by the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.
Claims
1. A method for handling exceptions, characterized in that, The method is applied to an in-vehicle embedded system, which includes a first processing unit and a second processing unit, and the second processing unit is a backup processing unit of the first processing unit. The method includes: During the running of the vehicle, controlling the in-vehicle embedded system by using the first processing unit; If an exception occurs in the in-vehicle embedded system, using the first processing unit to store the exception information of the in-vehicle embedded system from an internal memory to an external memory through the internal memory. Both the internal memory and the external memory are non-volatile memories; Using the first processing unit to store vehicle control information to a first storage area, and the first storage area is a shared storage area of the first processing unit and the second processing unit; After the second processing unit is started up successfully, using the second processing unit to replace the first processing unit to control the in-vehicle embedded system.
2. The method according to claim 1, wherein The vehicle control information includes port-related information of at least one hardware port. The method further includes: After the second processing unit is started up successfully, the second processing unit obtains the port-related information from the first storage area and sets the port states of the at least one hardware port according to the port-related information.
3. The method according to claim 1 or 2, characterized in that, The method further includes: After the first processing unit is restarted, the first processing unit determines whether the exception information is successfully saved to the external memory; If the exception information is not successfully saved to the external memory, re-storing the exception information in the internal memory to the external memory.
4. The method according to claim 3, wherein The first processing unit determines whether the exception information is successfully saved to the external memory, including: The first processing unit performs integrity verification on the exception information stored in the external memory; If the integrity verification fails, the first processing unit determines that the exception information is not successfully saved to the external memory.
5. The method according to claim 3, wherein The internal memory is a non-volatile random access memory RAM; and / or, the external memory is a flash memory FLASH.
6. The method according to claim 1 or 2, characterized in that, The method further includes: After an exception occurs in the in-vehicle embedded system, the second processing unit obtains the running information of the first processing unit when the exception occurs; After obtaining the running information, the second processing unit transmits the running information to an external device through an in-vehicle communication system.
7. The method according to claim 6, wherein The running information includes at least one of the following: information stored in the internal memory of the in-vehicle embedded system, information stored in the external memory of the in-vehicle embedded system, and information stored in the registers of the in-vehicle embedded system.
8. The method according to claim 1 or 2, characterized in that, Before starting the second processing unit, the method further includes: If the version of the program running on the first processing unit is a debug version, calling an exception handling program to handle the exception of the in-vehicle embedded system.
9. A device for handling exceptions, characterized in that, The device is located in an in-vehicle embedded system, which includes a first processing unit and a second processing unit, and the second processing unit is a backup processing unit of the first processing unit. The device includes: A first control module, configured to control the vehicle-mounted embedded system by using the first processing unit during the operation of the vehicle; A first storage module, configured to, if an exception occurs in the vehicle-mounted embedded system, use the first processing unit to store the exception information of the vehicle-mounted embedded system in an external memory through an internal memory, where both the internal memory and the external memory are non-volatile memories; A second storage module, configured to use the first processing unit to store vehicle control information in a first storage area, where the first storage area is a shared storage area of the first processing unit and the second processing unit; A second control module, configured to, after the second processing unit is started up, use the second processing unit to replace the first processing unit to control the vehicle-mounted embedded system.
10. An in-vehicle embedded system, characterized in that, The vehicle-mounted embedded system includes: A memory, configured to store program instructions; At least two processing units, where the at least two processing units include a first processing unit and a second processing unit, the second processing unit is a backup processing unit of the first processing unit, and the at least two processing units are configured to call the program instructions to execute the method according to any one of claims 1 to 10.
11. A vehicle, characterized in that, Including the vehicle-mounted embedded system according to claim 12.
12. A computer-readable storage medium, characterized in that, Stored thereon is code for executing the method according to any one of claims 1 to 8.