A method, device and vehicle for handling abnormal health detection in vehicles

Abstract

This application discloses a method, device, and vehicle for handling in-vehicle health detection anomalies, relating to the field of voice control. The method includes: responding to a user activating the health detection function of an in-vehicle health application, activating an in-cabin intelligent sensing device, and prompting the user to perform a health detection via a pop-up window on the in-vehicle display interface; if an anomaly occurs during the health detection process, determining the current anomaly scenario, and determining the anomaly prompt content and handling strategy corresponding to the current anomaly scenario; displaying the anomaly prompt content on the in-vehicle display interface via a pop-up window, and handling the detection anomaly based on the handling strategy. This achieves layered and refined guidance throughout the entire health detection process, thereby reducing the user's error rate, improving anomaly handling efficiency, and enhancing the user experience.

Description

Technical Field

[0001] This application relates to the field of advanced motor control, and in particular to a method for handling abnormalities in vehicle health detection, a device for handling abnormalities in vehicle health detection, and a vehicle. Background Technology

[0002] Current in-vehicle health monitoring systems achieve non-intrusive monitoring of driver and all occupants' fatigue, distraction, vital signs, posture, behavior, and health risks through lightweight edge-side algorithms and multi-source data fusion algorithms. The system has pre-processing steps such as power-on self-test, permission verification, sensor obstruction detection, and environmental adaptability assessment. It can operate stably in complex in-vehicle scenarios such as vibration, changes in lighting, and dynamic posture, and provides graded early warnings and vehicle safety linkages based on anomaly levels. It is a key underlying technology for active safety and occupant health management in intelligent cockpits.

[0003] In related technologies, users are only guided through general prompts (such as "Please complete the test"), leading to a high error rate among non-professional users. There are no standardized solutions for handling abnormal scenarios; for example, when a device (such as a camera) malfunctions or the user makes a mistake, only a "Test failed" message is output, resulting in a poor user experience. Furthermore, the workflow for multi-device collaborative testing lacks coordination. In testing scenarios involving multiple devices (such as OMS / DMS cameras and vital signs sensors), existing technologies do not clearly define the startup and interaction logic between devices, easily leading to asynchronous device responses. Summary of the Invention

[0004] The purpose of this invention is to provide a method, device, electronic device, storage medium, and vehicle for handling abnormal vehicle health detection, at least addressing one technical problem in reducing the error rate of non-professional users, reducing device response asynchrony, and improving the user experience.

[0005] This invention provides the following solution:

[0006] According to one aspect of the present invention, a method for handling abnormalities in vehicle-mounted health detection is provided, comprising:

[0007] In response to the user opening the health check function of the in-vehicle health application, the in-cabin intelligent sensing device is activated, and a pop-up window on the in-vehicle display interface prompts the user to perform a health check.

[0008] If an abnormality is detected during the health check, determine the current abnormal scenario and the corresponding abnormal prompt content and handling strategy.

[0009] The abnormality message is displayed on the vehicle display interface via a pop-up window, and the detected abnormality is processed based on the processing strategy.

[0010] Furthermore, the activation of the in-cabin intelligent sensing device, which prompts the user to perform a health check via a pop-up window on the vehicle display interface, includes:

[0011] Once it is confirmed that the camera access of the in-cabin intelligent sensing device has been successfully obtained, the time system and the camera are checked.

[0012] Once it is determined that the time system meets the requirements and the camera meets the requirements, the occupant detection system is activated based on the current driving status of the vehicle.

[0013] If the occupant detection system detects no abnormalities, the vital signs sensor is activated, and a pop-up window on the vehicle display interface displays a "Start Detection" icon, prompting the user to perform a health check.

[0014] Furthermore, determining that the time system meets the requirements includes:

[0015] Obtain the current vehicle infotainment system time, and determine the first detection record time for the current health check based on the vehicle infotainment system time;

[0016] Obtain the time of the second health check record last performed;

[0017] If the time of the first detection record is later than the time of the second detection record, or if the health detection corresponding to the time of the first detection record is the first health detection performed, then the time system is determined to meet the requirements.

[0018] Furthermore, the method also includes:

[0019] If the time of the first detection record is equal to or earlier than the time of the second detection record, it is determined that the time system does not meet the requirements. A pop-up window on the vehicle display interface will display a prompt message indicating that the time system is abnormal and that no record has been made for this health check.

[0020] Furthermore, determining that the camera meets the requirements also includes:

[0021] In response to the camera being obstructed or the camera failing to collect user information, a camera malfunction is determined;

[0022] Obtain a preset abnormal scenario library, which includes at least one abnormal scenario, as well as the abnormal prompt content and processing strategy corresponding to the abnormal scenario;

[0023] In the abnormal scene database, determine the first abnormal prompt content and the first processing strategy corresponding to the camera abnormality;

[0024] The first abnormality prompt is displayed through a pop-up window on the vehicle display interface, and the abnormality handling scenario of the camera is processed based on the first processing strategy.

[0025] Furthermore, the method also includes:

[0026] In response to the camera or vital sign sensor exceeding the startup time threshold, the vehicle system automatically restarts the camera or vital sign sensor and displays a pop-up message on the vehicle display interface indicating the automatic restart.

[0027] Furthermore, if an abnormality occurs during the health check, the current abnormal scenario is determined, and the corresponding abnormal prompt content and handling strategy are determined, including:

[0028] Determine the second abnormal prompt content and the second processing strategy corresponding to the current abnormal scenario from the abnormal scenario library.

[0029] Furthermore, the pop-up window based on the in-vehicle display interface displays a "Start Detection" icon, prompting the user to perform a health check, including:

[0030] In response to the user triggering the start detection icon, the detection program is loaded, and a loading animation is displayed on the in-vehicle display interface;

[0031] Once the detection program is confirmed to be fully loaded, a detection command is displayed in a pop-up window on the vehicle display interface, and the detection command is played via voice prompts the user to perform a health check until the health check is completed.

[0032] According to a second aspect of the present invention, an on-board health detection anomaly handling device is provided, comprising:

[0033] The process guidance module is used to respond to the user opening the health detection function of the in-vehicle health application, turn on the intelligent sensing device in the cabin, and prompt the user to perform a health detection through a pop-up window on the in-vehicle display interface;

[0034] The multi-device collaboration module is used to determine the current abnormal scenario and the corresponding abnormal prompt content and handling strategy if an abnormality occurs during the health detection process.

[0035] An anomaly handling module is used to display the anomaly prompt content on the vehicle display interface via a pop-up window, and to process the detected anomaly based on the processing strategy.

[0036] According to three aspects of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0037] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the vehicle health detection anomaly handling method.

[0038] According to four aspects of the present invention, a computer-readable storage medium is provided, comprising: storing a computer program executable by an electronic device, wherein when the computer program is run on the electronic device, the electronic device performs the steps of an on-board health detection anomaly handling method.

[0039] According to five aspects of the present invention, a vehicle is provided, comprising:

[0040] Electronic equipment for implementing the steps of an on-board health detection anomaly handling method;

[0041] The processor runs a program that, when running, executes the steps of the vehicle health detection anomaly handling method based on data output from the electronic device.

[0042] Storage medium for storing programs that, when running, execute steps of an on-board health detection anomaly handling method based on data output from electronic devices.

[0043] The above solution achieves the following beneficial technical effects:

[0044] This application prompts users to perform health checks via pop-up windows on the in-vehicle display interface, achieving layered and refined guidance throughout the entire health check process, thereby reducing the error rate of user operations.

[0045] This application addresses abnormal scenarios by determining the corresponding error message content and handling strategy, and displays the error message content. This enables targeted handling of abnormal scenarios, thereby improving error handling efficiency. Combined with pop-up windows, it provides precise guidance to users based on the fault type and corresponding solution steps, enhancing the user experience. Attached Figure Description

[0046] Figure 1 This is a flowchart of an abnormal handling method for vehicle health detection provided by one or more embodiments of the present invention.

[0047] Figure 2 This is a schematic diagram of a device self-test provided in a specific embodiment of the present invention.

[0048] Figure 3 This is a schematic diagram of detection record information provided in a specific embodiment of the present invention.

[0049] Figure 4 This is a structural diagram of an on-board health detection anomaly handling device provided in one or more embodiments of the present invention.

[0050] Figure 5 This is a block diagram of an electronic device for handling abnormal vehicle health detection provided by one or more embodiments of the present invention. Detailed Implementation

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

[0052] Figure 1 This is a flowchart of an abnormal handling method for vehicle health detection provided by one or more embodiments of the present invention.

[0053] like Figure 1 The methods for handling abnormal vehicle health detection are as follows:

[0054] Step S1: In response to the user opening the health detection function of the in-vehicle health application, the in-cabin intelligent sensing device is turned on, and a pop-up window on the in-vehicle display interface prompts the user to perform a health detection.

[0055] Users can access the driver health application through the in-vehicle health app or via voice commands; alternatively, users can configure the application to automatically open after the vehicle starts. This health application can monitor the driver's health status and, if the device is properly installed and permitted, can also monitor the health status of other passengers in the vehicle cabin.

[0056] Users can also connect to the in-vehicle health application on mobile devices, such as smartphones, to synchronize their test information.

[0057] Furthermore, upon detecting that the user has activated the health check function of the in-vehicle health application, the system activates and turns on the in-cabin intelligent sensing devices, such as cameras and vital sign sensors. After the in-cabin intelligent sensing devices complete their self-check, a pop-up window on the in-vehicle display interface prompts the user to perform a health check.

[0058] Step S2: If an abnormality occurs during the health check, determine the current abnormal scenario and the corresponding abnormal prompt content and handling strategy.

[0059] If an abnormal event occurs during the user's health check, the current abnormal scenario can be further determined. Abnormal scenarios include timeouts in infrared night vision mode (IR Night Vision), occupant monitoring system (OMS) or driver monitoring system (DMS) algorithm output, overexposure or underexposure of ambient light, abnormal values ​​transmitted by the OMS / DMS algorithm, no detected target user, and abnormal gear position, etc.

[0060] Based on the identified abnormal scenario, determine the corresponding abnormal message content and handling strategy.

[0061] Step S3: Display the abnormality message on the vehicle display interface via a pop-up window, and process the detected abnormality based on the processing strategy.

[0062] The system displays the confirmed abnormality information through a pop-up window on the in-vehicle display interface to inform the user of the abnormal scenario. Based on the determined handling strategy and the user's cooperative operation based on the abnormality information, the system handles the current abnormal scenario and completes the health check of the target user.

[0063] Figure 2 This is a schematic diagram of a device self-test provided in a specific embodiment of the present invention. For example... Figure 2 As shown, the self-test of the in-cabin intelligent sensing device includes testing the time system and the camera used to acquire user information. If the camera permission acquisition is successful, the time system and the camera are tested. If camera permission acquisition fails, an error message will be displayed on the vehicle display interface indicating that in-vehicle camera access permission has not been obtained and requesting authorization in the vehicle settings. A floating toast notification will also be displayed, for example, "Permission not enabled, please authorize first."

[0064] The time system detection uses the current detection record time and the last health check record time to determine if there are any anomalies. Camera detection can identify any abnormalities such as camera obstruction or disconnection.

[0065] In one implementation, for the detection of the time system, before each detection, the current vehicle-mounted system time needs to be used as the health detection record time and compared with the most recent health detection record time in the detection history. That is, the current vehicle-mounted system time is obtained, and the first detection record time for the current health detection is determined based on the vehicle-mounted system time; the second detection record time for the last health detection is obtained.

[0066] If the time of the first detection record is later than the time of the second detection record, or if the health detection corresponding to the time of the first detection record is the first health detection performed, the time system is determined to meet the requirements.

[0067] For example, if the history is empty, indicating this is the first health check, the health check for the target user will begin normally. If the current time (i.e., the time of the first check record) is later than the most recent time in the history (i.e., the time of the second check record), the check will begin normally. If the current time (the time of the first check record) is equal to or earlier than the most recent time in the history (the time of the second check record), a message will be displayed stating that the health check cannot be performed and a pop-up window will be displayed to the user: "Please note that the time system is malfunctioning, and the current check cannot be included in the history." The user can still perform the check and see the results, but it will not be recorded in the history.

[0068] Figure 3 This is a schematic diagram of detection record information provided in a specific embodiment of the present invention. For example... Figure 3 As shown, the detection record information includes the target user's heart rate, heart rate variability, blood oxygen saturation, and respiratory rate. This detection record information can be displayed through the in-vehicle display interface. The detection record information also includes the detection ID, detection time, detection items, result data, operating parameters (posture / duration), and abnormal records. The in-vehicle display interface can also display the detection time, items, results, and operating status (normal / abnormal). In addition, the interface can also display the message "The detection results of this product are for reference only and should not be used for medical diagnostic purposes."

[0069] In another implementation, for camera detection, if the camera is obstructed or fails to collect user information, a camera malfunction is determined. A preset abnormal scenario library is retrieved, which includes at least one abnormal scenario, along with corresponding abnormal prompts and processing strategies. From the abnormal scenario library, a first abnormal prompt and a first processing strategy corresponding to the camera malfunction are determined. The first abnormal prompt is displayed via a pop-up window on the in-vehicle display interface, and the camera malfunction scenario is processed based on the first processing strategy.

[0070] Abnormal scenarios for the camera include hot-swapping of OMS / DMS, OMS / DMS obstruction, and loss of face data.

[0071] For example, if the camera malfunction is OMS / DMS hot-plugging, the first malfunction message will be "Camera connection malfunction, please check the device." The first handling strategy will be to report the hot-plugging failure. Upon receiving the report, the health monitoring application will directly call the interface to stop the algorithm.

[0072] If the camera abnormality scenario is OMS / DMS occlusion, the first abnormality prompt is to ensure that the camera is not obstructed in order to ensure data validity. The first handling strategy is to report an occlusion fault when the camera is continuously obstructed for 5 seconds, and the health detection application will shut down the algorithm.

[0073] If the camera malfunctions in a scenario where a face is lost, the first error message will be "Data error. Please ensure you are sitting still and re-detect." The first handling strategy will be to stop the health check application algorithm.

[0074] After confirming that the time system and camera meet the requirements, the vehicle's current driving status is determined. If the vehicle is currently parked and the engine is off (i.e., the gear is in Park), the occupant detection system is activated. If the occupant detection system is found to be normal, the vital signs sensor is activated. The OMS / DMS camera identifies the user's posture and sends a "Posture Correct?" signal to the vital signs sensor. The sensor only begins collecting data after the "Posture Correct?" signal is triggered. Simultaneously, a pop-up window on the in-vehicle display shows a "Start Detection" icon, prompting the user to perform a health check.

[0075] This embodiment achieves the detection of OMS / DMS cameras and vital signs sensors through a multi-device collaborative detection process. It adds startup and interaction logic between devices, thereby clarifying the process connection logic of multi-device collaborative detection, avoiding asynchronous device responses, and enhancing the stability of multi-device collaboration.

[0076] If the camera or vital sign sensor's startup time exceeds a threshold, the vehicle system will automatically restart the camera or vital sign sensor and display a pop-up message on the vehicle's display interface indicating the automatic restart. For example, the system may automatically restart the corresponding device and display a message such as "Device response delayed, retrying."

[0077] After the device completes its self-test, the user can manually click the "Start Detection" button to trigger the test, or trigger an automatic test if the user's indicators exceed the normal threshold.

[0078] If an anomaly occurs during the detection process, the second anomaly prompt content and the second handling strategy corresponding to the current anomaly scenario will be determined from the anomaly scenario library.

[0079] For example, if an abnormal scenario occurs in the infrared night vision mode, the corresponding second abnormal prompt is that the ambient light is too dark and cannot be detected. The second handling strategy is for the user to start the detection and immediately report the abnormal value to the OMS / DMS system.

[0080] If an abnormal scenario occurs where the OMS / DMS algorithm output times out (e.g., no result is generated after more than 40 seconds), the corresponding second abnormal message will be "Detection timed out, please re-detect". The second handling strategy is to stop the OMS / DMS system detection algorithm for health applications.

[0081] If an abnormal scenario occurs, such as overexposed or underexposed ambient light, or abnormal values ​​transmitted by the OMS / DMS algorithm, the corresponding second abnormal message will be "Abnormal ambient light, please avoid overexposure or underexposed light." The second handling strategy is to stop the OMS / DMS system detection algorithm for healthy applications.

[0082] If an abnormal scenario occurs where the target user is not detected, the corresponding second abnormal message will be "No valid target detected. Please ensure that there is a target user in the corresponding position. Please avoid overexposure or underexposure." The second handling strategy is to stop the OMS / DMS system detection algorithm for healthy applications.

[0083] If an abnormal scenario occurs due to gear misalignment, the corresponding second abnormal message will be the system's unified abnormal message, and the second handling strategy will be to prohibit the use of health checks while the vehicle is in motion, that is, to prohibit the check when the gear is not in P gear.

[0084] Furthermore, in response to the user triggering the start detection icon, the system determines whether the intelligent sensing switch in the passenger compartment or driver's compartment is turned on, and monitors the status of the intelligent sensing switch in real time. The intelligent sensing switch can be configured by the user using options provided by the system, including on for 365 days, off, or on only for this driving session.

[0085] When the smart sensing switch is off, a pop-up window should appear when the user enters the application, prompting them that "Occupant data collection is off, health data collection will stop. Please turn on the smart sensing switch to use related functions." The specific design of the data security pop-up HMI should be followed. When the smart sensing switch is off, only historical records can be viewed; real-time detection is not supported.

[0086] In one implementation, during the health detection process, if the OMS (Occupant Detection System, for all passengers) switch status changes, a pop-up window should be displayed prompting "Occupant data collection switch is off, health data collection will stop, please turn on the smart sensing switch to use related functions"; if the OMS / DMS switch is off during detection, a pop-up window should be displayed, and the detection should be canceled.

[0087] The smart device is switched on, the detection program loads, and a loading animation is displayed on the in-vehicle display. Once the detection program is confirmed to be loaded, a pop-up window on the in-vehicle display shows the detection instructions, which are also played back via voice prompts to guide the user through the health check until it is complete. The detected health information is then displayed on the in-vehicle display.

[0088] This embodiment implements a five-stage process for health monitoring: detection, device self-test, user operation, data collection, and result display. This provides layered and refined guidance throughout the entire process, standardized handling of abnormal scenarios, and clear logical connections between multiple devices in collaborative testing. This reduces operational error rates, improves anomaly handling efficiency, and enhances the stability of multi-device collaboration.

[0089] Figure 4 This is a structural diagram of an on-board health detection anomaly handling device provided in one or more embodiments of the present invention.

[0090] like Figure 4 The on-board health detection anomaly handling device shown includes: a process guidance module, a multi-device collaboration module, and an anomaly handling module.

[0091] The process guidance module is used to respond to the user opening the health detection function of the in-vehicle health application, turn on the intelligent sensing device in the cabin, and prompt the user to perform a health detection through a pop-up window on the in-vehicle display interface;

[0092] The multi-device collaboration module is used to determine the current abnormal scenario and the corresponding abnormal prompt content and handling strategy if an abnormality occurs during the health detection process.

[0093] The anomaly handling module is used to display anomaly prompts on the vehicle display interface via pop-up windows and to process detected anomalies based on processing strategies.

[0094] The process guidance module is used to confirm that the camera permissions of the in-cabin intelligent sensing device have been successfully obtained, and to check the time system and the camera; after confirming that the time system and the camera meet the requirements, based on the current driving status of the vehicle, the occupant detection system is started; in response to the absence of abnormalities in the occupant detection system, the vital signs sensor is activated, and a pop-up window on the vehicle display interface displays a start detection icon, prompting the user to perform a health check.

[0095] The multi-device collaboration module is used to obtain the current vehicle system time, determine the first detection record time of the current health check based on the vehicle system time, obtain the second detection record time of the last health check, and determine if the first detection record time is later than the second detection record time or if the health check corresponding to the first detection record time is the first health check performed, and if the time system meets the requirements.

[0096] The multi-device collaboration module is used to determine that the time system does not meet the requirements if the first detection record time is equal to or earlier than the second detection record time. The module will then display a pop-up window on the vehicle display interface to indicate that the time system is abnormal and that there is no record for this health check.

[0097] The multi-device collaboration module is used to determine a camera malfunction in response to camera obstruction or failure to collect user information; obtain a preset abnormal scenario library, which includes at least one abnormal scenario, as well as corresponding abnormal prompt content and processing strategy; determine a first abnormal prompt content and a first processing strategy corresponding to the camera malfunction in the abnormal scenario library; display the first abnormal prompt content through a pop-up window on the vehicle display interface; and process the camera malfunction scenario based on the first processing strategy.

[0098] The multi-device collaboration module is used to automatically restart the camera or vital signs sensor when the startup time exceeds the threshold, and to display the corresponding prompt message for automatic restart in a pop-up window on the vehicle display interface.

[0099] The multi-device collaboration module is used to determine the second abnormal prompt content and the second handling strategy corresponding to the current abnormal scenario from the abnormal scenario library.

[0100] The process guidance module is used to respond to the user triggering the start detection icon, load the detection program, and display a loading animation on the in-vehicle display interface; after confirming that the detection program has been loaded, it displays the detection instructions in a pop-up window on the in-vehicle display interface, and plays the detection instructions through voice to prompt the user to perform the health detection until the health detection is completed.

[0101] Figure 5 This is a block diagram of an electronic device for handling abnormal vehicle health detection provided by one or more embodiments of the present invention.

[0102] like Figure 5 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0103] The memory stores a computer program that, when executed by the processor, causes the processor to perform steps of an on-board health detection anomaly handling method.

[0104] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of an on-board health detection anomaly handling method.

[0105] This application also provides a vehicle, including:

[0106] Electronic equipment for implementing the steps of an on-board health detection anomaly handling method;

[0107] The processor runs a program that, when running, executes the steps of the vehicle health detection anomaly handling method based on data output from the electronic device.

[0108] Storage medium for storing programs that, when running, execute steps of an on-board health detection anomaly handling method based on data output from electronic devices.

[0109] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0110] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0111] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0112] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0113] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0114] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0115] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0116] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0117] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0118] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for handling abnormalities in vehicle-mounted health detection, characterized in that, The method for handling abnormal vehicle health detection includes: In response to the user opening the health check function of the in-vehicle health application, the in-cabin intelligent sensing device is activated, and a pop-up window on the in-vehicle display interface prompts the user to perform a health check. If an abnormality is detected during the health check, determine the current abnormal scenario and the corresponding abnormal prompt content and handling strategy. The abnormality message is displayed on the vehicle display interface via a pop-up window, and the detected abnormality is processed based on the processing strategy.

2. The method for handling abnormal vehicle health detection according to claim 1, characterized in that, The activation of the in-cabin intelligent sensing device, which prompts the user to perform a health check via a pop-up window on the vehicle display interface, includes: Once it is confirmed that the camera access of the in-cabin intelligent sensing device has been successfully obtained, the time system and the camera are checked. Once it is determined that the time system meets the requirements and the camera meets the requirements, the occupant detection system is activated based on the current driving status of the vehicle. If the occupant detection system detects no abnormalities, the vital signs sensor is activated, and a pop-up window on the vehicle display interface displays a "Start Detection" icon, prompting the user to perform a health check.

3. The method for handling abnormal vehicle health detection according to claim 2, characterized in that, Determining that the time system meets the requirements includes: Obtain the current vehicle infotainment system time, and determine the first detection record time for the current health check based on the vehicle infotainment system time; Obtain the time of the second health check record last performed; If the time of the first detection record is later than the time of the second detection record, or if the health detection corresponding to the time of the first detection record is the first health detection performed, then the time system is determined to meet the requirements.

4. The method for handling abnormal vehicle health detection according to claim 3, characterized in that, The method further includes: If the time of the first detection record is equal to or earlier than the time of the second detection record, it is determined that the time system does not meet the requirements. A pop-up window on the vehicle display interface will display a prompt message indicating that the time system is abnormal and that no record has been made for this health check.

5. The method for handling abnormal vehicle health detection according to claim 2, characterized in that, The step of determining that the camera meets the requirements also includes: In response to the camera being obstructed or the camera failing to collect user information, a camera malfunction is determined; Obtain a preset abnormal scenario library, which includes at least one abnormal scenario, as well as the abnormal prompt content and processing strategy corresponding to the abnormal scenario; In the abnormal scene database, determine the first abnormal prompt content and the first processing strategy corresponding to the camera abnormality; The first abnormality prompt is displayed through a pop-up window on the vehicle display interface, and the abnormality handling scenario of the camera is processed based on the first processing strategy.

6. The method for handling abnormal vehicle health detection according to claim 5, characterized in that, The method further includes: In response to the camera or vital sign sensor exceeding the startup time threshold, the vehicle system automatically restarts the camera or vital sign sensor and displays a pop-up message on the vehicle display interface indicating the automatic restart.

7. The method for handling abnormal vehicle health detection according to claim 5, characterized in that, If an abnormality occurs during the health check, the current abnormal scenario is determined, and the corresponding abnormal prompt content and handling strategy are determined, including: Determine the second abnormal prompt content and the second processing strategy corresponding to the current abnormal scenario from the abnormal scenario library.

8. The method for handling abnormal vehicle health detection according to claim 2, characterized in that, The pop-up window based on the vehicle display interface displays a "Start Detection" icon, prompting the user to perform a health check, including: In response to the user triggering the start detection icon, the detection program is loaded, and a loading animation is displayed on the in-vehicle display interface; Once the detection program is confirmed to be fully loaded, a detection command is displayed in a pop-up window on the vehicle display interface, and the detection command is played via voice prompts the user to perform a health check until the health check is completed.

9. A vehicle-mounted health detection anomaly handling device, characterized in that, The on-board health detection anomaly handling device includes: The process guidance module is used to respond to the user opening the health detection function of the in-vehicle health application, turn on the intelligent sensing device in the cabin, and prompt the user to perform a health detection through a pop-up window on the in-vehicle display interface; The multi-device collaboration module is used to determine the current abnormal scenario and the corresponding abnormal prompt content and handling strategy if an abnormality occurs during the health detection process. An anomaly handling module is used to display the anomaly prompt content on the vehicle display interface via a pop-up window, and to process the detected anomaly based on the processing strategy.

10. A vehicle, characterized in that, include: An electronic device for implementing the steps of the vehicle health detection anomaly handling method as described in any one of claims 1 to 8; A processor that runs a program that, when the program is running, performs the steps of the vehicle health detection anomaly handling method as described in any one of claims 1 to 8 from data output by the electronic device. A storage medium for storing a program that, when running, performs the steps of the vehicle health detection anomaly handling method as described in any one of claims 1 to 8 on data output from an electronic device.

Images