Vehicle danger monitoring system

By installing a hazard monitoring system in vehicles, and using sensor data and algorithms to analyze smoke characteristics and generate confidence scores, the problem of difficulty in distinguishing smoke types in existing technologies is solved, thereby improving the accuracy and safety of users in dealing with dangerous situations.

CN121019470APending Publication Date: 2025-11-28GM GLOBAL TECHNOLOGY OPERATIONS LLC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202410974104.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2024-05-28
Filing Date
2024-07-19
Publication Date
2025-11-28

AI Technical Summary

Technical Problem

Existing vehicle systems struggle to distinguish between different types of smoke, making it difficult for users to make the right decisions, especially in dangerous situations such as airbag deployment or fire.

Method used

By installing a hazard monitoring system in the vehicle, sensor data and algorithms are used to analyze smoke characteristics, generate confidence scores, determine the hazard probability level, and provide corresponding instructions and information to users and third-party responders through communication functions.

Benefits of technology

It enables accurate identification of different types of smoke and assessment of hazardous situations, helping users make correct response decisions and improving vehicle safety and emergency response efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121019470A_ABST
    Figure CN121019470A_ABST
Patent Text Reader

Abstract

A computer-implemented method, when executed by data processing hardware, causes the data processing hardware to perform operations. The operations include: monitoring a trigger event via a hazard monitoring algorithm; detecting a trigger event via a hazard monitoring algorithm; and generating a confidence score based on the trigger event. The operations further include determining a hazard probability level based on the confidence score; performing a communication function via a hazard monitoring algorithm; and executing at least one of the instruction function and the classification function based on the hazard probability level.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to a hazard monitoring system for a vehicle. BACKGROUND

[0002] The information provided in this section is presented to generally summarize the context of the disclosure. To the extent the description in this section describes what is presently named as the inventor's work, and to the extent the described aspects can not be considered prior art, it is expressly not admitted that the inventor's work, as described in this section, is prior art to the disclosure.

[0003] Vehicles are equipped with sensors to monitor and detect impact events, collisions, or other events that can cause an airbag to deploy. Often, an airbag deploys with a cloud of smoke, but this smoke can not be related to smoke associated with a fire. Many vehicle systems can benefit from improved capabilities to detect and differentiate between various types of smoke. For example, while a vehicle can detect the presence of smoke, the vehicle can not be able to differentiate between types of smoke. Further, many users are not familiar with different types of smoke and can find it challenging to make an informed decision on how to proceed. Accordingly, there is a need for an improved system for monitoring a hazardous condition, such as the presence of smoke, and providing information to users and first responders about the state of the vehicle. SUMMARY

[0004] In some aspects, a computer-implemented method, when executed by data processing hardware, causes the data processing hardware to perform operations. The operations include monitoring, via a hazard monitoring algorithm, a triggering event; detecting, via the hazard monitoring algorithm, the triggering event; and generating a confidence score based on the triggering event. The operations further include determining a hazard probability level based on the confidence score; performing, via the hazard monitoring algorithm, a communication function; and performing at least one of an instruction function and a triage function based on the hazard probability level.

[0005] In some examples, detecting the triggering event can include receiving event data from at least one sensor of the vehicle. Optionally, the event data can include one or more of smoke, impact velocity, airbag deployment, collision type, and active diagnostic type code. In some cases, determining the hazard probability level can include performing a logic check, the hazard probability level including one of a low level, a medium level, and a high level. Additionally or alternatively, performing the logic check can include identifying the diagnostic type code.

[0006] In some configurations, performing the communication function can include performing an emergency communication with a third party responder. Optionally, performing the triage function can include outputting a triage question and determining an instruction of the instruction function based on a user response. In some cases, generating the confidence score includes determining a source of the smoke based on the event data.

[0007] In other aspects, a hazard monitoring system includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. These operations include: monitoring triggering events via a hazard monitoring algorithm; detecting triggering events via the hazard monitoring algorithm; and generating confidence scores based on the triggering events. The operations also include: determining a hazard probability level based on the confidence scores; performing communication functions via the hazard monitoring algorithm; and performing at least one of instruction functions and class selection functions based on the hazard probability level.

[0008] In some examples, detecting a triggering event includes receiving event data from at least one sensor of the vehicle. Optionally, the event data may include one or more of smoke, impact speed, airbag deployment, collision profile, and active diagnostic type codes. In some cases, determining the hazard probability level may include performing a logic check, where the hazard probability level includes one of low, medium, and high levels. Alternatively or additionally, performing the logic check may include identifying a diagnostic type code.

[0009] In some configurations, performing communication functions may include performing emergency communication with third-party responders. Optionally, performing class selection functions may include outputting class selection questions and determining instructions for the function based on user responses. In a further example, generating confidence scores may include determining the smoke source based on event data.

[0010] In a further aspect, a hazard monitoring system for a vehicle includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. These operations include: monitoring triggering events via a hazard monitoring algorithm; detecting triggering events via the hazard monitoring algorithm; and receiving event data from the vehicle's sensor system based on the triggering events, the event data including at least one or more of smoke data, collision speed, airbag deployment, collision profile, and active diagnostic type codes. The operations also include generating a confidence score based on the triggering events, determining a hazard probability level based on the confidence score, performing a communication function via the hazard monitoring algorithm, and performing at least one of an instruction function and a class selection function based on the hazard probability level.

[0011] In some examples, generating a confidence score may include determining at least one of smoke color, smoke location, and smoke acceleration based on smoke data. The operation may also include performing a logical check via a hazard monitoring algorithm and comparing the event data with the performed logical check. Optionally, performing communication functions may include communicating at least one of the event data and hazard probability levels to a third-party responder. Attached Figure Description

[0012] The accompanying drawings described herein are for illustrative purposes only and are not intended to limit the scope of this disclosure.

[0013] Figure 1 This is a schematic diagram of a hazard monitoring system based on this disclosure;

[0014] Figure 2 This is an exemplary block diagram of a hazard monitoring system according to the present disclosure;

[0015] Figure 3 This is another exemplary block diagram of a hazard monitoring system according to this disclosure;

[0016] Figure 4 This is yet another exemplary block diagram of a hazard monitoring system according to the present disclosure;

[0017] Figure 5 This is another exemplary block diagram of a hazard monitoring system according to this disclosure; and

[0018] Figure 6 This is an exemplary flowchart of a hazard monitoring system according to the present disclosure.

[0019] In all the accompanying drawings, the corresponding reference numerals indicate the corresponding parts. Detailed Implementation

[0020] The example configuration will now be described more fully with reference to the accompanying drawings. The example configuration is provided so that this disclosure will be thorough and will fully communicate the scope of this disclosure to those skilled in the art. Specific details, such as examples of specific components, devices, and methods, are set forth to provide a thorough understanding of the configuration of this disclosure. It will be apparent to those skilled in the art that the specific details are not required, that the example configuration may be implemented in many different forms, and that the specific details and exemplary configuration should not be construed as limiting the scope of this disclosure.

[0021] The terminology used herein is for the purpose of describing specific exemplary configurations only and is not intended to be limiting. As used herein, the singular articles “a,” “an,” and “the” may also be intended to include plural forms unless the context clearly indicates otherwise. The terms “comprising,” “including,” “containing,” and “having” are inclusive, thus specifying the presence of features, steps, operations, elements, and / or components, but not excluding the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. The method steps, processes, and operations described herein should not be construed as requiring them to be performed in the specific order discussed or shown, unless specifically identified as such. Additional or alternative steps may be employed.

[0022] When an element or layer is referred to as “on another element or layer,” “joined to,” “connected to,” “attached to,” or “linked to” another element or layer, it may be directly on, joined to, connected to, attached to, or linked to the other element or layer, or there may be intermediate elements or layers present. Conversely, when an element is referred to as “directly on another element or layer,” “directly joined to,” “directly connected to,” “directly attached to,” or “directly linked to” another element or layer, there may be no intermediate elements or layers present. Other terms used to describe relationships between elements should be interpreted in a similar manner (e.g., “between” vs. “directly between,” “adjacent” vs. “directly adjacent,” etc.). As used herein, the term “and / or” includes any and all combinations of one or more of the related listed items.

[0023] The terms first, second, third, etc., may be used herein to describe various elements, components, regions, layers, and / or parts. These elements, components, regions, layers, and / or parts should not be limited by these terms. These terms are used only to distinguish individual elements, components, regions, layers, or parts. Terms such as “first,” “second,” and other numerical terms do not imply order or sequence unless the context clearly indicates otherwise. Therefore, the first element, component, region, layer, or part discussed below may be referred to as the second element, component, region, layer, or part without departing from the teachings of the example configuration.

[0024] In this application, including the following definitions, the term "module" may be replaced by the term "circuit". The term "module" may refer to or be a part of an application-specific integrated circuit (ASIC), or include ASICs; digital, analog, or mixed-signal analog / digital discrete circuits; digital, analog, or mixed-signal analog / digital integrated circuits; combinational logic circuits; field-programmable gate arrays (FPGAs); processors (shared, dedicated, or grouped) that execute code; memory (shared, dedicated, or grouped) that stores code executed by the processor; other suitable hardware components that provide the functions described; or some or all of the above, such as in a system-on-a-chip.

[0025] The term "code" as used above can include software, firmware, and / or microcode, and can refer to programs, routines, functions, classes, and / or objects. The term "shared processor" includes a single processor that executes some or all of the code from multiple modules. The term "group processor" includes a processor, in conjunction with an additional processor, that executes some or all of the code from one or more modules. The term "shared memory" includes a single memory that stores some or all of the code from multiple modules. The term "group memory" includes memory, in conjunction with additional memory, that stores some or all of the code from one or more modules. The term "memory" can be a subset of the term "computer-readable medium." The term "computer-readable medium" does not include transient electrical and electromagnetic signals propagating through the medium and can therefore be considered tangible, non-transitory memory. Non-limiting examples of non-transitory memory include tangible computer-readable media, including non-volatile memory, magnetic memory, and optical memory.

[0026] The apparatus and methods described in this application may be implemented, in whole or in part, by one or more computer programs executed by one or more processors. The computer program includes processor-executable instructions stored on at least one non-transitory tangible computer-readable medium. The computer program may also include and / or depend on stored data.

[0027] A software application (i.e., a software resource) can refer to computer software that enables a computing device to perform tasks. In some examples, a software application may be referred to as an "application," "app," or "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and game applications.

[0028] Non-transitory memory can be a physical device used for temporary or permanent storage of programs (e.g., instruction sequences) or data (e.g., program state information) for use by a computing device. Non-transitory memory can be volatile and / or non-volatile addressable semiconductor memory. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., commonly used in firmware, such as bootloaders). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase-change memory (PCM), and magnetic disks or magnetic tapes.

[0029] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented using high-level procedural and / or object-oriented programming languages ​​and / or assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0030] Various implementations of the systems and techniques described herein can be implemented in digital electronic and / or optical circuits, integrated circuits, specially designed ASICs (Application-Specific Integrated Circuits), computer hardware, firmware, software, and / or combinations thereof. These different implementations may include implementations in one or more computer programs executable and / or interpretable on a programmable system, the programmable system including at least one programmable processor, at least one input device, and at least one output device, the programmable processor being dedicated or general-purpose, coupled to receive data and instructions from and send data and instructions to the storage system.

[0031] The processes and logic flows described in this specification can be executed by one or more programmable processors, also known as data processing hardware, which execute one or more computer programs to perform functions by manipulating input data and generating output. These processes and logic flows can also be executed by special-purpose logic circuits, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). For example, processors suitable for executing computer programs include general-purpose and special-purpose microprocessors, as well as any one or more processors of any kind of digital computer. Typically, the processor receives instructions and data from read-only memory or random access memory, or both. The basic components of a computer are a processor for executing instructions and one or more storage devices for storing instructions and data. Typically, a computer will also include or be operatively coupled to one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, to receive data from or transfer data to, or both. However, a computer does not need to have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor storage devices such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks or removable disks; magneto-optical disks; and CD-ROMs and DVD-ROMs. Processors and memory may be supplemented or incorporated therein by dedicated logic circuitry.

[0032] To provide interaction with the user, one or more aspects of this disclosure can be implemented on a computer having a display device for displaying information to the user, such as a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or touchscreen, and optional keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual, auditory, or tactile feedback; and input from the user can be received in any form, including sound, speech, or tactile input. Furthermore, the computer can interact with the user by sending documents to and receiving documents from the device used by the user; for example, by sending a webpage to a web browser on the user's client device in response to a request received from a web browser.

[0033] refer to Figures 1-6Hazard monitoring system 10 is configured for vehicle 100 and includes a controller 12 for vehicle 100 configured with hazard monitoring algorithm 14. Hazard monitoring system 10 also includes a sensor system 200 for vehicle 100, configured to communicate sensor data 202 with controller 12, the sensor data 202 including external and internal data of vehicle 100, as described below. Controller 12 also communicates with battery 300 of vehicle 100 to receive battery data 302. Each of sensor data 202 and battery data 302 is used at least in part to jointly define event data 16 that triggers event 18, as described below. Hazard monitoring system 10 is configured to advantageously monitor and detect trigger event 18 and utilize event data 16 to communicate procedure instructions 20 to occupants, as described herein. Hazard monitoring system 10 is configured to advantageously assist users in navigating trigger event 18, which users might otherwise be unsure how to proceed.

[0034] Still referencing Figures 1-6 Vehicle 100 is communicatively coupled to a third-party responder 402, which is part of the hazard monitoring system 10, via network 400. The third-party responder 402 may be a first responder vehicle and / or a dispatch office configured to contact the first responder vehicle. For example, in response to a triggering event 18, the controller 12 of vehicle 100 may communicate event data 16 analyzed by the hazard monitoring algorithm 14, as described herein, with the third-party responder 402. The third-party responder 402 may communicate with the occupants of vehicle 100 and provide them with information and potential instructions based on the hazard monitoring algorithm 14.

[0035] Specific reference Figures 2-5 The hazard monitoring algorithm 14 is executed by the data processing hardware 22 of the controller 12. The controller 12 also includes memory hardware 24 that communicates with the data processing hardware 22. The memory hardware 24 stores instructions that, when executed on the data processing hardware 22, cause the data processing hardware 22 to perform operations as described herein. The memory hardware 24 may store collision types 26 corresponding to potential triggering events 18. Collision types 26 may be pre-programmed as part of the hazard monitoring algorithm 14, or may be learned by the hazard monitoring algorithm 14 so that the hazard monitoring algorithm 14 can be periodically updated. Collision types 26 may include, but are not limited to, rear-end collisions, side collisions, front-end collisions, and / or rollover collisions. Collision types 26 may be identified by event data 16 and may help the hazard monitoring algorithm 14 determine the hazard probability level 28 of triggering event 18, as described below.

[0036] Triggering event 18 may include, but is not limited to, impact events, airbag deployment, and / or fire events. In some cases, triggering event 18 may be in response to an impact event causing one or more of airbag deployment 30 and / or fire 32. For example, triggering event 18 may be the result of a collision. Therefore, triggering event 18 may depend at least in part on collision type 26. In some examples, triggering event 18 may cause smoke 34 to appear inside or around vehicle 100. Sensor system 200 may capture smoke 34 as smoke data 36 and communicate smoke data 36 as part of sensor data 202 to hazard monitoring algorithm 14. While smoke data 36 may be attributed to various accidents and aspects of the vehicle, for the purposes of this disclosure, smoke data 36 may be attributed to at least one of airbag deployment 30 and fire 32. Since smoke data 36 may be related to triggering event 18, smoke data 36 may be analyzed by hazard monitoring algorithm 14 as part of event data 16.

[0037] Further reference Figures 2-5 The hazard monitoring algorithm 14 is configured with a class selection function 40 stored in memory hardware 24, and includes a class selection problem 42. The memory hardware 24 may also store an instruction function 44 of the hazard monitoring algorithm 14, which includes program instructions 20 provided to a third-party responder 402 and / or the occupants of vehicle 100 based on a hazard probability level 28. In some cases, the class selection function 40 and the instruction function 44 may be referred to together or separately as communication functions. As described above, based at least in part on sensor data 202, the hazard monitoring algorithm 14 collects event data 16 in response to a triggering event 18, the sensor data 202 of which may be captured by various monitoring systems of vehicle 100.

[0038] For example, sensor system 200 may include imaging system 200a and speaker system 200b. Imaging system 200a may capture image data 202a, which may be compared with image database 46 stored on memory hardware 24 of controller 12. Image database 46 may include a range of smoke colors and locations corresponding to at least one of airbag deployment 30 and fire 32. For example, when triggering event 18 is associated with airbag deployment 30, the image stored in image database 46 may reflect smoke 34 with a lighter color and emanating only from the interior compartment 102 of vehicle 100. In contrast, images of smoke 34 stored in image database 46 associated with fire 32 may be darker or more variable in color and may be both inside the interior compartment 102 and outside vehicle 100. Hazard monitoring algorithm 14 is configured to compare smoke data 36 with image data 202a and with image database 46 to distinguish between airbag smoke 34a and fire smoke 34b. The speaker system 200b can be configured to capture audio data 202b, which can be compared with key terms 48 stored in memory hardware 24.

[0039] In addition to image data 202a and audio data 202b, sensor data 202 may include the speed difference of vehicle 100, pretensioner deployment, emergency stop button activation of vehicle 100, impact velocity, and smoke acceleration. Therefore, hazard monitoring algorithm 14 can utilize sensor data 202 in conjunction with other event data 16 to determine the collision type 26. For example, hazard monitoring algorithm 14 may receive battery data 302, smoke data 36, ​​and airbag deployment 30. Airbag deployment 30 may indicate positive deployment 52 or negative deployment 54, where positive deployment 52 corresponds to triggering event 18. Negative deployment 54 may also be associated with triggering event 18, but may be associated with low-impact collision type 26, allowing hazard monitoring algorithm 14 to at least partially identify collision type 26 based on negative deployment 54.

[0040] Still referencing Figures 2-5 In response to a triggering event 18 corresponding to a smoke source, the hazard monitoring algorithm 14 generates a confidence score 60, as described below. The confidence score 60 can be used in conjunction with a diagnostic type code 62 generated by the hazard monitoring system 10 to determine a hazard probability level 28. The hazard probability level 28, determined by the hazard monitoring algorithm 14, indicates the likely severity of the triggering event 18. Hazard probability levels 28 include low level 28a, medium level 28b, and high level 28c.

[0041] When a hazard probability level 28 is determined, the hazard monitoring algorithm 14 can also perform a logic check 64. The logic check 64 is used to identify a diagnostic type code 62. The diagnostic type code 62 can indicate the severity of the triggering event 18. For example, the diagnostic type code 62 can classify the triggering event 18 as critical or non-critical. Some examples of critical diagnostic type codes 64 include, but are not limited to, random cylinder misfire, detection of an evaporative emission system leak, low system voltage, and / or out-of-range voltage of battery 300. Based on the diagnostic type code 62, the hazard monitoring algorithm 14 can assign a hazard probability level 28 based on whether the triggering event 18 is identified as critical or non-critical based on the diagnostic type code 62. It is conceivable that low levels 28a and medium levels 28b can be associated with non-critical diagnostic type codes 62, while high levels 28c can be associated with critical diagnostic type codes 62. Therefore, if the hazard monitoring algorithm 14 identifies a critical diagnostic code 62, the hazard monitoring algorithm 14 executes the high level 28c of the hazard monitoring system 10.

[0042] refer to Figures 2-5 Regardless of the hazard probability level 28, the hazard monitoring algorithm 14 executes the instruction function 44 to contact the third-party responder 402 to provide procedural instructions 20 to the occupants. For example, the hazard monitoring algorithm 14 may perform emergency communication with the third-party responder. When executing the instruction function 44, the hazard monitoring algorithm 14 determines the hazard probability level 28. Each hazard probability level 28 may have different executions of the hazard monitoring algorithm 14, each including the execution of the instruction function 44 to communicate with the third-party responder 402.

[0043] As described above, low level 28a corresponds to non-critical diagnostic type code 62. For example, event data 16 may indicate that the impact velocity is less than a predetermined impact velocity 70 stored in the memory hardware, and that there is a negative deployment 54 of the airbag deployment 30. The hazard monitoring algorithm 14 can also identify that collision type 26 is one of a rear-end collision and a side collision, which, combined with other event data 16, can correspond to low level 28a. As a result, the hazard monitoring algorithm 14 can execute a low level 28a response corresponding to the execution of instruction function 44. The third-party responder 402 receives the program instruction 20 corresponding to the low level 28a response and can provide the occupant with the program instruction 20 to remain in the vehicle 100 until the first responder arrives.

[0044] Level 28b may also correspond to non-critical diagnostic type code 62, but in addition to instruction function 44, it may include other event data 16 corresponding to execution class selection function 40. For example, the impact velocity may be greater than a first predetermined impact velocity 70a, but less than a second predetermined impact velocity 70b. The second predetermined impact velocity 70b may typically be defined as the threshold impact velocity that triggers high level 28c, as described below. Furthermore, the hazard monitoring algorithm 14 may determine that airbag deployment 30 is positive (i.e., positive deployment 52) ​​and receive smoke data 36. Collision type 26 may also include one of rear-end collision, side collision, and / or front-end collision.

[0045] Regarding smoke data 36, ​​hazard monitoring algorithm 14 can utilize other sensor data 202 to evaluate smoke data 36. For example, image data 202a can indicate the color and location of smoke 34. Audio data 202b can also provide information that can be used to inform about smoke data 36 by identifying key terms 48 associated with smoke data 36. For example, occupants can comment on the color, odor, and location of the smoke. Each of these examples can be compared with key terms 48 stored in memory hardware 24 to identify level 28b. For example, smoke data 36 can be determined to be light-colored and located inside the interior compartment 102, making smoke 34 associated with airbag deployment 30 and less likely to be associated with fire 32.

[0046] Once level 28b is determined and instruction function 44 is executed, hazard monitoring algorithm 14 can execute class selection function 40 and communicate class selection question 42 to third-party responder 402 via network 400. In some examples, third-party responder 402 can receive notification from hazard monitoring algorithm 14 that class selection function 40 has been executed, and third-party responder 402 can continue to ask class selection question 42. Class selection question 42 may involve, but is not limited to, the odor of smoke 34, flame identification, the color of smoke 34, and changes in smoke color. Third-party responder 402 can determine whether to indicate fire 32 based on the responses received from the occupants.

[0047] As described above, smoke data 36 may include airbag smoke 34a and fire smoke 34b. In some cases, occupants may find it difficult to distinguish between airbag smoke 34a and fire smoke 34b, and a third-party responder 402 may be able to help differentiate between the two. For example, airbag smoke 34a may be lighter in color and have a chemical odor. In contrast, fire smoke 34b may be darker and have a plastic and / or wood odor. Furthermore, airbag smoke 34a may be contained or confined within the interior compartment 102 of vehicle 100, such that the presence of smoke 34 outside vehicle 100 may be associated with fire smoke 34b rather than airbag smoke 34a. If the answer to alternative question 42 indicates that smoke data 36 is associated with airbag smoke 34a, it may be advised that occupants remain in vehicle 100 until the first responder arrives. If the answer to alternative question 42 indicates that smoke data 36 is associated with fire smoke 34b, it may be advised that occupants evacuate vehicle 100 and find a safe location.

[0048] Further reference Figures 2-5 Hazard monitoring algorithm 14 can determine that triggering event 18 is associated with high level 28c. In some cases, high level 28c can be associated with emergency diagnostic type code 62, such that one or more emergency diagnostic type codes 64 can be active. In some examples, high level 28c can also be determined by an impact velocity greater than or equal to a second predetermined impact velocity, as described above. Furthermore, smoke data 36 can reflect the detection of smoke both inside the interior compartment 102 and outside the vehicle 100, with smoke 34 changing color and smoke 34 accumulating at an accelerating rate.

[0049] Furthermore, battery data 302 can reflect a rapid decline in the state of charge 304 of battery 300. A rapid loss of state of charge 304 can indicate a problem with battery 300, which could be a source or consequence of a potential fire. However, a change in state of charge 304 could be the result of a separate problem with battery 300, therefore the hazard monitoring algorithm 14 compares battery data 302 with other received event data 16. For example, the hazard monitoring algorithm 14 can detect a rising temperature in the interior compartment 102 and can identify the collision type 26 that triggered event 18 as a high-level 28c collision, such as a rollover.

[0050] In some cases, event data 16 may include audio data 202b, which may capture what the occupants say. Audio data 202b may include one or more key terms 48 stored in memory hardware 24, such as fire, heat, etc. As described above, event data 16 may also include image data 202a, which includes images from the interior compartment 102 and the exterior of vehicle 100. Based on image database 46, image data 202a may show smoke 34 inside the interior compartment 102 and outside vehicle 100, and has a color variation consistent with fire smoke 34b. Hazard monitoring algorithm 14 may also compare image data 202a with smoke data 36 and may determine whether there is smoke acceleration.

[0051] If the hazard monitoring algorithm 14 determines that the triggering event 18 corresponds to a high level 28c, then in addition to executing the instruction function 44, the hazard monitoring algorithm 14 instructs the occupants to leave the vehicle 100 and seek safety. For example, the hazard monitoring algorithm 14 may issue an alarm 80 instructing the occupants to leave the vehicle 100. Alternatively, the hazard monitoring algorithm 14 may communicate the high level 28c of the triggering event 18 to a third-party responder 402, and the third-party responder 402 may instruct the occupants to leave the vehicle 100.

[0052] refer to Figure 6 An exemplary flowchart of a hazard monitoring system 10 is shown. At 500, the hazard monitoring system 10 monitors vehicle 100 during operation, and at 502, monitors for a triggering event 18. At 504, the hazard monitoring system 10 determines whether the triggering event 18 has been detected. If not, the hazard monitoring system 10 continues to monitor for the triggering event 18 while vehicle 100 is in operation. If the triggering event 18 is detected, at 506, the hazard monitoring system 10 executes instruction function 44, and at 508, determines a hazard probability level 28. If a low level 28a is determined, at 510, the hazard monitoring system 10 instructs the occupant to remain in vehicle 100 via a third-party responder 402. If a medium level 28b is determined, the hazard monitoring system 10 executes class selection function 40 at 512, and prompts the occupant with a class selection question 42 via the third-party responder 402 at 514.

[0053] At 516, the hazard monitoring system 10 determines, based on the user's response, whether to escalate to a high level 28c. If not escalated, the third-party responder 402 may instruct the occupants to remain in vehicle 100 at 510. If escalated, at 518, the third-party responder instructs the occupants to evacuate vehicle 100 and seek safety. Similarly, if the hazard monitoring system 10 determines a high level 28c, it instructs the occupants to evacuate vehicle 100 and seek safety at 518.

[0054] Refer again Figures 1-6The hazard monitoring system 10 advantageously monitors triggering events 18 of the vehicle 100 and, when detected, evaluates the triggering event 18. This evaluation helps identify a hazard probability level 28, which assists a third-party responder 400 in navigating the triggering event 18. For example, the third-party responder 400 can adjust its response based on the hazard probability level 28 determined by the hazard monitoring algorithm 14. The integration of the hazard monitoring algorithm 14 within the controller 12 of the vehicle 100 provides the hazard monitoring algorithm 14 with access to the various sensor systems 200 and battery 300 of the vehicle 100 to maximize the efficiency of acquiring sensor and battery data 202, 302, respectively. Therefore, the hazard monitoring algorithm 14 can have improved capabilities in identifying potential hazards and assigning appropriate levels 28 to improve the efficiency of responding to the triggering event 18.

[0055] Many embodiments have been described. However, it should be understood that various modifications can be made without departing from the spirit and scope of this disclosure. Therefore, other embodiments are also within the scope of the following claims.

[0056] The foregoing description has been provided for purposes of illustration and description. It is not intended to be exhaustive or limiting of this disclosure. Individual elements or features of a particular configuration are generally not limited to that particular configuration, but where applicable, they are interchangeable and can be used in selected configurations, even if not specifically shown or described. This can also be varied in many ways. Such variations should not be considered as departing from this disclosure, and all such modifications are intended to be included within the scope of this disclosure.

Claims

1. A hazard monitoring system, comprising: Data processing hardware; as well as Memory hardware that communicates with data processing hardware; the memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations including the following: Events are monitored and triggered via a hazard monitoring algorithm; Events are detected and triggered via a hazard monitoring algorithm; Generate confidence scores based on triggering events; The level of risk probability is determined based on confidence scores; Communication functions are performed via a hazard monitoring algorithm; and At least one of the following: the instruction execution function and the class selection function, based on the level of danger probability.

2. The hazard monitoring system according to claim 1, wherein, Detecting a triggering event involves receiving event data from at least one of the vehicle's sensors.

3. The hazard monitoring system according to claim 2, wherein, The event data includes one or more of the following: smoke, impact velocity, airbag deployment, collision profile, and active diagnostic type code.

4. The hazard monitoring system according to claim 1, wherein, Determining the risk probability level involves performing logical checks, and the risk probability level can be one of low, medium, or high.

5. The hazard monitoring system according to claim 4, wherein, The execution logic check includes identifying diagnostic type codes.

6. The hazard monitoring system according to claim 1, wherein, The communication function includes performing emergency communications with third-party responders.

7. The hazard monitoring system according to claim 1, wherein, The execution of the class selection function includes outputting the class selection question and determining the instruction function based on the user response.

8. The hazard monitoring system according to claim 1, wherein, Generating confidence scores involves identifying the smoke source based on event data.

9. The hazard monitoring system according to claim 1, wherein, Performing communication functions includes communicating at least one of the event data and the hazard probability level with a third-party responder.

10. A vehicle comprising the hazard monitoring system according to claim 1.