Concept for a charging-station-based charging contract selection

Abstract

The invention relates to a charging controller, a device for determining a selection of a charging contract, a vehicle having a charging controller, and corresponding methods and computer programs. The charging controller comprises at least one interface for communication with a charging infrastructure. The charging controller comprises a control circuit designed to process a communication message of the charging infrastructure. The control circuit is designed to determine at least one identifier of an operator of the charging infrastructure based on the communication message. The control circuit is designed to determine, based on the operator of the charging infrastructure, a selection of a charging contract from a plurality of charging contracts stored in the charging controller. The control circuit is designed to authenticate the charging controller with respect to the charging infrastructure based on the selected charging contract.

Description

[0001] Concept for a charging station-based charging contract selection

[0002] Technical area

[0003] The invention relates to a charging control device, a device for determining a selection of a charging contract, a vehicle with a charging control device, and corresponding methods and computer programs.

[0004] background

[0005] Plug & Charge (a charging standard for electric vehicles) is based on the industry standard ISO 15118. Using Plug & Charge, drivers of electric vehicles, such as battery electric vehicles (BEVs) or hybrid vehicles (PHEVs, plug-in hybrid electric vehicles, a hybrid vehicle whose battery can be charged by the engine and by plugging in a charging connector), can authenticate at public charging stations simply by plugging in the charging cable. Authentication is performed using a digital contract certificate in accordance with the standard. The contract certificate contains, among other things, the contract number.The charging point operator (CPO) can use this number to bill the charging process via existing roaming platforms with the contracted provider (EMP or MO, Electro Mobility Provider or Mobility Operator, often the same as the EMP) or directly with the customer (if the CPO is also a contracted provider). The functionality is described in detail below.

[0006] According to the current version of the standard (ISO 15118-2), the vehicle can only transmit one certificate to the charging station; therefore, in many systems, only one certificate is stored on the vehicle. If more than one certificate is installed on the vehicle, the user can, for example, specify which certificate is currently in use. This certificate is stored on the charging control unit and transmitted to the charging station when the charging process is initiated. In some cases, this can lead to incompatibilities if the charging station operator does not support the certificate (for example, because they do not offer roaming, or because one contract, and thus the certificate, only works at an employer's charging station and another contract only works at public charging stations), or it can lead to higher charging costs if the vehicle driver has multiple contracts that result in different costs.There is a need for an improved concept for authenticating a charging controller to a charging infrastructure.

[0007] Description

[0008] This need is taken into account by the subject matter of the independent claims.

[0009] The present invention is based on the finding that the selection of a charging contract that can be used for authentication with a charging infrastructure can be carried out automatically during the initialization of the charging process. For this purpose, the present invention analyzes a communication message transmitted by the charging infrastructure during connection establishment to extract at least one identifier. This at least one infrastructure is then analyzed to draw conclusions about the operator of the charging infrastructure based on the at least one identifier. This is then used, in turn, to automatically select a charging contract and to authenticate the charging control unit with the charging infrastructure based on the charging contract.This makes it possible, for example, to avoid the incompatibilities mentioned above and, on the other hand, to automatically select the contract that results in the lowest costs.

[0010] One aspect of the present invention relates to a charging control unit for a vehicle. The charging control unit comprises at least one interface for communication with a charging infrastructure. The charging control unit comprises a control circuit configured to process a communication message from the charging infrastructure. The control circuit is configured to determine at least one identifier of an operator of the charging infrastructure based on the communication message. The control circuit is configured to determine a selection of a charging contract from a plurality of charging contracts stored in the charging control unit based on the operator of the charging infrastructure. The control circuit is configured to authenticate the charging control unit to the charging infrastructure based on the selected charging contract.This makes it possible, on the one hand, to avoid the incompatibilities mentioned above and, on the other hand, to automatically select the contract that results in the lowest costs.

[0011] For example, the communication message can be received during a connection setup between the charging infrastructure and the charging controller. This enables automated selection during the connection setup, as provided for in the ISO 15118-2 or ISO 15118-20 standards, without the charging infrastructure having to transmit additional information to support the selection of the charging contract, and without causing (excessive) delays in the connection setup.

[0012] There are various locations within or in the communication message where an identifier can point to the operator of the charging infrastructure. For example, such an identifier can be extracted from a digital certificate used to establish Transport Layer Security (TLS) encryption. Accordingly, the control circuit can be configured to extract the at least one identifier from a Leaf certificate used by the charging infrastructure or from another certificate in a certificate chain that includes the Leaf certificate. This Leaf certificate contains information that allows the operator to be identified.In addition, information can be extracted from other certificates in the certificate chain that allow conclusions to be drawn about the operator of the charging infrastructure, for example, from an issuer field or a subject field of the respective certificate. Thus, in addition to the Leaf certificate, the certificate chain also allows conclusions to be drawn about the operator of the charging infrastructure.

[0013] For example, at least one of a Supply Equipment Communication Controller Identifier (SECCID) and a Charge Point Identifier (CPID) can be extracted from the Leaf certificate and used as at least one identifier. These identifiers can be used to identify the operator of the charging infrastructure.

[0014] Alternatively or additionally, the at least one identifier may comprise an identifier used by the charging infrastructure to identify itself to the charging control unit. For example, the at least one identifier may comprise an Electric Vehicle Supply Equipment Identifier (EVSEID). The EVSEID can also be used in some cases to identify the operator of the charging infrastructure.

[0015] Practical implementations have shown that the identifiers transmitted by the charging infrastructure are handled differently by different operators. This sometimes makes it impossible to reliably identify the operator from a single identifier. For example, the control circuit can be configured to determine a plurality of identifiers based on the communication message and, depending on the operator, to use one or more of the identifiers to identify the operator. This increases the reliability of operator recognition. Based on the operator, a charging contract can now be selected. For example, the selection can be determined based on a data structure (such as a decision tree or case differentiation). In this case, a charging contract to be selected can be defined in the data structure for a plurality of operators.This enables the timely selection of a charging contract with low computational complexity. The data structure can also define a charging contract to be selected if no charging contract is defined for an operator. This allows, given the large number of possible operators and / or the emergence of new operators, the selection of a charging contract (e.g., a charging contract from an operator with multiple roaming agreements) to be used by default, enabling the charging process to be carried out even if the operator is unknown.

[0016] In the present concept, the actual selection of the charging contract can take place on the charging control unit or on another control unit in the vehicle (or even on a server in the backend). In other words, the selection of the charging contract can be performed by the control circuit. This enables the selection to be determined with low latency. However, the available memory in the charging control unit is usually limited, so that with a large number of possible operators, not every operator may be supported. Alternatively, determining the selection can comprise providing information about the at least one identifier to a remote station and receiving information about the charging contract to be selected from the remote station. The remote station can be another control unit of the vehicle or a backend server.This allows, for example, a remote station that has more storage space to cover a larger number of operators or to take into account other criteria (night or day electricity, special offers) or has more recent information about the operators to take over the selection, at the cost of higher latency and / or greater implementation complexity.

[0017] In some cases, such as charging communication according to ISO 15118-20, the charging infrastructure can also provide information about which mobility operators are supported by the charging infrastructure. This information can then be used to further improve the selection, for example in cases where the operator is unknown. In other words, the control circuit can be further configured to receive a list of supported mobility operators from the charging infrastructure and to determine the selection of the charging contract based on the list of supported mobility operators. This enables further improvement of the selection, particularly in cases where the operator of the charging infrastructure is unknown to the charging control unit or cannot be determined. In some cases, authentication may fail despite selecting 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 selection criteria in the future. For example, the control circuit can be further 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 event that the authentication fails.

[0018] The proposed invention is particularly applicable within the framework of the Plug & Charge charging standard. Accordingly, the charging contracts and communication with the charging infrastructure can be based on the ISO 15118 standard. However, the basic concept can also be adapted to comparable charging communication standards.

[0019] A further aspect of the present invention relates to a corresponding method for a charging control unit for a vehicle. The method comprises processing a communication message from 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 a charging contract from a plurality of charging contracts stored in the charging control unit based on the operator of the charging infrastructure. The method comprises authenticating the charging control unit to the charging infrastructure based on the selected charging contract. The method can be executed, for example, by the charging control unit.

[0020] A further aspect of the present invention relates to a corresponding program with a program code for carrying out the method for the charging control device when the program code is executed on a computer, a processor, a control module, a control circuit or a programmable hardware component, such as the charging control device.

[0021] A further aspect of the present invention relates to a device for determining a selection of a charging contract. The device comprises an interface for communication with a charging control unit of a vehicle. The device comprises a control circuit configured to receive information about at least one identifier of an operator of a charging infrastructure from the charging control unit. The control circuit is configured to determine a selection of a charging contract from a plurality of charging contracts stored in the charging control unit 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 unit.By implementing the device in another control unit (e.g. a head unit) of the vehicle or in a backend server, the selection of the charging contract can be outsourced from the charging control unit.

[0022] A further aspect of the present invention 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 unit. The method comprises determining a selection of a charging contract from a plurality of charging contracts stored in the charging control unit based on the operator of the charging infrastructure. The method comprises providing information about the charging contract to be selected to the charging control unit. The method can be executed, for example, by a control unit of the vehicle or by a backend server.

[0023] A further aspect of the present invention relates to a corresponding program comprising a program code for carrying out the method for determining a selection of a charging contract when the program code is executed on a computer, a processor, a control module, a control circuit or a programmable hardware component.

[0024] Short character description

[0025] Exemplary embodiments are explained in more detail below with reference to the accompanying figures. They show:

[0026] Fig. 1a shows a schematic diagram of a charging control device;

[0027] Fig. 1b shows a flowchart of a method for a charging control device;

[0028] Fig. 2a shows a schematic diagram of an apparatus for determining a selection of a charging contract;

[0029] Fig. 2b shows a flowchart of a method for determining a selection of a charging contract;

[0030] Fig. 3 shows a schematic diagram of a technical perspective on Plug & Charge;

[0031] Fig. 4 shows a simplified representation of the technical infrastructure for using Plug & Charge; and Fig. 5 shows a diagram of an example of fields in a certificate.

[0032] Description

[0033] Some examples will now be described in more detail with reference to the accompanying figures. However, other possible examples are not limited to the features of these detailed embodiments. These may include modifications of the features, as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe specific examples is not intended to be limiting of other possible examples.

[0034] Throughout the description of the figures, identical or similar reference numerals refer to identical or similar elements or features, which may be implemented identically or in a modified form while providing the same or a similar function. Furthermore, the thickness of lines, layers, and / or regions in the figures may be exaggerated for clarity.

[0035] When two elements A and B are combined using "or," this is to be understood as disclosing all possible combinations, i.e., only A, only B, and both A and B, unless explicitly defined otherwise in the individual case. Alternative wording for the same combinations may be "at least one of A and B" or "A and / or B." This applies equivalently to combinations of more than two elements.

[0036] If a singular form is used, such as "a," "an," and "the," and the use of only a single element is neither explicitly nor implicitly defined as mandatory, further examples may also use multiple elements to implement the same function. If a function is described below as being implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity.It is further understood that the terms “comprises,” “comprising,” “has,” and / or “having,” when used herein, describe the presence of the specified features, integers, steps, operations, processes, elements, components, and / or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components, and / or a group thereof. Fig. 1a shows a schematic diagram of a charging control unit 10 for a vehicle 100, wherein the charging control unit 10 is part of the vehicle 100. The charging control unit comprises at least one interface 12 for communication with a charging infrastructure 5 (such as a charging station), for example via power line communication.In some examples, the at least one interface 12 comprises an interface for communication with another control unit 200 of the vehicle 100 (such as a head unit of the vehicle), at least one interface for communication with a server 205, such as via a telematics connection / mobile radio connection. The charging control unit 10, shown in Fig. 1a, comprises a cryptographically secured element 14, such as a so-called "secure element" or "trusted execution environment." The charging control unit 10 comprises a control circuit 16 coupled to the cryptographically secured element 14 and the at least one interface 12. For example, the cryptographically secured element can be part of the control circuit 16 or a separate component. Optionally, the charging control unit 18 further comprises a memory 18 coupled to the control circuit 16.

[0037] Fig. 1a further shows a system comprising the charging control unit 10 and the control unit 200. Fig. 1a further shows a system comprising the charging control unit 10 and the server 205. Fig. 1a further shows a system comprising the charging control unit 10 and the control unit 200 and the server 205.

[0038] The control circuit 16 is configured to process a communication message from the charging infrastructure. The control circuit 16 is configured to determine at least one identifier of an operator of the charging infrastructure based on the communication message. The control circuit 16 is configured to determine a selection of a charging contract from a plurality of charging contracts stored in the charging control unit based on the operator of the charging infrastructure. The control circuit 16 is configured to authenticate the charging control unit to the charging infrastructure based on the selected charging contract.

[0039] Fig. 1b shows a flowchart of a corresponding method for the charging control unit 10. The method comprises processing 110 the communication message of the charging infrastructure. The method comprises determining 120 the at least one identifier of the operator of the charging infrastructure based on the communication message. The method comprises determining 130 the selection of the charging contract from the plurality of charging contracts stored in the charging control unit based on the operator of the charging infrastructure. The method comprises authenticating 140 the charging control unit to the charging infrastructure based on the selected charging contract. The charging control unit, the corresponding method, and a corresponding computer program are described below with reference to the charging control unit. Features that can be described in connection with the charging control unit can likewise be applied to the corresponding method or computer program.

[0040] In charging communication according to the Plug & Charge standard, charging contracts (also called contract certificates) are used to authenticate the charging control unit to the charging infrastructure (e.g., a charging station). These charging contracts are issued as part of a contract between the driver / user of the vehicle and a so-called mobility provider (mobility operator) and are used by the operator of the charging infrastructure to bill for the supplied charging current. To this end, the mobility provider concludes a contract with the operator of the charging station (unless the mobility provider and the charging station operator are the same entity) that specifies the costs incurred by the mobility provider when a customer of the mobility provider uses the charging infrastructure. The mobility provider, in turn, bills the customer for the services provided by the charging station operator.However, not all mobility providers have concluded contracts with all charging station operators, meaning that the use of a charging infrastructure is not possible with all contracts. In addition, prices vary considerably depending on the contract between the mobility provider and the customer, and the mobility provider and the charging station operator. In current implementations of Plug and Charge (according to ISO 15118-2), often only one certificate is installed with which Plug and Charge can be used. In this case, the user does not have to select the certificate. If more than one certificate is installed on the vehicle, the user can, for example, set which certificate is currently in use. If the vehicle user has multiple contracts with multiple mobility providers, and therefore multiple charging contracts, they are required to select the appropriate contract for the respective charging station.The present invention further automates this selection and deals with charging station-based contract selection, for example in connection with Plug & Charge.

[0041] To at least ensure that the charging contract used is also supported by the charging station operator, the current version of ISO15118-20 of the standard supports a charging station using the SupportedProvidersListType data structure (supported service provider list type) to inform the connected vehicle which contract providers are supported. This function enables the vehicle to use a suitable certificate, provided a suitable one is installed. This partially alleviates the problem by allowing the car to at least select an accepted contract. However, the standard does not provide a mechanism for dealing with, for example, more than one accepted contract. Likewise, the stations currently in widespread use that comply with ISO15118-2 cannot use this mechanism. A subsequent switch to ISO15118-20 may be possible for some charging stations.However, due to various limitations, vehicles cannot be retrofitted to ISO 15118-20, which is why ISO 15118-2 must be supported by all market participants for the foreseeable future. Furthermore, there are usage scenarios from the user perspective in which users may want to use a specific contract with a specific charging station operator because, for example, they receive better terms with this contract from this provider than with the otherwise preferred standard contract.

[0042] The present invention is based on the fact that the operator can be identified by means of a unique identifier of the charging station, which is transmitted during the charging communication. For this purpose, the charging control unit processes the communication message from the charging infrastructure. This communication message can, for example, be a communication message that is exchanged at the beginning of the communication between the charging control unit and the charging infrastructure (i.e. charging station), such as a message from the charging infrastructure to the charging control unit as part of the connection setup. For example, the communication message can have been received as part of a connection setup between the charging infrastructure and the charging control unit. The communication between the charging infrastructure and the charging control unit can be based, for example, on the ISO15118 standard, and in particular ISO15118-2 or ISO15118-20.The loading contracts mentioned here can also be based on standard ISO15118, and in particular ISO15118-2 or ISO 15118-20.

[0043] The control circuit is configured to determine at least one identifier of an operator of the charging infrastructure based on the communication message. Various sources are possible. For example, the so-called EVSEID (Electric Vehicle Supply Equipment Identifier). In other words, the at least one identifier may include the EVSEID. This is transmitted, according to the standard, by the charging station as part of the SessionSetupRes (session setup response). Alternatively or additionally, the SECCID (Supply Equipment Communication Controller Identifier) ​​and / or the CPID (Charge Point Identifier) ​​may be used, each of which is part of the Leaf certificate.The SECCID is part of the SECC (Supply Equipment Communication Controller) Leaf certificate according to ISO15118-20, and the CPID is part of the Leaf certificate according to ISO15118-2. Accordingly, the control circuit can be configured to extract the at least one identifier from a Leaf certificate used by the charging infrastructure. In this case, the at least one identifier can comprise at least one of the Supply Equipment Communication Controller Identifier (SECCID) and the Charge Point Identifier (CPID). In some cases, the CPID can also match the EVSEID. Both the EVSEID and SECCID contain a 3-digit alphanumeric EVSE (Electric Vehicle Supply Equipment) Operator ID (identifier), as well as a 2-digit country code, which (together) identify the charging station operator.

[0044] In addition to the SECCID or CPID, the Leaf certificate also contains additional information found in other certificates in a certificate chain that includes the Leaf certificate, which allows conclusions to be drawn about the operator. Examples of the fields of such a certificate are shown in Big.5. In particular, one or more of the fields "Country," "Organization," and "Common Name" in the Issuer and / or Subject sections can be used to identify the operator of the charging infrastructure. For example, the CPID corresponds to the common name if the certificate is the Leaf certificate according to ISO15118-2. Accordingly, the control circuit can be configured to extract the at least one identifier from a certificate in the certificate chain that includes the Leaf certificate used by the charging infrastructure.The identifier may, for example, include one or more of the above-mentioned fields.

[0045] In an ISO 15118-2 / -20-compliant charging controller, the EVSEID from the SessionSetupRes can be temporarily cached. Additionally, the charging controller can extract and temporarily cache the CPID or SECCID from the SECC Leaf certificate, depending on the standard. Experiments have shown that the EVSEID from the SessionSetupRes is not reliable data in Europe, which is why it may be useful to additionally or alternatively use the information from the certificates, if these are considered more reliable. Accordingly, the control circuit can be configured to determine a plurality of identifiers based on the communication message (e.g., EVSEID and CPID, or EVSEID and SECCID), and to use one or more of the identifiers, depending on the operator, to identify the operator.The decision to use a specific date for automated contract selection can be set via configuration parameters. Alternatively, an algorithm on the charging controller can decide which date is most likely to be correct and use that for the subsequent process.

[0046] The control circuit is designed to determine the selection of the charging contract from the plurality of charging contracts stored in the charging control unit based on the operator of the charging infrastructure. For example, the selection can be determined based on a data structure, wherein a charging contract to be selected is defined in the data structure for a plurality of operators. The data structure can, for example, be stored in the memory 18. In the following, a list of EMAIDs (E-Mobility Account Identifiers) is used as the data structure by way of example. Instead of the list, however, a database or a decision tree can also be used as the data structure. The examples given in connection with the list can also be transferred to a database or a decision tree accordingly. In the examples, the respective EMAID stands for the charging contract to be selected, i.e.The loading contract to be selected is identified by the corresponding EMAID.

[0047] The charging controller, or another entity, can also store a list that represents the specifications for automated contract selection. Each list entry can, for example, contain at least a two-digit country ID, a three-digit operator ID, and the EMAID. Additionally, the list can contain one or more EMAIDs that serve as recourse contracts. In other words, the data structure can further define a charging contract (the one or more recourse contracts) to be selected if no charging contract to be selected is defined for an operator.

[0048] Based on the identified operator, the vehicle can now be informed, for example using a predefined list of contract IDs (EMAID, E-Mobility Account Identifier) ​​and EVSE Operator IDs (which identify the operator), which contract (EMAID) with which operator (EVSE Operator ID) should be automatically selected and used. If a vehicle is now connected to a charging station that supports Plug and Charge, the charging control unit first checks, for example, the EVSEID / SECCID / CPID temporarily stored for this charging process (i.e., at least one identifier). To do this, the Operator ID and the Country ID from this date can now be compared with the list. If an identical entry is found in the list, the EMAID of the list entry can be read and selected.If no matching entry is found, the fallback EMAID can be selected and information about an error can also be saved. This process takes place, for example, after the TLS (Transport Layer Security) connection is established, but before authentication using the Plug & Charge certificate. The selected EMAID refers to the contract that will be used for authentication in the next step at the charging station as part of the Plug & Charge authentication.

[0049] This list can be defined based on various premises (or in combination), such as (known) roaming conditions, customer preferences (set by the customer or learned based on behavior), knowledge of the individual prices for a specific EMAID with a specific charging station operator, and the lowest possible cost for the customer. Furthermore, other prioritization options are explicitly possible. The list can either be created locally on the vehicle or imported and updated into the vehicle via a backend connection. If communication is via ISO15118-20, a comparison can be made with the SupportedProvidersListType.In other words, the control circuit can be further configured to receive a list of supported mobility operators from the charging infrastructure (the SupportedProvidersListType) and to determine the selection of the charging contract based on the list of supported mobility operators. For example, the aforementioned list can contain the same operator ID for multiple EMAIDs. The list can be structured, for example, such that there is one prioritized or one or more fallback contracts (EMAID) for each operator ID. If the provider of the prioritized EMAID is not part of the SupportedProvidersListType, a fallback contract can be selected.

[0050] The list that specifies the automatic selection in the charging control unit can, for example, be created user-specifically in the backend and imported into the charging control unit via a remote connection. The list itself can be created based on customer specifications (individual prioritization of contracts depending on the charging station operator), existing restrictions (e.g., due to roaming of certain contracts with certain stations), taking into account the cheapest price or other criteria, or a combination of these. A contract specified by the customer can be used as a fallback contract, which is to be used if automatic selection of the contract is not possible. In many cases, the selection of the charging contract can be carried out by the control circuit. Alternatively, instead of the charging control unit, several control units that communicate with each other in the vehicle can be involved in the automatic contract selection.Accordingly, determining the selection can comprise providing information about the at least one identifier to a remote station (for example, via the at least one interface 12) and receiving information about the charging contract to be selected from the remote station (for example, via the at least one interface 12). The remote station can be another control unit 105 of the vehicle or a backend server 200. Figures 2a and 2b provide examples of a device, a method, and a computer program that perform the selection on the remote station. For example, the list can be located on another control unit or the backend server, and the charging control unit queries the EMAID to be used for this combination via a vehicle network prior to authentication using the operator ID and country ID / code.The control unit storing the list performs the comparison and sends the selected EMAID, and optionally also a fallback EMAID, back to the charging control unit. In a further variant, the charging control unit or another control unit communicating with the charging control unit can query the preferred EMAID (and fallback EMAID) before each charging process after identifying the operator ID and country ID / code in the backend.

[0051] During the authentication of the charging control unit (for example via at least one interface 12), the certificate of the selected charging contract is now used to cryptographically secure the communication with the charging infrastructure 5 and to identify the charging control unit to the charging infrastructure, and thus to authenticate it.

[0052] After authentication, a message can be sent from the charging control unit to the backend, containing, for example, (at least) the following information: EVSEID, CPID, SECCID, EMAID used, automatic selection successful, authentication successful. In other words, the control circuit can further be configured to transmit, at least in the event that authentication fails, 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 200. This information can be used, on the one hand, to transparently display error cases 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 automatic selection, in particular the aforementioned list.

[0053] The at least one interface 12 may, 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 a code, within a module, between modules, or between modules of different entities.

[0054] In embodiments, the control circuit 16 can correspond to any controller or processor or a programmable hardware component. For example, the control circuit 16 can also be implemented as software programmed for a corresponding hardware component. In this respect, the control circuit 16 can be implemented as programmable hardware with appropriately adapted software. Any processors, such as digital signal processors (DSPs), can be used. Embodiments are not limited to a specific type of processor. Any processor or even multiple processors are conceivable for implementation. In some examples, the control circuit 16 can include the cryptographically secured element 14.

[0055] The memory 18 of the charging control unit can, for example, comprise at least one element from the group consisting of computer-readable storage medium, magnetic storage medium, optical storage medium, hard disk, flash memory, floppy disk, random access memory, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), and network storage. The vehicle 100 can, for example, correspond to a land vehicle, a watercraft, an aircraft, a rail vehicle, a road vehicle, a car, an off-road vehicle, a motor vehicle, or a truck.

[0056] More details and aspects of the charging controller, the corresponding method, and the computer program are mentioned in connection with the concept or examples described below (e.g., Figs. 2a to 4). The charging controller, the corresponding method, and the computer program may include one or more additional optional features corresponding to one or more aspects of the proposed concept or the described examples, as described before or after.

[0057] Fig. 2a shows a schematic diagram of a device 20 for determining a selection of a charging contract. The device 20 comprises at least one interface 22 for communication with a charging control unit 10 (shown in Fig. 1a) of the vehicle. The device comprises a control circuit 24 coupled to the at least one interface 22. The control circuit 24 is configured to receive information about at least one identifier of an operator of a charging infrastructure from the charging control unit (via the interface 22). The control circuit 24 is configured to determine a selection of a charging contract from a plurality of charging contracts stored in the charging control unit based on the operator of the charging infrastructure. The control circuit 24 is configured to provide information about the charging contract to be selected to the charging control unit (via the interface 22).The device 20 can be part of a control unit (such as control unit 200 in Fig. 1a) or part of a backend server (such as backend server 205 in Fig. 1a).

[0058] Fig. 2b shows a flowchart of a corresponding method for determining the selection of the charging contract. The method comprises receiving 210 the information about the at least one identifier of the operator of the charging infrastructure from the charging control unit. The method comprises determining 220 the selection of the charging contract from the plurality of charging contracts stored in the charging control unit 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 unit.

[0059] The selection of the charging contract performed by the device 20 of Fig. 2a and the method of Fig. 2b (and by a corresponding computer program) can, for example, be performed analogously to the selection of the charging contract as described in connection with Figs. 1a and 1b. 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 a code, within a module, between modules, or between modules of different entities.

[0060] In exemplary embodiments, the control circuit 24 can correspond to any controller or processor or a programmable hardware component. For example, the control circuit 24 can also be implemented as software programmed for a corresponding hardware component. In this respect, the control circuit 24 can be implemented as programmable hardware with appropriately adapted software. Any processors, such as digital signal processors (DSPs), can be used. Exemplary embodiments are not limited to a specific type of processor. Any processor or even multiple processors are conceivable for implementation.

[0061] More details and aspects of the device, the corresponding method, and the computer program are mentioned in connection with the concept or examples described below (e.g., Figs. 1a to 1b, 3 to 4). The device, the corresponding method, and the computer program may include one or more additional optional features corresponding to one or more aspects of the proposed concept or the described examples, as described before or after.

[0062] The following provides a brief overview of the mechanisms of Plug & Charge, as used in the present invention, for further understanding. Plug & Charge enables a fully automated and secure charging experience through EV-to-charging station authentication technology (according to ISO 15118). Fig. 3 shows a schematic diagram of a technical perspective on Plug & Charge. First (1.), the vehicle manufacturer (shown as an OEM in Fig. 4) provides a provisioning certificate to an aggregator. In this case, this provisioning certificate includes a user account-specific unique identifier. Then, the vehicle user concludes a charging contract with the mobility operator (MO). As part of concluding the charging contract, the vehicle user provides the vehicle identification number (e.g., the PCID), which can be done by the vehicle manufacturer, for example. The mobility operator creates a contract certificate (3.) for the specified vehicle identification number, which is also provided to the aggregator. The aggregator notifies the OEM (4.) that it has received a contract certificate and optionally forwards it to them (or the contract certificate is retrieved from the OEM as needed). The customer instructs the vehicle manufacturer, and in particular the vehicle, to download and install the contract certificate (5.). During the charging process, the vehicle manufacturer or the vehicle communicates (6.) via ISO 15118 with the charging point operator (CPO), which in turn can then contact the mobility operator via the aggregator and / or a roaming platform regarding payment for the charging process.

[0063] Fig. 4 shows a simplified representation of the technical infrastructure for using Plug & Charge. Fig. 4 shows a charging control unit 410, which can correspond to the charging control unit 10 of Fig. 1a, a user interface control unit 420, which can correspond to the control unit 200 of Fig. 1a, an intermediary 430 (which can be used in the vehicle or during vehicle production), a Plug & Charge coordinator 440 (on the part of the vehicle manufacturer), an aggregator 450, a mobility service provider 460, a charging station operator 470, and the charging station 480. The charging control unit 410 is configured for communication according to ISO 15118 and is responsible for certificate storage and handling (including diagnostic requests). The intermediary is the root certificate authority of the vehicle manufacturer and provides provisioning certificates.

[0064] To install a new contract in the vehicle, and in particular in the charging control unit, the following steps can be performed. To enable the installation of charging contracts (or the corresponding certificates), a so-called commission certificate is required. In the present example, this is carried out by the intermediary 440. The intermediary receives a certificate signing request (CSR) from the charging control unit and provides a private key of the certificate to the charging control unit 430 and a public key to the Plug & Charge coordinator 440. The coordinator publishes the commission certificate (i.e., its public key) to the aggregator 450. The commission certificate contains a cryptographically secured identification code for the vehicle (e.g., the chassis number).

[0065] When a customer signs a charging contract, they provide the vehicle's identification code to the mobility service provider 450 as part of the contract. The mobility service provider creates a new contract certificate. The contract certificate can then be encrypted using the provision certificate (i.e., the public key) so that it can only be decrypted by a charging control unit that has the private key of the provisioning certificate. The appropriate commission certificate is determined using the identification code (i.e., the unique identifier). The aggregator 450 receives the encrypted contract certificate and informs the Plug & Charge coordinator 440. The coordinator can then receive the contract certificate and make it available to the charging control unit, for example, via a telematics connection. Alternatively, the contract certificate can be exchanged via powerline communication between the charging station 480 and the charging control unit 410.If the charging controller has a corresponding contract certificate, it can identify itself via a connection secured by TLS (Transport Layer Security) communication. The charging station identifies itself via a leaf certificate derived from a V2G (Vehicle-to-Grid) root certificate. Using the charging station's leaf certificate, a TLS (e.g., TLS 1.2) connection is first established between the charging station and the vehicle (similar to transport encryption on the internet). The contract certificate is then transmitted. The contract certificate is therefore not part of the TLS chain. In the case of TLS 1.3, another certificate is used, which is described in ISO 15518-20.The charging session is authorized between the charging station 480, the charging station operator 470, and the aggregator 450, whereby the charging station operator 470 can identify the mobility service provider 460 via the aggregator 450. Payment is then made, in accordance with the contract, to the mobility service provider 460 via an e-mobility identifier.

[0066] The user interface control unit comprises a system for a graphical user interface, which can be based, for example, on a graphical operating system for mobile devices and can enable on-board user guidance, vehicle configuration, and Plug & Charge functionality, as well as the actual control unit functionality. The latter communicates with the charging control unit 410 and receives information about provisioning and contract certificates stored there from the charging control unit 410. The graphical user interface system can then provide the option of selecting one of the stored certificates, with the selection being communicated to the charging control unit. The user interface control unit 420 also requests identifiers of new contract certificates (and V2G root certificates) from the Plug & Charge coordinator 440 in order to be able to offer the installation of the contract certificates.If the installation is initiated, the user interface control unit 420 requests the relevant certificates for installation from the Plug & Charge coordinator. These certificates are then forwarded to the charging control unit. For communication between the user interface control unit 420 and the charging control unit 410, diagnostic communication and / or status / configuration communication can be used, for example.

[0067] Fig. 5 shows a diagram of an example of certificate fields used in an EVSE / CPO certificate chain according to the ISO15118-2 or ISO15118-20 standards. These are certificates according to the X.509v3 standard. The certificates include the sections "to-be-signed certificate" (tbsCertificate) with the fields "version", "serial number", and "signature"; "issuer" with the fields "country", "organization", "organizational unit", and "common name"; and "validity"; and "subject" with the fields "country", "organization", "organizational unit", and "domain component". For example, the certificates CPO Sub 1 (Charging Point Operator Sub-Certificate 1), CPO Sub 2 (Charging Point Operator Sub-Certificate 2), and SECC Certificate (as a BLAT certificate) can be used in the certificate chain.Of the fields, the Country, Organization, and Common Name fields in the Issuer and Subject sections are of particular interest for determining at least one identifier. The CPID corresponds to the common name in the Subject section of a Leaf certificate according to ISO 15118-2. Only the CPID is defined in the standard and is therefore the most promising indicator. However, other indicators can also be used.

[0068] The aspects and features described in connection with a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the feature into the further example.

[0069] Examples may further be or relate to a (computer) program with program code for carrying out one or more of the above methods when the program is executed on a computer, a processor, or other programmable hardware component. Steps, operations, or processes of various of the methods described above may therefore also be carried out by programmed computers, processors, or other programmable hardware components. Examples may also cover program storage devices, e.g., digital data storage media, which are machine-, processor-, or computer-readable and encode or contain machine-executable, processor-executable, or computer-executable programs and instructions. The program storage devices may, for example,Digital memories, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives or optically readable digital data storage media may include or be computers, processors, control units, field-programmable logic arrays ((F)PLAs = (Field) Programmable Logic Arrays), field-programmable gate arrays ((F)PGA = (Field) Programmable Gate Arrays), graphics processors (GPU = Graphics Processor Unit), application-specific integrated circuits (ASIC = application-specific integrated circuit), integrated circuits (IC = Integrated Circuit) or one-chip systems (SoC = System-on-a-Chip) programmed to carry out the steps of the methods described above.

[0070] It is further understood that the disclosure of multiple steps, processes, operations, or functions disclosed in the specification or claims should not be construed as necessarily being in the described order, unless explicitly stated in the individual case or absolutely necessary for technical reasons. Therefore, the foregoing description does not limit the performance of multiple steps or functions to any particular order. Furthermore, in further examples, a single step, function, process, or operation may include and / or be broken down into multiple sub-steps, functions, processes, or operations.

[0071] If some aspects in the preceding sections were described in connection with a device or system, these aspects are also to be understood as a description of the corresponding method. For example, a block, a device, or a functional aspect of the device or system can correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in connection with a method are also to be understood as a description of a corresponding block, a corresponding element, a property, or a functional feature of a corresponding device or system.

[0072] The following claims are hereby incorporated into the Detailed Description, each claim being understood to stand on its own as a separate example. It should also be noted that although a dependent claim in the claims refers to a particular combination with one or more other claims, other examples may include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby explicitly contemplated unless it is specifically stated that a particular combination is not intended. Furthermore, features of a claim for any other independent claim are also intended to be included, even if that claim is not directly defined as dependent on that other independent claim.

[0073] List of reference symbols Charging infrastructure Charging control unit Interface Cryptographically secured element Control circuit Memory Device Interface Control circuit Vehicle Processing a communication message from a charging infrastructure; Determining at least one identifier of an operator of the charging infrastructure based on the communication message; Determining a selection of a charging contract from a plurality of charging contracts stored in the charging control unit based on the operator of the charging infrastructure Authenticating the charging control unit to the charging infrastructure based on the selected charging contract.Control unit Backend server Obtaining information about at least one identifier of an operator of a charging infrastructure from a charging control unit Determining a selection of a charging contract from a plurality of charging contracts stored in the charging control unit based on the operator of the charging infrastructure Providing information about the charging contract to be selected to the charging control unit Charging control unit User interface control unit Intermediary Plug & Charge coordinator Aggregator Mobility service provider Operator of a charging station Charging station.

Claims

Patent claims 1. A charging control device (10) for a vehicle (100), the charging control device comprising: at least one interface (12) for communication with a charging infrastructure (5); a control circuit (16) designed to: Processing a communication message from the charging infrastructure, Determining at least one identifier of an operator of the charging infrastructure based on the communication message, 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, and authenticating the charging control device to the charging infrastructure based on the selected charging contract.

2. The charging control device according to claim 1, wherein the communication message was received as part of a connection establishment between the charging infrastructure and the charging control device.

3. The charging control device according to one of claims 1 or 2, wherein the control circuit is configured to extract the at least one identifier from a leaf certificate used by the charging infrastructure or from another certificate of a certificate chain comprising the leaf certificate.

4. The charging controller according to claim 3, wherein the at least one identifier comprises at least one of a Supply Equipment Communication Controller Identifier, SECCID, and a Charge Point Identifier, CPID.

5. The charging controller according to one of claims 1 to 4, wherein the at least one identifier comprises an Electric Vehicle Supply Equipment Identifier, EVSEID.

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

7. The charging control device according to one of claims 1 to 6, wherein the selection is determined based on a data structure, wherein a charging contract to be selected is defined in the data structure for a plurality of operators.

8. The charging control device according to claim 7, wherein the data structure further defines a charging contract to be selected if no charging contract to be selected is defined for an operator.

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

10. The charging control device according to one of claims 1 to 8, wherein determining the selection comprises providing information about the at least one identifier to a counterpart, and receiving information about the charging contract to be selected from the counterpart, wherein the counterpart is a further control device (105) of the vehicle or a backend server (200).

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

12. The charging control device according to one of claims 1 to 11, wherein the control circuit is further configured to transmit, at least in the event that the authentication fails, 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 (200).

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

14. A device (20) for determining a selection of a charging contract, comprising: an interface (22) for communication with a charging control unit of a vehicle; and a control circuit (24) designed to: Receiving information about at least one identifier of an operator of a charging infrastructure from the charging control unit, 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, and providing information about the charging contract to be selected to the charging control device.

15. A method for a charging control device for a vehicle, the method comprising: processing (110) a communication message of a charging infrastructure; Determining (120) at least one identifier of an operator of the charging infrastructure based on the communication message; Determining (130) 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; and Authenticating (140) the charging control unit to the charging infrastructure based on the selected charging contract.

16. A method for determining a selection of a loading contract, comprising: Obtaining (210) information about at least one identifier of an operator of a charging infrastructure from a charging control unit; Determining (220) 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; and Providing (230) information about the charging contract to be selected to the charging control device.

17. A program comprising program code for performing the method according to claim 15 or the method of claim 16 when the program code is executed on a computer, a processor, a control module, a control circuit or a programmable hardware component.

Images