DE102012219234A1 - Prediction method for predicting locations of motor car, involves providing predicted location or predicted locations and associated location information using data over interface, where data is provided as given multimodal movement model - Google Patents

Abstract

The method involves providing predicted location or multiple predicted locations and associated location information and connection information based on a position using data over an interface i.e. client application programming interface (API), where the data is provided as a given multimodal movement model, and the connection information comprises modality information. The data is provided if an authentication is successfully performed. The location information or the connection information is selected based on a request message over the interface.

Description

The invention relates to a prediction method. For many applications, it is desirable to provide one or more predicted locations. This may concern, for example, predicted locations of a motor vehicle.

The rapid and continuing development of computer technology and also a general trend towards green energy has led to sophisticated vehicle sensor systems in vehicles, for example contributing to energy-efficient internal combustion engines and, in particular, to hybrid and electric vehicles. Navigation units use in this context position determination units, such as supported by information provided by GPS signals. They also use information provided by the powertrain, gyrometer, accelerometer, and other vehicle sensors to determine exactly one position of the vehicle.

In this context, certain functions in the vehicle fundamentally require that a user of the vehicle provide information about a destination that is to be reached with the vehicle. Furthermore, their execution is sometimes difficult or error-prone when deviating from a route determined by means of the navigation unit of the vehicle.

The object underlying the invention is to provide a prediction method which contributes to a precise prediction of one or more predicted locations and to the fact that it is convenient to use.

The object is solved by the features of the independent claim. Advantageous embodiments are characterized in the subclaims.

The invention is characterized by a prediction method in which a predicted location or a plurality of predicted locations and associated location information are provided via an interface depending on a position by means of a predetermined multimodal motion model as a data record.

In this way, the predicted location (s) and associated location information are readily available through the interface and may then optionally be used by a corresponding application for further processing. They can be used so universally and for example also to a route planning, but not limited thereto. In particular, by means of the multimodal motion model, a corresponding predicted location and / or multiple predicted locations and the associated location information may be provided for different resources. In this context, resources may include persons, but may also include different means of transport, such as a motor vehicle, a bicycle, or other resources, such as a mobile phone.

The multimodal movement model is thus provided for various modalities, such as running, cycling, using a motor vehicle, such as a car or a motorcycle or a truck. Further, the modalities may include the use of a train, a tram, a bus, a ship, an airplane, a wheelchair, a lift, an escalator, and the like.

In this case, the multimodal movement model can each comprise a subset of the modalities and / or resources, the subset in particular comprising at least two different modalities.

The respective data record provided via the interface can then be further evaluated, in particular by a corresponding application.

Via the interface, the data record is made available externally in particular. This can for example be external to a server, by means of which the respective data record is provided at the interface.

According to an advantageous embodiment, one or more connections to the one or more predicted locations depending on the position with associated connection information by means of the multimodal motion model are provided as a record via the interface.

By providing the connections and the associated connection information, the respective data record has extensive information that can be used accordingly by corresponding applications that access the interface.

According to a further advantageous embodiment, the connection information comprises a modality information. The modality information is so representative of one type of means of transport and / or travel.

According to a further advantageous embodiment, the connection information comprises a time duration information that is representative of the The amount of time it takes to get along the connection to the respective assigned predicated location.

According to a further advantageous embodiment, the interface is a client API, wherein API is a common abbreviation for "application programming interface", which can also be referred to as "application programming interface".

In particular, such a client API can work independently of transport mechanisms and is thus easy and universally applicable.

According to a further advantageous embodiment, a provision of the respective data record only takes place if an authentication was previously carried out successfully. In this way, in particular sensitive data can be protected accordingly and ensure that only units have access to the interface, and in particular the respectively provided there records, which also have permission to do so.

According to a further advantageous embodiment, the available type of location information and / or connection information is provided on request at the interface. In this way, it can be easily detected which type of location information and / or connection information is available and thus in particular a selection of the requested type of location information and / or connection information are made, in particular by a corresponding application that requests the respective records, and so in particular a quantity of data to be transmitted is reduced.

According to a further advantageous embodiment, upon a change of the predicted location (s) and / or associated location information and / or the connection or connections and / or associated connection information, this is provided at the interface. In this way, such can thus be provided in particular automatically at the interface and so these are provided in particular in the form of a subscription in each case given currently. In this way, a respective active requesting of the respective data records can thus be reduced.

According to a further advantageous embodiment, depending on a request message via the interface, a selection of the respective location information and / or connection information is provided. In this way, a data volume to be transmitted relative to the respective data set can be suitably reduced and, in particular, reduced to those data which are actually required for the respective application.

Embodiments of the invention are explained in more detail below with reference to the schematic drawings. Show it:

1 various elements to explain a multimodal movement model,

2 a flow chart for creating the multimodal motion model,

3 Units by means of which a prediction method is performed and

4 a graph representation of a mobility horizon.

In the 1 designated 1 a backend server. Further, a vehicle 3 available and a mobile device 5 , which is designed in particular as a smartphone and a user of the vehicle 3 assigned. Basically, you can also use several mobile devices 5 be provided, for example, the various users of the vehicle 3 , ie persons, are assigned.

The backend server 1 has at least one communication interface via which it can communicate with at least one other component. So also points the vehicle 3 as well as a communication interface on which, for example, with the backend server 1 can communicate.

The vehicle 3 has a vehicle sensor system, for example, a position determination unit 7 may include, for example, GPS-based, and / or a gyrometer 9 or other vehicle sensors.

In addition, in the vehicle 3 also a navigation unit 11 arranged. The navigation unit 11 is for example also the position determination unit 7 assigned and they can also communicate with other vehicle sensors. The navigation unit 11 includes in particular a computing unit and a data and program memory.

The mobile device 5 , which is designed in particular as a smartphone, for example, includes a further position determination unit 13 and / or an acceleration sensor 15 , In this way it is designed to capture its position, in particular quasi-continuously.

The mobile device 5 also includes a communication interface, for example may be a mobile interface, via the position data of the mobile terminal 5 and associated time data can be transmitted, in particular to one or more location-based services 17 , Also the respective location-based service 17 It has a communication interface via which it can communicate directly or indirectly with the communication interface of the mobile device 5 can communicate. Examples of such location-based services are Google Latitude, Gowalla, Foursquare, Qype, Geologi, and Facebook Places. For example, Google Latitude is designed to gain access to a user's footprints and focuses on positions and their history.

Gowalla, Foursquare, Qype, Geoloqi and Facebook Places provide access to check-ins and context information such as location descriptions of the user. Facebook Places also gives access to a check-in history of friends.

Google Calendar provides a broad range of interaction opportunities related to events, contacts, and places.

The location-based services also have a communication interface to the respective mobile terminal 5 also a communication interface, via the location-based service tuple comprising position data and associated time data related to the respective user can be retrieved. In this context, for example, they have a respective API that can be addressed using REST and can also be represented using Atom or JSON. In addition, most location-based services also provide libraries for php, C #, and Java.

In this respect, provision of respective location-based service tuples is, for example, with the backend server 1 just possible. Typically, authorization must be established to connect to the location-based service and retrieve corresponding location-based service tuples. For example, in the case of web services, this can be done using OAuth2.

For example, determining a multimodal motion model may be done in the backend server 1 respectively. Alternatively or additionally, however, this can also be distributed to one or more from the set of the backend server 1 , of the vehicle 3 and the mobile terminal 5 respectively. Thus, for example, individual steps in particular can be processed only on the mobile terminal or in the vehicle, which may be desirable, for example, with regard to data protection considerations and / or protection of the privacy of the respective user.

Furthermore, in the case of multiple users of the vehicle 3 also several corresponding mobile terminals associated therewith 5 be present and related to the respective user related data from the mobile terminal 5 to the respective location-based services 17 be transmitted.

A flow diagram of a program for exemplary realization of determining the movement model is based on 2 and will be explained in more detail below. It is whole or distributed in the respective data and program memory of the backend server 1 and / or the navigation unit 11 and / or the mobile terminal 5 saved. As part of the program, the multimodal movement model is created, which is a personal movement model of the user of the vehicle 3 includes.

The program is started in a step S1 in which variables can be initialized if necessary.

In a step S3, tuples TUP are provided relative to a respective user, which include position data and associated time data relative to the respective user. Thus, vehicle sensor-based tuples are provided in this context.

Further, location based service tuples are provided by at least one of the location based services. These also include position data and associated time data relative to the respective user. In this context, the location-based service tuples may also include information about check-ins, attributes of the places the user visits, contacts, current friends, notes, and even appointments.

In particular, in step S3 corresponding tuples TUP relative to the respective user are provided for a suitably selected, in particular longer, period. This period can, for example, include several days or even several weeks or several months.

Check-ins provide feedback on which positions the user actually wants to be. In addition, they lead to a certain semantics in the sense that one knows in which kind of place the user is, which name is to be assigned to the place and how often he is at this place. One-time check-ins can be classified as of little importance. In addition, however, it should be borne in mind that a user might forget to check in or not makes just before he leaves the respective place and so no indication is given about an arrival time and a length of stay. Calendar entries, contact information, and friends' positions can be used to decide whether the user wants to meet someone in a particular location, which can be used to great advantage in non-routine prediction within the movement model.

In this way, a plurality of tuples TUP can thus be provided in the step S5.

In a step S7 follows a cleaning up of the information contained in the tuples TUP and a merging of the information.

For this purpose, it is assumed, for example, that vehicle-sensor-based tuples TUP are already cleared and are thus adapted to the road network, for example, using so-called map matching techniques. Parking positions can be extracted, for example, using so-called clustering methods (such as DJ clustering). In this context, for example, park cluster tuples are determined as a function of at least one parking indicator determined on the vehicle side. Such a parking indicator may, for example, a state of a terminal 15 be the vehicle or other operating variables of the vehicle, which are representative of the fact that the vehicle 3 located in a parking position. Thus, for example, an inactive state of the position determination unit 7 be a parking indicator of the vehicle. For example, where the parking indicator represents a park state when the position determination unit 7 is inactive for a given sleep duration threshold.

In principle, as part of the cleanup of the tuples TUP those tuples TUP are discarded which have position data with a larger accuracy radius, ie a higher degree of inaccuracy, than a tuple TUP with almost the same time data. Thus, for example, those location-based service tuples that are timed to vehicle sensor-based tuples during a ride on the vehicle are discarded 3 correspond.

Further, those location-based service tuples are discarded whose position data has a precision radius greater than a predetermined inaccuracy threshold. The accuracy radius is so representative of a maximum inaccuracy of the respective position data. The predetermined inaccuracy threshold may be, for example, 800 m.

Further, based on respective location-based service tuples, a minimum distance is determined depending on their distance to temporally adjacent tuples based on their respective position data minus a sum of the accuracy radii of the respective tuples associated with the respective position data. Those location-based service tuples are discarded whose consideration in the case of a movement trajectory to be determined based on a plurality of tuples TUP results in the minimum distance assigned to them falling below a predetermined minimum distance value.

In addition, in step S7, those location-based service tuples are discarded whose consideration in a movement trajectory to be determined based on a plurality of tuples implies a speed of the user above a predetermined speed threshold and / or an acceleration of the user above a predetermined acceleration threshold and related to tuples TUP with temporally adjacent time data.

The predetermined speed threshold may be, for example, 300 km / h. The predetermined acceleration value can be, for example, 3.2 × 10 ⁵ km / h ² .

Further, those location-based service tuples based on check-in are discarded and in which a distance based on the respective position data between the respective check-in based location-based service tuple and a further tuple within a given time window is larger is a predetermined check-in distance value where the additional tuple is the one closest to the location-based service tuple based on the respective check-in.

In a step S9, stops are determined on the basis of the tuples TUP remaining after the processing of step S7, specifically with regard to determining the respective destination point of the user. Thus, location-based service tuples based on check-ins are classified as candidate stop tuples. There are location-based service tuples that have a given spatial relationship with respect to their position data and have no temporally adjacent tuples outside the given spatial relationship but with a time interval less than a stop distance threshold to a candidate stop cluster tuple summarized.

Subsequently, a dominant stop tuple is then determined as a function of a candidate stop duration of stay and / or after accumulation of the candidate stop tuple. For example, the candidate stop-duration may be within the framework of the Clusters of the respective tuple in determining the respective candidate stop clusters are determined. Optionally, for location-based service tuples based on check-ins, a duration of stay is also associated with the respective tuple TUP. Basically, for example, a density-based clustering is done in this context.

The respective determined dominant stop tuple can then represent a target position of the respective movement trajectory of the user.

The respective dominant stop tuple is assigned, based on the associated movement trajectory, a park cluster tuple and thus a link is established between the two, thus containing the information which parking position the user has visited in this case with regard to the target position represented by Dominant stop tuple, reach.

In addition, a parking time duration is preferably determined and assigned to the respective park cluster tuple depending on the assigned movement trajectory and the dominant stop tuple.

Furthermore, in the course of determining the movement trajectory, a respective mode of transport, ie modality, is preferably determined for respective sections of the respective movement trajectory as a function of data of the tuples. In this context, for example, typical movement pattern or other sensor signal characteristics can be used for the respective means of transportation. In principle, this can also be done, for example, by using data from the acceleration sensor 15 of the mobile terminal 5 consequences. In addition, it can be used in this context, for example, that when using underground public transport during their use regularly no satellite-based position determination is possible due to a lack of the corresponding signal, such as the GPS signal.

In a step S11, the personal movement model is then created using the data prepared in steps S7 and S9, that is, the non-thrown tuple, the determined movement trajectories, the determined candidate stop residence times, and also using the time information that can be assigned to the respective movement trajectory For example, the time duration from the starting point of the respective movement trajectory to the target point, represented by the dominant stop tuple.

Furthermore, the creation of the personal movement model also takes place using the other historical information which can be derived from the time data of the tuple TUP, for example with respect to the respective days of the week, which can be assigned to the determined movement trajectories, and / or the respective time of day, that of the respective movement trajectory is assignable.

In addition, for different users of a particular vehicle 3 appropriate personal movement models are created and these are then used with respect to the respective vehicle 3 related to all its users.

The respective personal movement models can also be created according to a variety of modalities, with examples of the modalities are: running, so in various forms, such as running, walking, hiking, strolling and the like, cycling, driving a car, such a private or renting a car, riding a motorcycle, driving a truck, driving a train, tram and the like, driving a bus, driving a ship, flying with an airplane, driving a wheelchair, using a lift, using an escalator and the like.

The respective personal movement models determined in this way, also taking into account the various modalities, are preferably fused to form a multimodal movement model, this also especially with regard to a respective resource, such as a vehicle, a bicycle, an airplane and the like, but also the respective ones Person can be done.

In this connection, unless already explained above, a multiplicity of data sources can be used, which in particular include the user's electronic calendar or calendars, recorded movement profiles, for example of a smartphone, a vehicle and the like, location-based services, databases of locations of Interest, also referred to as Points of Interest, digital road map data for motor vehicles, bicycles and / or pedestrians, maps of buildings, digital data relating to air and / or ship routes, public transport timetables and the like.

For example, the multimodal motion model is in the backend server 1 saved. However, it can in principle also in the vehicle 3 and / or the mobile terminal 5 be stored completely or partially.

Based on 3 are represented units which can form parts or the whole of a prediction system in this connection and on which a corresponding prediction method can proceed. Such is a server 21 provided, for example, the backend server 1 can be, but can also be arranged or designed otherwise. On the server 21 the multimodal motion model is stored and used there to predict one or more predicted locations and associated location information. In addition, by means of the multimodal motion model, one or more connections can also be determined in this context to the one or more predicted locations.

This is done in each case starting from a position provided in this context. This can also be done depending on a time assigned to the respective position.

Starting from the respective position and, if appropriate, the assigned point in time, one or more locations can then be predicted by means of the multimodal movement model, in which context a predefined time horizon can be taken into account, that is to say those possible locations can be predicted which start from the point in time Time horizons are possible predicted places. The prediction can be done arbitrarily, that is, for example, based on one or different resources in the above sense. In this context, corresponding probability information can also be taken into account in the frame of the prediction. In this context, prediction algorithms can be used which are used, for example, in learning navigation systems.

In addition, corresponding calendar entries can also be used automatically to determine the predicted location (s). In this context, in prediction, a corresponding classification of respective clusters into working days, weekends, days, time of day and night time and also the time during the day can be used to provide suitable temporal information for the prediction.

In addition, the prediction may also include a prediction of a predictive schedule using the multimodal motion model. The predicted locations determined in the context of the prediction, the assigned location information and also the one or more connections to the one or more predicted locations and the associated connection information are then provided in the form of a data record. They are so in particular over an interface 25 provided.

In this context, for example, the data set can be offered via an Internet service, for example in an XML or JSON format. the interface 25 can also be realized using a so-called client API.

With the reference number 23 is in the 3 a client, where the client 23 especially external to the server 21 can be trained, but does not have to be. The client 23 can for example in the mobile terminal 5 be educated. However, he can in principle also in the vehicle 3 or any other location. The client 23 is designed in this context, via the interface 25 one or more requests to the server 21 to send.

In this context, an authentication is preferably required, which can be carried out in particular in the context of an authentication process, in the context of which, for example, a user name and a password must be transmitted in particular. In return, the corresponding client receives, for example, a time-based authentication token. This authentication token must then be present for all requests to the server 21 to be provided. Authentication can also be used on multiple sessions, also referred to as sessions. In particular, a status in this context can also be a prediction on the server 21 be followed. In this way, data protection requirements can be met.

In particular, various queries are provided, which may be designed, for example, as functions or methods, for example, in the context 27 a selection of possible such requests shown. Examples of such methods or functions are: getMobilityHorizon (), getProperties (), getRessources (), updateHorizon ().

The method getMobilityHorizon () has transfer parameters, which may include, for example, the position include the time and / or a selection of the type of location information and / or connection information and / or a corresponding horizon parameter specifying over which period the prediction should occur and / or whether a selection of the predicted locations to be returned or of the predicted location and / or the connections is to be made with regard to the probability information that is representative of a probability that a particular connection is used or another probability information that is representative of that Predicted location of the respective resource is also taken.

In addition, an identifier of the respective resource or the respective resources is passed as a parameter, with respect to the Record is requested. The requested dataset represents in this context a so-called mobility horizon.

The respective predicted location can be identified by corresponding position information, for example. The dataset, which, as explained above, may also be referred to as a mobility horizon, comprises in particular an identification of the respective resource or of the respective resources with respect to which it is output. In addition, the mobility horizon preferably also includes time stamp information for which the mobility horizon is generated. In addition, it also includes a starting position, which may also be a set of starting positions, especially if it is not clear, due to corresponding inaccuracies, which is the exact starting position.

The structure of the data set in this context is such that it can be represented in particular in the form of a graph, as can be seen from the 4 is shown. It thus comprises the respective predicted locations, which are identified in particular by a location identification and include associated location information, such as the respective location position, and / or a list of all resources that are at the predicted location and / or a description of the location using, for example a name, an address and the like. For example, the location information may also include a list of possible outgoing calls. In addition, it may also include information regarding the respective predicted subordinate locations, such as meeting rooms within a building or floors within a building. In addition, the location information may also include the further probability information representative of the presence of the respective resource at the respective predicted location. In addition, other information may be assigned as location information.

Furthermore, the data record may preferably also include one or more connections to the one or more predicted locations, which may be represented in particular by a corresponding identification. The respective connection is preferably associated with corresponding connection information in this context. The connection information may be, for example, a period of time required to reach its end by means of the respective connection from its assigned start. In addition, the connection information may also include the respective resource. It may also include the probability information representative of a probability that the particular connection will be used. In addition, the connection information may also include other information. Such other information related to the connection may also include so-called profiles as used in Advanced Driver Assistance Systems (ADAS) protocols. A specific implementation provides z. For example, the ADASIS v2 protocol.

Thus, a curve profile and / or a slope profile and / or a speed can thus be included. Furthermore, such other information may also be representative of a weather and / or an availability of mobile radio connections. However, it may also alternatively or additionally represent costs of the connections. Such costs may be, for example, tolls, but they may also be vehicle costs, and / or corresponding usage fees.

For example, by the method getproperties (), this can be done by the client 23 over the interface 25 which type of location information and / or connection information is to be selectively provided. As a return, a list of those types of location information and / or connection information can be returned, which in fact via the interface by means of the respective modal movement model for this case 25 can be provided.

By means of the method getRessources (), it is thus possible, for example, to transfer which types of resources or which named-named resources, such as a specific person, from the client 23 over the interface 25 be requested. The return is then a corresponding list of resources which, based on transfer parameters, actually exist in the respective modal movement model and can thus be returned.

Using the updateHorizon () method, an updated position is passed as a parameter, which is particularly representative of where a resource has moved. In addition, it includes an identification of the mobility horizon, a so-called main identification, which was previously requested or returned using the getMobilityHorizon () method. Optionally, a corresponding period of time can also be transferred, after which in each case an updated mobility horizon at the client 23 over the interface 25 should be returned.

The transfer of the above updated position is optional.

In response to the updateHorizon () method, the corresponding mobility horizon is then returned in the form of the respective data record via the interface 25 , In this way, a corresponding update can be made without much effort.

Based on 4 an exemplary graph is shown, which represents the respective mobility horizon, ie a data set returned via the interface.

P1 represents a respective starting location that is representative of the respective resource in relation to the transferred position. The starting point P1 may be associated with a first location information OI1, which here includes "Now, Monday 12:00, @ work".

Further, the graph includes first and second predicted locations P2, P3 associated with respective second and third location information OI2, OI3. The graph further comprises first, second and third connections L1, L2, L3 to which respective first, second, third connection information VI1, VI2, VI3 are assigned. The first and second links connect the starting location P1 to the first predicted location P2. The third connection L3 connects the starting point P1 to the second predicted location P3.

The location information may also alternatively or additionally represent one or more activities. A data structure of the data record can be predefined in particular using the so-called composite pattern.

LIST OF REFERENCE NUMBERS

1

Backend server

3

vehicle

5

mobile terminal

7

Position Determination Entity

9

gyro

11

navigation unit

13

further position determination unit

15

accelerometer

17

location-based service

21

server

23

client

25

interface

27

box

S1-S13

steps

TUP

tuple

P2-P3

first, second predicted place

P1

starting

L1-L3

first, second, third connection

OI1-OI3

first - third location information

VI1-VI3

first - third connection information

Claims (10)

Prediction method in which an interface ( 25 ) a predicted location or a plurality of predicted locations and associated location information is provided as a data set dependent on a position by means of a predetermined multimodal motion model. Prediction method according to Claim 1, in which, via the interface ( 25 ) one or more connections to the one or more predicted locations depending on the position with associated connection information by means of the multimodal motion model are provided as a record. The prediction method of claim 2, wherein the connection information comprises modality information. A prediction method as claimed in any one of claims 2 or 3, wherein the connection information comprises a duration information representative of the amount of time required to travel along the connection to the respective associated predicated location. A prediction method according to any one of claims 2 to 4, wherein the connection information comprises probability information representative of a probability that the respective connection is used. Prediction method according to one of the preceding claims, in which the interface ( 25 ) is a client API. Prediction method according to one of the preceding claims, in which provision of the data record takes place only if an authentication was previously carried out successfully. Prediction method according to one of the preceding claims, in which the deliverable type of location information and / or connection information is requested on the interface ( 25 ) provided. Prediction method according to one of the preceding claims, wherein upon a change of the predicted location (s) and / or associated location information and / or the connection (s) and / or associated connection information (s) at the interface ( 25 ) to be provided. Prediction method according to one of the preceding claims, in which, depending on a request message via the interface ( 25 ) a selection of the respective location information and / or connection information is provided.

Images