Message Push Method, Computer Program, and Server

Abstract

The present application provides a message push method, a storage medium, and a server, belonging to the field of Internet of Vehicles. The method includes the steps of acquiring basic data related to a target vehicle, the basic data including at least vehicle user data and driving environment data; recognizing a scene in which the target vehicle is currently located based on the acquired basic data; determining at least one service currently required by the target vehicle based on the obtained scene recognition result; generating a service message for the at least one service; and pushing the generated service message to the target vehicle. The present application realizes active scene recognition, and based on the scene recognition result, actively determines services that the user may need at the current time and space, and actively pushes corresponding service messages to the vehicle. Since the user can receive the required services without performing any additional operations, the method significantly improves driving safety in an in-vehicle environment and effectively meets the service needs of users in an in-vehicle environment.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims priority based on a Chinese patent application filed on July 2, 2019, with the application number 201910589563.1 and the invention title "Message Push Method, Apparatus, Storage Medium and Server", and the entire content of the Chinese patent application is incorporated herein by reference.

[0002] This application relates to the field of the Internet of Vehicles (IoV), and particularly to a message push method, a storage medium and a server.

Background Art

[0003] As a combination of the Internet of Things and the Internet, the Internet of Vehicles is currently an important component in the field of vehicle driving. In short, the Internet of Vehicles is a huge network that, based on a network, conducts wireless communication and information exchange between vehicles and all kinds of things (such as vehicle - to - vehicle, vehicle - to - road, vehicle - to - human, or vehicle - to - network, etc.) according to agreed - upon communication protocols and data exchange standards. Here, according to the Internet of Vehicles, intelligent traffic management, dynamic message service provision, and intelligent vehicle control can be realized.

[0004] In related technologies, the Internet of Vehicles platform provides users with services in the form of messages. Also, users need to wake up through manual operations or voice commands in the vehicle environment. However, such a service acquisition method in the vehicle environment will surely affect the safety of users' driving. Therefore, considering the safety of vehicle driving and the continuous improvement of users' needs in the in - vehicle environment, how to push messages to users in the vehicle environment has become an issue for those skilled in the art to solve.

Summary of the Invention

Problems to be Solved by the Invention

[0005] Embodiments of the present application provide a message push method, a storage medium, and a server that can improve the safety of vehicle driving in an in-vehicle environment, meet the service requirements of users in the in-vehicle environment, and have better effects. The technical solutions are as follows.

Means for Solving the Problem

[0006] According to one aspect, a message push method applied to a server is provided. The method includes: acquiring basic data related to a target vehicle, where the basic data includes at least vehicle user data and driving environment data; recognizing the scene where the target vehicle is currently located based on the acquired basic data; determining at least one service currently required by the target vehicle based on the obtained scene recognition result, and generating a service message for the at least one service; and pushing the generated service message to the target vehicle.

[0007] In a possible implementation, the step of distributing the acquired basic data to different scene engines (also referred to as scenario engines) includes: performing preprocessing on the acquired basic data; and distributing the preprocessed basic data to different scene engines.

[0008] According to another aspect, a message push device applied to a server is provided. The device includes: an acquisition module configured to acquire basic data related to a target vehicle, where the basic data includes at least vehicle user data and driving environment data; A recognition module configured to perform recognition on the scene where the target vehicle is currently located based on the obtained basic data; A generation module configured to determine at least one service currently required by the target vehicle based on the obtained scene recognition result and generate a service message for the at least one service; And a transmission module configured to push the generated service message to the target vehicle.

[0009] In a possible implementation form, the generation module is configured to execute the steps of: determining the at least one service based on the obtained scene recognition result, where the service types of each service among the at least one service are different; and generating a service card that matches each service, where one service card includes a service message of one service.

[0010] In a possible implementation form, the transmission module is configured to select at least two service cards of different service types from the generated service cards according to a priority rule, push the selected service cards to the target vehicle, push the service card with the highest demand degree in the current scene to the target vehicle, and push the generated service cards to the target vehicle in order at a target frequency interval according to the priority rule, where the priority rule is that the higher the demand degree of the service card in the current scene, the higher its priority.

[0011] In a possible implementation form, the recognition module is configured to execute the step of calling a functional module of the public service layer and performing recognition on the scene where the target vehicle is currently located based on the obtained basic data.

[0012] In a possible implementation form, the recognition module inputs the acquired basic data into the machine learning model of the model service module, and based on the machine learning model, recognizes the scene where the target vehicle is currently located; detects whether the acquired basic data meets a predetermined rule based on the rule setting module, and based on the obtained detection result, recognizes the scene where the target vehicle is currently located; recognizes the scene where the target vehicle is currently located based on the acquired basic data and the profile that matches the basic data, where the profile is constructed based on the historical basic data related to the target vehicle; and calls the content service module to obtain specified basic data that matches the current time and space based on the acquired basic data, and based on the specified basic data, recognizes the scene where the target vehicle is currently located.

[0013] In a possible implementation form, the recognition module further distributes the acquired basic data to different scene engines for scene recognition, where the basic data received by each scene engine matches the pre-subscribed data type; and uses the scene recognized by each scene engine as the scene recognition result.

[0014] In a possible implementation form, the recognition module checks the distributed basic data for each scene engine. After the check is completed, it creates a plurality of threads, and the plurality of threads call the function modules of the public service layer to perform recognition on the scene where the target vehicle is currently located based on the distributed basic data.

[0015] In a possible implementation form, the generation module determines at least one scene having a current service demand from the scenes recognized by each scene engine, and based on the correspondence between the scene and the service, determines a service that matches the at least one scene, and is configured to determine the service that matches the at least one scene as the at least one service.

[0016] In a possible implementation form, the recognition module is further configured to perform preprocessing on the acquired basic data and distribute the preprocessed basic data to different scene engines.

[0017] In a possible implementation form, the sending module further includes steps of generating a target service message from service messages generated by at least two scene engines according to a priority rule, and pushing the target service message to the target vehicle, where the target service message is the service message with the highest demand degree in the current scene, and pushing the service messages generated by the at least two scene engines to the target vehicle in sequence at a target frequency interval according to the priority rule, and pushing some of the service messages generated by the at least two scene engines to the target vehicle in sequence at the target frequency interval according to the priority rule, and responding to the case where the number of service messages generated by one of the scene engines is at least two, and pushing the at least two service messages to the target vehicle at the target frequency interval, and is configured to execute, the priority rule is such that the higher the demand degree of the service message in the current scene, the higher its priority.

[0018] In a possible implementation form, the obtaining module is further configured to obtain a message display template that matches the generated service message. The sending module is further configured to send the message display template to the target vehicle. The message display template is for instructing the target vehicle to display the received service message according to the message display template.

[0019] In a possible implementation form, the vehicle user data includes vehicle data and user data. The vehicle data includes at least vehicle state data and trajectory data. The user data includes at least user behavior data, user preference data, and resource label data of the user on the vehicle side. The driving environment data includes at least road condition data, weather environment data, Point of Interest (POI) data, and infrastructure data.

[0020] In a possible implementation form, the profiles that match the basic data include user profiles, vehicle profiles, environment profiles, and content profiles. Here, the environment profile is constructed based on historical weather environment data and is updated by the real-time obtained weather environment data. The vehicle profile is constructed based on historical vehicle state data and is updated by the real-time obtained vehicle state data. The user profile is constructed based on historical user behavior data and historical user preference data and is updated by the real-time obtained user behavior data and user preference data. The content profile is constructed based on historical resource label data and is updated by the real-time obtained resource label data.

[0021] According to another aspect, a storage medium is provided. At least one instruction is stored in the storage medium, and when the at least one instruction is loaded and executed by a processor, the processor is caused to implement the above message push method.

[0022] According to another aspect, a server is provided. The server includes a processor and a memory. The memory stores at least one instruction, and the processor loads and executes the at least one instruction to obtain basic data related to the target vehicle, where the basic data includes at least vehicle user data and driving environment data, perform recognition on the scene where the target vehicle is currently located based on the obtained basic data, determine at least one service currently required by the target vehicle based on the obtained scene recognition result, and generate a service message for the at least one service, and push the generated service message to the target vehicle.

Advantages of the Invention

[0023] The beneficial effects of the technical solution provided by the embodiments of the present application are as follows. In an embodiment of the present application, the server actively acquires basic data related to a vehicle, and based on the acquired basic data, actively recognizes the scene where the target vehicle is currently located. Here, the basic data includes at least vehicle user data and driving environment data. Based on the obtained scene recognition result, after determining at least one service currently required by the target vehicle, the server automatically generates a service message for the at least one service and actively pushes the generated service message to the vehicle. The embodiment of the present application can realize active recognition of a scene, actively determine a service that a user may need at the current time and space based on the scene recognition result, and actively push a corresponding service message to the vehicle side. Without the user performing a separate operation, the user can receive the required service, which greatly improves the driving safety in the in-vehicle environment, meets the service requirements of the user in the in-vehicle environment, and has high effectiveness.

Brief Description of the Drawings

[0024]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Embodiments for Carrying Out the Invention

[0025] In order to more clearly explain the technical solutions in the embodiments of the present application, the drawings necessary for the description of the embodiments will be briefly described below. Of course, the following drawings are only some embodiments of the present application, and those skilled in the art can also obtain other drawings based on these drawings without creative efforts. In order to make the objectives, technical solutions and advantages of the present application more clear, the embodiments of the present application will be described in more detail below with reference to the drawings.

[0026] The terms "first", "second", etc. used in the present application are for explaining various concepts in this specification. However, unless otherwise explicitly stated, these concepts are not limited to these terms. These terms are only for distinguishing one concept from another. Here, at least one refers to one or more. For example, at least one service card may be one service card, two service cards, three service cards, or any integer number of service cards greater than or equal to 1. At least two refers to two or more. For example, at least two service cards may be two service cards, three service cards, or any integer number of service cards greater than or equal to 2. The term "plurality" refers to two or more. For example, a plurality of service cards may be any integer number of two or more service cards, such as two service cards, three service cards, and so on.

[0027] Before elaborating on the embodiments of the present application in detail, first, some terms related to the embodiments of the present application will be explained. Scene: In the Internet environment of a vehicle, a scene is for describing the time, space, in-vehicle environment, out-of-vehicle environment, vehicle body state, and current behavior where the user is located, etc.

[0028] As an example, in an in-vehicle environment, through real-time data collection, scenes such as "commuting, fatigue, suitable for vehicle washing, or a highway at night" can be automatically recognized, and further, based on the scene recognition result, the currently required services can be actively pushed to the user.

[0029] Profile: A tool for effectively depicting a person or an object. By abstracting the specific information of a person or an object, a profile for describing the person or the object is formed. In a possible implementation form, for the Internet scene of a vehicle, the profile may be not only for the user, but also a result with a tendency or statistical meaning formed after mining multi-dimensional historical data such as the user, the vehicle, the environment (weather), and resource tags. That is to say, the profile may be constructed after mining the historical data. In addition, the constructed profile may be updated with respect to the data collected in real time. The embodiments of the present application do not specifically limit this. As an example, the profile constructed in the embodiments of the present application generally performs initial abstraction on the historical data to learn features, quickly makes calls in subsequent scene recognition processes, and is for assisting scene sensing.

[0030] Hereinafter, the implementation environment related to the message push method provided by the embodiments of the present application will be described. Referring to FIG. 1, the implementation environment includes a vehicle 101 and a server 102. Here, the server 102 may also be referred to as a vehicle Internet platform or a backend server in this specification. The server 102 and the vehicle 101 can communicate via a mobile network or via a wireless network, and the embodiments of the present application do not specifically limit this.

[0031] In a possible implementation form, a compatible application software client is installed on the in-vehicle multimedia terminal of the vehicle 101, and the vehicle 101 communicates with the vehicle Internet platform via the application software client. The embodiments of the present application do not specifically limit this.

[0032] In the vehicle Internet scenario, the related technology can currently only provide a single scene recognition service and can only perform scene recognition on the vehicle side. That is, scene sensing is performed based on the corresponding application software client on the vehicle side. This severely restricts the expandability of the scene, and the service is too single. Also, the application software client affects the output of service capabilities during the service upgrade process. In addition, during the driving process, the user is required to have concentration and consistency. As a result, the user may not be able to perform other operations to obtain other in-vehicle needs in the in-vehicle environment. Or, even if other operations can be performed, in order to obtain other in-vehicle needs, it is also necessary to perform troublesome operation steps. For example, the user needs to manually perform multiple-step operations or wake up by voice commands in the in-vehicle environment. Thus, when performing driving and other in-vehicle needs in parallel, there are many problems such as the operation steps being too long, affecting driving safety, and the information not arriving in time.

[0033] In view of the above problems existing in the related art, in the embodiments of the present application, in the manner of making the service online, based on the overall data of humans, vehicles, roads, the environment, etc. collected, the server 102 closely combines the understanding of the user's needs and the understanding of the scene and space with the vehicle. It can accurately and actively recognize the virtual vehicle scene in real time and actively push the customized service to the vehicle 101. For example, through the dynamic container technology of the application software client in the vehicle 101, the customized service in the form of a message is displayed.

[0034] Here, the embodiments of the present application not only make the service online, that is, perform scene sensing by the server 102, but also actively perform scene recognition based on the data collected in real time and push the corresponding service. In addition, the scene scalability of the server 102 is higher. With various scene engines, not only can various scene sensing services be provided, but the existing engine capabilities can be enriched or enhanced, or new scene engines can be added without affecting the existing scene engines. That is, by providing a multi-dimensional combinable refined long-tail scene service, a perfect in-vehicle ecosystem can be constructed. Here, the long-tail service is from the long-tail theory.

[0035] As another expression method, the embodiment of the present application performs real-time scene recognition based on the overall data of humans, vehicles, roads, environments, etc. collected, and combines the dynamic container technology of the application software client, the algorithm service of the real-time data model analysis of the server 102, and the interaction framework technology shown in FIG. 2, so as to make the scene scalability of the server 102 higher. Without affecting the existing scene engine, the existing engine capabilities are enriched and strengthened, or a new scene engine is added. Here, the interaction framework technology may be the spring-boot-TAF scene engine framework technology, and the embodiment of the present application does not specifically limit this. In addition, by making the algorithm service online, it is easier for the algorithm service to act on the process. The automatic upgrade of the algorithm service does not affect the ability output of the scene sensing service. That is, the scene sensing function provided by the server 102 will not be interrupted by the automatic upgrade of the algorithm service.

[0036] As shown in FIG. 2, the server 102 mainly includes the following. The data access layer 1021 is configured to shield the diversity of each upper-layer data source and perform batch preprocessing on the data collected from various routes. Here, the preprocessing includes, but is not limited to, data check processing. In addition, batch packaging processing is performed on different data from multiple data sources. For example, packaging is performed into a consistent data format. For example, packaging is performed into a consistent Event (event) message body. The embodiment of the present application does not specifically limit this. The scene engine 1022 is a core component for connecting upper and lower layers or modules.

[0037] In the embodiments of the present application, the scene engine 1022 may include a large number of scene engines. Different scene engines can perform different scene sensing. Also, new scene engines can be continuously newly added or extended to the scene engine 1022. That is, the embodiments of the present application provide diverse scene engine capabilities. Each scene engine can subscribe to and analyze data of interest from the data access layer 1021 based on its own data analysis characteristics. As another expression method, the data access layer 1021 can distribute and analyze pre-processed data to different scene engines according to the data types subscribed by each scene engine, and complete scene sensing. That is, the pre-processed data received by each scene engine matches the pre-subscribed data types.

[0038] The common service layer 1023 is a single layer. It provides basic service capabilities to all scene engines through common algorithms. That is, the scene engine 1022 completes scene sensing with the help of the common service layer 1023. Here, as shown in FIG. 2, the common service layer 1023 includes various function modules for assisting scene recognition. For example, it includes a rule setting module, a model service module, a profile, a content service module, etc. As an example, the content service module refers to a weather service or a road condition service, etc. The embodiments of the present application do not specifically limit this.

[0039] Here, the rule setting module is for providing lightweight pre-rule implementation. For example, based on pre-set thresholds, it determines whether a vehicle is speeding. The model service module is generally an Artificial Intelligence (AI) model and is used for sensing complex scenes. For example, in a navigation scene, it predicts the next route, etc. That is, the model service module is used to perform model analysis on the input basic data by means of an AI algorithm. This mainly performs further mining on the data based on historical features.

[0040] The arbitration module 1024 is used to perform arbitration on the service messages generated after the scene engine 1022 completes scene recognition. For example, it is used for performing wired degree control or traffic control, etc. For example, when it is necessary to push service messages generated in various scenes to the vehicle 101, the arbitration module 1024 mainly controls the delivery priority of various service messages and the delivery frequency of a single type of service message.

[0041] Exemplarily, the embodiments of the present application provide an integrated and extensible message structure to the application software client in each vehicle based on a general-purpose message protocol. That is, by using a predetermined message structure format, it is ensured that the application software client can recognize the service messages pushed from the server 102 in any case, and there is no need to make any changes to the application software client. This ensures that scene recognition has high extensibility, avoids frequent upgrades due to the inability of the application software client to analyze newly added service message types, and can dynamically provide the latest scene services at the lowest cost.

[0042] In short, the embodiments of the present application can actively determine the services that a user may need at the current time or location through active recognition of real-time scenes, and actively push them to the user. Therefore, it can greatly improve the driving safety and user comfort, improve the sensing possibility of long-tail services, and provide users with a richer driving experience. Specifically, based on the above interaction framework, at least the following can be realized in the vehicle Internet scene.

[0043] 1. Complete scene recognition based on server-side data analysis and prediction. That is, the embodiments of the present application can complete scene recognition by the server side, provide strong scene sensing capabilities, and provide various services. 2. Have strong scene expansion capabilities. As the services become richer, the server side can provide more scene engines while maintaining the current architecture as it is. That is, the interaction framework provided by the embodiments of the present application can quickly realize the expansion of scene engines without affecting the ability output of other scene engines. 3. Have rapid adaptation capabilities for multi-tenants. Without performing version iterations, it can meet the needs of various vehicle scenes with the same service capabilities in an allocation manner. That is, the embodiments of the present application are adaptable to vehicle scenes with different needs and applicable to vehicle scenes with different needs. 4. Make accurate recommendations based on real-time scene recognition. By performing scene sensing in real time by the scene engine, an accurate push service can be actively provided.

[0044] Hereinafter, the message push method provided by the embodiments of the present application will be described in detail. It should be noted that terms such as the following first, second, third, fourth, etc. are only for distinguishing different objects and do not limit the present application in any way. Figure 3 is a flowchart showing the message push method according to an embodiment of the present application. The interaction entities of the method are the vehicle and the server shown in Figure 1. As shown in Figure 3, the process of the method provided in the embodiment of the present application includes the following. In 301, the server acquires basic data related to the target vehicle, and the basic data includes at least vehicle user data and driving environment data. Here, the target vehicle generally refers to any vehicle that accesses the Internet of vehicles in this specification.

[0045] This step is a data collection step. The embodiment of the present application establishes a dual-path data collection mechanism on the vehicle side and the server side. That is, the server can know some data changes in real time through a plurality of message contacts set on the vehicle side. That is, the server can collect data from the vehicle. Conversely, after the server completes scene sensing, it can also actively push some services to the vehicle. These services are generally pushed to the vehicle in the form of messages. Therefore, in this specification, they are also called service messages.

[0046] In the embodiment of the present application, the server can collect data through various routes. The collected data may be roughly divided into trajectory data, event tracking data, and other data shown in Figure 4. The embodiment of the present application does not specifically limit this.

[0047] In a possible implementation form, the server acquires basic data related to the target vehicle. The basic data includes at least two types of data, such as vehicle user data and driving environment data, but is not limited thereto.

[0048] For example, as shown in Figure 5, the server can acquire the following data. 1. Data that strongly depends on the vehicle side, such as user behavior data and vehicle state data. Here, the user behavior data may include user behaviors such as opening an application, swiping to the next screen, and closing a message notification. Exemplarily, the above application refers to an in-vehicle application. As an example, the vehicle state data may be divided into 15 categories such as vehicle body state, driving data, energy / mode, panoramic photography, air conditioner, air quality, transmission case, door lock, wiper, lamp, seat belt, charger, tire, meter, and maintenance inspection. The embodiments of the present application do not specifically limit this. Here, such data that strongly depends on the vehicle may be provided to the profile mining module and the scene engine on the server side in two modes: event tracking report or long connection real-time report.

[0049] 2. Highly real-time data such as weather environment data and dynamic road condition data. The weather environment data may include real-time temperature, wind force, precipitation, etc. based on the standard weather region. The embodiments of the present application do not specifically limit this. The dynamic road condition data may include data such as dynamic traffic congestion status, travel time, traffic accidents, puddle points, and electronic eye cameras based on the topological road. The embodiments of the present application do not specifically limit this either. Here, such highly real-time data is provided to the profile mining module and the scene engine on the server side in a service form.

[0050] 3. Static data that depends on collaboration with the outside, such as user preference data and resource tag data. Here, the above user preference data may be referred to as user mobile client preference data in this specification. That is, mainly collect the user's preference data on the mobile client. The user mobile client preference data may include age, education level, music style preference, star preference, news preference, consumption level, brand preference, etc., and the embodiments of the present application do not specifically limit this. Here, the resource label data may be further divided into content label data and applet label data. Here, the content label data generally refers to listening data and may include the length of a song, the singer, style tags, the album name, the author of a book, and the like. The applet label data may include the mini-program developer, service type, popularity, and the like. The embodiments of the present application do not specifically limit this.

[0051] In a possible implementation form, such static data may be directly constructed from the profile layer. That is, in the profile layer, docking can be performed and interactions can be carried out in the profile layer. For example, from other routes, the above-mentioned static data related to the user can be directly obtained. The embodiments of the present application do not specifically limit this.

[0052] 4. It is also possible to obtain the trajectory data, POI data, and infrastructure data of the target vehicle. Here, the trajectory data belongs to the flow data and is obtained through a dedicated route. The POI data and infrastructure data are obtained in a service format. The above-mentioned road condition data, weather environment data, POI data, and infrastructure data all belong to the driving environment data.

[0053] Here, in a geographic information system, one POI may be one building, one store, one postal post, or one bus terminal, etc. The full name of the infrastructure is infrastructure and may refer to one grassland or one dam.

[0054] The first point that needs to be explained is that since the above-mentioned user behavior data, user preference data, and resource label data are all related to the user, they may be collectively referred to as user data of the target user in this specification. Here, the target user is the user located inside the target vehicle. The above-mentioned vehicle state data and trajectory data may be collectively referred to as vehicle data of the target vehicle in this specification.

[0055] The second point that needs to be explained is that in addition to providing various basic data obtained in real time to the scene engine on the server side for real-time data analysis to complete scene sensing, it is also used to perform real-time updates on the profiles constructed and provided to the profile mining module on the server side. The embodiments of the present application do not specifically limit this.

[0056] In a possible implementation form, the collection of data is associated with the construction of the profile. By performing precipitation and mining on the collected historical basic data (offline data), a profile can be constructed. The basic data collected in real time can also be used to perform mining and updating on the profile again. When the scene engine performs scene sensing in real time, the constructed profile can assist in scene recognition.

[0057] The third point that needs to be explained is that in a possible implementation form, since the fluctuations of the above-mentioned static data are generally small, it is not necessary to obtain it each time. For example, after obtaining it once, it may not be necessary to obtain it subsequently, or it may be obtained once after a long time. The embodiments of the present application do not specifically limit this.

[0058] Hereinafter, profile mining will be described. As shown in FIG. 6, in a possible implementation form, the embodiments of the present application can construct a profile tag library according to four dimensions, namely, user, vehicle, environment (especially referring to weather), and content. That is, the constructed profile includes a user profile, a vehicle profile, an environment profile, and a content profile.

[0059] As an example, referring to FIG. 6, the user profile may be divided into four categories: biometric account, basic information, driving behavior, and application operations. Here, the biometric account includes, but is not limited to, user account information used by the user to log in to various applications. The basic information includes, but is not limited to, age, occupation, education level, gender, region, etc. The application operations include, but are not limited to, various operations executed by the user on the screen provided by the application. The embodiments of the present application do not specifically limit this.

[0060] Vehicle profile: Exemplarily, based on the 15 data collection categories of the above vehicle state data, four profiles can be obtained: basic information, driving preference, usage status, and maintenance. Here, the basic information here refers to the basic information of the vehicle and includes, but is not limited to, vehicle body condition, tires, door locks, etc.

[0061] Environmental profile: Exemplarily, based on the real-time weather data query results, three environmental profiles can be obtained: short-term regional weather prediction, year-on-year regional weather, and dangerous intervals due to historical environmental changes.

[0062] The content profile may be divided into four categories: basic attributes, scene attributes, style, and new hits, for example. Here, the basic attributes include, but are not limited to, the singer of the song, the length of the song, the album name, the author of the book, etc. The style may refer to the style of the song. The new hits may refer to the popularity of the mini-program, the popularity of the song, or the popularity of the book. The scene attributes may refer to the scene suitable for the song. The embodiments of the present application do not specifically limit this.

[0063] The fourth point that needs to be explained is that among all the acquired basic data, not all the basic data is necessarily used for profile mining. For example, there is no profile for the basic data provided in the service form.

[0064] In addition, in the embodiments of the present application, each profile mined in the in-vehicle environment may be fused with the user's tag profile in the mobile client. For example, the content profile in the in-vehicle environment and the user's content profile in the mobile client may be fused to more completely describe the user. For example, it is known that the user prefers heavy metal music in the in-vehicle environment and light music in the mobile client scene, and different services are provided for users located in different scenes is realized.

[0065] In a possible implementation form, as can be seen from the above, it may be constructed based on historical weather environment data and updated by real-time acquired weather environment data. The vehicle profile may be constructed based on historical vehicle state data and updated by real-time acquired vehicle state data. The user profile may be constructed based on historical user behavior data and historical user preference data and updated by real-time acquired user behavior data and user preference data. The content profile may be constructed based on historical resource label data and updated by real-time acquired resource label data. In 302, the server recognizes the scene where the target vehicle is currently located based on the acquired basic data.

[0066] In a possible implementation form, as shown in FIG. 2, the scene engine in the server calls the function module of the public service layer to recognize the scene where the target vehicle is currently located.

[0067] In 303, the server determines at least one service currently required by the target vehicle based on the obtained scene recognition result and generates a service message for the at least one service.

[0068] In a possible implementation, the services provided in the embodiments of the present application include, but are not limited to, basic services and value-added services. Here, the basic services include, but are not limited to, navigation services. The value-added services may also be referred to as content services or care services, and include, but are not limited to, weather services, listening services, etc. The embodiments of the present application do not specifically limit this.

[0069] In a possible implementation, as shown in FIG. 7, the embodiments of the present application push the generated service message in the form of a service card. Here, the service card is generated on the server side, and subsequently, the server can push the generated service card to the vehicle side for display. Also, on the vehicle side, a service card can be generated after receiving the service message pushed from the server. The embodiments of the present application do not specifically limit this.

[0070] As an example, based on the obtained scene recognition result, the step of determining at least one service currently required by the target vehicle and generating a service message for the at least one service includes, based on the obtained scene recognition result, determining at least one service currently required by the target vehicle, and based on the service type, generating a service card that matches each service. Here, one service card includes a service message for one service. In other words, the server generates a service card that matches each service.

[0071] As an example, the service types of each of the at least one service are generally different. Taking the example that the at least one service includes a weather service, a listening service, and a navigation service, a weather card corresponding to the weather service, a listening card corresponding to the listening service, and a navigation card corresponding to the navigation service can be generated. That is, three service cards with different service types are generated. In 304, the server pushes the generated service message to the target vehicle.

[0072] As an example, the server uses an integrated extensible message structure to push the message to the vehicle side. That is, by using a predetermined message structure format, it is ensured that the application software client on the vehicle side can recognize the pushed service message in any case, and there is no need to make any changes to the application software client. That is, for newly extended scene services, frequent upgrades of the application software client due to the inability of the application software client to analyze newly added service message types are avoided, and the latest scene services can be dynamically provided at the lowest cost.

[0073] In a possible implementation form, the step of the server pushing the generated service message to the target vehicle includes, but is not limited to, any one of the following.

[0074] In step A, according to the priority rule, at least two service cards of different service types are selected from the generated service cards, and the selected service cards are pushed to the target vehicle.

[0075] Regarding this step, generally, different scenes correspond to different service demands. In one scene, a user may need multiple services simultaneously. Therefore, multiple service cards for different service types can be pushed to the user on the vehicle side to achieve service diversification. Note that if the number of generated service cards is too large, in order to avoid overly disturbing the user, considering the size of the display of the in-vehicle terminal, multiple service cards of different service types can be selected from the generated service cards according to the priority rule and pushed to the user on the vehicle side. If the number of service cards is less than a predetermined threshold, all the generated service cards can be pushed to the user on the vehicle side at once to serve the user on the vehicle side in a diverse manner. The embodiments of the present application do not specifically limit this.

[0076] Exemplarily, the priority rule may be such that the higher the demand for the service card in the current scene, the higher its priority. As an example, the demand may be preset, and the embodiments of the present application do not specifically limit this.

[0077] As an example, taking the scene of cloudy + fatigue + highway as an example, based on the scene where the user on the vehicle side is currently located, the server may determine that the services currently needed by the user on the vehicle side are weather service, listening service, and navigation service. To enable the user to obtain diverse services, the server can push three service cards of different service types to the user on the vehicle side. These service cards include a weather card that outputs weather messages, a listening card that outputs listening messages, and a navigation card that outputs navigation messages. Further, the vehicle side outputs these three service cards simultaneously for the user on the vehicle side to view. In step B, the service card with the highest demand in the current scene is pushed to the target vehicle.

[0078] In addition to the method of pushing multiple service cards, it is also possible to push the service card with the highest current demand to the user on the vehicle side. The embodiments of the present application do not specifically limit this. For example, when the current user is in a fatigue scene, what the current vehicle side most needs may not be the weather service but the audio listening service. Therefore, in the current scene, the listening card is selected and pushed to the user on the vehicle side. In step C, according to the priority rule, the generated service cards are pushed to the target vehicle in order at the target frequency interval.

[0079] As another example, in order to ensure that the user on the vehicle side can obtain various services while not overly disturbing the user on the vehicle side, the service cards can also be pushed to the user on the vehicle side in order according to the set priority. The embodiments of the present application do not specifically limit this either. In step 305, the target vehicle displays the acquired service message.

[0080] As an example, as shown in FIG. 7, the service message may be presented to the user on the vehicle side in the form of a service card. The embodiments of the present application do not specifically limit this. As an example, the service card may have the following functional characteristics on the vehicle side.

[0081] The service card may be presented by an application software client on the vehicle side. Note that the content of the service card can be replaced. For example, it supports the replacement of some elements or global elements. Here, the above elements may include buttons containing hyperlinks. Note that the service card has an erasure feature. That is, when the service card is removed, it has an erasure video effect. Here, after one service card is erased, the remaining subsequent service cards generally default to advancing one before. Note that dynamic ordering can be performed on the service card. For example, it supports the order adjustment of the service card and has the corresponding video effect. Note that it supports manually removing the service card. For example, the service card can be removed by a gesture operation (e.g., a swipe up) (generally, the weather service card is the bottom card and cannot be removed). Note that it supports manually adding the service card. Note that within the service card, swiping is supported. For example, a waterfall flow can be seen by swiping. Note that the dimensions of the service card may conform to the dimensions of the screen. Note that within the service card, the presentation of various interface elements is supported. That is, the service card can present rich interface elements and present video effects with a good visual experience.

[0082] In the embodiments of the present application, the server actively acquires basic data related to a vehicle, and based on the acquired basic data, actively recognizes the scene where the target vehicle is currently located. Here, the basic data includes at least vehicle user data and driving environment data. The server determines at least one service currently required by the target vehicle based on the obtained scene recognition result, then automatically generates a service message for the at least one service, and actively pushes the generated service message to the vehicle. The embodiments of the present application can realize active recognition of a scene, actively determine services that a user may need in the current time and space based on the scene recognition result, and actively push corresponding service messages to the vehicle side. Since the user can receive the required services without performing separate operations, the driving safety in the in-vehicle environment is greatly improved, the service requirements of the user in the in-vehicle environment are met, and the effect is high.

[0083] FIG. 8 is a flowchart showing a message push method according to an embodiment of the present application. The interaction entities of the method are the vehicle and the server shown in FIG. 1. As shown in FIG. 8, the process of the method provided in the embodiments of the present application includes the following. In 801, the server acquires basic data related to the target vehicle. This step is the same as step 301 above.

[0084] In 802, the server performs preprocessing on the acquired basic data, and distributes the preprocessed basic data to different scene engines based on the data types subscribed by each scene engine.

[0085] This step distributes the preprocessed basic data to different scene engines of the server. Here, the basic data acquired by each scene engine conforms to the data types subscribed in advance.

[0086] In the embodiments of the present application, the preprocessing of data is executed by the data access layer. Here, as shown in FIG. 4, after the data access layer performs batch data access on the basic data from multiple data sources, the data access layer first performs data check processing on the obtained basic data.

[0087] After the data check processing, in order to shield the diversity of data sources, events are packaged in batches and packaged into an integrated Event message body. That is, the event uniform encapsulation step is responsible for performing data packaging processing based on the above-mentioned checked basic data to obtain basic data with an integrated data format.

[0088] In a possible implementation form, all data interactions according to the embodiments of the present application all use an asynchronous method. That is, since data is interacted in the form of asynchronous messages, the synchronization of asynchronous messages can be performed before registering with the registration center. The embodiments of the present application do not specifically limit this.

[0089] As an example, the registration center may be an Mq (producer-consumer mode) proxy. As shown in FIG. 4, the data access layer on the data supply side registers with the Mq proxy. Each scene engine as a subscriber can subscribe to and analyze the data of interest from the data access layer through the Mq proxy.

[0090] It should be noted that the scene engines A to D shown in FIG. 4 do not limit the number of scene engines. In fact, more scene engines may be included.

[0091] In 803, for each scene engine, a function module of the public service layer is called to execute the step of recognizing the scene where the target vehicle is currently located based on the distributed basic data, and the scene recognized by each scene engine is used as the obtained scene recognition result.

[0092] In a possible implementation form, as shown in FIG. 9, the functional modules included in the common service layer include, but are not limited to, a model service module, a profile, a rule setting module, and a content service module.

[0093] As an example, the step of calling the functional module of the public service layer to perform recognition on the scene where the target vehicle is currently located based on the distributed basic data includes at least one of the following.

[0094] At 8031, input the distributed basic data into the machine learning model of the model service module, and based on the machine learning model, recognize the scene where the user on the vehicle side is currently located.

[0095] In this step, the model service model is used to recognize complex scenes. That is, based on the AI algorithm related to the machine learning model, recognize complex scenes. As another expression method, the model service module is used to sense complex scenes. For example, in a navigation scene, predict the next route, etc. That is, the model service module is used to perform model analysis on the input basic data by means of an AI algorithm. This mainly performs further mining on the data based on historical features.

[0096] At 8032, based on the rule setting module, detect whether the distributed basic data meets a predetermined rule, and based on the obtained detection result, recognize the scene where the user on the vehicle side is currently located.

[0097] In this step, the rule setting module is used to recognize simple scenes. That is, the rule setting module is for providing lightweight pre-rule realization. For example, assuming that the basic data delivered by one scene engine is vehicle state data, the scene engine can call the rule setting module to determine whether the current driving speed of the vehicle is overspeed. That is, the rule setting module can preset a speed threshold. That is, a setting rule is generated in advance, and based on this setting rule, it is determined whether the vehicle is currently driving overspeed. In 8033, based on the delivered basic data and the profile that matches the basic data, the scene where the user on the vehicle side is currently located is recognized.

[0098] In the embodiments of the present application, the generated profile includes, but is not limited to, a user profile, a vehicle profile, an environment profile, and a content profile. Here, since the profile is obtained by performing initial abstraction on the historical basic data related to the vehicle to learn features, by combining the real-time obtained basic data with the profile to perform scene recognition, the accuracy of recognition can be significantly improved.

[0099] In another possible implementation form, the generated profile is used to guide the generation of service messages by the scene engine. For example, based on the user profile and the content profile, a service message preferred by the user or a service message that matches the basic information of the user is generated. Also for example, based on the vehicle profile, a service message that matches the driving behavior habits of the user, etc. is generated. The embodiments of the present application do not specifically limit this.

[0100] In 8034, a content service module is called to obtain specified basic data that matches the current time and space based on the distributed basic data, and a step of recognizing the scene where the user on the vehicle side is currently located based on the specified basic data is executed.

[0101] Here, the content service module includes, but is not limited to, the weather service, road condition service, map open platform service, geofencing, reverse GEO (geography), etc. shown in FIG. 9.

[0102] Taking the weather service as an example, assuming that the basic data received by the weather service is trajectory data and weather environment data, the weather service determines the geographical location where the target vehicle is currently located based on the trajectory data, and then determines the weather environment data that matches the current time and space based on the geographical location, current time, and distributed weather environment data. For example, obtain weather environment data such as temperature and wind force at the current time and space. Subsequently, based on the weather environment data that matches the current time and space, it is recognized whether it is sunny or rainy at present.

[0103] Here, geofencing is used to determine whether a point is located within a surface. For example, it is determined whether the vehicle is currently within the geographical range of the home. If it is Yes, the corresponding operation is executed. For example, turn on the air conditioner or lamp indoors early. Reverse GEO can output the geographical location in text form based on the longitude and latitude data. For example, geographical location information such as **City** District **Street is output. Hereinafter, with reference to FIG. 10, the service processing of a single scene engine will be described.

[0104] As shown in FIG. 10, since the acquired basic data is encapsulated in the event uniform in the data access layer, what the scene engine receives is actually the basic data in the Event format. Here, the scene engine performs an event check. That is, each scene engine first performs an event check after accessing the basic data in the Event format. That is, a check process is performed on the distributed basic data. After the check is completed, generally, in order to improve the data processing efficiency, a plurality of threads are created, and service processing is performed by the plurality of threads. The service processing by each thread performs scene recognition depending on external basic capabilities as shown in FIG. 10. That is, the function module of the public service layer is called, and based on the distributed basic data, the step of recognizing the scene where the target vehicle is currently located is executed. Here, the post-processing is to asynchronously process the generated service message in the thread pool.

[0105] In another implementation form, as shown in FIG. 9, based on the historical basic data stored offline, algorithm predictions such as destination mining and customization mining can be performed to guide scene recognition. The embodiments of the present application do not specifically limit this. As shown in FIG. 9, the embodiments of the present application also relate to the storage of state data. Here, the state data refers to some description information about humans, vehicles, roads, environments, etc. that do not have a high occurrence frequency and do not have a high variation frequency. As an example, the storage system may be a Hadoop storage system, and the embodiments of the present application do not specifically limit this.

[0106] At 804, the server determines at least one service currently required by the target vehicle based on the obtained scene recognition result, generates a service message for the at least one service, and pushes the generated service message to the target vehicle. Here, the service types of each service among the at least one service are different.

[0107] In a possible implementation form, the step of determining at least one service currently required by the target vehicle based on the obtained scene recognition result includes: determining at least one scene having a current service requirement from the scenes recognized by each scene engine; determining a service that matches at least one scene based on the correspondence between the scene and the service; and determining the service that matches at least one scene as at least one service currently required by the target vehicle.

[0108] Here, the scene having a service requirement is an unusual scene that needs to be served. These scenes may be preset. For example, a rainy day scene, a fatigue scene, an overspeed scene, etc. all belong to the scenes having a service requirement. In addition, the embodiments of the present application can also preset the correspondence between the scene and the service. Here, different scenes may correspond to services of the same type. For example, both the commuting scene and the fatigue scene may correspond to the listening scene. The embodiments of the present application do not specifically limit this.

[0109] In Example 1, in the navigation scene, the basic data distributed from the data access layer to the corresponding scene engine may include any one or at least two combinations of vehicle state data, trajectory data, dynamic road state data, POI data, infrastructure data, and weather environment data. The corresponding scene engine calls function modules such as the rule setting module, the model service module, and the profile in the public service layer to perform scene recognition based on the distributed basic data and execute the step of generating a navigation message that matches the navigation scene. Here, the navigation message may be as shown in FIG. 7.

[0110] In Example 2, in the content service scenario, the basic data distributed from the data access layer to the corresponding scene engine may include any one or a combination of two of the user behavior data and the vehicle state data. The corresponding scene engine calls functional modules such as the content service module and the profile in the public service layer, performs scene recognition based on the distributed basic data, and executes the step of generating a content service message that matches the content service scene. For example, push the listening service to the user on the vehicle side. In the embodiment of the present application, the step of pushing the generated service message to the target vehicle is executed by the arbitration module.

[0111] In a possible implementation form, the arbitration module may include a traffic control module, a decoration module, a push module, and the like. Here, after receiving the service message generated by the scene engine, the arbitration module manages the distribution order or frequency of the service message through the traffic control module. Thereby, it is avoided to interfere with the user on the vehicle side by frequent message pushing. The decoration module is responsible for controlling the display form of the service message in the application software client on the vehicle side. The push module is responsible for pushing the message to the vehicle side.

[0112] In 8041, when it is necessary to push all the service messages generated by multiple scene engines to the vehicle side, the traffic control module controls the message push according to the priority rule.

[0113] That is, the traffic control module can determine the target service message from the service messages generated by at least two scene engines according to the priority rules. Here, the target service message is the service message with the highest demand in the current scene. Also, the push module pushes the target service message to the vehicle side. Here, the priority rules may be such that the higher the demand for the service message in the current scene, the higher its priority.

[0114] For example, when the current user is in a fatigue scene, what the current vehicle side most needs may not be the weather service but the audio listening service. As an example, the demand may be preset. The embodiments of the present application do not specifically limit this. Note that in order to ensure the diversity of services, the traffic control module can also select and push multiple service messages ranked at the top in terms of importance from the service messages generated by at least two scene engines according to the priority rules. The embodiments of the present application do not specifically limit this.

[0115] The second point that needs to be explained is that the arbitration module can perform message pushing to the vehicle side in sequence according to the predetermined priority rules. After pushing the service message that the vehicle side currently most needs, it may not be necessary to perform other service message pushing, or it may not be necessary to perform pushing after pushing multiple other service messages. The embodiments of the present application do not specifically limit this. That is, the embodiments of the present application further include the following.

[0116] In 8042, according to the priority rules, the service messages generated by at least two scene engines are pushed to the target vehicle in sequence at the target frequency interval.

[0117] In 8043, according to the priority rules, some of the service messages generated by at least two scene engines are pushed to the target vehicles in order at the target frequency interval.

[0118] In 8044, for at least two service messages generated by one scene engine, the traffic control module controls the distribution frequency of these service messages.

[0119] That is, when the number of service messages generated by one scene engine is at least two, the traffic control module can push these service messages to the vehicle side at the target frequency interval. Here, the value of the target frequency interval may be 5 minutes, 10 minutes, etc., and the embodiments of the present application do not specifically limit this.

[0120] In a possible implementation, after the traffic control for the service message is completed, the arbitration module returns the traffic control result to the calling side. Here, the calling side here refers to the scene engine. Note that for the service message that has been traffic controlled, when the arbitration module determines that the service message meets its basic requirements, it can also return a successful result to the calling side. It should be noted that if the above service message is in the form of a service card, what is pushed to the vehicle side is a service card. In 805, the target vehicle displays the service message pushed from the server. In a possible implementation, the vehicle side can display the service message based on the dynamic message container technology.

[0121] In another possible implementation, the arbitration module can also instruct the display format of service messages on the vehicle side. Specifically, the decoration module included in the arbitration module is responsible for controlling the display format of service messages in the application software client on the vehicle side. Here, the arbitration module can instruct the specific display format of service messages on the vehicle side by distributing a message display template. The embodiments of the present application do not specifically limit this.

[0122] That is, the embodiments of the present application further include the steps of obtaining a message display template that matches the generated service message, and sending the message display template to the target vehicle, where the message display template is for instructing the target vehicle to display the received service message according to the message display template.

[0123] The first point that needs to be explained is that one service message may correspond to one message display template. For example, the listening service corresponds to one form of message display template, and the weather service corresponds to another form of message display template. The embodiments of the present application do not specifically limit this.

[0124] The second point that needs to be explained is that the message display template may be sent before the transmission of the service message, or may be sent together with the service message. The embodiments of the present application do not specifically limit this.

[0125] In short, in the embodiments of the present application, after the user gets in the car, the server analyzes the data collected in real time to actively recognize the scene where the vehicle is currently located. When the user on the vehicle side needs a service, the corresponding service can be actively pushed to the vehicle side. For example, the service that the user currently most needs is pushed to the vehicle side. That is, the function card that is currently most needed is presented for the user. Thereby, the user can perform immersive driving and at the same time receive services more quickly and easily to obtain information. The method provided in the embodiments of the present application has at least the following beneficial effects.

[0126] In the embodiments of the present application, the server actively acquires the basic data related to the vehicle. After preprocessing the acquired basic data by the data access layer, the data access layer distributes the data to different scene engines based on the data types subscribed by each scene engine for scene recognition. Based on the scene recognized based on each scene engine, after determining at least one service currently required by the target vehicle, the embodiments of the present application automatically generate a service message for at least one service and actively push the generated service message to the vehicle. The embodiments of the present application can realize active recognition of the scene, actively determine the service that the user may need at the current time and space based on the scene recognition result, and actively push the corresponding service message to the vehicle side. Since the user can receive the required service without performing a separate operation, the driving safety in the in-vehicle environment is greatly improved, the service requirements of the user in the in-vehicle environment are met, and the effect is high. That is, the embodiments of the present application realize real-time scene sensing by the scene engine and actively provide accurate push services to the user on the vehicle side.

[0127] In the embodiments of the present application, scene recognition is completed by the server side. It not only provides strong scene sensing capabilities and can provide various services, but also has strong scene extension capabilities. Specifically, as the services become richer, the server side can provide more scene engines while maintaining the current architecture as it is. That is, the interaction framework provided in the embodiments of the present application can quickly realize the extension of the scene engine without affecting the ability output of other scene engines.

[0128] In addition, the embodiments of the present application further have the ability to quickly adapt to multi-tenants. Without performing version iteration, it can meet the needs of various vehicle scenes with the same service capabilities in an arranged manner. That is, the embodiments of the present application can be adapted to vehicle scenes with different needs and are applicable to vehicle scenes with different needs. In another embodiment, hereinafter, while referring to FIG. 11, the overall execution process of the embodiments of the present application is summarized. The execution process includes the following. In 1101, the back-end server collects basic data related to the vehicle through multiple routes.

[0129] In the embodiments of the present application, the back-end server can collect data from the application software client on the vehicle side, can also collect data in the form of event tracking, can also collect data in the form of long connections, and can also collect data in the form of services. The embodiments of the present application do not specifically limit this. In 1102, the data access layer accesses the collected basic data and performs preprocessing on the collected basic data.

[0130] Here, the preprocessing process includes, but is not limited to, data check, encapsulation of event uniformity, and synchronization of asynchronous messages. The embodiments of the present application do not specifically limit this.

[0131] In 1103, the data access layer distributes the pre - processed basic data to different scene engines according to the data types subscribed by each scene engine by the registration center.

[0132] In 1104, for each scene engine, call the function module of the public service layer, execute the step of performing scene recognition based on the distributed basic data, determine at least one service currently required by the target vehicle based on the scene recognized by each scene engine, and generate a service message for at least one service.

[0133] In 1105, the arbitration module performs arbitration on the generated service message and pushes the generated service message to the vehicle side. In 1106, the vehicle side displays the received service message.

[0134] In a possible implementation form, all data interactions related to the embodiments of this application all use an asynchronous method. That is, data interacts in the form of asynchronous messages.

[0135] The method provided in the embodiments of this application actively acquires basic data related to vehicles. After the acquired basic data is preprocessed by the data access layer, it is distributed from the data access layer to different scene engines for scene recognition based on the data types subscribed by each scene engine. Based on the scenes recognized by each scene engine, after determining at least one service currently required by the target vehicle, the embodiments of this application automatically generate a service message for at least one service and actively push the generated service message to the vehicle. The embodiments of this application can realize active recognition of scenes, actively determine the services that the user may need at the current time and space based on the scene recognition results, and actively push the corresponding service messages to the vehicle side. Since the user can receive the required services without performing separate operations, the driving safety in the in-vehicle environment is greatly improved, the service needs of the user in the in-vehicle environment are met, and the effect is high. That is, the embodiments of this application realize real-time scene sensing by the scene engine and actively provide accurate push services to the users on the vehicle side.

[0136] In addition, in the embodiments of this application, scene recognition is completed by the server side. It can not only provide a strong scene sensing ability and provide various services, but also has a strong scene expansion ability. Specifically, as the services become richer, the server side can provide more scene engines while maintaining the current architecture. That is, the interaction framework provided in the embodiments of this application can quickly realize the expansion of scene engines without affecting the ability output of other scene engines.

[0137] In addition, the embodiments of the present application further have the ability to quickly adapt to multi-tenants. Without performing version iteration, the requirements of various vehicle scenarios can be met with the same service capabilities in the deployment method. That is, the embodiments of the present application can be adapted to vehicle scenarios with different requirements and can be applied to vehicle scenarios with different requirements.

[0138] FIG. 12 is a schematic diagram showing the structure of a message push device according to an embodiment of the present application. The device is applied to a server. As shown in FIG. 12, the device includes an acquisition module 1201 configured to acquire basic data related to a target vehicle, where the basic data includes at least vehicle user data and driving environment data, and the acquisition module 1201; a recognition module 1202 configured to recognize the scene where the target vehicle is currently located based on the acquired basic data; a generation module 1203 configured to determine at least one service currently required by the target vehicle based on the obtained scene recognition result and generate a service message for the at least one service; and a transmission module 1204 configured to push the generated service message to the target vehicle.

[0139] The device provided in the embodiments of this application actively acquires basic data related to a vehicle, and based on the acquired basic data, actively recognizes the scene where the target vehicle is currently located. Here, the basic data includes at least vehicle user data and driving environment data. The server determines at least one service currently required by the target vehicle based on the obtained scene recognition result, then automatically generates a service message for the at least one service, and actively pushes the generated service message to the vehicle. The embodiments of this application can realize active recognition of a scene, actively determine services that a user may need at the current time and space based on the scene recognition result, and actively push corresponding service messages to the vehicle side. Since the user can receive the required services without performing separate operations, the driving safety in the in-vehicle environment is greatly improved, the service needs of the user in the in-vehicle environment are satisfied, and the effect is high.

[0140] In a possible implementation form, the generation module 1203 is configured to execute the steps of determining the at least one service based on the obtained scene recognition result, where the service types of each service among the at least one service are different, and generating a service card that matches each service, where one service card includes a service message of one service.

[0141] In a possible implementation form, the sending module 1204 is configured to select service cards of at least two different service types from the generated service cards according to a priority rule, push the selected service cards to the target vehicle, push the service card with the highest demand degree in the current scene to the target vehicle, and push the generated service cards to the target vehicle in sequence at a target frequency interval according to the priority rule. The priority rule is that the higher the demand degree of the service card in the current scene, the higher its priority.

[0142] In a possible implementation form, the recognition module 1202 is configured to execute a step of calling a function module of the public service layer to perform recognition on the scene where the target vehicle is currently located based on the obtained basic data.

[0143] In a possible implementation form, the recognition module 1202 inputs the obtained basic data into a machine learning model of the model service module, and based on the machine learning model, recognizes the scene where the target vehicle is currently located; based on the rule setting module, detects whether the obtained basic data meets a predetermined rule, and based on the obtained detection result, recognizes the scene where the target vehicle is currently located; based on the obtained basic data and the profile that matches the basic data, recognizes the scene where the target vehicle is currently located, where the profile is constructed based on historical basic data related to the target vehicle; calls the content service module to obtain specified basic data that matches the current time and space based on the obtained basic data, and based on the specified basic data, recognizes the scene where the target vehicle is currently located.

[0144] In a possible implementation form, the recognition module 1202 is configured to execute a step of distributing the obtained basic data to different scene engines for scene recognition, where the basic data received by each scene engine matches the pre-subscribed data type; and a step of using the scene recognized by each scene engine as the scene recognition result.

[0145] In a possible implementation form, the recognition module 1202 checks the distributed basic data for each of the scene engines, and after completing the check, creates a plurality of threads, and the plurality of threads are configured to call the functional modules of the public service layer and perform recognition on the scene where the target vehicle is currently located based on the distributed basic data.

[0146] In a possible implementation form, the generation module 1203 determines at least one scene having service requirements from the scenes recognized by each of the scene engines, determines a service that matches the at least one scene based on the correspondence between the scene and the service, and is configured to determine the service that matches the at least one scene as the at least one service.

[0147] In a possible implementation form, the recognition module 1202 performs preprocessing on the acquired basic data and is configured to distribute the preprocessed basic data to different scene engines.

[0148] In a possible implementation form, the sending module 1204 generates a target service message from service messages generated by at least two scene engines according to a priority rule, and pushes the target service message to the target vehicle, where the target service message is the service message with the highest demand degree in the current scene, and according to the priority rule, pushing the service messages generated by the at least two scene engines to the target vehicle in sequence at a target frequency interval, and according to the priority rule, pushing some of the service messages generated by the at least two scene engines to the target vehicle in sequence at the target frequency interval. In response to the number of service messages generated by one of the scene engines being at least two, pushing the at least two service messages to the target vehicle at the target frequency interval; The priority rule is such that the higher the demand for service messages in the current scene, the higher the priority.

[0149] In a possible implementation form, the acquisition module 1201 is configured to acquire a message display template that matches the generated service message. The transmission module 1204 is configured to transmit the message display template to the target vehicle, and the message display template is for instructing the target vehicle to display the received service message according to the message display template.

[0150] In a possible implementation form, the vehicle user data includes vehicle data and user data. The vehicle data includes at least vehicle state data and trajectory data, and the user data includes at least user behavior data, user preference data, and resource label data of the user on the vehicle side. The driving environment data includes at least road condition data, weather environment data, POI data, and infrastructure data.

[0151] In a possible implementation form, the profiles that match the basic data include user profiles, vehicle profiles, environment profiles, and content profiles. Here, the environmental profile is constructed based on historical weather environment data and updated by real-time acquired weather environment data. The vehicle profile is constructed based on historical vehicle state data and updated by real-time acquired vehicle state data. The user profile is constructed based on historical user behavior data and historical user preference data and updated by real-time acquired user behavior data and user preference data. The content profile is constructed based on historical resource label data and updated by real-time acquired resource label data.

[0152] Any combination of all the above selectable technical solutions can be used to arbitrarily form selectable embodiments of the present application. Here, it will not be described one by one.

[0153] It should be noted that when the message push device provided in the above embodiment performs message push, only the division of each of the above function modules is taken as an example for explanation. In actual application, if necessary, the above functions can be realized by various function modules. That is, the internal structure of the device is divided into various function modules to complete all or part of the above functions. It should be noted that the concept of the device provided in the above embodiment is the same as that of the method embodiment. For the specific implementation process, please refer to the method embodiment. Here, detailed description will be omitted.

[0154] FIG. 13 is a schematic diagram showing the structure of a server according to an embodiment of the present application. The server 1300 may vary greatly depending on its configuration or performance. It may include one or more central processing units (CPUs) 1301 and one or more memories 1302. Here, at least one instruction is stored in the memory 1302, and the at least one instruction is loaded and executed by the processor 1301 to implement the message push method provided in the embodiments of the above methods. Of course, the server may also have components such as a wired or wireless network interface, a keyboard, and an input / output interface for input / output. The server may also have other components for realizing the functions of the device. Here, detailed descriptions are omitted.

[0155] In an exemplary embodiment, for example, a computer-readable storage medium such as a memory containing instructions is further provided. The above instructions are executed by a processor in a terminal to implement the message push method in the above embodiments. For example, the computer-readable storage medium may be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a flexible disk, an optical data storage device, or the like.

[0156] All or some of the steps in the above embodiments may be implemented by hardware, or may be implemented by a program instructing related hardware, and the program may be stored in a computer-readable storage medium. It should be understood by those skilled in the art that the above storage medium may be a read-only memory, a magnetic disk, an optical disk, or the like.

[0157] The above are only preferred embodiments of the present application and do not limit the present application. All modifications, equivalent replacements, improvements, etc. made without departing from the spirit and principles of the present application shall be included within the protection scope of the present application.

Description of Reference Numerals

[0158] 101 Vehicle 102 Server 1021 Data Access Layer 1022 Scene Engine 1023 Common Service Layer 1024 Arbitration Module 1201 Acquisition Module 1202 Recognition Module 1203 Generation Module 1204 Transmission Module 1300 Server 1301 Processor 1302 Memory

Claims

1. A message push method executed by a server, comprising: actively acquiring basic data related to a target vehicle, where the basic data includes at least vehicle data, user data, and driving environment data, and the user data includes at least user behavior data of a user on the vehicle side; actively recognizing the scene where the target vehicle is currently located based on the acquired basic data; distributing the acquired basic data to at least two different scene engines, where the basic data received by each scene engine matches a pre-registered data type; each of the at least two different scene engines creates a plurality of threads, and the plurality of threads call functional modules of a common service layer to recognize the scene where the target vehicle is currently located based on the distributed basic data; using the scenes recognized by the at least two different scene engines as scene recognition results; determining at least one service currently required by the target vehicle based on the obtained scene recognition result, and generating a service message for the at least one service; actively pushing the generated service message to the target vehicle.

2. The step of determining at least one service currently required by the target vehicle based on the obtained scene recognition result and generating a service message for the at least one service includes: determining the at least one service based on the obtained scene recognition result, where the service types of each service among the at least one service are different; generating a service card corresponding to each service, where one service card includes a service message for one service. The method according to Claim 1.

3. The step of pushing the generated service message to the target vehicle includes: according to the priority rule, selecting at least two service cards of different service types from the generated service cards, and pushing the selected service cards to the target vehicle; pushing the service card with the highest demand in the current scene to the target vehicle; pushing the generated service cards to the target vehicle in order at the target frequency interval according to the priority rule, and including any one of them; The priority rule is characterized in that the higher the demand for the service card in the current scene, the higher its priority. The method according to claim 2.

4. The step of calling the function module of the common service layer and performing recognition on the scene where the target vehicle is currently located based on the acquired basic data includes: inputting the acquired basic data into the machine learning model of the model service module, and recognizing the scene where the target vehicle is currently located based on the machine learning model; detecting whether the acquired basic data meets a predetermined rule based on the rule setting module, and recognizing the scene where the target vehicle is currently located based on the obtained detection result; recognizing the scene where the target vehicle is currently located based on the acquired basic data and the profile matching the basic data, where the profile is constructed based on the historical basic data related to the target vehicle; calling the content service module, acquiring specified basic data that matches the current time and space based on the acquired basic data, and recognizing the scene where the target vehicle is currently located based on the specified basic data, and including at least one of them. The method according to claim 1.

5. The step of determining a plurality of different services currently required by the target vehicle based on the obtained scene recognition result includes: determining at least one scene having a current service demand from the scenes recognized by each scene engine; Based on the correspondence between the scene and the service, determining a service that matches the at least one scene; determining the service that matches the at least one scene as the plurality of different services, characterized by including: The method according to claim 4.

6. The step of pushing the generated service message to the target vehicle includes: generating a target service message from the service messages generated by at least two scene engines according to a priority rule, and pushing the target service message to the target vehicle, where the target service message is the service message with the highest demand in the current scene; pushing the service messages generated by the at least two scene engines to the target vehicle in order at a target frequency interval according to the priority rule; pushing some of the service messages generated by the at least two scene engines to the target vehicle in order at the target frequency interval according to the priority rule; including any one of: in response to the number of service messages generated by one scene engine being at least two, pushing the at least two service messages to the target vehicle at the target frequency interval; The priority rule is characterized in that the higher the demand for the service message in the current scene, the higher its priority. The method according to claim 4.

7. The method further includes: obtaining a message display template that matches the generated service message; sending the message display template to the target vehicle, where the message display template is for instructing the target vehicle to display the received service message according to the message display template. The method according to claim 1.

8. The vehicle data includes at least vehicle state data and trajectory data, and the user data further includes at least user preference data and resource label data of the user on the vehicle side. The driving environment data includes at least road condition data, weather environment data, point of interest (POI) data, and infrastructure data. The method according to any one of claims 1 to 6.

9. The profiles matching the basic data include user profiles, vehicle profiles, environmental profiles, and content profiles. Here, the environmental profile is constructed based on historical weather environment data and updated by real-time acquired weather environment data. The vehicle profile is constructed based on historical vehicle state data and updated by real-time acquired vehicle state data. The user profile is constructed based on historical user behavior data and historical user preference data and updated by real-time acquired user behavior data and user preference data. The content profile is constructed based on historical resource label data and updated by real-time acquired resource label data. The method according to claim 8.

10. A computer program for causing a computer to implement the message push method according to any one of claims 1 to 9.

11. A memory configured to store at least one instruction, A server comprising a processor configured to load and execute the at least one instruction to execute the method according to any one of claims 1 to 9.

Images