Disaster warning method, system, vehicle and storage medium

Abstract

A disaster early warning method and system, a vehicle and a storage medium are applied to the technical field of vehicle safety monitoring. When it is detected that the vehicle is parked, the vehicle body controller, the cabin controller and the communication module are switched to the corresponding light sleep mode, deep sleep mode and low-frequency broadcast mode respectively. The vehicle body controller, the cabin controller and the communication module follow the principle of gradual wake-up: the vehicle body controller performs a data listening task in a conventional low-power mode; when there is a suspected disaster, the vehicle body controller wakes up the cabin controller; the cabin controller controls the communication module to broadcast the monitoring data of the vehicle at a high frequency, and receives the monitoring data of surrounding vehicles. The vehicle body controller, the cabin controller and the communication module cooperate with each other, gradually wake up, and significantly reduce the power consumption of the whole vehicle. The monitoring data collected by multiple vehicles are verified cooperatively, the monitoring information between vehicles can be compared and matched, and the disaster event recognition accuracy and early warning output accuracy are improved.

Description

Technical Field

[0001] This application relates to the field of vehicle-mounted safety monitoring technology, and in particular to a disaster early warning method, system, vehicle, and storage medium. Background Technology

[0002] With the rapid iteration of intelligent vehicle technology and the widespread adoption of new energy vehicles, vehicle safety management is receiving increasing attention. When the monitoring data collected by a single vehicle exceeds the preset safety threshold or abnormal risk signals are detected, the onboard disaster monitoring system will identify disasters and determine the risk level. If a potential disaster is identified, it will trigger warning actions such as audible and visual alerts.

[0003] The disaster monitoring scheme based on single-vehicle monitoring data described above is susceptible to interference from external environmental factors such as dust, insects, rain splashes, environmental electromagnetic interference, and continuous site vibrations. To avoid false alarms, vehicles can synchronize environmental monitoring data for collaborative verification. However, if the vehicle remains in a wake-up state during this process, it will result in high power consumption, affecting the vehicle's driving range. Summary of the Invention

[0004] This application provides a disaster early warning method, system, vehicle, and storage medium for reducing power consumption during multi-vehicle collaborative disaster early warning.

[0005] To solve the above problems, this application adopts the following technical solution: Firstly, a disaster early warning method is provided. This method can be applied to a first vehicle. The first vehicle may include a body controller, a cockpit controller, and a communication module. The method may include: after the first vehicle is parked, the body controller acquires monitoring data of the first vehicle in a shallow sleep mode; the cockpit controller detects a wake-up signal in a deep sleep mode; and the communication module broadcasts first information in a low-frequency broadcast mode, indicating that the first vehicle has the ability to share monitoring data. When the monitoring data of the first vehicle reaches an early warning threshold, the body controller sends a wake-up signal to the cockpit controller. The cockpit controller, in response to the wake-up signal, switches from a deep sleep mode to a normal operating mode and sends a first instruction to the communication module. The communication module, in response to the first instruction, switches from a low-frequency broadcast mode to a high-frequency broadcast mode and broadcasts the monitoring data of the first vehicle in the high-frequency broadcast mode. The monitoring data of the first vehicle is used for disaster early warning. The power consumption of the deep sleep mode is less than that of the normal operating mode, the power consumption of the shallow sleep mode is less than that of the normal operating mode, and the power consumption of the low-frequency broadcast mode is less than that of the high-frequency broadcast mode.

[0006] In this method, upon detecting vehicle parking, the body controller, cabin controller, and communication module switch to their corresponding shallow sleep mode, deep sleep mode, and low-frequency broadcast mode, respectively. These modes are specific modes defined within the vehicle's sleep state, and compared to the normal operating mode, they reduce power consumption. The body controller, cabin controller, and communication module follow a step-by-step wake-up principle: the body controller performs data monitoring tasks in the normal low-power mode; when a suspected disaster occurs, the body controller wakes up the cabin controller; the cabin controller then controls the communication module to broadcast the vehicle's monitoring data at high frequency. This collaborative, step-by-step wake-up of the body controller, cabin controller, and communication module not only ensures the disaster warning function but also significantly reduces overall vehicle power consumption. Furthermore, this method enables mutual risk assistance among vehicles, relying on environmental monitoring data collected synchronously by multiple vehicles within the same parking area for collaborative joint verification. This effectively filters out various environmental interference signals such as light, dust, and short-term weather fluctuations, accurately distinguishing interference sources from actual disaster characteristics, significantly suppressing false disaster warnings, and significantly improving the accuracy of disaster event identification and warning output.

[0007] The aforementioned body-type and cockpit-type controllers are functionally defined units categorized by vehicle functional domains, and are not fixed hardware entity names. Their specific hardware carriers and naming conventions vary depending on the overall vehicle's electronic and electrical architecture. For example, in a distributed architecture, body-type and cockpit-type controllers can be decomposed into multiple independent small ECUs. Furthermore, in a domain-centralized architecture, body-type controllers can be BDC, VDC, or Body Super Core, while cockpit-type controllers can be CDC, MGU, or Cockpit Super Core. Yet another example is in a CC architecture, where body-type controllers can be domain controllers responsible for collecting sensor data and device communication; cockpit-type controllers can be central computing units responsible for disaster assessment based on multi-vehicle data.

[0008] The aforementioned communication module is used to broadcast the vehicle's monitoring data to surrounding vehicles and to receive monitoring data from the communication modules of surrounding vehicles. As an example, the communication modules installed between different vehicles can employ wireless communication methods, such as Bluetooth, Wi-Fi, NFC, RFID, UWB, or Wi-Fi, as well as other future short-range communication technologies. Compared to wired communication methods, wireless communication between vehicles eliminates the limitations of wiring harness connections and interface matching, making it suitable for simultaneous disaster early warning in scenarios involving existing vehicles and mixed parking of multiple vehicle types.

[0009] In one possible implementation, after the communication module switches from a low-frequency broadcast mode to a high-frequency broadcast mode in response to a first command, the method may further include: the communication module receiving monitoring data from a second vehicle; and the cockpit controller performing disaster warning based on the monitoring data from the first vehicle and the monitoring data from the second vehicle. In this approach, vehicles can not only broadcast their own collected monitoring data but also receive monitoring data from other vehicles, thereby enabling collaborative joint verification based on environmental monitoring data collected synchronously by multiple vehicles.

[0010] In one possible implementation, the method may further include: a communication module receiving second information from other vehicles in a low-frequency broadcast mode and forwarding the second information to a body-type controller. This second information can indicate that other vehicles have the capability to share monitoring data, including a second vehicle. The wake-up signal carries information about the vehicles capable of sharing monitoring data. The aforementioned cockpit-type controller performs disaster warnings based on the monitoring data of the first and second vehicles, which may include: the cockpit-type controller performing disaster warnings based on the vehicle information, the monitoring data of the first vehicle, and the monitoring data of the second vehicle. In this approach, vehicles parked in the same area can broadcast their risk-sharing capabilities to each other, allowing them to know in advance whether there are vehicles with risk-sharing capabilities nearby. If the first vehicle receives capability information from other vehicles and monitoring data from other vehicles, it can use the measurement data from other vehicles to assist in assessing the disaster situation.

[0011] In one possible implementation, after the body-type controller sends a wake-up signal carrying vehicle information to the cockpit-type controller, the method may further include: if the cockpit-type controller does not receive monitoring data from other vehicles through the communication module, the cockpit-type controller does not trigger an alarm operation. In this approach, vehicles parked in the same area can broadcast their risk mutual assistance capabilities to each other, allowing them to know in advance whether there are vehicles with risk mutual assistance capabilities nearby. If the first vehicle determines that there are vehicles with risk mutual assistance capabilities nearby, but does not receive monitoring data from surrounding vehicles, it means that the monitoring data from surrounding vehicles has not reached the warning threshold and therefore has not woken up the cockpit-type controller. In this case, the first vehicle can directly determine that it is environmental interference and perform silent suppression.

[0012] In one possible implementation, the method may further include: if the communication module does not receive the second information, after the body-type controller wakes up the cockpit-type controller, the cockpit-type controller sends a second instruction to the communication module and issues a disaster warning based on the monitoring data of the first vehicle. This second instruction instructs the communication module to stop transmitting and receiving monitoring data. In this approach, if the first vehicle does not receive the second information, it indicates that there are no vehicles with risk mutual assistance capabilities nearby. The first vehicle can then make a disaster assessment based solely on single-vehicle monitoring data and notify the communication module to stop transmitting and receiving monitoring data, thereby reducing vehicle power consumption.

[0013] In one possible implementation, the cockpit controller performs disaster early warning based on vehicle information, monitoring data from a first vehicle, and monitoring data from a second vehicle. This can include: when the vehicle information indicates that both a second and a third vehicle are present, and the communication module has not received monitoring data from the third vehicle, the cockpit controller determines that the monitoring data from the third vehicle has not reached the warning threshold, and determines whether to trigger an alarm operation based on the fusion result of the monitoring data from the first and second vehicles; when the vehicle information indicates that both a second and a third vehicle are present, and the communication module has received monitoring data from the third vehicle, the cockpit controller performs disaster early warning based on the monitoring data from the first, second, and third vehicles. In this approach, multiple vehicles may exist around the first vehicle. The monitoring data of some of these vehicles may be abnormal, while the monitoring data of others may not be abnormal. Vehicles without abnormalities may return monitoring data to the first vehicle or may not. Because other vehicles broadcast their risk-sharing capabilities to the first vehicle in advance, the first vehicle can make accurate disaster predictions regardless of whether other vehicles share their monitoring data with it.

[0014] In one possible implementation, the method may further include: after the alarm operation is completed, the cockpit controller sends a third instruction to the communication module, and the cockpit controller returns to deep sleep mode. The third instruction is used to instruct the communication module to return to low-frequency broadcast mode. In this approach, after the alarm operation is completed, the communication module returns to low-frequency broadcast mode and the cockpit controller returns to deep sleep mode, which can reduce vehicle power consumption.

[0015] In one possible implementation, before the cockpit controller receives monitoring data from the second vehicle via the communication module, the method may further include: the cockpit controller reading the state of the risk mutual assistance switch, which is used to enable or disable the function of sharing monitoring data; and when the risk mutual assistance switch is in the enabled state, the cockpit controller enables the function of sharing monitoring data. The shared monitoring data includes sending and receiving monitoring data. Additionally, after the cockpit controller reads the state of the risk mutual assistance switch, the method may further include: when the risk mutual assistance switch is in the disabled state, the cockpit controller sends a fourth instruction to the communication module and issues a disaster warning based on the monitoring data from the first vehicle; this fourth instruction instructs the communication module to stop sending and receiving monitoring data. In this approach, the "risk mutual assistance switch" is a newly added function switch, used by the user to autonomously enable or disable the vehicle-to-vehicle cooperative warning function. The "state of the risk mutual assistance switch" is a static value used to determine whether the vehicle-to-vehicle cooperative warning function is enabled. After the vehicle enters a dormant state, the "state of the risk mutual assistance switch" can be synchronized to the vehicle network in real time. After waking from deep sleep, the cockpit controller can read the status of the "risk mutual assistance switch". If the "risk mutual assistance switch" is on, the cockpit controller can activate the vehicle-to-vehicle cooperative warning function, broadcasting its own monitoring data and receiving monitoring data from surrounding vehicles. If the "risk mutual assistance switch" is off, the cockpit controller can disable the vehicle-to-vehicle cooperative warning function and adopt a single-vehicle warning mode, that is, using only the monitoring data collected by its own vehicle to complete the disaster assessment. In addition, the communication module stops sending and receiving monitoring data, which can reduce vehicle power consumption. By adding a risk mutual assistance switch, the CDC reads the status of the risk mutual assistance switch after waking up, thereby controlling the start and stop of vehicle-to-vehicle cooperative data interaction, realizing manual switching of warning modes, and compatibility with user privacy protection and power consumption.

[0016] In one possible implementation, the broadcast period for the first information is a first cycle, and the period for the monitoring data of the first vehicle is a second cycle, which is shorter than the first cycle. In this implementation, the communication module is equipped with two communication modes: a low-frequency broadcast mode and a high-frequency broadcast mode. In the low-frequency broadcast mode, the communication module uses a low-frequency, intermittent wireless broadcast mechanism, i.e., it sends signals according to the first cycle, thereby reducing power consumption. In the high-frequency broadcast mode, the communication module uses a high-frequency, continuous broadcast mechanism, i.e., it sends signals according to the second cycle, thereby improving the speed of monitoring data sharing.

[0017] In one possible implementation, the monitoring data of the first vehicle can be encapsulated as a disaster message, which includes at least one of the following: vehicle identifier for marking the vehicle; disaster type field for indicating the type of suspected disaster detected; local perception confidence level for assisting surrounding vehicles in determining the disaster situation; vehicle location information for indicating the vehicle's location; timestamp for marking the time of data collection; and CRC checksum. In this approach, vehicles parked in the same area broadcast their risk mutual assistance capabilities, facilitating mutual determination among vehicles to identify whether there are other vehicles with risk mutual assistance capabilities nearby. After the vehicle-to-vehicle cooperative early warning function is activated, the risk early warning method can be optimized based on the known vehicles with risk mutual assistance capabilities and the received monitoring data, further improving the accuracy of disaster event identification and early warning output.

[0018] In one possible implementation, the method may further include: if the monitoring data of the first vehicle does not reach the warning threshold, and the communication module receives monitoring data from other vehicles, the body controller sends a wake-up signal to the cockpit controller; the cockpit controller responds to the wake-up signal by switching from deep sleep mode to normal operation mode and sends a first command to the communication module; the communication module responds to the first command by switching from low-frequency broadcast mode to high-frequency broadcast mode and broadcasts the monitoring data of the first vehicle in high-frequency broadcast mode. In this method, when the sensor data acquired by the first vehicle reaches the warning threshold, the body controller of the first vehicle wakes up the cockpit controller and returns the vehicle's monitoring data to surrounding vehicles, facilitating accurate disaster prediction by combining the monitoring data of multiple vehicles.

[0019] Secondly, this application provides a vehicle body control system. The vehicle body control system includes a body-type controller, a cockpit-type controller, and a communication module. The body-type controller is used to acquire monitoring data of a first vehicle in a shallow sleep mode after the vehicle is parked; and to send a wake-up signal to the cockpit-type controller when the monitoring data of the first vehicle reaches a warning threshold. The cockpit-type controller is used to detect the wake-up signal in a deep sleep mode after the vehicle is parked; and to switch from deep sleep mode to normal operation mode in response to the detected wake-up signal, and to send a first command to the communication module. The communication module is used to broadcast first information in a low-frequency broadcast mode after the vehicle is parked, the first information indicating that the first vehicle has the ability to share monitoring data; and to switch from low-frequency broadcast mode to high-frequency broadcast mode in response to the first command, broadcasting the monitoring data of the first vehicle in high-frequency broadcast mode, the monitoring data of the first vehicle being used for disaster warning. The power consumption of the deep sleep mode is less than that of the shallow sleep mode, the power consumption of the shallow sleep mode is less than that of the normal operation mode, and the power consumption of the low-frequency broadcast mode is less than that of the high-frequency broadcast mode.

[0020] In one possible implementation, the body-type controller can also be used to execute the method executed by the body-type controller in the first aspect and any of its possible implementations, the cockpit-type controller can also be used to execute the method executed by the cockpit-type controller in the first aspect and any of its possible implementations, and the communication module can also be used to execute the method executed by the communication module in the first aspect and any of its possible implementations.

[0021] Thirdly, this application provides a vehicle that may include the body control system provided in the second aspect.

[0022] Fourthly, this application provides a computer-readable storage medium. This computer-readable storage medium may include instructions. When executed on a computer, the instructions cause the computer to perform the method described in the first aspect above and any possible implementation thereof.

[0023] It is understood that the beneficial effects achieved by the body control system of the second aspect, the vehicle of the third aspect, and the computer-readable storage medium of the fourth aspect can be referred to as the beneficial effects of the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0024] Figure 1 This is a functional schematic diagram of a vehicle provided in an embodiment of this application; Figure 2 A schematic diagram of a disaster early warning system based on a domain-centralized architecture provided in an embodiment of this application; Figure 3 A schematic diagram illustrating a vehicle-to-vehicle near-field communication scenario provided in an embodiment of this application; Figure 4 A flowchart illustrating a disaster early warning method provided in an embodiment of this application; Figure 5 A flowchart illustrating another disaster early warning method provided in this application embodiment; Figure 6 A flowchart illustrating another disaster early warning method provided in this application embodiment; Figure 7 A flowchart illustrating another disaster early warning method provided in this application embodiment; Figure 8 A flowchart illustrating another disaster early warning method provided in this application embodiment; Figure 9 A flowchart illustrating another disaster early warning method provided in this application embodiment; Figure 10 This is a schematic block diagram of a communication device provided in an embodiment of this application. Detailed Implementation

[0025] The terms "first" and "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the description of embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0026] The following explains some key terms used in the embodiments of this application.

[0027] 1. Parked status.

[0028] In the automotive electronics / automotive industry, parking status typically refers to a vehicle that is completely stationary, with the power system stopped outputting power. The wheels are locked by a combination of mechanical locking in the P gear and the parking brake, providing anti-rollover capability. This is categorized into temporary parking (e.g., AUTOHOLD) and long-term parking. In this embodiment, parking status refers to a vehicle that is completely stationary, with the gear in parking gear, the parking brake engaged, occupants exiting the vehicle and locking the doors. The vehicle shuts off most onboard electrical equipment, maintaining only basic power for security and low-voltage wake-up, entering a low-power sleep state.

[0029] 2. Normal working mode and hibernation mode.

[0030] Vehicles can be divided into normal working mode and sleep mode.

[0031] Normal operating mode, also known as wake-up mode or wake-up state, refers to the vehicle's network and necessary control units entering an "active" state. At this time, the current rises from microamperes or milliamperes to amperes, various controllers power on and run their main programs, and the vehicle can respond to driver or system commands to perform various functions. For example, the vehicle is in wake-up mode while driving (e.g., autonomous or manual driving). Another example is when the vehicle detects a real disaster, it enters wake-up mode and executes an alarm.

[0032] Hibernation mode, also known as sleep state, refers to a state in which the vehicle's entire network and most control units enter a "silent" state. At this time, bus communication activity essentially ceases, most controllers disable their main functions, and only retain extremely low-power standby circuits to minimize quiescent current when the vehicle is stationary and prevent battery depletion. For example, the vehicle is in hibernation mode when parked. Another example is when the vehicle returns to hibernation mode after executing an alarm action.

[0033] 3. Deep sleep mode / state.

[0034] Deep sleep mode / state is an extremely low-power operating mode / state designed for vehicle controllers (such as cockpit domain controllers) while in sleep mode. In deep sleep mode / state, the controller shuts down most of its computational logic, cuts off most peripheral communication and drive interactions, and only maintains minimal basic circuitry operation such as wake-up signal detection. There are no periodic sensor checks, status updates, or other active tasks, and the vehicle's static power consumption remains at an extremely low level. It can be woken up by a detected trigger signal and switched to normal operating mode. The power consumption of deep sleep mode is less than that of normal operating mode.

[0035] 4. Shallow hibernation mode / state.

[0036] Shallow sleep mode / state is a conventional low-power mode / operating state designed for vehicle controllers (such as body controllers) during sleep mode. In shallow sleep mode / state, overall power consumption is lower than in normal operating mode. The controller suspends non-core complex calculations, retains basic signal paths, and automatically performs lightweight basic tasks such as sensor data acquisition, condition monitoring, and status reporting according to a set cycle. It can respond to real-time monitoring needs and has a faster wake-up response speed. The power consumption of shallow sleep mode is less than that of normal operating mode.

[0037] 5. Single-vehicle warning mode.

[0038] Single-vehicle warning mode refers to a traditional warning mode in which data is collected by the vehicle's own sensors. When the data value collected by the sensors exceeds the warning threshold, the vehicle relies on its own sensor data to complete the disaster judgment and alarm, without interacting with surrounding vehicles.

[0039] 6. Vehicle-to-vehicle cooperative early warning function.

[0040] Vehicle-to-vehicle cooperative early warning function, also known as risk mutual assistance function, is a new feature added in this application embodiment. Vehicles with the vehicle-to-vehicle cooperative early warning function enabled can share vehicle monitoring data, such as sensor data for smoke, temperature, water level, or vibration. After a single vehicle's sensor triggers an early warning threshold, it can broadcast its own monitoring data while simultaneously receiving monitoring data from surrounding vehicles. Thus, the vehicle can jointly determine a disaster by utilizing the monitoring data from other vehicles parked in the same environment.

[0041] 7. Risk mutual assistance switch.

[0042] The risk assistance switch is a new feature added to the vehicle-to-vehicle cooperative warning / risk assistance function. It can be either a physical button or a virtual soft switch on the vehicle's infotainment system, allowing the user to manually enable or disable the vehicle-to-vehicle cooperative warning function. As an example, the on / off state of the risk assistance switch can be read by the cockpit domain controller (CDC) and used as the overall function enable signal. If the risk assistance switch is on, the CDC can enable the vehicle-to-vehicle cooperative warning function. If the risk assistance switch is off, the CDC reverts to single-vehicle warning mode, disabling the vehicle-to-vehicle cooperative warning function.

[0043] 8. False alarm suppression.

[0044] False alarm suppression, also known as silent suppression, refers to the process of distinguishing between environmental interference and real disasters by comparing data from multiple vehicles when the vehicle-to-vehicle cooperative early warning function is enabled. Abnormal triggers caused by environmental interference are handled silently to avoid invalid alarms.

[0045] 9. Disaster reports.

[0046] Disaster messages refer to standardized data frames sent out by vehicles when the vehicle-to-vehicle cooperative early warning function is enabled. These frames include vehicle identification, disaster type, sensor data, location, timestamp, and cyclic redundancy check (CRC) code. They are used for vehicle-to-vehicle cooperative data exchange to complete multi-vehicle cooperative verification.

[0047] 10. Low-frequency broadcast mode and high-frequency broadcast mode.

[0048] Low-frequency broadcast mode and high-frequency broadcast mode are two relative operating modes designed for the communication module during sleep mode. Low-frequency broadcast mode, also known as low-power intermittent broadcast mode, is the normal operating mode for the vehicle communication module. It uses a low-frequency, intermittent wireless broadcast mechanism to ensure basic communication capabilities while meeting the low-power management requirements during vehicle parking. High-frequency broadcast mode, also known as high-frequency alarm broadcast mode, is a dedicated operating mode activated by the communication module when vehicle sensors detect abnormal operating conditions. It continuously broadcasts signals at high frequency for transmitting alarms of abnormal events. The power consumption of low-frequency broadcast mode is lower than that of high-frequency broadcast mode.

[0049] 11. Area Controller.

[0050] The zone control unit (ZCU) is a hardware unit for the new generation of intelligent vehicle architectures, responsible for interfacing with sensors, actuators, and the central computing platform to achieve signal forwarding and peripheral management. As an example, according to the physical installation location of the vehicle, the zone control unit can be divided into the front zone control unit (FZCU), the left body zone control unit (LZCU), the right body zone control unit (RZCU), the tail zone control unit (TZCU), etc. As another example, classified by hardware computing power and processing capabilities, the zone control unit can be divided into zone aggregators, standard zone control units, high-performance zone processors, etc.

[0051] With the rapid iteration of intelligent vehicle technologies and the widespread popularity of new energy vehicles, vehicle safety control has received increasing attention. The on-vehicle disaster monitoring system has become an essential safety protection configuration for new energy vehicles and fuel vehicles. The on-vehicle disaster monitoring system can effectively monitor various disaster risks such as fires, waterlogging, and external force damage during the vehicle's stationary state, providing basic protection for the overall vehicle's use safety.

[0052] In the mainstream disaster monitoring solutions, the vehicle is equipped with various environmental perception sensors. The on-vehicle disaster monitoring system periodically collects real-time monitoring data through various environmental perception sensors to achieve regular inspections of the vehicle's surrounding and interior environments. After the monitoring data collected by the sensors exceeds the preset safety threshold or captures abnormal risk signals, the on-vehicle disaster monitoring system conducts disaster identification and risk level determination. If a disaster隐患 is identified, the on-vehicle disaster monitoring system will trigger warning operations such as audible and visual warnings to alert surrounding personnel of the vehicle safety risk.

[0053] The above disaster monitoring solutions have the following defects: After the vehicle parks and the vehicle occupants leave the vehicle, various environmental perception sensors are vulnerable to external environmental factors such as dust, mosquito and insect occlusion, rain splashing, environmental electromagnetic interference, and continuous site vibration, generating abnormal acquisition data and reaching the warning threshold, thus generating a large number of false alarm messages. The frequently generated false alarm messages will not only continuously disturb users, but in the long run, will also significantly reduce the trust level of vehicle occupants in the overall vehicle warning system. In addition, the disaster monitoring system has a single judgment logic and a relatively simple warning form, lacking expansion capabilities such as risk traceability and hierarchical linkage protection, unable to identify group safety risks such as连片 fires and regional waterlogging, and difficult to adapt to the current requirements for all-round, refined, and highly reliable vehicle safety protection of intelligent vehicles.

[0054] It should be noted that there is an unclear expression "灾害隐患" in the original text which is directly translated as "disaster隐患" here. It may need to be further clarified and accurately translated according to the specific context. Also, "连片火情" is translated as "连片 fires" which may not be the most accurate term and might need to be adjusted based on the actual meaning.In view of the above problems, this application provides a disaster early warning method, system, vehicle, and storage medium based on vehicle-to-vehicle cooperation. After the vehicle is parked, the body controller acquires the monitoring data of the first vehicle in a shallow sleep mode, the cockpit controller detects a wake-up signal in a deep sleep mode, and the communication module broadcasts first information in a low-frequency broadcast mode, which indicates that the first vehicle has the ability to share monitoring data. When the monitoring data of the first vehicle reaches the early warning threshold, the body controller sends a wake-up signal to the cockpit controller. The cockpit controller switches from deep sleep mode to wake-up mode in response to the wake-up signal and sends a first instruction to the communication module. The communication module switches from low-frequency broadcast mode to high-frequency broadcast mode in response to the first instruction and broadcasts the monitoring data of the first vehicle in high-frequency broadcast mode. The monitoring data of the first vehicle is used for disaster early warning. The power consumption of the deep sleep mode is less than that of the wake-up mode, the power consumption of the shallow sleep mode is less than that of the wake-up mode, and the power consumption of the low-frequency broadcast mode is less than that of the high-frequency broadcast mode.

[0055] In this method, upon detecting vehicle parking, the body controller, cabin controller, and communication module switch to their corresponding shallow sleep mode, deep sleep mode, and low-frequency broadcast mode, respectively. These modes are specific modes defined within the vehicle's sleep state. The body controller, cabin controller, and communication module follow a step-by-step wake-up principle: the body controller performs data monitoring tasks in normal low-power mode; when a suspected disaster occurs, the body controller wakes up the cabin controller; the cabin controller then controls the communication module to broadcast the vehicle's monitoring data at high frequency. The body controller, cabin controller, and communication module work together, waking up step-by-step, significantly reducing overall vehicle power consumption. Furthermore, this method enables mutual risk assistance between vehicles, relying on environmental monitoring data collected synchronously by multiple vehicles within the same parking area for collaborative joint verification. This effectively filters out various environmental interference signals such as light, dust, and short-term weather fluctuations, accurately distinguishing interference sources from actual disaster characteristics, significantly suppressing false disaster warnings, and significantly improving the accuracy of disaster event identification and warning output. This method allows for software upgrades based on the vehicle's hardware architecture without requiring additional physical components, thus reducing mass production costs and improving the versatility of the solution.

[0056] The aforementioned body-type controllers and cockpit-type controllers are functional definition units divided according to vehicle functional domains, and are not fixed hardware entity names. Their specific hardware carriers and naming formats are adjusted according to changes in the overall vehicle electronic and electrical architecture. This functional division logic is universal and can be adapted to various evolving vehicle electronic and electrical architectures. With the iteration of architecture computing power layout and hardware integration solutions, the hardware carriers and professional names corresponding to body-type controllers and cockpit controllers will change accordingly.

[0057] The aforementioned cockpit controller can also be replaced with a telematics box (T-BOX) or other controllers.

[0058] The disaster early warning method provided in this application can be applied to distributed architecture, domain-centralized architecture, and central computing architecture.

[0059] The distributed architecture is driven by functional requirements, adding on-demand in-vehicle electronic devices such as sensors and electronic control units (ECUs), enabling configurations where a single function is matched with an independent ECU. As in-vehicle functions continue to expand, the number of ECUs in a vehicle is constantly increasing, leading to a corresponding increase in system coupling complexity and wiring harness scale. This architecture is suitable for older gasoline vehicles and the retrofitting of existing models. Various controllers operate independently in a network, and new functions can be deployed using the vehicle's existing wiring harnesses and native signal interaction links without significant modifications to the vehicle's underlying electronic and electrical architecture. In this distributed architecture, body controllers and cabin controllers can be broken down into multiple independent small ECUs. For example, body controllers can be broken down into left front door control ECUs, right front door control ECUs, rear window control ECUs, lighting ECUs, and tailgate ECUs; cabin controllers can be broken down into instrument cluster ECUs, in-vehicle infotainment (IVI) head units, audio amplifier ECUs, etc.

[0060] The domain-centralized architecture is functionally divided into domains, with centralized control within each domain, reducing the number of ECUs and lowering system complexity. The traditional five domains are powertrain, chassis, body, intelligent driving, and cockpit. Current trends favor vehicle control, autonomous driving (or intelligent driving), and intelligent cockpit domains, each centrally controlled by a domain controller. The vehicle domain controller (VDC) is responsible for overall vehicle control and has high requirements for real-time performance and safety; the vehicle control domain can be understood as integrating the original powertrain, chassis, and body domains. The intelligent driving domain controller (ADC) is responsible for perception, decision-making, and control functions related to intelligent driving. The intelligent cockpit domain controller (CDC) is responsible for cockpit intelligence functions such as human-machine interaction. Domain controllers have different names on different manufacturers' platforms. For example, the E3 architecture of one manufacturer's MEB platform (the first car, ID.3) is a domain-centralized EEA consisting of three in-car application servers (ICAS): Vehicle Control Server ICAS1, Intelligent Driving Server ICAS2, and Infotainment Server ICAS3. Another manufacturer's iNEXT model's EEA includes three domain controllers: BDC (Body Domain Controller, corresponding to VDC), SAS (ADC), and MGU (Media Graphics Unit, corresponding to CDC). In some three-domain EEA solutions, the three domain controllers are Body Super Core (corresponding to VDC), ADAS Super Core (corresponding to ADC), and Cockpit Super Core (corresponding to CDC). Some also call ADC the Mobile Data Center (MDC). In a domain-centralized architecture, body-related controllers can be the Body Domain Controller (BDC), VDC, or Body Super Core, while cockpit-related controllers can be CDC, MGU, or Cockpit Super Core.

[0061] The central computing (CC) architecture employs a distributed network + domain controller architecture, dividing vehicle control into three main parts: driving, cockpit, and vehicle control. It introduces three major platforms: MDC (as an intelligent driving platform), CDC (as an intelligent cockpit platform), and VDC (as a vehicle control platform). The CC architecture's network primarily consists of a backbone network and multiple intranets. MDC, CDC, and VDC are connected to the backbone network and communicate with each other through it. Multiple intranets form a distributed network, connected to the backbone network via distributed gateways. These distributed gateways can also be called vehicle integration units (VIUs). VIUs function as gateways, connecting their respective intranets to the backbone network. They can perform data format conversion (or encapsulation) and forwarding functions. For example, they can convert data from intranets into data formats supported by the backbone network for forwarding, or encapsulate data from the backbone network into data formats supported by the intranet for forwarding. This format conversion process can be a process of encapsulating data according to supported protocols; therefore, it can also be called an encapsulation process or a protocol conversion process. In addition to gateway functions, the VIU (Vehicle Integrated Unit) can also possess electronic control capabilities, providing partial or complete data processing and / or control functions for at least one vehicle component. This means the VIU can implement the electronic control functions provided by the ECUs (Electronic Control Units) of some or all vehicle components, thus reducing the number of ECUs required. Furthermore, the VIU can also handle cross-vehicle component data processing, such as processing and calculating data acquired from actuators of multiple vehicle components. In the CC (Computer-Controlled) architecture, body-type controllers can be domain controllers, responsible for acquiring sensor data and device communication; cockpit-type controllers can be central computing units, responsible for disaster assessment based on multi-vehicle data.

[0062] The backbone network can adopt a ring topology network structure, and communication between various domain controllers, as well as between the intranet and the domain controllers, can be realized through vehicle-mounted Ethernet. In addition, the CC architecture can also include a T-BOX (or vehicle-mounted communication unit), which is connected to the backbone network to realize communication between the vehicle and the cloud, other terminals (such as vehicles, mobile phones, etc.), or roadside equipment.

[0063] The specific implementation of the disaster early warning method provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0064] For example, Figure 1 This is a functional schematic diagram of the vehicle 00 provided in the embodiments of this application.

[0065] like Figure 1As shown, vehicle 00 may include various subsystems, such as perception system 1000 and computing platform 2000. In one possible implementation, vehicle 00 may include more or fewer subsystems, and each subsystem may include one or more components. Furthermore, each subsystem and component of vehicle 00 may be interconnected via wired or wireless means.

[0066] The perception system 1000 may include several types of sensors for sensing information about the interior or surrounding environment of the vehicle 00.

[0067] As an example, the sensing system 1000 may include a camera 1100, a temperature sensor 1200, an infrared thermal imager 1300, a smoke sensor 1400, a water level sensor 1500, and a vibration sensor 1600. The camera 1100, temperature sensor 1200, infrared thermal imager 1300, smoke sensor 1400, water level sensor 1500, and vibration sensor 1600 can be connected to the computing platform 2000 via wiring harnesses or wirelessly. The camera 1100 may include a forward-facing camera positioned above the inner side of the windshield, side-facing cameras positioned below the B-pillar, fender, or exterior rearview mirror, a rear-facing camera positioned near the trunk or tailgate emblem, and cameras positioned within the smart cockpit. These cameras can capture continuous video frames, such as RGB images, for disaster identification. The temperature sensor 1200 can be positioned inside the battery pack, in high-voltage junction boxes, and in motor windings—critical heat points—to directly measure temperature values ​​for fire identification. The infrared thermal imager 1300 can be deployed inside the cabin and battery pack to provide two-dimensional temperature field images for detecting anomalous hotspots not covered by contact sensors. The smoke sensor 1400, also known as a smoke detection sensor, can be deployed inside the battery pack, forward cabin, and crew compartment to trigger fire warnings in the early stages of smoke generation due to short circuits or overheating. The water level sensor 1500 can be a water pressure sensor, ultrasonic level sensor, millimeter-wave radar level sensor, etc., deployed under the chassis to calculate water depth based on water pressure or distance. The vibration sensor 1600 can be an accelerometer, microelectromechanical system (MEMS) sensor, inertial measurement unit (IMU), etc., to capture geological vibration signals.

[0068] Some or all of the functions of vehicle 00 can be controlled by computing platform 2000. Computing platform 2000 may include one or more processors 2100. Processor 2100 is a circuit with signal processing capabilities. In one implementation, processor 2100 may be a circuit with instruction read and execute capabilities, such as a central processing unit (CPU), microprocessor unit (MPU), graphics processing unit (GPU) (which can be understood as a type of microprocessor), or digital signal processor (DSP). In another implementation, processor 2100 can implement certain functions through the logical relationships of hardware circuits. These logical relationships are fixed or reconfigurable. For example, processor 2100 may be a hardware circuit implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as a field-programmable gate array (FPGA). In a reconfigurable hardware circuit, the process of processor 2100 loading configuration documents and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the aforementioned units. Furthermore, processor 2100 can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU) or a deep learning processing unit (DPU). In addition, computing platform 2000 may also include memory for storing instructions. Some or all of the processors in processor 2100 can call instructions from memory to implement corresponding functions.

[0069] The computing platform 2000 can control the functions of the vehicle 00 based on inputs received from various subsystems (such as the sensing system 1000). The computing platform 2000 provides control over many aspects of the vehicle 00 and its subsystems. For example, in a fire warning scenario, after receiving video frames from the camera 1100, the computing platform 2000 can identify flames, smoke, or abnormal brightness changes based on features such as color, shape, and texture, and output structured data such as visual fire confidence scores, flame / smoke location coordinates, and diffusion speed. Alternatively, after receiving temperature data from the temperature sensor 1200, the computing platform 2000 can extract features such as absolute temperature and temperature rise rate (the slope of temperature rise per unit time), and output structured data such as temperature anomaly level, highest temperature point and location, and maximum temperature rise rate. Or, after receiving thermal images from the infrared thermal imager 1300, the computing platform 2000 can identify localized overheated areas (hot spots) and their diffusion trends through thermal imaging analysis.

[0070] In some embodiments, after receiving sensor data from camera 1100, temperature sensor 1200, infrared thermal imager 1300, smoke sensor 1400, water level sensor 1500, and vibration sensor 1600, the computing platform 2000 can align these data on a timeline to ensure that the analysis is of the vehicle status at the same moment. Then, it performs fusion inference and confidence calculation on the aligned environmental monitoring data and environmental monitoring data synchronously collected from other vehicles in the same parking area to generate safety warning level information. Different safety warning levels trigger different operations on vehicle 00.

[0071] In some embodiments, in intelligent vehicles employing a domain-centralized architecture and a central computing platform 2000, Ethernet and a controller area network (CAN) bus are connected via a central gateway. Ethernet is responsible for transmitting high-bandwidth data, such as sensor data collected by cameras 1100, temperature sensors 1200, infrared thermal imagers 1300, smoke sensors 1400, water level sensors 1500, and vibration sensors 1600; the CAN bus is responsible for transmitting high-real-time control signals, such as audible and visual alarms and door unlocking signals during disasters.

[0072] The vehicle 00 in this application embodiment may include: road vehicles, water vehicles, air vehicles, industrial equipment, agricultural equipment, or entertainment equipment, etc. For example, vehicle 00 may be a means of transportation (such as commercial vehicles, passenger cars, motorcycles, flying cars, trains, etc.), industrial vehicles (such as forklifts, trailers, tractors, etc.), engineering vehicles (such as excavators, bulldozers, cranes, etc.), agricultural equipment (such as lawnmowers, harvesters, etc.), amusement equipment, toy vehicles, etc. This application embodiment does not specifically limit the type of vehicle 00.

[0073] The vehicle 00 in this application embodiment can be a traditional fuel vehicle; or a new energy vehicle, such as a pure electric vehicle, a plug-in hybrid electric vehicle, a range-extended electric vehicle, a fuel cell vehicle, a hydrogen internal combustion engine vehicle, or a supercapacitor vehicle, etc.

[0074] For example, Figure 2 This is a schematic diagram of a disaster early warning system based on a domain-centralized architecture, provided in an embodiment of this application.

[0075] like Figure 2 As shown, a disaster early warning system may include various sensors installed in the perception layer, such as temperature sensors, smoke sensors, water level sensors, vibration sensors, cameras, and infrared thermal imagers. These sensors are used to collect monitoring data of the vehicle's interior and surrounding environment. This application does not limit the types and number of sensors used to collect monitoring data.

[0076] The disaster early warning system may include a BDC / VDC located in the vehicle body domain, and a CDC and risk mutual assistance switch module located in the cabin domain. The BDC / VDC is the core unit for vehicle status detection and determining vehicle wake-up and sleep conditions. Its constant power supply circuit can operate continuously at low power after the vehicle is parked, monitoring all wake-up sources such as door locks, keys, and various environmental sensors in real time, and uniformly managing the timing of vehicle power-on wake-up and power-off sleep. For example, after the vehicle enters the parking state, the BDC / VDC periodically acquires monitoring data collected by sensors, such as temperature, water level, gas concentration, images, and displacement values. When one or more of these data reach the early warning threshold, it sends a wake-up signal (also called a CAN signal) to the CDC via the CAN bus to wake up the CDC. The CDC reads the status of the risk mutual assistance switch from the risk mutual assistance switch module and executes the processing action corresponding to the status of the risk mutual assistance switch. The risk mutual assistance switch is a newly added function switch in this embodiment, used by the user to independently enable or disable the vehicle-to-vehicle cooperative early warning function. The "status of the risk mutual assistance switch" determines whether the vehicle-to-vehicle cooperative early warning function is enabled. If the "Risk Mutual Assistance Switch Status" is on, the CDC can activate the vehicle-to-vehicle cooperative warning function, broadcasting its own monitoring data and receiving monitoring data from surrounding vehicles. This allows the CDC to jointly determine a disaster using monitoring data from other vehicles parked in the same environment. If the "Risk Mutual Assistance Switch Status" is off, the CDC can disable the vehicle-to-vehicle cooperative warning function and use a single-vehicle warning mode, meaning it only uses the monitoring data collected by its own vehicle to determine a disaster.

[0077] The disaster early warning system may also include a communication module set up at the execution layer. After the CDC activates the vehicle-to-vehicle cooperative early warning function, the CDC can send control commands to the vehicle's communication module. The vehicle's communication module is used to broadcast its monitoring data to surrounding vehicles, receive monitoring data from the communication modules of surrounding vehicles, and report the monitoring data of surrounding vehicles to the vehicle's CDC. As an example, the communication module set up between different vehicles can adopt wireless communication methods, such as Bluetooth, Spark Link, Near Field Communication (NFC), ZigBee, Radio Frequency Identification (RFID), Ultra Wide Bandwidth (UWB), Wireless Fidelity (Wi-Fi), and other future types of short-range communication technologies. This application does not limit the wireless communication method used by the communication module. It is understood that, compared with wired communication methods, wireless communication between vehicles does not have the limitations of wiring harness docking and interface matching, and is suitable for disaster synchronous early warning in scenarios involving existing vehicles and mixed parking of multiple vehicle models.

[0078] The disaster early warning system may also include an audible and visual alarm module located at the execution layer. After the CDC generates safety warning level information based on monitoring data collected by the vehicle and / or monitoring data of surrounding vehicles, the CDC sends control commands to the audible and visual alarm module. The audible and visual alarm module is used to respond to the control commands and output warning information in the form of sound and light.

[0079] The above embodiments are illustrated using a domain-centralized architecture where the BDC / VDC is the core unit for vehicle status detection, vehicle wake-up, and sleep condition determination. In a distributed architecture, there is no BDC / VDC domain controller; the basic BCM body control module undertakes the functions of vehicle wake-up, sleep, and vehicle status monitoring, while various independent ECUs in the cockpit only perform local device management. In the CC architecture, the vehicle sleep / wake-up strategy is migrated to the central computing unit, and each regional controller undertakes the original BDC local signal acquisition and wake-up source hard-wired detection.

[0080] For example, Figure 3 This is a schematic diagram of a vehicle-to-vehicle near-field communication scenario provided in an embodiment of this application.

[0081] In vehicle-to-vehicle near-field communication scenarios, each vehicle can be configured with, for example... Figure 2 The disaster early warning system shown. (As shown in the image) Figure 3 As shown, vehicles A, B, and C may each include a BDC / VDC located in the body domain, a CDC located in the cockpit domain, and a communication module located in the execution layer. The specific functions of each module can be found in the description of the above embodiments.

[0082] One scenario is as follows: In a parking lot, vehicles A and B have their vehicle-to-vehicle (V2V) cooperative warning functions enabled, while vehicle C does not. When vehicle A's sensors experience abnormal interference and the monitored data reaches the warning threshold, vehicle A's BDC / VDC wakes up its CDC and broadcasts a message via its communication module. Vehicle B receives and verifies the message, then sends back normal monitoring data to vehicle A. Vehicle A's CDC combines the monitoring data from both vehicles A and B to complete the verification and determines it to be a false alarm. Vehicle C's communication module does not listen to or respond to external messages, maintaining independent single-vehicle monitoring and not interfering with other vehicles.

[0083] Another scenario is that all buses in a city are equipped with communication modules. At night, the fleet is concentrated at a bus depot, and all vehicles have their risk mitigation switch on by default. When a fire breaks out in the passenger compartment of one vehicle, the smoke sensor data reaches the warning threshold and activates the CDC (Disaster Warning Center). The CDC then controls the communication module to simultaneously broadcast a fire warning message. Sensors in adjacent vehicles simultaneously detect the anomaly and broadcast fire warning messages. All vehicles receive and verify these messages. After verification by multiple vehicles, if it is determined to be a real, contiguous disaster, all vehicles trigger a high-decibel audible and visual alarm, achieving joint prevention and control at the depot. After the emergency is resolved, the vehicles' disaster warning system returns to dormancy.

[0084] It should be noted that in vehicle-to-vehicle near-field communication scenarios, the vehicles can be manufactured by the same manufacturer or different manufacturers; they can use the same architecture or different architectures; and they can be fuel-powered vehicles or new energy vehicles. Vehicles distributed within the same parking area, if they support vehicle-to-vehicle collaborative early warning functions and have their risk mutual assistance switch activated, can interact with the communication modules of other vehicles through their own communication modules to exchange the monitoring data they have collected, and carry out joint multi-vehicle disaster verification operations, without being restricted by manufacturer, vehicle model, or electronic and electrical architecture isolation.

[0085] The following example uses a domain-centralized architecture to illustrate how to execute the disaster early warning method provided in this application based on BDC and CDC. It can be understood that the disaster early warning method provided in this application is also applicable to distributed architectures, central computing architectures, or other future vehicle architectures. In addition, BDC can be replaced by body-type controllers such as VDC, Body Super Core, or domain controllers, and CDC can be replaced by cockpit-type controllers such as MGU, Cockpit Super Core, or central computing unit.

[0086] The disaster early warning method provided in this application embodiment can be applied to, for example... Figure 2 The disaster early warning system shown or other disaster early warning systems. For example... Figure 2As shown, the disaster early warning system may include a disaster warning system (BDC) and a disaster warning system (CDC). The BDC and CDC can be implemented in hardware or a combination of software and hardware to realize the disaster early warning method provided in this application embodiment, and this application embodiment does not impose any restrictions on this.

[0087] For example, Figure 4 This is a flowchart illustrating a disaster early warning method provided in an embodiment of this application.

[0088] like Figure 4 As shown, the method may include the following steps S101 to S107.

[0089] S101, BDC detects vehicle status.

[0090] Vehicles can be categorized into wake-up state / mode and sleep state / mode.

[0091] If the system detects that the vehicle has switched from wake-up mode to sleep mode, then steps S102 to S107 can be executed. It is understood that after the vehicle is parked, the occupants leave the vehicle and lock the doors, and the disaster warning system can provide safety protection for the entire vehicle by executing the following steps.

[0092] If the vehicle is detected to switch from sleep mode to wake-up mode, then the execution of S102 to S107 below can be stopped / disabled. It is understood that when the vehicle is in wake-up mode, the driver and passengers are usually inside the vehicle and can consciously detect the existence of vehicle safety risks, or the vehicle can execute the warning mechanism in wake-up mode.

[0093] S102, BDC periodically acquires sensor data.

[0094] In this embodiment, the sleep state can be divided into shallow sleep mode and deep sleep mode. Shallow sleep mode refers to a conventional low-power mode / operating state designed for vehicle controllers (such as BDC). Deep sleep mode refers to an extremely low-power operating mode / operating state designed for vehicle controllers (such as CDC). The power consumption of deep sleep mode is less than that of shallow sleep mode.

[0095] Sensors can only perceive the environment and output raw physical signals; they lack timed reading, data processing, and transmission capabilities. BDC (Battery Controller) possesses timed scheduling, signal reading, and data parsing capabilities. When the vehicle enters a sleep state, the BDC is in a shallow sleep state, periodically and actively reading the raw signals output by various sensors and completing signal conversion and data preprocessing. This process can be described as the BDC periodically acquiring sensor data or cyclically collecting sensor data.

[0096] As an example, sensor data may include at least one of the following: temperature value, temperature change value, smoke concentration value, water level value, light radiation band, volatile organic compound concentration value, image, and displacement value. This data can be acquired using temperature sensors, smoke sensors, water level sensors, vibration sensors, cameras, infrared thermal imagers, or other types of sensors located in different areas of the vehicle.

[0097] As an example, different types of sensor data correspond to different warning thresholds.

[0098] Taking fire monitoring scenarios as an example, BDC can periodically read data from temperature sensors, smoke sensors, flame sensors, and gas detection sensors. Among them, the temperature sensor can be a constant-temperature temperature sensor that triggers an alarm when the ambient temperature reaches a fixed set value (such as 60℃), a differential-temperature temperature sensor that monitors the rate of temperature rise per unit time, or a composite temperature sensor that combines constant-temperature and differential-temperature functions; the smoke sensor can be an ionization smoke sensor that uses radioactive materials to ionize the air inside the cavity, a photoelectric smoke sensor with a light-emitting tube and a photosensitive tube inside the cavity, or an aspirating smoke detector that draws air samples from the protected area through a pipeline network and sends them into a high-sensitivity detection cavity for analysis; the flame sensor can be an ultraviolet flame detector that detects the 185-260nm ultraviolet band emitted by the flame, an infrared flame detector that detects the unique carbon dioxide emission band (about 4.4μm) of the flame, or an ultraviolet / infrared composite flame detector that detects both ultraviolet and infrared bands simultaneously; the volatile organic compounds (VOC) can be a carbon monoxide sensor, a hydrogen sensor (hydrogen is released in the early stages of thermal runaway of lithium batteries), or a volatile VOC sensor, etc.

[0099] As an example, the data acquisition cycle of the BCM (Battery Management Center) can be determined by a combination of factors, including: using the vehicle's factory-calibrated baseline cycle as the normal sampling interval; dynamically adjusting based on the vehicle's remaining battery power, extending the acquisition cycle when the battery is low to reduce static power consumption; classifying disaster risk levels based on local sensor signals and shared monitoring data from surrounding vehicles, maintaining long-cycle sampling in low-risk scenarios, and automatically shortening the sampling cycle when abnormal vibrations, water accumulation signals, or cross-vehicle warning messages are detected to achieve high-frequency data acquisition. Furthermore, differentiated base cycles are set for disaster monitoring sensors such as water level and MEMS sensors compared to conventional body sensors such as door locks and lights, balancing disaster identification accuracy with overall vehicle parking energy consumption.

[0100] S103, BDC determines whether the sensor data has reached the warning threshold.

[0101] If the sensor data reaches the warning threshold, it is determined to be a suspected disaster, and the following S104 is executed to wake up the CDC which is in deep sleep mode. It is understood that the water level and vibration monitoring data collected by the vehicle through local sensors, after preliminary judgment by BDC, have characteristics that match the data of disasters such as floods and ground vibrations. However, relying solely on the limited data of a single vehicle cannot completely rule out environmental interference such as water splashing, and a reliable judgment has not yet been formed. Therefore, it is called a suspected disaster.

[0102] If the sensor data does not reach the warning threshold, it is determined to be in a state of no abnormality / safe monitoring, and the process returns to execute S101 and S102 as described above. It can be understood that when the sensor data does not reach the warning threshold, no suspected disaster signals with disaster characteristics are identified, and the current environment is directly determined to be in a normal monitoring state with no risk of flooding or vibration-related disasters, without the need for further multi-vehicle collaborative verification.

[0103] The phrase "sensor data reaches the warning threshold" can refer to a specific type of sensor data reaching its corresponding warning threshold. For example, when the water level exceeds the warning threshold, it indicates a potential risk of flooding. Similarly, when the temperature exceeds the warning threshold, it indicates a potential risk of fire. And when the geological vibration exceeds the warning threshold, it indicates a potential risk of earthquakes. Regardless of the type of disaster risk, it can potentially damage vehicles, necessitating a disaster assessment.

[0104] As one optional implementation, if the BDC determines that the sensor data has reached the warning threshold, then the BDC switches from shallow sleep mode to wake-up mode and starts core operations such as fault classification calculation and remote TBOX diagnosis. Alternatively, if the BDC determines that the sensor data has reached the warning threshold, then the BDC can also remain in shallow sleep mode to reduce power consumption.

[0105] Furthermore, the above embodiments are illustrated using the example of determining a suspected disaster if sensor data reaches a warning threshold, and do not limit the scope of this application. In another implementation, when multiple types of sensors are set up, the BDC can fuse data from multiple types of sensors and calculate the perception confidence level of the sensor data. If the perception confidence level reaches a threshold, it is determined to be a suspected disaster, and the following S104 is executed.

[0106] S104, BDC sends a wake-up signal to CDC.

[0107] After the vehicle switches from wake-up mode to sleep mode, the CDC enters deep sleep mode, shutting down most of its computational logic and cutting off most peripheral communication and drive interactions, maintaining only the minimum basic circuitry such as wake-up signal detection to reduce unnecessary power consumption. If sensor data reaches a warning threshold, indicating a potential disaster risk, the BDC can send a wake-up signal to the CDC to wake it from deep sleep mode and switch it to wake-up mode, executing steps S105 and S105 below. That is, the wake-up signal is used to wake up the CDC.

[0108] S105, after being woken up, the CDC broadcasts the vehicle's monitoring data through the communication module.

[0109] The monitoring data in S105 mentioned above refers to sensor data that has reached the warning threshold. Typically, only one or a few types of disasters may occur at the same time or within the same time period, and only one or a few types of sensor data may reach the warning threshold among multiple sensor data. The BDC can send only the sensor data that has reached the warning threshold to the CDC. This sensor data can be carried in the wake-up signal or sent independently. After being woken up, the CDC can send control commands to the vehicle's communication module. This communication module encapsulates the sensor data that has reached the warning threshold, generates a message, and broadcasts the disaster message wirelessly to alert surrounding vehicles of a suspected disaster.

[0110] In vehicle-to-vehicle cooperative communication scenarios, disaster messages can be encapsulated in a unified format to facilitate mutual identification between vehicles.

[0111] As an example, a disaster message may include the following information: ① Vehicle identification, used to uniquely identify a vehicle, such as the vehicle identification number (VIN).

[0112] ② The disaster type field is used to indicate the type of suspected disaster currently being monitored, such as flooding, vehicle fire, surrounding fire, and implementation.

[0113] ③ Local perception confidence score, used to assist surrounding vehicles in judging the disaster situation, such as the confidence score range of 0~100 points.

[0114] ④ Vehicle positioning information, used to indicate the vehicle's location, such as global positioning system (GPS) or BeiDou coordinates.

[0115] ⑤ Timestamp, used to mark the time when sensor data was collected.

[0116] ⑥ CRC checksum, used to resist wireless interference and prevent messages from being tampered with.

[0117] S106, the CDC receives monitoring data from surrounding vehicles via a communication module.

[0118] Nearby vehicles that have activated the risk mutual assistance switch can receive disaster messages through their respective communication modules. The communication modules can decapsulate and perform CRC checks on the disaster messages, and after passing the CRC check, report the valid data to their own controllers, such as CDC, BDC, or T-BOX. Additionally, the controllers of nearby vehicles can also broadcast their collected monitoring data through the communication modules.

[0119] Taking a CDC (Disaster Control Center) as an example, the CDCs of surrounding vehicles can obtain monitoring data matching the disaster type field and timestamp carried in the received disaster message. Then, the communication modules of the surrounding vehicles encapsulate the monitoring data matching the disaster type field and timestamp into a disaster message using a standardized format and broadcast the disaster message. The vehicle that initially broadcast the disaster message can then receive the disaster messages returned by the surrounding vehicles through its communication module, decapsulate the disaster message, perform CRC verification, and report the valid data to its own CDC after passing the CRC verification. Additionally, surrounding vehicles can also determine the disaster based on their own monitoring data and the monitoring data of surrounding vehicles, as described in S107 below, which will not be repeated here.

[0120] As an example, in an underground parking lot, vehicles activate a risk mutual assistance switch and uniformly use CRC-16 verification rules. If surrounding wireless noise or external devices send tampered or incomplete messages, the vehicle's communication module, after completing the CRC check, directly discards the abnormal message without reporting to the CDC or triggering an alert. Only messages with valid format and verification are used in the collaborative judgment process, thus achieving data anti-interference and anti-tampering.

[0121] The execution order of S105 and S106 is not limited in this embodiment. After the CDC is woken up, if the vehicle-to-vehicle cooperative warning function is enabled, the CDC allows the communication module to receive monitoring data from other vehicles. The order in which the vehicle sends monitoring data and the order in which it receives monitoring data from other vehicles can be executed sequentially or synchronously.

[0122] S107, the CDC makes a disaster assessment based on the monitoring data of this vehicle and the monitoring data of surrounding vehicles.

[0123] The CDC can integrate and cross-compare the monitoring data of the vehicle itself with the monitoring data of surrounding vehicles.

[0124] If the cross-comparison result shows that only the monitoring data of this vehicle is abnormal (only the monitoring data of this vehicle reaches the warning threshold), then the CDC can determine that it is due to environmental interference, perform silent suppression, and retain the log. "Perform silent suppression" means that the CDC will not send control commands to the audible and visual alarm module, thus preventing the audible and visual alarm module from performing alarm operations.

[0125] If the monitoring data of multiple vehicles are abnormally synchronized (the monitoring data of multiple vehicles reaches the warning threshold), the CDC can determine it as a real disaster and then generate safety warning level information based on structured data. Different safety warning levels trigger the audible and visual alarm module to perform different alarm operations. Here, "abnormal synchronization of monitoring data of multiple vehicles" means that not only is the monitoring data of this vehicle abnormal, but the monitoring data received by this vehicle from at least one surrounding vehicle is also abnormal.

[0126] After the process is completed, the CDC sends a command (which can be called a third command) to the communication module, and the communication module returns to low-frequency broadcast mode; the CDC then resumes deep sleep mode. These modules returning to sleep state can reduce the overall vehicle power consumption.

[0127] In a specific scenario, multiple vehicles may be present around the vehicle. The monitoring data of some of these vehicles may show anomalies, while the monitoring data of others may not. In this case, the vehicle can work with the surrounding vehicles to collect more data to assist in disaster assessment. Alternatively, the vehicle can use its location information to increase the confidence level of the monitoring data of vehicles closer to it and decrease the confidence level of the monitoring data of vehicles farther away. Then, a comprehensive confidence level can be calculated based on the confidence levels of all the monitoring data. Finally, the warning level can be determined based on the comprehensive confidence level.

[0128] As an example, the relationship between safety warning levels and vehicle actions follows the principle of "tiered warning and step-by-step response." Taking a fire scenario as an example, the CDC can monitor the risk of thermal runaway through sensors and visual information, and trigger different levels of warnings and corresponding automated measures based on the severity of the risk.

[0129] For example, Table 1 below shows the correspondence between security warning level information and the actions to be performed.

[0130] Table 1

[0131] In the disaster early warning method provided in this application embodiment, after the vehicle enters the parking state, the BDC periodically acquires sensor data and wakes up the CDC after the sensor data reaches the early warning threshold. The CDC broadcasts its own monitoring data and receives monitoring data from surrounding vehicles, thereby jointly completing the disaster determination by using the monitoring data of other vehicles in the same parking environment. This method relies on the environmental monitoring data collected synchronously by multiple vehicles in the same parking area to carry out collaborative joint verification, which can realize cross-comparison and mutual corroboration of monitoring information between vehicles, effectively filter out various environmental interference signals such as light, dust, and short-term weather fluctuations, accurately distinguish interference sources from real disaster characteristics, greatly suppress the occurrence of false disaster early warnings, and significantly improve the accuracy of disaster event identification and early warning output.

[0132] In the above embodiments, after the CDC receives the wake-up signal from the BDC, it directly activates the vehicle-to-vehicle cooperative warning function, broadcasting the vehicle's monitoring data to surrounding vehicles. However, in some scenarios, users may not want their vehicle to broadcast its monitoring data for various reasons. Based on this requirement, this application embodiment also provides a risk assistance switch. This risk assistance switch can be a physical button or a virtual soft switch on the vehicle's infotainment system. Users can independently activate or deactivate the vehicle-to-vehicle cooperative warning function as needed.

[0133] For example, Figure 5 This is a flowchart illustrating another disaster early warning method provided in an embodiment of this application.

[0134] and Figure 4 The difference between the disaster early warning methods shown lies in the fact that, for Figure 5 The disaster early warning method shown may further include S108 before S105 to S107. After S108, the method may further include S109 to S110. S105 to S107 and S109 to S110 are two parallel branches.

[0135] S108, CDC reads the status of the risk mutual assistance switch.

[0136] The “risk mutual assistance switch” is a new function switch added in this application embodiment, which is used for users to independently turn on or off the vehicle-to-vehicle cooperative warning function.

[0137] The "Risk Mutual Assistance Switch Status" is a static value used to determine whether the vehicle-to-vehicle cooperative warning function is enabled.

[0138] After the vehicle enters a sleep state, the "risk mutual assistance switch status" can be synchronized to the vehicle network in real time. After the CDC wakes up from deep sleep mode, it can read the "risk mutual assistance switch status".

[0139] If the "risk mutual assistance switch status" is on, then the CDC can activate the vehicle-to-vehicle cooperative warning function and send an instruction (which may be called the first instruction) to the communication module. The communication module then responds to the instruction by broadcasting the monitoring data of its own vehicle and receiving the monitoring data of surrounding vehicles, that is, executing S105 to S107 of the above embodiment.

[0140] If the "risk mutual assistance switch status" is off, the CDC can disable the vehicle-to-vehicle cooperative warning function and send a command (referred to as the fourth command) to the communication module. The communication module then responds to this command by ceasing to send and receive monitoring data, thus reducing the power consumption of the communication module. Alternatively, the CDC can adopt a single-vehicle warning mode, meaning it only uses the monitoring data collected by the vehicle itself to complete the disaster determination, i.e., executing steps S109 to S110 of the following embodiment.

[0141] S109, CDC integrates the data from this vehicle.

[0142] The difference between S107 and S109 is as follows: In S107, the CDC merges the monitoring data of the vehicle itself with the monitoring data of surrounding vehicles, and the monitoring data of the vehicle itself and the monitoring data of surrounding vehicles are included in one or more sensor data collected at the same time or time period; In S109, the CDC only merges the data of the vehicle itself, and the data of the vehicle itself may be included in one or more sensor data collected at a time or time period.

[0143] S110, the CDC determines whether a disaster is real based on the merged data.

[0144] In the event of a real disaster, the CDC generates safety warning level information based on the fused data. Different safety warning levels are used to trigger different alarm operations by the audible and visual alarm modules.

[0145] If it is not an actual disaster, then the CDC logs a warning.

[0146] After the process is completed, the communication module returns to low-frequency broadcast mode, and the CDC resumes deep sleep mode.

[0147] One scenario is a recreational vehicle (RV) parked long-term at a suburban campsite. The user can set the risk-assistance switch to "off." During parking, the Bluetooth module is in deep sleep, with no broadcasting or listening activity, minimizing overall vehicle power consumption. When an electrical malfunction causes abnormal temperature, and sensor data reaches the warning threshold, the BCM (Browser Control Center) wakes up the CDC (Digital Control Center). The CDC reads that the "risk-assistance switch status" is off, disables vehicle-to-vehicle communication, and determines the fire situation and triggers a local alarm based solely on individual vehicle data. No data is transmitted externally throughout the process, balancing low power consumption and privacy protection.

[0148] It should be noted that the aforementioned risk mutual assistance switch is only used for vehicles in parked / dormant states. While the vehicle is in motion, regardless of the switch's status, vehicle-to-vehicle coordination and multi-vehicle verification functions are all disabled, and the original vehicle warning system operates according to traditional logic. The risk mutual assistance switch only becomes active after the vehicle has completed parking lockout and the occupants have left the vehicle, strictly distinguishing between driving and parking conditions.

[0149] In the disaster early warning method provided in the embodiments of this application, a risk mutual assistance switch is added. The CDC reads the status of the risk mutual assistance switch after being woken up, thereby controlling the start and stop of vehicle-to-vehicle collaborative data interaction, realizing manual switching of the early warning mode, and being compatible with user privacy protection and power consumption.

[0150] In the above embodiment, the CDC is in deep sleep mode before receiving the wake-up signal from the BDC. In this way, the CDC cannot obtain the monitoring data of other vehicles through the communication module, nor can it broadcast its own monitoring data to other vehicles. As a result, other vehicles are not clear whether they did not receive the monitoring data because there were no vehicles around, or because the surrounding vehicles did not wake up the CDC.

[0151] One scenario is as follows: In a highway service area, vehicles A, B, and C are all in sleep mode. The CDC (Distributed Damping Controller) of vehicles A, B, and C is in deep sleep mode. The BCM (Body Control Controller) of vehicles A, B, and C periodically collects data. Rainfall causes water to briefly splash into vehicle A, causing its water level sensor to momentarily reach the warning threshold, waking up the CDC. The CDC of vehicle A reads that the risk mutual assistance switch is in the "on" state and controls the Bluetooth module to broadcast a fire information message carrying CRC-16 verification. The water level sensors of vehicles B and C do not reach the warning threshold and do not wake up their CDCs, thus not returning monitoring data to vehicle A. Without monitoring data from vehicles B and C as supplementary information, vehicle A may falsely trigger its audible and visual alarms.

[0152] Another scenario involves a batch of smart cars equipped with various sensors for smoke, temperature, water level, and vibration parked in a car manufacturer's new vehicle parking lot. Dust and ground vibrations may cause a few vehicles to momentarily exceed sensor limits. The body domain controllers of these vehicles activate the central computing unit, which reads that the switch is on and controls the communication module to broadcast a comprehensive anomaly message. Other vehicles not affected by dust or ground vibrations do not reach the warning threshold and will not activate the central computing unit, thus not broadcasting monitoring data. Relying solely on the monitoring data of a few vehicles may lead to inaccurate joint judgments and false triggering of audible and visual alarms.

[0153] Another scenario involves a heavy-duty van temporarily parked at a highway service area. The driver leaves the vehicle to rest, and the risk mitigation switch is activated. When the temperature sensor detects abnormally high temperatures, the BCM wakes up the CDC, which then instructs the StarFlash module to broadcast a disaster message. Since no other vehicles are parked at the service area, this van does not receive monitoring data from other vehicles. The CDC mistakenly assumes that the monitoring data from surrounding vehicles is normal and therefore does not receive any data, leading to a false alarm and thus compromising vehicle safety.

[0154] To address the aforementioned issues, this application also provides another disaster early warning method. After a vehicle enters a dormant state, it broadcasts its risk mutual assistance capability to other vehicles via a communication module. By broadcasting their own risk mutual assistance capabilities, vehicles within the same area can easily determine whether other vehicles with such capabilities are nearby. This facilitates disaster assessment based on whether monitoring data from these vehicles is subsequently received.

[0155] The following example illustrates the risk mutual assistance capabilities of vehicles A, B, and C parked in the same area. Vehicles A and B acquire sensor data that reaches the warning threshold, while vehicle C acquires sensor data that does not. Figures 6 to 9 The implementation of the disaster early warning method provided in the embodiments of this application is illustrated by examples.

[0156] For example, Figure 6 This is a flowchart illustrating the disaster early warning method performed by vehicle A in an embodiment of this application.

[0157] like Figure 6 As shown, the method may include the following steps S201 to S214.

[0158] S201, Vehicle A's BDC detects the status of Vehicle A.

[0159] If vehicle A is detected to switch from wake-up mode to sleep mode, then the following steps S202 to S203 and S204 to S205 can be executed in parallel.

[0160] If vehicle A is detected to switch from sleep mode to wake-up mode, then the following steps 202 to S203 and S204 to S205 can be stopped / disabled.

[0161] The implementation of S201 is similar to that of S101 in the above embodiment, and will not be described again here.

[0162] S202, Vehicle A's BDC sends a control command to the communication module, which is used to instruct the broadcast vehicle A's risk mutual assistance capability.

[0163] When vehicle A switches from hibernation mode to wake-up mode, the CDC enters deep hibernation mode, cutting off interaction with the communication module, while the BDC enters shallow hibernation mode, preserving the basic signal path. Therefore, the BDC sends control commands to the communication module to broadcast that vehicle A has risk mutual assistance capabilities.

[0164] S203, the communication module of vehicle A broadcasts the first information according to the first cycle. The first information is used to indicate that the vehicle has the ability to help each other in case of risk.

[0165] The aforementioned communication module is equipped with two communication modes: low-frequency broadcast mode and high-frequency broadcast mode. In low-frequency broadcast mode, the communication module uses a low-frequency, intermittent wireless broadcast mechanism, such as transmitting signals according to a first cycle. In high-frequency broadcast mode, the communication module uses a high-frequency, continuous broadcast mechanism, such as transmitting signals according to a second cycle. The second cycle is shorter than the first cycle.

[0166] As an example, the first cycle is 1 minute and the second cycle is 1 second; or, the first cycle is 5 minutes and the second cycle is 2 seconds; or, the first cycle is 10 minutes and the second cycle is 0.1 seconds. In actual implementation, other values ​​can also be used for the first and second cycles.

[0167] While vehicle A's communication module broadcasts its risk mutual assistance capability in the first cycle, if there are other vehicles around vehicle A, vehicle A's communication module can also receive broadcast information from other vehicles with risk mutual assistance capability (such as vehicle B and vehicle C) and forward it to vehicle A's BDC, so that vehicle A can know whether there are vehicles with risk mutual assistance capability around it.

[0168] S204, Vehicle A's BDC periodically acquires sensor data.

[0169] S205, Vehicle A's BDC determines whether the sensor data has reached the warning threshold.

[0170] If the sensor data reaches the warning threshold, it is determined to be a suspected disaster, and the following S206 is executed.

[0171] If the sensor data does not reach the warning threshold, it is determined to be in a state of no abnormality / safety monitoring, and the process returns to execute S201 above.

[0172] The implementation methods of S204 to S205 are similar to those of S102 to S103 in the above embodiments, and will not be described again here.

[0173] S206, Vehicle A's BDC sends a wake-up signal to the CDC.

[0174] If the sensor data reaches the warning threshold, it indicates that there may be a disaster risk. Vehicle A's BDC can send a wake-up signal to Vehicle A's CDC to wake up the CDC from deep sleep mode.

[0175] As an example, the wake-up signal can carry vehicles with risk mutual assistance capabilities (such as vehicle B and vehicle C).

[0176] S207, after being woken up, the CDC enables the vehicle-to-vehicle cooperative warning function.

[0177] After the vehicle-to-vehicle cooperative warning function is enabled, vehicle A can share monitoring data with other vehicles. For example, vehicle A can broadcast its monitoring data to other vehicles through the communication module (i.e., execute S208 to S209 below), and receive monitoring data from surrounding vehicles (such as vehicle B with the vehicle-to-vehicle cooperative warning function enabled) through the communication module.

[0178] S208, the CDC of vehicle A sends a control command to the communication module, which instructs the broadcasting of monitoring data from vehicle A.

[0179] S209, Vehicle A's communication module broadcasts vehicle A's monitoring data according to the second cycle. The second cycle is shorter than the first cycle.

[0180] The implementation methods of S208 to S209 are similar to the implementation method of S105 in the above embodiment, and will not be described again here.

[0181] S210, the CDC of vehicle A determines whether there is a vehicle with risk mutual assistance capability.

[0182] If the wake-up signal does not carry a vehicle with risk mutual assistance capability, it means that there are no vehicles with risk mutual assistance capability around vehicle A, and the measurement data of other vehicles cannot be used to assist in assessing the disaster situation, thus executing S211 below.

[0183] If the wake-up signal carries a vehicle with risk mutual assistance capability (such as vehicle B or vehicle C), it means that there are vehicles with risk mutual assistance capability around vehicle A. The measurement data of other vehicles can be used to assist in assessing the disaster situation, thereby executing S212 below.

[0184] S211, Vehicle A's CDC determines the disaster level based on the vehicle's sensor data.

[0185] The CDC can employ a single-vehicle early warning mode, making disaster assessments based solely on monitoring data collected by the vehicle itself. Additionally, the CDC can send instructions (referred to as a second instruction) to the communication module, instructing it to cease transmitting and receiving monitoring data to reduce power consumption.

[0186] The implementation of S211 is similar to that of S109 to S110 in the above embodiments, and will not be described again here.

[0187] S212, Vehicle A's CDC determines whether it has received monitoring data from other vehicles.

[0188] If vehicle A's CDC determines that there are vehicles with risk mutual assistance capabilities in the vicinity, but does not receive monitoring data from these vehicles, it means that the monitoring data from the surrounding vehicles has not reached the warning threshold and therefore the CDC has not been activated. In this case, the CDC can directly determine it as environmental interference, perform silent suppression, and retain the log, i.e., execute S213 below.

[0189] If the CDC of vehicle A determines that there are vehicles with risk mutual assistance capabilities in the vicinity, and receives monitoring data from surrounding vehicles (such as vehicle B with vehicle-to-vehicle cooperative early warning function enabled) through the communication module, then it can assist other vehicles in assessing the disaster situation by measuring the data, that is, to execute S214 below.

[0190] S213, Vehicle A's CDC performs silent suppression.

[0191] S214, Vehicle A's CDC makes a disaster assessment based on its own monitoring data and the monitoring data of surrounding vehicles.

[0192] After the warning action is completed, the CDC of vehicle A sends a command to the communication module, instructing the communication module to return to the low-frequency broadcast mode. Subsequently, the CDC of vehicle A enters deep sleep mode, and the disaster warning system returns to sleep state.

[0193] The implementation of S214 is similar to that of S107 in the above embodiment, and will not be described again here.

[0194] In the method provided in this application embodiment, vehicles A, B, and C parked in the same area broadcast their own risk mutual assistance capabilities, facilitating mutual determination among the vehicles to identify whether there are other vehicles with risk mutual assistance capabilities in their vicinity. After vehicle A activates the vehicle-to-vehicle cooperative early warning function, the risk early warning method can be optimized based on the known vehicles with risk mutual assistance capabilities and the received monitoring data, further improving the accuracy of disaster event identification and the accuracy of early warning output.

[0195] The above embodiments are implemented through Figure 6 Sections S201 to S214 describe the process by which vehicle A implements the disaster warning method. Figure 7 This is a schematic flowchart illustrating the disaster early warning method implemented by vehicle B according to an embodiment of this application. Figure 7 As shown, the method may include S301 to S314. The implementation of S301 to S314 is similar to that of S201 to S214, and will not be described again. Figure 6 and Figure 7 The difference is: in Figure 6 In the middle, vehicle A broadcasts that it has the capability to mutually assist in risk management, and receives broadcast information from vehicles B and C that they also have the capability to mutually assist in risk management; Figure 7 In the middle, vehicle B broadcasts that it has the ability to help each other with risks, and receives broadcast information from vehicles A and C that they also have the ability to help each other with risks.

[0196] The following is through Figure 8 , Figure 9 This document presents flowcharts illustrating two methods for implementing disaster early warning systems using vehicle C.

[0197] like Figure 8 As shown, the method may include the following steps S401 to S409.

[0198] like Figure 9 As shown, the method may include the following steps S401 to S405.

[0199] Figure 8 and Figure 9 The similarities are that both vehicles C broadcast their own risk mutual assistance capabilities, receive broadcast information from vehicles with mutual assistance capabilities, and periodically acquire sensor data, i.e., both perform the following S401 to S405. Figure 8 and Figure 9 The difference is: in Figure 8 In the meantime, if sensor data does not reach the warning threshold, the CDC remains in deep sleep mode, disabling vehicle-to-vehicle cooperative communication functions, and the communication module is prohibited from broadcasting its own vehicle's monitoring data; Figure 9 In the case where the sensor data does not reach the warning threshold, the vehicle-to-vehicle cooperative communication function is allowed to be activated to broadcast the vehicle's monitoring data, i.e., to execute the following S406 to S409.

[0200] S401, Vehicle C's BDC detects the vehicle's status.

[0201] If vehicle C is detected to switch from wake-up mode to sleep mode, then the following steps S402 to S403 and S404 to S405 can be executed in parallel.

[0202] If vehicle C is detected to switch from sleep mode to wake-up mode, then the following steps 202 to S403 and S404 to S405 can be stopped / disabled.

[0203] S402, the BDC of vehicle C sends a control command to the communication module, which is used to instruct the broadcast vehicle C's risk mutual assistance capability.

[0204] S403, Vehicle C's communication module broadcasts in the first cycle that the vehicle has risk mutual assistance capabilities.

[0205] While vehicle C's communication module broadcasts its risk mutual assistance capability in the first cycle, if there are other vehicles around vehicle C, vehicle C's communication module can also receive broadcast information from other vehicles with risk mutual assistance capability (such as vehicle A and vehicle B) and forward it to vehicle C's BDC, so that vehicle C can know whether there are vehicles with risk mutual assistance capability around it.

[0206] S404, Vehicle C's BDC periodically acquires sensor data.

[0207] S405, Vehicle C's BDC determines whether the sensor data has reached the warning threshold.

[0208] If the sensor data does not reach the warning threshold, it is determined to be in a state of no abnormality / safety monitoring, and the process returns to execute S401 as described above.

[0209] The implementation methods of S401 to S405 are similar to those of S301 to S305 in the above embodiments, and will not be described again here.

[0210] S406, if the sensor data does not reach the warning threshold, but monitoring data from other vehicles (such as vehicle A) is received, vehicle C's BDC sends a wake-up signal to the CDC.

[0211] Before the BDC of vehicle C sends a wake-up signal to the CDC, the CDC is in deep sleep mode, unable to acquire monitoring data from other vehicles (such as vehicle A), nor will it return monitoring data from vehicle C to other vehicles. To solve this problem, after the communication module of vehicle C receives monitoring data from other vehicles (such as vehicle A), it can report it to the BDC, which will then wake up the CDC via a wake-up signal.

[0212] S407, after being woken up, the CDC enables the vehicle-to-vehicle cooperative warning function.

[0213] After enabling the vehicle-to-vehicle cooperative warning function, vehicle C can share monitoring data with other vehicles. For example, vehicle C's monitoring data can be broadcast to other vehicles (such as vehicle A) through its communication module, i.e., S408 below is executed. As an optional implementation, after enabling the vehicle-to-vehicle cooperative warning function, if vehicle C's communication module continues to receive monitoring data from other vehicles, vehicle C's communication module can directly report the monitoring data to the CDC.

[0214] S408, the CDC of vehicle C sends a control command to the communication module, which instructs the broadcast of monitoring data from vehicle A.

[0215] S409, Vehicle C's communication module broadcasts vehicle A's monitoring data according to the second cycle. The second cycle is shorter than the first cycle.

[0216] Vehicles A, B, and C parked in the same area can broadcast their risk mutual assistance capabilities to each other, allowing them to know in advance whether there are other vehicles with risk mutual assistance capabilities in their vicinity. In a scenario where the sensor data acquired by vehicles A and B reaches the warning threshold, while the sensor data acquired by vehicle C does not, vehicle C's CDC can remain in deep sleep mode and not return its own monitoring data to other vehicles (such as vehicle A). Vehicle A assumes that vehicle C's monitoring data has not reached the warning threshold. Vehicle A fuses the monitoring data of vehicles A and B to determine whether to generate safety warning level information. When only monitoring data from vehicles A and B are acquired, there is a risk of false alarms. A preset algorithm can be used to appropriately reduce the confidence of the fusion result of vehicle A's monitoring data from vehicle B, and then compare it with the warning threshold. If the fusion result does not exceed the warning threshold, silent suppression is performed; if the fusion result exceeds the warning threshold, safety warning level information is generated. Alternatively, vehicle C's CDC can be woken up by BDC and return its own monitoring data to other vehicles (such as vehicle A). Vehicle A fuses the monitoring data of vehicles A, B, and C to generate safety warning level information, as described in S107 above, which will not be repeated here.

[0217] It is understandable that since vehicle C broadcasts its risk-sharing capability to other vehicles in advance, if vehicle C does not share its monitoring data with other vehicles when the sensor data it acquires does not reach the warning threshold, other vehicles can infer the reason why it did not share the monitoring data, thus facilitating other vehicles to make accurate disaster predictions.

[0218] It should be understood that Figures 1 to 9 The structural diagrams, flowcharts, or scenario diagrams shown are for illustrative purposes only and are not intended to limit the embodiments of this application to the examples illustrated. In fact, those skilled in the art can interpret them based on... Figures 1 to 9 The examples in the examples can be equivalently transformed to obtain more implementation methods. In the above embodiments, the steps can be executed in different orders as presented in each embodiment, and it is not necessary to execute all the operations in the embodiments of this application. Moreover, the order of the steps does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0219] Figure 10 This is a schematic block diagram of a communication device provided in an embodiment of this application. The communication device may be a chip, chip system, processor, BDC, CD, or disaster early warning system, etc., used in a device to implement the above-described methods. This communication device can be used to implement the methods described in the above-described method embodiments; for details, please refer to the descriptions in the above-described method embodiments.

[0220] like Figure 10 As shown, the communication device may include one or more processors 511, which may also be called processing units or processing modules, and can realize certain control functions.

[0221] In one possible implementation, the processor 511 may also store instructions and / or data, which can be executed by the processor 511 to cause the communication device to perform the methods described in the above method embodiments.

[0222] In another possible implementation, the communication device may include a communication interface 512 for implementing receiving and transmitting functions. For example, the communication interface 512 may be a transceiver circuit, interface, interface circuit, or transceiver. The transceiver circuit, interface, interface circuit, or transceiver for implementing receiving and transmitting functions may be separate or integrated. The aforementioned transceiver circuit, interface, interface circuit, or transceiver may be used for reading and writing code / data, or it may be used for transmitting or relaying signals.

[0223] The communication device may include one or more memories 513, which may store instructions that can be executed on the processor 511, causing the communication device to perform the methods described in the above method embodiments. Optionally, the memories 513 may also store data. Optionally, the processor 511 may also store instructions and / or data. The processor 511 and the memories 513 may be provided separately or integrated together.

[0224] It should be understood that, in one possible implementation, the steps in the method embodiments provided in this application can be completed by integrated logic circuits in the processor hardware or by instructions in software form. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0225] In one implementation, processor 511 can be used to execute instructions stored in memory 513, and when processor 511 executes instructions stored in memory, processor 511 is used to perform various steps and / or processes of the above method embodiments.

[0226] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory of the systems and methods described in this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0227] This application also provides a computer-readable storage medium storing a program that, when run on a computer, causes the computer to perform the above-described actions. Figures 4 to 9 The steps performed by BDC or CDC in the method described in the illustrated embodiment.

[0228] This application also provides a computer program product, which includes a program that, when run on a computer, causes the computer to perform the above-described actions. Figures 4 to 9 The steps performed by BDC or CDC in the method described in the illustrated embodiment.

[0229] This application embodiment also provides a circuit system, the circuit system including a processing circuit, the processing circuit being configured to perform the above-described... Figures 4 to 9 The steps performed by BDC or CDC in the method described in the illustrated embodiment.

[0230] The planning data acquisition device provided in this application embodiment can specifically be a chip. The chip includes a processing unit, such as a processor. Optionally, the chip also includes a communication unit, such as an input / output interface, pins, or circuits. The processing unit can execute computer execution instructions stored in the storage unit to cause the chip to perform the above-mentioned tasks. Figures 4 to 9 The method described in the illustrated embodiment. Optionally, the storage unit is an in-chip storage unit, such as a register, cache, etc. The storage unit can also be an external storage unit located in the wireless access device, such as a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, such as random access memory (RAM).

[0231] The processor mentioned above can be a general-purpose central processing unit, a microprocessor, an ASIC, or one or more integrated circuits used to control the execution of a program in the first aspect of the method.

[0232] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the accompanying drawings of the device embodiments provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0233] Through 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, and of course, it can also be implemented by special hardware including application-specific integrated circuits, special-purpose CLUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. 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 is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or 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 of the various embodiments of this application.

[0234] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0235] 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)).

Claims

1. A disaster early warning method, characterized in that, The method is applied to a first vehicle, the first vehicle including a body controller, a cockpit controller, and a communication module, the method comprising: After the first vehicle is parked, the body controller acquires the monitoring data of the first vehicle in shallow sleep mode, the cockpit controller detects the wake-up signal in deep sleep mode, and the communication module broadcasts first information in low-frequency broadcast mode. The first information is used to indicate that the first vehicle has the ability to share monitoring data. When the monitoring data of the first vehicle reaches the warning threshold, the body controller sends a wake-up signal to the cockpit controller. The cockpit controller responds to the wake-up signal by switching from the deep sleep mode to the normal operation mode and sends a first command to the communication module; The communication module responds to the first instruction by switching from the low-frequency broadcast mode to the high-frequency broadcast mode, and broadcasts the monitoring data of the first vehicle in the high-frequency broadcast mode. The monitoring data of the first vehicle is used for disaster early warning. The power consumption of the deep sleep mode is less than that of the normal operation mode, the power consumption of the shallow sleep mode is less than that of the normal operation mode, and the power consumption of the low-frequency broadcast mode is less than that of the high-frequency broadcast mode.

2. The method according to claim 1, characterized in that, After the communication module switches from the low-frequency broadcast mode to the high-frequency broadcast mode in response to the first instruction, the method further includes: The communication module receives monitoring data from the second vehicle; The cockpit controller provides disaster warnings based on monitoring data from the first vehicle and the second vehicle.

3. The method according to claim 2, characterized in that, The cockpit controller provides disaster warnings based on monitoring data from the first vehicle and the second vehicle, including: If the monitoring data of the second vehicle does not reach the warning threshold, the cockpit controller will not trigger an alarm operation; When the monitoring data of the second vehicle reaches the warning threshold, the cockpit controller generates safety warning level information based on the monitoring data of the first vehicle and the monitoring data of the second vehicle. The safety warning level information is used to trigger an alarm operation.

4. The method according to claim 2, characterized in that, The method further includes: the communication module receiving second information from other vehicles in the low-frequency broadcast mode, and forwarding the second information to the body control controller, the second information indicating that the other vehicles have the ability to share monitoring data, the other vehicles including the second vehicle, and the wake-up signal carrying vehicle information that has the ability to share monitoring data; The cockpit controller performs disaster early warning based on the monitoring data of the first vehicle and the monitoring data of the second vehicle, including: the cockpit controller performs disaster early warning based on the vehicle information, the monitoring data of the first vehicle and the monitoring data of the second vehicle.

5. The method according to claim 4, characterized in that, After the body-type controller sends a wake-up signal carrying the vehicle information to the cockpit-type controller, the method further includes: If the cockpit controller does not receive monitoring data from the other vehicles through the communication module, the cockpit controller will not trigger an alarm operation.

6. The method according to claim 4, characterized in that, The method further includes: If the communication module does not receive the second information, after the vehicle body controller wakes up the cockpit controller, the cockpit controller sends a second instruction to the communication module and performs a disaster warning based on the monitoring data of the first vehicle. The second instruction is used to instruct the communication module to stop sending and receiving monitoring data.

7. The method according to claim 4, characterized in that, The cockpit controller performs disaster early warning based on the vehicle information, the monitoring data of the first vehicle, and the monitoring data of the second vehicle, including: If the vehicle information indication includes the second vehicle and the third vehicle, and the communication module does not receive monitoring data from the third vehicle, the cockpit controller determines that the monitoring data of the third vehicle has not reached the warning threshold, and determines whether to trigger an alarm operation based on the fusion result of the monitoring data of the first vehicle and the monitoring data of the second vehicle. When the vehicle information indication includes the second vehicle and the third vehicle, and the communication module receives monitoring data from the third vehicle, the cockpit controller performs a disaster warning based on the monitoring data of the first vehicle, the monitoring data of the second vehicle, and the monitoring data of the third vehicle.

8. The method according to any one of claims 2 to 7, characterized in that, The method further includes: After the alarm operation is completed, the cockpit controller sends a third instruction to the communication module, and the cockpit controller returns to the deep sleep mode. The third instruction is used to instruct the communication module to return to the low-frequency broadcast mode.

9. The method according to any one of claims 1 to 8, characterized in that, Before the cockpit controller sends the first instruction to the communication module, the method further includes: The cockpit controller reads the status of the risk mutual assistance switch, which is used to turn the shared monitoring data function on or off. When the risk mutual assistance switch is in the on state, the cockpit controller enables the shared monitoring data function. The shared monitoring data includes sending monitoring data and receiving monitoring data.

10. The method according to claim 9, characterized in that, After the cabin controller reads the risk mutual assistance switch, the method further includes: When the risk mutual assistance switch is in the off state, the cockpit controller sends a fourth instruction to the communication module and performs a disaster warning based on the monitoring data of the first vehicle. The fourth instruction is used to instruct the communication module to stop sending and receiving monitoring data.

11. The method according to any one of claims 1 to 10, characterized in that, The broadcast period of the first information is the first period, and the period of the monitoring data of the first vehicle is the second period, which is shorter than the first period.

12. The method according to any one of claims 1 to 11, characterized in that, The monitoring data of the first vehicle is encapsulated into a disaster message, which includes at least one of the following pieces of information: Vehicle markings are used to identify vehicles; The disaster type field is used to indicate the type of suspected disaster detected; Local perception confidence is used to assist surrounding vehicles in assessing the disaster situation; Vehicle location information, used to indicate the vehicle's location; A timestamp is used to mark the time when monitoring data was collected. CRC checksum.

13. The method according to any one of claims 1 to 12, characterized in that, The method further includes: If the monitoring data of the first vehicle does not reach the warning threshold, and the communication module receives monitoring data from other vehicles, the body controller sends the wake-up signal to the cockpit controller; the cockpit controller responds to the wake-up signal by switching from the deep sleep mode to the normal operation mode and sends the first instruction to the communication module; the communication module responds to the first instruction by switching from the low-frequency broadcast mode to the high-frequency broadcast mode and broadcasts the monitoring data of the first vehicle in the high-frequency broadcast mode.

14. A vehicle body control system, characterized in that, The vehicle control system includes a body controller, a cockpit controller, and a communication module; The vehicle body controller is used to acquire monitoring data of the first vehicle in a shallow sleep mode after the vehicle is parked; and to send a wake-up signal to the cockpit controller when the monitoring data of the first vehicle reaches the warning threshold. The cockpit controller is used to detect a wake-up signal in deep sleep mode after the vehicle is parked; and in response to the detected wake-up signal, to switch from deep sleep mode to normal operation mode, to send a first instruction to the communication module. The communication module is used to broadcast first information in low-frequency broadcast mode after the vehicle is parked, the first information indicating that the first vehicle has the ability to share monitoring data; In response to the first instruction, the system switches from the low-frequency broadcast mode to the high-frequency broadcast mode, broadcasting the monitoring data of the first vehicle in the high-frequency broadcast mode. The monitoring data of the first vehicle is used for disaster early warning. The power consumption of the deep sleep mode is less than that of the shallow sleep mode, the power consumption of the shallow sleep mode is less than that of the normal operation mode, and the power consumption of the low-frequency broadcast mode is less than that of the high-frequency broadcast mode.

15. A vehicle, characterized in that, The vehicle includes the body control system as described in claim 14.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 13.

Images