EP4683824A1 - Konzept für eine ladestationsbasierte ladekontraktauswahl - Google Patents

Konzept für eine ladestationsbasierte ladekontraktauswahl

Info

Publication number
EP4683824A1
EP4683824A1 EP24702793.1A EP24702793A EP4683824A1 EP 4683824 A1 EP4683824 A1 EP 4683824A1 EP 24702793 A EP24702793 A EP 24702793A EP 4683824 A1 EP4683824 A1 EP 4683824A1
Authority
EP
European Patent Office
Prior art keywords
charging
contract
control device
operator
infrastructure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24702793.1A
Other languages
English (en)
French (fr)
Inventor
Florian Kotsch
Harald Hofmeier
Holger Wierschin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bayerische Motoren Werke AG
Original Assignee
Bayerische Motoren Werke AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bayerische Motoren Werke AG filed Critical Bayerische Motoren Werke AG
Publication of EP4683824A1 publication Critical patent/EP4683824A1/de
Pending legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/30—Constructional details of charging stations
    • B60L53/305—Communication interfaces
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • B60L53/65—Monitoring or controlling charging stations involving identification of vehicles or their battery types
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • B60L53/66—Data transfer between charging stations and vehicles
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • B60L53/66—Data transfer between charging stations and vehicles
    • B60L53/665—Methods related to measuring, billing or payment
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60Y—INDEXING SCHEME RELATING TO ASPECTS CROSS-CUTTING VEHICLE TECHNOLOGY
    • B60Y2200/00—Type of vehicle
    • B60Y2200/90—Vehicles comprising electric prime movers
    • B60Y2200/91—Electric vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/70—Energy storage systems for electromobility, e.g. batteries
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/7072—Electromobility specific charging systems or methods for batteries, ultracapacitors, supercapacitors or double-layer capacitors
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02T90/10—Technologies relating to charging of electric vehicles
    • Y02T90/12—Electric charging stations
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02T90/10—Technologies relating to charging of electric vehicles
    • Y02T90/16—Information or communication technologies improving the operation of electric vehicles
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02T90/10—Technologies relating to charging of electric vehicles
    • Y02T90/16—Information or communication technologies improving the operation of electric vehicles
    • Y02T90/167—Systems integrating technologies related to power network operation and communication or information technologies for supporting the interoperability of electric or hybrid vehicles, i.e. smartgrids as interface for battery charging of electric vehicles [EV] or hybrid vehicles [HEV]

Definitions

  • 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 to corresponding methods and computer programs.
  • Plug & Charge (a charging standard for charging electric vehicles) is based on the industry standard ISO 15118. Using Plug & Charge, drivers of electric cars, such as battery-electric cars (also called BEV, Battery Electric Vehicle) or hybrid vehicles (also called PHEV, Plug-in Hybrid Electric Vehicle, a motor vehicle with a hybrid drive whose battery can be charged by the engine and by plugging in a charging plug), can authenticate at public charging stations simply by plugging in the charging cable. Authentication is carried out using a digital contract certificate in accordance with the standard. The contract certificate contains, among other things, the contract number.
  • the vehicle can only transmit one certificate to the charging station; therefore, in many systems, only one certificate is kept on the vehicle. If more than one certificate is installed on the vehicle, the user can, for example, set which certificate is currently being used. 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 operator of the charging station 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 can lead to higher charging costs if the driver of the vehicle has several contracts that result in different costs. There is a need for an improved concept for authenticating a charging controller to a charging infrastructure.
  • the present invention is based on the finding that the selection of a charging contract that can be used for authentication to a charging infrastructure can be carried out automatically during the initialization of the charging process.
  • a communication message that the charging infrastructure transmits as part of the connection setup is analyzed in order to extract at least one identifier.
  • This at least one infrastructure is then analyzed in order 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 device to the charging infrastructure based on the charging contract. This makes it possible, for example, on the one hand to avoid the aforementioned incompatibilities and, on the other hand, to automatically select the contract that leads to the lowest costs.
  • the charging control device comprises at least one interface for communication with a charging infrastructure.
  • the charging control device comprises a control circuit designed to process a communication message from 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 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 is designed to authenticate the charging control device to the charging infrastructure based on the selected charging contract. This makes it possible, on the one hand, to avoid the aforementioned incompatibilities and, on the other hand, to automatically select the contract that leads to the lowest costs.
  • the communication message can be received as part of a connection setup between the charging infrastructure and the charging control unit.
  • This enables automated selection as part of the connection setup, as provided for in the ISO 15118-2 or ISO 15118-20 standards, without the charging infrastructure having to provide further information on the Support for the selection of the charging contract and without (excessively) delaying the connection setup.
  • an identifier can point to the operator of the charging infrastructure.
  • an identifier can be extracted from a digital certificate that is used to set up transport layer security (TLS) encryption.
  • the control circuit can be designed 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 has information that allows conclusions to be drawn about the operator.
  • information can also 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 from a subject field of the respective certificate.
  • the certificate chain also allows conclusions to be drawn about the operator of the charging infrastructure.
  • 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.
  • SECCID Supply Equipment Communication Controller Identifier
  • CPID Charge Point Identifier
  • the at least one identifier can comprise an identifier with which the charging infrastructure presents itself to the charging control unit.
  • the at least one identifier can comprise an Electric Vehicle Supply Equipment Identifier (EVSEID).
  • EVSEID Electric Vehicle Supply Equipment Identifier
  • the EVSEID can also be used in some cases to identify the operator of the charging infrastructure.
  • the control circuit can be designed 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 the operator's recognition.
  • a charging contract can now be selected based on the operator. For example, the selection can be determined based on a data structure (such as a decision tree or a case distinction). In this case, a charging contract to be selected can be defined in the data structure for a plurality of operators. This enables a charging contract to be selected promptly, with low computational complexity.
  • a charging contract can also be defined in the data structure to be selected if no charging contract to be selected has been defined for an operator. Given the large number of possible operators and/or the emergence of new operators, this enables the selection of a charging contract (such as a charging contract from an operator with many roaming agreements) that is used as standard in order to be able to carry out the charging process despite an unknown operator.
  • a charging contract such as a charging contract from an operator with many roaming agreements
  • 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).
  • the selection of the charging contract can be carried out by the control circuit. This enables the selection to be determined with a low latency.
  • 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.
  • determining the selection can include providing information about the at least one identifier to a counterpart and receiving information about the charging contract to be selected from the counterpart.
  • the counterpart can be another control unit of the vehicle or a backend server. This means that a counterpart that has more storage space to cover a larger number of operators or to take other criteria (night or day power, special offers) or has more recent information about the operators can take over the selection, at the cost of higher latency and/or higher implementation complexity.
  • 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.
  • the control circuit can be further designed 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, in particular in cases where the operator of the charging infrastructure is unknown to the charging control unit or cannot be determined.
  • authentication may fail.
  • information about this can be transmitted to a backend server in order to improve the selection criteria in the future.
  • the control circuit can further be designed 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 authentication fails.
  • 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 selected for comparable standards for charging communication.
  • a further aspect of the present invention relates to a corresponding method for a charging control device for 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 a 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 to the charging infrastructure based on the selected charging contract.
  • the method can be carried out by the charging control device, for example.
  • 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.
  • 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 device of a vehicle.
  • the device comprises a control circuit designed to receive information about at least one identifier of an operator of a charging infrastructure from the charging control device.
  • the control circuit is designed to determine 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 is designed to provide information about the charging contract to be selected to the Charging control unit.
  • the selection of the charging contract can be outsourced from the charging control unit.
  • 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 device.
  • the method comprises 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 method comprises providing information about the charging contract to be selected to the charging control device.
  • the method can be carried out, for example, by a control device of the vehicle or by a backend server.
  • a further aspect of the present invention relates to a corresponding program with 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.
  • Fig. la shows a schematic diagram of a charging control device
  • Fig. 1b shows a flow chart of a method for a charging control device
  • Fig. 2a shows a schematic diagram of an apparatus for determining a selection of a loading contract
  • Fig. 2b shows a flowchart of a method for determining a selection of a loading contract
  • Fig. 3 shows a schematic diagram of a technical perspective on Plug &Charge
  • Fig. 4 shows a simplified representation of the technical infrastructure for the use of Plug &Charge; and Fig. 5 shows a diagram of an example of fields of a certificate.
  • the charging control device comprises at least one interface 12 for communication with a charging infrastructure 5 (such as a charging station), for example via powerline communication.
  • the at least one interface 12 comprises an interface for communication with another control device 200 of the vehicle 100 (such as a head unit of the vehicle), at least one interface for communication with a server 205, for example via a telematics connection/mobile radio connection.
  • the charging control device 10 shown in Fig. 1a comprises a cryptographically secured 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 to the cryptographically secured element 14 and the at least one interface 12.
  • the cryptographically secured element can be part of the control circuit 16 or a separate component.
  • the charging control device 18 further comprises a memory 18 which is coupled to the control circuit 16.
  • Fig. la further shows a system comprising the charging control device 10 and the control device 200.
  • Fig. la further shows a system comprising the charging control device 10 and the server 205.
  • Fig. la further shows a system comprising the charging control device 10 and the control device 200 and the server 205.
  • the control circuit 16 is designed to process a communication message of the charging infrastructure.
  • the control circuit 16 is designed to determine at least one identifier of an operator of the charging infrastructure based on the communication message.
  • the control circuit 16 is designed to determine 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 is designed to authenticate the charging control device to the charging infrastructure based on the selected charging contract.
  • Fig. 1b shows a flow chart of a corresponding method for the charging control device 10.
  • the method includes processing 110 the communication message of the charging infrastructure.
  • the method includes determining 120 the at least one identifier of the operator of the charging infrastructure based on the communication message.
  • the method includes determining 130 the 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 includes authenticating 140 the charging control device to the charging infrastructure based on the selected charging contract.
  • the charging control device, the corresponding method and a corresponding computer program are described below with reference to the charging control device. Features that can be described in connection with the charging control device can also be applied to the corresponding method or computer program.
  • charging contracts also called contract certificates
  • charging contracts are used to authenticate the charging control unit to the charging infrastructure (such as 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 charging current supplied.
  • the mobility provider concludes a contract with the operator of the charging station (if the mobility provider and the operator of the charging station are not the same entity) which 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 operator of the charging station.
  • Plug and Charge according to ISO 15118-2
  • the user does not have to select. If more than one certificate is installed on the vehicle, the user can, for example, set which certificate is currently being used. If the user of the vehicle has several contracts with several mobility providers, and therefore also several charging contracts, he is therefore required to select the appropriate contract for the respective charging station.
  • the present invention automates this selection further and deals with a charging station-based contract selection, for example in connection with Plug & Charge.
  • the current ISO15118-20 version of the standard supports a charging station using the SupportedProvidersListType data structure to inform the connected vehicle which contract providers are supported.
  • This function enables the vehicle to use a suitable certificate, provided that a suitable one is installed. This partially helps by allowing the car to select at least one accepted contract.
  • the standard does not provide a mechanism for how to deal with more than one accepted contract, for example.
  • the stations that are common today according to ISO15118-2 cannot use this mechanism.
  • a subsequent switch to ISO15118-20 may on the part of charging stations may be possible in some cases.
  • 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.
  • 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 establishment.
  • the communication message can have been received as part of a connection establishment between the charging infrastructure and the charging control unit.
  • the communication between the charging infrastructure and the charging control unit can be based on the ISO15118 standard, and in particular ISO15118-2 or ISO15118-20.
  • the charging contracts mentioned here can also be based on the ISO15118 standard, and in particular ISO15118-2 or ISO 15118-20.
  • the control circuit is designed to determine at least one identifier of an operator of the charging infrastructure based on the communication message.
  • Various sources come into consideration here.
  • the so-called EVSEID Electric Vehicle Supply Equipment Identifier
  • the at least one identifier can comprise the EVSEID.
  • this is transmitted by the charging station as part of the SessionSetupRes (session setup response).
  • the SECCID Serial Equipment Communication Controller Identifier
  • the CPID Charge Point Identifier
  • 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.
  • the control circuit may be configured to extract the at least one identifier from a Leaf certificate used by the charging infrastructure.
  • the at least one identifier may comprise at least one of the Supply Equipment Communication Controller Identifier, SECCID, and the Charge Point Identifier, CPID.
  • the CPID may also match the EVSEID.
  • Both EVSEID and SECCID contain a 3-digit alphanumeric EVSE (Electric Vehicle Supply Equipment, Electric Vehicle Supply Equipment) Operator ID (identifier), as well as a 2-digit country code, which (together) identify the charging station operator.
  • the Leaf certificate also includes further information that can also be 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.
  • the CPID corresponds, for example, to the common name if the certificate is the Leaf certificate in accordance with ISO15118-2.
  • the control circuit can be designed 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 can, for example, include one or more of the above fields.
  • the EVSEID from the SessionSetupRes can be temporarily cached.
  • the charging controller can extract the CPID or SECCID from the SECC Leaf certificate, depending on the standard, and temporarily cache it.
  • the control circuit can be designed to determine a plurality of identifiers based on the communication message (e.g.
  • EVSEID and CPID e.g., a specific date for automated contract selection
  • EVSEID and SECCID e.g., a specific date for automated contract selection
  • the decision to use a specific date for automated contract selection can be set via configuration parameters.
  • an algorithm on the charging control unit can decide which date is most likely correct and use this for the further process.
  • the control circuit is designed to determine the 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, wherein a charging contract to be selected is defined in the data structure for a plurality of operators.
  • the data structure can be stored in the memory 18, for example.
  • a list of EMAIDs E-Mobility Account Identifiers
  • a database or a decision tree can also be used as a data structure.
  • the examples given in the The information given in connection with the list can also be transferred to a database or a decision tree.
  • the respective EMAID stands for the loading contract to be selected, ie the loading contract to be selected is designated by the associated EMAID.
  • the charging controller can also store a list that represents the specification for automated contract selection.
  • Each list entry can, for example, include at least a two-digit country ID, a three-digit operator ID and the EMAID.
  • the list can include one or more EMAIDs that serve as recourse contracts.
  • the data structure can also 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.
  • the vehicle can now be informed, for example using a predefined list of contract ID (EMAID, E-Mobility Account Identifier) and EVSE Operator ID (which identifies the operator), which contract (EMAID) with which operator (EVSE Operator ID) is to be automatically selected and used.
  • EMAID E-Mobility Account Identifier
  • EVSE Operator ID which identifies the operator
  • EMAID E-Mobility Account Identifier
  • the fallback EMAID can be selected and information about an error can also be stored. This process takes place, for example, after the TLS (Transport Layer Security) connection has been established, but before authentication using the Plug & Charge certificate.
  • the selected EMAID refers to the contract that is now used for authentication in the next step at the charging station as part of the Plug and Charge authentication.
  • This list can be defined on the basis of various premises (also in combination), for example based on (known) roaming conditions, customer preference (defined by customers or learned based on behavior), with knowledge of the individual prices of a certain EMAID at a certain charging station operator, according to the cheapest possible costs for the customer. Furthermore, other options for prioritization are also explicitly possible.
  • the list can either be created locally on the vehicle or imported into the vehicle and updated via a backend connection. If communication is carried out using ISO15118-20, a comparison can be made with the SupportedProvidersListType.
  • the control circuit can also be designed 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.
  • the above list can contain the same operator ID for several EMAIDs.
  • the list can be structured, for example, so that there is one prioritized or one or more fallback contracts (EMAID) for each operator ID.
  • EMAID fallback contracts
  • a fallback contract can be selected.
  • the list that specifies the automatic selection in the charging control unit can, for example, be created user-specifically in the backend and fed 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.
  • the selection of the charging contract can be carried out by the control circuit.
  • several control units that communicate with each other in the vehicle can be involved in the automatic contract selection.
  • determining the selection can include providing information about the at least one identifier to a counterpart (for example via the at least one interface 12) and receiving information about the charging contract to be selected from the counterpart (for example via the at least one interface 12).
  • the counterpart can be another control unit 105 of the vehicle or a backend server 200.
  • Figures 2a and 2b show examples of a device, a method and a computer program that carry out the selection on the counterpart.
  • the list can be on another control unit or the backend server and the charging control unit queries which EMAID is to be used for this combination via a vehicle network before authentication using the operator ID and country ID/code.
  • the control unit on which the list is stored carries out the comparison and sends the selected EMAID, and optionally also a fallback EMAID, back to the charging control unit.
  • the charging control unit or another control unit that communicates 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.
  • the certificate of the selected charging contract is now used to establish communication with the Charging infrastructure 5 is to be cryptographically secured and the charging control unit is to be identified to the charging infrastructure and thus authenticated.
  • a message can be sent from the charging control unit to the backend, which contains, for example, (at least) the following information: EVSEID, CPID, SECCID, EMAID used, automatic selection successful, authentication successful.
  • the control circuit can also be designed 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 200, at least in the event that the authentication fails.
  • This information can be used on the one hand to display error cases transparently 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.
  • 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.
  • control circuit 16 can correspond to any controller or processor or a programmable hardware component.
  • control circuit 16 can also be implemented as software that is programmed for a corresponding hardware component.
  • 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 restricted to a specific type of processor. Any processor or even multiple processors are conceivable for implementation.
  • the control circuit 16 can include the cryptographically secured element 14.
  • the memory 18 of the charging controller can, for example, comprise at least one element of the group 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 may, 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.
  • the charging controller, the corresponding method and the computer program may comprise 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.
  • 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 communicating with a charging control device 10 (shown in Fig. 1a) of the vehicle.
  • the device comprises a control circuit 24 which is coupled to the at least one interface 22.
  • the control circuit 24 is designed to receive information about at least one identifier of an operator of a charging infrastructure from the charging control device (via the interface 22).
  • the control circuit 24 is designed to determine 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 24 is designed to provide information about the charging contract to be selected to the charging control device (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).
  • Fig. 2b shows a flow chart of a corresponding method for determining the selection of the charging contract.
  • the method includes obtaining 210 the information about the at least one identifier of the operator of the charging infrastructure from the charging control device.
  • the method includes determining 220 the 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 includes providing 230 the information about the charging contract to be selected to the charging control device.
  • the selection of the charging contract carried out by the device 20 of Fig. 2a and the method of Fig. 2b (and by a corresponding computer program) can, for example, be carried out analogously to the selection of the charging contract as described in connection with Figs. 1a and 1b.
  • the at least one interface 22 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.
  • control circuit 24 can correspond to any controller or processor or a programmable hardware component.
  • control circuit 24 can also be implemented as software that is programmed for a corresponding hardware component.
  • control circuit 24 can be implemented as programmable hardware with appropriately adapted software.
  • Any processors, such as digital signal processors (DSPs), can be used. Embodiments are not restricted to a specific type of processor. Any processor or even multiple processors are conceivable for implementation.
  • the device, the corresponding method and the computer program may comprise 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.
  • Plug & Charge enables a fully automated and secure charging experience through the authentication technology from EV to charging station (according to ISO 15118).
  • Fig. 3 shows a schematic diagram of a technical perspective on Plug & Charge.
  • the vehicle manufacturer shown as OEM in Fig. 4
  • this provisioning certificate includes a user account-specific unique identifier.
  • the vehicle user concludes a charging contract with the mobility operator (MO).
  • the vehicle user provides the vehicle identification number (e.g. the PCID), which can be done by the vehicle manufacturer, for example.
  • the vehicle identification number e.g. the PCID
  • 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 it (or the contract certificate is retrieved from the OEM as required).
  • the customer instructs the vehicle manufacturer, and in particular the vehicle, to download and install the contract certificate (5.).
  • the The vehicle manufacturer or the vehicle communicates 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.
  • CPO charging point operator
  • Fig. 4 shows a simplified representation of the technical infrastructure for the use of 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 production of the vehicle), a Plug & Charge coordinator 440 (on the part of the vehicle manufacturer), an aggregator 450, a mobility service provider 460, an operator of the charging station 470, and the charging station 480.
  • the charging control unit 410 is designed for communication in accordance with ISO 15118 and is responsible for certificate storage and handling (including diagnostic orders).
  • the intermediary is the root certificate authority of the vehicle manufacturer and provides provisioning certificates.
  • a so-called commission certificate is required.
  • 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 (such as the chassis number).
  • 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 now 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 provision 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 about it.
  • the coordinator can now receive the contract certificate and make it available to the charging control unit, for example via a telematics connection.
  • the contract certificate can be exchanged via powerline communication between the charging station 480 and the charging control unit 410.
  • the charging controller has a corresponding contract certificate, it can identify itself via the contract certificate over a connection that is secured by means of TLS (Transport Layer Security) communication.
  • the charging station identifies itself using a leaf certificate that is derived from a V2G (vehicle-to-grid) root certificate.
  • a TLS such as a TLS 1.2
  • the contract certificate is then transmitted.
  • the contract certificate is therefore not part of the TLS chain.
  • TLS 1.3 another certificate is used that is described in ISO15518-20.
  • the charging session is authorized between the charging station 480, the operator of the charging station 470 and the aggregator 450, whereby the operator 470 of the charging station can determine 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.
  • the user interface control unit comprises a system for a graphical interface, which can be based on a graphical operating system for mobile devices, for example, and can enable user guidance on board as well as configuration of the vehicle and the 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 system for the graphical interface can now provide an option to select 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.
  • the user interface control unit 420 If the installation is initiated, the user interface control unit 420 requests the respective certificates for installation from the Plug & Charge coordinator. These are then passed on to the charging control unit. For communication between user interface control unit 420 and charging control unit 410, for example, diagnostic communication and/or status/configuration communication can be used.
  • Fig. 5 shows a diagram of an example of fields of a certificate as used in an EVSE/CPO certificate chain of 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, validity and subject with the fields country, organization, organizational unit, common name and domain component.
  • the certificates CPO Sub 1 (charging point operator sub-certificate 1)
  • CPO Sub 2 charging point operator sub-certificate 2
  • SECC certificate as a leaf certificate.
  • the CPID corresponds to the common name in the Subject section of a leaf certificate according to ISO15118-2. Only the CPID is defined in the standard and is therefore the most promising indicator. However, other indicators can also be used.
  • Examples may further be or relate to a (computer) program with a program code for carrying out one or more of the above methods when the program is executed on a computer, a processor or another programmable hardware component. Steps, operations or processes of various of the methods described above may thus 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 include or be, for example, digital memories, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives or optically readable digital data storage media.
  • FIG. 1 Further examples may also cover computers, processors, controllers, field-programmable logic arrays ((F)PLAs), field-programmable gate arrays ((F)PGAs), graphics processor units (GPUs), application-specific integrated circuits (ASICs), integrated circuits (ICs), or systems-on-a-chip (SoCs) programmed to perform the steps of the methods described above.
  • FPLAs field-programmable logic arrays
  • FPGAs field-programmable gate arrays
  • GPUs graphics processor units
  • ASICs application-specific integrated circuits
  • ICs integrated circuits
  • SoCs systems-on-a-chip
  • 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 a corresponding system.
  • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Transportation (AREA)
  • Power Engineering (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Charge And Discharge Circuits For Batteries Or The Like (AREA)

Abstract

Die Erfindung bezieht sich auf ein Ladesteuergerät, eine Vorrichtung zum Ermitteln einer Auswahl eines Ladekontraktes, ein Fahrzeug mit einem Ladesteuergerät, sowie auf entsprechende Verfahren und Computerprogramme. Das Ladesteuergerät umfasst zumindest eine Schnittstelle zur Kommunikation mit einer Ladeinfrastruktur. Das Ladesteuergerät umfasst eine Steuerungsschaltung, ausgebildet zum Verarbeiten einer Kommunikationsnachricht der Ladeinfrastruktur. Die Steuerungsschaltung ist ausgebildet zum Bestimmen zumindest eines Identifikators eines Betreibers der Ladeinfrastruktur basierend auf der Kommunikationsnachricht. Die Steuerungsschaltung ist ausgebildet zum Ermitteln einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur. Die Steuerungsschaltung ist ausgebildet zum Authentifizieren des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt.

Description

Konzept für eine ladestationsbasierte Ladekontraktauswahl
Technisches Gebiet
Die Erfindung bezieht sich auf ein Ladesteuergerät, eine Vorrichtung zum Ermitteln einer Auswahl eines Ladekontraktes, ein Fahrzeug mit einem Ladesteuergerät, sowie auf entsprechende Verfahren und Computerprogramme.
Hintergrund
Plug & Charge (Einstecken und Laden, ein Ladestandards für das Laden von Elektrofahrzeugen) basiert auf dem Industriestandard ISO 15118. Unter Nutzung von Plug & Charge können Fahrer von Elektroautos, etwa batterieelektrischen Autos (auch BEV, Battery Electric Vehicle, genannt) oder Hybridfahrzeugen (auch PHEV, Plug-in Hybrid Electric Vehicle, ein Kraftfahrzeug mit Hybridantrieb, dessen Akku von dem Motor und durch Einstecken („Plug-In“) eines Ladesteckers geladen werden kann), an öffentlichen Ladesäulen nur durch Einstecken des Ladekabels authentifizieren. Die Authentifizierung erfolgt dabei mit einem digitalen Vertragszertifikat gemäß Norm. Das Vertragszertifikat enthält unter anderem die Vertragsnummer. Der Lade Säulenbetreiber (CPO, Charging Point Operator) kann mit dieser Nummer über die bestehenden Roamingplattformen mit dem Vertragsanbieter (EMP oder MO, Electro Mobility Provider / Elektromobilitätsbereitsteller oder Mobility Operator / Mobilitätsoperator, oft derselbe wie der EMP) den Ladevorgang abrechnen oder direkt mit dem Kunden abrechnen (falls CPO gleichzeitig Vertragsanbieter ist). Die Funktionsweise wird im Detail im weiteren Verlauf beschrieben.
Gemäß dem bisherigem Stand der Norm (ISO 15118-2) kann das Fahrzeug der Ladesäule nur ein Zertifikat übermitteln; daher wird in vielen Systemen nur ein Zertifikat auf dem Fahrzeug vorgehalten. Wenn mehr als ein Zertifikat auf dem Fahrzeug installiert wird, kann beispielsweise durch den Nutzer eingestellt werden, welches Zertifikat aktuell verwendet wird. Dieses Zertifikat wird auf dem Ladesteuergerät gespeichert und, beim Initiieren des Ladevorgangs, der Ladesäule übermittelt. Dies kann in manchen Fällen zu Inkompatibilitäten führen, wenn der Betreiber der Ladesäule das Zertifikat nicht unterstützt (etwa, da er kein Roaming anbietet, oder weil ein Vertrag, und damit das Zertifikat, nur an einer Ladesäule des Arbeitgebers funktioniert und ein anderer Vertrag nur an öffentlichen Ladesäulen funktioniert), oder kann zu höheren Ladekosten führen, falls der Fahrer des Fahrzeugs über mehrere Verträge verfügt, die unterschiedliche Kosten zur Folge haben. Es besteht der Bedarf nach einem verbesserten Konzept zur Authentifizierung eines Ladesteuergeräts gegenüber einer Ladeinfrastruktur.
Beschreibung
Diesem Bedarf wird durch den Gegenstand der unabhängigen Ansprüche Rechnung getragen.
Die vorliegende Erfindung basiert auf der Erkenntnis, dass die Auswahl eines Ladekontrakts, der für die Authentifizierung gegenüber einer Ladeinfrastruktur genutzt werden kann, automatisiert während der Initialisierung des Ladevorgangs durchgeführt werden kann. Zu diesem Zweck wird in der vorliegenden Erfindung eine Kommunikationsnachricht, die die Ladeinfrastruktur im Rahmen des Verbindungsaufbaus übermittelt analysiert, um zumindest einen Identifikator zu extrahieren. Dieser zumindest eine Infrastruktur wird daraufhin analysiert, um basierend auf dem zumindest einen Identifikator Rückschlüsse auf den Betreiber der Ladeinfrastruktur zu ziehen. Dieser wird nun wiederum genutzt, um automatisiert einen Ladekontrakt auszuwählen und um das Ladesteuergerät basierend auf dem Ladekontrakt gegenüber der Ladeinfrastruktur zu authentifizieren. Dies ermöglicht es beispielsweise einerseits, die zuvor genannten Inkompatibilitäten zu vermeiden und andererseits, automatisiert denjenigen Vertrag auszuwählen, der zu den geringsten Kosten führt.
Ein Aspekt der vorliegenden Erfindung bezieht sich auf ein Ladesteuergerät für ein Eahrzeug. Das Ladesteuergerät umfasst zumindest eine Schnittstelle zur Kommunikation mit einer Ladeinfrastruktur. Das Ladesteuergerät umfasst eine Steuerungsschaltung, ausgebildet zum Verarbeiten einer Kommunikationsnachricht der Ladeinfrastruktur. Die Steuerungsschaltung ist ausgebildet zum Bestimmen zumindest eines Identifikators eines Betreibers der Ladeinfrastruktur basierend auf der Kommunikationsnachricht. Die Steuerungsschaltung ist ausgebildet zum Ermitteln einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Lade Steuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur. Die Steuerungsschaltung ist ausgebildet zum Authentifizieren des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt. Dies ermöglicht es einerseits, die zuvor genannten Inkompatibilitäten zu vermeiden und andererseits, automatisiert denjenigen Vertrag auszuwählen, der zu den geringsten Kosten führt.
Beispielsweise kann die Kommunikationsnachricht im Rahmen eines Verbindungsaufbaus zwischen der Ladeinfrastruktur und dem Ladesteuergerät empfangen werden. Dies ermöglicht die automatisierte Auswahl im Rahmen des Verbindungsaufbaus, wie er etwa in den Standards ISO 15118-2 oder ISO 15118-20 vorgesehen ist, ohne dass die Ladeinfrastruktur weitergehende Informationen zur Unterstützung der Auswahl des Ladekontrakts übermitteln muss, und ohne, dass der Verbindungsaufbau dadurch (übermäßig) verzögert wird.
Es gibt verschiedene Stellen innerhalb oder an der Kommunikationsnachricht, an denen ein Identifikator auf den Betreiber der Ladeinfrastruktur hinweisen kann. Beispielsweise kann ein solches Identifikator aus einem digitalen Zertifikat, das zum Aufbau einer Transportebenensicherheits- Verschlüsselung (TLS, Transport Layer Security) verwendet wird, extrahiert werden. Entsprechend kann die Steuerungsschaltung ausgebildet sein, um den zumindest einen Identifikator aus einem Leaf- Zertifikat (engl. für Blatt-Zertifikat), das von der Ladeinfrastruktur verwendet wird, oder aus einem anderen Zertifikat einer Zertfikatskette, die das Leaf-Zertifikat umfasst, zu extrahieren. Dieses Leaf- Zertifikat verfügt über Informationen, die den Rückschluss auf den Betreiber zulassen. Zudem können auch Informationen aus anderen Zertifikaten der Zertifikatskette extrahiert werden, die Rückschluss auf den Betreiber der Ladeinfrastruktur zulassen, etwa aus einem Issuer (Herausgeber)-Eeld, oder aus einem Subject (Gegenstand)-Eeld des jeweiligen Zertifikats. Somit ermöglicht neben dem Leaf- Zertifikat auch die Zertifikatskette Rückschlüsse auf den Betreiber der Ladeinfrastruktur.
Aus dem Leaf-Zertifikat kann beispielsweise zumindest eines von einem Supply Equipment Communication Controller Identifier (SECCID, Identifikator des Kommunikationssteuergeräts der Versorgungsausrüstung) und einem Charge Point Identifier (CPID, Ladepunktidentifikator) extrahiert werden und als zumindest einer Identifikator verwendet werden. Diese Identifikatoren können genutzt werden, um den Betreiber der Ladeinfrastruktur zu identifizieren.
Alternativ oder zusätzlich kann der zumindest eine Identifikator einen Identifikator umfassen, mit der sich die Ladeinfrastruktur gegenüber dem Ladesteuergerät vorstellt. Beispielsweise kann der zumindest eine Identifikator einen Electric Vehicle Supply Equipment Identifier (EVSEID, Identifikator der Elektrofahrzeugversorgungsausrüstung) umfassen. Auch die EVSEID kann in manchen Lällen genutzt werden, um den Betreiber der Ladeinfrastruktur zu identifizieren.
In praktischen Implementierungen hat sich gezeigt, dass die von der Ladeinfrastruktur übermittelten Identifikatoren von den verschiedenen Betreibern unterschiedlich gehandhabt werden. Dadurch ist es bisweilen nicht möglich, aus einem einzigen Identifikator zuverlässig auf den Betreiber zu schließen. Beispielsweise kann die Steuerungsschaltung ausgebildet sein, um eine Mehrzahl von Identifikatoren basierend auf der Kommunikationsnachricht zu bestimmen, und um je nach Betreiber einen oder mehrere der Identifikatoren zu verwenden, um den Betreiber zu identifizieren. Dies erhöht die Zuverlässigkeit der Erkennung des Betreibers. Ausgehend von dem Betreiber kann nun ein Ladekontrakt ausgewählt werden. Beispielsweise kann die Auswahl basierend auf einer Datenstruktur (wie etwa einem Entscheidungsbaum oder einer Fallunterscheidung) ermittelt werden. Dabei kann in der Datenstruktur für eine Mehrzahl von Betreibern ein auszuwählender Ladekontrakt definiert sein. Dies ermöglicht eine zeitnahe Auswahl eines Ladekontrakts, bei einer geringen Rechenkomplexität. In der Datenstruktur kann ferner ein Ladekontrakt definiert sein, der auszuwählen ist, falls für einen Betreiber kein auszuwählender Ladekontrakt definiert ist. Dies ermöglicht, bei der Vielzahl von möglichen Betreibern und/oder beim Aufkommen neuer Betreiber die Auswahl eines Ladekontrakts (etwa eines Ladekontrakts eines Betreibers mit vielen Roaming -Abkommen), der standardmäßig verwendet wird, um trotz unbekanntem Betreiber den Ladevorgang durchführen zu können.
Im vorliegenden Konzept kann die eigentliche Auswahl des Ladekontrakts auf dem Lade Steuergerät oder auf einem anderen Steuergerät im Fahrzeug (oder sogar auf einem Server im Backend erfolgen). In anderen Worten kann die Auswahl des Ladekontrakts durch die Steuerungsschaltung durchgeführt werden. Diese ermöglicht ein Ermitteln der Auswahl mit einer geringen Latenz. Allerdings ist ein verfügbarer Speicher in dem Ladesteuergerät meist begrenzt, so dass hier bei einer Vielzahl von möglichen Betreibern möglicherweise nicht jeder Betreiber unterstützt werden kann. Alternativ kann das Ermitteln der Auswahl ein Bereitstellen einer Information über den zumindest einen Identifikator an eine Gegenstelle, und ein Erhalten einer Information über den auszuwählenden Ladekontrakt von der Gegenstelle umfassen. Dabei kann die Gegenstelle ein weiteres Steuergerät des Fahrzeugs oder ein Backend-Server sein. Hierdurch kann etwa eine Gegenstelle die Auswahl übernehmen, die über mehr Speicherplatz zur Abdeckung einer größeren Anzahl von Betreibern oder zur Berücksichtigung anderer Kriterien (Nacht- oder Tagstrom, Sonderangebote) oder über neuere Informationen über die Betreiber verfügen, auf Kosten einer höheren Latenz und/oder einer höheren Implementierungskomplexität.
In manchen Fällen, etwa bei der Ladekommunikation gemäß ISO 15118-20, kann die Ladeinfrastruktur auch Informationen darüber bereitstellen, welche Mobilitätsoperatoren von der Ladeinfrastruktur unterstützt werden. Diese Informationen können dann genutzt werden, um die Auswahl weiter zu verbessern, etwa in Fällen, in denen der Betreiber nicht bekannt ist. In anderen Worten kann die Steuerungsschaltung ferner ausgebildet sein, um eine Liste mit unterstützten Mobilitätsoperatoren von der Ladeinfrastruktur zu erhalten, und um die Auswahl des Ladekontrakts ferner basierend auf der Liste mit unterstützten Mobilitätsoperatoren zu ermitteln. Dies ermöglicht eine weitere Verbesserung der Auswahl, insbesondere in Fällen, in denen der Betreiber der Ladeinfrastruktur dem Ladesteuergerät nicht bekannt ist oder nicht ermittelt werden kann. In manchen Fällen kann es, trotz Auswahl des Ladekontrakts basierend auf dem Betreiber der Ladeinfrastruktur, vorkommen, dass die Authentifizierung fehlschlägt. In diesen Fällen können Informationen darüber an einen Backend-Server übermittelt werden, um die Kriterien zur Auswahl in Zukunft zu verbessern. Beispielsweise kann die Steuerungsschaltung ferner ausgebildet sein, um, zumindest in dem Fall, dass die Authentifizierung fehlschlägt, eine Information über den zumindest einen Identifikator, über den ausgewählten Ladekontrakt, und über den Erfolg oder Misserfolg der Authentifizierung an einen Backend-Server zu übermitteln.
Die vorgeschlagene Erfindung ist insbesondere im Rahmen des Plug & Charge -Lade standards anwendbar. Entsprechen können die Ladekontrakte und eine Kommunikation mit der Ladeinfrastruktur auf dem Standard ISO 15118 basieren. Jedoch ist das Grundkonzept auch auf vergleichbare Standards zur Ladekommunikation auswählbar.
Ein weiterer Aspekt der vorliegenden Erfindung bezieht sich auf ein entsprechendes Verfahren für ein Ladesteuergerät für ein Fahrzeug. Das Verfahren umfasst ein Verarbeiten einer Kommunikationsnachricht einer Ladeinfrastruktur. Das Verfahren umfasst ein Bestimmen zumindest eines Identifikators eines Betreibers der Ladeinfrastruktur basierend auf der Kommunikationsnachricht. Das Verfahren umfasst ein Ermitteln einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur. Das Verfahren umfasst ein Authentifizieren des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt. Das Verfahren kann beispielsweise von dem Ladesteuergerät ausgeführt werden.
Ein weiterer Aspekt der vorliegenden Erfindung bezieht sich auf ein entsprechendes Programm mit einem Programmcode zum Durchführen des Verfahrens für das Ladesteuergerät, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul, einer Steuerungsschaltung oder einer programmierbaren Hardwarekomponente, etwa des Ladesteuergeräts, ausgeführt wird.
Ein weiterer Aspekt der vorliegenden Erfindung bezieht sich auf eine Vorrichtung zum Ermitteln einer Auswahl eines Ladekontrakts. Die Vorrichtung umfasst eine Schnittstelle zur Kommunikation mit einem Ladesteuergerät eines Fahrzeugs. Die Vorrichtung umfasst eine Steuerungsschaltung, ausgebildet zum Erhalten einer Information über zumindest einen Identifikator eines Betreibers einer Ladeinfrastruktur von dem Ladesteuergerät. Die Steuerungsschaltung ist ausgebildet zum Ermitteln einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur. Die Steuerungsschaltung ist ausgebildet zum Bereitstellen einer Information über den auszuwählenden Ladekontrakt an das Ladesteuergerät. Durch Implementierung der Vorrichtung in einem anderen Steuergerät (etwa einer „Head Unit“, Kopfeinheit) des Fahrzeugs oder in einem Backend-Server kann die Auswahl des Ladekontrakts aus dem Ladesteuergerät ausgelagert werden.
Ein weiterer Aspekt der vorliegenden Erfindung bezieht sich auf ein entsprechendes Verfahren zum Ermitteln einer Auswahl eines Ladekontrakts. Das Verfahren umfasst ein Erhalten einer Information über zumindest einen Identifikator eines Betreibers einer Ladeinfrastruktur von einem Ladesteuergerät. Das Verfahren umfasst ein Ermitteln einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur. Das Verfahren umfasst ein Bereitstellen einer Information über den auszuwählenden Ladekontrakt an das Ladesteuergerät. Das Verfahren kann beispielsweise von einem Steuergerät des Fahrzeugs oder von einem Backend-Server ausgeführt werden.
Ein weiterer Aspekt der vorliegenden Erfindung bezieht sich auf ein entsprechendes Programm mit einem Programmcode zum Durchführen des Verfahrens zum Ermitteln einer Auswahl eines Ladekontrakts, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul, einer Steuerungsschaltung oder einer programmierbaren Hardwarekomponente ausgeführt wird.
Figurenkurzbeschreibung
Ausführungsbeispiele werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert. Es zeigen:
Fig. la zeigt ein schematisches Diagramm eines Ladesteuergeräts;
Fig. 1b zeigt ein Flussdiagramm eines Verfahrens für ein Ladesteuergerät;
Fig. 2a zeigt ein schematisches Diagramm einer Vorrichtung zum Ermitteln einer Auswahl eines Ladekontrakts;
Fig. 2b zeigt ein Flussdiagramm eines Verfahrens zum Ermitteln einer Auswahl eines Ladekontrakts;
Fig. 3 zeigt ein schematisches Diagramm einer technischen Perspektive auf Plug & Charge;
Fig. 4 zeigt eine vereinfachte Darstellung der technischen Infrastruktur für die Nutzung von Plug & Charge; und Fig. 5 zeigt ein Diagramm eines Beispiels von Feldern eines Zertifikats.
Beschreibung
Einige Beispiele werden nun ausführlicher Bezug nehmend auf die beiliegenden Figuren beschrieben. Weitere mögliche Beispiele sind jedoch nicht auf die Merkmale dieser detailliert beschriebenen Ausführungsformen beschränkt. Diese können Modifikationen der Merkmale sowie Entsprechungen und Alternativen zu den Merkmalen aufweisen. Ferner soll die Terminologie, die hierin zum Beschreiben bestimmter Beispiele verwendet wird, nicht einschränkend für weitere mögliche Beispiele sein.
Gleiche oder ähnliche Bezugszeichen beziehen sich in der gesamten Beschreibung der Figuren auf gleiche oder ähnliche Elemente beziehungsweise Merkmale, die jeweils identisch oder auch in abgewandelter Form implementiert sein können, während sie die gleiche oder eine ähnliche Funktion bereitstellen. In den Figuren können ferner die Stärken von Linien, Schichten und/oder Bereichen zur Verdeutlichung übertrieben sein.
Wenn zwei Elemente A und B unter Verwendung eines „oder“ kombiniert werden, ist dies so zu verstehen, dass alle möglichen Kombinationen offenbart sind, d. h. nur A, nur B sowie A und B, sofern nicht im Einzelfall ausdrücklich anders definiert. Als alternative Formulierung für die gleichen Kombinationen kann „zumindest eines von A und B“ oder „A und/oder B“ verwendet werden. Das gilt Äquivalent für Kombinationen von mehr als zwei Elementen.
Wenn eine Singularform, z. B. „ein, eine“ und „der, die, das“ verwendet wird und die Verwendung nur eines einzelnen Elements weder explizit noch implizit als verpflichtend definiert ist, können weitere Beispiele auch mehrere Elemente verwenden, um die gleiche Funktion zu implementieren. Wenn eine Funktion im Folgenden als unter Verwendung mehrerer Elemente implementiert beschrieben ist, können weitere Beispiele die gleiche Funktion unter Verwendung eines einzelnen Elements oder einer einzelnen Verarbeitungsentität implementieren. Es versteht sich weiterhin, dass die Begriffe „umfasst“, „umfassend“, „aufweist“ und/oder „aufweisend“ bei deren Gebrauch das Vorhandensein der angegebenen Merkmale, Ganzzahlen, Schritte, Operationen, Prozesse, Elemente, Komponenten und/oder einer Gruppe derselben beschreiben, dabei aber nicht das Vorhandensein oder das Hinzufügen eines oder mehrerer anderer Merkmale, Ganzzahlen, Schritte, Operationen, Prozesse, Elemente, Komponenten und/einer Gruppe derselben ausschließen. Fig. la zeigt ein schematisches Diagramm eines Ladesteuergeräts 10 für ein Fahrzeug 100, wobei das Ladesteuergerät 10 Teil des Fahrzeugs 100 ist. Das Lade Steuergerät umfasst zumindest eine Schnittstelle 12 zur Kommunikation mit einer Ladeinfrastruktur 5 (etwa einer Ladesäule), etwa über eine Powerline -Kommunikation. In manchen Beispielen umfasst die zumindest eine Schnittstelle 12 eine Schnittstelle zur Kommunikation mit einem anderen Steuergerät 200 des Fahrzeugs 100 (etwa einer Head Unit des Fahrzeugs), zumindest eine Schnittstelle zur Kommunikation mit einem Server 205, etwa über eine Telematikverbindung/Mobilfunkverbindung. Das Ladesteuergerät 10, die in Fig. la gezeigt ist, umfasst ein kryptografisch gesichertes Element 14, etwa ein sogenanntes „Secure Element“ oder „Trusted Execution Environment“ (Ausführungsumgebung, der vertraut wird). Das Ladesteuergerät 10 umfasst eine Steuerungsschaltung 16, die mit dem kryptografisch gesicherten Element 14 und der zumindest einen Schnittstelle 12 gekoppelt ist. Beispielsweise kann das kryptografisch gesicherte Element ein Teil der Steuerungsschaltung 16 sein oder ein separates Bauteil sein. Optional umfasst das Ladesteuergerät 18 ferner einen Speicher 18, der mit der Steuerungsschaltung 16 gekoppelt ist.
Fig. la zeigt ferner ein System umfassend das Ladesteuergerät 10 und das Steuergerät 200. Fig. la zeigt ferner ein System umfassend das Ladesteuergerät 10 und den Server 205. Fig. la zeigt ferner ein System umfassend das Ladesteuergerät 10 und das Steuergerät 200 und den Server 205.
Die Steuerungsschaltung 16 ist ausgebildet zum Verarbeiten einer Kommunikationsnachricht der Ladeinfrastruktur. Die Steuerungsschaltung 16 ist ausgebildet zum Bestimmen zumindest eines Identifikators eines Betreibers der Ladeinfrastruktur basierend auf der Kommunikationsnachricht. Die Steuerungsschaltung 16 ist ausgebildet zum Ermitteln einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur. Die Steuerungsschaltung 16 ist ausgebildet zum Authentifizieren des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt.
Fig. 1b zeigt ein Flussdiagramm eines entsprechenden Verfahrens für das Ladesteuergerät 10. Das Verfahren umfasst ein Verarbeiten 110 der Kommunikationsnachricht der Ladeinfrastruktur. Das Verfahren umfasst ein Bestimmen 120 des zumindest einen Identifikators des Betreibers der Ladeinfrastruktur basierend auf der Kommunikationsnachricht. Das Verfahren umfasst ein Ermitteln 130 der Auswahl des Ladekontrakts aus der Mehrzahl von in dem Lade Steuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur. Das Verfahren umfasst ein Authentifizieren 140 des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt. Im Folgenden wird das Lade Steuergerät, das entsprechende Verfahren sowie ein entsprechendes Computerprogramm mit Bezug auf das Ladesteuergerät beschrieben. Merkmale, die im Zusammenhang mit dem Ladesteuergerät beschrieben werden können, gleichfalls auf das entsprechende Verfahren oder Computerprogramm angewandt werden.
In der Ladekommunikation gemäß Plug & Charge-Standard werden Ladekontrakte (auch Vertragszertifikate genannt) genutzt, um das Ladesteuergerät gegenüber der Ladeinfrastruktur (etwa einer Ladesäule) zu authentifizieren. Diese Ladekontrakte werden im Rahmen eines Vertrags zwischen dem Fahrer/Nutzer des Fahrzeugs und einem sogenannten Mobilitätsanbieter (Mobility Operator) ausgestellt, und werden von dem Betreiber der Ladeinfrastruktur genutzt, um den gelieferten Ladestrom abzurechnen. Dazu schließt der Mobilitätsanbieter mit dem Betreiber der Ladestation einen Vertrag (sofern Mobilitätsanbieter und Betreiber der Ladestation nicht die gleiche Entität ist), in dem festgelegt ist, welche Kosten dem Mobilitätsanbieter bei Nutzung der Ladeinfrastruktur durch einen Kunden des Mobilitätsanbieters entstehen. Der Mobilitätsanbieter rechnet wiederum mit dem Kunden für die erbrachten Leistungen des Betreibers der Ladestation ab. Allerdings haben nicht alle Mobilitätsanbieter mit allen Ladestationsbetreibem Verträge abgeschlossen, so dass eine Nutzung einer Ladeinfrastruktur nicht mit allen Verträgen möglich ist. Zudem variieren die Preise, je nach Vertrag zwischen Mobilitätsanbieter und Kunden und Mobilitätsanbieter und Ladestationsbetreiber, teilweise erheblich. In aktuellen Umsetzungen von Plug and Charge (nach ISO 15118-2), wird häufig nur ein Zertifikat installiert mit dem Plug and Charge genutzt werden kann. In diesem Fall entfällt die Auswahl durch den Nutzer. Wenn mehr als ein Zertifikat auf dem Fahrzeug installiert wird, kann beispielsweise durch den Nutzer eingestellt werden, welches Zertifikat aktuell verwendet wird. Verfügt der Nutzer des Fahrzeugs über mehrere Verträge mit mehreren Mobilitätsanbietem, und damit auch mehrere Ladekontrakte, ist er daher gefordert, für die jeweilige Ladestation den passenden Vertrag auszuwählen. Die vorliegende Erfindung automatisiert diese Auswahl weitergehend, und befasst sich mit einer ladestationsbasierten Vertragsauswahl, etwa im Zusammenhang mit Plug & Charge.
Um zumindest sicherzustellen, dass der genutzte Ladekontrakt auch von dem Betreiber der Ladestation unterstützt wird, unterstützt die aktuelle Version ISO15118-20 des Standards, dass eine Ladestation dem angestecktem Fahrzeug mittels der Datenstruktur SupportedProvidersListType (Unterstützte Diensterbringer-Listentyp) mitteilt, welche Vertragsanbieter unterstützt werden. Diese Funktion ermöglicht dem Fahrzeug ein passendes Zertifikat zu verwenden, sofern ein passendes installiert ist. Dies schafft teilweise Abhilfe, indem das Auto zumindest einen akzeptierten Vertrag auswählen kann. Allerdings sieht die Norm keinen Mechanismus vor, wie beispielsweise bei mehr als einem akzeptierten Vertrag umzugehen ist. Ebenso können die heute verbreiteten Stationen nach ISO15118-2 diesen Mechanismus nicht nutzen. Ein nachträglicher Umstieg auf ISO15118-20 mag seitens Ladestationen zum Teil möglich sein. Fahrzeuge können auf Grund diverser Limitierungen jedoch nicht nachträglich auf ISO 15118-20 ertüchtigt werden, weshalb auch künftig ISO 15118-2 von allen Markteilnehmem auf absehbare Zeit zu unterstützen ist. Zudem gibt es Nutzungsszenarien aus Nutzersicht, in denen der Nutzer einen bestimmten Vertrag für einen bestimmten Ladestationsbetreiber verwenden möchten, da sie beispielsweise mit diesem Vertrag bei diesem Anbieter bessere Konditionen bekommen als mit dem sonst favorisierten Standardvertrag.
Die vorliegende Erfindung basiert darauf, dass mittels einem eindeutigen Identifikator der Ladestation, die im Zuge der Ladekommunikation übertragen wird, der Betreiber identifiziert werden kann. Dazu verarbeitet das Ladesteuergerät die Kommunikationsnachricht der Ladeinfrastruktur. Diese Kommunikationsnachricht kann beispielsweise eine Kommunikationsnachricht sein, die zu Beginn der Kommunikation zwischen Ladesteuergerät und Ladeinfrastruktur (d.h. Ladesäule) ausgetauscht wird, etwa eine Nachricht der Ladeinfrastruktur an das Lade Steuergerät im Rahmen des Verbindungsaufbaus. Beispielsweise kann die Kommunikationsnachricht im Rahmen eines Verbindungsaufbaus zwischen der Ladeinfrastruktur und dem Ladesteuergerät empfangen worden sein. Dabei kann die Kommunikation zwischen Ladeinfrastruktur und Ladesteuergerät etwa auf dem Standard ISO15118, und insbesondere ISO15118-2 oder ISO15118-20 basieren. Auch die hier erwähnten Ladekontrakte können auf Standard ISO15118, und insbesondere ISO15118-2 oder ISO 15118-20 basieren.
Die Steuerungsschaltung ist ausgebildet zum Bestimmen zumindest eines Identifikators eines Betreibers der Ladeinfrastruktur basierend auf der Kommunikationsnachricht. Dabei kommen verschiedene Quellen in Betracht. Beispielsweise kann den sogenannte EVSEID (Electric Vehicle Supply Equipment Identifier, Identifikator der Elektrofahrzeugversorgungsausrüstung). In anderen Worten kann der zumindest eine Identifikator den EVSEID umfassen. Dieser wird, gemäß Standard, als Teil der SessionSetupRes (Sitzungsaufbauantwort) von der Ladestation übermittelt. Alternativ oder zusätzlich kann den SECCID (Supply Equipment Communication Controller Identifier, Identifikator des Kommunikationssteuergeräts der Versorgungsausrüstung) und/oder den CPID (Charge Point Identifier, Ladepunktidentifikator) genutzt werden, die jeweils Teil des Leaf-Zertifikats sind. Dabei ist die SECCID ein Teil des SECC (Supply Equipment Communication Controller) Leaf- Zertifikats gemäß ISO15118-20, und die CPID ist Teil des Leaf-Zertifikats nach ISO15118-2-. Entsprechend kann die Steuerungsschaltung ausgebildet sein, um den zumindest einen Identifikator aus einem Leaf-Zertifikat, das von der Ladeinfrastruktur verwendet wird, zu extrahieren. In diesem Fall kann der zumindest eine Identifikator zumindest eines von dem Supply Equipment Communication Controller Identifier, SECCID, und dem Charge Point Identifier, CPID, umfassen. In manchen Fällen kann der CPID auch mit dem EVSEID übereinstimmen. Sowohl EVSEID als auch SECCID enthalten einen 3-stellige alphanumerische EVSE (Electric Vehicle Supply Equipment, Elektrofahrzeugversorgungsausrüstung) Operator-ID (Identifikator), sowie einen 2-stelligen Ländercode, die (zusammen) den Ladestationsbetreiber identifizieren.
Zudem umfasst das Leaf-Zertifikat, neben der SECCID oder CPID, weitere Informationen, die sich zudem in anderen Zertifikaten einer Zertifikatskette, die das Leaf-Zertifikat umfasst, finden, die Rückschlüsse auf den Betreiber zulassen. In Big. 5 sind Beispiele der Felder eines solchen Zertifikats gezeigt. Insbesondere können eines oder mehrere der Felder „Land“ (engl. Country), „Organisation“ (engl. Organization) und „gebräuchliche Bezeichnung“ (engl. common name) der Abschnitte Ausgeber (engl. Issuer) und/oder Gegenstand (engl. Subject) genutzt werden, um den Betreiber der Ladeinfrastruktur zu identifizieren. Dabei entspricht die CPID beispielsweise der gebräuchlichen Bezeichnung, falls das Zertifikat das Leaf-Zertifikat gemäß ISO15118-2 ist. Entsprechend kann die Steuerungsschaltung ausgebildet sein, um den zumindest einen Identifikator aus einem Zertifikat der Zertifikatskette, die das Leaf-Zertifikat umfasst, das von der Ladeinfrastruktur verwendet wird, zu extrahieren. Dabei kann der Identifikator beispielsweise eines oder mehrere der o.g. Felder umfassen.
In einem ISO 15118-2/-20 konformen Lade Steuergerät kann die EVSEID aus der SessionSetupRes temporär zwischengespeichert werden. Zusätzlich kann das Ladesteuergerät die CPID bzw. die SECCID der aus dem SECC Leaf-Zertifikat, je nach Standard, extrahieren und temporär Zwischenspeichern. Experimente haben gezeigt, dass die EVSEID aus der SessionSetupRes in Europa kein zuverlässiges Datum ist, weshalb es sinnvoll sein kann, zusätzlich oder alternativ die Information aus den Zertifikaten zu nutzen, sofern diese als zuverlässiger erachtet werden. Entsprechend kann die Steuerungsschaltung ausgebildet sein, um eine Mehrzahl von Identifikatoren basierend auf der Kommunikationsnachricht zu bestimmen (etwa EVSEID und CPID, oder EVSEID und SECCID), und um je nach Betreiber einen oder mehrere der Identifikatoren zu verwenden, um den Betreiber zu identifizieren. Die Entscheidung zur Nutzung eines bestimmten Datums für die automatisierte Vertragsauswahl kann per Konfigurationsparameter eingestellt werden. Alternativ kann ein Algorithmus auf dem Ladesteuergerät entscheiden, welches Datum am wahrscheinlichsten korrekt ist und dieses für den weiteren Verlauf nutzen.
Die Steuerungsschaltung ist ausgebildet zum Ermitteln der Auswahl des Ladekontrakts aus der Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur. Beispielsweise kann die Auswahl basierend auf einer Datenstruktur ermittelt werden, wobei in der Datenstruktur für eine Mehrzahl von Betreibern ein auszuwählender Ladekontrakt definiert ist. Die Datenstruktur kann beispielsweise in dem Speicher 18 gespeichert sein. Im Folgenden wird beispielhaft eine Liste von EMAIDs (E-Mobility Account Identifier, E-Mobilitäts- Benutzerkontenidentifikator) als Datenstruktur verwendet. Anstelle der Liste kann jedoch auch eine Datenbank oder ein Entscheidungsbaum als Datenstruktur verwendet werden. Die Beispiele, die im Zusammenhang mit der Liste gegeben werden, können entsprechend auch auf eine Datenbank oder einen Entscheidungsbaum übertragen werden. In den Beispielen steht die jeweilige EMAID für den auszuwählenden Ladekontrakt, d.h. der auszuwählende Ladekontrakt wird durch die dazugehörige EMAID bezeichnet.
Das Ladesteuergerät, oder eine andere Entität, kann zudem eine Liste speichern, welche die Vorgabe zur automatisierten Vertragsauswahl darstellt. Jeder Listeneintrag kann beispielsweise mindestens eine zweistellige Länder ID, eine dreistellige Operator ID sowie die EMAID umfassen. Zusätzlich kann die Liste eine oder mehrere EMAIDs umfassen, die als Rückgriff-Verträge (engl. Eallback) dienen. In anderen Worten kann in der Datenstruktur ferner ein Ladekontrakt definiert sein (der eine oder die mehreren Rückgriff-Verträge), der auszuwählen ist, falls für einen Betreiber kein auszuwählender Ladekontrakt definiert ist.
Basierend auf dem identifizierten Betreiber kann nun dem Eahrzeug beispielsweise mittels einer vordefmierten Liste aus Vertrags-ID (EMAID, E-Mobility Account Identifier, E-Mobilitäts- Benutzerkontenidentifikator) und EVSE Operator ID mitgeteilt werden (welche den Betreiber identifiziert), welcher Vertrag (EMAID) bei welchem Betreiber (EVSE Operator ID) automatisch auszuwählen und zu nutzen ist. Ist ein Eahrzeug nun an einer Ladestation angeschlossen, die Plug and Charge unterstützt, überprüft das Ladesteuergerät beispielsweise zunächst die temporär für diesen Ladevorgang gespeicherte EVSEID/SECCID/CPID (d.h. den zumindest einen Identifikator). Dazu kann die Operator ID und die Länder ID aus diesem Datum nun mit der Liste abgeglichen werden. Ist ein identischer Eintrag in der Liste vorhanden, kann die EMAID des Listeneintrags ausgelesen und ausgewählt werden. Wird kein passender Eintrag gefunden, kann die Rückgriff-EMAID ausgewählt werden und zudem Informationen über einen Fehler gespeichert werden. Dieser Vorgang findet beispielsweise nach dem Aufbau der TLS (Transport-Layer Security, Transportebenensicherheit)- Verbindung statt, aber vor der Authentifizierung mittels Plug & Charge- Zertifikat. Die gewählte EMAID bezeichnet dabei den Vertrag, der im Rahmen der Plug and Charge -Authentifizierung nun im nächsten Schritt an der Ladestation zur Authentifizierung verwendet wird.
Diese Liste kann auf Basis verschiedener Prämissen (auch in Kombination) festgelegt werden, etwa basierend auf (bekannten) Roamingverhältnissen, Kundenpräferenz (durch Kunden festgelegt oder auf Basis des Verhaltens erlernt), mit Wissen um die individuellen Preise einer bestimmten EMAID bei einem bestimmten Ladestationsbetreiber, nach den möglichst günstigsten Kosten für den Kunden. Ferner sind explizit auch andere Möglichkeiten zur Priorisierung möglich. Die Liste kann entweder lokal auf dem Fahrzeug erstellt oder mittels Backendverbindung in das Fahrzeug eingebracht und aktualisiert werden. Sofern mittels ISO15118-20 kommuniziert wird, kann ein Abgleich mit der SupportedProvidersListType erfolgen. In anderen Worten kann die Steuerungsschaltung ferner ausgebildet sein, um eine Liste mit unterstützten Mobilitätsoperatoren von der Ladeinfrastruktur zu erhalten (die SupportedProvidersListType), und um die Auswahl des Ladekontrakts ferner basierend auf der Liste mit unterstützten Mobilitätsoperatoren zu ermitteln. Beispielsweise kann die o.g. Liste zu mehreren EMAIDs dieselbe Operator-ID enthalten. Die Liste kann beispielsweise so strukturiert werden, dass es je Operator ID einen priorisierten bzw. einen oder mehrere Rückgriff (engl. fallback)- Verträge (EMAID) gibt. Im Fall, dass der Provider der priorisierten EMAID nicht Teil der SupportedProvidersListType ist, kann ein Rückgriff-Vertrag gewählt werden.
Die Liste, die die automatische Auswahl im Ladesteuergerät vorgibt, kann beispielsweise nutzerspezifisch im Backend erstellt und per Fern-Verbindung in das Ladesteuergerät eingebracht werden. Die Liste selbst kann auf Basis von Kundenvorgaben (individuelle Priorisierung der Verträge je nach Ladestationsbetreiber), vorhandene Beschränkungen (z.B. aufgrund von Roaming bestimmter Verträge mit bestimmten Stationen), unter Berücksichtigung des günstigsten Preises oder anderen Kriterien bzw. einer Kombination aus selbigen erstellt werden. Als Rückgriff-Vertrag kann ein vom Kunden bestimmter Vertrag genutzt verwendet werden, der genutzt werden soll, falls eine automatische Auswahl des Vertrags nicht möglich ist. In vielen Fällen kann die Auswahl des Ladekontrakts durch die Steuerungsschaltung durchgeführt werden. Alternativ können statt dem Ladesteuergerät auch mehrere Steuergeräte, die im Fahrzeug miteinander kommunizieren, an der automatischen Vertragsauswahl beteiligt sein. Entsprechend kann das Ermitteln der Auswahl ein Bereitstellen einer Information über den zumindest einen Identifikator an eine Gegenstelle (etwa über die zumindest eine Schnittstelle 12), und ein Erhalten einer Information über den auszuwählenden Ladekontrakt von der Gegenstelle (etwa über die zumindest eine Schnittstelle 12) umfassen. Dabei kann die Gegenstelle ein weiteres Steuergerät 105 des Fahrzeugs oder ein Backend-Server 200 sein. In den Fign. 2a und 2b sind Beispiele einer Vorrichtung, eines Verfahrens und eines Computerprogramms gegeben, die die Auswahl auf der Gegenstelle durchführen. So kann beispielsweise die Liste auf einem anderen Steuergerät oder dem Backend-Server liegen und das Ladesteuergerät fragt vor der Authentifizierung mittels Operator-ID und Länder-ID/Code über ein Fahrzeugnetzwerk an, welche EMAID für diese Kombination zu verwenden ist. Das Steuergerät, auf dem die Liste gespeichert ist, übernimmt den Vergleich und schickt die ausgewählte EMAID, und optional auch eine Rückgriff-EMAID, zurück an das Ladesteuergerät. In einer weiteren Ausprägung kann das Lade Steuergerät oder eine anderes Steuergerät, das mit dem Ladesteuergerät kommuniziert, vor jedem Ladevorgang nach Identifikation der Operator ID und Länder-ID/Code im Backend die präferierte EMAID (und Rückgriff-EMAID) abfragen.
Während der Authentifizierung des Ladesteuergeräts (etwa über die zumindest eine Schnittstelle 12) wird nun das Zertifikat des ausgewählten Ladekontrakts genutzt, um die Kommunikation mit der Ladeinfrastruktur 5 kryptografisch abzusichem und das Ladesteuergerät gegenüber der Ladeinfrastruktur zu identifizieren, und damit zu authentifizieren.
Nach der Authentifizierung kann eine Meldung vom Ladesteuergerät an das Backend geschickt werden, die beispielsweise (zumindest) die folgenden Informationen enthält: EVSEID, CPID, SECCID, verwendete EMAID, automatische Auswahl erfolgreich, Authentifizierung erfolgreich. In anderen Worten kann die Steuerungsschaltung ferner ausgebildet sein, um, zumindest in dem Fall, dass die Authentifizierung fehlschlägt, eine Information über den zumindest einen Identifikator, über den ausgewählten Ladekontrakt, und über den Erfolg oder Misserfolg der Authentifizierung an einen Backend-Server 200 zu übermitteln. Diese Information kann einerseits dazu genutzt werden, Fehlerfälle transparent gegenüber dem Kunden, etwa in einer mobilen Applikation des Fahrzeugherstellers, anzuzeigen. Anderseits kann diese Information dazu genutzt werden, den Mechanismus zur automatischen Auswahl, insbesondere der zuvor genannten Liste zu verbessern.
Die zumindest eine Schnittstelle 12 kann beispielsweise einem oder mehreren Eingängen und/oder einem oder mehreren Ausgängen zum Empfangen und/oder Übertragen von Informationen entsprechen, etwa in digitalen Bitwerten, basierend auf einem Code, innerhalb eines Moduls, zwischen Modulen, oder zwischen Modulen verschiedener Entitäten.
In Ausführungsbeispielen kann die Steuerungsschaltung 16 einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen. Beispielsweise kann die Steuerungsschaltung 16 auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern kann die Steuerungsschaltung 16 als programmierbare Hardware mit entsprechend angepasster Software implementiert sein. Dabei können beliebige Prozessoren, wie Digitale Signalprozessoren (DSPs) zum Einsatz kommen. Ausführungsbeispiele sind dabei nicht auf einen bestimmten Typ von Prozessor eingeschränkt. Es sind beliebige Prozessoren oder auch mehrere Prozessoren zur Implementierung denkbar. In manchen Beispielen kann die Steuerungsschaltung 16 das kryptografisch gesicherte Element 14 umfassen.
Der Speicher 18 des Lade Steuergeräts kann beispielsweise zumindest ein Element der Gruppe von computerlesbares Speichermedium, magnetisches Speichermedium, optisches Speichermedium, Festplatte, Flash-Speicher, Diskette, Zufallszugriffsspeicher (auch engl. Random Access Memory), Programmable Read Only Memory (PROM), Erasable Programmable Read Only Memory (EPROM), Electronically Erasable Programmable Read Only Memory (EEPROM), und Netzwerkspeicher umfassen. Das Fahrzeug 100 kann beispielsweise einem Landfahrzeug, einem Wasserfahrzeug, einem Luftfahrzeug, einem Schienenfahrzeug, einem Straßenfahrzeug, einem Auto, einem Geländefahrzeug, einem Kraftfahrzeug, oder einem Lastkraftfahrzeug entsprechen.
Mehr Details und Aspekte des Ladesteuergeräts, des entsprechenden Verfahrens und des Computerprogramms werden in Verbindung mit dem Konzept oder Beispielen genannt, die nachher (z.B. Fig. 2a bis 4) beschrieben werden. Das Ladesteuergerät, des entsprechenden Verfahren und das Computerprogramm kann ein oder mehrere zusätzliche optionale Merkmale umfassen, die ein oder mehreren Aspekten des vorgeschlagenen Konzepts oder der beschriebenen Beispiele entsprechen, wie sie vorher oder nachher beschrieben werden.
Fig. 2a zeigt ein schematisches Diagramm einer Vorrichtung 20 zum Ermitteln einer Auswahl eines Ladekontrakts. Die Vorrichtung 20 umfasst zumindest eine Schnittstelle 22 zur Kommunikation mit einem Ladesteuergerät 10 (in Fig. la gezeigt) des Fahrzeugs. Die Vorrichtung umfasst eine Steuerungsschaltung 24, die mit der zumindest einen Schnittstelle 22 gekoppelt ist. Die Steuerungsschaltung 24 ist ausgebildet zum Erhalten einer Information über zumindest einen Identifikator eines Betreibers einer Ladeinfrastruktur von dem Lade Steuergerät (über die Schnittstelle 22). Die Steuerungsschaltung 24 ist ausgebildet zum Ermitteln einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur). Die Steuerungsschaltung 24 ist ausgebildet zum Bereitstellen einer Information über den auszuwählenden Ladekontrakt an das Ladesteuergerät (über die Schnittstelle 22). Dabei kann die Vorrichtung 20 Teil eines Steuergeräts (etwa Steuergerät 200 in Fig. la) oder Teil eines Backend-Servers (etwa Backend-Server 205 in Fig. la) sein.
Fig. 2b zeigt ein Flussdiagramm eines entsprechenden Verfahrens zum Ermitteln der Auswahl des Ladekontrakts. Das Verfahren umfasst ein Erhalten 210 der Information über den zumindest einen Identifikator des Betreibers der Ladeinfrastruktur von dem Ladesteuergerät. Das Verfahren umfasst ein Ermitteln 220 der Auswahl des Ladekontrakts aus der Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur. Das Verfahren umfasst ein Bereitstellen 230 der Information über den auszuwählenden Ladekontrakt an das Ladesteuergerät.
Die von der Vorrichtung 20 von Fig. 2a und dem Verfahren von Fig. 2b (und von einem entsprechenden Computerprogramm) durchgeführte Auswahl des Ladekontrakts kann beispielsweise analog zu der Auswahl des Ladekontrakts, wie er im Zusammenhang mit den Fign. la und 1b beschrieben ist, durchgeführt werden. Die zumindest eine Schnittstelle 22 kann beispielsweise einem oder mehreren Eingängen und/oder einem oder mehreren Ausgängen zum Empfangen und/oder Übertragen von Informationen entsprechen, etwa in digitalen Bitwerten, basierend auf einem Code, innerhalb eines Moduls, zwischen Modulen, oder zwischen Modulen verschiedener Entitäten.
In Ausführungsbeispielen kann die Steuerungsschaltung 24 einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen. Beispielsweise kann die Steuerungsschaltung 24 auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern kann die Steuerungsschaltung 24 als programmierbare Hardware mit entsprechend angepasster Software implementiert sein. Dabei können beliebige Prozessoren, wie Digitale Signalprozessoren (DSPs) zum Einsatz kommen. Ausführungsbeispiele sind dabei nicht auf einen bestimmten Typ von Prozessor eingeschränkt. Es sind beliebige Prozessoren oder auch mehrere Prozessoren zur Implementierung denkbar.
Mehr Details und Aspekte der Vorrichtung, des entsprechenden Verfahrens und des Computerprogramms werden in Verbindung mit dem Konzept oder Beispielen genannt, die nachher (z.B. Fig. la bis 1b, 3 bis 4) beschrieben werden. Die Vorrichtung, des entsprechenden Verfahren und das Computerprogramm können ein oder mehrere zusätzliche optionale Merkmale umfassen, die ein oder mehreren Aspekten des vorgeschlagenen Konzepts oder der beschriebenen Beispiele entsprechen, wie sie vorher oder nachher beschrieben werden.
Im Folgenden wird ein kurzer Überblick zu dem Mechanismen von Plug & Charge, wie sie in der vorliegenden Erfindung genutzt werden, zum weiteren Verständnis gegeben. Plug & Charge ermöglicht ein vollautomatisches und sicheres Ladeerlebnis durch die Authentifizierungstechnologie von EV zu Ladestation (gemäß ISO 15118). Fig. 3 zeigt ein schematisches Diagramm einer technischen Perspektive auf Plug & Charge. Zuerst (1.) stellt der Fahrzeughersteller (als OEM in Fig. 4 dargestellt) ein Provisionierungszertifikat einem Aggregator bereit. Dieses Provisionierungszertifikat umfasst im vorliegenden Fall einen Benutzerkonto-spezifischen eindeutigen Identifikator. Dann schließt der Fahrzeugnutzer einen Ladekontrakt mit dem Mobilitätsoperator (MO) ab. Im Rahmen des Abschlusses des Ladekontrakts teilt der Fahrzeugnutzer die Fahrzeug-Identifikationsnummer (etwa die PCID) mit, was etwa durch den Fahrzeughersteller geschehen kann. Der Mobilitätsoperator erstellt ein Kontrakt-Zertifikat (3.) für die angegebenen Fahrzeug-Identifikationsnummer, das ebenfalls dem Aggregator bereitgestellt wird. Der Aggregator benachrichtigt den OEM (4.), dass er ein Kontrakt-Zertifikat erhalten hat und leitet es ihm optional weiter (oder das Kontrakt-Zertifikat wird nach Bedarf von dem OEM abgerufen). Der Kunde beauftragt den Fahrzeughersteller, und insbesondere das Fahrzeug, das Kontrakt-Zertifikat herunterzuladen und zu installieren (5.). Im Rahmen des Ladevorgangs kommuniziert (6.) der Fahrzeughersteller bzw. das Fahrzeug über ISO 15118 mit dem Ladestellenoperator (CPO), welcher nun wiederum über den Aggregator und/oder eine Roaming -Plattform mit dem Mobilitätsoperator Kontakt aufnehmen kann bezüglich der Bezahlung des Ladevorgangs.
In Fig. 4 ist eine vereinfachte Darstellung der technischen Infrastruktur für die Nutzung von Plug & Charge gezeigt. Fig. 4 zeigt ein Ladesteuergerät 410, das dem Ladesteuergerät 10 von Fig. la entsprechen kann, ein Benutzerschnittstellensteuergerät 420, das dem Steuergerät 200 der Fig. la entsprechen kann, einen Intermediär 430 (der im Fahrzeug oder bei der Fertigung des Fahrzeugs genutzt werden kann), ein Plug & Charge -Koordinator 440 (seitens des Fahrzeugherstellers), einen Aggregator 450, einen Mobilitätsdienstleister 460, einen Betreiber der Ladestation 470, sowie die Ladestation 480. Das Ladesteuergerät 410 ist zur Kommunikation gemäß ISO 15118 ausgebildet und ist für die Zertifikatsspeicherung & -handhabung (inkl. Diagnoseaufträge) zuständig. Der Intermediär ist die Wurzel-Zertifikatsautorität des Fahrzeugherstellers und stellt Provisionierungszertifikate bereit.
Um einen neuen Kontrakt im Fahrzeug, und insbesondere im Ladesteuergerät zu installieren, können die folgenden Schritte ausgeführt werden. Um die Installation von Ladekontrakten (bzw. der entsprechenden Zertifikate) zu ermöglichen, wird ein sogenanntes Provisionszertifikat benötigt. Im vorliegenden Beispiel wird dies durch den Intermediär 440 durchgeführt. Dieser erhält einen Certificate Signing Request (CSR, Zertifikatssignierungsanfrage) von dem Ladesteuergerät, und stellt einen privaten Schlüssel des Zertifikats dem Lade Steuergerät 430 bereit und einen öffentlichen Schlüssel dem Plug & Charge -Koordinator 440. Dieser veröffentlich das Provisionszertifikat (d.h. den öffentlichen Schlüssel davon) bei dem Aggregator 450. Das Provisionszertifikat enthält kryptografisch gesichert eine Identifikationskennung des Fahrzeugs (etwa die Fahrgestellnummer).
Unterzeichnet ein Kunde einen Ladevertrag, so gibt er als Teil des Vertrags die Identifikationskennung des Fahrzeugs gegenüber dem Mobilitätsdienstleister 450 an. Dieser erstellt ein neues Kontrakt- Zertifikat. Das Kontrakt-Zertifikat kann nun mittels des Provisionszertifikats (d.h. des öffentlichen Schlüssels) verschlüsselt werden, so dass es nur von einem Ladesteuergerät entschlüsselt werden kann, das über den privaten Schlüssel des Provisionierungszertifikats verfügt. Das passende Provisionszertifikat wird mittels der Identifikationskennung (d.h. den eindeutigen Identifikator) ermittelt. Der Aggregator 450 erhält das verschlüsselte Kontrakt-Zertifikat und informiert den Plug & Charge -Koordinator 440 darüber. Dieser kann nun das Kontrakt-Zertifikat erhalten und dem Ladesteuergerät bereitstellen, etwa über eine Telematikverbindung. Alternativ kann das Kontrakt- Zertifikat über die Powerline -Kommunikation zwischen Ladestation 480 und Lade Steuergerät 410 ausgetauscht werden. Verfügt das Ladesteuergerät über ein entsprechendes Kontraktzertifikat, so kann es sich, über eine Verbindung, die mittels einer TLS (Transport Layer Security, Transportschichtsicherheit)-Kommunikation gesichert ist, über das Kontraktzertifikat identifizieren. Die Ladestation identifiziert sich über ein Leaf-Zertifikat, das von einem V2G (Vehicle-to-Grid, Fahrzeug-zu-Netz)-Wurzelzertifikat abgeleitet ist. Mittels dem Leaf-Zertifikat der Ladestation wird zunächst eine TLS (etwa eine TLS 1.2)-Verbindung zwischen Ladestation und Fahrzeug aufgebaut (ähnlich der Transportverschlüsslung im Internet). Im Anschluss wird das Kontraktzertifikat übertragen. Das Kontraktzertifikat ist damit nicht Teil der TLS-Kette. Im Falle von TLS 1.3 wird ein weiteres Zertifikat genutzt, das in ISO15518-20 beschrieben ist. Die Autorisierung der Ladesitzung erfolgt zwischen Ladestation 480, Betreiber der Ladestation 470 und Aggregator 450, wobei der Betreiber 470 der Ladestation den Mobilitätsdienstleister 460 über den Aggregator 450 ermitteln kann. Die Bezahlung erfolgt dann, gemäß Kontrakt, über einen E-Mobilitäts-Identifikator an den Mobilitätsdienstleister 460.
Das Benutzerschnittstellensteuergerät umfasst ein System für eine grafische Oberfläche, das beispielsweise auf einem grafischen Betriebssystem für Mobilgeräte basieren kann und die Benutzerführung an Bord sowie die Konfiguration des Fahrzeugs sowie der Plug & Charge- Funktionalität ermögliche kann, sowie die eigentliche Steuergerätfunktionalität. Letztere kommuniziert mit dem Lade Steuergerät 410 und erhält Informationen über dort gespeicherte Provisionierungs- und Vertragszertifikate von dem Lade Steuergerät 410. Über das System für die grafische Oberfläche kann nun eine Möglichzeit zur Auswahl eines der gespeicherten Zertifikate gegeben werden, wobei die Auswahl an das Ladesteuergerät kommuniziert wird. Das Benutzerschnittstellensteuergerät 420 fragt zudem Identifikatoren von neuen Kontraktzertifikaten (und V2G-Wurzelzertifikaten) am Plug & Charge -Koordinator 440 an, um die Installation der Kontraktzertifikate anbieten zu können. Wird die Installation veranlasst, dann fragt das Benutzerschnittstellensteuergerät 420 die jeweiligen Zertifikate zur Installation von dem Plug & Charge -Koordinator an. Diese werden dann an das Lade Steuergerät weitergegeben. Für die Kommunikation zwischen Benutzerschnittstellensteuergerät 420 und Ladesteuergerät 410 kann dabei beispielsweise eine Diagnose-Kommunikation und/oder eine Stauts/Konfigurations-Kommunikation verwendet werden.
Fig. 5 zeigt ein Diagramm eines Beispiels von Feldern eines Zertifikats, wie es im Rahmen einer EVSE/CPO-Zertifikatskette der Standards ISO15118-2 oder ISO15118-20 verwendet wird. Dabei handelt es sich um Zertifikate gemäß Standard X.509v3. Die Zertifikate umfassen die Abschnitte zusignierendes Zertifikat (engl. tbsCertificate, to-be-signed certificate) mit den Feldern Version, Seriennummer und Signatur, Ausgeber/Herausgeber (engl. issuer) mit den Feldern Land, Organisation, Organisationseinheit, und gebräuchlicher Name, Validität sowie Gegenstand (engl. subject), mit den Feldern Land, Organisation, Organisationseinheit, gebräuchlicher Name und Domänenkomponente. In der Zertifikatskette können beispielsweise die Zertifikate CPO Sub 1 (Ladepunktbetreiber Unter-Zertifikat 1), CPO Sub 2 (Ladepunktbetreiber Unter-Zertifikat 2) und SECC-Zertifikat (als Blat-Zertifikat) verwendet werden. Von den Feldern sind insbesondere die Felder Land, Organisation und gebräuchlicher Name der Abschnite Ausgeber und Gegenstand von Interesse, um den zumindest einen Identifikator zu bestimmen. Dabei entspricht die CPID dem gebräuchlichen Namen im Abschnit Gegenstand eines Leaf-Zertifikats nach ISO15118-2. Lediglich die CPID ist in der Norm definiert und ist damit der erfolgsversprechendste Indikator. Auf andere Indikatoren kann jedoch auch zurückgegriffen werden.
Die Aspekte und Merkmale, die im Zusammenhang mit einem bestimmten der vorherigen Beispiele beschrieben sind, können auch mit einem oder mehreren der weiteren Beispiele kombiniert werden, um ein identisches oder ähnliches Merkmal dieses weiteren Beispiels zu ersetzen oder um das Merkmal in das weitere Beispiel zusätzlich einzuführen.
Beispiele können weiterhin ein (Computer-)Programm mit einem Programmcode zum Ausführen eines oder mehrerer der obigen Verfahren sein oder sich darauf beziehen, wenn das Programm auf einem Computer, einem Prozessor oder einer sonstigen programmierbaren Hardwarekomponente ausgeführt wird. Schrite, Operationen oder Prozesse von verschiedenen der oben beschriebenen Verfahren können also auch durch programmierte Computer, Prozessoren oder sonstige programmierbare Hardwarekomponenten ausgeführt werden. Beispiele können auch Programmspeichervorrichtungen, z.B. Digitaldatenspeichermedien, abdecken, die maschinen-, Prozessor- oder computerlesbar sind und maschinenausführbare, prozessorausführbare oder computerausführbare Programme und Anweisungen codieren beziehungsweise enthalten. Die Programmspeichervorrichtungen können z.B. Digitalspeicher, magnetische Speichermedien wie beispielsweise Magnetplaten und Magnetbänder, Festplatenlaufwerke oder optisch lesbare Digitaldatenspeichermedien umfassen oder sein. Weitere Beispiele können auch Computer, Prozessoren, Steuereinheiten, feld-programmierbare Logik-Arrays ((F)PLAs = (Field) Programmable Logic Arrays), feld-programmierbare Gate-Arrays ((F)PGA = (Field) Programmable Gate Arrays), Grafikprozessoren (GPU = Graphics Processor Unit), anwendungsspezifische integrierte Schaltungen (ASIC = application-specific integrated circuit), integrierte Schaltungen (IC= Integrated Circuit) oder Ein-Chip -Systeme (SoC = System-on-a-Chip) abdecken, die zum Ausführen der Schrite der oben beschriebenen Verfahren programmiert sind.
Es versteht sich ferner, dass die Offenbarung mehrerer, in der Beschreibung oder den Ansprüchen offenbarter Schrite, Prozesse, Operationen oder Funktionen nicht als zwingend in der beschriebenen Reihenfolge befindlich ausgelegt werden soll, sofern dies nicht im Einzelfall explizit angegeben oder aus technischen Gründen zwingend erforderlich ist. Daher wird durch die vorhergehende Beschreibung die Durchführung von mehreren Schriten oder Funktionen nicht auf eine bestimmte Reihenfolge begrenzt. Ferner kann bei weiteren Beispielen ein einzelner Schrit, eine einzelne Funktion, ein einzelner Prozess oder eine einzelne Operation mehrere Teilschritte, -Funktionen, - prozesse oder -Operationen einschließen und/oder in dieselben aufgebrochen werden.
Wenn einige Aspekte in den vorhergehenden Abschnitten im Zusammenhang mit einer Vorrichtung oder einem System beschrieben wurden, sind diese Aspekte auch als eine Beschreibung des entsprechenden Verfahrens zu verstehen. Dabei kann beispielsweise ein Block, eine Vorrichtung oder ein funktionaler Aspekt der Vorrichtung oder des Systems einem Merkmal, etwa einem Verfahrensschritt, des entsprechenden Verfahrens entsprechen. Entsprechend dazu sind Aspekte, die im Zusammenhang mit einem Verfahren beschrieben werden, auch als eine Beschreibung eines entsprechenden Blocks, eines entsprechenden Elements, einer Eigenschaft oder eines funktionalen Merkmals einer entsprechenden Vorrichtung oder eines entsprechenden Systems zu verstehen.
Die folgenden Ansprüche werden hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Anspruch als getrenntes Beispiel für sich stehen kann. Ferner ist zu beachten, dass - obwohl ein abhängiger Anspruch sich in den Ansprüchen auf eine bestimmte Kombination mit einem oder mehreren anderen Ansprüchen bezieht - andere Beispiele auch eine Kombination des abhängigen Anspruchs mit dem Gegenstand jedes anderen abhängigen oder unabhängigen Anspruchs umfassen können. Solche Kombinationen werden hiermit explizit vorgeschlagen, sofern nicht im Einzelfall angegeben ist, dass eine bestimmte Kombination nicht beabsichtigt ist. Ferner sollen auch Merkmale eines Anspruchs für jeden anderen unabhängigen Anspruch eingeschlossen sein, selbst wenn dieser Anspruch nicht direkt als abhängig von diesem anderen unabhängigen Anspruch definiert ist.
Bezugszeichenliste Ladeinfrastruktur Ladesteuergerät Schnittstelle Kryptografisch gesichertes Element Steuerungsschaltung Speicher Vorrichtung Schnittstelle Steuerungsschaltung Fahrzeug Verarbeiten einer Kommunikationsnachricht einer Ladeinfrastruktur; Bestimmen zumindest eines Identifikators eines Betreibers der Ladeinfrastruktur basierend auf der Kommunikationsnachricht; Ermitteln einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur Authentifizieren des Lade Steuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt. Steuergerät Backend-Server Erhalten einer Information über zumindest einen Identifikator eines Betreibers einer Ladeinfrastruktur von einem Ladesteuergerät Ermitteln einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur Bereitstellen einer Information über den auszuwählenden Ladekontrakt an das Ladesteuergerät Ladesteuergerät Benutzerschnittstellensteuergerät Intermediär Plug & Charge -Koordinator Aggregator Mobilitätsdienstleister Betreiber einer Ladestation Lade Station

Claims

Patentansprüche
1. Ein Ladesteuergerät (10) für ein Fahrzeug (100), das Ladesteuergerät umfassend: zumindest eine Schnittstelle (12) zur Kommunikation mit einer Ladeinfrastruktur (5); eine Steuerungsschaltung (16), ausgebildet zum:
Verarbeiten einer Kommunikationsnachricht der Ladeinfrastruktur,
Bestimmen zumindest eines Identifikators eines Betreibers der Ladeinfrastruktur basierend auf der Kommunikationsnachricht,
Ermitteln einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur, und Authentifizieren des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt.
2. Das Ladesteuergerät gemäß Anspruch 1, wobei die Kommunikationsnachricht im Rahmen eines Verbindungsaufbaus zwischen der Ladeinfrastruktur und dem Lade Steuergerät empfangen wurde.
3. Das Lade Steuergerät gemäß einem der Ansprüche 1 oder 2, wobei die Steuerungsschaltung ausgebildet ist, um den zumindest einen Identifikator aus einem Leaf-Zertifikat, das von der Ladeinfrastruktur verwendet wird, oder aus einem anderen Zertifikat einer Zertifikatskette, die das Leaf-Zertifikat umfasst, zu extrahieren.
4. Das Ladesteuergerät gemäß Anspruch 3, wobei der zumindest eine Identifikator zumindest eines von einem Supply Equipment Communication Controller Identifier, SECCID, und einem Charge Point Identifier, CPID, umfasst.
5. Das Ladesteuergerät gemäß einem der Ansprüche 1 bis 4, wobei der zumindest eine Identifikator einen Electric Vehicle Supply Equipment Identifier, EVSEID, umfasst.
6. Das Ladesteuergerät gemäß einem der Ansprüche 1 bis 5, wobei die Steuerungsschaltung ausgebildet ist, um eine Mehrzahl von Identifikatoren basierend auf der Kommunikationsnachricht zu bestimmen, und um je nach Betreiber einen oder mehrere der Identifikatoren zu verwenden, um den Betreiber zu identifizieren.
7. Das Ladesteuergerät gemäß einem der Ansprüche 1 bis 6, wobei die Auswahl basierend auf einer Datenstruktur ermittelt wird, wobei in der Datenstruktur für eine Mehrzahl von Betreibern ein auszuwählender Ladekontrakt definiert ist.
8. Das Ladesteuergerät gemäß Anspruch 7, wobei in der Datenstruktur ferner ein Ladekontrakt definiert ist, der auszuwählen ist, falls für einen Betreiber kein auszuwählender Ladekontrakt definiert ist.
9. Das Ladesteuergerät gemäß einem der Ansprüche 1 bis 8, wobei die Auswahl des Ladekontrakts durch die Steuerungsschaltung durchgeführt wird.
10. Das Ladesteuergerät gemäß einem der Ansprüche 1 bis 8, wobei das Ermitteln der Auswahl ein Bereitstellen einer Information über den zumindest einen Identifikator an eine Gegenstelle, und ein Erhalten einer Information über den auszuwählenden Ladekontrakt von der Gegenstelle umfasst, wobei die Gegenstelle ein weiteres Steuergerät (105) des Fahrzeugs oder ein Backend-Server (200) ist.
11. Das Ladesteuergerät gemäß einem der Ansprüche 1 bis 10, wobei die Steuerungsschaltung ferner ausgebildet ist, um eine Liste mit unterstützten Mobilitätsoperatoren von der Ladeinfrastruktur zu erhalten, und um die Auswahl des Ladekontrakts ferner basierend auf der Liste mit unterstützten Mobilitätsoperatoren zu ermitteln.
12. Das Ladesteuergerät gemäß einem der Ansprüche 1 bis 11, wobei die Steuerungsschaltung ferner ausgebildet ist, um, zumindest in dem Fall, dass die Authentifizierung fehlschlägt, eine Information über den zumindest einen Identifikator, über den ausgewählten Ladekontrakt, und über den Erfolg oder Misserfolg der Authentifizierung an einen Backend-Server (200) zu übermitteln.
13. Das Ladesteuergerät gemäß einem der Ansprüche 1 bis 12, wobei die Ladekontrakte und eine Kommunikation mit der Ladeinfrastruktur auf dem Standard ISO 15118 basiert.
14. Eine Vorrichtung (20) zum Ermitteln einer Auswahl eines Ladekontrakts, umfassend: eine Schnittstelle (22) zur Kommunikation mit einem Lade Steuergerät eines Fahrzeugs; und eine Steuerungsschaltung (24), ausgebildet zum:
Erhalten einer Information über zumindest einen Identifikator eines Betreibers einer Ladeinfrastruktur von dem Lade Steuergerät, Ermiteln einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur, und Bereitstellen einer Information über den auszuwählenden Ladekontrakt an das Ladesteuergerät.
15. Ein Verfahren für ein Ladesteuergerät für ein Eahrzeug, das Verfahren umfassend: Verarbeiten (110) einer Kommunikationsnachricht einer Ladeinfrastruktur;
Bestimmen (120) zumindest eines Identifikators eines Betreibers der Ladeinfrastruktur basierend auf der Kommunikationsnachricht;
Ermiteln (130) einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur; und
Authentifizieren (140) des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt.
16. Ein Verfahren zum Ermiteln einer Auswahl eines Ladekontrakts, umfassend:
Erhalten (210) einer Information über zumindest einen Identifikator eines Betreibers einer Ladeinfrastruktur von einem Lade Steuergerät;
Ermiteln (220) einer Auswahl eines Ladekontrakts aus einer Mehrzahl von in dem Ladesteuergerät gespeicherten Ladekontrakten basierend auf dem Betreiber der Ladeinfrastruktur; und
Bereitstellen (230) einer Information über den auszuwählenden Ladekontrakt an das Ladesteuergerät.
17. Programm mit einem Programmcode zum Durchführen des Verfahrens gemäß Anspruch 15 oder des Verfahrens von Anspruch 16, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul, einer Steuerungsschaltung oder einer programmierbaren Hardwarekomponente ausgeführt wird.
EP24702793.1A 2023-03-20 2024-01-31 Konzept für eine ladestationsbasierte ladekontraktauswahl Pending EP4683824A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102023106845.8A DE102023106845A1 (de) 2023-03-20 2023-03-20 Konzept für eine ladestationsbasierte Ladekontraktauswahl
PCT/EP2024/052379 WO2024193883A1 (de) 2023-03-20 2024-01-31 Konzept für eine ladestationsbasierte ladekontraktauswahl

Publications (1)

Publication Number Publication Date
EP4683824A1 true EP4683824A1 (de) 2026-01-28

Family

ID=89772195

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24702793.1A Pending EP4683824A1 (de) 2023-03-20 2024-01-31 Konzept für eine ladestationsbasierte ladekontraktauswahl

Country Status (5)

Country Link
EP (1) EP4683824A1 (de)
KR (1) KR20250144434A (de)
CN (1) CN121001897A (de)
DE (1) DE102023106845A1 (de)
WO (1) WO2024193883A1 (de)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210100545A (ko) * 2020-02-06 2021-08-17 현대자동차주식회사 전기차에 대한 계약 인증서 설치 지원 방법 및 장치
DE102020205022B4 (de) * 2020-04-21 2024-01-04 Siemens Aktiengesellschaft Verfahren, Authentifikationsmittel und Autorisierungseinrichtung zur Autorisierung eines Ladevorgangs
EP4011684A3 (de) * 2020-08-27 2022-07-06 Hyundai Motor Company Verfahren und vorrichtung zur automatischen authentifizierung eines benutzers eines elektrischen fahrzeugs basierend auf einer blockchain
DE102021106261A1 (de) * 2021-03-15 2022-09-15 Audi Aktiengesellschaft Verfahren zur Autorisierung eines ersten Teilnehmers in einem Kommunikationsnetz, Verarbeitungseinrichtung, Kraftfahrzeug und Infrastruktureinrichtung

Also Published As

Publication number Publication date
WO2024193883A1 (de) 2024-09-26
DE102023106845A1 (de) 2024-09-26
KR20250144434A (ko) 2025-10-10
CN121001897A (zh) 2025-11-21

Similar Documents

Publication Publication Date Title
DE102009037193B4 (de) System und Verfahren zum Durchführen eines Austauschs eines asymmetrischen Schlüssels zwischen einem Fahrzeug und einer entfernten Einrichtung
EP3807121B1 (de) Ladesystem zur dynamischen aufladung von elektrofahrzeugen
DE102014114607B4 (de) Programmierung von Fahrzeugmodulen mit Remotevorrichtungen und zugehörige Methoden und Systeme
DE112023003620T5 (de) Interne Zertifizierungsstelle für elektronische Steuereinheit
EP3787222B1 (de) Verfahren zur geschützten kommunikation eines fahrzeugs mit einem externen server, vorrichtung zur durchführung der schlüsselableitung bei dem verfahren sowie fahrzeug
DE102017119373A1 (de) Aktualisierung der servers der netzwerkadresse der mobilvorrichtung
DE102017126113A1 (de) Virtueller schlüssel zum warten eines fahrzeugs
DE102018104079A1 (de) Sichere end-to-end-fahrzeug-ecu-freischaltung in einer halb-offline-umgebung
DE102012224421A1 (de) Fahrzeuggebundenes system und kommunikationsverfahren
DE102016226333A1 (de) Einrichtung für das gewähren der erlaubnis, ein fahrzeug zu steuern, und verfahren für das fahren desselben
DE102019212958B3 (de) Verfahren und Vorrichtung zur Erzeugung von kryptographischen Schlüsseln nach einem Schlüsselableitungsmodell sowie Fahrzeug
DE102017205993A1 (de) System und Verfahren zur selektiven Freischaltung von Fahrzeugfunktionen
DE102019115419A1 (de) Energieübertragungssysteme und -verfahren
DE102023109987A1 (de) System und verfahren zur optimierung der netzwerkverbindung ineinem fahrzeug
DE102017119450A1 (de) Systeme und Verfahren zum Betanken eines Fahrzeugs mit einem Kraftstofflieferdienst
EP4683824A1 (de) Konzept für eine ladestationsbasierte ladekontraktauswahl
DE102017008669A1 (de) Verfahren zum Laden eines elektrochemischen Energiespeichers eines Fahrzeugs
DE102024210824A1 (de) Fahrzeugdomänencontroller, datensicherheitsimplementierungsverfahren, speichermedium und fahrzeug
DE102019125394A1 (de) Vorrichtungen, Verfahren und Computerprogramme für einen Server, ein Verwaltungssystem und ein Fahrzeug
DE102023106848A1 (de) Konzept für nutzerspezifische Provisions- und Ladekontraktzertifikate
DE102023106713A1 (de) Verfahren, Vorrichtungen und Computerprogramme für einen Server und ein Fahrzeug
EP3225043B1 (de) Verfahren und vorrichtung zur kontrolle zumindest eines datenabrufs von einem steuergerät eines fahrzeugs sowie verfahren und vorrichtung zum abrufen von daten von einem steuergerät eines fahrzeugs
DE102023102287A1 (de) Ladesteuergerät, Benutzerschnittstellensteuergerät, Fahrzeug und entsprechende Verfahren und Computerprogramme
DE102022002638A1 (de) Verfahren zum Hinterlegen eines Identifikators auf einer zentralen Recheneinrichtung
DE102016201162B4 (de) Übermitteln einer anzuzeigenden Nachricht an eine Anzeigeeinrichtung eines Kraftfahrzeugs

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250818

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR