Design for charging station-based charging contract selection

Abstract

The invention relates to a charging control device, a device for determining a selection of a charging contract, a vehicle comprising a charging control device, and a corresponding method and computer program. The charging control device comprises at least one interface for communicating with a charging infrastructure. The charging control device comprises a control circuit which is designed to process communication messages of the charging infrastructure. The control circuit is designed to determine at least one identifier of an operator of the charging infrastructure on the basis of the communication message. The control circuit is designed to determine, on the basis of an operator of the charging infrastructure, a selection of a charging contract from a plurality of charging contracts stored in the charging control device. The control circuit is designed to authenticate the charging control device with respect to the charging infrastructure on the basis of the selected charging contract.

Description

TECHNICAL FIELD

[0001] The present invention relates to a charging control device, a device for determining a selection of a charging contract, a vehicle comprising a charging control device and corresponding methods and computer programs. BACKGROUND

[0002] Plug&Charge, a charging standard for charging electric vehicles, is based on the industry standard ISO 15118. With Plug&Charge, a driver of an electric car, e.g. a battery electric car (also called BEV, Battery Electric Vehicle) or a hybrid vehicle (also called PHEV, Plug-in Hybrid Electric Vehicle, i.e. a motor vehicle comprising a hybrid drive, whose battery can be charged by the engine and by plugging in a "Plug-in" charging plug), can be authenticated at a public charging station only by plugging in a charging cable. The authentication is here done with a digital contract certificate according to the standard. The contract certificate additionally contains a contract number. A charging station operator (CPO, Charging Point Operator) can use this number to settle the charging process with the contract provider (EMP or MO, Electro Mobility Provider or Mobility Operator, often the same as the EMP) via existing roaming platforms or directly with the customer (if the CPO is at the same time the contract provider). The working principle is explained in detail below.

[0003] With the current version of the standard (ISO 15118-2), a vehicle at a charging column can only transmit one certificate; therefore in many systems only one certificate is kept on the vehicle. When more than one certificate is installed on the vehicle, it is possible, for example, to set which certificate is currently used by the user. This certificate is stored on the charging control device and transmitted to the charging column when starting the charging process. This can lead to incompatibilities in some cases - when the operator of the charging column does not support the certificate (for example because the operator does not offer roaming, or because the contract and thus the certificate only works on the employer's charging columns and another contract only works on public charging stations), or if the driver of the vehicle has several contracts which result in different costs.

[0004] There is a need for an improved design for authenticating a charging control device with respect to a charging infrastructure. SUMMARY

[0005] DESCRIPTION

[0006] The demand is taken into account by the technical solution of the independent claims.

[0007] The application is based on the insight that the selection of a charging contract, which can be used for authentication with respect to a charging infrastructure, can be carried out automatically during the initiation of a charging process. For this purpose, in the application a communication message transmitted by the charging infrastructure within the framework of a connection establishment is analyzed in order to extract at least one identifier. The at least one infrastructure is then analyzed in order to infer the operator of the charging infrastructure on the basis of the at least one identifier. This operator is now used again in order to automatically select a charging contract and in order to authenticate the charging control device with respect to the charging infrastructure on the basis of the charging contract. This can for example achieve that on the one hand the incompatibilities described previously are avoided and on the other hand a contract is automatically selected which leads to the lowest costs.

[0008] An aspect of the application relates to a charging control device for a vehicle. The charging control device comprises at least one interface for communicating with a charging infrastructure. The charging control device comprises a control circuit which is configured to process a communication message of the charging infrastructure. The control circuit is configured to determine at least one identifier of an operator of the charging infrastructure on the basis of the communication message. The control circuit is configured to determine a selection of one charging contract from a plurality of charging contracts stored in the charging control device on the basis of the operator of the charging infrastructure. The control circuit is configured to authenticate the charging control device with respect to the charging infrastructure on the basis of the selected charging contract. This can achieve that on the one hand the incompatibilities described previously are avoided and on the other hand a contract is automatically selected which leads to the lowest costs.

[0009] The communication message can for example be received within the framework of a connection establishment between the charging infrastructure and the charging control device. This can achieve that the automatic selection is implemented within the framework of a connection establishment, like for example a connection establishment as specified in the standards ISO 15118-2 or ISO 15118-20, without the charging infrastructure having to transmit further information for supporting the selection of a charging contract and without the connection establishment being thereby (excessively) delayed.

[0010] There are different locations within or on the communication message at which an identifier can indicate an operator of the charging infrastructure. Such an identifier can be extracted, for example, from a digital certificate used to establish a Transport Layer Security (TLS) encryption. Accordingly, the control circuit can be configured to extract the at least one identifier from a Leaf-Zertifikat used by the charging infrastructure or from a further certificate of a certificate chain comprising the Leaf-Zertifikat. This Leaf-Zertifikat has information that allows an inference of the operator. Information can also be extracted from a further certificate of the certificate chain, for example from an Issuer field or from a Subject field of the respective certificate, which allows an inference of the operator of the charging infrastructure. Thus, in addition to the Leaf-Zertifikat, the certificate chain can also enable an inference of the operator of the charging infrastructure.

[0011] At least one of a power supply equipment communication controller identifier (SECCCID) and a charging point identifier (CPID) can be extracted from the Leaf-Zertifikat, for example, and used as the at least one identifier. These identifiers can be used to identify the operator of the charging infrastructure.

[0012] Alternatively or additionally, the at least one identifier can comprise an identifier with which the charging infrastructure presents itself to the charging control device. For example, the at least one identifier can comprise an electric vehicle supply equipment identifier (EVSEID). In some cases, the EVSEID can also be used to identify the operator of the charging infrastructure.

[0013] It has been shown in practical implementations that the identifiers transmitted by the charging infrastructure are manipulated differently by different operators. As a result, the operator cannot always be reliably inferred from a unique identifier. For example, the control circuit can be configured to determine a plurality of identifiers on the basis of the communication message and to identify the operator using one or more of the identifiers, as the operator uses them. This increases the reliability of the operator identification.

[0014] Now a charging contract can be selected from the operator. The selection can be determined, for example, based on a data structure such as a decision tree or a conditional branch. Here, a charging contract to be selected can be defined in the data structure for a plurality of operators. This enables a quick selection of a charging contract with low computational complexity. If no charging contract to be selected is defined for an operator, a charging contract to be selected can also be defined in the data structure. This enables a selection of a charging contract (for example, a charging contract of an operator comprising a plurality of roaming agreements) at a plurality of possible operators and / or upon the occurrence of a new operator, which is used as a standard in order to be able to implement a charging process despite unknown operators.

[0015] In the present design, the actual selection of a charging contract can be made on the charging control device or on a further control device in the vehicle (or even on a server in the backend). In other words, the selection of a charging contract can be implemented by the control circuit. This enables a determination of the selection with small delay. Of course, the available memory in the charging control device is mostly limited, so that here a support of each operator in the case of a plurality of possible operators is not possible. Alternatively, the determination of the selection can comprise a provision of information about the at least one identifier to a counterpart and a reception of information about a charging contract to be selected from the counterpart. Here, the counterpart can be a further control device of the vehicle or a backend server. Thereby, for example, the counterpart can take over the selection with higher delay and / or higher implementation complexity, which has more storage space to cover a larger number of operators or takes other criteria (night or daytime point flow, special offers) into account or has more recent information about the operators.

[0016] In some cases, for example in a charging communication according to ISO 15118-20, the charging infrastructure can also provide information about which mobile operators are supported by the charging infrastructure. These information can then be used to further improve the selection, for example in the case of an unknown operator. In other words, the control circuit can furthermore be configured to obtain a list comprising supported mobile operators from the charging infrastructure and to determine the selection of the charging contract based on the list comprising supported mobile operators. This enables a further improvement of the selection, in particular in the case of an unknown or indeterminable operator of the charging infrastructure for the charging control device.

[0017] In some cases, an authentication failure can occur despite the selection of the charging contract based on the operator of the charging infrastructure. In these cases, information about this can be transmitted to a backend server in order to improve the criteria for the selection in the future. For example, the control circuit can furthermore be configured to transmit information about the at least one identifier, about the selected charging contract and about the success or failure of the authentication to a backend server at least in the case of the authentication failure.

[0018] The proposed invention can be used, in particular, in the context of the plug-and-charge charging standard. Accordingly, the charging contract and the communication with the charging infrastructure can be based on the ISO 15118 standard. However, the basic concept can also be chosen in accordance with comparable standards for charging communication.

[0019] Another aspect of the invention relates to a corresponding method for a charging control device of a vehicle. The method comprises processing a communication message of a charging infrastructure. The method comprises determining at least one identifier of an operator of the charging infrastructure based on the communication message. The method comprises determining a selection of one charging contract from a plurality of charging contracts stored in the charging control device based on the operator of the charging infrastructure. The method comprises authenticating the charging control device with respect to the charging infrastructure based on the selected charging contract. The method may, for example, be implemented by a charging control device.

[0020] Another aspect of the invention relates to a corresponding program comprising a program code for implementing a method for a charging control device when the program code is implemented on a computer, a processor, a control module, a control circuit or a programmable hardware component of the charging control device, for example.

[0021] Another aspect of the invention relates to a device for determining a selection of a charging contract. The device comprises an interface for communicating with a charging control device of a vehicle. The device comprises a control circuit configured to obtain information about at least one identifier of an operator of a charging infrastructure from the charging control device. The control circuit is configured to determine a selection of one charging contract from a plurality of charging contracts stored in the charging control device based on the operator of the charging infrastructure. The control circuit is configured to provide information about the charging contract to be selected to the charging control device. By implementing the device in a further control device of the vehicle, for example a "Head Unit", a car radio, or in a backend server, the selection of the charging contract can be transferred out of the charging control device.

[0022] Another aspect of the application relates to a corresponding method for determining a selection of a charging contract. The method comprises obtaining information about at least one identifier of an operator of a charging infrastructure from a charging control device. The method comprises determining a selection of one charging contract from a plurality of charging contracts stored in the charging control device based on the operator of the charging infrastructure. The method comprises providing information about the charging contract to be selected to the charging control device. The method can for example be implemented by a control device of a vehicle or by a backend server.

[0023] Another aspect of the application relates to a corresponding program comprising program code for implementing a method for determining a selection of a charging contract when the program code is implemented on a computer, a processor, a control module, a control circuit or a programmable hardware component. BRIEF DESCRIPTION OF DRAWINGS

[0024] Embodiments are described below in more detail with reference to the accompanying drawings. In the drawings:

[0025] Figure 1a a schematic diagram of a charging control device is shown;

[0026] Figure 1b a flow chart of a method for a charging control device is shown;

[0027] Figure 2a a schematic diagram of a device for determining a selection of a charging contract is shown;

[0028] Figure 2b a flow chart of a method for determining a selection of a charging contract is shown;

[0029] Figure 3 a schematic diagram of a technical perspective of plug and charge is shown;

[0030] Figure 4 a simplified diagram of a technical infrastructure for utilizing plug and charge is shown; and

[0031] Figure 5 a chart showing examples of fields of a certificate. DETAILED DESCRIPTION

[0032] DETAILED DESCRIPTION

[0033] Some examples will now be described in more detail below with reference to the accompanying drawings. However, other possible examples are not limited to features of the implementation forms described in detail. These can include modifications and equivalents of the features as well as additional and alternative features. Moreover, terms used herein are not intended to be limiting, particularly as to other possible examples.

[0034] Throughout the description of the figures, same or similar reference numerals can represent same or similar elements or features, which can be implemented identically or also differently, respectively, and which provide the same or similar function, throughout the whole description of the figures. Furthermore, in the figures, the thicknesses of lines, layers and / or regions can be exaggerated, for clarity.

[0035] When combining two elements A and B in the case of using "or", it is understood that all possible combinations are disclosed, i.e. only A, only B, and A and B, unless explicitly otherwise limited in the individual case. As an alternative expression for the same combination, "at least one of A and B" or "A and / or B" can be used. This applies to combinations with more than two elements as well.

[0036] If a singular form, e.g. "one", "the", is used and the use of only one individual element is not explicitly or implicitly limited to be necessary, further examples can also use a plurality of elements to implement the same function. When in the following a function is described as being implemented using a plurality of elements, further examples can implement the same function using a single element or a single processing entity. It is also understood that when the terms "comprising", "comprises", "comprised" and / or "having", "has", "having" are used, it is meant that the given features, integers, steps, operations, processes, elements, components and / or groups thereof are present, but not excluding the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or groups thereof.

[0037] Figure 1a A schematic diagram of a charging control device 10 for a vehicle 100 is shown, wherein the charging control device 10 is part of the vehicle 100. The charging control device comprises at least one interface 12 for communicating with a charging infrastructure 5, e.g. a charging column, e.g. by power line communication. In some examples, the at least one interface 12 comprises an interface for communicating with a further control device 200 of the vehicle 100, e.g. a head unit of the vehicle, at least one interface for communicating with a server 205, e.g. by telematics connection / mobile radio connection. In Figure 1aThe charging control device 10 shown in the middle comprises an encryption-secure element 14, for example a so-called "Secure Element" or "Trusted Execution Environment". The charging control device 10 comprises a control circuit 16, which is coupled with the encryption-secure element 14 and the at least one interface 12. The encryption-secure element can be part of the control circuit 16 or a separate component, for example. Optionally, the charging control device 18 furthermore comprises a memory 18, which is coupled with the control circuit 16.

[0038] Figure 1a Furthermore, a system comprising the charging control device 10 and the control device 200 is shown. Figure 1a Furthermore, a system comprising the charging control device 10 and the server 205 is shown. Figure 1a Furthermore, a system comprising the charging control device 10 and the control device 200 and the server 205 is shown.

[0039] The control circuit 16 constitutes means for processing a communication message of the charging infrastructure. The control circuit 16 constitutes means for determining at least one identifier of an operator of the charging infrastructure based on the communication message. The control circuit 16 constitutes means for determining a selection of a charging contract from a plurality of charging contracts stored in the charging control device based on the operator of the charging infrastructure. The control circuit 16 constitutes means for authenticating the charging control device with respect to the charging infrastructure based on the selected charging contract.

[0040] Figure 1b A corresponding flow chart of a method for a charging control device 10 is shown. The method comprises processing 110 a communication message of the charging infrastructure. The method comprises determining 120 the at least one identifier of an operator of the charging infrastructure based on the communication message. The method comprises determining a selection of the charging contract from the plurality of charging contracts stored in the charging control device based on the operator of the charging infrastructure. The method comprises authenticating the charging control device with respect to the charging infrastructure based on the selected charging contract 140.

[0041] The charging control device, the corresponding method and a corresponding computer program in respect of the charging control device are then described. Features described in connection with the charging control device apply equally to the corresponding method or computer program.

[0042] Charging contracts (also called contract certificates) are utilized in charging communication according to the plug-in charging standard in order to authenticate the charging control device with respect to the charging infrastructure, for example a charging column. These charging contracts are issued within the framework of a contract between the driver / user of the vehicle and a so-called mobility operator and are utilized by the operator of the charging infrastructure in order to settle the provided charging current. For this purpose, the mobility operator concludes a contract with the operator of the charging station (as long as the mobility operator and the operator of the charging station are not the same entity), in which it is specified what fees arise for the mobility operator when the charging infrastructure is utilized by a customer of the mobility operator. The mobility operator in turn settles the provided services of the operator of the charging station with the customer. However, not all mobility operators have concluded a contract with all charging station operators, so that the charging infrastructure cannot be utilized with all contracts. Furthermore, the price varies significantly in parts according to the contracts between the mobility operator and the customer and between the mobility operator and the operator of the charging station. In the current implementation of plug-in charging (according to ISO 15118-2), often only one certificate is installed with the aid of which plug-in charging can be utilized. The selection by the user is cancelled in this case. When more than one certificate is installed on the vehicle, it is possible, for example, to set which certificate is currently used by the user. If the user of the vehicle has a plurality of contracts including a plurality of mobility operators and thus also a plurality of charging contracts, it is therefore required that the user selects the appropriate contract for the respective charging station. The present invention automates this selection to a large extent and, for example, in connection with plug-in charging, strives for a contract selection based on the charging station.

[0043] To at least guarantee that the utilized charging contract is also supported by the operator of the charging station, the current version of the standard ISO 15118-20 supports that the charging station informs the plugged-in vehicle by means of the data structure SupportedProvidersListType which contract providers are supported. As long as a suitable certificate is installed, this function allows the vehicle to use a suitable certificate. This gives a remedy, in part, in that the car can select at least one accepted contract. However, the standard does not specify a mechanism for how to deal with, for example, more than one accepted contract. Also, the currently prevailing stations according to ISO 15118-2 cannot make use of this mechanism. On the part of the charging station, a switch to ISO 15118-20 part ex post could be possible. However, due to diverse limitations, vehicles cannot be upgraded to ISO 15118-20 ex post, so that in the foreseeable future ISO 15118-2 will also be supported by all market participants. Furthermore, there are use cases from the user's perspective in which the user wishes to use a certain contract for a certain charging station operator, because the user obtains better conditions with this contract at this supplier than with the otherwise preferred standard contract, for example.

[0044] The application is based on the fact that the operator can be identified by means of an unambiguous identifier of the charging station transmitted in the charging communication. For this purpose the charging control device processes a communication message of the charging infrastructure. This communication message can be, for example, a communication message exchanged at the beginning of the communication between the charging control device and the charging infrastructure, i.e. the charging column, for example a message of the charging infrastructure to the charging control device within the framework of the connection establishment. For example, the communication message can have been received within the framework of the connection establishment between the charging infrastructure and the charging control device. Here, the communication between the charging infrastructure and the charging control device can be based on the standard ISO 15118 and in particular on ISO 15118-2 or ISO 15118-20, for example. The charging contract mentioned here can also be based on the standard ISO 15118 and in particular on ISO 15118-2 or ISO 15118-20.

[0045] The control circuitry is configured to determine at least one identifier of the operator of the charging infrastructure based on the communication messages. Different sources are considered here. For example, it could be a so-called EVSEID (Electric Vehicle Supply Equipment Identifier). In other words, the at least one identifier could include an EVSEID. This EVSEID is transmitted by the charging station as part of a Session Setup Response according to standards. Alternatively or additionally, a SECCID (Supply Equipment Communication Controller Identifier) ​​and / or a CPID (Charge Point Identifier) ​​can be utilized, both of which are part of a leaf certificate. Here, the SECCID is part of a SECC (Supply Equipment Communication Controller) leaf certificate according to ISO 15118-20, and the CPID is part of a leaf certificate according to ISO 15118-2. Accordingly, the control circuitry can be configured to extract at least one identifier from the leaf certificate used by the charging infrastructure. In this case, the at least one identifier could include at least one of the Supply Equipment Communication Controller Identifier, i.e., the SECCID, and the Charging Point Identifier, i.e., the CPID. In some cases, CPID can also be consistent with EVSEID. Not only EVSEID, but also SECCID contains a 3-digit alphanumeric EVSE (Electric Vehicle Supply Equipment) operator identifier (operator ID) and a 2-digit country code, which together identify the charging station operator.

[0046] In addition to SECCCID or CPID, the leaf certificate includes other information, which is also found in other certificates in the certificate chain that includes the leaf certificate, and this information allows for the inference of the operator. Figure 5An example of fields of such a certificate is shown in the table below. In particular, one or more of the fields "Country", "Organization" and "common name" of the fields Issuer and / or Subject can be used to identify the operator of the charging infrastructure. Here, if the certificate is a leaf certificate according to ISO 15118-2, the CPID for example corresponds to the common name. Accordingly, the control circuit can be configured to extract the at least one identifier from a certificate of a certificate chain, the certificate chain comprising a leaf certificate used by the charging infrastructure. Here, the identifier for example can comprise one or more of the above-mentioned fields.

[0047] In a charging control device according to ISO 15118-2 / -20, the EVSEID from SessionSetupRes can be temporarily cached. Additionally, the charging control device can extract and temporarily cache the CPID or SECCID from the SECC leaf certificate according to the standard. Experiments have shown that the EVSEID from SessionSetupRes is not a reliable data in Europe, so it can make sense to additionally or alternatively use information from these certificates as long as these certificates are considered reliable. Accordingly, the control circuit can be configured to determine a plurality of identifiers (e.g. EVSEID and CPID or EVSEID and SECCID) based on the communication messages and to use one or more of the identifiers according to the operator in order to identify the operator. The decision to use determined data for the selection of a contract for automation can be set via a configuration parameter. Alternatively, an algorithm can decide on the charging control device which data is most likely correct and use this data for further processes.

[0048] The control circuit is configured to determine a selection of the charging contract from the plurality of charging contracts stored in the charging control device based on the operator of the charging infrastructure. For example, the selection can be determined based on a data structure in which a plurality of operators is defined with a charging contract to be selected. The data structure for example can be stored in the memory 18. Exemplarily, a list of EMAIDs (E-Mobility Account Identifier) is used as a data structure. However, instead of the list, a database or a decision tree can also be used as a data structure. The examples given in connection with the list can also be transferred to the database or the decision tree accordingly. In these examples, the respective EMAID stands for a charging contract to be selected, i.e. a charging contract to be selected is indicated by the associated EMAID.

[0049] The charging control device or other entity can also store a list which represents a specification for the automated selection of a contract. Each list entry can comprise, for example, a two-digit country ID, a three-digit operator ID and an EMA ID. In addition, the list can comprise one or more EMA IDs which serve as fallback contracts. In other words, if no charging contract to be selected is defined for the operator, a charging contract to be selected (the one or the more fallback contracts) can also be defined in the data structure.

[0050] Based on the identified operator, the vehicle can now be informed, for example by means of a predefined list consisting of contract IDs (EMA ID, E-Mobility Account Identifier, electronic mobility account identifier) and EVSE operator IDs (which identify the operator), which contract (EMA ID) is automatically selectable and utilizable at which operator (EVSE Operator ID). If the vehicle is now connected to a charging station which supports plug-and-charge, the charging control device checks, for example, the EVSE ID / SECC ID / CP ID (i.e. the at least one identifier) temporarily stored for the charging process first. For this purpose, the operator ID and the country ID from this data can now be compared with the list. If there is the same entry in the list, the EMA ID of the list entry can be read and selected. If no suitable entry is found, a fallback EMA ID can be selected and, in addition, information about the error can be stored. This procedure takes place, for example, after the establishment of a TLS (Transport-Layer Security, transport layer security) connection, but before the authentication by means of the plug-and-charge certificate. The selected EMA ID here represents the contract which is now used for the authentication at the charging station in the next step within the framework of the plug-and-charge authentication.

[0051] The list can be specified based on different premises (also in combination), for example based on (known) roaming relationships, customer preferences (by customer specification or learned based on behavior), with knowledge about individual prices for a determined EMAID at a determined charging station operator, determined as optimally favorable as possible to the customer. Further possibilities for prioritization are expressly possible. The list can either be built locally on the vehicle or can be introduced into the vehicle with the aid of a backend connection and updated. A comparison with SupportedProvidersListType can be made as soon as with the aid of ISO 15118-20 communication. In other words, the control circuit can furthermore be configured to obtain a list comprising supported mobile operators (SupportedProvidersListType) from the charging infrastructure and furthermore determine the selection of the charging contract based on the list comprising supported mobile operators. The above-mentioned list can contain the same operator ID for multiple EMAIDs, for example. The list can be structured such that for each operator ID a preferred or one or more fallback contract (EMAID) is given, for example. In the case of a provider of a preferred EMAID not being part of SupportedProvidersListType, a fallback contract can be selected.

[0052] The list predetermined for automatic selection in the charging control device can be built in the backend, for example user-specifically, and introduced into the charging control device via a remote connection. The list itself can be built based on customer specifications (individual contracts according to individual priorities of the charging station operators), existing restrictions (for example contracts with determined stations based on roaming), in consideration of the most favorable prices or other criteria or combinations thereof. As a fallback contract, a contract determined by the customer can be used, which should be used if automatic selection of a contract is not possible. In many cases, the selection of a charging contract can be carried out by the control circuit. Alternatively, instead of the charging control device, a plurality of controllers in communication with one another in the vehicle can also participate in the automatic contract selection. Accordingly, the determination of the selection can comprise providing information about the at least one identifier to a counterpart (for example by means of the at least one interface 12) and receiving information about a charging contract to be selected from the counterpart (for example by means of the at least one interface 12). Here, the counterpart can be a further control device 105 of the vehicle or a backend server 200. In Figure 2a and 2bExamples of devices, methods and computer programs for implementing the selection on the backend are given in the detailed description. So the list can for example be on a further control device or on a backend server and the charging control device asks via the vehicle network before authentication by operator ID and country ID / Code which EMAID is available for this combination. The control device on which the list is stored is responsible for the comparison and sends the selected EMAID and optionally also a fallback EMAID back to the charging control device. In another form the charging control device or a further control device in communication with the charging control device can query the preferred EMAID (and fallback EMAID) on the backend after identification of the operator ID and country ID / Code before each charging process.

[0053] During the authentication of the charging control device (e.g. by means of the at least one interface 12) now the certificate of the selected charging contract is utilized in order to encrypt the communication with the charging infrastructure 5 and to identify the charging control device with respect to the charging infrastructure and thereby to authenticate the charging control device.

[0054] After the authentication a report can be sent from the charging control device to the backend, which report for example contains at least the following information: EVSE ID, CP ID, SECC ID, used EMA ID, automatic selection success, authentication success. In other words, the control circuit can furthermore be configured to transmit information about the at least one identifier, about the selected charging contract and about the success or failure of the authentication to the backend server 200 at least in the case of a failure of the authentication. This information can on the one hand be used to display error situations transparently with respect to the customer, for example in a mobile application of the vehicle manufacturer. On the other hand, this information can be used to improve the mechanism for the automatic selection, in particular of the previously mentioned list.

[0055] The at least one interface 12 can for example correspond to one or more inputs and / or one or more outputs for receiving and / or transmitting information, for example in digital bit values, based on codes, within a module, between modules or between modules of different entities.

[0056] In embodiments, the control circuit 16 can correspond to any control device or processor or programmable hardware component. The control circuit 16 can also be implemented as software, for example, which programs a corresponding hardware component. Here the control circuit 16 can be implemented as programmable hardware including a corresponding adapted software. Any processor, such as a digital signal processor (DSP), can be used here. The embodiments are not limited here to a certain type of processor. Any processor or a plurality of processors can be envisaged for the implementation. In some examples, the control circuit 16 can comprise a cryptographic security element 14.

[0057] The memory 18 of the charge control device can for example comprise at least one element of the group of computer readable storage media, magnetic storage media, optical storage media, hard disks, flash memories, floppy disks, random access memories (also called RAM in English), programmable read-only memories (PROM), erasable programmable read-only memories (EPROM), electrically erasable programmable read-only memories (EEPROM) and network memories.

[0058] The vehicle 100 can for example correspond to a land vehicle, a water vehicle, an air vehicle, a rail vehicle, a road vehicle, a car, a cross-country vehicle, a motor vehicle or a heavy motor vehicle.

[0059] Further details and aspects of the charge control device, the corresponding method and the computer program are pointed out with the designs or examples explained thereafter (for example Figures 2a to 4 ). The charge control device, the corresponding method and the computer program can comprise one or more additional optional features corresponding to one or more aspects explained before or after the proposed designs or described examples.

[0060] Figure 2a A schematic diagram of an apparatus 20 for determining a selection of a charging contract is shown. The apparatus 20 comprises at least one interface 22 for communicating with a charge control device 10 (shown in Figure 1a ) of a vehicle. The apparatus comprises a control circuit 24 coupled with the at least one interface 22. The control circuit 24 is configured to obtain (via the interface 22) from the charge control device information about at least one identifier of an operator of a charging infrastructure. The control circuit 24 is configured to determine a selection of one charging contract from a plurality of charging contracts stored in the charge control device based on the operator of the charging infrastructure. The control circuit 24 is configured to provide (via the interface 22) to the charge control device information about the charging contract to be selected. The apparatus 20 can here be part of a control device (for example the control device 200 in Figure 1a ) or part of a back-end server (for example the back-end server 205 in Figure 1a ).

[0061] Figure 2bA flow chart showing a corresponding method for determining a selection of the charging contract is shown. The method comprises obtaining 210 information about the at least one identifier of an operator of a charging infrastructure from a charging control device. The method comprises determining 220 a selection of the charging contract from the plurality of charging contracts stored in the charging control device based on the operator of the charging infrastructure. The method comprises providing 230 the information about the charging contract to be selected to the charging control device.

[0062] The selection of the charging contract is determined by Figure 2a The device 20 and Figure 2b The selection implemented by the method (and the corresponding computer program) can for example be implemented similar to the selection of a charging contract as explained in connection with Figure 1a and 1b The selection of the charging contract is determined by

[0063] The at least one interface 22 can for example correspond to one or more inputs and / or one or more outputs for receiving and / or transmitting information for example in digital bit values, based on codes, within a module, between modules or between modules of different entities.

[0064] In embodiments the control circuit 24 can correspond to any control device or processor or programmable hardware component. The control circuit 24 can also be implemented as software for example, which programs a corresponding hardware component. Here the control circuit 24 can be implemented as programmable hardware including a corresponding adapted software. Any processor can be used here, like a digital signal processor (DSP). Embodiments are not limited here to a certain type of processor. Any processor or a plurality of processors can be envisaged for the implementation.

[0065] The design or the example explained later on (for example Figures 1a to 1b , 3 to 4) points out further details and aspects of the device, the corresponding method and the computer program. The device, the corresponding method and the computer program can comprise one or more additional optional features, which correspond to one or more aspects of the design proposed or the example described before or later on.

[0066] A short overview of the plug-in-charging mechanism as utilized in the present application is given next for further understanding. Plug-in-charging enables a fully automated and secure charging experience by means of an authentication technology from the EV to the charging station (according to ISO 15118). Figure 3 A schematic diagram showing the technical perspective of plug-in-charging is shown. First (1.) the vehicle manufacturer (as OEM in Figure 4The vehicle user is provided with a provisioning certificate (as shown in Fig. 1) by the aggregator. This provisioning certificate comprises in the present case a clear identifier specific to the user account. The vehicle user then enters into a charging contract with a mobile operator (MO). Within the framework of the conclusion of the charging contract, the vehicle user informs the vehicle identification number (e.g. PCID), which can be done for example by the vehicle manufacturer. The mobile operator builds (3.) a contract certificate for the given vehicle identification number, which is likewise provided to the aggregator. The aggregator informs the OEM (4.) that it has obtained the contract certificate and optionally forwards the contract certificate to the OEM (or the contract certificate is invoked by the OEM as required). The customer commissions the vehicle manufacturer and in particular the vehicle to download and install (5.) the contract certificate. Within the framework of the charging process, the vehicle manufacturer or the vehicle communicates (6.) with the charging station operator (CPO) via ISO 15118, which can now establish a connection with the mobile operator with regard to payment for the charging process via the aggregator and / or roaming platform.

[0067] In Figure 4 a simplified diagram for the use of a technical infrastructure for plug and charge is shown. Figure 4 A charging control device 410, which can correspond to the charging control device 10 of Figure 1a a user interface control device 420, which can correspond to the control device 200 of Figure 1a an intermediary 430 (which can be utilized in the vehicle or at the time of manufacturing the vehicle), a plug and charge coordinator 440 (on the vehicle manufacturer side), an aggregator 450, a mobile service provider 460, an operator of a charging station 470 and a charging station 480 are shown. The charging control device 410 constitutes a communication for ISO 15118 and is responsible for certificate storage and operation (including diagnostic tasks). The intermediary is a root certificate authority of the vehicle manufacturer and provides a provisioning certificate.

[0068] In order to install a new contract in the vehicle and in particular in the charging control device, the following steps can be implemented. In order to enable the installation of a charging contract (or a corresponding certificate), a so-called provisioning certificate is required. In the present example, this is implemented by the intermediary 440. The intermediary obtains a certificate signing request (CSR) from the charging control device and provides the private key of the certificate for the charging control device 430 and the public key for the plug and charge coordinator 440. The plug and charge coordinator publishes the provisioning certificate (i.e. its public key) at the aggregator 450. The provisioning certificate cryptographically securely contains an identification mark of the vehicle (e.g. the vehicle frame number).

[0069] If the customer signs a charging contract, the customer gives the identification mark of the vehicle to the mobile service provider 450 as part of the contract. The mobile service provider builds a new contract certificate. The contract certificate can now be encrypted by means of the provisioning certificate, i.e. the public key, so that the contract certificate can only be decrypted by the charging control device with the private key of the provisioning certificate. The appropriate provisioning certificate is determined by means of the identification mark, i.e. the unambiguous identifier. The aggregator 450 obtains the encrypted contract certificate and informs the plug-in charging coordinator 440 thereof. The plug-in charging coordinator can now obtain the contract certificate and provide it to the charging control device, for example via a telematics connection. Alternatively, the contract certificate can be exchanged between the charging station 480 and the charging control device 410 by power line communication. If the charging control device has the corresponding contract certificate, the charging control device can be identified by the contract certificate over an encrypted connection by means of TLS (Transport Layer Security) communication.

[0070] The charging station is identified by a leaf certificate derived from a V2G (Vehicle-to-Grid) root certificate. By means of the leaf certificate of the charging station, a TLS (e.g. TLS 1.2) connection is first established between the charging station and the vehicle (similar to transport encryption in the Internet). The contract certificate is then transmitted. The contract certificate is thus not part of the TLS chain. In the case of TLS 1.3, a further certificate is used, which is specified in ISO 15518-20. Authorization of the charging session takes place between the charging station 480, the operator of the charging station 470 and the aggregator 450, wherein the operator of the charging station 470 can determine the mobile service provider 460 via the aggregator 450. Payment to the mobile service provider 460 is then made by means of the electronic mobile identifier in accordance with the contract.

[0071] The user interface control device comprises a system for a graphical interface, which can be based on a graphical operating system for mobile devices, for example, and can implement a configuration of the on-board user guidance as well as the vehicle and the plug-and-charge functionality as well as the real control device functionality. The latter communicates with the charging control device 410 and obtains information about the supply and contract certificates stored there from the charging control device 410. By means of the system for the graphical interface, it is now possible to give the possibility to select one of the stored certificates, wherein the selection is communicated to the charging control device. The user interface control device 420 furthermore inquires the identifier of the new contract certificate (and the V2G root certificate) at the plug-and-charge broker 440, so that the installation of the contract certificate can be provided. If the installation is triggered, the user interface control device 420 inquires the corresponding certificates for the installation from the plug-and-charge broker. These certificates are then transmitted to the charging control device. For the communication between the user interface control device 420 and the charging control device 410, diagnostic communication and / or status / configuration communication can be used here, for example.

[0072] Figure 5 A diagram showing an example of the fields of a certificate as used within the framework of the EVSE / CPO certificate chain of the standard ISO 15118-2 or ISO 15118-20. The certificate described here is a certificate according to the standard X.509 v3. The certificate comprises the following sections: tbsCertificate (to-be-signed certificate) including the fields: version, serial number and signature; issuer including the fields: country, organization, organizational unit and common name; validity and subject including the fields: country, organization, organizational unit, common name and domain component. In the certificate chain, the certificates CPO Sub 1 (charging point operator sub certificate 1), CPO Sub 2 (charging point operator sub certificate 2) and the SECC certificate (as leaf certificate) can be used, for example. In the fields, especially the fields of the country, organization and common name in the sections of the issuer and the subject are of interest in order to determine the at least one identifier. The CPID corresponds to the common name in the subject section of the leaf certificate according to ISO 15118-2 here. Only the CPID is defined in the standard and thereby is the most promising indicator. However, other indicators can also be employed.

[0073] The aspects and features explained in connection with the examples of the preceding examples can also be combined with one or more of the further examples to replace identical or similar features of the further example or additionally introduce the features into the further example.

[0074] Examples can also be or relate to (computer) programs comprising program code, which programs, when executed by a computer, processor or other programmable hardware component, carry out one or more of the methods as described herein. One or more of the steps, acts, or functions of the above-described methods can also be carried out by or with the aid of such programming. Examples can also cover apparatuses or systems followed by corresponding device or system, characterized by such apparatuses or systems in combination with the corresponding method steps to be executed by the device or system in question. Examples can also cover program storage devices, such as digital data storage media, which are machine-, processor- or computer-readable and which encode machine-, processor- or computer-executable programs or instructions and / or data. Such program storage devices can be, for example, digital memories, magnetic or optical storage media, memory or memory components, such as for example read-only memory (ROM), floppy disks, hard disks or optical disks, and the like. The examples can further cover the programs, which are directly loadable into and / or executable by the computer, processor or other programmable hardware component.

[0075] It is further understood that the disclosure of a number of steps, processes, operations or functions in the description or claims is not to be interpreted as a requirement to perform the steps, processes, operations or functions in the order in which they are described, unless explicitly stated or required by the nature of the steps, processes, operations or functions. Therefore, the preceding description does not limit the order of the steps or functions in the methods described. Additionally, individual steps, functions, processes or operations can be combined and / or divided in other examples.

[0076] When in the preceding description some aspects are described in association with a device or system, these aspects are also to be understood as a description of a corresponding method. Here, for example, a block, device or functional aspect of the described device or system can correspond to a feature of the corresponding method, for example a method step. Correspondingly, aspects associated with a method description can also be understood as a description of corresponding blocks, elements, features or functional aspects of a corresponding device or a corresponding system.

[0077] The following claims are hereby incorporated into the detailed description, in which each claim by itself can serve as a separate example. Moreover, it should be noted that while the dependent claims refer in the claims to a specific combination with one or more other claims, other examples can also include a combination of the subject matter of the dependent claim with any other dependent or independent claim. These combinations are hereby explicitly proposed, as long as they are not excluded in the individual cases by the description. Furthermore, it should also be included for any further independent claim that the features of the following claim are included, even if the claim is not directly defined as dependent on the further independent claim.

[0078] List of reference signs

[0079] 5 charging infrastructure

[0080] 10 charging control device

[0081] 12 interface

[0082] 14 cryptographically secure element

[0083] 16 control circuitry

[0084] 18 memory

[0085] 20 device

[0086] 22 interface

[0087] 24 control circuitry

[0088] 100 vehicle

[0089] 110 processing a communication message of a charging infrastructure;

[0090] 120 determining at least one identifier of an operator of the charging infrastructure based on the communication message;

[0091] 130 determining a selection of one charging contract from a plurality of charging contracts stored in the charging control device based on the operator of the charging infrastructure

[0092] 140 authenticating the charging control device with respect to the charging infrastructure based on the selected charging contract.

[0093] 200 control device

[0094] 205 backend server

[0095] 210 obtaining information about at least one identifier of an operator of a charging infrastructure from a charging control device

[0096] 220 determining selection of one charging contract from a plurality of charging contracts stored in the charging control device based on an operator of the charging infrastructure

[0097] 230 providing information on the charging contract to be selected to the charging control device

[0098] 410 charging control device

[0099] 420 user interface control device

[0100] 430 intermediary

[0101] 440 plug-and-charge coordinator

[0102] 450 aggregator

[0103] 460 mobile service provider

[0104] 470 operator of the charging station

[0105] 480 charging station

Claims

1. A charging control device (10) for a vehicle (100), the charging control device comprising: At least one interface (12) for communicating with the charging infrastructure (5); Control circuit (16), the control circuit being configured to: Process the communication messages of the charging infrastructure. Based on the communication messages, at least one identifier of the operator of the charging infrastructure is determined. Based on the charging infrastructure, the operator determines the selection of a charging contract from multiple charging contracts stored in the charging control device, and The charging control device is certified relative to the charging infrastructure based on the selected charging contract.

2. The charging control device according to claim 1, wherein, The communication message has been received within the framework of the connection established between the charging infrastructure and the charging control device.

3. The charging control device according to claim 1 or 2, wherein, The control circuitry is configured to extract the at least one identifier from a leaf certificate used by the charging infrastructure or from an additional certificate in a certificate chain that includes the leaf certificate.

4. The charging control device according to claim 3, wherein, The at least one identifier includes at least one of the power supply equipment communication controller identifier, i.e., SECCID, and the charging point identifier, i.e., CPID.

5. The charging control device according to any one of claims 1 to 4, wherein, The at least one identifier includes an electric vehicle power supply device identifier, namely EVSEID.

6. The charging control device according to any one of claims 1 to 5, wherein, The control circuitry is configured to determine a plurality of identifiers based on the communication message, and to identify the operator by using one or more of the identifiers.

7. The charging control device according to any one of claims 1 to 6, wherein, The selection is determined based on a data structure in which charging contracts to be selected are defined for multiple operators.

8. The charging control device according to claim 7, wherein, If no charging contract to be selected is defined for a particular operator, then a charging contract to be selected is further defined in the data structure.

9. The charging control device according to any one of claims 1 to 8, wherein, The selection of the charging contract is implemented through the control circuit.

10. The charging control device according to any one of claims 1 to 8, wherein, Determining the selection includes providing information about the at least one identifier to the peer and obtaining information from the peer about the charging contract to be selected, wherein the peer is another controller (105) of the vehicle or a back-end server (200).

11. The charging control device according to any one of claims 1 to 10, wherein, The control circuitry is further configured to obtain from the charging infrastructure a list of supported mobile operators, and further determine the selection of the charging contract based on the list of supported mobile operators.

12. The charging control device according to any one of claims 1 to 11, wherein, The control circuit is further configured to transmit information about the at least one identifier, the selected charging contract, and the success or failure of the authentication to a backend server (200), at least in the event of authentication failure.

13. The charging control device according to any one of claims 1 to 12, wherein, The charging contract and communication with the charging infrastructure are based on the standard ISO 15118.

14. A means (20) for determining the selection of a charging contract, the means comprising: An interface (22) for communicating with the vehicle's charging control device; as well as Control circuit (24), the control circuit being configured to: Information about at least one identifier of the operator of the charging infrastructure is obtained from the charging control device. Based on the charging infrastructure, the operator determines the selection of a charging contract from multiple charging contracts stored in the charging control device, and Information about the charging contract to be selected is provided to the charging control device.

15. A method for a charging control device for a vehicle, the method comprising: Process (110) communication messages for charging infrastructure; Based on the communication message, at least one identifier of the operator of the charging infrastructure is determined (120); Based on the charging infrastructure, the operator determines (130) the selection of a charging contract from a plurality of charging contracts stored in the charging control device; as well as The charging control device is certified (140) based on the selected charging contract relative to the charging infrastructure.

16. A method for determining the selection of a charging contract, the method comprising: (210) Obtain information (210) about at least one identifier of the operator of the charging infrastructure from the charging control device; Based on the charging infrastructure, the operator determines (220) the selection of a charging contract from a plurality of charging contracts stored in the charging control device; as well as Information about the charging contract to be selected is provided (230) to the charging control device.

17. A program including program code, which, when implemented on a computer, processor, control module, control circuit, or programmable hardware component, is used to perform the method according to claim 15 or the method according to claim 16.

Images