U.S. patent application number 14/122097 was filed with the patent office on 2014-07-03 for method for vehicle communication, interface module, vehicle diagnosis interface, user communication terminal, data network system and diagnosis and control network.
This patent application is currently assigned to AUGMENTATION INDUSTRIES GMBH. The applicant listed for this patent is Stephan Kaufmann, Alexander Marten. Invention is credited to Stephan Kaufmann, Alexander Marten.
Application Number | 20140189814 14/122097 |
Document ID | / |
Family ID | 46354164 |
Filed Date | 2014-07-03 |
United States Patent
Application |
20140189814 |
Kind Code |
A1 |
Marten; Alexander ; et
al. |
July 3, 2014 |
METHOD FOR VEHICLE COMMUNICATION, INTERFACE MODULE, VEHICLE
DIAGNOSIS INTERFACE, USER COMMUNICATION TERMINAL, DATA NETWORK
SYSTEM AND DIAGNOSIS AND CONTROL NETWORK
Abstract
The invention relates to a method for vehicle communication,
particularly using a vehicle-implemented vehicle diagnosis system
(3), to which a vehicle diagnosis interface (10) having an
interface connector (11), an interface module (12) and an air
interface (13) is connected, wherein for the purpose of
authentication the vehicle communication involves an authorization
code being transmitted wirelessly and the authorization code is
based on a combination of at least two codes.
Inventors: |
Marten; Alexander;
(Dusseldorf, DE) ; Kaufmann; Stephan; (Franfurt am
Main, DE) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Marten; Alexander
Kaufmann; Stephan |
Dusseldorf
Franfurt am Main |
|
DE
DE |
|
|
Assignee: |
AUGMENTATION INDUSTRIES
GMBH
Dusseldorf
DE
|
Family ID: |
46354164 |
Appl. No.: |
14/122097 |
Filed: |
May 25, 2012 |
PCT Filed: |
May 25, 2012 |
PCT NO: |
PCT/EP2012/059921 |
371 Date: |
February 12, 2014 |
Current U.S.
Class: |
726/4 |
Current CPC
Class: |
G08G 1/162 20130101;
H04L 63/0876 20130101; H04W 12/08 20130101; H04W 12/06 20130101;
G07C 5/008 20130101; G08G 1/205 20130101; H04W 12/00512 20190101;
H04L 67/12 20130101 |
Class at
Publication: |
726/4 |
International
Class: |
H04W 12/06 20060101
H04W012/06 |
Foreign Application Data
Date |
Code |
Application Number |
May 27, 2011 |
DE |
10 2011 076 638.3 |
Claims
1. A method for vehicle communication by means of a system, having
a vehicle diagnosis interface in a vehicle and a user communication
terminal that are designed for wireless communication, wherein for
the purpose of authentication the vehicle communication involves an
authorization code being transmitted wirelessly and the
authorization code is based on a combination of at least two codes,
the at least two codes being selected from the group comprising: a
vehicle code that is used for vehicle identification, a
communication code that relates to the mobile user communication
terminal, an interface code that is used for interface
identification.
2. The method as claimed in claim 1, characterized in that the
authorization code is based on two codes, namely: a code in the
form of a vehicle identification character string and/or number, a
further code in the form of a character string and/or number that
is associated with the interface module.
3. The method as claimed in claim 1, characterized in that the
authorization code is based on three codes, namely: a first code in
the form of a vehicle identification character string and/or
number, a second code in the form of a SIM character string and/or
number and/or in the form of a telephone character string and/or
number, a third code in the form of a character string and/or
number that is associated with the interface module.
4. The method as claimed in claim 1, characterized in that the
authorization code is based on at least two codes, the at least two
codes being selected from the cited group, which also comprises: a
code that is input by the user, an individual user identification
character string and/or number, an application character string
and/or number and a network identification character string and/or
number for identifying a computer and/or a user communication
terminal in the network.
5. The method as claimed in claim 1, characterized in that the
vehicle-independent center comprises one or more centers that are
selected from the group comprising: the user communication terminal
and/or the data network system and/or other data systems; a service
provider; a limited-access local area; the vehicle diagnosis system
of the cited vehicle and/or of another vehicle; a user
communication terminal that is associated with the cited vehicle
and/or with another vehicle by means of an interface module,
particularly the vehicle diagnosis interface; a roadside
installation; a user communication terminal that is associated with
a road user without an interface module, such as a pedestrian, a
cyclist or the like.
6. The method as claimed in claim 1, characterized in that the
vehicle code that is used for vehicle identification is a vehicle
registration character string and/or number and/or is a vehicle
identification character string and/or number and/or a motor
transport authority number.
7. The method as claimed in claim 1, characterized in that the
communication code that relates to the mobile user communication
terminal is a device character string and/or number of the user
communication terminal; and/or is a telephone character string
and/or number that is associated with the user communication
terminal; and/or is a SIM character string and/or number that is
associated with the user communication terminal; and/or is a
network identification character string and/or number for
identifying a computer and/or user communication terminal in a
local or regional network.
8. The method as claimed in claim 1, characterized in that the
interface code that is used for interface identification is a
character string and/or number that is associated with the
interface module.
9. The method as claimed in claim 1, characterized in that for the
purpose of authenticating the vehicle for an authorization check
the authorization code is compared with a stored code, wherein the
stored code is stored in a data network system and the
vehicle-independent center sets up an examination connection to the
data network system for the authorization check for authenticating
the vehicle.
10. The method as claimed in claim 1, characterized in that the
authorization code is used to encrypt data for the vehicle
communication.
11. The method as claimed in claim 1, characterized in that vehicle
identification is first of all effected independently of an
authorization code and then authentication is effected on the basis
of the authorization code; or the vehicle identification is
effected automatically on the basis of the authorization code,
particularly vehicle identification is effected by means of the
vehicle authentication.
12. The method for vehicle communication as claimed in claim 1,
using a vehicle-implemented vehicle diagnosis system, to which a
vehicle diagnosis interface having an interface connector, an
interface module and an air interface is connected, and in which:
vehicle-related data are transmitted to a mobile user communication
terminal and/or a data network system, and wherein the vehicle is
identified to a vehicle-independent center, characterized in that
vehicle communication with the vehicle-independent center involves
automatic authentication of the vehicle, wherein the authentication
is based on the authorization code that is transmitted
automatically during the vehicle communication.
13. The method as claimed in claim 1, characterized in that vehicle
diagnosis data from a vehicle are transmitted, particularly in
authenticated and/or encrypted form, from the vehicle-implemented
vehicle diagnosis system of the vehicle to a mobile user
communication terminal and/or a data network system via the air
interface; the vehicle diagnosis data are augmented with
supplementary data that are obtained outside the vehicle diagnosis
system, the supplementary data going beyond vehicle diagnosis data;
and the data network system makes the vehicle diagnosis data and
the supplementary data available, particularly in authenticated
and/or encrypted form, to at least one mobile user communication
terminal again.
14. The method as claimed in claim 1, characterized in that a
relevance of the supplementary data to the immediate driving
situation of the vehicle is predetermined in an instruction
specification, particularly the instruction specification is
created in an open programming environment, and the instruction
specification is compatible with the mobile user communication
terminal.
15. The method as claimed in claim 1, characterized in that a
verifiable proposal for a vehicle control function is made
following transmission of the vehicle diagnosis data and the
supplementary data back as far as to the vehicle diagnosis
interface.
16. An interface module for integration in or for connection to a
vehicle diagnosis interface that, furthermore, has an interface
connector and/or an air interface, designed for implementing the
method as claimed in claim 1, having: a memory and a logic unit,
wherein the memory is designed to hold at least two codes selected
from a group of codes comprising: a vehicle code that is used for
vehicle identification, a communication code that relates to the
mobile user communication terminal, an interface code that is used
for interface identification; and the logic unit is designed: to
generate an authorization code on the basis of a combination of at
least two codes selected from the cited group of codes, and vehicle
communication with the vehicle-independent center involving
automatic authentication of the vehicle; and a transmission device
is designed: to transmit the authorization code during the vehicle
communication, the authentication being based on the authorization
code.
17. The interface module as claimed in claim 16, characterized in
that the logic unit is designed to execute a software module with
an instruction protocol for implementing an instruction
specification, wherein the instruction specification is designed to
predetermine relevant supplementary data for the immediate driving
situation of the vehicle, and the memory is designed to store the
vehicle diagnosis data and/or the relevant supplementary data.
18. A vehicle diagnosis interface having an interface connector, an
air interface and having an interface module as claimed in claim
16, characterized in that the interface connector is a connector
for a vehicle control network, particularly is an OBD connector or
an SAE connector or RJ connector.
19. A user communication terminal, designed for participation in a
method as claimed in claim 1 and for receiving vehicle diagnosis
data from a vehicle from a vehicle-implemented vehicle diagnosis
system of the vehicle by an air interface and/or from a data
network system, characterized in that the user communication
terminal is designed to carry out the method steps of the
characterizing part of claim 1 and to execute an instruction
specification on the user communication terminal.
20. A data network system designed for receiving vehicle diagnosis
data from a vehicle from a vehicle-implemented vehicle diagnosis
system of the vehicle and/or via a mobile user communication
terminal via an air interface, characterized in that the data
network system is designed to carry out the method steps of the
characterizing part of claim 1 and to execute an instruction
specification on the data network system, particularly for holding
the authorization code.
21. A diagnosis and control network, particularly having a
multiplicity of vehicles each having a vehicle-implemented vehicle
diagnosis system and a vehicle diagnosis interface, which has an
interface connector, an interface module and an air interface for
the vehicle-implemented vehicle diagnosis system of the respective
vehicle, comprising: a communication network, via which vehicle
diagnosis data can be transmitted to a data network system, and
wherein vehicle-related data can be transmitted to a mobile user
communication terminal and/or a data network system, and wherein
the vehicle can be identified to a vehicle-independent center,
designed such that vehicle communication with the
vehicle-independent center involves automatic authentication of the
vehicle, wherein the authentication is based on an authorization
code that is transmitted automatically during the vehicle
communication, and wherein the authorization code is based on a
combination of at least two codes, the at least two codes being
selected from the group comprising: a vehicle code that is used for
vehicle identification, a communication code that relates to the
mobile user communication terminal, an interface code that is used
for interface identification.
Description
[0001] The invention relates to a method for vehicle communication
by means of a system, having a vehicle, via a vehicle diagnosis
interface. The invention also relates to an interface module for a
vehicle diagnosis interface and to the vehicle diagnosis interface.
In addition, the invention relates to a user communication
terminal, a data network system and a diagnosis and control network
for a multiplicity of vehicles.
[0002] Vehicle diagnosis systems that are limited to vehicle
diagnosis, such as an onboard diagnosis system (OBD system), are
known. During driving, all systems, particularly those that
influence exhaust gases, are monitored, and also additionally
further important controllers such as temperature controllers or
the like, the data of which are accessible through their software.
Errors that occur are indicated to the driver by means of a warning
light and are permanently stored in the respective controller.
Error reports can then be requested later by a technical workshop
using standardized interfaces or suchlike vehicle diagnosis
interfaces.
[0003] What are known as OBD diagnosis interfaces are also known
that--as can be gleaned from the website www.obd-2.de for
example--can use a Bluetooth or suchlike air interface to couple to
the vehicle diagnosis interface in order to make vehicle diagnosis
data available for a smartphone, Android or pocket PC or suchlike
mobile user communication terminal. Such devices dispense with the
need to go to the workshop, but are limited to making only the
vehicle diagnosis data available to the vehicle driver and user of
the mobile user communication terminal. A problem with such devices
is simply the flexibility with regard to usability with reference
to the vehicle diagnosis interface. Although the errors or other
codes of the vehicle diagnosis data are standardized (ISO Standard
15031-6), the protocol for transmitting them is not. Therefore, it
has also been necessary to date for a separate OBD interface,
separate from mobile user communication terminals, still to be
limited to a particular interpreter chip (e.g. ELM327).
[0004] US 2010/0210254 A1 discloses a system that restricts the use
of a mobile user communication terminal, coupled to a vehicle
diagnosis interface in this manner, for particular driving
situations for the vehicle. Thus a piece of blocking software may
be designed to receive vehicle diagnosis data and to block the
operation of at least one communication function of the mobile user
communication terminal on the basis of the received vehicle
diagnosis data. This may be an increased speed or a switching
process or suchlike result of a vehicle diagnosis, for example.
[0005] US 2010/0256861 discloses a system for monitoring the
integrity status of a vehicle using a vehicle monitoring computer
system and a mobile telephone that can receive a piece of
diagnostic information relating to a vehicle from a vehicle. This
is also intended to be used to automatically determine a severity
status for vehicle states on the basis of predefined severity
status values, and if the severity status exceeds a predefined
severity threshold value for any of the vehicle states then a text
message is intended to be automatically transmitted to the mobile
telephone. In this case, a vehicle identification number (FIN) or
an identification for the mobile telephone (PIN) is able to be
implemented in a suitable data packet. The mobile telephone in the
system is wirelessly connected to the vehicle or to its environment
and can communicate with the environment, for example, via a
communication network or an Internet, in order to transmit vehicle
diagnosis data to the network. This allows the data to be
evaluated, whether by the vehicle keeper and mobile telephone user
from an external center or whether by a control center belonging to
third parties. The mobile telephone and the CPU of the vehicle
controller can enter a paired state using Bluetooth in this case
without the need for user intervention, which means the vehicle
diagnosis data are transmitted automatically.
[0006] The aforementioned diagnosis connections coupled to a
vehicle-implemented vehicle diagnosis system by air interfaces are
limited to the evaluation of vehicle diagnosis data that, in this
respect, can be transmitted in an uplink--from the
vehicle-implemented vehicle diagnosis system to the mobile user
communication terminal--only unidirectionally. The systems are
limited either to restricting the communication function of the
mobile user communication terminal as a result of the vehicle
diagnosis data, as in US 2010/0210254 A1, or else to transmitting a
message to the mobile user communication terminal merely for the
purpose of informing the user of the mobile user communication
terminal, as in US 2010/0256861, who is not necessarily the vehicle
driver. Such systems are limited to merely rendering the pure
vehicle diagnosis data transparently visible to a mobile telephone
user and possibly to dispensing with the need to go to the
workshop.
[0007] US 2008/0015748 A1 discloses a system and method for
representing and analyzing vehicle diagnosis data from a vehicle
diagnosis interface that has, inter alia, an air interface coupling
to a mobile user communication terminal, which means that the
vehicle diagnosis data can be transmitted wirelessly. In this case,
in addition to the vehicle diagnosis data, geographical position
data are also transmitted from the vehicle diagnosis interface to
the mobile user communication terminal or a navigation device and
forwarded to an Internet server or a Wide Area Network (WAN). Thus,
the data can be inspected by end users or software applications can
gain access to such data in a manner automated by a program. Such a
software application may be coupled to the mobile user
communication terminal only from a network in dynamically
configurable fashion. The vehicle diagnosis data can be made
available to an authorized user, namely a recovery service.
[0008] This system is also limited to a unidirectional connection
within the context of an uplink--for a vehicle-implemented vehicle
diagnosis system to the mobile user communication terminal--in
order to spur on an action from external authorized users on the
basis of an analysis that uses the vehicle diagnosis data.
[0009] It is desirable for such aforementioned diagnosis systems
and diagnosis networks extended by means of a vehicle-implemented
vehicle diagnosis system--which are ultimately based only on
vehicle diagnosis data--to be substantially improved, particularly
in terms of their functionality and their data basis.
[0010] This is the starting point for the invention, the object of
which is to specify a method and an apparatus--particularly an
interface module, a vehicle diagnosis interface and a diagnosis
network--that is improved beyond an extended diagnosis of vehicle
data as cited at the outset. In particular, the aim is for a
functionality of the method and of the apparatus to be
substantially improved. In particular, the aim is for the data
basis of such a method and of such an apparatus to be substantially
improved.
[0011] The object concerning the method is achieved by a method,
particularly of the type cited at the outset, in which the features
of claim 1 are provided.
[0012] In the case of a method for vehicle communication, having an
interface module that is designed for wireless communication, the
invention provides that for the purpose of authentication the
vehicle communication involves an authorization code being
transmitted wirelessly and the authorization code is based on a
combination of at least two codes, the at least two codes being
selected from the group comprising: [0013] a vehicle code that is
used for vehicle identification, [0014] a communication code that
relates to the mobile user communication terminal, [0015] an
interface code that is used for interface identification.
[0016] Advantageous developments of the invention can be found in
the subclaims and provide a detailed specification of advantageous
possibilities for implementing the concept explained above for the
statement of the object and in respect of further advantages.
[0017] With particular preference, the authorization code in a
first variant is based on two codes, namely: [0018] a code in the
form of a vehicle identification character string and/or number
(FIN/VIN), [0019] a further code in the form of a character string
and/or number that is associated with the interface module.
[0020] With particular preference, the authorization code in the
second variant is based on three codes, namely: [0021] a first code
in the form of a vehicle identification character string and/or
number (FIN/VIN), [0022] a second code in the form of a SIM
(subscriber identification module) character string and/or number
and/or a telephone character string and/or number, [0023] a third
code in the form of a character string and/or number that is
associated with the interface module.
[0024] Advantageously, the authorization code is based on at least
two codes, the at least two codes being selected from the group
furthermore comprising: a code that is input by the user, an
individual user identification character string and/or number, an
application character string and/or number and a network
identification character string and/or number (IPv4, IPv6) for
identifying a computer and/or a user communication terminal in the
network. A code that is input by the user may be a numerical code
or a scanned code, e.g. a 2D code or an image or the like. The code
used may also be voice recognition or photograph recognition. It is
also possible for a user code/ID/hash from a user database of the
data network system, in which user database the user can enter his
personal data, to be brought in as a part.
[0025] The concept of the invention is found to be particularly
advantageous within the framework of a development according to the
method of claim 12.
[0026] Preferably, but not necessarily, the mobile user
communication terminal is associated with the vehicle, in
particular is known to the vehicle diagnosis system of the vehicle
or at least to the vehicle diagnosis interface. In principle, the
mobile user communication terminal does not initially need to be
known to the vehicle, such as an automobile. Preferably, however,
the vehicle and the mobile user communication terminal are known to
the vehicle diagnosis interface--also called an adapter. Also
preferably, but not necessarily, the adapter is known to the mobile
user communication terminal and to an application. All known
devices are stored in a database of the data network system and
reported to the system. Preferably, the mobile user communication
terminal is associated with the vehicle by means of the interface
module; in particular i.e. in the connected case by means of the
vehicle diagnosis interface, with an interface connector, the
interface module and an air interface. By way of example, the air
interface can be used to set up a fixed wireless communication link
(pairing) between the mobile user communication terminal and an
interface (e.g. an OBD or SAE interface) of the vehicle diagnosis
system. It is also possible for vehicle diagnosis data from a
vehicle to be transmitted from the vehicle-implemented vehicle
diagnosis system of the vehicle via the air interface to a
preferably but not necessarily predeterminedly stipulated number of
multiple mobile user communication terminals; by way of example
these can also be stipulated on the basis of situation by a vehicle
driver or other user. It is also possible to send to an unknown
number that is not associated with the vehicle. In principle, it is
not necessary for the associated mobile user communication
terminal(s) to be located in the vehicle. However, it has been
found to be advantageous for the purpose of monitoring, diagnosis
and communication in respect of the vehicle functions if an
associated mobile user communication terminal is located in the
vehicle. In particular, the method is found to be particularly
effective when information available via the user communication
terminal is available from the vehicle driver or a vehicle
occupant, particularly just a single user communication terminal,
preferably belonging to the vehicle driver, in addition to the
cockpit indicators in the vehicle.
[0027] Preferably, provision is made for [0028] the vehicle to be
identified to a vehicle-independent center; [0029] the vehicle
communication with the vehicle-independent center to involve
automatic authentication of the vehicle, wherein [0030] the
authentication is based on an authorization code that is
transmitted automatically during the vehicle communication.
[0031] According to the concept, in this case too, the
authorization code is based on a combination of at least two codes,
the at least two codes being formed from the group comprising:
[0032] a vehicle code that is used for vehicle identification,
[0033] a communication code that relates to the mobile user
communication terminal; [0034] an interface code that is used for
interface identification.
[0035] Preferably, the authorization code is based on the
combination of at least two codes when the at least two codes are
used in some way to generate the authorization code from the at
least two codes. This may be mere juxtaposition of the at least two
codes. In methods that have been developed further, this may also
be an expedient type of algorithmic use of the at least two codes
for generating a totally new authorization code. By way of example,
a first of the two codes can be used as a random number generator
in order to obtain the authorization code from a second of the two
codes by means of permutation or otherwise. These are just
examples, however, to clarify the broad applicability of the two
codes for generating the authorization code. In the broadest sense,
an authorization code is based on the at least two codes when the
at least two codes are used reproducibly in some way to determine
the authorization code.
[0036] The development is based on the consideration that reliable
vehicle communication is improved if, besides a mere origin and
association of the data, it is particularly possible to
authenticate even subjective reliability of the data provenance,
not only within the system comprising user communication terminal,
possibly data network system, vehicle and interface module, but
particularly furthermore with regard to third vehicle-independent
centers, such as service providers or the like. The invention has
recognized that a combination of at least two codes is suitable for
this, said codes being able to be associated with at least two of
the three, possibly four, essential components of the
system--namely vehicle, vehicle diagnosis interface and user
communication terminal, possibly even data network system. This
results in an authorization code with a high, even subjective,
reliability measure, which means that it can be used not just for
authentication, but rather can furthermore be used as a basis for
further stages of vehicle communication that may be based on the
reliability measure. Preferably, the driver of a vehicle can even
be identified by means of one or more of said details, particularly
in conjunction with a known combination of FIN, telephone number
and user ID.
[0037] By way of example, this may relate to the fundamental
provision of services and/or to the billing options for services
provided. The invention has recognized that authentication with an
authorization code that is made up of codes that inherently have
high reliability measure as a basis allows not only simple exchange
of information but furthermore an extensive range of higher
communication levels in the vehicle communication.
[0038] In particular, the development has recognized that it is
possible to generate an authorization code that is based on at
least two codes that have already been checked. The two codes
selected from the inventive group contain particularly a
qualification for a high subjective reliability measure, which
qualification is inherently sufficient for the "vehicle and vehicle
keeper" combination. Hence, higher expansion levels of vehicle
communication are also accessible more easily and in automated
fashion. In particular, in a higher or downstream level of vehicle
communication, a further authorization check can be mostly
dispensed with following a single authentication with the
authorization code; this is because this has already occurred at
the commencement of the vehicle communication by virtue of
authentication with the authorization code, on the basis of the
inventive concept.
[0039] Advantageously, the development has recognized that it is
beneficial to a system of vehicle communication that, in this case,
may particularly be of open design if the actual input
authentication is based on an authorization code with a high
reliability measure.
[0040] Preferably, the vehicle-independent center comprises one or
more centers that are selected from the group comprising: the user
communication terminal and/or the data network system, a service
provider, a limited-access local area, the vehicle diagnosis system
of the cited vehicle and/or of another vehicle, a user
communication terminal that is associated with the cited vehicle
and/or with another vehicle by means of an interface module (12),
particularly the vehicle diagnosis interface (10); a roadside
installation (RoadSideEquipment, RSE); a user communication
terminal that is associated with a road user without an interface
module, such as a pedestrian, a cyclist or the like.
[0041] Particularly the aforementioned centers--namely a service
provider, a limited-access local area and a vehicle diagnosis
system and/or user communication terminal that is associated with a
vehicle other than the cited vehicle--can, in the present case, be
denoted as third vehicle-independent centers outside the core
components of the existing diagnosis and control network. They are
situated outside the cited vehicle and the diagnosis interface
associated with the cited vehicle and the user communication
terminal associated with the cited vehicle. Particularly the
authentication to such a third center outside the existing core
components needs to satisfy an increased measure of objective and
subjective reliability.
[0042] Independently of this, an authorization code according to
the concept is also suitable for use within the existing diagnosis
and control network with the cited vehicle, the diagnosis interface
associated therewith and the user communication terminal associated
therewith. By way of example, the authorization code can be used in
order to authenticate or identify oneself to the data network
system of the diagnosis and control network.
[0043] In principle, at least any desired combination of two of the
three codes cited according to the concept is suitable, namely at
least any desired combination of two, selected from vehicle code,
communication code and interface code; if need be, it is also
possible to use a code from the data network system as well. Thus,
within the framework of a first particularly preferred variant, an
authorization code as a combination of two comprising vehicle code
and communication code has been found to be simple and reliable. In
principle, in a second variant, the combination of two comprising
communication code and interface code is also suitable. In
principle, the combination of two comprising interface code and
vehicle code is also suitable. Within the framework of a
particularly reliable variant, an authorization code may be based
on the vehicle code, the communication code and the interface code;
the aforementioned development using a combination of three of the
codes from the group takes account of every core component of the
existing diagnosis and control network, namely the components of
the vehicle, of the vehicle diagnosis interface associated with the
vehicle and the user communication terminal associated with the
vehicle. Within the framework of the development, the
aforementioned combination of three also allows a particularly
great opportunity for variance, for example when the same vehicle
is used by different users with different user communication
terminals. In such cases and in similar cases, a logic unit may be
designed to generate an authorization code on the basis of a
combination of at least two codes, selected from the cited group of
codes, particularly on the basis of three codes from the cited
group. In the case of the cited combination of three, two different
authorization codes would be generated if the same vehicle with the
same vehicle diagnosis interface were to be used by a first driver,
e.g. the keeper of the vehicle, with a first user communication
terminal and a second driver with a second user communication
terminal. In most cases, this is also found to make sense, since,
by way of example, the keeper of the vehicle may admittedly have
different authorizations and credits, particularly a different
reliability level, than a driver of the vehicle who is, however,
not the keeper and is the owner of the second user communication
terminal.
[0044] In principle, however, it is possible for all the
aforementioned developments to be implemented realistically, with
the high measure of subjective reliability inherent to the
authorization code that has been explained for the concept of the
invention.
[0045] Within the framework of a particularly preferred
development, the vehicle code that is used for vehicle
identification is a vehicle identification character string,
particularly a motor transport authority number (KBA No.) and/or a
vehicle identification number, which is also known per se by the
abbreviation VIN (in German: FIN) and is explicitly associated with
a respective vehicle. In principle, the vehicle registration
character string and/or number is suitable in a similar manner.
However, it has been found that the vehicle identification
character string and/or number has a longer existence on average
than the vehicle registration character string and/or number, for
example. The length of the existence of the vehicle code used also
has an associated higher measure of data reliability.
[0046] Within the framework of a particularly preferred
development, the communication code may be a SIM character string
and/or number that is associated with the user communication
terminal. It has been found that a SIM character string and/or
number also has a comparatively long existence and hence is
beneficial to a reliability measure. Furthermore, it can be assumed
that subjective properties of a keeper of the user communication
terminal when there is a SIM character string and/or number
available with a long existence are also a quality feature for the
user. Equally, a telephone character string and/or number that is
associated with the user communication terminal is suitable. The
telephone number is allocated via the network provider.
Alternatively, an IP address for the smart phone in the network can
be used. A network identification character string and/or number
(IPv4, IPv6) for identifying a computer and/or a user communication
terminal in a local or regional network is also suitable in
principle. In principle, it is also possible to use other
opportunities for a communication code in so far as said
communication code can be associated with the user communication
terminal in some way. By way of example, the device character
string and/or number (IMEI) of the user communication terminal or a
telephone character string and/or number that is used on the user
communication terminal are also suitable.
[0047] Within the framework of a particularly preferred
development, the interface identification is provided by means of
an interface code that is associated with the interface module and
contains an appropriate character string and/or number. In
principle, in addition or as an alternative to the interface code,
it is also possible to use a code that is associated with the
vehicle diagnosis system, for example a code from the diagnosis
system interface, that is to say a code from the OBD-II interface
or the like.
[0048] Within the framework of a development that is described as
particularly preferred in the embodiment of the drawing, an
authorization code that is based on a combination of precisely
three or more than three codes has proved itself, the three codes
comprising: the vehicle identification number (VIN, or FIN in
German), the SIM (subscriber identification module) number that is
associated with the user communication terminal and a number and/or
character string that is associated with the interface module. As
an alternative to the SIM, it is possible to use the telephone
number. In a particularly preferred development, in addition to the
three codes (VIN, SIM or telephone number, interface module
number), there may also be a user code provided as a fourth
code.
[0049] Against this background, within the framework of the concept
of the invention, there is also claimed, in principle, a method for
vehicle communication, particularly using a vehicle diagnosis
interface that can be connected to a vehicle-implemented vehicle
diagnosis system, having an interface module that is designed for
wireless communication, wherein the vehicle communication involves
an authorization code being transmitted wirelessly for
authentication. Preferably, the authorization code is based on a
vehicle identification character string and/or number (FIN, VIN), a
SIM (subscriber identification module) character string and/or
number and a character string and/or number that is associated with
the interface module.
[0050] Advantageously, for the purpose of authenticating the
vehicle an authorization code generated in this manner can be
compared with a stored or generated code, or aligned with a
reference in another appropriate manner, for an authorization
check. In this case, it is found that, by way of example, two codes
from the group of codes cited according to the concept can be used
for generating an authorization code and the third in the group can
be used as a stored code. The stored code thus does not necessarily
need to be of the same type as the authorization code. Instead, the
authorization code and the stored code can be used in the manner of
a key/lock principle; in this respect, comparison of authorization
code and stored code can be understood broadly in the sense of
"matching to one another".
[0051] Preferably, the stored code is stored in the data network
system, and the vehicle-independent center is capable of setting up
an examination connection to the data network system for the
authorization check for authenticating the vehicle. By way of
example, it is thus possible for the stored code to be stored in
the data network system, and an association with a particular
authorization code. If a vehicle now needs to be authenticated to a
vehicle-independent center, the third center or another center can
set up an examination connection to the data network system and
request the association. If the authorization code and the stored
code match, this can be called a positive comparison and the
authentication of the vehicle can be concluded with a positive
outcome.
[0052] To increase data integrity, the authorization code can be
used for the vehicle communication for data encryption.
[0053] In principle, the authorization code may be a firmer code.
In one variant, the authorization code may also be a temporary
code. The authorization code may also be a variable code; e.g. by
virtue of a basic code being based on at least two codes selected
from the group comprising: a vehicle code that is used for vehicle
identification; a communication code that relates to the mobile
user communication terminal and an interface code that is used for
interface identification. The basic code may be able to be
augmented on a variable basis with a user code or an application
code or another code from the group furthermore comprising: a code
that is input by the user, an individual user identification
character string and/or number, an application character string
and/or number and a network identification character string and/or
number (IPv4, IPv6) for identifying a computer and/or a user
communication terminal in the network.
[0054] Particularly preferably suitable is a user ID (user code)
that is associated with a user profile, an adapter ID (interface
code) that is in turn associated with at least one user and
possibly with a vehicle, or a telephone number (communication code)
that is associated with at least one user and possibly with a
vehicle.
[0055] For a particularly secure application, the generation of the
authorization code on the basis of six codes (particularly vehicle
ID, connector ID, telephone ID, network ID, app ID, user ID) has
been found to be advantageous.
[0056] As a communication network with a long range, a cellular
communication network for mobile communication, e.g. on the basis
of a GPRS, UMTS or LTE technology or such like 2G, 3G standard,
etc., is particularly suitable. In one preferred variant, vehicle
identification is first of all effected independently of an
authorization code and then authentication is effected on the basis
of the authorization code. Furthermore, in another variant, it has
been found to be particularly advantageous for vehicle
identification to be effected automatically on the basis of the
authorization code. This has the advantage that the vehicle
identification and the actual vehicle authentication no longer need
to take place as separate processes, but rather the identification
and authentication of the vehicle coincide; by way of example, they
are implemented with the comparison of stored code and
authorization code. The comparison of authorization code and stored
code does not necessarily have to be effected directly; instead, it
is also possible for an indirect comparison to be effected such
that, by way of example, an authorization code is provided with an
association and a comparison is actually positive if the
association matches a stored code or matches an association of the
stored code.
[0057] In general, it has been found to be advantageous, for
example for carrying out an authentication or authorization method,
for an authorization code for a combination of vehicle, vehicle
diagnosis interface and user communication terminal to be
generated, according to the concept of the invention, from at least
two codes from the cited group, and for the vehicle to be
identified and authenticated by means of the authorization code in
the case of a service request, and for a service to be provided in
the event of positive authentication or authorization. The cited
method has the advantage that, on account of the high subjective
degree of reliability of the inventive authorization code, it is
also advantageously possible for the service to be actually
provided. That is to say that since the party requesting
authorization for the service is found to be sufficiently reliable
with its authorization code, the service provider can assume
that--even within the framework of the automated method--the
service can be provided in advance, since the requesting party has
sufficient "credit". In the case of a parking space request, a
fuelling request or suchlike services that hold a value, for
example, this may be a decisive time advantage during handling that
ultimately benefits the user and the service provider. The party
requesting the service has time advantages and the service is
provided independently of the actual billing or compensation for
the service. The omission of cash logistics is also already an
advantage over previous payment systems.
[0058] The concept of the invention and the aforementioned
developments also present an interface module of 16, which is
designed to implement the method according to claim 1, particularly
according to claim 12. In particular, the interface module has a
memory and a logic unit that are designed to implement the
method.
[0059] The concept of the invention also presents an interface
connector having the interface module. The concept of the invention
also presents a user communication terminal that is designed for
participation in the inventive method or one of the
developments.
[0060] The concept of the invention also presents a data network
system according to claim 20, which is designed for receiving
vehicle diagnosis data, wherein particularly preferably the data
network system can be communicatively connected to a
vehicle-independent center for examination authorization for an
authorization code.
[0061] The concept of the invention also presents a diagnosis and
control network according to claim 21, particularly having the core
components of a vehicle, a vehicle diagnosis interface and a user
communication terminal. Furthermore, the diagnosis and control
network advantageously has the data network system and also the
vehicle-independent center, particularly a third
vehicle-independent center.
[0062] The diagnosis and control network is suitable for the
connection of proprietary, public or state data systems that,
particularly for an examination authorization request, transmit an
authorization code to the data network system, which then compares
this authorization code with a stored code and returns a positive
or negative response pertaining to the authorization code to the
connected data systems of the center, particularly of the third
center.
[0063] In such or similarly preferred manners, it is possible for a
multiplicity of everyday services, such as a search for a parking
space, fuelling, special rights for sensing club memberships or the
like, to be automated on the basis of the concept for
authentication on the basis of the inventive authorization
code.
[0064] In particular, the method of vehicle communication with a
vehicle-independent center is suitable for vehicle communication
not just with a vehicle-independent center (car-2-X) but also with
a center that is formed by other vehicles (N-2-N). In particular,
the vehicle communication can be definitively supported by vehicle
diagnosis data and/or by supplementary data that are obtained
outside the vehicle diagnosis system. Such and other data can be
provided via the data network system, the user communication
terminal and the vehicle diagnosis system, but also by third
centers (car-2-X centers) or other vehicles (N-2-N centers). This
supplementary information can firstly prompt the provision of
particular services but can also prompt the nonprovision of
particular services. By way of example, in the case of
authentication that is proceeding positively, in principle, during
a search for a parking space, the service of providing a parking
space can nevertheless be refused if it is known on the basis of
the vehicle diagnosis data that an exhaust system on the vehicle is
defective. On the other hand, in the same situation cited above
with authentication of the vehicle proceeding positively, it would
simultaneously be possible to offer and/or to fix a time for a
visit by the vehicle to a garage in the relatively close
vicinity.
[0065] Such and other opportunities exist particularly within the
framework of the developments explained below for making available
supplementary data, obtained outside the vehicle diagnosis system,
that are particularly suitable for augmenting vehicle diagnosis
data.
[0066] With particular preference, provision is made for [0067] the
vehicle diagnosis data to be augmented with supplementary data that
are obtained outside the vehicle diagnosis system, [0068] a
relevance of the supplementary data to the immediate driving
situation of the vehicle to be predetermined in an instruction
specification.
[0069] In particular, the vehicle diagnosis data and the
supplementary data can be transmitted back as far as to the vehicle
diagnosis interface, but in one variant also just as far as the
mobile communication terminal.
[0070] Preferably, a diagnosis and control network is of
appropriate design. A user communication terminal and/or the data
network system and/or the vehicle diagnosis interface is/are of
appropriate design to augment the vehicle diagnosis data with
supplementary data that are obtained outside the vehicle diagnosis
system.
[0071] By way of example, the instruction specification, which can
preferably be created in an open programming environment, may be a
software application or another interpreter that can be used
without restriction by a user of the mobile user communication
terminal or a user of the communication network. In particular, a
preferably open programming environment contains an interpreter
that is compatible with an operating system of the mobile user
communication terminal. By way of example, this may be an
interpreter version for an iPad, an Android, a Blackberry (RIM) or
a Windows device. By way of example, the open programming
environment may be compatible with operating systems such as iOS,
WINDOWSmobile, BADA, RIM OS or the like. In particular, a
communication network is intended to be understood to mean the
Internet or a mobile communication network and also possibly a WAN
(Wide Area Network--network that extends over long distances and is
bounded neither in terms of geographical range nor in terms of the
number of computers) or LAN (Local Area Network--network
(particularly wireless) that is locally/geographically limited
(approximately 500 m)). It is also possible to use Personal Area
Networks (PAN) or what are known as WiFi networks and what are
known as PicoNets, which can be set up and cleared down on an ad
hoc basis by small devices such as PDAs or mobile telephones; in
particular, wireless networks such as WLAN, WPAN, WiFi networks are
advantageous.
[0072] Developments also present an interface module and a vehicle
interface. In particular, the interface connector is an OBD
connector (particularly based on OBDII or OBDIII) or an SAE
connector. The interface in the form of a CARB or OBD socket is in
turn connected precisely to the ZGW by means of CAN and in future
by means of Ethernet (DoIP), e.g. by means of an RJ connector. The
vehicle diagnosis interface that is yet to be explained can be
customized and appropriately coupled to this and other types of
interfaces of the vehicle diagnosis system using a compatible
interface connector and is accordingly also sometimes called an
adapter here for short.
[0073] In the case of a preferred interface module, the logic is
designed to implement an instruction specification that is created
in a preferably open programming environment and that is compatible
with the mobile user communication terminal, wherein the
instruction specification is designed to predetermine relevant
supplementary data for the immediate driving situation of the
vehicle.
[0074] In the case of the preferred interface module, the memory is
designed to store the vehicle diagnosis data and/or the relevant
supplementary data, wherein the interface module can be connected
to or integrates an interface connector and/or an air interface of
the vehicle diagnosis interface.
[0075] In other words, the vehicle diagnosis data and the
supplementary data are stored on the interface module of the
vehicle diagnosis interface and can be communicated
bidirectionally, i.e. in an uplink to the mobile user communication
terminal and a downlink from the mobile user communication
terminal, via the interface module with a vehicle controller and an
external environment. Preferably, the vehicle diagnosis data and
the supplementary data are stored only on the interface module,
which means that the interface of the vehicle diagnosis interface,
which interface exists in the form of a connector per se, does not
need to be altered as such in principle. Nevertheless, both the
supplementary data and the vehicle diagnosis data enhanced with the
supplementary data are therefore available--via the interface
module--on the vehicle diagnosis interface again, that is to say
are available to the vehicle-implemented vehicle diagnosis system
and also to the vehicle controller.
[0076] Essential aspects of the concept of the particularly
preferred development therefore go beyond direct or indirectly
extended mere vehicle diagnosis just on the basis of vehicle
diagnosis data.
[0077] In relation to a first aspect, the particularly preferred
development has recognized that vehicle diagnosis data can in
various respects also be augmented with supplementary data obtained
outside the vehicle diagnosis system. As recognized by the
invention, the database of the diagnosis and control network or of
the method for vehicle diagnosis is substantially extended and can
be used in order to allow not just extended vehicle diagnosis but
furthermore to take on a specific control function that is
advantageous to the vehicle keeper.
[0078] To this end, a second aspect of the particularly preferred
development provides that the vehicle diagnosis data and
supplementary data are transmitted back as far as to the vehicle
diagnosis interface. The connection between a mobile user
communication terminal and the vehicle diagnosis interface is
preferably bidirectional in terms of the data transmission. Vehicle
diagnosis data can be transmitted (within the context of an uplink)
from the vehicle diagnosis interface to the mobile user
communication terminal. Furthermore, not just these vehicle
diagnosis data but also particularly vehicle diagnosis data
enhanced with suitable supplementary data can be transmitted from
the mobile user communication terminal (within the context of a
downlink) to the vehicle diagnosis interface, however. The vehicle
diagnosis system and/or a vehicle controller has/have access to the
supplementary data too and can introduce measures of vehicle
control that are based thereon if necessary. By way of example,
this allows a template--e.g. from an application APP, a third-party
provider or the data network system, explained here in principle,
or suchlike infrastructure element, or from the interface module
itself as part of the vehicle diagnosis interface with an interface
connector, an interface module and an air interface.
[0079] The concept of the development is not just limited to pure
vehicle diagnosis but also goes beyond this. The concept is
directed at extended vehicle control using the vehicle diagnosis
data and also supplementary data that are relevant thereto, that
are obtained externally to the vehicle diagnosis system (e.g. via
what is known as RoadSideEquipment RSE) and are made available to
the vehicle controller via the mobile user communication terminal,
inter alia.
[0080] The relevance of the supplementary data to the immediate
driving situation of the vehicle is predetermined in an instruction
specification.
[0081] As recognized by one particularly preferred development, the
instruction specification is particularly advantageously able to be
created in an open programming environment and is compatible with
the mobile user communication terminal. This firstly overcomes
previous compatibility problems regarding the transmission
protocol. Secondly, any software application or suchlike computer
program product that implements the instruction specification is
comparatively simple to create in the open programming environment.
By way of example, a user of the mobile user communication terminal
can use comparatively simple programming instructions to create an
instruction specification individually customized to him on a
mobile user communication terminal.
[0082] The logic unit of a vehicle diagnosis interface is of
appropriate design to implement an instruction specification that
predetermines the relevance of the supplementary data to the
immediate driving situation of the vehicle. In particular, the
logic unit of the interface module is designed to execute a
software module with an instruction protocol (application protocol
interface, API) for implementing an instruction specification. The
memory of an interface module is of appropriate design to store
vehicle diagnosis data and/or relevant supplementary data and to
hold them for a vehicle diagnosis system and/or vehicle
control.
[0083] Preferably, data pertaining to the static data network
system are transmitted via a long range communication network
and/or data pertaining to the mobile vehicle diagnosis interface
from the vehicle are preferably transmitted via a shorter range
communication network. Preferably, it is possible for [0084]
vehicle diagnosis data and/or supplementary data to be transmitted
between the mobile user communication terminal and/or between the
vehicle diagnosis interface, on the one hand, and the data network
system, on the other hand, via a communication network,
particularly an Internet. In addition or alternatively, it is
possible for [0085] vehicle diagnosis data and/or supplementary
data to be transmitted between the mobile user communication
terminal, on the one hand, and the vehicle diagnosis interface, on
the other hand, via a communication network, particularly a local
area network, such as a WiFi or LAN network. It is also possible to
use personal area networks (PAN) or what are known as WiFi networks
and what are known as PicoNets, which can be set up and cleared
down on an ad-hoc basis by small devices such as PDAs or mobile
telephones; in particular wireless networks such as WLAN, WPAN,
WiFi networks, are advantageous.
[0086] Preferably, data enhancement and/or buffering can take place
at any communication node. In particular, supplementary data and/or
data buffering of at least the supplementary data, particularly
also of the vehicle diagnosis data, can take place on at least one
of the components that are selected from the group consisting of:
vehicle diagnosis interface, user communication terminal, data
network system, proprietary data systems and open data systems. In
particular, the interface module and/or the vehicle diagnosis
interface is/are designed to perform data enhancement. Preferably,
the supplementary data from the interface module comprise at least:
time of day and date; in particular also comprise location data,
preferably obtained from a communication network, a global
positioning system (GPS) or the like, location time data,
particularly in the form of uninfluenced supplementary data that
are in the form of substantiation data for verifying a vehicle time
and/or location.
[0087] A user communication terminal and/or the data network system
are of appropriate design to augment the vehicle diagnosis data
with supplementary data that are obtained outside the vehicle
diagnosis system.
[0088] The vehicle diagnosis data and the supplementary data
obtained outside the vehicle diagnosis system are associated with
one another by means of the filter action determined for the
immediate driving situation of the vehicle in an instruction
specification. In principle, the vehicle diagnosis data and the
supplementary data obtained outside the vehicle diagnosis system
can be communicated independently of one another and/or can be
communicated for different components of a diagnosis and control
network. It has also been found to be advantageous to communicate
the vehicle diagnosis data and the supplementary data obtained
outside the vehicle diagnosis system in a data packet, particularly
in a data packet that fully or partly contains the vehicle
diagnosis data and supplementary data associated with one another
by means of the instruction specification.
[0089] Advantageously, the vehicle diagnosis data are ascertained
and enhanced in real time and continuously, which allows
particularly good support for the vehicle driver in an immediate
driving situation. In the broader sense, continuous is intended to
be understood to mean any process that works on ascertaining and
enhancing the vehicle diagnosis data in a manner appropriate to the
situation. When a data connection has been interrupted owing to the
situation, a continuous process may provide for buffer storage of
all or relevant data, for example, so that an event or important
events is/are not lost. Such a process runs in real time when an
interrupt to the data update is sufficiently quick in comparison
with a change in the driving situation. An interrupt may be
designed to have a fundamentally short clock rate in the sub-Hz
range, as are customary for communication networks. Nevertheless,
an interrupt may also be characterized by very much longer cycles
of minutes or else hours if the driving situation so allows.
[0090] The supplementary data are advantageously available from the
communication network and/or the data network system. The
supplementary data can advantageously be used both by the mobile
user communication terminal and/or by the communication network
and/or by the data network system and/or from an external sensor
system in order to enhance the pure vehicle diagnosis data. The
data network system advantageously comprises a database and a
number of proprietary, public and/or state-owned data systems.
[0091] Particularly preferably, the supplementary data can be
obtained from supplementary modules of the mobile user
communication terminal. In particular, these are modules
implemented in the user communication terminal. Alternatively, it
is possible to use modules or a sensor system that are available
externally to the user communication terminal. The mobile user
communication terminal particularly has supplementary modules that
are selected from but not limited to the group of modules
consisting of: GPS, clock, motion module, gyroscope, camera, video
camera, microphone, loudspeaker, light area. It is thus possible
for supplementary data such as position, time of day, motion state,
local close environment, acoustic close environment, temperature,
humidity or the like to be captured comparatively easily
particularly using the user communication terminal and, depending
on the relevance to an immediate driving situation, to be used by
an instruction specification in order to enhance the vehicle
diagnosis data. Close environment initially means particularly the
vehicle interior and the immediate close environment of the
vehicle. In particular, the close environment may alternatively
comprise a further close environment, as prescribed by the range of
a WLAN, WiFi and/or the closer traffic environment, for
example--preferably up to at least 500 m. Supplementary data may
also comprise user inputs or the like that are input using an MMI
(man machine interface) or another suitable interface between user
and a device, particularly the user communication terminal,
smartphone and/or the data network system. Further examples of a
suitable MMI that is suitable particularly for displaying vehicle
diagnosis data with supplementary data obtained outside the vehicle
diagnosis system is a head-up display (HUD), for example, that is
to say a display panel in the direction of view, in the case of
which the information important to the user can be projected into
his field of vision, or what are known as smart glasses (projection
glass), onto which information from the Internet, for example, can
be loaded into one's own field of vision and which can be
controlled using spoken commands or gestures, for example.
[0092] Within the context of what is known as "car-2-X"
communication, the supplementary data can come from an external
sensor system and can be transmitted directly to the vehicle
diagnosis interface. In particular, the supplementary data can then
be transmitted to the user communication terminal and/or can be
transmitted directly to the user communication terminal.
Advantageously, the user communication terminal is therefore used
as a controller in order to monitor an external sensor system at
the same time in addition to a vehicle sensor system or to enhance
appropriate diagnosis data with supplementary data. Supplementary
data can also be provided by RSE (road side equipment) such as
traffic lights, tollbooths, checkpoints for fine particles,
etc.
[0093] Within the context of what is known as "car-2-car"
communication, one particularly preferred development provides for
vehicle diagnosis data from a vehicle to be transmitted by radio
broadcast from the vehicle-implemented vehicle diagnosis system of
the vehicle via the air interface to an air interface of another
vehicle and for vehicle diagnosis data in the other vehicle to be
transmitted to a mobile user communication terminal and possibly a
data network system that is associated with the other vehicle.
Transmission can also take place via WLAN or a WiFi interface. This
can be used for advance warning of accidents, for example, by
virtue of an interface module of the first vehicle transmitting
critical operating states of the first vehicle (e.g. full braking)
to other vehicles within the context of a broadcast. The vehicle
drivers of the other vehicles thus possibly have the opportunity to
react early or else to receive a proposal--explained further
below--for a vehicle control function. In other words, the
supplementary data may also comprise data from other vehicles that
are able to be used to enhance the diagnosis data from the
diagnosis system of a vehicle.
[0094] In particular, a packet comprising vehicle diagnosis data
and supplementary data for a particular immediate driving situation
can be used in order to make a verifiable proposal for a vehicle
control function. The proposal for a vehicle control function can
be presented to the vehicle keeper via the vehicle controller for
the purpose of verification. In particular, however, it has also
been found to be advantageous that the vehicle control function can
be changed without driver verification. This becomes possible
particularly with suitable verification of the vehicle and/or of
the mobile user communication terminal and/or of the vehicle
diagnosis interface. By way of example, the verification can take
place using a vehicle identification number (FIN) and/or an
identification number from the mobile user communication terminal
or from the user (PIN, SIM No., device number or agreement number
or telephone number of the mobile customer) or a connector PIN from
the interface connector, for example an OBD or SAE connector or an
RJ plug connection for coupling to an Ethernet of the vehicle
diagnosis system. In particular, such verification can also be set
up on a permanent basis. By way of example, this can be achieved by
a practically fixed, nondetachable coupling between the interface
connector and the interface module; for example by storing a key
that uses the numbers of the verification in a permanent memory of
the interface connector and in the interface module, for example an
EPROM or the like. The interface module is particularly preferably
provided with a powerful logic unit, e.g. that of a smartphone
equivalently or similarly, and the interface module preferably has
an adequate memory, e.g. a few gigabytes of an EPROM or of a
persistent memory. The memory is used, inter alia, for storing
matrices or suchlike information masks for addressing the interface
to the vehicle diagnosis system. The memory is preferably also used
for storing vehicle diagnosis data and the supplementary data.
[0095] An instruction specification suitable for the immediate
driving situation can advantageously be created within the context
of a programmed software application or may contain such an
application. The instruction specification may be designed for
different functions, particularly vehicle control functions. In
this case, according to the concept, the instruction specification
advantageously provides not only uplink transmission and/or
ascertainment of vehicle diagnosis data but also, advantageously,
additionally downlink transmission and/or ascertainment of data,
namely particularly from a packet comprising vehicle diagnosis data
and supplementary data. Examples of such instruction
specifications, inter alia, are explained in the description of the
drawings. Vehicle control functions are not limited to the group of
functions consisting of: [0096] vehicle control proposal and/or
repair, [0097] accident examination and notification, [0098]
journey route stipulation and analysis, [0099] journey route and/or
driving behavior cost balancing, [0100] vehicle passport data
update and storage, [0101] driving behavior control and [0102]
analysis, particularly in respect of economical and/or efficient
driving behavior.
[0103] The respectively first-mentioned vehicle control function
(vehicle control proposal, journey route stipulation, vehicle
passport data update, driving behavior control) respectively
relates to the downlink transmission of vehicle diagnosis data and
supplementary data in a packet that matches the immediate driving
situation of the vehicle. By way of example, a vehicle control
proposal and/or repair--for example loading a piece of emergency
software or removing an electronic lock--can temporarily render a
vehicle in an emergency situation fit for the journey to the next
garage.
[0104] Exemplary embodiments of the invention are now described
below with reference to the drawing. This is not necessarily meant
to present the exemplary embodiments to scale, but rather the
drawing--where useful for explanatory purposes--is shown in
schematic and/or slightly distorted form. For additions to the
teaching that can be identified directly from the drawing,
reference is made to the relevant prior art. In this case, it
should be taken into account that diverse modifications and changes
relating to the form and the detail of an embodiment can be made
without departing from the general idea of the invention. The
features of the invention disclosed in the description, in the
drawing and in the claims may be essential to the development of
the invention either individually or in any combination. In
addition, the scope of the invention covers all combinations of at
least two of the features disclosed in the description, the drawing
and/or the claims. The general idea of the invention is not limited
to the exact form or the detail of the preferred embodiment shown
and described below or limited to subject matter that would be
restricted in comparison with the subject matter claimed in the
claims. In the case of specified dimensional ranges, values within
the cited limits are also intended to be disclosed as limit values
and able to be used and demanded as desired. For the sake of
simplicity, the same reference symbols are used below for identical
or similar portions or portions with an identical or similar
function.
[0105] Further advantages, features and details of the invention
emerge from the description below of the preferred exemplary
embodiments and from the drawings, in which, specifically:
[0106] FIG. 1 shows a schematic overview of a diagnosis and control
network for a multiplicity of vehicles with a respective
vehicle-implemented vehicle diagnosis system, based on the concept
of mobile assisted driving (Mobile Assisted Driving);
[0107] FIG. 2 shows, in view (A), a simplified diagram to
illustrate the core components of a diagnosis and control network,
namely a vehicle, a vehicle diagnosis interface and a user
communication terminal, and also possibly (not shown) a data
network system;
[0108] in view (B), a simplified schematic illustration to
illustrate a method for vehicle communication, in which vehicle
diagnosis data are augmented by supplementary data obtained outside
the vehicle diagnosis system, said supplementary data going beyond
vehicle diagnosis data;
[0109] FIG. 3 shows a basic diagram that shows that a plurality of
vehicles having a plurality of vehicle diagnosis interfaces may be
associated with a mobile user communication terminal (upper part)
and similarly a plurality of mobile user communication terminals
may be associated with a vehicle (lower part)--depending on the
type and number of such connections represented by communications
links, it is possible to implement
[0110] what is known as an N-2-N system, shown in view (A), from a
multiplicity of vehicle diagnosis interfaces and user communication
terminals and to implement
[0111] what is known as a car-2-X system, in view (B), for vehicle
communication between a vehicle and third centers, such as service
providers, or else centers within the existing diagnosis and
control network, such as the user communication terminal of the
vehicle driver or vehicle keeper;
[0112] FIG. 4 shows, in view (A), a schematic illustration of a
particularly preferred authorization code, made up of two to
possibly six codes (vehicleID, connectorID, telephoneID, networkID,
appID, userID), in this case optionally preferably three codes,
comprising an interface number, a SIM number and a vehicle
identification number FIN;
[0113] in view (B), a method diagram for the authentication of a
vehicle to a third center;
[0114] FIG. 5 shows a simplified more general diagram to illustrate
the concept of the vehicle communication with authentication of a
vehicle to vehicle-independent centers or other centers;
[0115] FIG. 6 shows a substantiation of the method for vehicle
communication, wherein particularly an end-to-end flow of data can
involve data enhancement with supplementary data and/or data
buffering at each station of the data flow (view (A) or view
(B))--the diagram in FIG. 6 provides the specification while
necessarily involving the user communication terminal--but can
nevertheless--as shown in FIG. 5--be modified such that a flow of
data occurs directly from the vehicle diagnosis interface to the
data network system;
[0116] FIG. 7 shows an exemplary illustration of vehicle
communication with authentication using an authorization code (such
as one of the authorization codes in FIG. 4), which is made up of
or based on codes from the essential core components of a diagnosis
and control network--namely of the vehicle, of the user
communication terminal and of the module of the vehicle diagnosis
interface--and is used when using a service, in this case a parking
service.
[0117] FIG. 1 shows a diagnosis and control network 100 for a
multiplicity of vehicles, from which a single vehicle is shown
symbolically. The vehicle 1 has a vehicle control system 2 with a
vehicle controller ECU and a vehicle diagnosis system 3. Both the
vehicle controller ECU and the vehicle diagnosis system 3 have
control and/or data access to an engine 4 in the vehicle 1, so that
engine data can be transmitted from the vehicle control system 2 to
a vehicle system interface 5--in this case an OBD-II interface.
Besides the engine data, exhaust-related vehicle data from the
vehicle diagnosis system 3, in particular, are also present on the
vehicle system interface 5. In the present case, the vehicle system
interface 5 is in the form of an OBD-II interface, but may also be
a further development thereof such as an OBD-III interface or an
alternative interface, such as an SAE interface. The explanation
below of the preferred embodiment as shown in FIG. 1 is provided
using the example of an OBD-II system as a vehicle-implemented
vehicle diagnosis system 3 without any limiting effect--in
principle, this may be any OBD-based or SAE-based system or else an
Ethernet-based system with an RJ interface. Preferably, an
interface couples to a CAN bus in a vehicle. Other BUS systems in
the vehicle, such as K-Line, L-Line, SAE J1708, LIN, PWM, Flexray,
CAN, TT-CAN, TTP and MOST or the like, can also be coupled using
appropriate interfaces. These are usually (not always) actuated via
the ZGW (central gateway). The interface in the form of a CARB or
OBD socket is in turn connected precisely to the ZGW via CAN and in
future via Ethernet (DoIP), e.g. via an RJ connector. The vehicle
diagnosis interface 10, which is also explained, can be customized,
and accordingly coupled to this and other types of interfaces of
the vehicle diagnosis system using a compatible interface connector
11 and is accordingly sometimes also called an adapter for short
here. For such a vehicle 1, FIG. 1 shows a diagnosis and control
network 100 with the components explained below.
[0118] In the present case, a vehicle diagnosis interface 10 is
designed with an interface connector 11, an interface module 12 and
an air interface 13. In the present case, the air interface 13 has
a first antenna module 13.1, which is designed for wireless
bidirectional network communication in a local area; the first
antenna module 13.1 is implemented as part of a WiFi interface in
the present case, but is not limited thereto. The first antenna
module 13.1 of the air interface 13 may also be implemented as part
of a Bluetooth, LAN, WiFi, particularly WLAN, WPAN or PicoNet or
suchlike locally limited air interface that has a suitable antenna
or the like therefor.
[0119] In the present case, the air interface 13 also has a second
antenna module 13.2, that is designed to perform a unidirectional
broadcast function, i.e. to transmit messages, at least in a local
area of up to at least 500 m or the like. By way of example, the
broadcast function can be used for "car-2-car" telecommunication,
which is explained in more detail in FIG. 3. The broadcast function
can also be used for "car-2-X" telecommunication beyond this, for
example.
[0120] The network 100 also has a mobile user communication
terminal 20, which in the present case is in the form of a
smartphone. The air interface 13 can be used to continuously
transmit the vehicle diagnosis data I obtained from the OBD-II
interface to the user communication terminal 20 in real time in any
case; the vehicle diagnosis data I are therefore available to the
smartphone too in real time and continuously.
[0121] Similarly, the smartphone has a series of supplementary data
II present on it that can be obtained via one or more modules, such
as via a GPS module, of the smartphone. The supplementary data II
can also be obtained via an Internet connection of the smartphone.
Merely by way of example, a position II.1 that can be obtained via
the GPS module or a map II.2 or cost center II.3 or parking space
situation II.4 or multimedia data II.5 such as audio and video data
or other image data, which is/are available via the Internet,
is/are available as supplementary data II here.
[0122] In principle, the network 100 can also be provided with
further supplementary data IV from an external sensor system 50, an
example of which is subsequently also explained with reference to
FIG. 4. The external sensor system 50 may comprise a sensor system
for the vehicle (also a vehicle-implemented sensor system), but not
limited thereto. On the contrary, the external sensor system 50
comprises particularly a system of external vehicle sensors that,
by way of example, can deliver multimedia data, particularly video
data or the like, or else temperature values or suchlike ambient
data. Particularly an aforementioned external vehicle sensor system
can easily be retrofitted to the vehicle. Further supplementary
data from an external sensor system 50 can best be made available
directly to the air interface 13 as supplementary data IV.1. In
addition, or alternatively, supplementary data IV.2 can also be
made available to the mobile user communication terminal 20. The
supplementary data IV.1, IV.2 can come from the same or different
sensors of the sensor system 50.
[0123] All supplementary data I, II, IV--and also the supplementary
data III that are also explained below--are obtained outside the
vehicle diagnosis system 2. At any rate the vehicle diagnosis data
I enhanced with a selection of such supplementary data II, possibly
also IV, or supplementary data of a further or different type are
transmitted to a data network system 40 via a communication network
30 as a packet of vehicle diagnosis data I and supplementary data
II, and possibly IV. In the present case, the communication network
30 is a wirelessly available Internet, for example. The
supplementary data II and IV are therefore obtained completely
outside the vehicle diagnosis system 2, particularly outside the
vehicle control system 2, via the mobile user communication
terminal 20 or an external sensor system 50 in the present
case.
[0124] The data network system 40 has a database 41, in which the
packets of vehicle diagnosis data I and supplementary data II, IV
are available for later retrieval in a memory 42. The memory 42 has
a multiplicity of memory units, one memory unit 43 of which is
associated with the vehicle 1. In the present case, the association
is made by identifying the vehicle 1 using a vehicle identification
number FIN and identifying the smartphone using a user
identification number (PIN or SIM number) and also a connector
number SN. In the present case, a combination of the numbers FIN,
SN, PIN and/or SIM is also used as the key in order to set up a
protected uplink connection UL between the vehicle system interface
5 and the data network system 40 for the purpose of transmitting
the data packet of vehicle diagnosis data I and the supplementary
data II, IV. The uplink connection UL also extends to proprietary
data systems 45 connected to the database 41; of these, the systems
of a police department 45.1, an OEM 45.2, a tollbooth 45.3, an
automobile assistance service 45.4 or a state institution 45.5 are
shown by way of example in the present case. The data packets (I,
II, IV) stored in a personalized database unit 43 are thus
available for various evaluations and user-oriented uses.
[0125] In addition, the data packet (I, II, IV) of vehicle
diagnosis data I and supplementary data II, IV can be augmented by
supplementary data III of a further type. By way of example, these
may be data from the proprietary data system 45 (for example the
availability of spare parts or toll costs or assistance services or
federal regulations or police orders) that are obtained directly
from the proprietary data systems 45 or are kept available in the
database 41 of the data network system 40.
[0126] Particularly preferably, in the present case, a downlink
connection DL from the data network system 40 via the mobile user
communication terminal 20 and the vehicle diagnosis interface 10 to
the vehicle control system 2 via the vehicle system interface 5 is
shown in the present case. The downlink connection DL is designed,
according to the concept of the invention, to return not just the
vehicle diagnosis data I, but also a data packet (I, II, III, IV)
of the vehicle diagnosis data I enhanced by the supplementary data
II, possibly IV, and/or enhanced by the further supplementary data
III. This is in turn effected largely in real time and continuously
insofar as the wireless links of the communication network 30 and
the wireless air link 13 permit this within the framework of the
data transmission speed. In this way, all supplementary data II,
III, IV available via the smartphone or the data network generally
or expediently can be taken into account, and used, as a whole in
addition to the vehicle diagnosis data I by a vehicle controller
ECU and/or the vehicle diagnosis system 3, i.e. the vehicle control
system 2, for controlling the engine 4 or the vehicle 1.
Ultimately, this allows the vehicle controller ECU to make a
verifiable proposal for a vehicle control function to the vehicle
driver in the immediate driving situation or else actually to
implement the vehicle control function without driver verification
within the framework of suitable safety specifications.
[0127] The latter is possible particularly in a guaranteed manner,
since both the uplink connection UL and the downlink connection DL
are made in an encrypted manner--namely using the FIN of the SN and
also the PIN or SIM number as a key. The diagnosis and control
network 100 shown in FIG. 1 therefore allows mobile assisted
control of the vehicle 1, be it fully automatic or semiautomatic,
with verification of vehicle control functions by the vehicle
driver. The diagnosis and control network 100 therefore has its
functionality and data availability designed to be essentially
beyond that of standard diagnosis systems.
[0128] Furthermore, an instruction specification can be created for
the purpose of stipulating the relevance of supplementary data for
an immediate driving situation within the framework of an open
programming environment, for example on the smartphone, e.g. this
can be implemented within the framework of a programmed software
application, for example interpreter programming for an iPad, an
Android, a Blackberry or a Windows-compatible device.
[0129] View A in FIG. 2 schematically shows the core
components--so-called here--of the diagnosis and control network
100 described in detail by way of example in FIG. 1. These are the
core components 110, as can be found in a vehicle following
adoption of the concept of the invention, for example when a
service as described by way of example in FIG. 7 is requested from
a third center, i.e. a vehicle-independent center. In this case,
the core components 110 of the vehicle communication comprise the
vehicle 1, the interface module 12 and the vehicle diagnosis
interface 10 for connection to the vehicle diagnosis system 3 on an
OBD II connector thereof--or a similar connector of comparable
vehicle diagnosis systems --, wherein the vehicle diagnosis
interface 10 comprises the interface module 12, an interface
connector 11 and an air interface 13. The core components 110 thus
relate to or identify particularly the vehicle 1, the vehicle
diagnosis interface 10 and a user communication terminal 20, which
is able to communicate wirelessly with the vehicle diagnosis
interface 10.
[0130] View (B) in FIG. 2 schematically shows vehicle diagnosis
data I and schematically shows supplementary data II, which are
made available by a user communication terminal 20, in this case a
smartphone. The vehicle diagnosis data I and the supplementary data
II can be combined to form a common set of data, as symbolized in
FIG. 2, view (B). By way of example, the vehicle diagnosis data I
comprise the vehicle identification number VIN, a speed statement
in real time, an odometer reading in real time, and a tank
indicator in real time. By way of example, the supplementary data
II comprise data, as are available in the case of a smartphone, for
example a GPS position, an acceleration statement measurable with a
gyroscope, other data from a data memory, an audio stream recorded
by a microphone, a video stream recorded by a camera or other
multimedia recordings that may be beneficial to an immediate
driving situation. By way of example, the supplementary data can be
selected within the framework of applications that can be created
as needed in an open programming environment. As a result, the user
communication terminal 20 in the form of the smartphone can
represent an extended monitor console, possibly even control or
regulatory console, for the automobile; a complete implementation
of extended control, regulatory and monitor features in a vehicle
implemented multimedia system can be bypassed or augmented
particularly easily. In addition, the present concept provides the
option of not just making useful information available to the
vehicle driver and vehicle keeper, but furthermore, also making it
available to third centers that are vehicle-independent. This can
form the basis for the provision of services for the vehicle keeper
in a manner customized according to need, said vehicle keeper in
turn being able to use services in a simplified manner. As an
extended console, the user communication terminal 20 is used in
addition to the control console of the vehicle.
[0131] View (A) in FIG. 3 schematically shows the option of what is
known as an N-2-N system for vehicle communication, in which the
vehicle 1 described previously can use a vehicle diagnosis
interface 10 to communicate with the user communication terminal 20
described previously, that is to say within the core components
110. Furthermore, the N-2-N system shown also results in
communication paths to other user communication terminals, for
example a further user communication terminal 21, which is
associated with the aforementioned vehicle 1 and can be used as an
additional extended console besides the user communication terminal
20. It is also possible for yet a further user communication
terminal or a multiplicity of such yet further user communication
terminals 20' to be provided, which in turn have one or more
vehicles 1', 1'', 1''' connected to them via appropriate vehicle
diagnosis interfaces, 10', 10'' and 10'''.
[0132] View (B) in FIG. 3 shows the option of communicatively
connecting the aforementioned vehicle 1 to such and other vehicles
1' or to the aforementioned user communication terminal 20 of the
vehicle driver or vehicle keeper via the vehicle diagnosis
interface 10 with the aforementioned interface module 12. Thus,
while communication is possible within the aforementioned core
components 110 within the framework of the car-2-X system shown in
FIG. 3 (B), this car-2-X system--unlike the N-2-N system of FIG. 3
(A)--allows communication not just with other vehicles 1' but also
with vehicle-independent centers, such as service providers II.6
(police), II.7 (OEM vehicle manufacturer), II.8 (charge center for
highways or the like), II.9 (ADAC or suchlike automobile assistance
services).
[0133] View (A) in FIG. 4 shows a particularly preferred embodiment
of an authorization code 130 that is symbolized as a key and that
is based on, in the present case, five or six, preferably at least
two, preferably three or four codes. The codes comprise an
interface code 120 for interface identification that has a
character string and/or number associated with the interface module
12, in this case called an adapter ID. The codes also comprise a
vehicle code 121 for vehicle identification, in this case a vehicle
registration character string and/or number 121.2 and a vehicle
identification character string and/or number 121.1 (also called
FIN). In addition, the codes comprise a communication code 122 that
relates to the mobile user communication terminal, namely a
telephone character string and/or number 122.1 and/or a SIM
character string and/or number 122.2.
[0134] In the present case, the authorization code 130 is also
based on a user password or another user identifier as a user code
123, which in this case is called a user ID. The authorization code
130 can be obtained from the aforementioned codes using any simple
or else complex cryptographical or other algorithms or methods and
can be used for authentication for the vehicle communication. That
is to say that, in principle, it is also possible for other codes,
such as the user ID/code/hash/ already mentioned, the telephone
number of a smartphone, the network ID, IP address or the like of
the smartphone, a credit card code, a date of birth or the like, to
be used for authentication. An association with the authorization
code can be made from all codes and/or parts of the codes in the
form of the keys, but at least two keys and not necessarily from
all listed keys.
[0135] In a simplified, particularly preferred version of an
authorization code 130', the latter comprises three codes that are
each associated with a component from the core components 110 of
the diagnosis and control network 100, namely particularly
preferably the vehicle identification number VIN (121.1), a
telephone number (122.1) or SIM number (122.2) and an adapter
identification number (120).
[0136] Besides the core components 110--vehicle 1, interface module
12 or vehicle diagnosis interface 10 and user communication
terminal 20--the method shown in view (B) in FIG. 4 also shows the
further essential components of the diagnosis and control network
100, namely the data network system 40 and a vehicle-independent
center 60 or 45--for example one of the centers 45.1, 45.2, 45.3,
45.4, 45.5 in FIG. 1 or one of the centers II.6 to II.9 in FIG. 3.
In the present case, the data network system 40 is connected to the
vehicle-independent centers 60, namely particularly data systems 45
in FIG. 1, via a wireless communication network 30. This connection
via the communication network 30 for the authorization check is
subsequently described within the framework of the authentication
of a vehicle 1 for use of a service. In this case, the
authorization code 130 shown in view (A) in FIG. 4 is checked for
the communication links denoted by K5, K6 and K7.
[0137] Specifically, for the communication link K1, the vehicle 1
is authenticated by means of a vehicle identification number VIN to
the vehicle diagnosis interface 10 that is called an adapter in the
present case. In the communication link K2, the user communication
terminal 20 is authenticated to the vehicle diagnosis interface 10;
in specific terms, this authentication for a first communication
link K2.1 is effected by means of a telephone number and/or for a
second communication link K2.2 by means of a SIM number; both
numbers may be associated with the user communication terminal 20.
In principle, it is also possible to use other additional or
alternative communication codes 122 for the authentication.
[0138] For a communication link K4 between the vehicle diagnosis
interface 10 and the data network system 40, it is possible to use
an authorization code 130 to 130' --that is to say at least
comprising the VIN 121.1, the SIM 122.2 and the adapter ID 120 of
the adapter--to perform an authentication attempt on the data
network system 40. The data network system 40 may store not only
the aforementioned individual codes for the authorization code 130,
130' as authentication access but also a customer name, telephone
number, provider, billing methods and the like. In particular, it
is also possible for the codes that are not used in the present
example, such as motor vehicle registration, and the codes that are
used, such as VIN, SIM and adapter ID, to be stored. In a
communication step K3, the authentication, i.e. the authentication
code, is released--possibly with a time limit, possibly also with a
local limit, but at any rate in appropriate fashion--for example by
virtue of a pass code or the like being transferred and/or
associated with the authorization code. A pass code can be stored
for the authorization code or can be associated with the
authorization code without the authorization code 130, 130' being
stored. The adapter, i.e. the vehicle interface module 12, then
stores either the authorization code 130, 130' or else the pass
code, depending on what is stored in the data network system 40. In
a further communication step K5, the adapter can then use the pass
code or the authorization code 130, 130' in order to identify and
authenticate itself to a third vehicle-independent center 60. To
this end, the pass code can be held in the adapter memory. The
adapter may also have logic that is capable of generating the
authorization code from the FIN, the SIM and the adapter ID (in the
present case) in the case of a service request and transmitting it
for the communication request K5 to the service provider 60.
[0139] For a communication link K6 from the service provider to the
adapter, it is then possible for receipt to be confirmed and, at
the same time, for a communication link K7 to the data network
system 40, for the authorization code 130, 130' and the pass code
to be aligned; that is to say aligned with the authorization code
and/or pass code stored in the data network system (depending on
what variant applies in the present case). If an authentication
result for the bidirectional communication link K7 is positive, the
requested service is released for the core components 110, i.e.
regularly a particular vehicle with a particular user communication
terminal 20 and vehicle diagnosis interface 10. In a step K8 that
is not shown, it is then possible for billing to take place between
the data network system 40 or the operator of the data network
system 40 and the proprietor of the core components 110.
[0140] This approach is found to be simple and reliable since, in
the special case described here, the codes--VIN, SIM and adapter
ID--and the codes from the other options demonstrated within the
framework of FIG. 4(A) are used, which have already been checked by
another party, for example a telephone service provider, a
motor-vehicle or automobile registration center or suchlike
reliable regulatory institutions.
[0141] Furthermore, the supplementary data II explained within the
framework of FIG. 1, FIG. 2(B) are also available in addition to
vehicle diagnosis data I and can be used for the approval or
non-approval of a service, since all of these data are available
for the communication links K5, K6, K7.
[0142] FIG. 5 shows a particularly preferred, simplified embodiment
of the system described in FIG. 1. In addition, the origins of the
codes are shown in detail. The vehicle 1 is connected to the user
communication terminal 20 via the vehicle diagnosis interface 10 or
the interface module 12 thereof via an air interface--in the
downlink DL or UL uplink--or else is connected directly to a data
network system 40 via a communication network 30. By way of
example, it is thus possible for the communication links K4, K5
shown in FIG. 4 to be routed via the communication network 30,
while the downlink and uplink communication links K2.1, K2.2
between the adapter and the user communication terminal 20 can be
routed via the air interface. Furthermore, the communication
network 30 is available bidirectionally for connecting the user
communication terminal 20 to the adapter and/or to the data network
system 40 too.
[0143] In one combination, the identification key--i.e.
authorization code 130--is obtained from the adapter ID (120) in
step S0, from the VIN (121.1) in step S1 and from the telephone
number and/or the SIM in step S2. In step S3, a user ID (for
example from the communication link K3) can be additionally used in
order to provide the authorization code 130 as an identification
key. The authorization code 130 can be used not just for
authentication on all interfaces but also possibly for specific
data encryption.
[0144] FIG. 6 shows the core components 110 shown in FIG. 5, namely
the vehicle 1, the vehicle diagnosis interface 10 and the user
communication terminal 20 together with the data network system 40
and the proprietary data systems 45, as have already been described
with reference to FIG. 1.
[0145] As can be seen from view (B) in FIG. 6, data
buffering--denoted by D1, D2, D3 here--can take place on every
component, particularly the vehicle diagnosis interface 10, the
user communication terminal 20 and the data network system 40. The
connection between the vehicle 1 and the data network system 40 or
the proprietary data system 45 is a completely bidirectional
end-to-end data connection DEE in the present case. This is not
necessarily the case, however, as shown by the embodiment in FIG.
5, for example, in which the connections V1, V2, V3 can be used for
a bypass to the data communication terminal 20. It is also possible
for a return transmission from the data network system via V3, V4
to end on the user communication terminal 20 without the need for
all data to be transmitted back to the vehicle diagnosis interface
10 or the vehicle.
[0146] Specifically, FIG. 6 once again makes it clear that the
uplink UL is used to effect a realtime data transmission from the
OBD-II interface of the vehicle diagnosis system 3 to the adapter
or interface connector 11 by means of the connection V1. Also in
the uplink, the vehicle diagnosis interface 10 can use its air
interface 13, e.g. within the framework of a WLAN connection, to
transmit data to the user communication terminal 20; by way of
example, via the communication link V6, V5. In principle, however,
a connection via the Internet 30 is also possible by means of the
connection V2, V4. Also in the uplink UL, the user communication
terminal 20 can be connected to the data network system 40 via a
mobile Internet connection on the basis of the connections V3, V4.
The data network system 40 in turn sets up an interface V7 to the
proprietary data network systems 45, i.e. essentially databases
with third-party providers. By way of example, time of day, date,
etc., can be transmitted in the uplink from the adapter of the
vehicle diagnosis interface 10, e.g. to the mobile user
communication terminal 20 and/or to the data network system 40.
Usually, the vehicle uses its interface or the BUS to send only
vehicle diagnosis data, such as vehicle diagnosis data such as
speed, temperature, etc., via the BUS, but not time and date.
According to the concept of this embodiment, these come from the
adapter; specifically the interface module 12 of the vehicle
diagnosis interface 10. There, values such as time of day, date,
etc., can additionally or alternatively be added to any
vehicle-related data or vehicle diagnosis data. By way of example,
a date stamp and time-of-day stamp may be provided for the vehicle
diagnosis data. The enhancement takes place in the interface module
12 of the vehicle diagnosis interface 10; the vehicle cannot
usually process data such as time of day and date in an interface.
Time of day and date are therefore found to be supplementary data,
which can already be enhanced in the adapter. V6, V5 or V2, V4 can
be used to transmit this data record provided with a time stamp to
the user communication terminal 20, for example via a WLAN or
Internet connection. There, the position, the state of movement,
i.e. particularly the state of acceleration and speed or the like,
can be added as a second data enhancement point.
[0147] At the further data submission point, values such as filling
station prices, weather, etc. can be added. At the further fourth
data submission point, values such as parking space situation,
vouchers, etc., can be indicated.
[0148] In the downlink, in turn, supplementary information can be
returned via the interface V7, optionally just as far as the data
network system 40 or optionally just as far as the user
communication terminal 20 or optionally just as far as the
diagnosis interface module 10 or optionally all the way into the
vehicle diagnosis system of the vehicle 1.
[0149] In this way, the vehicle diagnosis data I can be augmented
with supplementary data II, III, IV that are obtained outside the
vehicle diagnosis system 3, the supplementary data II, III, IV
going beyond vehicle diagnosis data. The data network system 40,
the vehicle diagnosis data I and the supplementary data II, III, IV
are made available to at least the mobile user communication
terminal 20 again, particularly in a manner authenticated and/or
encrypted in the manner described above. A relevance of the
supplementary data II, III, IV to the immediate driving situation
of the vehicle is predetermined on the user communication terminal
20 in an instruction specification APP that is shown in FIG. 6. The
instruction specification APP can be created in an open programming
environment and is compatible with the mobile user communication
terminal 20. If the vehicle diagnosis data I and the supplementary
data II, III, IV are transmitted completely back into the vehicle
diagnosis system of the vehicle 1 again, it is possible for a
verifiable proposal for a vehicle control function to be made, as
required, following transmission of the vehicle diagnosis data I
and the supplementary data II, III, IV back as far as to the
vehicle diagnosis interface 10.
[0150] FIG. 7 shows an example of the progression of a parking
space search by means of the mobile assisted vehicle guidance using
the core components 110, namely the vehicle 1, the vehicle
diagnosis interface 10 and the user communication terminal 20.
These have authenticated themselves on the data network system 40
for the communication link K4, K3--as explained with reference to
FIG. 4. There is also a communication link K7 between a service
provider or another proprietary system 45 between the data network
system and the proprietary system 45, in this case using the
example of the service provider for a supply of parking spaces. An
authorization code--in the present example the combination based on
VIN, SIM or telephone number and adapter ID, i.e. ID of the vehicle
diagnosis interface 10 or of the interface module 12--interchanged
via the communication links K5, K6 is explicitly stipulated for the
core components 110. The service provider 60 can use the
communication link K7 to have an authorization check performed on
the basis of the authorization code in the data network system 40
and to release the service--in this case a parking space for the
vehicle 1; as a service in advance. This means that payment for a
parking space can be made using an established payment system.
[0151] In principle, a payment method can be established
particularly easily and nevertheless securely on the basis of the
concept of the invention. In particular, in the present embodiment,
the specific situation can be provided with the following method
progression.
[0152] In a first step P1, the vehicle 1 drives up to a barrier in
the parking garage 61 and identifies itself in a second step P2 by
transmitting the authorization code 130. In a third step P3, the
communication link K7 is used to effect an authorization check on
the authorization code. In a fourth step P4, the barrier at the
parking garage 61 can be opened; the vehicle 1 can drive in, with a
time stamp and a log book entry being produced in the parking
garage 61 (possibly by aligning the time data, as entered in the
adapter, i.e. the vehicle diagnosis interface 10 or in the
interface module 12). In a fifth step P5, the vehicle 1 can park in
the parking garage 61 as required and, in a sixth step P6, can
leave the parking garage 61 again. Previously, in a seventh step
P7, the vehicle or the core component 110 is identified and
authenticated at the barrier and finally, in an eighth step P8, the
vehicle drives out with a time and a log book entry being recorded
in a ninth step P9. Up to this time, the service has been provided
as a result of the reliability check on the basis of the
authorization code 130 and also the vehicle diagnosis data and the
supplementary data without compensation; this means that the
service provider provides the service in advance or the vehicle
driver has a credit account and payment is therefore simplified for
the vehicle driver. Not until in a subsequent tenth step P10 can
automatic billing take place using a further established
service--the latter on the basis of the subjective reliability
check as a result of the reliably selected authorization code
130.
LIST OF REFERENCE SYMBOLS
[0153] 1 Vehicle [0154] 2 Vehicle control system [0155] 3 Vehicle
diagnosis system [0156] 4 Engine [0157] 5 Vehicle system interface
[0158] 10 Vehicle diagnosis interface [0159] 11 Interface connector
[0160] 12 Interface module [0161] 13 Air interface [0162] 13.1
First antenna module [0163] 13.2 Second antenna module [0164] 20
Mobile user communication device [0165] 30 Communication network
[0166] 40 Data network system [0167] 41 Database [0168] 42 Memory
[0169] 43 Memory unit [0170] 45 Proprietary data systems [0171]
45.1 Police station [0172] 45.2 OEM [0173] 45.3 Tollbooth [0174]
45.4 Automobile assistance service [0175] 45.5 State institution
(federation) [0176] 50 Sensor system [0177] 100 Diagnosis and
control network [0178] APP Instruction specification [0179] DL
Downlink connection [0180] ECU Vehicle controller [0181] FIN
Vehicle identification number [0182] I Vehicle diagnosis data
[0183] II, III, IV Supplementary data [0184] II.1 Obtainable
position [0185] II.2 Available map [0186] II.3 Cost center [0187]
II.4 Parking space situation [0188] II.5 Multimedia data [0189]
PIN/SIM User identification number [0190] SN Connector number
[0191] UL Uplink connection
* * * * *
References