WO2020169052A1

WO2020169052A1 - Systems and methods for driving condition identification

Info

Publication number: WO2020169052A1
Application number: PCT/CN2020/075879
Authority: WO
Inventors: Guanqiao HE; Wei Zhang; Jialin Zhang
Original assignee: Beijing Didi Infinity Technology And Development Co., Ltd.
Priority date: 2019-02-21
Filing date: 2020-02-19
Publication date: 2020-08-27
Also published as: CN111599164A; CN111599164B

Abstract

It may provide a method for identifying a driving condition of a vehicle. The method may include obtaining real-time status data in a driving process of the vehicle (1010), determining whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data to obtain a determination result (1020), determining risk information associated with the vehicle in the driving process based on the determination result (1030).

Description

SYSTEMS AND METHODS FOR DRIVING CONDITION IDENTIFICATION

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority of Chinese Patent Application No. 201910130722.1 filed on February 21, 2019, the contents of which are hereby incorporated by reference in its entirety.

TECHNICAL FIELD

The present disclosure generally relates to the field of security technology, and in particular, to systems and methods for driving condition identification.

BACKGROUND

With the rapid development of an online-to-offline service platform, more and more users may call a vehicle on the online-to-offline service platform, and the probabilities of accidents occurring in a driving process of the vehicle may increase. In order to ensure the personal safety of a driver and passenger, driving condition identification of the vehicle may be necessary. Therefore, it is desirable to provide systems and methods for accurately identifying whether the vehicle is in an abnormal driving condition in the driving process.

SUMMARY

In one aspect of the present disclosure, a system configured to identify a driving condition of a vehicle may be provided. The system may include at least one storage medium including a set of instructions; and at least one processor in communication with the at least one storage medium, wherein when executing the set of instructions, the at least one processor may be directed to: obtain real-time status data in a driving process of the vehicle; determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data to obtain a determination result; and determine risk information associated with the vehicle in the driving process based on the determination result.

In another aspect of the present disclosure, a system configured to identify a driving condition of a vehicle may be provided. The system may include at least one storage medium including a set of instructions; and at least one processor in communication with the at least one storage medium, wherein when executing the set of instructions, the at least one processor may be directed to: obtain real-time status data in a driving process of the vehicle; and determine risk information associated with the vehicle in the driving process using a driving condition identification model based on the real-time status data.

In another aspect of the present disclosure, a method for identifying a driving condition of a vehicle may be provided. The method may be implemented on a computing device having at least one processor and at least one storage device. The method may include: obtaining real-time status data in a driving process of the vehicle; determining whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data to obtain a determination result; and determining risk information associated with the vehicle in the driving process based on the determination result.

In another aspect of the present disclosure, a method for identifying a driving condition of a vehicle may be provided. The method may be implemented on a computing device having at least one processor and at least one storage device. The method may include: obtaining real-time status data in a driving process of the vehicle; and determining risk information associated with the vehicle in the driving process using a driving condition identification model based on the real-time status data.

In another aspect of the present disclosure, a system configured to identify a driving condition of a vehicle may be provided. The system may include: a data obtaining module configured to obtain real-time status data in a driving process of the vehicle; a risk determination module configured to determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data to obtain a determination result; and the risk determination module further configured to determine risk information associated with the vehicle in the driving process based on the determination result.

In another aspect of the present disclosure, a system configured to identify a driving condition of a vehicle may be provided. The system may include: a data obtaining module configured to obtain real-time status data in a driving process of the vehicle; and a risk determination module configured to determine risk information associated with the vehicle in the driving process using a driving condition identification model based on the real-time status data.

In another aspect of the present disclosure, a device for identifying a driving condition of a vehicle may be provided. The device may include at least one storage device configured to store a set of instructions; and at least one processor configured to execute the set of instructions and perform a method for identifying the driving condition of the vehicle. The method may include: obtaining real-time status data in a driving process of the vehicle; determining whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data to obtain a determination result; and determining risk information associated with the vehicle in the driving process based on the determination result.

In another aspect of the present disclosure, a device for identifying a driving condition of a vehicle. The device may include at least one storage device configured to store a set of instructions; and at least one processor configured to execute the set of instructions and perform a method for identifying the driving condition of the vehicle. The method may include: obtaining real-time status data in a driving process of the vehicle; and determining risk information associated with the vehicle in the driving process using a driving condition identification model based on the real-time status data.

In another aspect of the present disclosure, a non-transitory computer readable medium may be provided. The non-transitory computer readable medium may include at least one set of instructions for identifying a driving condition of a vehicle, wherein when executed by one or more processors of a computing device, the at least one set of instructions may cause the computing device to perform a method. The method may include: obtaining real-time status data in a driving process of the vehicle; determining whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data to obtain a determination result; and determining risk information associated with the vehicle in the driving process based on the determination result.

In another aspect of the present disclosure, a non-transitory computer readable medium may be provided. The non-transitory computer readable medium may include at least one set of instructions for identifying a driving condition of a vehicle, wherein when executed by one or more processors of a computing device, the at least one set of instructions may cause the computing device to perform a method. The method may include: obtaining real-time status data in a driving process of the vehicle; and determining risk information associated with the vehicle in the driving process using a driving condition identification model based on the real-time status data.

Additional features will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following and the accompanying drawings or may be learned by production or operation of the examples. The features of the present disclosure may be realized and attained by practice or use of various aspects of the methodologies, instrumentalities, and combinations set forth in the detailed examples discussed below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is further described in terms of exemplary embodiments. These exemplary embodiments are described in detail with reference to the drawings. These embodiments are non-limiting exemplary embodiments, in which like reference numerals represent similar structures throughout the several views of the drawings, and wherein:

FIG. 1 is a schematic diagram illustrating an exemplary driving condition identification system according to some embodiments of the present disclosure;

FIG. 2 is a schematic diagram illustrating exemplary hardware and/or software components of a mobile device on which a terminal is implemented according to some embodiments of the present disclosure;

FIG. 3 is a block diagram illustrating an exemplary driving condition identification system according to some embodiments of the present disclosure;

FIG. 4 is a flowchart illustrating an exemplary process for preventing a risk according to some embodiments of the present disclosure;

FIG. 5 is a flowchart illustrating an exemplary process for identifying a driving condition of a vehicle according to some embodiments of the present disclosure;

FIG. 6 is a flowchart illustrating another exemplary process for identifying a driving condition of a vehicle according to some embodiments of the present disclosure;

FIG. 7 is a flowchart illustrating an exemplary process for generating a driving condition identification model according to some embodiments of the present disclosure;

FIG. 8 is a flowchart illustrating an exemplary process for determining risk information associated with a vehicle using a driving condition identification model according to some embodiments of the present disclosure;

FIG. 9 is a schematic diagram illustrating exemplary hardware and software components of a computing device according to some embodiments of the present disclosure; and

FIG. 10 is a flowchart illustrating an exemplary process for determining risk information associated with a vehicle according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the present disclosure, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. Thus, the present disclosure is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the claims.

The terminology used herein is to describe particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a, " "an, " and "the" may be intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprise, " "comprises, " and/or "comprising, " "include, " "includes, " and/or "including, " when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

These and other features, and characteristics of the present disclosure, as well as the methods of operation and functions of the related elements of structure and the combination of parts and economies of manufacture, may become more apparent upon consideration of the following description with reference to the accompanying drawings, all of which form a part of this disclosure. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended to limit the scope of the present disclosure. It is understood that the drawings are not to scale.

The flowcharts used in the present disclosure illustrate operations that systems implement according to some embodiments in the present disclosure. It is to be expressly understood, the operations of the flowchart may be implemented not in order. Conversely, the operations may be implemented in inverted order, or simultaneously. Moreover, one or more other operations may be added to the flowcharts. One or more operations may be removed from the flowcharts.

Moreover, while the system and method in the present disclosure are described primarily in regard to identifying a driving condition of a vehicle associated with a transportation service, it should also be understood that the present disclosure is not intended to be limiting. The system or method of the present disclosure may be applied to any other kind of services. For example, the system or method of the present disclosure may be applied to transportation systems of different environments including land, ocean, aerospace, or the like, or any combination thereof. The vehicle of the transportation systems may include a taxi, a private car, a hitch, a bus, a train, a bullet train, a high-speed rail, a subway, a vessel, an aircraft, a spaceship, a hot-air balloon, a driverless vehicle, or the like, or any combination thereof. The transportation system may also include any transportation system for management and/or distribution, for example, a system for sending and/or receiving an express. The application of the system or method of the present disclosure may be implemented on a user device and include a webpage, a plug-in of a browser, a client terminal, a custom system, an internal analysis system, an artificial intelligence robot, or the like, or any combination thereof. It should be understood that the application scenarios of the system and method of the present disclosure are merely some examples or embodiments of the present disclosure. For those of ordinary skill in the art, the present disclosure may also be applied to other similar scenarios based on these drawings without creative work.

The term "passenger, " "requester, " “requestor, ” "service requester, " "service requestor, " and "customer" in the present disclosure are used interchangeably to refer to an individual, an entity, or a tool that may request or order a service. Also, the term "driver, " "provider, " and "service provider" in the present disclosure are used interchangeably to refer to an individual, an entity, or a tool that may provide a service or facilitate the providing of the service. The term "user" may refer to an individual, an entity or a tool that may request a service, order a service, provide a service, or facilitate the providing of the service.

The term "service request, " "request for a service, " "requests, " and "order" in the present disclosure are used interchangeably to refer to a request that may be initiated by a passenger, a service requester, a customer, a driver, a provider, a service provider, or the like, or any combination thereof. The service request may be accepted by any one of a passenger, a service requester, a customer, a driver, a provider, or a service provider. The service request may be chargeable or free.

The term "service provider terminal, ” " terminal of a service provider, ” “provider terminal, ” and "driver terminal" in the present disclosure are used interchangeably to refer to a mobile terminal that is used by a service provider to provide a service or facilitate the providing of the service. The term "service requester terminal, " "terminal of a service requester, " “requester terminal, ” and "passenger terminal" in the present disclosure are used interchangeably to refer to a mobile terminal that is used by a service requester to request or order a service.

It should be noted that a first speed range, a second speed range, a third speed range, a fourth speed range and/or a fifth speed range used in the present disclosure may be the same or different and have no relation. The first speed range, the second speed range, the third speed range, the fourth speed range and/or the fifth speed may be default settings in the system 100, or set by the system 100 or a user of the system 100.

FIG. 1 is a schematic diagram illustrating an exemplary driving condition identification system 100 according to some embodiments of the present disclosure. The driving condition identification system 100 (or referred to as the system 100 in brevity) may be configured to determine whether a vehicle is in an abnormal driving condition in a driving process of the vehicle and/or obtain a determination result. The system 100 may determine risk information associated with the vehicle in the driving process based on the determination result. In some embodiments, the system 100 may determine and/or perform at least one risk response operation to reduce harm to a user (e.g., a driver, a passenger) associated with the vehicle. For example, based on speed data of the vehicle, the driving condition identification system 100 may determine whether the vehicle is at risk in the driving process, such as a rollover of the vehicle or a collision of the vehicle. The driving condition identification system 100 may be a service platform implemented over the Internet or other networks. For example, the driving condition identification system 100 may be an online service platform that provides a transportation service such as a taxi-hailing service, a chauffeur service, an express car service, a carpool service, a bus service, a driver hire service, a shuttle service, etc. In some embodiments, the driving condition identification system 100 may be an online service platform that provides a meal delivery service, a delivery service, a meal service, a shopping service, etc. In some embodiments, the driving condition identification system 100 may be an online service platform that provides a housekeeping service, a travel service, an education (e.g., offline education) service, etc. As shown in FIG. 1, the driving condition identification system 100 may include a processing device 110, one or more terminal (s) 120 (or referred to as user terminal (s) 120) , a storage device 130, a network 140, and/or an information source 150.

In some embodiments, the processing device 110 may process data and/or information obtained from the one or more terminal (s) 120, the storage device 130, and/or the information source 150. For example, the processing device 110 may obtain location information, trajectory information of the one or more terminal (s) 120, and/or feature information of a user (e.g., a driver, a passenger) related to a trip of a service order (also referred to as an “order” ) . As another example, the processing device 110 may obtain real-time status data (e.g., speed data of the vehicle) in a driving process of the vehicle from the terminal (s) 120, the storage device 130, and/or the information source 150. The processing device 110 may process the obtained information and/or data to perform one or more functions described in the present disclosure. For example, the processing device 110 may process the real-time status data to determine whether the vehicle is in the abnormal condition in the driving process. The processing device 110 may also determine risk information based on a risk determination rule and/or a driving condition identification model, and/or obtain a risk identification result based on the determination result. As another example, the processing device 110 may determine risk information based on a risk determination rule and/or a driving condition identification model based on the real-time status data. In some embodiments, the processing device 110 may also determine at least one risk response operation, such as alarming and/or providing offline support according to the risk identification result. In some embodiments, the processing device 110 may obtain service order data. The service order data may include data relating to a service order, for example, one or more features of the service order, real-time status data of the service order generated during the service order execution, one or more historical records associated with at least one piece of the service order data, etc. In some embodiments, the processing device 110 may process the service order data based on the risk determination rule and/or determine the risk identification result (e.g., a rollover of the vehicle, a collision of the vehicle) . For example, the processing device 110 may determine whether the vehicle is in an abnormal driving condition in the driving process (e.g., whether an event that affects personal safety such as a collision or rollover of the vehicle occurs) based on a first speed range and the speed data. In some embodiments, the processing device 110 may perform at least one risk response operation based on the risk identification result.

In some embodiments, the processing device 110 may be an independent server or a server group. The server group may be centralized, or distributed (e.g., the processing device 110 may be a distributed device) . In some embodiments, the processing device 110 may be local or remote. For example, the processing device 110 may access the information and/or data stored in the terminal (s) 120, the storage device 130, and/or the information source 150 via the network 140. In some embodiments, the processing device 110 may be directly connected to the terminal (s) 120, the storage device 130, and/or the information source 150 to access the information and/or data stored therein. In some embodiments, the processing device 110 may be implemented on a cloud platform. Merely by way of example, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an inter-cloud, a multi-cloud, or the like, or any combination thereof. In some embodiments, the processing device 110 may be implemented on the terminal (s) 120.

In some embodiments, the processing device 110 may include one or more sub-processing devices (e.g., signal-core processing engine (s) or multi-core processor (s) ) . Merely by way of example, the processing device 110 may include a central processor (CPU) , an application-specific integrated circuit (ASIC) , a special-purpose instruction processor (ASIP) , a graphics processor (GPU) , a physical processor (PPU) , a digital signal processor (DSP) , a field-programmable gate array (FPGA) , an editable logic circuit (PLD) , a controller, a microcontroller unit, a reduced instruction set computer (RISC) , a microprocessor, or the like, or any combination thereof.

In some embodiments, each of the terminal (s) 120 may be a device with data acquisition, storage, and/or sending functions, and/or may be associated with a user (e.g., any service requester, any service provider) . A terminal 120 may include a terminal that is not directly involved in a service, a terminal of the service provider (also referred to as “service provider terminal” ) , a terminal of the service requester (also referred to as “service requester terminal” ) , a vehicle-mounted terminal, etc. The service provider may be an individual, a tool, or an entity that may provide a service or facilitate the providing of the service. The service requester may be an individual, a tool, or an entity that may request or order the service, or be receiving the service. For example, for a transportation service, the service provider may be a driver, a third-party platform. The service requester may be a passenger, another person, or a device (e.g., an Internet of Things device) that receives similar services.

In some embodiments, the terminal (s) 120 may be configured to collect various types of data including, for example, service-related data (also referred to as service order data) . For example, the data collected by the terminal (s) 120 may include data related to an order (e.g., an order request time, a start location and destination, service requester information (e.g., passenger information) , service provider information (e.g., driver information) , vehicle information, etc. ) , data related to a vehicle in a driving process (e.g., a speed of the vehicle, an acceleration of the vehicle, a posture of the vehicle, a road condition associated with the vehicle, etc. ) , data related to a trip (e.g., a preset route, an actual driving route, a cost, etc. ) , data related to service participants (e.g., service provider (s) , service requester (s) ) (e.g., personal information of the participants, information of operations performed by the service provider/service requester on the terminal (s) 120, data related to the terminal device, etc. ) , or the like, or any combination thereof. The collected data may be real-time data or historical data. The terminal (s) 120 may collect the data obtained by a sensor (e.g., a vehicle-mounted sensor) disposed on the vehicle, a sensor external to the vehicle. The terminal (s) 120 may also read data stored in its storage device or the storage device 150 via the network 140. In some embodiments, the sensor may include a positioning device, a sound sensor, an image sensor, a temperature and/or humidity sensor, a position sensor, a pressure sensor, a distance sensor, a speed sensor, an acceleration sensor, a gravity sensor, a displacement sensor, a torque sensor, a gyroscope, or the like, or any combination thereof. The various types of data collected by the terminal (s) 120 may be configured to identify dangerous event (s) and/or abnormal driving condition (s) that occur in the driving process of the vehicle within the service time. For example, based on driving trajectory data, whether there is an abnormal stop (e.g., during the service and/or after the service) at a location in the driving process, whether the signal of the user terminal is lost on a road section, whether the service is terminated in advance without arriving at the destination, whether the vehicle deviates from a preset route, whether the vehicle drives to a remote area, whether the vehicle stops multiple times in the trip, whether the driving speed is slow, whether the driving time exceeds a threshold, etc., may be determined. As another example, whether the vehicle is at risk (such as a collision or a rollover) may be determined according to the changes of the posture, the speed, and/or the acceleration of the vehicle, etc.

In some embodiments, the terminal (s) 120 may include a tablet computer 120-1, a laptop computer 120-2, a built-in device in a vehicle 120-3, a mobile device 120-4, or the like, or any combination thereof. In some embodiments, the mobile device 120-4 may include a smart home device, a wearable device, a smart mobile device, a virtual reality device, an augmented reality device, or the like, or any combination thereof. In some embodiments, the wearable device may include a smart bracelet, a smart footgear, smart glasses, a smart helmet, a smart watch, smart clothing, a smart backpack, a smart accessory, or the like, or any combination thereof. In some embodiments, the smart mobile device may include a smartphone, a personal digital assistant (PDA) , a gaming device, a navigation device, a point of sale (POS) device, or the like, or any combination thereof. The built-in device in the vehicle 120-3 may include a vehicle-mounted computer, a vehicle data logger, a vehicle-mounted human-machine interaction (HCI) system, a driving recorder, a vehicle-mounted television, or the like, or any combination thereof.

In some embodiments, the built-in device in the vehicle 120-3 may obtain component data and/or operating data of the vehicle, such as a speed of the vehicle, an acceleration of the vehicle, a driving direction of the vehicle, a component state of the vehicle, the surrounding environment of the vehicle, or the like, or any combination thereof. The obtained data may be configured to determine, for example, whether the vehicle is in an abnormal driving condition in a driving process of the vehicle, risk information associated with the vehicle, whether a driving accident (e.g., a rollover, a collision) occurs, whether a vehicle is broken (e.g., an engine or a transmission part of the vehicle is broken such that the vehicle cannot move) , or the like, or any combination thereof.

In some embodiments, the terminal (s) 120 may be one or more devices with a positioning technology for positioning the location (s) of the terminal (s) 120. In some embodiments, the terminal (s) 120 may transmit the collected data/information to the processing device 110 via the network 140 for subsequent operations. In some embodiments, the terminal (s) 120 may also store the collected data/information in its storage device, or transmit the collected data/information to the storage device 130 via the network 140 for storage. The terminal (s) 120 may also receive and/or display notifications related to risk prevention generated by the processing device 110. In some embodiments, a plurality of terminals may be connected to each other, collect various types of data together, and preprocess the data by one or more terminals of the plurality of terminals.

The storage device 130 may store data and/or instructions. In some embodiments, the storage device 130 may store data/information obtained by the terminal (s) 120. The storage device 130 may also store historical service order data, such as one or more historical features of a historical service order, historical status data of a vehicle associated with the historical service order, a historical record associated with at least one piece of the historical service order data, etc. In some embodiments, the storage device 130 may store data and/or instructions that the processing device 110 may execute or use to complete the exemplary processes described in the present disclosure. For example, the storage device 130 may store a driving condition identification model, which may be used to determine whether the transportation service is at risk based on the data/information related to the transportation service obtained by the processing device 110. In some embodiments, the storage device 130 may store various types of real-time data or historical data of the user terminal, for example, historical records of historical users related to historical services (e.g., such as historical evaluations) . In some embodiments, the storage device 130 may be a part of the processing device 110 or the terminal (s) 120.

In some embodiments, the storage device 130 may include a mass storage device, a removable storage device, a volatile read-write memory, a read-only memory (ROM) , or the like, or any combination thereof. Exemplary mass storage devices may include a magnetic disk, an optical disk, solid-state disks, etc. Exemplary removable storage devices may include a flash drive, a floppy disk, an optical disk, a memory card, a zip disk, a magnetic tape, etc. Exemplary volatile read-and-write memory may include a random access memory (RAM) . Exemplary RAM may include a dynamic RAM (DRAM) , a double date rate synchronous dynamic RAM (DDR SDRAM) , a static RAM (SRAM) , a thyristor RAM (T-RAM) , and a zero-capacitor RAM (Z-RAM) , etc. Exemplary ROM may include a mask ROM (MROM) , a programmable ROM (PROM) , an erasable programmable ROM (EPROM) , an electrically erasable programmable ROM (EEPROM) , a compact disk ROM (CD-ROM) , and a digital versatile disk ROM, etc.

In some embodiments, the storage device 130 may be implemented on a cloud platform. Merely by way of example, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an inter-cloud, a multi-cloud, or the like, or a combination thereof. For example, some algorithms or data for risk determination in the present disclosure may be stored on a certain cloud platform and/or periodically updated. The processing device 110 may access the algorithms or the data via the network 140 to achieve the unification and interaction of the algorithms or the data of the entire platform. In some embodiments, some historical data may be uniformly stored on the cloud platform so as to be accessed or updated by the processing devices 110 or the terminal (s) 120, thereby ensuring the data to be used in real-time by one or more platforms. For example, the terminal (s) 120 may transmit speed information and location information of the terminal (s) 120 to a cloud platform at any time. The system 100 may determine whether the vehicle is in an abnormal driving condition in the driving process according to feedback (s) from the terminal (s) 120.

In some embodiments, the storage device 130 may be connected to the network 140 to communicate with one or more components (e.g., the processing device 110, the terminal (s) 120, the information source 150) in the driving condition identification system 100. In some embodiments, the one or more components in the driving condition identification system 100 may access data or instructions stored in the storage device 130 via the network 140. In some embodiments, the storage device 130 may be directly connected to or communicated with one or more components (e.g., the processing device 110, the terminal (s) 120, the information source 150) in the driving condition identification system 100. In some embodiments, the storage device 130 may be a part of the processing device 110.

The network 140 may facilitate the exchange of information and/or data. In some embodiments, one or more components (e.g., the processing device 110, the terminal (s) 120, the storage device 130, the information source 150) in the driving condition identification system 100 may send and/or receive information and/or data to/from other components in the driving condition identification system 100 via the network 140. For example, the processing device 110 may obtain data/information related to the transportation service from the terminal (s) 120 and/or the information source 150 via the network 140. As another example, the processing device 110 may obtain real-time status data in a driving process of the vehicle. As a further example, the terminal (s) 120 may obtain a driving condition identification model for determining whether the vehicle is at risk from the processing device 110 or the storage device 130 via the network 140. The driving condition identification model may be implemented by an application software of the terminal (s) 120. After obtaining the data/information related to the transportation service, the terminal (s) 120 may determine whether the transportation service (or a vehicle thereof) is at risk and perform at least one risk response operation, for example, activating a telephone alarm.

In some embodiments, the network 140 may be any type of wired or wireless network, or combination thereof. Merely by way of example, the network 140 may include a cable network, a wireline network, an optic fiber network, a telecommunications network, an intranet, an internet, a local area network (LAN) , a wide area network (WAN) , a wireless local area network (WLAN) , a metropolitan area network (MAN) , a wide area network (WAN) , a public switched telephone network (PSTN) , a Bluetooth network, a Zigbee network, a near field communication (NFC) network, a global system for mobile communications (GSM) network, a code division multiple access (CDMA) network, a time division multiple access (TDMA) network, a general packet radio service (GPRS) network, an enhanced data rate GSM evolution (EDGE) network, a wideband code division multiple access (WCDMA) networks, a high speed downlink packet access (HSDPA) network, a long term evolution (LTE) network, a user datagram protocol (UDP) network, a transmission control protocol/Internet protocol (TCP/IP) network, a short message service (SMS) network, a wireless application protocol (WAP) network, an ultra-wide band (UWB) network, a mobile communication (1 G, 2G, 3G, 4G, 5G) a Wi-Fi, a Li-Fi, a narrowband Internet of Things (NB-IoT) , or the like, or any combination thereof. In some embodiments, the driving condition identification system 100 may include one or more network access points. For example, the driving condition identification system 110 may include wired or wireless network access points, via which one or more components of the driving condition identification system 100 may be connected to the network 140 to exchange data and/or information.

The information source 150 may be configured to provide information to the driving condition identification system 100. In some embodiments, the information source 150 may be configured to provide real-time status data in a driving process of the vehicle, information related to the transportation service (e.g., weather conditions, transportation information, geographic information, law information and regulation information, news events, life information, life guide information, etc. ) to the driving condition identification system 100. In some embodiments, the information source 150 may be a third-party platform that may provide credit records (e.g., loan records) of the service requester and/or the service provider. In some embodiments, the information source 150 may be configured to provide information related to driving condition identification (e.g., driving safety information, personal safety information, property safety information, etc. ) for the driving condition identification system 100. The information source 150 may be implemented in a single central server, a plurality of servers or a plurality of user terminals that are connected with each other via a communication link. If the information source 150 is implemented in the plurality of user terminals, the user terminals may generate content (or referred to as "user-generated content" ) by, for example, uploading texts, voices, images, and/or videos to a cloud server. The information source 150 may include a plurality of user terminals and/or cloud servers. The storage device 130, the processing device 110, and/or the terminal (s) 120 may also be used as the information source 150 or a portion thereof. For example, the terminal (s) 120 may be used as an information source to provide information on traffic conditions for other devices (e.g., the processing device 110) of the system 100.

FIG. 2 is a schematic diagram illustrating exemplary hardware and/or software components of the mobile device 200 on which the terminal (s) 120 may be implemented according to some embodiments of the present disclosure. As shown in FIG. 2, the mobile device 200 may include a communication unit 210, a display unit 220, a graphics processing unit (GPU) 230, a central processing unit (CPU) 240, an input/output (I/O) 250, a memory 260, a storage 270, and a plurality of sensors 280. In some embodiments, any other suitable components, including, for example, a system bus or controller (not shown) , may also be included in the mobile device 200.

In some embodiments, the mobile operating system 262 (e.g., IOS ^TM, Android ^TM, Windows Phone ^TM, etc. ) and one or more applications 264 may be loaded from the storage 290 into the memory 260 in order to be executed by the CPU 240. The application (s) 264 may include a browser or any other suitable mobile applications for sending data/information associated with the transportation service, and/or receiving and/or displaying information processed by or related to the driving condition identification system 100. For example, the application (s) 264 may be an online transportation platform (e.g., Didi Travel ^TM) . A user (e.g., a service requester) may request a transportation service via the application (s) 264 and send the requested information to the server (e.g., the processing device 110) . User interaction with information stream (s) may be achieved via the I/O 250 and/or provided to the processing device 110 and/or other components of the driving condition identification system 100 via the network 140.

In some embodiments, the mobile device 200 may also include the plurality of sensors 280. The sensors 280 may obtain data, for example, real-time status data in a driving process of the vehicle, data related to service participants (e.g., drivers/passengers) , data related to the vehicle, data related to a trip associated with a service order, etc. In some embodiments, the sensors 280 may include a sound sensor, an image sensor, a temperature and/or humidity sensor, a position sensor, a pressure sensor, a distance sensor, a speed sensor, an acceleration sensor, a gravity sensor, a displacement sensor, a torque sensor, a gyroscope, or the like, or any combination thereof. In some embodiments, data obtained by the sensors 280 may be used to determine whether the vehicle is in the abnormal driving condition and/or obtain a determination result. In some embodiments, risk information associated with the vehicle in the process may be determined based on the determination result. In some embodiments, data obtained by the sensors 280 may be configured to determine whether the vehicle is at risk and/or determine the type of the risk. For example, the sound sensor may collect conversations between service participants. The image sensor may collect real-time scenes in the vehicle to determine whether there is a driver-passenger conflict or a property/personal safety event, for example, physical conflict, drunk driving, robbery, sexual assault, sexual harassment, etc. As another example, the position sensor may collect the real-time location of the vehicle. The displacement sensor may collect a driving trajectory of the vehicle to determine whether the vehicle is in an abnormal driving condition in the driving process, such as an abnormal stop, deviation from a preset route, an abnormal driving time, etc. As a further example, the speed sensor, the acceleration sensor, and/or the gyroscope may collect a real-time speed of the vehicle, a real-time acceleration of the vehicle, a deflection amount of the terminal (s) 120, a deflection frequency of the terminal (s) 120, etc., and such information may be used to determine whether the vehicle is involved with an accident (e.g., a collision of the vehicle or a rollover of the vehicle) .

In some embodiments, the mobile device 200 may communicate (e.g., through Bluetooth communication) with the vehicle to obtain data (e.g., driving data of the vehicle, real-time status data) collected by the sensors disposed on the vehicle and/or the user terminal. The mobile device 200 may merge the data obtained from the sensor (s) disposed on the user terminal and the data obtained from the vehicle-mounted sensor (s) for subsequent risk identification.

In some embodiments, the mobile device 200 may send the obtained data/information (e.g., the data obtained from the sensor (s) (e.g., the vehicle-mounted sensor (s) ) disposed on the user terminal) to the processing device 110 of the driving condition identification system 100 for risk determination and/or at least one risk response operation via the network 140. In some embodiments, the mobile device 200 may directly perform the risk determination and the risk response operation. For example, the application (s) 264 may include codes or modules for risk determination, and/or may directly perform the risk determination and/or the risk response operation. In some embodiments, the processing device 110 and/or the mobile device 200 of the driving condition identification system 100 may further generate a notified instruction according to the risk identification result and/or the risk response operation. The mobile device 200 may remind a user in a current status by receiving and/or executing the notified instruction. For example, the mobile device 200 may remind the user of a notification through voice (e.g., via a speaker) , vibration (e.g., via a vibrator) , text (e.g., via a short message service or a social application) , flashing lights (e.g., via a flash or display unit 220) , or the like, or any combination thereof.

In some embodiments, users (e.g., drivers and/or passengers) of the mobile device 200 may perform the risk determination manually. Specifically, the drivers and/or passengers may report risk (s) through the application (s) 264 in the mobile device 200. For example, a user may perform a specific operation (e.g., shaking or throwing) using the mobile device 200 to initiate an alarm procedure. As another example, an interface of application (s) 264 may include a quick entry (e.g., an alarm button, a help button) configured to directly communicate with a back-end security platform. Upon determining that a user is in a dangerous situation, the user may call another party (e.g., the police) by clicking the alarm button. After or when the alarm is initiated, the application (s) 264 may send the current location and/or trip information of the user who imitates the alarm to the called party to assist the rescue.

To implement various modules, units, and functionalities described in the present disclosure, computer hardware platforms may be used as the hardware platform (s) for one or more of the components described herein. A computer with user interface elements may be configured to implement a personal computer (PC) or any other type of work station or terminal device, although a computer may also act as a server if appropriately programmed.

FIG. 3 is a block diagram illustrating an exemplary processing device 110 according to some embodiments of the present disclosure. As shown in FIG. 3, the processing device 110 may include a data obtaining module 310, a risk determination module 320, a training module 330, a risk response module 340, and an update module 350. In some embodiments, the data obtaining module 310, the risk determination module 320, the training module 330, the risk response module 340, and the update module 350 may be disposed in the processing device 110.

In some embodiments, the data obtaining module 310 may obtain service order data of at least one service order. A service order may be a transportation service order (e.g., a cargo transportation order, a travel service order) that is requested, being executed, and/or completed. The service order data may include one or more features of the service order, real-time status data of a vehicle associated with the service order, a historical record associated with at least one piece of the service order data. The one or more features of the service order may include information recorded in the service order including, for example, identity information of a service provider associated with the service order, identity information of a vehicle associated with the service order, a service time of the service order, a start location of a trip of the service order, a destination of a trip of the service order, a route of a trip of the service order, identity information of a service requester of the service order, an estimated cost of the service order, or the like, or any combination thereof. The real-time status data may refer to status data of a device (e.g., the vehicle) associated with the service order and/or data associated with the surrounding environment of a user inside the vehicle or the vehicle. The real-time status data may include, for example, location data of one or more terminals associated with the service order, status data of one or more terminals associated with the service order, status data of the vehicle, data associated with the internal environment of the vehicle, data associated with the surrounding environment of the vehicle, or the like, or any combination thereof. The historical record associated with the at least one piece of the service order data may include a historical record corresponding to a piece of data in a historical service order, for example, a historical record of a historical service provider executing a historical service order, a credit record of a historical service provider, a service requester's participation record of a historical service order, a credit record of a service requester, or the like, or any combination thereof.

In some embodiments, the data obtaining module 310 may obtain real-time status data in a driving process of the vehicle. The real-time status data may at least include speed data of the vehicle. In some embodiments, the real-time status data in the driving process of the vehicle may further at least include location data of the vehicle, status data of a user terminal associated with the vehicle, data associated with internal environment of the vehicle, data associated with surrounding environment of the vehicle, or the like, or any combination thereof. In some embodiments, the speed data of the vehicle may include a speed and/or an acceleration of the vehicle. The speed data of the vehicle may be obtained via a sensor disposed on the vehicle (e.g., a vehicle-mounted sensor) and/or a user terminal. In some embodiments, the data obtaining module 310 may obtain the service order data by communicating with the terminal (s) 120, the storage device 130, and/or the information source 150 (e.g., via the network 140) . The data obtaining module 310 may transmit the service order data to the risk determination module 320 to determine a type of a risk.

In some embodiments, the data obtaining module 310 may obtain real-time status data in a driving process of the vehicle. For example, the real-time status data may include speed data of the vehicle, location data of the vehicle, status data of a user terminal associated with the vehicle, data associated with internal environment of the vehicle, data associated with surrounding environment of the vehicle, data associated with a driving behavior of the vehicle, or power data of the vehicle. In some embodiments, the data obtaining module 310 may obtain the real-time status data based on service order data associated with the vehicle in the driving process.

In some embodiments, the data obtaining module 310 may also obtain historical service order data. In some embodiments, vehicle (s) associated with one or more historical transportation service orders may be at risk, and the historical service order data may include data related to such historical transportation service order (s) . The historical service order data may be similar to the service order data. The historical status data may be obtained based on the historical service order data and/or include a type of a risk corresponding to the historical transportation service order. Exemplary types of the risk may include a collision of the vehicle, a rollover of the vehicle, dangerous driving of the vehicle, or the like, or any combination thereof. In some embodiments, the historical service order data may be used as training data to train a driving condition identification model or determine a risk determination rule. The trained driving condition identification model or the risk determination rule may be used to analyze the service order data to determine whether the vehicle is at risk in a driving process of the vehicle. In some embodiments, the historical service order data may be stored in the storage device 130. The data obtaining module 310 may communicate with the storage device 130 (e.g., via the network 140) and/or obtain the historical service order data stored therein.

In some embodiments, the risk determination module 320 may determine whether the vehicle is in the abnormal driving condition in the driving process based on the real-time status data to obtain a determination result. The risk determination module 320 may also determine risk information associated with the vehicle in the driving process based on the determination result.

In some embodiments, the risk determination module 320 may be configured to perform a risk determination operation on a current status of the service order according to the risk determination rule. In some embodiments, the risk determination rule may include one or more conditions or thresholds set according to the historical service order data and/or the user experiences. The threshold (s) of the risk determination rule may be determined according to data statistics or an intermediate result obtained during the training of the driving condition identification model. For example, the risk determination module 320 may determine whether the vehicle is in an abnormal driving condition (e.g., a dangerous driving condition) , such as a collision of the vehicle, a rollover of the vehicle, by determining whether sensor data (e.g., an acceleration of gravity) exceeds a preset range. In some embodiments, the risk determination module 320 may be configured to determine whether the vehicle is in an abnormal driving condition in a driving process during a current trip of a current service order based on service order data of the current service order and/or status data (e.g., real-time status data) when the current service order is being executed.

In some embodiments, the risk determination module 320 may obtain a first piece of speed data collected by the vehicle-mounted sensor, and/or determine a first condition identification result based on the first piece of speed data. In some embodiments, the risk determination module 320 may obtain a second piece of speed data collected by the user terminal, and/or determine a second condition identification result based on the second piece of speed data. Exemplary user terminals may include a service provider terminal and/or a service requester terminal. The risk determination module 320 may determine whether the vehicle is in the abnormal driving condition in the driving process based on the first condition identification result and/or the second condition identification result. It should be noted that the first condition identification result and the second condition identification result may be the same or different and have no correlation. In some embodiments, the risk determination module 320 may process the real-time status data in the driving process of the vehicle using a driving condition identification model to determine the risk information of the abnormal driving (also referred to as “dangerous driving” ) . In some embodiments, the risk determination module 320 may input the real-time status data into the driving condition identification model, and the driving condition identification model may output the risk information of the abnormal driving.

In some embodiments, the risk determination module 320 may determine whether a variation of the speed data of the vehicle with time satisfies a first condition. For example, the first condition may include the variation of the speed being within a variation range from -10km/h to 10km/h. In response to determining that the variation satisfies the first condition, the risk determination module 320 may determine that the vehicle is at no risk. In some embodiments, the risk determination module 320 may determine whether the speed data of the vehicle exceeds a second speed range. For example, the second speed range may include a range from a minimum allowed speed of the vehicle to a maximum allowed speed of the vehicle. In response to determining that the speed data of the vehicle exceeds the second speed range, the risk determination module 320 may determine a duration time in which the speed data of the vehicle exceeds the second speed range. The risk determination module 320 may determine whether the duration time exceeds a time threshold. In response to determining that the duration time exceeds the time threshold, the risk determination module 320 may determine that the vehicle is at risk. In some embodiments, the risk determination module 320 may obtain the location data of the vehicle based on the real-time status data. The risk determination module 320 may determine a driving trajectory of the vehicle after the speed data of the vehicle exceeds a fourth speed range based on the location data of the vehicle. For example, the fourth speed range may include a range from a minimum allowed speed of the vehicle to a maximum allowed speed of the vehicle. The risk determination module 320 may determine the risk information associated with the vehicle based on the driving trajectory. In some embodiments, the risk determination module 320 may obtain, based on the real-time status data, data associated with a user behavior after the speed data of the vehicle exceeds a fifth speed range. For example, the fifth speed range may include a range from a minimum allowed speed of the vehicle to a maximum allowed speed of the vehicle. The risk determination module 320 may determine the risk information associated with the vehicle based on data associated with the user behavior. In some embodiments, the data associated with the user behavior may at least include one operation of the user in an application of a service platform (e.g., the application 264) . For example, if the user behavior indicates that the user still grabs an electronic red envelope in an application of the platform after the vehicle overspeeds, the risk determination module 320 may determine the vehicle is at no risk. As another example, if the user behavior indicates that the user (e.g., the service provider) accepts a service request (e.g., in a short time) after the vehicle overspeeds, the risk determination module 320 may determine the vehicle is at no risk. In some embodiments, the risk determination module 320 may obtain, based on the real-time status data, vehicle posture data after the speed data of the vehicle exceeds a third speed range. For example, the third speed range may include a range from a minimum allowed speed of the vehicle to a maximum allowed speed of the vehicle. In response to determining that the vehicle posture data satisfies a second condition, the risk determination module 320 may determine that the vehicle is at risk. For example, the second condition may include a rotation angle of the vehicle being within a range from 0 to a rotation angle when the vehicle turns, etc. It should be noted that the first condition and the second condition may be the same or different and have no correlation.

In some embodiments, the risk determination module 320 may use a driving condition identification model to perform risk determination (or identification) on a current status of the transportation service order and/or obtain a risk identification result. The driving condition identification model may be a machine learning model (e.g., a decision tree) . The driving condition identification model may be obtained after being trained based on historical service order data. For example, the driving condition identification model may be obtained by training a preliminary model based on the historical service order data. The model may be trained by inputting at least a part (e.g., a part, the whole) of the historical service order data into the preliminary model. Actual risk information (e.g., the type of risks such as a dangerous event or abnormal driving) of the historical service order data may be obtained and/or used as desired output (e.g., the ground truth of the historical service order data) of the preliminary model in the training process. In some embodiments, the driving condition identification model may be an integrated determination model configured to determine whether the vehicle is in one or more abnormal driving conditions (e.g., a collision of the vehicle, a rollover of the vehicle, dangerous driving of the vehicle, or the like, or any combination thereof) and/or obtain a determination result. For example, the processing device 110 may input the real-time status data and/or the service order data into the driving condition identification model, and the driving condition identification model may output the determination result. In some embodiments, the risk determination module 320 may determine the risk information associated with the vehicle in the driving process using the driving condition identification model. For example, the processing device 110 may input the determination result into the driving condition identification model, and the driving condition identification model may output the risk information. As another example, the processing device 110 may directly input the real-time status data and/or the service order data into the driving condition identification model, and the driving condition identification model may output the risk information. The driving condition identification model may be a regression-based machine learning model. In some embodiments, the driving condition identification model may process the service order data and/or the real-time status data in the driving process of the vehicle and output a result indicating the level of the risk, a probability of occurrence of risk, etc. The risk determination module 320 may determine one or more types of risks using a plurality of models. The plurality of models may be determined or used according to actual needs. For example, the plurality of models may include a rollover identification model configured to determine a rollover of a vehicle in a driving process, a collision identification model configured to determine a collision of the vehicle in the driving processing, etc.

In some embodiments, the risk identification result of the risk determination module 320 may include whether the vehicle is at risk and/or a quantitative representation of the risk. Merely by way of example, the risk identification result may include whether the vehicle is at risk, a type of the risk and a corresponding probability, a level of the risk and a corresponding probability, etc. For example, the determination result may indicate the vehicle is at risk and deviating from a preset route (e.g., at risk level 5) , or at risk and driving to a remote area (e.g., with a probability of 56%) and/or with abnormal stop (e.g., with a probability of 87%) . In some embodiments, the risk determination module 320 may comprehensively determine levels and/or probabilities of various types of risks and output an overall risk identification result corresponding to the comprehensive risk identification. For example, the risk identification result may indicate the vehicle is at risk (e.g., with a probability of 74%) . It should be noted that the representation of the risk identification result described above is only provided for illustrative purposes, and the present disclosure does not limit the scope of the risk identification result described above.

The training module 330 may determine the driving condition identification model. In some embodiments, the driving condition identification model may be configured to determine whether the vehicle is in the abnormal driving condition and/or the risk information associated with the vehicle in the driving process. In some embodiments, the training module 330 may obtain a plurality of historical orders. In some embodiments, the historical orders may be obtained from one or more components of the system 100 (e.g., the storage device 130, the processing device 110, the terminal (s) 120, the information source 150) via the network 140.

In some embodiments, the historical orders may also be referred to as historical service orders, such as historical orders of historical taxi-hailing services, historical chauffeur services, historical express car services, historical carpool services, historical bus services, historical driver hire services, historical shuttle services, etc. In some embodiments, the training module 330 may obtain the historical orders within a time period (e.g., a week, a month, etc. ) as training samples. In some embodiments, the historical orders may include completed orders, canceled orders, and/or other orders stored in the system 100.

In some embodiments, the training module 330 may obtain historical status data associated with historical driving processes of vehicles of the historical orders. In some embodiments, the training module 330 may label historical data with abnormal driving as positive samples and historical data without abnormal driving as negative samples. For example, if historical data of a historical order includes information of abnormal driving, the training module 330 may determine the historical data as a positive sample. Conversely, if historical data of a historical order does not include the information of abnormal driving, the training module 330 may determine the historical data as a negative sample. In some embodiments, the training module 330 may train the driving condition identification model based on the historical status data associated with the historical driving processes of the vehicles in the historical orders and the corresponding labeling results (also referred to as labels) . In some embodiments, the training module 330 may train the driving condition identification model by using historical speed data collected from vehicle-mounted sensors and/or historical speed data collected from user terminals associated with the historical orders as input and the labeling result of the positive samples and negative samples as desired output. In some embodiments, the driving condition identification model may be a machine learning model, including but is not limited to, a classification and logistic regression (LR) model, a k-nearest neighbor (kNN) model, a Naive Bayes (NB) model, a support vector machine (SVM) , a decision tree (DT) model, a random forest (RF) model, a classification and regression tree (CART) model, a gradient boosting decision tree (GBDT) model, a xgboost (or referred to as eXtreme Gradient Boosting) , a light gradient boosting machine (or referred to as LightGBM) , a gradient boosting machine (GBM) , a least absolute shrinkage and selection operator (LASSO) , an artificial neural network (ANN) model, etc.

In some embodiments, the risk response module 340 may be configured to perform at least risk response operation based on the risk identification result. In some embodiments, the risk response module 340 may include a risk ranking unit 342, a risk verification unit 344, a risk disposal unit 346, and/or a monitoring unit 348. The risk ranking unit 342 may rank the risk identification result (s) associated with the service order data based on a ranking rule. The risk ranking unit 342 may determine the ranking rule based on one or more risk parameters (e.g., a feature value such as a duration of an abnormal stop) in different risks. The risk ranking unit 342 may determine the ranking rule based on the risk probability and/or the level of the risk in the risk identification result associated with the historical service order data. The ranking rule may also include one or more ranking thresholds (e.g., a level threshold, a probability threshold, etc. ) . In some embodiments, the risk ranking unit 342 may rank the risk identification results according to the ranking thresholds, respectively. In some embodiments, the risk ranking unit 342 may determine the ranking rule based on a calculation result (e.g., a weighted mean) of a plurality of risk parameters. In some embodiments, the risk ranking unit 342 may rank the risk identification results using a ranking model. The ranking model may be a mathematical model and configured to obtain a risk ranking result based on feature values of different types of the risk and/or feature values of all risks (e.g., through weight calculation) . The ranking model may be a machine learning model, which may be obtained after being trained based on historical feature information associated with historical risks. In some embodiments, the risk verification unit 344 may input the risk identification results corresponding to the service orders into the trained risk ranking model to determine the ranking result. In some embodiments, the ranking result may indicate the ranking of the risk levels of the service orders. In some embodiments, the ranking result may indicate the ranking of the risk probability of the service orders. In some embodiments, the ranking result may be used to determine at least one risk response operation corresponding to the risk identification result.

In some embodiments, the risk ranking unit 342 may rank different types of risks, respectively. For example, the risk ranking unit 342 may rank orders with a same type of risks among the orders, so that the risk ranking unit 342 may obtain ranking results of different types of risks, respectively. In some embodiments, the risk ranking unit 342 may rank all types of risks synthetically. For example, the risk ranking unit 342 may set weights for different risks, and/or may comprehensively rank the orders of different risks according to the weights.

The risk verification unit 344 may perform risk verification. In some embodiments, the risk verification unit 344 may confirm the risks based on the ranking results of the risk ranking unit 342. For example, the risk verification unit 344 may select a preset count of orders that have relatively high rankings in the ranking results for the risk verification. In some embodiments, the risk verification unit 344 may directly confirm the risk based on the risk identification result of the risk determination module 320. For example, the risk verification unit 344 may perform the risk verification on orders that have risk identification results (e.g., risk levels, risk probabilities, etc. determined by the risk determination module 320) within a preset range. In some embodiments, the risk verification unit 344 may directly perform the risk verification on a plurality of (e.g., all) service orders.

In some embodiments, the risk verification operation may include risk verification through information interaction with the user, risk verification by the staff at the scene, obtaining audio or image information in the vehicle for the risk verification, risk verification based on traffic broadcast information, or the like, or any combination thereof. In some embodiments, the risk verification unit 344 may perform the risk verification manually. For an order with a potential risk, the driving condition identification system 100 may display information related to the order, and further confirm risk information of the order through a manual manner (e.g., a customer service) . In some embodiments, the risk verification unit 344 may perform the risk verification in an automated manner. For an order with a potential risk, the automatic risk verification unit 344 may confirm the risk through a call via an interactive voice response (IVR) , a popup displayed in a terminal, an application text, a voice inquiry or voice monitoring of an in-vehicle driver and/or passenger, in-car recording and reporting, etc. In some embodiments, the risk verification unit 344 may perform the risk verification through the manual interaction and/or automatic interaction. For an order with a potential risk, the risk verification unit 344 may perform the risk verification through telephone interaction with the user (e.g., the vehicle driver and/or passenger) .

The risk disposal unit 346 may perform a risk disposal operation. The risk disposal operation may include notifying emergency contacts, initiating data reporting by a service provider terminal and/or a service requester terminal, a follow-up alarm by a specialized person, or the like, or any combination thereof. In some embodiments, the risk disposal unit 346 may directly determine the risk disposal operation based on the risk identification result. For example, the risk disposal unit 346 may perform the risk disposal on high-risk orders and take different actions based on the risk probabilities of the service orders. For example, according to an algorithm, the risk disposal unit 346 may take an action on an order if the risk probability of the order exceeds 20%. For example, the risk disposal unit 346 may send prompt information to a user terminal associated with the service order to remind a user (e.g., a driver or a passenger) that there is a risk. In some embodiments, the risk disposal unit 346 may terminate the service if the risk probability is relatively high (e.g., higher than 90%) . In some embodiments, the risk disposal unit 346 may determine the risk disposal operation based on the risk ranking result (s) . For example, the risk disposal unit 346 may perform the risk disposal (e.g., send a certain person to follow up) on orders with the risk ranking in the top 30%. In some embodiments, the risk disposal unit 346 may determine the risk disposal operation based on the risk verification result. For example, the risk disposal unit 346 may perform risk disposal operations on orders that have been identified to be at risk. In some embodiments, the criteria and thresholds for the risk disposal may be updated by the update module 350, and/or dynamically adjusted based on the real-time conditions, the historical data, the feedback from the terminal (s) 120, etc.

In some embodiments, the risk disposal unit 346 may perform the risk disposal through a manner of risk research. The risk disposal unit 346 may obtain a service order and/or service order data relating to the service order that satisfy a condition for the risk research. The risk disposal unit 346 may obtain a risk identification result of the service order and/or risk information of the service order. The risk disposal unit 346 may determine whether a risk event occurs in the service order based on the risk identification result and/or the risk information by a researcher associated with the risk research.

In some embodiments, the risk disposal unit 346 may perform the risk disposal through a manner of risk rescue. The risk disposal unit 346 may determine whether a service order satisfies a risk rescue condition based on the risk identification result. In response to determining that the service order satisfies the risk rescue condition, the risk disposal unit 346 may generate and send rescue information. For example, for an order that is determined to be at risk, the risk disposal unit 346 may obtain its risk information (e.g., risk type, risk level, etc. ) . For an order whose risk level satisfies a level threshold, the risk disposal unit 346 may generate rescue information to notify surrounding drivers to go for helping or checking.

The monitoring unit 348 may monitor the service order (e.g., continuously) . The monitoring may be performed continuously on a service order that is determined to be risk-free (or at no risk) in the risk determination, a part of service orders that have relatively low ranking levels in the risk ranking results, a service order that is risk-free after risk verification, etc. In some embodiments, the monitoring unit 348 may determine a terminal associated with the service order based on the service order data to be continuously monitored. The terminal may be a service provider terminal, a service requester terminal, a vehicle-mounted terminal, or the like, or any combination thereof. The monitoring unit 348 may obtain text, sound, and/or image data indicating the execution of the service order through the terminal. Data may be obtained through various sensors installed in the terminal. For example, audio data may be obtained through a sound sensor (e.g., a microphone) . Video data may be obtained through an image sensor (e.g., a camera) . The obtained data may be used for the risk determination and/or risk disposal at a subsequent time point, for example, after 10s.

The update module 350 may update rules and/or models based on the results of the risk response operation. The updated rules may include one or more risk determination rules, one or more risk ranking rules, etc. Updated models may include a driving condition identification model, a risk ranking model, etc. In some embodiments, the update module 350 may compare the risk verification result and/or the risk disposal result with the risk identification result and/or the risk ranking result to obtain a difference. In some embodiments, the risk parameters in the determination/ranking rule (s) may be updated according to the difference. In some embodiments, the update module 350 may determine orders with vehicles at risk which are verified in the risk verification operation and/or processed in the risk disposal operation as new sample data. The update module 350 may retrain the driving condition identification model based on the new sample data to update parameters thereof. At the same time, the update module 350 may retrain the risk ranking model according to feature information of one or more orders (e.g., each order) determined based on actual ranking results obtained by the risk verification operation or the risk response operation. In some embodiments, the update module 350 may update the rules and/or models at a preset interval, for example, every day, every week, every month, every quarter of the year, etc. In some embodiments, the update module 350 may actively force the system to update the rules and/or models.

It should be understood that the system and its modules shown in FIG. 3 may be implemented in various ways. For example, in some embodiments, the system and its modules may be implemented by hardware, software, or a combination of software and hardware. As used herein, the hardware component may be implemented by dedicated logic. The software component may be stored in the storage which may be executed by a suitable instruction execution system, for example, a microprocessor or dedicated design hardware. It will be appreciated by those skilled in the art that the above processes and systems may be implemented by computer-executable instructions and/or embedded in the control codes of a processor. For example, the control codes may be provided by a medium such as a disk, a CD or a DVD-ROM, a programmable memory device such as read-only memory (e.g., firmware) , or a data carrier such as an optical or electric signal carrier. The system in the present disclosure and its modules may not only be implemented by large scale integrated circuits or gate arrays, semiconductor devices (e.g., logic chips, or transistors) , or hardware circuits of programmable hardware devices (e.g., field-programmable gate arrays, or programmable logic devices) , but may also be implemented by software executed in various types of processors, or a combination of the above hardware circuits and software (e.g., firmware) .

It should be noted that the above description of the system 100 and its modules is for convenience of description only, and cannot limit the present disclosure to the scope of the illustrated embodiment. For persons having ordinary skills in the art, modules may be combined in various ways or connected with other modules as sub-systems, and various modifications and transformations in form and detail may be conducted under the teaching of the present disclosure.

In some embodiments, the data obtaining module 310, the risk determination module 320, the training module 330, the risk response module 340, and the update module 350 disclosed in FIG. 3 may be independent modules in the system. In some embodiments, two or more modules mentioned above may be combined as a module configured to implement the functions thereof. For example, the data obtaining module 310 and the risk determination module 320 may be two modules, and may also be combined as a module having the functions of obtaining the real-time status data and determining whether the vehicle is in the abnormal condition. As another example, two or more modules may share a single storage module, or each module may have its own storage module. As a further example, the training module 330 may be omitted. However, those variations and modifications may not depart the scope of the present disclosure.

FIG. 4 is a flowchart illustrating an exemplary process 400 for preventing a risk according to some embodiments of the present disclosure. In some embodiments, one or more operations in process 400 may be implemented in the system 100 shown in FIG. 1. For example, one or more operations in process 400 may be stored as instructions in storage device 130 and/or storage 270, and called and/or executed by the processing device 110. In some embodiments, in the process 400, the processing device 110 may assess and/or prevent risks of at least one service order (e.g., executing at a current time point) in a service platform (e.g., the system 100) .

In 410, the processing device 110 (e.g., the data obtaining module 310) may obtain service order data of at least one service order. In some embodiments, a service order may be a transportation service order (e.g., a cargo transportation order, a travel service order) that is requested, being executed, and/or completed. The service order data may include one or more features of the service order, real-time status data of a vehicle associated with the service order, a historical record associated with at least one piece of the service order data, etc. In some embodiments, the one or more features of the service order may include identity information of a service provider (e.g., a driver) , identity information of the vehicle associated with the service order, a service time of the service order, a start location of a trip of the service order, a destination of a trip of the service order, a route of a trip of the service order, identity information of a service requester (e.g., a passenger) , an estimated cost of the service order, or the like, or any combination thereof.

The identity information of the service provider may include an age of the service provider, the gender of the service provider, a face portrait of the service provider, contact information of the service provider, an education level of the service provider, an ID number of the service provider, a license number of the service provider, driving behavior data of the service provider, a driving age of the service provider, a proficiency level that the service provider drives a vehicle, a duration time before or of fatigued driving of the service provider, or the like, or any combination thereof. In some embodiments, a first piece of identity information of the service provider may be determined based on a second piece of identity information of the service provider. For example, the proficiency level may be determined based on the driving age. The duration time before fatigued driving may be determined based on the driving age of the service provider.

The identity information of the vehicle associated with the service order may include a license plate number of the vehicle, a vehicle type, a vehicle brand, a vehicle color, a vehicle age that the vehicle has been driven, a load capacity, power data of the vehicle, acceleration data of the vehicle, data of a power system during an acceleration of the vehicle, data of a power system during braking of the vehicle, data of a power system when the vehicle makes a turn, a suitable road of a trip of the vehicle, a safety level of the vehicle, or the like, or any combination thereof. In some embodiments, a first piece of identity information of the vehicle may be determined based on a second piece of identity information of the vehicle. For example, the suitable road of the trip may be determined based on the type of the vehicle. As another example, the safety level may be determined based on the vehicle age or load capacity of the vehicle.

The service time may include a service order request time and/or a service order execution time. The service order request time may refer to a time at which the service requester issues the order request. The service order execution time may refer to a time at which the service provider starts to execute the service order (or provide the service) . The identity information of the service requester may include an age of the service requester, the gender of the service requester, a face portrait of the service requester, contact information of the service requester, an education level of the service requester, an ID number of the service requester, location data of the service requester, or the like, or any combination thereof. The one or more features of the service order may also include an estimated duration of the order, an estimated order-completion time, an estimated service cost, or the like, or any combination thereof.

In some embodiments, the real-time status data of the vehicle may include speed data of the vehicle, location data of the vehicle, status data of a user terminal associated with the vehicle, data associated with internal environment of the vehicle (also referred to as internal environment data) , data associated with surrounding environment of the vehicle, data associated with a driving behavior of the vehicle, power data of the vehicle, positioning data associated with the service order, status data of the service order, or the like, or any combination thereof. The data associated with the surrounding environment of the vehicle may include a road condition, a traffic volume, a road type, road event information, feature (s) associated with a current location, or the like, or any combination thereof. The real-time status data of the vehicle may further include operation contents of a user of a terminal (e.g., a service requester and/or a service provider) . The positioning data associated with the service order may include the position of the terminal (e.g., the service provider terminal, the service requester terminal) ) associated with service participants of the service order, a driving route of the vehicle, or the like. The status data of the service order may include the power of the terminal, the strength of the communication signal, the working status of the sensor, the running status of the application on the terminal, etc. The real-time status data of the vehicle may also include the position of the vehicle, the speed of the vehicle, an acceleration of the vehicle, a posture of the vehicle, a driving trajectory of the vehicle, a motion state of the vehicle (e.g., whether the vehicle is in stopped state) , etc.

The internal environment data of the vehicle may include in-vehicle audio data, in-vehicle image data, etc. In some embodiments, the historical record associated with the at least one piece of the service order data may include records of a plurality of (e.g., all) service orders of the service provider, credit records of the service provider, records of a plurality of (e.g., all) service orders of the service requester, credit records of the service requester, identity information of vehicles associated with a plurality of (e.g., all) service orders of the service provider, service times of a plurality of (e.g., all) service orders of the service provider, start locations of a plurality of (e.g., all) service orders of the service provider, destinations of a plurality of (e.g., all) service orders of the service provider, routes of a plurality of (e.g., all) service orders of the service provider, costs of a plurality of (e.g., all) service orders of the service requester, payment records of a plurality of (e.g., all) service orders of the service requester, or the like, or any combination thereof. The records of service orders of the service provider may include a count of completed service orders, a count of canceled service orders, a count of complaints, times of being banned from service providing, credit scores, evaluation levels, historical evaluation contents, or the like, or any combination thereof. The records of service orders of the service requester may include a count of requested service orders, a count of canceled service orders, a count of completed service orders, service fee payment status, credit scores, evaluation levels, historical evaluation contents, or the like, or any combination thereof. The credit records of the service provider/service requester may include credit records of borrowing and/or credit card consumption.

In some embodiments, the data obtaining module 310 may obtain the service order data by communicating with the terminal (s) 120, the storage device 130, and/or the information source 150. For example, the terminal (s) 120 may acquire sensing data through various sensors installed thereon and a content of the user’s operation on the terminal (s) 120 in real-time, and the data obtaining module 310 may perform data acquisition by communicating with the terminal (s) 120. As another example, the data obtaining module 310 may access data associated with a user (e.g., feature information of a user) stored on the terminal (s) 120 or the storage device 130. As a further example, the data obtaining module 310 may communicate with the information source 150 to obtain data external to the terminal (s) 120 (e.g., driving safety information) .

It should be noted that the service order data may be obtained periodically (e.g., every 15 seconds, 30 seconds, etc. ) or in real-time. The data obtaining module 310 may transmit the obtained service order data to other modules (e.g., the risk determination module 320) of the processing device 110 (e.g., in real-time) to perform risk determination and/or at least one risk response operation in the driving process of the vehicle.

In some embodiments, the service order data may include data of one or more service orders. In some embodiments, the service order data may be obtained by one or more operations. For example, a request for obtaining the service order data may be transmitted, for example, from the user terminal (s) 120 to the processing device 110. The service order data may then be obtained via one or more terminals (e.g., the terminal (s) 120) , one or more sensors, or one or more information sources (e.g., the information source 150) . As another example, after the service order data is obtained, the service order data may be cleaned, and/or the cleaned service order data may be used for further processing.

In 420, the processing device 110 (e.g., the risk determination module 320) may process the service order data and/or perform a risk determination operation on the service order. In some embodiments, the risk determination operation may include or be performed based on the determination of abnormal driving conditions in the driving process, the determination of risk information associated with the vehicle in the driving process, etc. Exemplary abnormal driving conditions may include the speed of the vehicle being abnormal, the acceleration of the vehicle being abnormal, the driving direction of the vehicle being deviating, dangerous driving, etc. The risk information may include whether the vehicle is at risk in the driving process, a type of the risk (also referred to as “risk type” ) , a probability of the risk type, a level of the risk (also referred to as “risk level” ) , a probability of the risk level, or the like, or any combination thereof. The type of the risk may include, for example, a risk of violating the road safety law, a risk of violating driving behavior regulation, a risk of violating vehicle operation regulation, or the like, or any combination thereof. The type of the risk may include, for example, a rollover of the vehicle, a collision of the vehicle, etc. The level of the risk may include, for example, a mild level, a moderate level, a high level, etc.

In some embodiments, the risk determination module 320 may perform the risk determination on the vehicle associated with the service order based on a risk determination rule. For example, the one or more risk determination rules may include at least one rule of the determination of the abnormal driving condition, at least one rule of the determination of the risk information, etc. The risk determination rule may include a condition/or a threshold set according to historical service order data and/or user experiences. The historical service order data may include data of historical service orders in which vehicle (s) were in abnormal driving conditions in historical driving processes of the vehicle (s) . Similar to the service order data, the historical service order data may include a specific type of an abnormal driving condition that occurred in a historical service order. In some embodiments, through statistical analysis of the historical order data, the risk determination rule for the abnormal driving condition may be determined. For example, statistical analysis may be performed on historical order data including a collision event. One or more features such as speed data and/or acceleration data of vehicles associated with the historical order data may be obtained. Then, for the determination of the collision, speed and acceleration thresholds may be determined based on the one or more features and/or may be set as the risk determination rule. In some embodiments, the thresholds of the risk determination rule may be determined according to data statistics. The risk determination module 320 may compare the service order data with the risk determination rule. The risk determination module 320 may determine a service order corresponding to the service order data with a value (e.g., the speed, the acceleration of the vehicle) exceeding the threshold as a risk order. In some embodiments, for some types of the abnormal driving conditions, one or more risk determination rules may be obtained or used. The risk determination module 320 may determine the risk information of the vehicle by using a rule, a plurality of rules, or all rules of the one or more risk determination rules.

In some embodiments, the one or more risk determination rules may include whether the speed data of the vehicle exceeds a speed range, whether a first difference between an actual travel time and an estimated travel time of the vehicle exceeds a time threshold, whether a second difference between an actual start location and a preset start location or a third difference between an actual destination and a preset destination of the vehicle exceeds a first difference threshold, whether a fourth difference between an actual route and a preset route of the vehicle exceeds a second difference threshold, or the like, or any combination thereof. For example, in response to determining that the first difference exceeds the time threshold, the processing device 110 may determine that the vehicle is in the abnormal driving condition in the driving process. As another example, in response to determining that the second difference or the third difference exceeds the first difference threshold, the processing device 110 may determine that the vehicle is in the abnormal driving condition in the driving process. As a further example, in response to determining that the fourth difference exceeds the second difference threshold, the processing device 110 may determine that the vehicle is in the abnormal driving condition in the driving process. As still a further example, in response to determining that the second difference or the third difference exceeds the first difference threshold and the fourth difference exceeds the second difference threshold, or the second difference or the third difference exceeds the first difference threshold, the processing device 110 may determine that the vehicle is in the abnormal driving condition in the driving process.

In some embodiments, the abnormal driving condition and/or the risk information may be determined using a supervised learning technique, an unsupervised learning technique, a deviation analysis, etc.

In some embodiments, the risk determination module 320 may perform the risk determination operation to determine the abnormal driving condition (s) based on a machine learning model (e.g., a driving condition identification model) . The risk determination operation may include determining an abnormal type of the abnormal driving condition, a degree of harm of the abnormal driving, an occurrence probability of the abnormal driving, etc. The model may be a machine learning model, including but being not limited to, a classification and logistic regression (LR) model, a k-nearest neighbor (kNN) model, a Naive Bayes (NB) model, a support vector machine (SVM) , a decision tree (DT) model, a random forest (RF) model, a classification and regression tree (CART) model, a gradient boosting decision tree (GBDT) model, a xgboost (or referred to as eXtreme Gradient Boosting) , a light gradient boosting machine (or referred to as LightGBM) , a gradient boosting machine (GBM) , a least absolute shrinkage and selection operator (LASSO) , an artificial neural network (ANN) model, etc. The model may be obtained by training a preliminary model based on historical service order data. For example, the model may be trained by inputting at least a part (e.g., a part, the whole) of the historical service order data into the preliminary model. Actual risk information (e.g., an actual type of risk such as a type of a dangerous event (e.g., the collision or rollover of the vehicle) or abnormal driving) of the historical service order data may be obtained and used as desired output (e.g., the ground truth of the historical service order data) of the preliminary model in the training process. Model parameters may be adjusted based on the difference between the predicted output (e.g., the predicted type of the risk) of the preliminary model and the desired output. In response to determining a termination condition is satisfied, the training process may be terminated. Exemplary termination conditions may include a count of training samples reaching a preset count, the prediction accuracy rate of the preliminary model exceeding a preset threshold, a value of a loss function being smaller than a preset value, or the like, or any combination thereof. More descriptions of the training of the driving condition identification model may be found elsewhere in the present disclosure (e.g., FIG. 7 and descriptions thereof) .

In some embodiments, the risk determination module 320 may perform the risk determination operation of the service order based on the driving condition identification model to determine the risk information of the service order. In some embodiments, the risk determination module 320 may perform the risk determination associated with the vehicle in the driving process based on the driving condition identification model to determine the risk level, the probability of the occurrence of the risk, the probability of the occurrence of the abnormal driving condition, etc. In some embodiments, the driving condition identification model may be a model for determining various (e.g., all) types of the abnormal driving conditions. The risk determination module 320 may use the driving condition identification model to process a service order to determine types of the risks associated with the service order. More descriptions of the driving condition identification model may be found elsewhere in the present disclosure. See, for example, FIG. 6 and descriptions thereof.

In some embodiments, the risk identification result may include whether the vehicle is at risk, a quantitative representation of the risk, etc. The risk identification result may represent the risk information of the vehicle. Merely by way of example, if the vehicle is at risk, the risk identification result may include whether the vehicle is at risk, a type of the risk and a corresponding probability of the risk type, a level of the risk and a corresponding probability of the risk level, etc. For example, the determination result may indicate the vehicle is at risk and deviating from a preset route (e.g., at risk level 5) , or at risk and driving to a remote area (e.g., with a probability of 56%) and/or with abnormal stop (e.g., with a probability of 87%) . In some embodiments, the risk determination module 320 may comprehensively determine levels and/or probabilities of various (e.g., all) risks and output a risk identification result corresponding to the comprehensive risk determination. For example, the risk identification result may indicate the vehicle is at risk (e.g., with a probability of 74%) . It should be noted that the representation of the risk identification result described above is only for illustrative purposes, and the present disclosure does not limit to the representation of the risk identification result described above.

In 430, the processing device 110 (e.g., the risk response module 340) may perform at least one risk response operation on one or more (e.g., each) service orders based on the risk identification result (e.g., the abnormal driving condition, the risk information associated with the vehicle) . In some embodiments, the risk response module 340 may perform different risk response operations according to different risk identification results. Exemplary risk response operations may include a risk ranking operation, a risk verification operation, a risk disposal operation, a monitoring operation (e.g., continuous monitoring) , or the like, or any combination thereof. In some embodiments, the processing device 110 may process multiple service orders at the same time. In some embodiments, service orders at risk may be ranked based on the risk identification result. A time sequence for performing the risk response operation on the service orders may be determined based on the ranking result. If a large count of orders needs to be processed, the orders may be ranked in order to ensure that high-risk orders are processed in time. In some embodiments, the risk identification results of the service orders may be ranked. In some embodiments, one or more risk parameters may be determined based on the risk identification results. The risk identification results may be ranked based on the risk parameters. The risk parameters may include a piece of the service order data (e.g., an acceleration of a vehicle, the greater the acceleration is, the larger a possibility that the vehicle is at risk may be) , a type of the risk, a level of the risk, a risk probability in the risk identification result, or the like, or any combination thereof. In some embodiments, the service orders may be ranked according to the types of the abnormal driving condition of the service orders or the risk information of the vehicle. For example, orders with dangerous events may be processed in priority. For example, a service order with a relatively high probability of a collision or a rollover may be processed in priority. For a service order with a relatively low probability of a collision or a rollover, the risk verification operation may be performed first, and then the risk disposal operation may be performed after the risk verification operation.

In some embodiments, the risk ranking operation may be performed based on a ranking rule. The ranking rule may be determined based on or be associated with the risk probabilities and/or the levels of the risks in the risk identification result. In some embodiments, the ranking rule may include ranking thresholds (e.g., a level threshold, a probability threshold, etc. ) . The risk identification results may be ranked according to the ranking thresholds, respectively. In some embodiments, the ranking rule may be directly determined based on or be associated with the risk probabilities included in the risk identification result. In some embodiments, the ranking rule may be determined based on or be associated with a plurality of risk parameters (e.g., a comprehensive analysis result (e.g., a weighted mean) of the plurality of risk parameters) .

In some embodiments, the risk ranking operation may be performed based on a ranking model. In some embodiments, the ranking model may be a mathematical model and configured to obtain risk ranking results based on feature values of different types of risks and/or a feature value of various (e.g., all) risks (e.g., a comprehensive analysis result (e.g., a weighted sum) of the risks) . In some embodiments, the ranking model may be a machine learning model, including, but being not limited to, a classification and logistic regression (LR) model, a k-nearest neighbor (kNN) model, a Naive Bayes (NB) model, a support vector machine (SVM) , a decision tree (DT) model, a random forest (RF) model, a classification and regression tree (CART) model, a gradient boosting decision tree (GBDT) model, a xgboost (or referred to as eXtreme Gradient Boosting) , a light gradient boosting machine (or referred to as LightGBM) , a gradient boosting machine (GBM) , a least absolute shrinkage and selection operator (LASSO) , an artificial neural network (ANN) model, etc. The model (i.e., the ranking model) may be obtained after being trained based on feature information associated with the risks. The risk response module 340 may input a plurality of risk identification results of the service orders into the ranking model to determine the ranking results. In some embodiments, the risk response module 340 may input a part or the whole of the real-time status data of vehicles that have been identified to be at risk into the trained ranking model to determine the ranking result.

In some embodiments, the risk response module 340 may rank different risk types respectively to obtain the ranking results of different types of risks. In some embodiments, the risk response module 340 may rank all types of risks comprehensively. For example, weights may be set for different types of risks, and the orders with different types of risks may be ranked based on the weights to determine a comprehensive risk ranking result for all service orders. In some embodiments, the risk response module 340 may rank the service orders that have been identified to be at risk of a certain type. For example, the risk response module 340 may rank service orders of which the risk identification results indicate robbery and personal security incidents.

In some embodiments, the risk response module 340 may directly process each service order without the risk ranking operation. The processing operation may include a risk verification operation, a risk disposal operation, a monitoring operation, etc. It should be noted that the operations performed by the risk response module 340 on service orders with different risk identification results may be different. For example, for a high-risk order (e.g., the risk probability is greater than 50%) , the risk response module 340 may perform the risk disposal operation to alert the user (e.g., the service provider, the service requester) and/or directly call the police. As another example, the risk response module 340 may first perform the risk verification operation for service orders other than high-risk orders. Upon confirming that the service orders are at risk, the risk response module 340 may immediately call the police and/or rescue the user. For risk-free service orders or risk-free orders verified by the risk verification operation, the risk response module 340 may perform the continuous monitoring operation to detect whether the vehicle is at risk in time. In some embodiments, the risk response model 340 may perform the same operation for all orders. For example, the risk response model 340 may perform the risk verification operation for all service orders before performing other risk operations, or perform the risk disposal operation directly.

In some embodiments, the risk verification operation may be performed to determine an actual driving condition of the vehicle of the service order, and/or to determine whether the actual driving condition is consistent with the risk identification result obtained through the risk determination operation. In some embodiments, the risk verification operation may include interaction with the user for information verification, manual verification at the scene, risk verification by obtaining audio or image information in the vehicle, risk verification based on traffic broadcast information, or the like, or any combination thereof. The user may refer to a participant of a service order, e.g., a service provider and/or a service requester.

The risk verification through interaction with the user may include risk verification through a call via an interactive voice response (IVR) , a popup displayed in a terminal, application text, voice inquiries, telephone interaction, etc. For example, through the call via the IVR, a user may be allowed to enter information, such as a mobile number, on a user terminal (e.g., the terminal (s) 120) to confirm that the user is in a secure state. The telephone interaction may be a call for a user to confirm a state of the user. The risk response module 340 may obtain the telephone interaction content, and/or determine whether a call recipient is the user or whether there is a dangerous word in the telephone interaction content through techniques of voice recognition, semantic recognition, tone recognition for risk verification, etc. For example, a telephone interaction with a driver and/or passenger may be used to confirm whether the driver or the passenger is at risk. As another example, voice information of the driver or the passenger may be collected through anonymous calls (e.g., calls from insurance sales, real estate sales, telephone shopping, etc. ) , and the risk may be confirmed by identifying the tone (e.g., whether it is angry) , background sound, or voiceprint recognition. As another example, the telephone interaction may be conducted with a non-risk party in the vehicle (e.g., performing telephone interaction with a driver when it is determined that passengers are in danger) to confirm the risk.

The risk verification by the staff at the scene may be performed based on the location of the user terminals or the vehicle of the service order. The staff near the location may go to the scene. The audio or image information in the vehicle for risk verification may be obtained via a sensor (e.g., an image sensor, a sound sensor, etc. ) disposed on the terminal (e.g., a service provider terminal, a service requester terminal, a vehicle terminal, etc. ) , and then the risk verification may be performed automatically or manually based on the obtained audio or image information in the vehicle. The risk verification based on the traffic broadcast information may be performed to confirm the authenticity of the occurrence of the risk of the service order to be confirmed based on an event location, an event time and/or an event type in the traffic broadcast information.

In some embodiments, the risk verification operation may also include manual confirmation. The manual risk verification may be performed by displaying various information (e.g., a driving trajectory, videos and audios in the vehicle, a current location of the user, historical risk data of the user, the cause of historical risk, etc. ) of the service order to be confirmed to the back-end security confirmation personnel. The security confirmation personnel may confirm the risk information, for example, where the vehicle stopped, how many times the vehicle stopped, whether the driving trajectory disappeared, whether there were physical and/or language conflicts between users, etc.

As described above, the risk verification operation may confirm the actual condition of the service order to obtain a verification result. The risk verification operation may also confirm whether the risk identification result is consistent with the verification result. For example, in response to determining that the risk identification result is consistent with the verification result (e.g., the vehicle is not at risk) , the processing device 110 may not perform any risk response operation. As another example, in response to determining that the risk identification result is inconsistent with the verification result and the verification result indicates that the vehicle is not at risk, the processing device 110 may not perform any risk response operation. In response to determining that the risk identification result is inconsistent with the verification result and the verification result indicates that the vehicle is at risk, the processing device 110 may perform the at least one risk response operation.

In some embodiments, the risk disposal operation may include notifying emergency contacts, initiating data reporting on driver terminal and/or passenger terminal, a follow-up alarm by a special person, or the like, or any combination thereof. Emergency contacts may include contact information (e.g., mobile number) of the first contact when the passengers and/or drivers are in danger. The first contact may be added by passengers and/or drivers during registration and/or use of the service (e.g., via a passenger and/or driver terminal, a mobile app, etc. ) . In some embodiments, a quick entry for communication with the back-end security platform (e.g., an emergency contact button, an alarm button, a help button) may be set on the user terminal. If the user is determined to be in danger, the user may click the emergency contact button. After detecting that the emergency contact button is triggered, the terminal may automatically send helping voice or text information to the emergency contact. In some embodiments, the current location information of the terminal may be automatically added to the information. Alternatively, in some embodiments, the user may alert the police by clicking the alarm button. After alerting the police, the terminal may also send the current location and/or trip information of the user to the police to assist the rescue. The data of the driver terminal and/or the passenger terminal may include audio, video, and image data obtained through various sensors disposed on the driver terminal and/or the passenger terminal (e.g., the terminal (s) 120 or the mobile device 200) . The processing device 110 may obtain the data automatically. In some embodiments, the users may actively report this data. The follow-up alarms by a special person may be handled by a person (e.g., a manual customer service) . In some embodiments, the risk response module 340 may perform the risk disposal operation on the service order that is verified by the risk verification operation. For example, if an order is determined to be at risk, the risk response module 340 may perform the risk disposal operation such as an alarm.

In some embodiments, the risk disposal operation may include risk research. The risk response module 340 may obtain one or more service orders and service order data of the service order (s) that satisfies a condition for risk research. The risk response module 340 may also obtain risk identification results of the service order (s) and risk information related to various aspects of the service order (s) . The risk response module 340 may send the data to a processing device of a researcher associated with risk research and obtain a result of the manual research through the processing device. Exemplary conditions for risk research may include the risk identification result of the service order being that the service order is at risk, the risk level or the risk probability exceeding a research threshold, the service order being not verified by the risk verification, the result of the risk verification of the service order in a previous time being that the service order being not at risk (e.g., “temporarily secure” or “no alarm” ) but the service order is at risk in current moment, or the like. For a service order that satisfies the condition for risk research, the risk response module 340 may obtain the risk identification result of the service order (e.g., based on operation 420) and the risk information related to various aspects of the service order, e.g., user information (e.g., a current location of the user, a count of times that the user is complained, etc. ) , a vehicle location (e.g., the vehicle is in a remote area, etc. ) , trajectory data (e.g., a route of the vehicle deviates from a common route, the vehicle stops in a location for too long, etc. ) , information extracted inside the vehicle (e.g., recording, video, call, image, etc. ) , external environment information of the vehicle (e.g., a traffic flow, etc. ) .

After obtaining the information, the risk response module 340 may send the data to the processing device of the researcher associated with the risk research. After receiving the data, a processing device of the researcher may automatically research the service order to determine whether a dangerous event and/or an abnormal condition occurs, or the researcher may determine the result by operating the processing device. In some embodiments, the risk response module 340 may generate a risk-research order and/or assign the risk-research order to a plurality of processing devices of the researcher to perform the risk research to determine the result of the risk research. The risk-research order may be displayed in a preset form (e.g., a list) in an interface (e.g., in a processing interface of a processing device of the researcher) . A back-end security researcher may select or click the list to view the information contained in the risk-research order. For example, the risk identification result of the service order corresponding to the risk-research order and the risk information related to various aspects of the service order may be generated. Whether a dangerous event and/or an abnormal condition occurs may be determined. At the same time, the information may be in the form of highlighting, for example, highlighted font, highlighted color, etc. In some embodiments, the risk response module 340 may first determine the service order that satisfies the condition for risk research, and send the determination result (e.g., in the form of a system opinion) together with the risk-research order to the processing device of the researcher to assist the determination.

In some embodiments, the risk disposal operation may include risk rescue. The risk response module 340 may generate rescue information based on relevant information and a risk identification result of a service order that is at risk and is to be disposed. In some embodiments, the risk response module 340 may determine whether the service order satisfies a risk rescue condition based on the risk identification result. In some embodiments, the risk response module 340 may determine that a service order with a risk level and/or a risk probability exceeding a rescue threshold (for example, 80%, 85%, or 90%) satisfies the risk rescue condition. For a service order that satisfies the rescue conditions, the risk response module 340 may generate rescue information based on the relevant information of the service order. For example, the risk response module 340 may generate rescue information based on the location of the vehicle, vehicle information, the risk type of the service order, etc. For example, the rescue information may indicate: a white vehicle whose current location is near the east gate of Central Park and whose license plate number is Beijing A12345 may be in an abnormal stopping state (e.g., being suspected of robbery) , please go to check and rescue.

After generating the rescue information, the risk response module 340 may send the rescue information to a processing device associated with a party (e.g., the police) , a terminal associated with an emergency contact, a terminal associated with another service provider, etc. If the processing device associated with the party (e.g., the police) sends the rescue information, the police may be alerted (e.g., at the same time) . When sending the rescue information to the terminal associated with the emergency contact, reminder information may be sent at the same time to remind the emergency contact to report to the police or to ensure personal safety during checking and/or rescuing. The other service providers may include service providers whose location does not exceed a first distance threshold from the current execution location of the service order that is at risk and is to be disposed. The current execution location may refer to the location of a participant (including users and vehicles) of the service order that is at risk and is to be disposed at the current moment. In some embodiments, in addition to sending the rescue information, subsidy information or reward information may also be sent for reminding the service providers (e.g., drivers) that they may receive a subsidy or reward if they go to check and/or rescue. In some embodiments, different counts and/or different types of drivers may be notified for different risk events. For example, a count of drivers notified to rescue an abnormal stop event may be smaller than a count of drivers notified to rescue a robbery event. As another example, the drivers being sent to check and rescue a robbery event may be young drivers. In some embodiments, the rescue information may be sent in consideration of the distance of the drivers from the location where the risk event occurs and conditions of a route to the location.

In some embodiments, the risk response operation may be delayed. By collecting the security behavior of the user within the delay time, the processing pressure and impact on a risk processing device (e.g., processing device 110) may be reduced. In some embodiments, the processing device 110 may need to process a plurality of service orders at the same time, the delay processing may reduce the load of the processing device 110 and speed up the speed of processing the service orders. In some embodiments, after a service order that is determined to be at risk is completed, the risk response module 340 may obtain data indicating user behaviors of a user associated with the service order. The risk response module 340 may determine whether the user associated with the service order has performed a security behavior, based on data indicating the user behaviors associated with the service order. If the security behavior is performed by the user associated with the service order, a risk identification result indicating that the service order is at risk may be canceled. For example, in operation 420, the service order may be determined to be at risk of an abnormal stop, the risk level of the abnormal stop may be a mild level (e.g., the risk level and the risk probability of the abnormal stop may be within a preset threshold range) , and accordingly, the risk response module 340 may continue to monitor the service order. If a driver associated with the service order is able to continue to accept orders normally and/or a passenger associated with the service order is able to continue to request an order normally after the current order is completed, the risk identification result indicating that the service order is at risk of abnormal stop may be canceled, and the driver and/or passenger may be determined to be safe. In some embodiments, the order determined to be at high risk may also be verified during the delay time. The verification may be performed through manners such as manual verification, automatic verification, phone-based interactive verification, etc. The verification may include, for example, guiding the passenger to confirm whether there is a security risk on the passenger terminal (e.g., send information to be answered in the APP, initiate a red envelope grab activity, etc. ) , dialing a service phone number automatically, making an indirect call (e.g., to obtain relevant information by calling a financial service phone, etc. ) , contacting a relative or a friend to verify.

In some embodiments, the user may independently determine and/or report the security risk. For example, the interface of the application 264 may include a quick entry (e.g., an alarm button, a help button) that communicates directly with the online-to-offline service platform. The user may report risks through the quick entry. As another example, the user may perform a specific operation (e.g., pressing, shaking, or throwing) on the mobile device 200. If the sensors (e.g., sound sensors, image sensors, pressure sensors, speed sensors, acceleration sensors, gravity sensors, displacement sensors, gyroscopes, or the like, or any combination thereof) disposed in the mobile device 200 identify the specific operation, the mobile device 200 may start an alarm procedure to report the security risk. After receiving the report, the risk response module 340 may determine the accuracy of the reported security risk (e.g., whether there is noise, etc. ) for the risk verification operation and/or the risk disposal operation.

In some embodiments, the risk disposal operation may include monitoring the vehicle (s) (or service order (s) ) . In some embodiments, the monitoring may be performed continuously. The continuous monitoring may be performed on a service order that is determined to be risk-free in the operation 420, a part of service orders that have relatively low risks according to the risk ranking results, a service order that is verified as risk-free by the risk verification operation, etc. In some embodiments, the risk response module 340 may determine a terminal associated with the service order based on the service order data to be continuously monitored. The terminal may be a service provider terminal associated with the service order, a service requester terminal associated with the service order, a vehicle terminal, or the like. The risk response module 340 may obtain text, sound, and/or image data indicating the execution of the service order from the terminal. Data may be obtained through various sensors installed on the terminal. For example, audio data may be obtained through a sound sensor (e.g., a microphone) . Video data may be obtained through an image sensor (e.g., a camera) . The obtained data may be used for the risk determination operation and/or risk disposal operation at a subsequent time point, for example, after 10s.

It should be noted that the risk determination operation and/or response operation on an order may be an ongoing process. If a service order is determined to be safe at the current moment or during the risk response operation (e.g., a risk verification operation) , the continuous monitoring may still be performed. The risk determination operation and/or the risk response operation may be repeated to determine whether a subsequent risk event occurs. For example, the risk determination operation and subsequent operations (e.g., the risk verification operation, the risk response operation) thereof may be performed at intervals (e.g., every 10 seconds) . If the service order is completed or terminated for a threshold time (e.g., 10 minutes, 20 minutes, 30 minutes) , the risk determination operation and/or the risk response operation for the order may be terminated. The risk response module 340 may continuously monitor the service order of which risk identification result indicates risk-free obtained in operation 420.

Similarly, it should be understood that the processing in the risk response operation may be selectively performed. In some embodiments, the risk response module 340 may rank all service orders based on the risk identification results, and/or selectively perform subsequent operations according to the ranking results. For example, the risk response module 340 may perform risk disposal operations on service orders that have relatively high risks according to the ranking result. The risk response module 340 may perform risk disposal operations on service orders that have medium risk levels in the ranking result. The risk response module 340 may perform continuous monitoring operations on service orders that have relatively low risks in the ranking result. In some embodiments, the risk response module 340 may skip the ranking operation, directly perform risk verification on all service orders, and perform subsequent processing operations based on the verification results. For example, a risk-free service order may be continuously monitored after the risk of the risk-free service order is confirmed. For service orders at risk, according to the risk levels of the service orders, users associated with the service orders may be reminded of the risk (e.g., an abnormal stop of the vehicle) , or an alarm may be directly initiated (e.g., the service order is at risk of robbery) .

In some embodiments, the risk response module 340 may directly process a plurality of service orders (e.g., all service orders) based on the risk identification result. For example, the risk response module 340 may send an alert to associated users of service orders at relatively low risks. For service orders with relatively high risks, the risk response module 340 may directly call the police. For risk-free service orders, the risk response module 340 may perform continuous monitoring to determine subsequent risks in time when the subsequent risks occur. In some embodiments, the risk response module 340 may rank the service orders based on the risk identification results, and/or directly process the service orders based on the ranking results. For example, the risk response module 340 may first process the service orders with higher ranks (e.g., orders with higher risks) , and then continue to process the orders with lower ranks (e.g., orders with lower risks) after the processing of the service orders with the higher risks is completed. In some embodiments, the risk response module 340 may perform delay processing on the service orders based on the risk identification results. For example, the risk response module 340 may monitor the service orders that are determined to be at risk. After the service orders at risk are completed or terminated, the risk response module 340 may obtain the behavior data of the users related to the service orders. If a user has a security behavior, for example, a user related to a service order continues to request a transportation service after the service order is completed, then the risk response module 340 may determine that the service order is a secure order (or at no risk) .

In 440, the processing device 110 (e.g., the update module 350) may update rules and/or models based on the risk response operation. In some embodiments, the rules may include one or more risk determination rules, one or more risk ranking rules, or the like. The models may include a driving condition identification model, a risk ranking model, or the like. In some embodiments, the update module 350 may compare the risk verification result and/or the risk disposal result with the risk identification result and obtain differences therebetween. In some embodiments, the risk parameters associated with the risk determination rule (s) may be updated according to the differences. For example, a risk determination rule for determining a robbery event may be determined based on a service request time of a service order associated with the robbery event and a start location of the service order associated with the robbery event. If the service request time is after 12 p.m. and a destination of the service order is in a nearby city, the risk identification result may indicate that a vehicle associated with the service order is at risk of robbery. If risk verification is performed on a plurality of service orders with service request times between 12 p.m. and 12: 30 p.m. and no robbery event is found in the service orders, then the update module 350 may update the risk determination rule as indicating that a service order with a service request time later than 12: 30 in the evening and a destination located in a nearby city or country may have a risk of robbery. In some embodiments, the update module 350 may determine the service orders (that have risk events and are determined in the risk verification operation and/or the risk disposal operation) as new sample data to retrain the driving condition identification model to update the parameters of the model. Similarly, for the risk ranking rules and the training of the risk ranking model, the update module 350 may compare the risk verification result and/or the risk disposal result with the risk ranking results to obtain differences therebetween and update the ranking rules and /or the risk ranking model. For example, if a high-risk order with a relatively high rank in the ranking result is determined to have no risk in subsequent risk verification operations, the update module 350 may update the risk parameters used for the ranking rules and /or the ranking model. For the risk ranking model, the update module 350 may retrain the risk ranking model according to feature information of service orders in an actual ranking result obtained through the risk verification or risk response operations to achieve updating of the risk ranking model. In some embodiments, the rules and models may be updated at preset intervals, for example, every day, every week, every month, every quarter, or the like.

It should be noted that the above description is merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. However, those variations and modifications do not depart from the scope of the present disclosure. In some embodiments, one or more optional operations in the process 400 may be omitted. For example, for service orders whose risk identification results indicate relatively high risks (e.g., whose risk levels or risk probabilities, etc., are higher than a preset threshold) , the risk ranking operation and/or the risk verification operation may be omitted, and the risk disposal operation may be directly performed (e.g., call the police, or transfer the service order (s) to a security officer for risk research) . As another example, for service orders whose risk identification results indicate relatively low risks (e.g., whose risk levels or risk probabilities, etc., are lower than the preset threshold) , the monitoring and/or delay processing operation may be performed (e.g., data acquisition may be continued, and/or risk determination operation may be performed again after a preset time) . As a further example, operation 440 may be omitted.

FIG. 5 is a flowchart illustrating an exemplary process for identifying a driving condition of a vehicle according to some embodiments of the present disclosure. In some embodiments, one or more operations in process 500 may be implemented in the system 100 shown in FIG. 1. For example, one or more operations in process 500 may be stored in the form of instructions in the storage device 130 and/or storage 270 and executed by the processing device 110. In some embodiments, in the process 500, the processing device 110 may assess and/or prevent risks in a driving process based on real-time status data (e.g., of a service order) associated with the driving process in the process 500.

In 510, the processing device 110 (e.g., the data obtaining module 310) may obtain real-time status data in a driving process of a vehicle. In some embodiments, the real-time status data in the driving process may include driving data of the vehicle (e.g., speed data of the vehicle) , turning data of the vehicle) , location data of the vehicle, status data of a user terminal associated with the vehicle, data associated with internal environment of the vehicle, data associated with surrounding environment of the vehicle, data associated with a driving behavior of the vehicle, power data of the vehicle, speed data of the user terminal, or the like, or any combination thereof. In some embodiments, the speed data of the vehicle may include a speed of the vehicle and/or an acceleration of the vehicle. In some embodiments, the speed data of the vehicle (e.g., a speed of the vehicle, an acceleration of the vehicle) and/or the speed data of the user terminal (e.g., a speed of the user terminal, an acceleration of the user terminal, etc. ) may be obtained via one or more sensors (e.g., vehicle-mounted sensor (s) ) disposed in the vehicle and/or the user terminal. In some embodiments, the user terminal may be a service provider terminal and/or a service requester terminal.

In some embodiments, the location data of the vehicle may include location information of the vehicle, the service provider terminal or the service requester terminal. In some embodiments, the status data of the user terminal may include status data such as whether the service provider terminal or service requester terminal has initiated an alarm, whether the service provider terminal or service requester terminal has sent information, whether the service provider terminal or service requester terminal is normally turned on, power data of the user terminal, a communication signal strength of the user terminal, a sensor working status of the user terminal, a running status of application (s) on the user terminal, etc. In some embodiments, the data associated with the internal environment of the vehicle may include audio data or image data (e.g., whether there is a conflict between a passenger and a driver, whether a driver is fatigued, whether a passenger is fatigued, whether a passenger is asleep, etc. ) . In some embodiments, the data associated with the surrounding environment of the vehicle may include data such as a real-time road condition, a traffic flow, a road type, road event information, a feature of a current location of the vehicle, whether a current time is late at night, or the like. In some embodiments, the driving data of the vehicle (e.g., the speed data of the vehicle) may be obtained via various sensors disposed on the vehicle or the user terminal. For example, the speed data of the vehicle may be detected by a wheel speed sensor disposed on the vehicle. Turning data of the vehicle may be detected by a steering wheel angle sensor disposed on the vehicle. The acceleration data of the vehicle may be detected by an acceleration sensor disposed on the vehicle or a user terminal.

In some embodiments, the data associated with the driving behavior of the vehicle may include data associated with a turning operation of a user driving the vehicle, data associated with a braking operation of a user driving the vehicle, data associated with light using of a user driving the vehicle, or the like, or any combination thereof. The power data of the vehicle may include a remaining power of the vehicle, consumption of the power of the vehicle, a remaining mileage of the vehicle, etc. In some embodiments, the real-time status data may also include road data (e.g., data associated with roads on which the vehicle is driving) , weather data, a type of the vehicle, or the like, or any combination thereof. For example, the road data may include a gradient of a road, a turn of a road, an attitude of a road, accident information of a road, or the like, or any combination thereof. Merely by way of example, the accident information of a road may include whether a count of accidents in the road exceeds a threshold, the type of an accident, a notification (e.g., warning information) associated with an accident, or the like, or any combination thereof. The type of the vehicle may include a fuel vehicle, an electric vehicle, etc. The weather data may include whether it’s rainy, a rainfall, whether it’s snowy, a snowfall, a level of the wind, a direction of the wind, or the like, or any combination thereof.

In some embodiments, at least a portion of the real-time status data of the vehicle may be obtained via one or more sensors (e.g., one or more vehicle-mounted sensors) disposed on the vehicle, a user terminal (e.g., a terminal of the service provider, a terminal of the service requester) , a monitoring device external to the vehicle, or the like, or any combination thereof.

In some embodiments, the processing device 110 may extract feature information of the real-time status data. For example, the extraction of the feature information may refer to processing the real-time status data and extracting the feature information thereof. The extraction of the feature information may enhance the expression of the real-time status data to facilitate subsequent processing (s) . In some embodiments, the processing device 110 may extract the feature information based on a feature extraction algorithm. Exemplary feature extraction algorithms may include a statistical algorithm (e.g., a principal component analysis algorithm) , a dimension reduction algorithm (e.g., a linear discriminant analysis algorithm) , etc.

In some embodiments, the feature information of the real-time status data may include feature information of a driving road of the vehicle, feature information of a driving behavior associated with the vehicle, feature information of weather in a driving region associated with the vehicle, feature information of the power of the vehicle, feature information of the location of the vehicle, feature information of a status of a user terminal associated with the vehicle, feature information associated with internal environment of the vehicle, feature information associated with the surrounding environment of the vehicle, feature information of the service provider, feature information of the service requester, feature information of a service order associated with the vehicle, or the like, or any combination thereof. In some embodiments, the feature information may include one or more numeric values, one or more vectors, one or more determinants, one or more matrices or the like, or any combination thereof. For example, a driving age of a service provider may be converted into a feature value or a feature vector of a proficiency level that the service provider drives a vehicle.

In some embodiments, the real-time status data may be converted into the feature values according to one or more rules. Take the driving age of the service provider as an example, if the driving age is within 0-3 years, a feature value of the proficiency level may be within a range from 0 to 0.6. If the driving age is within 3-6 years, a feature value of the proficiency level may be within a range from 0.6 to 1. If the driving age is more than 6 years, a feature value of the proficiency level may exceed 1.

In some embodiments, the real-time status data may be converted into the feature information according to a continuous function. Take the driving age of the service provider as an example, a sigmoid function may be used as a feature value of the driving age. In some embodiments, the real-time status data may be converted into one or more feature vectors using a bucketing manner. Taking the driving age of the service provider as an example, a driving age of 0-3 years may proportionally correspond to [1, 0, 0] . A driving age of 3-6 years may proportionally correspond to [0, 1, 0] . A driving age of more than 6 years may proportionally correspond to [0, 0, 1] .

In some embodiments, the feature information may be determined based on multi-source data. For example, a feature value or a vector representing the influence of wind force may be obtained based on the wind direction, the wind force, and/or the driving state of the vehicle. The influence of wind force on the vehicle when an angle between the wind direction and the driving direction of the vehicle is 90 degrees may be larger than when the wind direction and the driving direction of the vehicle are the same. As another example, the greater the vehicle speed is, the greater the influence of the wind force may be.

In some embodiments, the feature information may be extracted using a combination of multiple vectors. The combination of vectors may refer to combining feature values or feature vectors having related relationships into a new feature value or a feature vector that may represent the feature information. For example, a feature value representing visibility, a feature value representing pavement slipperiness, and a feature value representing wind impact may be weighted and summed to obtain a combined feature value representing climate effect.

In some embodiments, representation learning may be performed on the real-time status data in the driving process to extract the feature information. Representing learning may refer to that a model automatically learns input data (e.g., the real-time status data) to obtain features, which may facilitate the extraction of the feature information.

In some embodiments, at least a part (e.g., a part, the whole) of the feature information may be obtained based on historical data or historical features using a machine learning model. For example, a value of driving stability of a service provider may be obtained based on a feature of a driving action of the driver, a feature of climate effect, a feature of a time point of the service provider driving the vehicle, a feature of a vehicle condition, etc., using a driving stability model. In some embodiments, the machine learning model may be a regression model determined based on linear regression and neural networks. In some embodiments, the machine learning model may determine the feature information by convolution or pooling.

In some embodiments, the machine learning model may process sequence data based on a sequence-oriented machine learning model to obtain the feature information of the real-time status data. Exemplary sequence-oriented machine learning models may include a recurrent neural network (RNN) model such as a long-short term memory (LSTM) model.

In some embodiments, the data obtained by the feature extraction processing may be further analyzed to obtain a required result, e.g., a driving condition determination result, a risk identification result illustrated in

operations

520 and 530. For example, the feature information may be input into a model (e.g., a driving condition identification model) to obtain the required result or may be input into other network models for problem analysis. In some embodiments, a feature analysis of the extracted feature information may be performed to obtain the required result. For example, by analyzing feature information of the power data, a power consumption condition and/or an estimated power consumption condition may be determined in the vehicle driving process.

In 520, the processing device 110 (e.g., the risk determination module 310) may determine whether the speed data exceeds a first speed range. In response to determining that the speed data exceeds the first speed range, the processing device 110 may determine that the vehicle is in an abnormal driving condition in the driving process. In some embodiments, the abnormal driving condition may be an abnormal driving condition in a service order (e.g., a taxi-hailing service, a chauffeur service, an express car service, a carpool service, a bus service, a driver hire service, and a shuttle service, etc. ) . In some embodiments, the abnormal driving condition may indicate that the vehicle has a driving accident that endangers the personal safety of a user in the vehicle. In some embodiments, the abnormal driving condition (e.g., the speed data exceeds a first speed range) may cause a rollover or collision of the vehicle. In some embodiments, the abnormal driving condition (e.g., the speed of the vehicle is abnormally high or slow) may occur due to a conflict between the service provider (e.g., the driver) and the service requester (e.g., the passenger) or one of the service provider and the service requester suffering a personal attack. In some embodiments, the first speed range may relate to a maximum allowed speed of the vehicle, a minimum allowed speed of the vehicle, etc. The abnormal driving condition may indicate that the speed of the vehicle exceeds the maximum speed or is less than the minimum speed. For example, the maximum speed may be 125 km/h, and the minimum speed may be 30 km/h. If the speed of the vehicle exceeds 125 km/h or is less than 30 km/h, the vehicle may be considered to be in the abnormal driving condition in the driving process. In some embodiments, the speed data of the vehicle may include a speed of the vehicle, an acceleration of the vehicle, or a combination of the speed and the acceleration. In some embodiments, the driving condition may be identified according to the speed data of the user terminal and the speed data of the vehicle. For example, when both of the speed data of the vehicle and the speed data of the user terminal exceed the first speed range, the processing device 110 may determine that the vehicle is in the abnormal driving condition in the driving process. As another example, in response to determining that the speed data of the vehicle or the speed data of the user terminal is within the first speed range, the processing device 110 may determine that the vehicle is in the abnormal driving condition in the driving process.

In some embodiments, the service order may include a real-time order (also referred to as “current service order” ) . For the current service order, whether the vehicle is in the abnormal driving condition or a probability that the vehicle is in the abnormal driving condition may be determined according to historical statistical data, a function, or a machine learning model. For example, historical orders with the abnormal driving conditions in the recent ten, five, or three years may be obtained to determine whether the vehicle is in the abnormal driving condition or the probability that the vehicle is in the abnormal driving condition in the current service order according to statistical rules. In some embodiments, a function between driving data and types of abnormal driving conditions may be established to determine whether the vehicle is in the abnormal driving condition or the probability that the vehicle is in the abnormal driving condition in the current service order.

In some embodiments, the abnormal driving condition may refer that the real-time status data is inconsistent with normal data under the same environment or exceeds the range of the normal data. For example, if a vehicle is on a high-speed road, the driving behavior of a user driving the vehicle includes frequently changing lanes (which may affect traffic in the high-speed road) , and the frequency that the vehicle changes the lanes exceeds a frequency of changing lanes of normal driving in the high-speed road, then the processing device 110 may determine that the vehicle is in the abnormal driving condition.

In 530, the processing device 110 (e.g., the risk determination module 310) may determine risk information associated with the vehicle in the driving process based on the real-time status data in the driving process. In some embodiments, in response to determining that the vehicle is in the abnormal driving condition or the probability that the vehicle is in the abnormal driving condition is relatively high (e.g., exceeding a probability threshold) , the processing device may determine the risk information. In some embodiments, the risk information may include whether the vehicle is at risk in the driving process, a type of the risk, a level of the risk, or the like, or any combination thereof. For example, the processing device 110 may determine the probability that the vehicle is in the abnormal driving condition (e.g., a rollover of the vehicle, a collision of the vehicle, a driver being kidnapped, a conflict between a driver and a passenger, etc. ) that can affect the personal safety of the user in the vehicle. In response to determining that the probability exceeds the probability threshold, the processing device 110 may determine that the vehicle is at risk. In some embodiments, conditions corresponding to different types of accidents may be determined according to driving data and risk determination rules. In response to determining that a condition corresponding to a type of accident is satisfied, the processing device 110 may determine that the type of accident occurs in the current service order. In some embodiments, the processing device 110 may determine whether a variation of the speed data of the vehicle with time satisfies a first condition. For example, the first condition may include the variation of the speed being within a variation range from -10km/h to 10km/h. In response to determining that the variation satisfies the first condition, the processing device 110 may determine that the vehicle is at no risk. As another example, in response to determining that the speed data of the vehicle is abnormal (e.g., exceeding the first speed range) for a while and the speed data of the vehicle becomes normal (e.g., within the first speed range) soon, the processing device 110 may determine that the vehicle is at no risk. In some embodiments, the processing device 110 may determine whether the speed data of the vehicle exceed a second speed range. For example, the second speed range may include a range from a minimum allowed speed of the vehicle to a maximum allowed speed of the vehicle. In response to determining that the speed data of the vehicle exceeds the second speed range, the processing device 110 may determine a duration time in which the speed data of the vehicle exceeds the second speed range. The processing device 110 may determine whether the duration time exceeds a time threshold. In response to determining that the duration time exceeds the time threshold, the processing device 110 may determine that the vehicle is at risk. For example, in response to determining that the speed data of the vehicle exceeds the maximum value of the second speed range and the duration time exceeds the time threshold, the processing device 110 may determine that the vehicle is at risk (such as a rollover of the vehicle or a collision of the vehicle) . The processing device 110 may further determine the level of the risk according to the speed data of the vehicle exceeding the second speed range and the duration time exceeding the time threshold.

In some embodiments, the processing device 110 may obtain the location data of the vehicle based on the real-time status data. The processing device 110 may determine a driving trajectory of the vehicle after the speed data of the vehicle exceeds a fourth speed range based on the location data of the vehicle. For example, the fourth speed range may include a range from a minimum allowed speed of the vehicle to a maximum allowed speed of the vehicle. In some embodiments, the processing device 110 may determine the risk information associated with the vehicle based on the driving trajectory. For example, in response to determining, based on the driving trajectory, that the vehicle stops, the processing device 110 may determine that the vehicle is at risk. As another example, upon detecting that the acceleration of the vehicle exceeds the maximum value of the fourth speed range at a time point, the location data of the vehicle and/or the driving trajectory before and after the time point may be obtained. If the vehicle stops driving after the time point, the processing device 110 may determine that the vehicle is at risk, e.g., the collision or the rollover of the vehicle. The risk level may be determined based on the speed data of the vehicle exceeding the fourth speed range and the time point the vehicle stops driving.

In some embodiments, the processing device 110 may obtain data associated with a user behavior after the speed data of the vehicle exceeds a fifth speed range based on the real-time status data. For example, the fifth speed range may include a range from a minimum allowed speed of the vehicle to a maximum allowed speed of the vehicle. The processing device 110 may determine the risk information associated with the vehicle based on the data associated with the user behavior. In some embodiments, the data associated with the user behavior may at least include one operation of the user in an application of a service platform (e.g., the system 100) , for example, whether the user reports an alarm, whether the user sends out a call for help, the user grabbing a red envelope in an application of the platform, the completion of the order, the user continuing to accept the order, the user sending out other order requests, etc. If the user sends out information for calling for help after the acceleration of the vehicle exceeds the fifth speed range, the processing device 110 may determine that the vehicle is at risk, and the risk level may be relatively high (e.g., exceeding a first level threshold) . If the user completes the order and evaluates the service order after the acceleration of the vehicle exceeds the fifth speed range, the processing device 110 may determine that the probability of risk of collision or rollover is relatively low (e.g., exceeding a second level threshold) . In some embodiments, the processing device 110 may obtain vehicle posture data after the speed data of the vehicle exceeds a third speed range based on the real-time status data. For example, the third speed range may include a range from a minimum allowed speed of the vehicle to a maximum allowed speed of the vehicle. In response to determining that the vehicle posture data satisfies a second condition, the processing device 110 may determine that the vehicle is at risk. In some embodiments, the vehicle posture data may include information such as posture angle data of the vehicle, a rotation angle data of the vehicle, or the like. The posture angle data may be measured by a gyroscope disposed on the vehicle or the user terminal. The rotation angle data may be measured by a steering wheel angle sensor disposed on the vehicle. In some embodiments, the risk described above may include a rollover of the vehicle or a collision of the vehicle in the driving process. It should be noted that the second speed range, the third speed range, the fourth speed range and/or the fifth speed range may be the same or different and have no relation.

In some embodiments, the processing device 110 may obtain the location data of the vehicle (also referred to as “vehicle location data” ) based on the real-time status data. The processing device 110 may determine the driving trajectory of the vehicle based on the vehicle location data. In response to determining that the driving trajectory is abnormal, the processing device 110 may determine that the vehicle is at risk and/or determine risk information associated with the vehicle. For example, the driving trajectory may be abnormal when the driver is drunk or the driver is confused. As another example, when the driving trajectory of the driver is S line or the driving trajectory of the driver is a curve with excessive curvature, etc., the processing device 110 may determine that the driving trajectory is abnormal.

In some embodiments, the processing device 110 may obtain driving behavior data of a user driving the vehicle after the speed data of the vehicle exceeds a speed threshold based on the real-time status data. The processing device 110 may determine the abnormal driving condition and/or the risk information based on the driving behavior data. For example, if the user continues to step on the accelerator to accelerate at high speeds, the processing device 110 may determine that the vehicle is at risk. As another example, in response to determining that the user steps on the brakes quickly, the processing device 110 may determine that the vehicle is not at risk. As a further example, in response to determining that the user uses lights affecting the sight of an oncoming vehicle, the processing device 110 may determine that the vehicle is at the abnormal driving condition.

In some embodiments, the processing device 110 may obtain the power data of the vehicle based on the real-time status data. The processing device 110 may determine the abnormal driving condition and/or the risk information based on the power data of the vehicle. For example, if the power of a vehicle drops rapidly in a few seconds, minutes, etc., the processing device 110 may determine that the vehicle is damaged and at risk. The processing device 110 may determine the risk information based on the rate of the drop of the power.

In some embodiments, the processing device 110 may determine the abnormal driving condition and/or the risk information using a supervised learning model. For example, the processing device 110 may determine a driving condition identification model configured to determine the risk information associated with the vehicle. Supervised learning may refer to training or obtaining a model from existing training samples (i.e., known data and its corresponding output) to implement data discrimination or classification. In some embodiments, the supervised learning model may include a machine learning model, for example, a neural network (NN) model such as a classification, a logistic regression (Logistic Regression) model, a k-Nearest Neighbor (kNN) model, a Naive Bayes (NB) model, etc. In some embodiments, the supervised learning model may include a sequence model, for example, a deep recurrent neural network (RNN) model. Sequence data with respect to the real-time status data in the driving process may be input into the RNN model that can analyze and process the input data with different sequence lengths. In some embodiments, the real-time status data in the driving process may be input into the supervised learning model to determine various conditions (e.g., the abnormal driving condition) in the driving process of the vehicle.

In some embodiments, the data input into the supervised learning model may include feature information of the real-time status information and/or feature information of the service order, for example, feature information of a driving road segment, feature information of a driving behavior of the driver, feature information of weather in a driving region of the vehicle, feature information of the power of the vehicle, feature information of the location of the vehicle, feature information of a user terminal status associated with the vehicle, feature information of the internal environment of the vehicle, feature information of the surrounding environment of the vehicle, or the like, or any combination thereof.

In some embodiments, the supervised learning model may be determined by training a preliminary model based on a plurality of training samples associated with historical status data in a plurality of historical driving processes of a plurality of vehicles. In some embodiments, one type of the historical status data may be input to the preliminary model to determine the supervised learning model. For example, a supervised learning model may be determined by training the preliminary model based on historical feature information of historical locations of the vehicles, and the trained supervised learning model may be configured to determine whether a driving trajectory of a vehicle is abnormal. As another example, a supervised learning model may be determined by training the preliminary model based on feature information of historical driving behavior associated with the vehicles, and the trained supervised learning model may be configured to determine whether a driving behavior associated with a vehicle is abnormal. As a further example, a supervised learning model may be determined by training the preliminary model based on feature information of historical service routes of the historical service orders and the trained supervised learning model may be configured to determine whether the service route of the service order is abnormal. In some embodiments, two or more types of the historical status data may be input to the preliminary model to determine the supervised learning model. For example, a supervised learning model may be determined by training the preliminary model based on historical feature information of historical locations of the vehicles and feature information of historical driving behavior associated with the vehicles, and the trained supervised learning model may be configured to determine whether a driving trajectory of a vehicle is abnormal and whether a driving behavior associated with a vehicle is abnormal.

In some embodiments, the training samples of the supervised learning model may be obtained based on the historical status data, historical service order data, theoretical data of driving processes, theoretical data of service orders, or the like, or any combination thereof. For example, the theoretical data of the driving processes may include a normal driving speed of a vehicle, a normal acceleration of a vehicle, a normal trajectory of the vehicle or other data of a vehicle. The theoretical data of the service order may include a normal deviation range of a service time of the service order, a normal deviation range of a service route of the service order, or the like, or any combination thereof. In some embodiments, the theoretical data of the driving processes and the theoretical data of the service orders may be determined based on empirical calculations, physical laws, public research data, etc.

Taking the training based on the feature information of historical driving behavior associated with the vehicles to determine the supervised learning model configured to determine whether the driving behavior associated with the vehicle is abnormal as an example, the training samples may be obtained based on historical status data of historical service order data in historical driving processes. In some embodiments, actual driving conditions (e.g., normal driving conditions, abnormal driving conditions) of the historical driving processes may be determined according to historical sensor data of vehicles associated with the historical service orders, historical feedback of driving safety from historical service providers in the historical service orders, historical sensor data of user terminals associated with the historical service orders, or the like, or any combination thereof. Feature information of historical driving behaviors corresponding to vehicles being in abnormal driving conditions may be used as positive samples. Feature information of historical driving behaviors corresponding to vehicles being in normal driving conditions may be used as negative samples. The positive and negative samples may be used as the training samples for training the supervised learning model.

In some embodiments, an unsupervised learning technique may be used to determine the driving condition and/or the risk information. The unsupervised learning technique may refer to obtaining results by directly modeling and analyzing data (e.g., real-time status data, servicer order data) without labeling the data. In some embodiments, the unsupervised learning technique may be used to analyze the data after vectorization. In some embodiments, the vectorization may refer to characterizing the real-time status data as feature vectors. Taking the driving age of the service provider as an example, a driving age of 0-3 years may proportionally correspond to [1, 0, 0] . A driving age of 3-6 years may proportionally correspond to [0, 1, 0] . A driving age of more than 6 years may proportionally correspond to [0, 0, 1] .

In some embodiments, the unsupervised learning may perform operations such as cluster analysis and similarity calculation after the data vectorization. In some embodiments, feature vectors of historical status data may be clustered, and then difference (s) between real-time feature information of the real-time status data and historical feature information may be determined. For example, a distance between the real-time feature information and the center of the cluster may be determined. As another example, the similarity between real-time feature information (e.g., a corresponding feature vector thereof) and historical feature information (e.g., a corresponding feature vector thereof) similar to the real-time feature information may be determined. Based on the distance and the similarity, historical status data (also referred to as “target historical status data” ) that is most similar to the real-time status data may be analyzed. The driving condition of the real-time status data may be determined based on the target historical status data. For example, if the target historical status data indicate that a vehicle associated with the target historical status data is in an abnormal driving condition, then it may be determined that a vehicle associated with the real-time status data is in the abnormal driving condition.

In some embodiments, the cluster analysis may be used to determine the abnormal condition and/or the risk information according to a deviation degree analysis. The deviation degree may refer to a deviation degree of the feature information of the real-time status data from the feature information of the historical status data. In some embodiments, due to the low frequency of abnormal driving events, it may be difficult to obtain sufficient samples for the supervised learning model. However, according to the present disclosure, the process and the accuracy for determining the deviation degree may not depend on the count of the abnormal driving events, which makes the process for the driving condition identification in the present disclosure be applicable for various application scenarios.

In some embodiments, the feature information may be represented by vectors. In the following descriptions, a term “current vector” may be used to represent a vector of the feature information of the real-time status data (e.g., a feature of a current driving state) , and a term “history vector” may be used to represent a vector of the historical feature information of the historical status data (e.g., historical feature information of a historical driving state) . In some embodiments, the current vector may correspond to a current time point, a time period, for example, 1 second, 2 seconds, etc.

In some embodiments, when using multiple features to represent the current vector, the multiple features may be combined in various ways, for example, vector stitching, weighted calculation, normalization, etc. Taking a feature of a current driving state and a feature of a current traveling trajectory feature as an example, a first feature vector indicating that the driving state is abnormal may be [1, 0, 0] , a second feature vector indicating that the current traveling trajectory is a curve may be [0, 1, 0] , and the vector stitching may be performed by adding the first feature vector and the second feature vector to obtain the current vector [1, 1, 0] . The weighting calculation may be performed by allocating a first weight to the first feature vector and allocating a second weight to the second feature vector, respectively, and adding the weighted feature vectors to obtain the current vector. For example, the first weight of the first feature vector may be 0.8, and the second weight of the second feature may be 0.6. Accordingly, a first weighted feature vector indicating that the driving state is abnormal may be [0.8, 0, 0] , a second weighted feature vector indicating that the current traveling trajectory is a curve may be [0, 0.6, 0] , and the first weighted feature vector and the second weighted feature vector may be added to obtain the current vector [0.8, 0.6, 0] . The normalization operation may be performed to limit values of the feature vectors to a certain required range. For example, a first feature vector indicating that the driving state is abnormal may be [1.2, 0.2, 0] , and the first feature vector [1.2, 0.2, 0] may be normalized as [1.2/ (1.2+0.2) , 0.2/ (1.2+0.2) , 0] (i.e., [0.857, 0.014, 0] ) . As another example, a second feature vector indicating that the current traveling trajectory is a curve may be [1, 1.6, 0] , and the second feature vector [1, 1.6, 0] may be normalized as [1/ (1+1.6) , 1.6/ (1+1.6) , 0] (i.e., [0.385, 0.615, 0] ) . The first normalized feature vector and the second normalized feature vector may be added to obtain the current vector.

In some embodiments, the historical feature information of the historical status data (e.g., historical feature information of the historical driving state) may be determined in the same way as the feature information of the current data. In some embodiments, the historical feature information may be pre-determined and stored.

In some embodiments, the deviation degree may be determined by various means, or may be determined by a transformation or combination of the various means. In some embodiments, the deviation degree may be determined based on average distances between a plurality of current vectors and one or more historical vectors nearest to each of the plurality of current vectors.

In some embodiments, the deviation degree may be determined based on the distances between the plurality of current vectors and a clustering center of the one or more historical vectors nearest to each of the plurality of current vectors. The clustering center of the one or more historical vectors may be pre-determined by one or more other means, for example, a K-Means clustering technique, a mean-shift clustering technique, a density-based clustering (DBSCAN) technique, a Gaussian mixture model (GMM) , etc. In some embodiments, one or more distances among the distances may be used as the deviation degree. In some embodiments, the deviation degree may be determined based on a plurality of types of current vectors. For example, the distance may be determined based on a feature vector of the current driving state and a feature vector of the current traveling trajectory feature vector to determine the deviation degree. In some embodiments, exemplary distances may include a Euclidean distance, a Manhattan distance, a Chebyshev distance, a Minkowski distance, a standardized Euclidean distance, a Markov distance, a Hamming distance, or the like, or any combination thereof.

In some embodiments, whether the vehicle is in the abnormal condition may be determined based on a relationship between at least one of the deviation degree and a degree threshold. For example, if the threshold is 0.6 and the deviation degree (e.g., the distance) determined according to the feature of the driving status is 0.9, then it may be determined that the vehicle is in the abnormal condition. As another example, if a first deviation degree (e.g., a distance) determined according to the feature of the driving status may be 0.9, and a second deviation degree (e.g., a distance) determined according to the feature of the traveling trajectory may be 0.5, then a comprehensive deviation degree may be determined by averaging, summing, or weighted summing the first deviation degree and the second deviation degree. If the comprehensive deviation degree exceeds the degree threshold, it may be determined that the vehicle is in the abnormal condition.

In some embodiments, at least one risk response operation may be performed based on the risk information. In some embodiments, the at least one risk response operation may include a risk disposal operation. In some embodiments, the risk disposal operation may include calling the police, notifying emergency contacts, turning on an in-vehicle monitoring device, triggering a reporting mechanism of the user terminal, contacting a service provider around the user for assistance, or the like, or any combinations thereof. In some embodiments, the type of the risk disposal operation may be determined based on the probability that the vehicle is in the abnormal driving condition. For example, in response to determining that the probability that the vehicle is in the abnormal driving condition exceeds a probability threshold, the possibility of the risk of a collision or rollover may be relatively high, and the police may be notified directly. As another example, the monitoring device in the vehicle may be turned on to collect audio or video information to record the damage of the vehicle and the security status of the user in the vehicle.

In some embodiments, the at least one risk response operation may also include triggering an in-vehicle alarm, limiting the speed of the vehicle, controlling the vehicle (e.g., flashing or whistling for reminding, reducing an output power of a power system of the vehicle, etc. ) , or the like, or any combination thereof.

In some embodiments, the at least one risk response operation may include a risk verification operation. In some embodiments, the risk verification operation may at least include interaction with the user for verification, risk verification based on manual research results, risk verification based on the audio or video information in the vehicle, risk verification based on traffic broadcast information, risk verification based on information associated with the user behavior after the order is completed, or the like, or any combination thereof. In some embodiments, the manual research may refer that the customer service staff communicates with the user (e.g., a passenger, a driver) via voice or video to verify whether the user is safe. In some embodiments, the driving condition may be verified according to the monitoring device disposed on the vehicle and configured to collect the audio or video information in the vehicle. In some embodiments, the traffic broadcast information may be obtained, and the driving condition may be verified based on the broadcast information such as a traffic volume on the road, whether there is traffic control, or whether there are traffic accidents, etc. In some embodiments, the risk verification may be performed based on the information associated with the user behavior after the order is completed, such as whether the passenger confirms that the order is completed, the evaluation contents of the passenger, whether the driver requests for repairing the vehicle after the order is completed, etc.

In some embodiments, the risk verification operation may be performed when the vehicle is in the abnormal condition and/or the vehicle is at risk. The risk verification operation may refer to verifying the abnormal driving condition, and/or the risk information associated with the vehicle to obtain a verification result. If the verification result indicates that the abnormal condition does not exist, the risk identification result may be adjusted. If the verification result indicates that the abnormal condition exists, the risk identification result may be verified to be true. At least one risk response operation of the abnormal condition may continue to be performed.

In some embodiments, vehicle remote diagnosis may also be performed (such as calling a diagnostic program) for further verification. For example, a diagnostic program of a vehicle may be called to diagnose the abnormal driving conditions determined for the first time and/or determine whether the abnormal driving condition is accurate. In some embodiments, if the abnormal driving condition is determined based on a part of the real-time status data for the first time. During the risk verification, more pieces of the real-time status data in the driving process may be used for determining the driving condition of the vehicle.

In some embodiments, a remote call of an APP or a vehicle control system may be configured to get more data for the risk verification. For example, the APP on the user terminal of passengers or drivers may be called to collect more data to help perform the risk verification. As another example, a vehicle control system may be called to collect more sensor data to get more data to facilitate the risk verification. In some embodiments, APP interaction may be used to perform the risk verification. For example, users such as passengers and drivers may use the APP to check the abnormal driving condition obtained for the first time and further perform the risk verification.

In some embodiments, automatic voice interaction may be used to perform the risk verification. For example, users such as passengers and drivers may perform the risk verification based on voice broadcast information associated with a feedback of the abnormal driving condition determined for the first time. For example, when the abnormal driving condition exists, a vehicle communication system or a user terminal may perform the voice broadcast, and a passenger and a driver may interact with the vehicle communication system by voice or text, and/or feed back whether the abnormal driving condition actually exists.

In some embodiments, the processing device 110 may perform at least one risk response operation based on the risk information of the vehicle. More descriptions of the at least one risk response operation may be found elsewhere in the present disclosure. See, for example, FIGs. 3 and 4 and descriptions thereof.

It should be noted that that the description of the process 500 is merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. However, those variations and modifications do not depart from the scope of the present disclosure. In some embodiments, the process 500 may further include storing feature information of the real-time status data of the service order to be identified in the storage device 130.

FIG. 6 is a flowchart illustrating another exemplary process 600 for identifying a driving condition of a vehicle according to some embodiments of the present disclosure. In some embodiments, one or more operations in process 600 may be implemented in the system 100 shown in FIG. 1. For example, one or more operations in process 600 may be stored in the form of instructions in the storage device 130 and/or storage 270 and executed by the processing device 110. In some embodiments, in the process 600, the processing device 110 may assess and/or prevent the risks in a driving process based on speed data associated with the driving process.

In 610, the processing device 110 (e.g., the data obtaining module 310) may obtain a first piece of speed data of the vehicle collected by a sensor. In some embodiments, the processing device 110 may determine a first condition identification result based on the first piece of speed data. In some embodiments, the first piece of speed data of the vehicle may be obtained through calculation. For example, the driving distance of the vehicle in the driving direction for a time period may be determined. The first piece of speed data may be obtained according to a relationship between the driving distance and the time period. In some embodiments, the first piece of speed data of the vehicle may be obtained by an acceleration sensor disposed on the vehicle. In some embodiments, the acceleration sensor disposed on the vehicle may include a uniaxial acceleration sensor (e.g., a lateral acceleration sensor, a longitudinal acceleration sensor) , a triaxial (e.g., an X-axis direction, a Y-axis direction, a Z-axis direction) acceleration sensor, a gravity acceleration sensor, a piezoelectric acceleration sensor, a capacitive acceleration sensor, a piezoresistive acceleration sensor or the like, or any combination thereof. In some embodiments, the first condition identification result may be an identification result of whether the vehicle is in the abnormal driving condition. In some embodiments, the first condition identification result may include a probability that the vehicle is in the abnormal driving condition.

In 620, the processing device 110 (e.g., the data obtaining module 310) may obtain a second piece of speed data of the vehicle collected by the user terminal. In some embodiments, the processing device 110 may determine a second condition identification result based on the second piece of speed data. In some embodiments, the user terminal may include a service provider terminal and/or a service requester terminal. In some embodiments, the second piece of speed data of the vehicle may be determined based on driving data associated with the user terminal. For example, the user terminal may obtain a displacement of the user terminal for a time period and determine the speed of the user terminal. In some embodiments, the acceleration of the user terminal may be the acceleration of the service provider terminal and/or the service requester terminal. In some embodiments, the service provider terminal or the service requester terminal may include, but is not limited to, a smartphone, a personal digital assistant (PDA) , a tablet computer, a handheld game player, a smart glasses, a smart watch, a wearable device, a virtual reality device, a augmented reality device, or the like, or any combination thereof. In some embodiments, the acceleration of the user terminal may be detected by an acceleration sensor disposed in the user terminal. In some embodiments, the second condition identification result may be an identification result of whether the vehicle (or the user terminal) is in the abnormal driving condition. In some embodiments, the second condition identification result may be a probability that the vehicle (or the user terminal) is in the abnormal driving condition.

In 630, the processing device 110 (e.g., the risk determination module 320) may determine whether the vehicle is in the abnormal driving condition based on the first condition identification result and the second condition identification result. In some embodiments, in response to determining that the first condition identification result is consistent with the second condition identification result, and the first condition identification result and the second condition identification result both indicate that the vehicle is in the abnormal driving condition, then the processing device 110 may determine that the vehicle is in the abnormal driving condition, and the probability that the vehicle is in the abnormal driving condition may be relatively high. In some embodiments, in response to determining that the first condition identification result is inconsistent with the second condition identification result, the processing device 110 may determine that the vehicle is in the abnormal driving condition, and the probability that the vehicle is in the abnormal driving condition may be relatively low. In some embodiments, in response to determining that the first condition identification result is inconsistent with the second condition identification result, a risk verification operation may be performed first, and a third condition identification result may be further determined. For example, the third condition identification result may be further determined through manual research. As another example, a vehicle driving status may be checked by turning on an audio or video device in the vehicle to further determine the third condition identification result.

It should be noted that the above description of the process 600 is merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. However, those variations and modifications do not depart from the scope of the present disclosure.

FIG. 7 is a flowchart illustrating an exemplary process for training a driving condition identification model according to some embodiments of the present disclosure. In some embodiments, one or more operations in process 700 may be implemented in the system 100 shown in FIG. 1. For example, one or more operations in process 700 may be stored in the form of instructions in the storage device 130 and/or storage 270 and executed by the processing device 110.

In 710, the processing device 110 (e.g., the training module 330) may obtain historical status data in historical driving processes. In some embodiments, the historical status data in the historical driving processes may be associated with records of the historical driving processes of any vehicle. For example, the historical status data in the historical driving processes may include records of historical driving processes of buses, records of historical driving processes of private cars, records of historical riving processes of taxis, records of historical driving processes of other vehicles in road traffic, etc. The historical status data in the historical driving process may be not limited to the records of the historical driving processes of vehicles associated with historical service orders in the system 100. For example, a part of the records may be obtained from an external source (e.g., a third-party) associated with the system 100. In some embodiments, the historical status data of the historical driving processes may include records of driving processes in historical service orders, for example, taxi-hailing orders, chauffeur orders, express car orders, carpool orders, bus orders, driver hire orders, shuttle orders, other historical transportation orders, etc. In some embodiments, the historical status data in the historical driving processes within a time period (e.g., one week, one month, etc. ) may be obtained as training samples. In some embodiments, a part of the historical status data in the historical driving processes may be obtained from a road transportation system (e.g., through a network, a transportation platform, a traffic sharing resource, etc. ) . In some embodiments, the historical status data in the historical driving processes may be obtained from one or more components (e.g., the processing device 110, the terminal (s) 120, the information source 150) of the system 100 (e.g., via the network 140) . In some embodiments, the historical status data in the historical driving processes may at least include historical speed data of vehicle (s) . In some embodiments, the historical status data in the historical driving processes may include historical location data of the vehicle (s) , historical status data of user terminal (s) associated with the vehicle (s) , historical data associated with historical internal environment of the vehicle (s) , historical data associated with historical surrounding environment of the vehicle (s) , historical data associated with historical driving behaviors of the vehicle (s) , and/or historical power data of the vehicle (s) . In some embodiments, the historical status data may be obtained through vehicle-mounted sensor (s) , user terminal (s) , monitoring device (s) external to the vehicle (s) , etc.

In 720, the processing device 110 (e.g., the training module 330) may label historical status data of which vehicles with abnormal driving conditions in the historical driving processes as positive samples, and/or label historical status data of which vehicles without abnormal driving conditions in the historical driving processes as negative samples. For example, the historical status data in the historical driving processes of vehicles with dangerous driving events (e.g., rollovers, crashes, drivers being kidnapped, conflicts between drivers and passengers, etc. ) that affect the personal safety of users in the vehicle (s) , may be determined as positive samples. Conversely, the historical status data in the historical driving processes of vehicles without abnormal driving conditions may be determined as negative samples. In some embodiments, the historical status data may be labeled manually. For example, a crash occurred on February 8, 2017, and historical status data in historical driving processes of a plurality of (e.g., all) vehicles on February 8, 2017, may be obtained as training samples. The historical status data in historical driving processes of vehicles with the crash occurred on February 8, 2017, may be labeled as positive samples, and other historical status data in historical driving processes of vehicles without crash occurred on February 8, 2017, may be labeled as negative samples. In some embodiments, according to the records in the system 100, the historical status data in historical driving processes of vehicles with dangerous driving events (e.g., rollovers, crashes, drivers being kidnapped, conflicts between drivers and passengers, etc. ) that affect the personal safety of the people in the vehicles may be labeled as positive samples. The historical status data in historical driving processes of vehicles without the abnormal driving conditions may be labeled as negative samples. In some embodiments, the positive samples may be represented by the number "1" and the negative samples may be represented by the number "0" .

In 730, the processing device 110 (e.g., the training module 330) may determine a driving condition identification model by training a preliminary driving condition identification model based on the historical status data in the historical driving processes and the labeled results. In some embodiments, the (preliminary) driving condition identification model may be a machine learning model, for example, a classification and logistic regression (LR) model, a k-nearest neighbor (kNN) model, a Naive Bayes (NB) model, a support vector machine (SVM) , a decision tree (DT) model, a random forest (RF) model, a classification and regression tree (CART) model, a gradient boosting decision tree (GBDT) model, a xgboost (or referred to as eXtreme Gradient Boosting) , a light gradient boosting machine (or referred to as LightGBM) , a gradient boosting machine (GBM) , a least absolute shrinkage and selection operator (LASSO) , an artificial neural network (ANN) model, etc. In some embodiments, the driving condition identification model may be trained by using historical speed data of the vehicles, historical acceleration data of the vehicles, historical speed data of user terminal (s) , historical acceleration data of the user terminal (s) in at least a part (e.g., a part of, the whole) of the historical driving processes, etc., as input of the preliminary driving condition identification model, and using the labeled results as desired output of the preliminary driving condition identification model.

In some embodiments, model parameters may be adjusted based on difference (s) between predicted output (e.g., the predicted type of the risk) of the preliminary driving condition identification model and the desired output. In response to determining that a termination condition is satisfied, the training process may be terminated. Exemplary termination conditions may include that a count of training samples reaches a preset count, the prediction accuracy rate exceeds a preset threshold, a loss function value is smaller than a preset value, or the like, or any combination thereof.

In some embodiments, the desired output determined in operation 720 may include actual driving condition (s) (e.g., an abnormal condition, a normal condition) of the vehicles associated with the historical status data, and the trained driving condition identification model may be used to determine whether a vehicle is in an abnormal driving condition in a driving process of the vehicle. In some embodiments, the desired output determined in operation 720 may include actual risk information associated with the vehicles, and the trained driving condition identification model may be used to determine risk information associated with a vehicle in a driving process of the vehicle. In some embodiments, the desired output determined in operation 720 may include the actual driving condition and the actual risk information, and the trained driving condition identification model may be used to determine whether a vehicle is in an abnormal driving condition in a driving process of the vehicle and risk information associated with the vehicle.

FIG. 8 is a flowchart illustrating an exemplary process 800 for determining risk information of a vehicle using a driving condition identification model according to some embodiments of the present disclosure. In some embodiments, one or more operations in process 800 may be implemented in the system 100 shown in FIG. 1. For example, one or more operations in process 800 may be stored in the form of instructions in the storage device 130 and/or storage 270 and executed by the processing device 110.

In 810, the processing device 110 (e.g., the data obtaining module 310) may obtain real-time status data in a vehicle driving process of a vehicle. In some embodiments, the real-time status data of the vehicle may at least include speed data of the vehicle, e.g., the speed and/or the acceleration of the vehicle. The speed data may be obtained via a sensor and/or a user terminal. In some embodiments, the real-time status data of the vehicle may further include location data of the vehicle, status data of a user terminal associated with the vehicle, data associated with internal environment of the vehicle, data associated with surrounding environment of the vehicle, data associated with a driving behavior of the vehicle, power data of the vehicle, or the like, or any combination thereof. In some embodiments, a driving condition identification model (e.g., the driving condition identification model as illustrated in FIGs. 4-7) may be obtained. The driving condition identification model may be used to determine risk information associated with a vehicle in a driving process of the vehicle based on the real-time status data. In some embodiments, the driving condition identification model may be obtained from the processing device 110, the storage device 130, the terminal (s) 120, and the information source 150 (e.g., via the network 140) .

In 820, the processing device 110 (e.g., the risk determination module 320) may determine risk information associated with the vehicle in the driving process by processing the real-time status data in the driving process based on the driving condition identification model. In some embodiments, at least a part of the real-time status data, for example, the speed of the vehicle, the acceleration of the vehicle, the speed of the user terminal, the acceleration of the user terminal, associated with the driving process may be input into the driving condition identification model. In some embodiments, a combination of one or more of the location data of the vehicle, the status data of the user terminal associated with the vehicle, the data associated with the internal environment of the vehicle, the data associated with the surrounding environment of the vehicle, the data associated with the driving behavior of the vehicle, or the power data of the vehicle in the driving process may be input into the driving condition identification model. In some embodiments, the driving condition identification model may output the risk identification result, for example, whether the vehicle is at risk (e.g., whether a collision of the vehicle or a rollover of the vehicle occurs) . In some embodiments, the driving condition identification model may output a probability that the vehicle is at risk, and may determine whether the vehicle is at risk according to the probability. In some embodiments, at least one risk response operation may be performed based on the risk identification result. More descriptions of the at least one risk response operation can be found elsewhere in the present disclosure, for example, FIGs. 3-5 and the descriptions thereof.

FIG. 9 is a schematic diagram illustrating exemplary hardware and software components of a computing device 900 on which the processing device 110, and/or the user terminal (s) 120 may be implemented according to some embodiments of the present disclosure. For example, the processing device 110 may be implemented on the computing device 900 and configured to perform functions of the processing device 110 disclosed in this disclosure.

The computing device 900 may be configured to implement the system 100 for the present disclosure. The computing device 900 may be configured to implement any component of the system 100 that performs one or more functions disclosed in the present disclosure. For example, the processing device 110 may be implemented on the computing device 900, via its hardware, software program, firmware, or a combination thereof. Although only one such computer is shown, for convenience, the computer functions relating to the online-to-offline service as described herein may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load.

The computing device 900, for example, may include COM ports 950 connected to and from a network connected thereto to facilitate data communications. The COM port 950 may be any network port or data exchange port to facilitate data communications. The computing device 900 may also include a processor (e.g., the processor 920) , in the form of one or more processors (e.g., logic circuits) , for executing program instructions. For example, the processor may include interface circuits and processing circuits therein. The interface circuits may be configured to receive electronic signals from a bus 910, wherein the electronic signals encode structured data and/or instructions for the processing circuits to process. The processing circuits may conduct logic calculations, and then determine a conclusion, a result, and/or an instruction encoded as electronic signals. The processing circuits may also generate electronic signals including the conclusion or the result (e.g., a risk identification result) and a triggering code. In some embodiments, the trigger code may be in a format recognizable by an operation system (or an application installed therein) of an electronic device (e.g., the user terminal (s) 120) in the system 100. For example, the trigger code may be an instruction, a code, a mark, a symbol, or the like, or any combination thereof, that can activate certain functions and/or operations of a mobile phone or let the mobile phone execute a preset program (s) . In some embodiments, the trigger code may be configured to rend the operation system (or the application) of the electronic device to generate a presentation of the conclusion or the result (e.g., a risk identification result) on an interface of the electronic device. Then the interface circuits may send out the electronic signals from the processing circuits via the bus 910.

The exemplary computing device may include the internal communication bus 910, program storage and data storage of different forms including, for example, a disk 970, and a read-only memory (ROM) 930, or a random access memory (RAM) 940, for various data files to be processed and/or transmitted by the computing device. The exemplary computing device may also include program instructions stored in the ROM 930, RAM 940, and/or other type of non-transitory storage medium to be executed by the processor 920. The methods and/or processes of the present disclosure may be implemented as the program instructions. The exemplary computing device may also include operation systems stored in the ROM 930, RAM 940, and/or other type of non-transitory storage medium to be executed by the processor 920. The program instructions may be compatible with the operation systems for providing the online-to-offline service. The computing device 900 also includes an I/O component 960, supporting input/output between the computer and other components. The computing device 900 may also receive programming and data via network communications.

Merely for illustration, only one processor is illustrated in FIG. 9. Multiple processors are also contemplated; thus, operations and/or method operations performed by one processor as described in the present disclosure may also be jointly or separately performed by the multiple processors. For example, if in the present disclosure the processor of the computing device 900 executes both operation A and operation B, it should be understood that operation A and operation B may also be performed by two different processors jointly or separately in the computing device 900 (e.g., the first processor executes operation A and the second processor executes operation B, or the first and second processors jointly execute operations A and B) .

FIG. 10 is a flowchart illustrating an exemplary process for determining risk information associated with a vehicle according to some embodiments of the present disclosure. In some embodiments, one or more operations in process 1000 may be implemented in the system 100 shown in FIG. 1. For example, one or more operations in process 1000 may be stored in the form of instructions in the storage device 130 and/or storage 270 and executed by the processing device 110.

In 1010, the processing device 110 (e.g., the data obtaining module 310) may obtain real-time status data in a driving process of the vehicle. As described in connection with FIGs. 4-5 and FIG. 8, the real-time status data may include speed data of the vehicle, location data of the vehicle, status data of a user terminal associated with the vehicle, data associated with internal environment of the vehicle, data associated with surrounding environment of the vehicle, data associated with a driving behavior of the vehicle, power data of the vehicle, or the like, or any combination thereof. For example, the speed data may include a speed of the vehicle, an acceleration of the vehicle, etc.

In some embodiments, the processing device 110 may obtain the real-time status data based on data relating a service order (also referred to as “service order data” ) . The service order data may be associated with the vehicle in the driving process. As described in connection with FIG. 4, the service order data may include data associated with a user (e.g., a service provider, a service requester) of the service order, the real-time status data of the vehicle, etc. More descriptions of the real-time status data and/or the service order data can be found elsewhere in the present disclosure, for example, FIGs. 4-5, FIG. 8 and the descriptions thereof.

In some embodiments, the processing device 110 may obtain the real-time status data from the terminal (s) 120, the storage device 130, and/or the information source 150 (e.g., via the network 140) . In some embodiments, the processing device 110 may obtain the real-time status data from an external source, for example, a monitoring device external to the vehicle. In some embodiments, the processing device 110 may directly obtain the real-time status data.

In 1020, the processing device 110 (e.g., the risk determination module 320) may determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data to obtain a determination result. For example, the abnormal driving condition may include the speed of the vehicle being abnormal, the acceleration of the vehicle being abnormal, the driving direction of the vehicle deviating, dangerous driving, etc.

In some embodiments, the processing device 110 may obtain the determination result based on a part of the one or more risk determination rules illustrated in FIGs. 3-6. For example, the part of the one or more risk determination rules may include whether the speed data of the vehicle exceed a speed range, whether a first difference between an actual travel time and an estimated travel time of the vehicle exceeds a time threshold, whether a second difference between an actual start location and a preset start location or a third difference between an actual destination and a preset destination of the vehicle exceeds a first difference threshold, whether a fourth difference between an actual route and a preset route of the vehicle exceeds a second difference threshold, or the like, or any combination thereof.

In some embodiments, the processing device 110 may determine whether the speed data exceeds a first speed range. In response to determining that the speed data exceeds the first speed range, the processing device 110 may determine that the vehicle is in the abnormal driving condition in the driving process.

In some embodiments, the processing device 110 may determine whether the first difference between the actual travel time and the estimated travel time of the vehicle exceeds the time threshold. In response to determining that the first difference exceeds the time threshold, the processing device 110 may determine that the vehicle is in the abnormal driving condition in the driving process.

In some embodiments, the processing device 110 may determine whether the second difference between the actual start location and the preset start location or the third difference between the actual destination and the preset destination of the vehicle exceeds the first difference threshold. In response to determining that the second difference or the third difference exceeds the first difference threshold, the processing device 110 may determine that the vehicle is in the abnormal driving condition in the driving process.

In some embodiments, the processing device 110 may determine whether the fourth difference between the actual route and the preset route of the vehicle exceeds the second difference threshold. In response to determining that fourth difference exceeds the second difference threshold, the processing device 110 may determine that the vehicle is in the abnormal driving condition in the driving process. More descriptions of obtaining the determination result based on the part of the one or more risk determination rules can be found elsewhere in the present disclosure, for example, FIGs. 3-6 and the descriptions thereof.

In some embodiments, the processing device 110 may determine whether the vehicle is in an abnormal driving condition in the driving process using a driving condition identification model as illustrated in FIGs. 3-9 based on the real-time status data. The driving condition identification model may be used to determine whether a vehicle is in an abnormal driving condition in a driving process of the vehicle based on real-time status data in the driving process. More descriptions of obtaining the determination result based on the abnormal driving condition model can be found elsewhere in the present disclosure, for example, FIGs. 3-5 and the descriptions thereof.

In 1030, the processing device 110 (e.g., the risk determination module 320) may determine risk information associated with the vehicle in the driving process based on the determination result. The risk information may include whether the vehicle is at risk in the driving process, a type of the risk, a level of the risk, or the like, or any combination thereof. For example, the type of the risk may include a risk of violating the road safety law, a risk of violating driving behavior regulation, a risk of violating vehicle operation regulation, or the like, or any combination thereof. As another example, the type of the risk may include a risk that the speed of the vehicle is abnormal, a risk that the acceleration of the vehicle is abnormal, a risk that the driving direction of the vehicle deviates, a rollover of the vehicle, a collision of the vehicle. The level of the risk may include, for example, a mild level, a moderate level, a high level, etc.

In some embodiments, the processing device 110 may determine the risk information based on another part of the one or more risk determination rules. In some embodiments, the processing device 110 may determine whether a variation of the speed data of the vehicle with time satisfies a first condition. In response to determining that the variation satisfies the first condition, the processing device 110 may determine that the vehicle is at no risk. In some embodiments, the processing device 110 may determine whether the speed data of the vehicle exceeds a second speed range. In response to determining that the speed data of the vehicle exceeds the second speed range, the processing device 110 may determine a duration time in which the speed data of the vehicle exceeds the second speed range. The processing device 110 may determine whether the duration time exceeds a time threshold. In response to determining that the duration time exceeds the time threshold, the processing device 110 may determine that the vehicle is at risk.

In some embodiments, the processing device 110 may obtain the location data of the vehicle based on the real-time status data. In some embodiments, the processing device 110 may determine, based on the location data of the vehicle, a driving trajectory of the vehicle after the speed data of the vehicle exceeds a fourth speed range. In some embodiments, the processing device 110 may determine the risk information associated with the vehicle based on the driving trajectory.

In some embodiments, the processing device 110 may obtain data associated with a user behavior after the speed data of the vehicle exceeds a fifth speed range based on the real-time status data. In some embodiments, the processing device 110 may determine the risk information associated with the vehicle based on the data associated with the user behavior. In some embodiments, the data associated with the user behavior may at least include one operation of the user in an application of a service platform.

In some embodiments, the processing device 110 may obtain vehicle posture data after the speed data of the vehicle exceeds a third speed range based on the real-time status data. In response to determining that the vehicle posture data satisfies a second condition, the processing device 110 may determine that the vehicle is at risk.

As illustrated in FIG. 8, the driving condition identification model may be used to determine the risk information associated with the vehicle. In some embodiments, the processing device 110 may determine the risk information using the driving condition identification model based on the determination result in operation 1020. More descriptions of determining the risk information can be found elsewhere in the present disclosure, for example, FIGs. 3-5 and the descriptions thereof.

It should be noted that the above descriptions are described for illustration purposes. In some embodiments, in 1010, the processing device 110 may simultaneously obtain real-time stats data in a plurality of driving processes of a plurality of vehicles and for further processing. In some embodiments, the processing device 110 may simultaneously process at least a part of the real-time status data in 1020 and 1030 to obtain the abnormal driving condition and/or the risk information.

In some embodiments, the processing device 110 may perform at least one risk response operation corresponding to the abnormal driving condition and/or the risk information, thereby reducing the effect of the abnormal driving condition and/or the risk information on a user (e.g., a driver and passenger) associated with the vehicle and further ensuring the personal safety of the user.

It should be noted that the above description of the process 1000 is merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. However, those variations and modifications do not depart from the scope of the present disclosure. For example, operation 1020 may be omitted. The processing device 110 may directly determine the risk information associated with the vehicle in the driving process using the driving condition identification model or the one or more risk determination rules based on the real-time status data. As used herein, the driving condition identification model may be configured to determine whether the vehicle is in the abnormal condition and determine the risk information associated with the vehicle in a driving process of the vehicle based on real-time status data of the vehicle in the driving process. Alternatively, the driving condition identification model may be used to determine risk information associated with a vehicle in a driving process of the vehicle based on real-time status data of the vehicle in the driving process.

According to the present disclosure, real-time status data in a driving process of a vehicle may be used to determine whether the vehicle is in an abnormal driving condition (e.g., a crash or a rollover of the vehicle) , and at least one response operation may be implemented based on the determination result to ensure the safety of a user (e.g., a driver, a passenger) associated with the vehicle. It should be noted that different embodiments may have different beneficial effects. In different embodiments, the possible beneficial effects may be any one or a combination of the foregoing and may be any other beneficial effects that may be obtained.

Having thus described the basic concepts, it may be rather apparent to those skilled in the art after reading this detailed disclosure that the foregoing detailed disclosure is intended to be presented by way of example only and is not limiting. Various alterations, improvements, and modifications may occur and are intended to those skilled in the art, though not expressly stated herein. These alterations, improvements, and modifications are intended to be suggested by this disclosure, and are within the spirit and scope of the exemplary embodiments of this disclosure.

Moreover, certain terminology has been configured to describe embodiments of the present disclosure. For example, the terms “one embodiment, ” “an embodiment, ” and/or “some embodiments” mean that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment, ” “one embodiment, ” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the present disclosure.

Further, it will be appreciated by one skilled in the art, aspects of the present disclosure may be illustrated and described herein in any of a number of patentable classes or context including any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof. Accordingly, aspects of the present disclosure may be implemented entirely hardware, entirely software (including firmware, resident software, micro-code, etc. ) or combining software and hardware implementation that may all generally be referred to herein as a "block, " “module, ” “engine, ” “unit, ” “component, ” or “system. ” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable media having computer readable program code embodied thereon.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including electro-magnetic, optical, or the like, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that may communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable signal medium may be transmitted using any appropriate medium, including wireless, wireline, optical fiber cable, RF, or the like, or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB. NET, Python or the like, conventional procedural programming languages, such as the “C” programming language, Visual Basic, Fortran 1703, Perl, COBOL 1702, PHP, ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN) , or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider) or in a cloud computing environment or offered as a service such as a software as a service (SaaS) .

Furthermore, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations, therefore, is not intended to limit the claimed processes and methods to any order except as may be specified in the claims. Although the above disclosure discusses through various examples what is currently considered to be a variety of useful embodiments of the disclosure, it is to be understood that such detail is solely for that purpose, and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover modifications and equivalent arrangements that are within the spirit and scope of the disclosed embodiments. For example, although the implementation of various components described above may be embodied in a hardware device, it may also be implemented as a software-only solution-e.g., an installation on an existing server or mobile device.

Similarly, it should be appreciated that in the foregoing description of embodiments of the present disclosure, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the various embodiments. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. Rather, claimed subject matter may lie in less than all features of a single foregoing disclosed embodiment.

Claims

A system configured to identify a driving condition of a vehicle, comprising:

at least one storage medium including a set of instructions; and

at least one processor in communication with the at least one storage medium, wherein when executing the set of instructions, the at least one processor is directed to:

obtain real-time status data in a driving process of the vehicle;

determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data to obtain a determination result; and

determine risk information associated with the vehicle in the driving process based on the determination result.
The system of claim 1, wherein to obtain real-time status data in a driving process of the vehicle, the at least one processor is further directed to:

obtain service order data associated with the vehicle in the driving process; and

obtain the real-time status data based on the service order data.
The system of claim 1 or claim 2, wherein the real-time status data in the driving process of the vehicle includes at least one of speed data of the vehicle, location data of the vehicle, status data of a user terminal associated with the vehicle, data associated with internal environment of the vehicle, data associated with surrounding environment of the vehicle, data associated with a driving behavior of the vehicle, or power data of the vehicle.
The system of claim 3, wherein

the speed data of the vehicle includes a speed of the vehicle or an acceleration of the vehicle; and

the speed data of the vehicle is obtained via a sensor disposed on the vehicle, the user terminal, or a monitoring device external to the vehicle.
The system of claim 3 or claim 4, wherein the user terminal includes a terminal of a service provider or a terminal of a service requester.
The system of any one of claims 3-5, wherein the real-time status data includes the speed data of the vehicle, and to determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data, the at least one processor is further directed to:

determine whether the speed data exceeds a first speed range; and

in response to determining that the speed data exceeds the first speed range, determine that the vehicle is in the abnormal driving condition in the driving process.
The system of claim 4 or claim 5, wherein to determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data, the at least one processor is further directed to:

obtain a first piece of speed data of the vehicle collected by the sensor;

determine a first condition identification result based on the first piece of speed data;

obtaining a second piece of speed data of the vehicle collected by the user terminal;

determine a second condition identification result based on the second piece of speed data; and

determine whether the vehicle is in the abnormal driving condition based on the first condition identification result and second condition identification result.
The system of any one of claims 1-5, wherein to determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data, the at least one processor is further directed to:

determine whether the vehicle is in the abnormal driving condition in the driving process using a driving condition identification model based on the real-time status data.
The system of any one of claims 1-8, wherein the risk information includes at least one of whether the vehicle is at risk in the driving process, a type of the risk, or a level of the risk.
The system of any one of claims 1-9, wherein to determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data, the at least one processor is further directed to:

extract feature information of the real-time status data; and

determine whether the vehicle is in an abnormal driving condition in the driving process based on the feature information.
The system of any one of claims 1-10, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and to determine risk information associated with the vehicle in the driving process based on the determination result, the at least one processor is further directed to:

determine whether a variation of the speed data of the vehicle with time satisfies a first condition; and

in response to determining that the variation satisfies the first condition, determine that the vehicle is at no risk.
The system of any one of claims 1-10, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and to determine risk information associated with the vehicle in the driving process based on the determination result, the at least one processor is further directed to:

determining whether the speed data of the vehicle exceeds a second speed range; and

in response to determining that the speed data of the vehicle exceeds the second speed range,

determining a duration time in which the speed data of the vehicle exceeds the second speed range;

determining whether the duration time exceeds a time threshold; and

in response to determining that the duration time exceeds the time threshold, determining that the vehicle is at risk.
The system of any one of claims 1-10, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and to determine risk information associated with the vehicle in the driving process based on the determination result, the at least one processor is further directed to:

obtain, based on the real-time status data, vehicle posture data after the speed data of the vehicle exceeds a third speed range; and

in response to determining that the vehicle posture data satisfies a second condition, determine that the vehicle is at risk.
The system of any one of claims 9-13, wherein the risk includes a rollover of the vehicle or a collision of the vehicle in the driving process.
The system of any one of claims 3-10, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and to determine risk information associated with the vehicle in the driving process based on the determination result, the at least one processor is further directed to:

obtain, based on the real-time status data, the location data of the vehicle;

determine, based on the location data of the vehicle, a driving trajectory of the vehicle after the speed data of the vehicle exceeds a fourth speed range; and

determine, based on the driving trajectory, the risk information associated with the vehicle.
The system of any one of claims 1-10, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and to determine risk information associated with the vehicle in the driving process based on the determination result, the at least one processor is further directed to:

obtain, based on the real-time status data, data associated with a user behavior after the speed data of the vehicle exceeds a fifth speed range; and

determine, based on the data associated with the user behavior, the risk information associated with the vehicle.
The system of claim 16, wherein the data associated with the user behavior includes at least one operation of the user in an application of a service platform.
The system of any one of claims 1-17, wherein the at least one processor is further directed to:

perform at least one risk response operation based on the risk information.
A system configured to identify a driving condition of a vehicle, comprising:

at least one storage medium including a set of instructions; and

at least one processor in communication with the at least one storage medium, wherein when executing the set of instructions, the at least one processor is directed to:

obtain real-time status data in a driving process of the vehicle; and

determine risk information associated with the vehicle in the driving process using a driving condition identification model based on the real-time status data.
A method for identifying a driving condition of a vehicle, the method being implemented on a computing device having at least one processor and at least one storage device, the method comprising:

obtaining real-time status data in a driving process of the vehicle;

determining whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data to obtain a determination result; and

determining risk information associated with the vehicle in the driving process based on the determination result.
The method of claim 20, wherein the obtaining real-time status data in a driving process of the vehicle comprises:

obtaining service order data associated with the vehicle in the driving process; and

obtaining the real-time status data based on the service order data.
The method of claim 20 or claim 21, wherein the real-time status data in the driving process of the vehicle includes at least one of speed data of the vehicle, location data of the vehicle, status data of a user terminal associated with the vehicle, data associated with internal environment of the vehicle, data associated with surrounding environment of the vehicle, data associated with a driving behavior of the vehicle, or power data of the vehicle.
The method of claim 22, wherein

the speed data of the vehicle includes a speed of the vehicle or an acceleration of the vehicle; and

the speed data of the vehicle is obtained via a sensor disposed on the vehicle, the user terminal, or a monitoring device external to the vehicle.
The method of claim 22 or claim 23, wherein the user terminal includes a terminal of a service provider or a terminal of a service requester.
The method of any one of claims 22-24, wherein the real-time status data includes the speed data of the vehicle, and the determining whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data comprises:

determining whether the speed data exceeds a first speed range; and

in response to determining that the speed data exceeds the first speed range, determining that the vehicle is in the abnormal driving condition in the driving process.
The method of claim 23 or claim 24, wherein the determining whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data comprises:

obtaining a first piece of speed data of the vehicle collected by the sensor;

determining a first condition identification result based on the first piece of speed data;

obtaining a second piece of speed data of the vehicle collected by the user terminal;

determining a second condition identification result based on the second piece of speed data; and

determining whether the vehicle is in the abnormal driving condition based on the first condition identification result and second condition identification result.
The method of any one of claims 20-24, wherein the determining whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data comprises:

determining whether the vehicle is in the abnormal driving condition in the driving process using a driving condition identification model based on the real-time status data.
The method of any one of claims 20-27, wherein the risk information includes at least one of whether the vehicle is at risk in the driving process, a type of the risk, or a level of the risk.
The method of any one of claims 20-28, wherein the determining whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data comprises:

extracting feature information of the real-time status data; and

determining whether the vehicle is in an abnormal driving condition in the driving process based on the feature information.
The method of any one of claims 20-29, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and the determining risk information associated with the vehicle in the driving process based on the determination result comprises:

determining whether a variation of the speed data of the vehicle with time satisfies a first condition; and

in response to determining that the variation satisfies the first condition, determining that the vehicle is at no risk.
The method of any one of claims 20-29, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and the determining risk information associated with the vehicle in the driving process based on the determination result comprises:

determining whether the speed data of the vehicle exceeds a second speed range; and

in response to determining that the speed data of the vehicle exceeds the second speed range,

determining a duration time in which the speed data of the vehicle exceeds the second speed range;

determining whether the duration time exceeds a time threshold; and

in response to determining that the duration time exceeds the time threshold, determining that the vehicle is at risk.
The method of any one of claims 20-29, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and the determining risk information associated with the vehicle in the driving process based on the determination result comprises:

obtaining, based on the real-time status data, vehicle posture data after the speed data of the vehicle exceeds a third speed range; and

in response to determining that the vehicle posture data satisfies a second condition, determining that the vehicle is at risk.
The method of any one of claims 28-32, wherein the risk includes a rollover of the vehicle or a collision of the vehicle in the driving process.
The method of any one of claims 22-29, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and the determining risk information associated with the vehicle in the driving process based on the determination result comprises:

obtaining, based on the real-time status data, the location data of the vehicle;

determining, based on the location data of the vehicle, a driving trajectory of the vehicle after the speed data of the vehicle exceeds a fourth speed range; and

determining, based on the driving trajectory, the risk information associated with the vehicle.
The method of any one of claims 20-29, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and the determining risk information associated with the vehicle in the driving process based on the determination result comprises:

obtaining, based on the real-time status data, data associated with a user behavior after the speed data of the vehicle exceeds a fifth speed range; and

determining, based on the data associated with the user behavior, the risk information associated with the vehicle.
The method of claim 35, wherein the data associated with the user behavior includes at least one operation of the user in an application of a service platform.
The method of any one of claims 20-36, further comprising:

performing at least one risk response operation based on the risk information.
A method for identifying a driving condition of a vehicle, the method being implemented on a computing device having at least one processor and at least one storage device, the method comprising:

obtaining real-time status data in a driving process of the vehicle; and

determining risk information associated with the vehicle in the driving process using a driving condition identification model based on the real-time status data.
A system configured to identify a driving condition of a vehicle, comprising:

a data obtaining module configured to obtain real-time status data in a driving process of the vehicle;

a risk determination module configured to determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data to obtain a determination result; and

the risk determination module further configured to determine risk information associated with the vehicle in the driving process based on the determination result.
The system of claim 39, wherein to obtain real-time status data in a driving process of the vehicle, the data obtaining module is further configured to:

obtain service order data associated with the vehicle in the driving process; and

obtain the real-time status data based on the service order data.
The system of claim 39 or claim 40, wherein the real-time status data in the driving process of the vehicle includes at least one of speed data of the vehicle, location data of the vehicle, status data of a user terminal associated with the vehicle, data associated with internal environment of the vehicle, data associated with surrounding environment of the vehicle, data associated with a driving behavior of the vehicle, or power data of the vehicle.
The system of claim 41, wherein

the speed data of the vehicle includes a speed of the vehicle or an acceleration of the vehicle; and

the speed data of the vehicle is obtained via a sensor disposed on the vehicle, the user terminal, or a monitoring device external to the vehicle.
The system of claim 41 or claim 42, wherein the user terminal includes a terminal of a service provider or a terminal of a service requester.
The system of any one of claims 41-43, wherein the real-time status data includes the speed data of the vehicle, and to determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data, the risk determination module is further configured to:

determine whether the speed data exceeds a first speed range; and

in response to determining that the speed data exceeds the first speed range, determine that the vehicle is in the abnormal driving condition in the driving process.
The system of claim 42 or claim 43, wherein to determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data, the risk determination module is further configured to:

obtain a first piece of speed data of the vehicle collected by the sensor;

determine a first condition identification result based on the first piece of speed data;

obtaining a second piece of speed data of the vehicle collected by the user terminal;

determine a second condition identification result based on the second piece of speed data; and

determine whether the vehicle is in the abnormal driving condition based on the first condition identification result and second condition identification result.
The system of any one of claims 39-43, wherein to determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data, the risk determination module is further configured to:

determine whether the vehicle is in the abnormal driving condition in the driving process using a driving condition identification model based on the real-time status data.
The system of any one of claims 39-46, wherein the risk information includes at least one of whether the vehicle is at risk in the driving process, a type of the risk, or a level of the risk.
The system of any one of claims 39-47, wherein to determine whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data, the risk determination module is further configured to:

extract feature information of the real-time status data; and

determine whether the vehicle is in an abnormal driving condition in the driving process based on the feature information.
The system of any one of claims 39-48, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and to determine risk information associated with the vehicle in the driving process based on the determination result, the risk determination module is further configured to:

determine whether a variation of the speed data of the vehicle with time satisfies a first condition; and

in response to determining that the variation satisfies the first condition, determine that the vehicle is at no risk.
The system of any one of claims 39-48, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and to determine risk information associated with the vehicle in the driving process based on the determination result, the risk determination module is further configured to:

determining whether the speed data of the vehicle exceeds a second speed range; and

in response to determining that the speed data of the vehicle exceeds the second speed range,

determining a duration time in which the speed data of the vehicle exceeds the second speed range;

determining whether the duration time exceeds a time threshold; and

in response to determining that the duration time exceeds the time threshold, determining that the vehicle is at risk.
The system of any one of claims 39-48, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and to determine risk information associated with the vehicle in the driving process based on the determination result, the risk determination module is further configured to:

obtain, based on the real-time status data, vehicle posture data after the speed data of the vehicle exceeds a third speed range; and

in response to determining that the vehicle posture data satisfies a second condition, determine that the vehicle is at risk.
The system of any one of claims 47-51, wherein the risk includes a rollover of the vehicle or a collision of the vehicle in the driving process.
The system of any one of claims 41-48, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and to determine risk information associated with the vehicle in the driving process based on the determination result, the risk determination module is further configured to:

obtain, based on the real-time status data, the location data of the vehicle;

determine, based on the location data of the vehicle, a driving trajectory of the vehicle after the speed data of the vehicle exceeds a fourth speed range; and

determine, based on the driving trajectory, the risk information associated with the vehicle.
The system of any one of claims 39-48, wherein the determination result indicates that the vehicle is in the abnormal driving condition in the driving process, and to determine risk information associated with the vehicle in the driving process based on the determination result, the risk determination module is further configured to:

obtain, based on the real-time status data, data associated with a user behavior after the speed data of the vehicle exceeds a fifth speed range; and

determine, based on the data associated with the user behavior, the risk information associated with the vehicle.
The system of claim 54, wherein the data associated with the user behavior includes at least one operation of the user in an application of a service platform.
The system of any one of claims 39-55, further comprising a risk response module, wherein the risk response module is configured to:

perform at least one risk response operation based on the risk information.
A system configured to identify a driving condition of a vehicle, comprising:

a data obtaining module configured to obtain real-time status data in a driving process of the vehicle; and

a risk determination module configured to determine risk information associated with the vehicle in the driving process using a driving condition identification model based on the real-time status data.
A device for identifying a driving condition of a vehicle, comprising:

at least one storage device configured to store a set of instructions; and

at least one processor configured to execute the set of instructions and perform a method for identifying the driving condition of the vehicle, the method including:

obtaining real-time status data in a driving process of the vehicle;

determining whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data to obtain a

determination result; and

determining risk information associated with the vehicle in the driving process based on the determination result.
A device for identifying a driving condition of a vehicle, comprising:

at least one storage device configured to store a set of instructions; and

at least one processor configured to execute the set of instructions and perform a method for identifying the driving condition of the vehicle, the method including:

obtaining real-time status data in a driving process of the vehicle; and

determining risk information associated with the vehicle in the driving process using a driving condition identification model based on the real-time status data.
A non-transitory computer readable medium, comprising at least one set of instructions for identifying a driving condition of a vehicle, wherein when executed by one or more processors of a computing device, the at least one set of instructions causes the computing device to perform a method, the method comprising:

obtaining real-time status data in a driving process of the vehicle;

determining whether the vehicle is in an abnormal driving condition in the driving process based on the real-time status data to obtain a determination result; and

determining risk information associated with the vehicle in the driving process based on the determination result.
A non-transitory computer readable medium, comprising at least one set of instructions for identifying a driving condition of a vehicle, wherein when executed by one or more processors of a computing device, the at least one set of instructions causes the computing device to perform a method, the method comprising:

obtaining real-time status data in a driving process of the vehicle; and

determining risk information associated with the vehicle in the driving process using a driving condition identification model based on the real-time status data.