US20140189814A1

US20140189814A1 - Method for vehicle communication, interface module, vehicle diagnosis interface, user communication terminal, data network system and diagnosis and control network

Info

Publication number: US20140189814A1
Application number: US14/122,097
Authority: US
Inventors: Alexander Marten; Stephan Kaufmann
Original assignee: Augmentation Industries GmbH
Current assignee: FLYCAR INNOVATIONS GmbH; Traffego GmbH; Augmentation Industries GmbH
Priority date: 2011-05-27
Filing date: 2012-05-25
Publication date: 2014-07-03
Also published as: WO2012163863A1; EP2715678A1; WO2012163861A1; US20140200760A1; US9538374B2; WO2012163862A1; EP2715679A1; DE102011076638A1

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.

Description

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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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:

- 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.

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.
With particular preference, the authorization code in a first variant is based on two codes, namely:

- a code in the form of a vehicle identification character string and/or number (FIN/VIN),
- a further code in the form of a character string and/or number that is associated with the interface module.

With particular preference, the authorization code in the second variant is based on three codes, namely:

- a first code in the form of a vehicle identification character string and/or number (FIN/VIN),
- 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,
- a third code in the form of a character string and/or number that is associated with the interface module.

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.
The concept of the invention is found to be particularly advantageous within the framework of a development according to the method of claim 12.
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.
Preferably, provision is made for

- the vehicle to be identified to a vehicle-independent center;
- the vehicle communication with the vehicle-independent center to involve automatic authentication of the vehicle, wherein
- the authentication is based on an authorization code that is transmitted automatically during the vehicle communication.

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:

- 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.

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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”.
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.
To increase data integrity, the authorization code can be used for the vehicle communication for data encryption.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
With particular preference, provision is made for

- the vehicle diagnosis data to be augmented with supplementary data that are obtained outside the vehicle diagnosis system,
- a relevance of the supplementary data to the immediate driving situation of the vehicle to be predetermined in an instruction specification.

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The relevance of the supplementary data to the immediate driving situation of the vehicle is predetermined in an instruction specification.
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.
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.
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

- 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
- 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.

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.
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.
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.
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.
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.
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.
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.
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.
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.
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:

- vehicle control proposal and/or repair,
- accident examination and notification,
- journey route stipulation and analysis,
- journey route and/or driving behavior cost balancing,
- vehicle passport data update and storage,
- driving behavior control and
- analysis, particularly in respect of economical and/or efficient driving behavior.

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.
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.

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:

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);

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;

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;

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

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

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;

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;

in view (B), a method diagram for the authentication of a vehicle to a third center;

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;

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;

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.

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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′″.
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).
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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

1 Vehicle
2 Vehicle control system
3 Vehicle diagnosis system
4 Engine
5 Vehicle system interface
10 Vehicle diagnosis interface
11 Interface connector
12 Interface module
13 Air interface
13.1 First antenna module
13.2 Second antenna module
20 Mobile user communication device
30 Communication network
40 Data network system
41 Database
42 Memory
43 Memory unit
45 Proprietary data systems
45.1 Police station
45.2 OEM
45.3 Tollbooth
45.4 Automobile assistance service
45.5 State institution (federation)
50 Sensor system
100 Diagnosis and control network
APP Instruction specification
DL Downlink connection
ECU Vehicle controller
FIN Vehicle identification number
I Vehicle diagnosis data
II, III, IV Supplementary data
II.1 Obtainable position
II.2 Available map
II.3 Cost center
II.4 Parking space situation
II.5 Multimedia data
PIN/SIM User identification number
SN Connector number
UL Uplink connection

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

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.