Car window control method, system and equipment and storage medium

Abstract

The invention discloses a vehicle window control method, system and device and a storage medium, and relates to the technical field of vehicle safety, and the method comprises the following steps: if it is determined that a collision event occurs based on multi-source sensing data of a vehicle, determining a collision scene based on the multi-source sensing data; determining a target vehicle window control strategy matched with the collision scene; wherein the target vehicle window control strategy comprises a target vehicle window and a lifting action corresponding to the target vehicle window; and controlling the target vehicle window to execute a corresponding lifting action.

Description

Technical Field

[0001] This application relates to the field of vehicle safety technology, and in particular to a method, system, device and storage medium for controlling vehicle windows. Background Technology

[0002] Vehicle safety technology has undergone years of development, achieving significant results in occupant protection during a collision, with passive safety systems such as seat belts and airbags becoming widely adopted. However, related safety strategies primarily focus on instantaneous protection during a collision, leaving a significant gap in emergency response afterward. As a crucial passageway within the vehicle, the status of car windows after an accident typically still relies on manual operation by occupants. In the event of a severe collision leading to vehicle deformation, occupant incapacitation, or loss of mains power, windows may become ineffective, hindering escape and rescue efficiency during critical rescue periods. Summary of the Invention

[0003] The embodiments of this application provide a method, system, device and storage medium for controlling vehicle windows, which can quickly and intelligently realize emergency control of vehicle windows after a collision, creating or maintaining a survival passage for occupants.

[0004] The summary section introduces a series of simplified concepts, which will be further explained in detail in the detailed description section. This summary section is not intended to limit the key and essential technical features of the claimed technical solution, nor is it intended to determine the scope of protection of the claimed technical solution.

[0005] This application specifically includes the following aspects: Firstly, this application proposes a method for controlling vehicle windows, including: If a collision event is determined to have occurred based on the vehicle's multi-source perception data, then the collision scenario is determined based on the multi-source perception data. Determine a target window control strategy that matches the collision scenario; wherein, the target window control strategy includes the target window and the corresponding lifting and lowering action of the target window; Control the target car window to perform the corresponding raising and lowering action.

[0006] In one feasible implementation, the multi-source sensing data includes impact data characterizing collision severity and type, attitude data characterizing vehicle attitude, and disaster risk data characterizing post-collision risk. Determining the collision scenario based on the multi-source sensing data includes: Based on the impact data, the attitude data, and the disaster risk data, preliminary scenario labels are obtained through a preset scenario rule base. Based on the preliminary scenario labels and weighted decision model, the collision scenario corresponding to the multi-source perception data is determined. The collision scenario includes at least one of the following: severe side collision, severe frontal collision with fire risk, severe rear-end collision, vehicle rollover, vehicle being hit while stationary, vehicle falling into water, and minor scratch.

[0007] In one feasible implementation, determining the target window control strategy matching the collision scenario includes: In the case of a severe side collision, the target windows are defined as all windows on the side of the vehicle that are impacted, and the lifting action corresponding to the target windows is a lowering action. In the case of a collision scenario that is a vehicle rollover, a vehicle falling into water, or a serious frontal collision with a risk of fire, the target window is determined to be all windows of the vehicle, and the lifting action corresponding to the target window is a lowering action. In the case of a severe rear-end collision, the target window is determined to be the rear window of the vehicle, and the lifting action corresponding to the target window is a lowering action. In the case where the collision scenario is a vehicle being struck while stationary, the target windows are defined as all unclosed windows of the vehicle, and the lifting action corresponding to the target windows is an upward action.

[0008] In one feasible implementation, the target window control strategy further includes execution priority, wherein controlling the target window to perform the corresponding lifting action includes: Based on the execution priority, determine the delay time for executing the lifting action; Based on the aforementioned delay time, the target window is controlled to perform the raising and lowering action.

[0009] In one feasible implementation, the method further includes: detecting the voltage of the vehicle's main power supply; When the voltage of the main power supply is lower than a preset voltage threshold, the emergency power supply of the vehicle is controlled to supply power to the drive module of the target window, so that the drive module drives the target window to perform the corresponding lifting and lowering action.

[0010] In one feasible implementation, the method further includes: starting a timer from when a collision event is determined to have occurred; If the collision scenario is not determined within the preset emergency decision time, a default window control strategy is obtained, and the windows are controlled according to the default window control strategy. If the collision scenario is determined within the emergency decision-making time, then the step of determining the target window control strategy that matches the collision scenario is executed.

[0011] In one feasible implementation, the method further includes: obtaining the open / closed state of the target window after it performs the lifting / lowering action; The output includes prompts about the collision scenario and / or the switch status.

[0012] Secondly, this application also proposes a vehicle window control system, the system comprising: A multi-source perception module is used to determine a collision scenario based on the multi-source perception data if a collision event is determined to have occurred based on the multi-source perception data of the vehicle. The decision engine module is used to determine a target window control strategy that matches the collision scenario; wherein, the target window control strategy includes the target window and the corresponding lifting action of the target window; The window control module is used to control the target window to perform corresponding lifting and lowering actions.

[0013] Thirdly, this application also proposes an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program stored in the memory to implement the steps of the window control method as described in any of the first aspects above.

[0014] Fourthly, this application also proposes a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any of the window control methods of the first aspect.

[0015] This application proposes a window control method that, by acquiring and fusing multi-source perception data from multiple heterogeneous sensors in real time, can intelligently identify the precise collision scenario category within a very short time window after a collision, and accordingly decide on a matching window control strategy, ultimately driving the target window to perform its raising and lowering action with differentiated emergency delays. This method achieves, for the first time, refined and contextualized perception and decision-making regarding collision type, severity, and secondary risks, breaking through the limitations of traditional single-signal triggering or fixed-strategy responses. Therefore, after various dangerous accidents such as side collisions, rollovers, and submersion in water, it can proactively, quickly, and intelligently create the best escape route or implement safety protection for occupants, significantly improving the survival rate of occupants and vehicle safety during the "golden rescue time" after a collision.

[0016] This application discloses a method, system, device, and storage medium for controlling vehicle windows. Other advantages, objectives, and features of this application will be partly apparent from the following description and partly understood by those skilled in the art through study and practice of this application. Attached Figure Description

[0017] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a window control method provided in an embodiment of this application; Figure 2 A vehicle power supply decision diagram provided in an embodiment of this application; Figure 3 A window control decision diagram provided in an embodiment of this application; Figure 4 This is a schematic diagram of the functional modules of a vehicle window control system provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a vehicle window control device provided in an embodiment of this application. Detailed Implementation

[0018] To better understand the technical solutions provided in the embodiments of this specification, the technical solutions of the embodiments of this specification will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments of this specification and the specific features in the embodiments are detailed descriptions of the technical solutions of the embodiments of this specification, rather than limitations on the technical solutions of this specification. In the absence of conflict, the embodiments of this specification and the technical features in the embodiments can be combined with each other.

[0019] In this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, without necessarily requiring or implying any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. The term "two or more" includes two or more cases.

[0020] Please see Figure 1 This is a flowchart illustrating a window control method provided in an embodiment of this application, which may specifically include: S110. If a collision event is determined based on the vehicle's multi-source perception data, then the collision scenario is determined based on the multi-source perception data.

[0021] For example, the vehicle's multi-source perception module continuously collects various types of data, covering multiple dimensions such as collision impact, vehicle posture, and disaster risk. The control system analyzes this data in real time to determine whether a collision event has occurred. As long as the preset collision judgment conditions are met (such as the peak acceleration exceeding 3g or the airbags deploying), the subsequent process will be triggered. Then, based on the collected multi-source perception data, the system will further identify the specific collision scenario, such as whether it is a side collision, a frontal collision, or a vehicle rollover.

[0022] Specifically, the multi-source perception data of vehicles is clearly divided into three categories: impact data representing the severity and type of collision, attitude data representing the vehicle's posture, and disaster risk data representing the subsequent risks of a collision. The specific attribution and corresponding sources of each type of data are as follows: Impact data characterizing collision severity and type focuses primarily on the intensity, direction, and structural impact of the collision event itself, mainly including: The peak impact acceleration, integral acceleration (velocity change ΔV), and impact duration collected by the vehicle's acceleration sensors in each direction directly reflect the severity of the collision and are the core basis for classifying collisions as mild, moderate, and severe. Simultaneously, the collision type is determined by the signal characteristics of sensors deployed at different locations (e.g., behind the front bumper (X-axis), inside the A-pillar / B-pillar (Y-axis), in front of the rear bumper (X-axis), and on the roof (Z-axis)). For example, a high peak value of Ax from the forward-facing sensor corresponds to a frontal collision, a high peak value of Ay from the B-pillar region corresponds to a side collision, and a high peak value of Ax from the rear-facing sensor corresponds to a rear-end collision. Furthermore, the severity level of the collision is estimated using ΔV (e.g., ΔV < 8 km / h for mild, 8-16 km / h for moderate, and > 16 km / h for severe). The deformation pressure or strain values ​​of key load-bearing structures such as the A-pillar, B-pillar, sill beam, and front longitudinal beam collected by the body structure pressure / strain sensors can directly reflect the amount of intrusion into the body structure during a collision, further corroborating the severity of the collision (e.g., excessive pressure on the B-pillar can confirm a severe side collision, and the door may be jammed). The airbag deployment status signal input by the airbag control unit (ACU) serves as an important basis for confirming the occurrence and severity of a collision. Whether the airbags have deployed and the type of airbags deployed (driver / passenger airbags, side airbags, curtain airbags) can all indirectly confirm the severity level and direction of the collision, providing supplementary support for determining the collision type and severity. For example, a collision in which the airbags have not deployed usually does not trigger higher-level window controls.

[0023] Attitude data characterizing vehicle posture focuses on capturing changes in the vehicle's spatial attitude during and after a collision. It primarily originates from three-axis accelerations (Ax, Ay, Az) and three-axis angular velocities (Gx, Gy, Gz) collected by the inertial measurement unit (IMU), as well as pitch, roll, yaw, and angular acceleration calculated from this raw data. This data accurately reflects whether the vehicle is in a normal posture or has experienced abnormal states such as rollover, overturning, or tipping over. For example, by checking if the absolute value of the roll or pitch angle is greater than 70° and lasts for more than 0.5 seconds, a severe attitude anomaly can be directly determined, providing core data support for identifying key collision scenarios such as "vehicle rollover."

[0024] Disaster risk data characterizing the risks following a collision is mainly used to predict potential secondary disasters after a collision and ensure the safety of occupants. Specifically, it includes real-time data of the high-voltage battery pack input by the battery management system (BMS), covering voltage, current, temperature, insulation resistance, etc. By monitoring indicators such as whether the temperature rises by more than 20°C within 1 second and whether the insulation resistance is below the threshold, it can be determined whether there is a risk of fire caused by high-voltage short circuit or battery pack rupture after the collision. The environmental sensors (optional and recommended) include an external humidity / water pressure sensor deployed at the bottom of the vehicle body. The water pressure data it collects is used to directly detect whether the vehicle is in water, thus avoiding the risk of drowning. The external surround view camera captures external environmental images after a collision when the system still has power. This data can help determine whether the vehicle is in a high-risk environment such as near water, providing supplementary information for assessing the risk of secondary disasters.

[0025] In addition, data collected from vehicle status signals, such as vehicle speed (VSS), door lock status, and current window position, while not directly categorized into the three main types mentioned above, can serve as supplementary information. This information, combined with impact data, attitude data, and disaster risk data, enhances scenario recognition, determining whether the vehicle is in motion or stationary (e.g., a collision at 0 speed, combined with the absence of fire / water ingress risk, can be classified as a "stationary collision" scenario), ensuring the comprehensiveness and accuracy of collision scenario recognition. All raw data undergoes preprocessing, including filtering (e.g., Kalman filtering for noise reduction), time synchronization (ensuring all data is at the same timestamp), and feature extraction (e.g., calculating peak values, ΔV, and attitude angle change rate), before being transmitted to the decision engine along with the categorized core data. This provides comprehensive data support for precise window control strategy decisions.

[0026] S120. Determine the target window control strategy that matches the collision scenario; wherein, the target window control strategy includes the target window and the corresponding lifting and lowering action of the target window.

[0027] For example, by accurately identifying the collision scenario, the corresponding target window and its raising / lowering action can be determined, providing a basis for subsequent differentiated control. Occupant safety needs differ under different collision scenarios. For instance, in a side collision, the doors are prone to jamming, requiring priority to open the window on the impacted side. Conversely, in a stationary collision, there is no escape pressure, but window raising is necessary for security. Collision scenario matching makes window control more targeted.

[0028] S130, Control the target vehicle window to perform the corresponding lifting and lowering action.

[0029] For example, through automatic system execution without occupant intervention, an escape route can be quickly created or anti-theft protection can be achieved within the "golden rescue time" after a collision, greatly improving the occupant's chances of survival and vehicle safety.

[0030] In some examples, multi-source perception data includes impact data characterizing collision severity and type, attitude data characterizing vehicle attitude, and hazard risk data characterizing post-collision risks. Collision scenarios are determined based on multi-source perception data, including: Based on impact data, attitude data, and disaster risk data, preliminary scenario labels are obtained through a pre-set scenario rule base. Based on preliminary scenario labels and weighted decision models, collision scenarios corresponding to multi-source perception data are determined. The collision scenarios include at least one of the following: severe side collision, severe frontal collision with fire risk, severe rear-end collision, vehicle rollover, vehicle being hit while stationary, vehicle falling into water, and minor scratches.

[0031] For example, impact data (such as peak acceleration and velocity change ΔV) is used to determine the severity and type of collision; attitude data (such as attitude angles and angular velocities) is used to identify abnormal attitudes such as rollover or overturning; and disaster risk data (such as battery temperature and water pressure) is used to determine whether there are secondary risks such as fire or drowning after the collision. These three types of data comprehensively cover key collision-related information, providing sufficient evidence for scenario identification. Next, the process of determining the collision scenario consists of two steps: the first step involves preliminary matching using a pre-set scenario rule base, comparing the multi-source sensing data with the judgment conditions of each scenario in the rule base to obtain preliminary scenario labels; the second step introduces a weighted decision model (such as decision trees, SVM, and other machine learning models) to assign different weights to each sensor signal, comprehensively evaluating the accuracy of the preliminary scenario labels, and finally determining a unique and accurate collision scenario. Simultaneously, the specific types of collision scenarios are clearly defined, covering all situations from minor scratches to severe collisions and secondary disasters, ensuring no omissions.

[0032] By combining preliminary matching from a scenario rule base with a weighted decision model, both recognition speed and accuracy are balanced. The pre-set scenario rule base can quickly complete preliminary matching, ensuring preliminary results are obtained within a short time after a collision, meeting the time requirements for emergency decision-making. The weighted decision model optimizes the results through machine learning algorithms, reducing misjudgments caused by errors from single sensors or special circumstances. For example, in a minor scratch scenario, there may be situations where the data from a single sensor is close to the threshold. By comprehensively evaluating the signals from all sensors through the weighted decision model, serious collision scenarios can be accurately ruled out, avoiding the false triggering of emergency window controls.

[0033] As shown in Table 1, the preset scenario rule base can include several specific collision scenarios. Taking vehicle falling into water (scenario SC06) as an example, when a vehicle is driving to the riverbank, it accidentally plunges into the water. The external water pressure sensor in the system's multi-source perception module is immediately triggered (disaster risk data). At the same time, the inertial measurement unit (IMU) detects the vehicle sinking rapidly and collects corresponding attitude data (such as Z-axis acceleration changes). The impact data shows that the collision force is not large (Ax / Ay is less than 3g). First, the system compares these multi-source perception data with the preset scenario rule base. The judgment condition for scenario SC06 is "external water pressure sensor triggered or IMU detects rapid sinking". The current data fully meets this condition, so the initial scenario label "vehicle falling into water" is obtained. Subsequently, the weighted decision model performs a weighted evaluation of the water pressure sensor signal, IMU data, etc. Since the water pressure sensor directly detects whether the vehicle has entered the water, it has the highest weight. The validity of its signal directly determines the scenario judgment result. Finally, the collision scenario is confirmed as "vehicle falling into water", providing an accurate basis for determining the subsequent window control strategy.

[0034]

[0035] Table 1 In some examples, a target window control strategy matching the collision scenario is determined, including: In the case of a severe side collision, the target windows are defined as all windows on the side of the vehicle that are hit, and the corresponding lifting action of the target windows is the lowering action. In the event of a collision scenario that is a vehicle rollover, a vehicle falling into water, or a severe frontal collision with a risk of fire, the target window is determined to be all windows of the vehicle, and the corresponding lifting action of the target window is the lowering action. In the case of a severe rear-end collision, the target window is determined to be the rear window of the vehicle, and the corresponding lifting action of the target window is the lowering action. In the case where the collision scenario involves a stationary vehicle being struck, the target windows are defined as all unclosed windows of the vehicle, and the corresponding lifting action for the target windows is an upward action.

[0036] As shown in Table 2 below, the target windows and lifting actions corresponding to different collision scenarios are clearly defined in the preset scenario rule base, thereby making the control strategy more targeted and operable. Based on the safety needs and actual conditions of occupants in different collision scenarios, differentiated window control schemes are formulated: For severe side collisions, the doors on the impacted side are prone to deformation and jamming, so all windows on the impacted side are lowered first to provide occupants with a dedicated escape route; for severe frontal collisions involving vehicle rollover, vehicle submersion in water, or with a risk of fire, occupants have limited escape time and may need escape routes from all directions, so all four windows are lowered to maximize escape opportunities; for severe rear-end collisions, rear occupants suffer greater impact, and the rear doors may be deformed and unable to open, so the rear side windows are lowered to prioritize the escape of rear occupants; for collisions where the vehicle is stationary, there is no risk of the vehicle moving and occupants do not have an emergency escape need, but there may be a risk of theft, so all open windows are raised to provide anti-theft protection; minor scratches do not require window control to avoid unnecessary operations.

[0037] Taking a severe left-side collision (Scenario SC01) as an example, when a vehicle violently collides with a vehicle on its left during driving, the multi-source perception module detects that the acceleration Ay of the B-pillar (left side) exceeds 10g, and the B-pillar pressure sensor exceeds its limit. The IMU detects a high rate of change in the roll angle (Roll angle), and the airbag control unit (ACU) reports that the side airbags have deployed. Therefore, the collision scenario is determined to be a "severe side collision," specifically a left-side collision. Following the strategy in Table 2, the target windows are all windows on the impact side (left side) of the vehicle (front left and rear left windows), and the corresponding lifting action is a lowering action. The decision engine generates corresponding instructions, and upon receiving these instructions, the window execution module immediately lowers the front left and rear left windows, quickly creating an escape route for occupants and preventing them from being trapped due to deformation and jamming of the left door.

[0038]

[0039] Table 2 In some examples, the target window control strategy also includes execution priority, controlling the target window to perform corresponding raising and lowering actions, including: The delay time for executing the lifting and lowering actions is determined based on the execution priority. Based on the delay time, control the target car window to perform the raising and lowering action.

[0040] Specifically, the execution priority is set based on the urgency of the collision scenario: the higher the risk and the more urgent the occupant's escape, the higher the execution priority and the shorter the corresponding delay time, ensuring the fastest response to the most urgent situations. For example, vehicle rollover and falling into water are extremely high-risk scenarios, where occupants face imminent danger to their lives; therefore, their execution priority is set to the highest, with a delay time ≤ 50ms. Severe side collisions and severe frontal collisions with fire risk are the next highest risks, with a high priority and a delay time ≤ 100ms. Severe rear-end collisions and stationary collisions have relatively low risks, with a medium priority and a delay time ≤ 200ms. Minor scratches have the lowest priority and require no action. After receiving a window control command, the system first determines the corresponding delay time based on the execution priority, and then drives the target window to perform the raising and lowering action according to that delay time. This ensures that window actions in emergency situations are completed quickly and efficiently, and that actions in non-emergency situations are also executed within a reasonable timeframe, avoiding resource waste.

[0041] Taking vehicle rollover (Scenario SC04) as an example, when a vehicle rolls over to avoid an obstacle, the multi-source sensing module detects an absolute value of the roll angle exceeding 70° for a duration ≥0.5s, and a peak Z-axis acceleration exceeding 3g. The side curtain airbags deploy, and the collision scenario is determined to be "vehicle rollover." The target windows are all four windows, and the lifting action is a lowering action. This scenario has the highest execution priority, with a corresponding delay of ≤50ms. After determining the collision scenario, the system immediately allocates resources according to the highest priority, completing instruction transmission and preparation within 50ms. 50ms later, the window execution module activates all window motors, lowering the windows at full speed to ensure that occupants can escape through the windows immediately during or after the rollover, minimizing the risk of injury or death due to entrapment.

[0042] In some examples, it also includes: Detect the voltage of the vehicle's main power supply; When the voltage of the main power supply is lower than the preset voltage threshold, the emergency power supply of the vehicle controls the power supply to the drive module of the target window, so that the drive module drives the target window to perform the corresponding lifting action.

[0043] Specifically, such as Figure 2As shown, the system monitors the voltage of the vehicle's main power supply (12V battery) in real time, with a preset voltage threshold (e.g., 9V). When the main power supply voltage is detected to be lower than this threshold, it indicates that the main power supply may be unable to supply power normally due to collision damage, circuit disconnection, or other reasons. At this time, the system automatically switches to the emergency power module (supercapacitor bank, capacity 100F-1000F, rated voltage 16V) to provide power. The emergency power supply provides stable power to the target window's drive module, ensuring that the drive module can normally drive the target window to perform the corresponding lifting and lowering actions. The emergency power module consists of a supercapacitor bank, a charging management circuit, and a discharge control and voltage conversion circuit. It is directly connected to the main relay or motor drive IC of the window motor via a dedicated hard wire, bypassing complex wiring harnesses that may be damaged by collisions. During normal vehicle operation, the charging management circuit charges the supercapacitor to its full rated voltage (16V) from the main power supply. When emergency power is needed, the discharge control and voltage conversion circuit outputs the voltage of the supercapacitor stably to the window drive module (e.g., 12V), and at the same time, it is directly connected to the window motor via a dedicated hard wire, bypassing complex wiring harnesses that may be damaged, ensuring stable and reliable power supply. Assuming that lowering all four car windows requires a total energy of 200J (50J per window), the supercapacitor energy E = 1 / 2 × C × Using a 500F, 16V capacitor, E = 1 / 2 × 500 × 256 = 64,000 J, far exceeds the requirements and can support multiple operations or long-term power supply.

[0044] In summary, the window motor drive unit receives instructions from the decision engine and controls the motor to rotate forward and backward to achieve the raising and lowering of the window. The window position sensor collects and provides feedback on the current open / closed state of the window in real time, with 0% indicating fully closed and 100% indicating fully open, providing accurate position reference for the decision engine and subsequent control.

[0045] In terms of execution logic, the system adopts differentiated instruction transmission and execution methods according to different operating conditions: Under normal operating conditions, the window control instructions generated by the decision engine are transmitted through the vehicle CAN bus to ensure the stability and universality of instruction transmission; when the decision engine determines that the collision scenario is a high-priority scenario (i.e., SC01 severe left / right collision, SC02 severe frontal collision + fire risk, SC04 vehicle rollover, SC06 vehicle falling into water), and the vehicle's main power supply is in a normal power supply state, the instructions are still transmitted through the CAN bus, but the bus's priority mechanism ensures a fast response to the instructions; if the collision causes the main power supply to fail, the decision engine will send a high-level pulse signal through a dedicated hard wire. This signal directly triggers the emergency power module to switch power supply, and simultaneously transmits it to the window drive unit as an "emergency window lowering" instruction. After receiving the signal, the drive unit immediately starts the motor to lower the window at full speed, bypassing the potentially damaged complex wiring harness through a direct hard wire connection to ensure reliable execution of window actions in extreme situations.

[0046] Furthermore, regarding the handling of the anti-pinch function, this application, based on the core safety principle of "life first," automatically disables the anti-pinch function in emergency mode. From the perspective of the function switching mechanism, the software and hardware layers form a collaborative guarantee: At the software level, when the decision engine identifies a high-priority emergency scenario, it sends a high-priority message to the motor control module through the vehicle network. This message has the highest arbitration priority and can interrupt any ongoing normal window raising and lowering operation, ensuring the priority execution of emergency control commands; At the hardware level, the window motor is controlled by a dedicated H-bridge drive IC. This drive IC integrates current detection and Hall sensor signal processing circuits for anti-pinch judgment. Upon receiving the "emergency mode" command from the software layer, the drive IC immediately disables the Hall sensor pulse anomaly detection and current surge judgment logic. Even if it detects increased resistance during window raising and lowering (such as accidental obstruction by a limb), it will not perform a reverse anti-pinch action, but will continuously output full power to drive the motor until the window is completely lowered.

[0047] Regarding the potential risk of occupant injury from disabling the anti-pinch function in emergency mode, this application has fully considered and clearly demonstrated that while there is a theoretical risk of limb injury from being pinched, in high-risk escape scenarios after a severe collision, this risk is far lower than the risk of suffocation, drowning, or death from fire caused by the inability to open the windows in time. According to accident statistics from authoritative agencies such as the NHTSA, the golden escape time after a vehicle catches fire or falls into water is usually less than 30 seconds. Any delay in window operation caused by the activation of the anti-pinch function could have fatal consequences. Therefore, this application strictly adheres to the safety ethical principle of "life over limb injury," actively disabling the anti-pinch function only in specific high-risk emergency situations, sacrificing a minimal potential risk of limb injury in exchange for maximizing the overall survival probability of occupants.

[0048] In some examples, it also includes: The timer starts from when a collision event is confirmed. If a collision scenario is not determined within the preset emergency decision time, the default window control strategy is obtained and the windows are controlled according to the default window control strategy. If a collision scenario is determined within the emergency decision-making timeframe, the steps to determine the target window control strategy that matches the collision scenario are executed.

[0049] Specifically, such as Figure 3As shown, the system begins timing from the moment it determines a collision event, with a preset emergency decision time (e.g., 500 milliseconds). This time is set based on the "golden rescue time" after the collision and the system's processing capacity, ensuring that window control is completed before a secondary collision occurs. If the system successfully determines the collision scenario within this time, it executes the corresponding target window control strategy according to the normal procedure. If, due to sensor malfunction, abnormal data transmission, or other reasons, the collision scenario is not determined within the emergency decision time, the system will automatically obtain the default window control strategy and perform window control according to the default strategy, avoiding delays in window control actions due to waiting for scenario determination. The design principle of the default window control strategy is "prioritizing escape," typically set to lower all four windows to ensure that an escape route is provided for occupants even if the scenario cannot be identified.

[0050] Assuming a vehicle collision occurs, the multi-source perception module collects some sensor data, but due to a malfunction of a key sensor (such as the inertial measurement unit), the data is incomplete. After confirming the collision event, the system starts timing. The emergency decision-making timeout is set to 500 milliseconds. During the timing, the system attempts to match the scenario rule base and analyze it through a weighted decision model, but due to incomplete data, it cannot determine the specific collision scenario. When the timeout reaches 500 milliseconds, the system triggers a timeout handling mechanism, automatically retrieving the default window control strategy: "lower all four windows." Subsequently, the window execution module drives all windows to lower according to the default strategy, providing an escape route for occupants and preventing delays in occupant escape due to uncertain scenario conditions.

[0051] In some examples, it also includes: Obtain the open / closed status of the target vehicle window after it has been raised or lowered. The output includes prompts indicating collision scenarios and / or on / off status.

[0052] For example, window control can not only perform "action execution" but also achieve "information synchronization," improving the occupant experience and rescue efficiency. Its core logic consists of two parts: first, obtaining the window's open / closed state after the action is performed (such as fully open, fully closed, partially open, etc.) to ensure the system is aware of the actual effect of the window control; second, outputting prompt information including the collision scenario and / or the window's open / closed state, targeting both occupants inside the vehicle and rescue personnel outside.

[0053] In-vehicle alerts are displayed via the instrument panel / head-up display (HUD) showing icons and text such as "Emergency! Windows are open" or "Anti-theft! Windows are closed"; a buzzer emits rapid "beep" sounds (e.g., 5 times) to indicate emergency window lowering, and a slow "beep-" sound to indicate window raising; and voice prompts such as "Serious collision detected, opening windows for escape," etc., conveying information to occupants through multiple channels so that they can be promptly informed of the vehicle's current status and window control.

[0054] External communication is achieved through the eCall function integrated into the in-vehicle T-Box, which sends extended data to the Power Assistance Center (PSAP), including the collision scenario (such as rollover, side collision, etc.) and the window status (open or closed). This allows rescue personnel to understand the vehicle's condition in advance before arriving at the scene and formulate a more accurate rescue plan (for example, knowing that the window is open, they can directly prepare window-breaking tools or adjust the rescue plan).

[0055] Furthermore, this application also proposes a window control system, specifically as follows: Figure 4 The diagram shown is a functional module schematic of a vehicle window control system proposed in this application. The system includes: The multi-source perception module 21 is used to determine the collision scenario based on the multi-source perception data if a collision event is determined to have occurred based on the multi-source perception data of the vehicle. The decision engine module 22 is used to determine the target window control strategy that matches the collision scenario; wherein, the target window control strategy includes the target window and the corresponding lifting action of the target window; The window execution module 23 is used to control the target window to perform the corresponding lifting and lowering action.

[0056] Furthermore, it also includes an emergency power supply module 24, which is used to detect the voltage of the vehicle's main power supply; when the voltage of the main power supply is lower than a preset voltage threshold, it controls the vehicle's emergency power supply to supply power to the drive module of the target window, so that the drive module drives the target window to perform the corresponding lifting action; the human-machine interaction and communication module 25 is used to obtain the opening and closing status of the target window after it performs the lifting and closing action; and outputs prompt information containing the collision scenario and / or opening and closing status.

[0057] It should be noted that the above embodiments are merely best examples and are not intended to limit the implementation of this application.

[0058] Furthermore, such as Figure 5 As shown, this application embodiment also provides an electronic device 300, including a processor 310, a memory 320, and a computer program 321 stored in the memory 320 and executable on the processor. When the processor 310 executes the computer program 321, it implements the steps of any of the above-described window control methods.

[0059] Since the electronic device described in this embodiment is a device used to implement a window control method in the embodiments of this application, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in the embodiments of this application. Therefore, how the electronic device implements the method in the embodiments of this application will not be described in detail here. Any device used by those skilled in the art to implement the method in the embodiments of this application falls within the scope of protection of this application.

[0060] In practical implementation, when the computer program 321 is executed by the processor, it can achieve the following: Figure 1 Any of the corresponding implementation methods in the embodiments.

[0061] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0062] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-readable program code.

[0063] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0064] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0065] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0066] This application also provides a computer program product, which includes computer software instructions that, when executed on a processing device, cause the processing device to execute a window control method.

[0067] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0068] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0069] In the several embodiments provided in this application, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0070] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0071] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0073] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0074] Although preferred embodiments have been described in this specification, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this specification.

[0075] Obviously, those skilled in the art can make various modifications and variations to this specification without departing from its spirit and scope. Therefore, if such modifications and variations fall within the scope of the claims and their equivalents, this specification is also intended to include such modifications and variations.

Claims

1. A vehicle window control method characterized by, The system comprises: if a collision event is determined based on vehicle-based multi-source perception data, determining a collision scenario based on the multi-source perception data; determining a target window control strategy matched with the collision scenario; wherein the target window control strategy comprises a target window and a corresponding lifting action of the target window; controlling the target window to perform the corresponding lifting action.

2. The method of claim 1, wherein, The multi-source perception data comprises impact data representing collision severity and collision type, attitude data representing vehicle attitude, and disaster risk data representing post-collision risk, and the determination of the collision scenario based on the multi-source perception data comprises: obtaining a preliminary scenario label through a preset scenario rule library based on the impact data, the attitude data and the disaster risk data; determining a collision scenario corresponding to the multi-source perception data based on the preliminary scenario label and a weighted decision model, wherein the collision scenario comprises at least one of a severe side collision, a severe frontal collision with fire risk, a severe rear-end collision, vehicle rollover, vehicle being hit in a stationary state, vehicle falling into water, and a minor scratch.

3. The method of claim 2, wherein, The determination of the target window control strategy matched with the collision scenario comprises: in the case of the collision scenario being a severe side collision, determining the target window to be all windows of the vehicle on the side hit by the vehicle, and the corresponding lifting action of the target window being a lowering action; in the case of the collision scenario being vehicle rollover, vehicle falling into water, or a severe frontal collision with fire risk, determining the target window to be all windows of the vehicle, and the corresponding lifting action of the target window being a lowering action; in the case of the collision scenario being a severe rear-end collision, determining the target window to be rear windows of the vehicle, and the corresponding lifting action of the target window being a lowering action; in the case of the collision scenario being a vehicle being hit in a stationary state, determining the target window to be all un-closed windows of the vehicle, and the corresponding lifting action of the target window being a lifting action.

4. The method of claim 3, wherein, The target window control strategy further comprises an execution priority, and the controlling of the target window to perform the corresponding lifting action comprises: determining a delay time for performing the lifting action based on the execution priority; controlling the target window to perform the lifting action based on the delay time.

5. The method of claim 4, wherein, The system further comprises: detecting a voltage of a main power supply of the vehicle; when the voltage of the main power supply is lower than a preset voltage threshold, controlling an emergency power supply of the vehicle to supply power to a driving module of the target window, so that the driving module drives the target window to perform the corresponding lifting action.

6. The method of claim 1, wherein, The system further comprises: starting timing from determining that a collision event occurs; if the collision scenario is not determined within a preset emergency decision time length, obtaining a default window control strategy and performing window control according to the default window control strategy; if the collision scenario is determined within the emergency decision time length, performing the step of determining the target window control strategy matched with the collision scenario.

7. The method of claim 1, wherein, The system further comprises: obtaining an on-off state of the target window after performing the lifting action; outputting prompt information containing the collision scenario and / or the on-off state.

8. A vehicle window control system characterized by comprising: The system comprises: a multi-source perception module configured to determine a collision scenario based on vehicle-based multi-source perception data if a collision event is determined based on the multi-source perception data; a decision engine module configured to determine a target window control strategy matching the collision scenario; wherein the target window control strategy comprises a target window and a corresponding lifting action of the target window; a window execution module configured to control the target window to perform the corresponding lifting action.

9. An electronic device comprising: A memory and a processor, wherein the processor is configured to implement the steps of the window control method according to any one of claims 1 to 7 when executing a computer program stored in the memory.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is configured to implement the steps of the window control method according to any one of claims 1 to 7 when executed by the processor.

Images