Travel safety early warning method and device based on driving behavior of driver

By aggregating and matching driver behavior events, the problems of small coverage and high cost of early warning in the existing technology are solved, and comprehensive and accurate early warning of driver driving behavior is achieved, and trip safety is improved.

CN119990759APending Publication Date: 2025-05-13SICHUAN SHENZHOUXING NETWORK CAR-HAILING SERVICE CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510080842.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-01-17
Publication Date
2025-05-13

AI Technical Summary

Technical Problem

The prior art warns drivers of dangerous driving behaviors such as fatigue driving and speeding, and requires additional equipment configuration and limited coverage, so it is impossible to conduct comprehensive and accurate early warnings.

Method used

By obtaining the driver behavior event of the client buried point, the event and pre-stored event are aggregated based on the driver identification information, matching the configuration event and event subrules, and outputting early warning information.

Benefits of technology

It realizes a comprehensive and accurate warning of drivers' driving behavior, provides diversified warning methods, and improves trip safety.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119990759A_ABST
    Figure CN119990759A_ABST
Patent Text Reader

Abstract

The invention discloses a driver driving behavior-based travel safety early warning method and device, and the method comprises the steps: obtaining a driver behavior event obtained by a client through carrying out the point burying of a behavior event of a driver, and the driver behavior event comprises driver identification information; based on the driver identification information, carrying out aggregation processing on the driver behavior event and a pre-stored driver behavior event to obtain a driver behavior integration event; determining whether the driver behavior integration event is matched with the configuration event; if yes, determining whether the driver behavior integration event is matched with the event sub-rule; and if yes, outputting corresponding early warning information for the driver behavior integration event. By combining back-end event configuration with front-end reported events, performing data aggregation on the events, matching the events with back-end configured events and event sub-rules, determining an early warning decision, and contacting the events to a client to realize early warning, a plurality of events can be aggregated, and early warning is performed through different early warning modes. And an accurate and diversified touch mode is provided.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of data aggregation technology, and in particular to a trip safety warning method, device, computer equipment and storage medium based on driver driving behavior. Background Art

[0002] As the demand for online ride-hailing services grows and the number of cars increases, traffic accidents occur more frequently. Irregular driving behavior poses serious safety risks, so early warning of dangerous driving behavior is becoming increasingly important.

[0003] Currently, drivers who spend a long time online taking orders may have dangerous driving problems such as fatigue driving and speeding. The existing warning mechanism needs to be configured with additional equipment or only make detection and judgment on a single behavior, which increases the cost of hardware equipment and the warning coverage is relatively small. Therefore, how to provide comprehensive and accurate warnings of safety hazards in the vehicle driving process based on the user's driving behavior has become an urgent problem that needs to be solved. Summary of the invention

[0004] Based on this, it is necessary to provide a trip safety warning method, device, computer equipment and storage medium based on the driver's driving behavior to address the above technical issues, so as to solve at least one problem existing in the above-mentioned prior art.

[0005] In a first aspect, the embodiment of the present application is implemented as follows: a trip safety warning method based on the driver's driving behavior is provided, comprising:

[0006] Obtaining a driver behavior event obtained by the client by burying the driver's behavior event, wherein the driver behavior event includes driver identification information;

[0007] Based on the driver identification information, the driver behavior event is aggregated with the pre-stored driver behavior event to obtain a driver behavior integration event;

[0008] Determine whether the driver behavior integration event matches the configuration event;

[0009] If the driver behavior integration event matches the configured event, determining whether the driver behavior integration event matches the event sub-rule;

[0010] If the driver behavior event matches the event sub-rule, corresponding warning information is output for the driver behavior integration event.

[0011] In an embodiment of the present application, the driver behavior event is aggregated with the pre-stored driver behavior event based on the driver identification information, including:

[0012] Merge and store driver behavior events that belong to the same driver identification information;

[0013] Determining whether the driver behavior event meets a preset aggregation condition;

[0014] If the driver behavior event meets the preset aggregation condition, the driver behavior event is aggregated with the pre-stored driver behavior event.

[0015] In an embodiment of the present application, determining whether the driver behavior integration event matches the configuration event includes:

[0016] Get pre-configured configuration events;

[0017] Comparing the driver behavior integration event with the configuration event one by one;

[0018] When the comparison is consistent, it is determined that the driver behavior integration event matches the configuration event.

[0019] In an embodiment of the present application, determining whether the driver behavior integration event matches the event sub-rule includes:

[0020] Receive the kafka message of the driver behavior integration event;

[0021] The driver behavior integration event is identified to determine whether the driver behavior integration event matches an event sub-rule.

[0022] In one embodiment of the present application, the event sub-rule includes multiple event sub-rules, and determining whether the driver behavior integration event matches the event sub-rule includes:

[0023] Compare the driver behavior integration event with each event sub-rule separately;

[0024] When the comparison is consistent, it is determined that the driver behavior integration event matches the event sub-rule.

[0025] In one embodiment of the present application, the outputting of corresponding warning information for the driver behavior integration event includes:

[0026] Determining a target event sub-rule matching the driver behavior integration event;

[0027] Determine the warning action corresponding to each of the target event sub-rules;

[0028] Based on the warning action, corresponding warning information is triggered to provide different warnings for the driver behavior integration event.

[0029] In an embodiment of the present application, obtaining the driver behavior event obtained by the client by burying the driver's behavior event includes:

[0030] The client obtains the driver's behavior events by burying the driver's behavior events;

[0031] The client sends the driver behavior event to Kafka, which in turn sends the driver behavior event to Flink through Kafka, so that Flink performs event aggregation and matching.

[0032] In the second aspect, a trip safety warning system based on the driver's driving behavior is provided, including:

[0033] A driver behavior event acquisition unit, used to acquire a driver behavior event obtained by the client by burying the driver's behavior event, wherein the driver behavior event includes driver identification information;

[0034] A driver behavior event aggregation unit, configured to aggregate the driver behavior event with pre-stored driver behavior events based on the driver identification information to obtain a driver behavior integration event;

[0035] A first matching unit, used to determine whether the driver behavior integration event matches the configuration event;

[0036] a second matching unit, configured to determine whether the driver behavior integration event matches the event sub-rule if the driver behavior integration event matches the configuration event;

[0037] The early warning unit is used to output corresponding early warning information for the driver behavior integration event if the driver behavior event matches the event sub-rule.

[0038] In a third aspect, a computer device is provided, comprising a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor, wherein when the processor executes the computer-readable instructions, the steps of the trip safety warning method based on the driver's driving behavior as described above are implemented.

[0039] In a fourth aspect, a readable storage medium is provided, wherein the readable storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by a processor, the steps of the trip safety warning method based on the driver's driving behavior as described above are implemented.

[0040] The above-mentioned trip safety warning method, device, computer equipment and storage medium based on the driver's driving behavior, and its method implementation include: obtaining the driver behavior event obtained by the client by burying the driver's behavior event, and the driver behavior event includes the driver identification information; based on the driver identification information, the driver behavior event is aggregated with the pre-stored driver behavior event to obtain the driver behavior integration event; determine whether the driver behavior integration event matches the configuration event; if the driver behavior integration event matches the configuration event, determine whether the driver behavior integration event matches the event sub-rule; if the driver behavior event matches the event sub-rule, output the corresponding warning information for the driver behavior integration event. In the embodiment of the present application, by combining the back-end event configuration with the front-end reported event, and aggregating the event data, matching the back-end configured event and the event sub-rule, determining the warning decision, and reaching the warning decision to the client to realize the warning, multiple events can be aggregated, and warnings can be issued through different warning methods, providing an accurate and diversified contact method. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments of the present application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0042] Figure 1 This is a schematic diagram of an application environment of a trip safety warning method based on a driver's driving behavior in an embodiment of the present application;

[0043] Figure 2 It is a flow chart of a trip safety warning method based on the driver's driving behavior in one embodiment of the present application;

[0044] Figure 3 It is a structural schematic diagram of a travel safety warning device based on the driver's driving behavior in one embodiment of the present application;

[0045] Figure 4 It is a schematic diagram of a computer device in one embodiment of the present application. DETAILED DESCRIPTION

[0046] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0047] The trip safety warning method based on driver driving behavior provided in this embodiment can be applied in the following aspects: Figure 1 In the application environment, the client communicates with flink, flink communicates with the background and the data analysis service module, and the data analysis service module can communicate with the background. The client includes but is not limited to various personal computers, laptops, smart phones, tablets and portable wearable devices, which are installed with preset applications. The background can be implemented with an independent server or a server cluster composed of multiple servers, which can be set locally or in the cloud.

[0048] The client is used to collect and report data. The flink receives data reported by the client through kafka, and obtains pre-configured configuration events from the background for comparison. If the configuration event is hit, the aggregated event is sent to the data analysis service module through kafka for event sub-rule matching. When the match is successful, the event notification is executed to warn the client.

[0049] In one embodiment, if Figure 2 As shown, a trip safety warning method based on the driver's driving behavior is provided, comprising the following steps:

[0050] In step S110, a driver behavior event is obtained by burying the driver's behavior event at the client, and the driver behavior event includes driver identification information;

[0051] In the embodiment of the present application, the client can start to collect data after the driver leaves the vehicle, and collect and report events of specified fields, such as driver departure time, driving speed, driving route and other driver behavior events. The data format of the driver behavior event can be the event name, driver ID information, latitude and longitude, time, etc. configured by the backend.

[0052] It should be noted that different driver behavior events may be added with corresponding driver identification information, such as driver ID, name, number, etc., to uniquely identify that the driver behavior events originate from the same driver.

[0053] In the embodiment of the present application, after the client embeds the driver behavior event at the front end, it can send the driver behavior event to Kafka (a high-throughput distributed publish-subscribe messaging system), and then send it to Flink (a framework and distributed processing engine) for aggregation processing. Using Kafka for decoupling and asynchronous processing, the service responsibilities are clear, and the throughput of the system is improved.

[0054] In step S120, based on the driver identification information, the driver behavior event is aggregated with the pre-stored driver behavior event to obtain a driver behavior integration event;

[0055] In an embodiment of the present application, Flink can partition and save the driver behavior events received and sent through Kafka according to preset rules, and can aggregate the driver behavior events belonging to the same partition to obtain driver behavior integration events.

[0056] In the embodiment of the present application, an aggregation condition can be set. When the aggregation condition is met, the driver behavior event currently received is aggregated with the corresponding pre-saved driver behavior event. The driver behavior integration event is obtained, and an aggregated data stream is generated. For example, the driver behavior events within a preset time are aggregated, and the preset driver behavior events associated with driver A are aggregated.

[0057] It can be understood that the aggregation conditions include multiple ones, and different business scenarios may correspond to different aggregation conditions, and the corresponding aggregation conditions may be called in real time according to the current business scenario, such as different business scenarios such as the vehicle driving process and the vehicle order receiving process.

[0058] In step S130, it is determined whether the driver behavior integration event matches the configuration event;

[0059] In the embodiment of the present application, after obtaining the driver behavior integration event, the configuration event pre-configured in the backend can be obtained. The driver behavior integration event is compared with the configuration event one by one. If the similarity between the driver behavior integration event and the configuration event is greater than a preset threshold, such as 90%, the two are considered to match. At this time, the aggregated driver behavior integration event can be notified to the data analysis service module through Kafka for analysis and processing.

[0060] In an embodiment of the present application, corresponding events, rules, trigger actions, etc. can be configured through the backend, and after successful configuration, they can be sent to the data analysis service module and flink to update local events and rules for comparison.

[0061] In step S140, if the driver behavior integration event matches the configuration event, it is determined whether the driver behavior integration event matches the event sub-rule;

[0062] In the embodiment of the present application, the event sub-rule can be configured in advance for the backend, and the data analysis service can obtain the event sub-rule when it is started and initialize it locally. It can specifically include event sub-rules corresponding to different configuration events, and different configuration events can correspond to multiple event sub-rules. For example, the driver fatigue driving event, the corresponding event sub-rule may be that the driving duration exceeds 4 hours, the rest time during driving is less than 20 minutes, or the driving time on the day exceeds 8 hours, etc.

[0063] In the embodiment of the present application, after obtaining the driver behavior integration event, it can be compared with each pre-configured event sub-rule. If the comparison is consistent, it is considered to match the event sub-rule. It can be understood that a driver behavior integration event can match multiple event sub-rules.

[0064] In step S150, if the driver behavior event matches the event sub-rule, corresponding warning information is output for the driver behavior integration event.

[0065] In the embodiment of the present application, different event sub-rules can trigger different warning actions, such as voice broadcast, SMS notification, information notification, etc. After the data analysis service module consumes the kafka data sent by flink, it can integrate the event recognition into the specified event based on the driver's behavior, and then make a series of judgments. For example, the driver has speeding behavior, the driver is online for too long and drives fatigued, and if it can match all the corresponding event sub-rules, then the driver's behavior can be used as a series of warnings to trigger intervention, such as notifying the driver through messages and voice broadcasts. Different real-time warnings can be made for multiple events, especially in the online car-hailing driver's journey, the entire journey safety can be warned, to achieve real-time warning and intervention, and ensure the travel safety of both drivers and passengers.

[0066] It should be noted that the warning actions corresponding to the successfully matched event sub-rules can be integrated to obtain a series of warning actions. For example, the warning actions corresponding to the successfully matched event sub-rules can include text messages and voice broadcasts. In this way, the user can be prompted in a multiple warning manner by sending text messages to the driver and broadcasting voice at the same time.

[0067] In one embodiment of the present application, the warning triggering method may specifically include vibration, voice broadcast, light, ringing, etc., which are notified to the client to prompt the user, achieve accurate and real-time warning and intervention, and ensure the travel safety of both the driver and the passengers.

[0068] In an embodiment of the present application, a method for early warning of travel safety based on the driver's driving behavior is provided, including: obtaining driver behavior events obtained by burying the driver's behavior events on the client, wherein the driver behavior events include driver identification information; based on the driver identification information, aggregating the driver behavior events with pre-stored driver behavior events to obtain driver behavior integration events; determining whether the driver behavior integration event matches the configured event; if the driver behavior integration event matches the configured event, determining whether the driver behavior integration event matches the event sub-rule; if the driver behavior event matches the event sub-rule, outputting corresponding early warning information for the driver behavior integration event. In an embodiment of the present application, by combining the back-end event configuration with the front-end reported event, and aggregating the event data, matching the back-end configured event and the event sub-rule, determining the early warning decision, and reaching the early warning decision to the client to realize the early warning, multiple events can be aggregated, and early warnings can be issued through different early warning methods, providing an accurate and diversified contact method.

[0069] In an embodiment of the present application, the driver behavior event is aggregated with the pre-stored driver behavior event based on the driver identification information, including:

[0070] Merge and store driver behavior events that belong to the same driver identification information;

[0071] Determining whether the driver behavior event meets a preset aggregation condition;

[0072] If the driver behavior event meets the preset aggregation condition, the driver behavior event is aggregated with the pre-stored driver behavior event.

[0073] Specifically, flink can partition and save the received driver behavior events sent through kafka according to preset rules, and can aggregate the driver behavior events belonging to the same partition to obtain driver behavior integration events. Optionally, flink can partition all driver behavior events reported by clients, such as hash partitioning method. For example, driver ID, client ID, event type, etc. can be used as key values ​​to send data with the same key to a partition. For example, taking driver ID as an example, all driver behavior events corresponding to each driver ID can be classified into a partition, and data can be lightly aggregated into intermediate data for storage according to preset rules, and the stored data will be updated every time a Kafka message is received.

[0074] It is understandable that in order to facilitate the aggregation of driver behavior events, corresponding aggregation conditions can be set. When the aggregation conditions are met, the latest received driver behavior event is aggregated with the corresponding pre-saved driver behavior event to obtain a driver behavior integration event and generate an aggregate data stream. For example, the driver behavior time within a preset time is aggregated, and the preset driver behavior events associated with driver A are aggregated, etc.

[0075] It can be understood that the aggregation conditions include multiple ones, and different business scenarios may correspond to different aggregation conditions, and the corresponding aggregation conditions may be called in real time according to the current business scenario, such as different business scenarios such as the vehicle driving process and the vehicle order receiving process.

[0076] In one embodiment of the present application, the determining whether the driver behavior integration event matches the configuration event obtains a pre-configured configuration event;

[0077] Comparing the driver behavior integration event with the configuration event one by one;

[0078] When the comparison is consistent, it is determined that the driver behavior integration event matches the configuration event.

[0079] Optionally, corresponding configuration events, such as speeding events, fatigue driving events, illegal parking events and other dangerous driving events, can be configured in advance in the backend and stored. When a driver behavior integration event is obtained, for example, the driver is in a driving state for a long time and there is fatigue driving and speeding, it can be compared with the pre-configured configuration events. If the match is consistent, for example, the event similarity is greater than a preset threshold, such as 95%, then the driver behavior integration event can be considered to match the configuration event.

[0080] It can be understood that a driver behavior integration event may integrate multiple driver behavior events, and when it hits a configuration event, it can be considered that it matches the configuration event.

[0081] It should be noted that the configuration event can be updated regularly or periodically, and the latest configuration event can be sent to Flink so that Flink can match it through the latest configuration event.

[0082] In an embodiment of the present application, determining whether the driver behavior integration event matches the event sub-rule includes:

[0083] Receive the kafka message of the driver behavior integration event;

[0084] The driver behavior integration event is identified to determine whether the driver behavior integration event matches an event sub-rule.

[0085] Optionally, after Flink integrates the driver behavior events into driver behavior integration events, it can send them to Kafka for decoupling and asynchronous processing to obtain aggregated data streams, which are then sent to the data analysis service module for processing. After receiving the Kafka message for the driver behavior integration event, the data analysis service module can identify the driver behavior integration event and match it with the pre-configured event sub-rule.

[0086] In one embodiment of the present application, the event sub-rule includes multiple event sub-rules, and determining whether the driver behavior integration event matches the event sub-rule includes:

[0087] Compare the driver behavior integration event with each event sub-rule separately;

[0088] When the comparison is consistent, it is determined that the driver behavior integration event matches the event sub-rule.

[0089] Optionally, different configuration events may correspond to different event sub-rules, and different configuration events may correspond to multiple event sub-rules. For example, for a driver fatigue driving event, the corresponding event sub-rule may be that the driving duration exceeds 4 hours, the rest time during driving is less than 20 minutes, or the driving time on the day exceeds 8 hours, etc.

[0090] In the embodiment of the present application, after obtaining the driver behavior integration event, it can be compared with each pre-configured event sub-rule. If the comparison is consistent, it is considered to match the event sub-rule. It can be understood that a driver behavior integration event can match multiple event sub-rules.

[0091] In one embodiment of the present application, the outputting of corresponding warning information for the driver behavior integration event includes:

[0092] Determining a target event sub-rule matching the driver behavior integration event;

[0093] Determine the warning action corresponding to each of the target event sub-rules;

[0094] Based on the warning action, corresponding warning information is triggered to provide different warnings for the driver behavior integration event.

[0095] Optionally, different event sub-rules can trigger different warning actions, such as voice broadcast, SMS notification, information notification, etc. After the data analysis service module consumes the Kafka data sent by Flink, it can integrate the event recognition into the specified event based on the driver's behavior, and then make a series of judgments, for example, the driver has speeding behavior, the driver has been online for too long and is driving fatigued, and if it can match all the corresponding event sub-rules, a series of triggering intervention warnings can be made for the driver's behavior, such as notifying the driver through messages and voice broadcasting. Different real-time warnings can be made for multiple events, especially in the online car-hailing driver's journey, the entire journey safety can be warned, to achieve real-time warning and intervention, to ensure the travel safety of both the driver and the passengers.

[0096] In an embodiment of the present application, obtaining the driver behavior event obtained by the client by burying the driver's behavior event includes:

[0097] The client obtains the driver's behavior events by burying the driver's behavior events;

[0098] The client sends the driver behavior event to Kafka, which sends the driver behavior event to Flink through Kafka, and performs event aggregation and matching through Flink.

[0099] Optionally, the client can track driver behavior events, with the data format being the event name configured in the backend, driver ID information, latitude and longitude, time, etc., and report the driver behavior events obtained by tracking to Flink for aggregation processing. The driver behavior event can be an event with a specified field, such as the driver's departure time, and the event is sent to Flink through Kafka for aggregation processing. Using Kafka for decoupling and asynchronous processing, the service responsibilities are clear, and the throughput of the system is improved.

[0100] In an embodiment of the present application, by combining the back-end event configuration with the front-end reported events, and aggregating the event data, matching the events configured with the back-end and the event sub-rules, determining the early warning decision, and delivering the early warning decision to the client to implement the early warning, multiple events can be aggregated and issued through different early warning methods, providing accurate and diversified delivery methods.

[0101] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean 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 the present application.

[0102] In one embodiment, a travel safety warning device based on the driver's driving behavior is provided, and the travel safety warning device based on the driver's driving behavior corresponds one-to-one with the travel safety warning method based on the driver's driving behavior in the above embodiment. Figure 3 As shown, the trip safety warning device based on driver driving behavior includes a driver behavior event acquisition unit 10, a driver behavior event aggregation unit 20, a first matching unit 30, a second matching unit 40 and a warning unit 50. Each functional module is described in detail as follows:

[0103] A driver behavior event acquisition unit 10, used to acquire a driver behavior event obtained by a client by burying a driver's behavior event, wherein the driver behavior event includes driver identification information;

[0104] A driver behavior event aggregation unit 20, configured to aggregate the driver behavior event with pre-stored driver behavior events based on the driver identification information to obtain a driver behavior integration event;

[0105] A first matching unit 30, used to determine whether the driver behavior integration event matches the configuration event;

[0106] A second matching unit 40 is used to determine whether the driver behavior integration event matches the event sub-rule if the driver behavior integration event matches the configuration event;

[0107] An early warning unit 50 is configured to output corresponding early warning information for the driver behavior integration event if the driver behavior event matches the event sub-rule;

[0108] In one embodiment of the present application, the driver behavior event aggregation unit 20 is further used to:

[0109] Merge and store driver behavior events that belong to the same driver identification information;

[0110] Determining whether the driver behavior event meets a preset aggregation condition;

[0111] If the driver behavior event meets the preset aggregation condition, the driver behavior event is aggregated with the pre-stored driver behavior event.

[0112] In one embodiment of the present application, the first matching unit 30 is further configured to:

[0113] Get pre-configured configuration events;

[0114] Comparing the driver behavior integration event with the configuration event one by one;

[0115] When the comparison is consistent, it is determined that the driver behavior integration event matches the configuration event.

[0116] In one embodiment of the present application, the second matching unit 40 is further configured to:

[0117] Receive the kafka message of the driver behavior integration event;

[0118] The driver behavior integration event is identified to determine whether the driver behavior integration event matches an event sub-rule.

[0119] In an embodiment of the present application, the event sub-rule includes multiple, and the second matching unit 40 is further used for:

[0120] Compare the driver behavior integration event with each event sub-rule separately;

[0121] When the comparison is consistent, it is determined that the driver behavior integration event matches the event sub-rule.

[0122] In one embodiment of the present application, the early warning unit 50 is further used for:

[0123] Determining a target event sub-rule matching the driver behavior integration event;

[0124] Determine the warning action corresponding to each of the target event sub-rules;

[0125] Based on the warning action, corresponding warning information is triggered to provide different warnings for the driver behavior integration event.

[0126] In one embodiment of the present application, the driver behavior event acquisition unit 10 is further used to:

[0127] The client obtains the driver's behavior events by burying the driver's behavior events;

[0128] The client sends the driver behavior event to Kafka, which in turn sends the driver behavior event to Flink through Kafka, so that Flink performs event aggregation and matching.

[0129] In an embodiment of the present application, by combining the back-end event configuration with the front-end reported events, and aggregating the event data, matching the events configured with the back-end and the event sub-rules, determining the early warning decision, and delivering the early warning decision to the client to implement the early warning, multiple events can be aggregated and issued through different early warning methods, providing accurate and diversified delivery methods.

[0130] For the specific definition of the travel safety warning device based on the driver's driving behavior, please refer to the definition of the travel safety warning method based on the driver's driving behavior above, which will not be repeated here. Each module in the above-mentioned travel safety warning device based on the driver's driving behavior can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0131] In one embodiment, a computer device is provided. The computer device may be a terminal device, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, a memory, and a network interface connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a readable storage medium. The readable storage medium stores computer-readable instructions. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer-readable instructions are executed by the processor, a travel safety warning method based on the driver's driving behavior is implemented. The readable storage medium provided in this embodiment includes a non-volatile readable storage medium and a volatile readable storage medium.

[0132] In an embodiment of the present application, a computer device is provided, including a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor. When the processor executes the computer-readable instructions, the steps of the trip safety warning method based on the driver's driving behavior as described above are implemented.

[0133] In an embodiment of the application, a readable storage medium is provided, wherein the readable storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by a processor, the steps of the trip safety warning method based on the driver's driving behavior as described above are implemented.

[0134] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing related hardware through computer-readable instructions, and the computer-readable instructions can be stored in a non-volatile readable storage medium or a volatile readable storage medium. When the computer-readable instructions are executed, they may include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0135] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0136] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A trip safety warning method based on driver's driving behavior, characterized in that: The method comprises: Obtaining a driver behavior event obtained by the client by burying the driver's behavior event, wherein the driver behavior event includes driver identification information; Based on the driver identification information, the driver behavior event is aggregated with the pre-stored driver behavior event to obtain a driver behavior integration event; Determine whether the driver behavior integration event matches the configuration event; If the driver behavior integration event matches the configured event, determining whether the driver behavior integration event matches the event sub-rule; If the driver behavior event matches the event sub-rule, corresponding warning information is output for the driver behavior integration event.

2. The method for early warning of driving safety of a driver according to claim 1, characterized in that: The step of aggregating the driver behavior event with pre-stored driver behavior events based on the driver identification information includes: Merge and store driver behavior events that belong to the same driver identification information; Determining whether the driver behavior event meets a preset aggregation condition; If the driver behavior event meets the preset aggregation condition, the driver behavior event is aggregated with the pre-stored driver behavior event.

3. The driver's driving behavior travel safety warning method according to claim 1, characterized in that: The determining whether the driver behavior integration event matches the configuration event includes: Get pre-configured configuration events; Comparing the driver behavior integration event with the configuration event one by one; When the comparison is consistent, it is determined that the driver behavior integration event matches the configuration event.

4. The driver's driving behavior travel safety warning method according to claim 1, characterized in that: The step of determining whether the driver behavior integration event matches the event sub-rule includes: Receive the kafka message of the driver behavior integration event; The driver behavior integration event is identified to determine whether the driver behavior integration event matches an event sub-rule.

5. The driver driving behavior travel safety warning method according to any one of claims 1 or 4, characterized in that: The event sub-rule includes a plurality of sub-rules, and the step of determining whether the driver behavior integration event matches the event sub-rule includes: Compare the driver behavior integration event with each event sub-rule separately; When the comparison is consistent, it is determined that the driver behavior integration event matches the event sub-rule.

6. The driver's driving behavior travel safety warning method according to claim 4, characterized in that: The outputting of corresponding warning information for the driver behavior integration event includes: Determining a target event sub-rule matching the driver behavior integration event; Determine the warning action corresponding to each of the target event sub-rules; Based on the warning action, corresponding warning information is triggered to provide different warnings for the driver behavior integration event.

7. The driver's driving behavior travel safety warning method according to claim 1, characterized in that: Get the driver behavior events obtained by the client by tracking the driver's behavior events, including: The client obtains the driver's behavior events by burying the driver's behavior events; The client sends the driver behavior event to Kafka, which in turn sends the driver behavior event to Flink through Kafka, so that Flink performs event aggregation and matching.

8. A trip safety warning system based on driver's driving behavior, characterized in that: The system comprises: A driver behavior event acquisition unit, used to acquire a driver behavior event obtained by the client by burying the driver's behavior event, wherein the driver behavior event includes driver identification information; A driver behavior event aggregation unit, configured to aggregate the driver behavior event with pre-stored driver behavior events based on the driver identification information to obtain a driver behavior integration event; A first matching unit, used to determine whether the driver behavior integration event matches the configuration event; a second matching unit, configured to determine whether the driver behavior integration event matches the event sub-rule if the driver behavior integration event matches the configuration event; The early warning unit is used to output corresponding early warning information for the driver behavior integration event if the driver behavior event matches the event sub-rule.

9. A computer device comprising a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor, characterized in that: When the processor executes the computer-readable instructions, the steps of the trip safety warning method based on the driver's driving behavior as described in any one of claims 1 to 7 are implemented.

10. A readable storage medium storing computer-readable instructions, characterized in that: When the computer-readable instructions are executed by the processor, the steps of the trip safety warning method based on the driver's driving behavior as described in any one of claims 1 to 7 are implemented.