EP4658528A1 - Ladesteuergerät, benutzerschnittstellensteuergerät, fahrzeug und entsprechende verfahren und computerprogramme - Google Patents

Ladesteuergerät, benutzerschnittstellensteuergerät, fahrzeug und entsprechende verfahren und computerprogramme

Info

Publication number
EP4658528A1
EP4658528A1 EP23789620.4A EP23789620A EP4658528A1 EP 4658528 A1 EP4658528 A1 EP 4658528A1 EP 23789620 A EP23789620 A EP 23789620A EP 4658528 A1 EP4658528 A1 EP 4658528A1
Authority
EP
European Patent Office
Prior art keywords
charging
contract
contracts
user interface
vehicle
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
EP23789620.4A
Other languages
English (en)
French (fr)
Inventor
Harald Hofmeier
Florian Kotsch
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 EP4658528A1 publication Critical patent/EP4658528A1/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/60—Monitoring or controlling charging stations
    • B60L53/66—Data transfer between charging stations and vehicles
    • B60L53/665—Methods related to measuring, billing or payment
    • 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
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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
    • 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

Definitions

  • Charging control unit user interface control unit, vehicle and corresponding methods and computer programs
  • the invention relates to a charging control device, a user interface control device, a vehicle with a charging control device and a user interface control device, as well as to corresponding methods and computer programs.
  • Plug & Charge (a charging standard for charging electric vehicles) is based on the industry standard ISO 15118.
  • P&C 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 charging point operator can use this number to bill the contract provider (EMP or MO, Electro Mobility Provider or Mobility Operator, often the same as the EMP) for the charging process via the existing roaming platforms or to bill the customer directly (if the CPO is also the contract provider).
  • EMP Electro Mobility Provider or Mobility Operator
  • the vehicle can only transmit one certificate to the charging station; therefore, in many systems, only one certificate is kept on the vehicle.
  • the certificate is usually stored on the charger. Certificates can be installed either via PLC (communication via charging cable) from the charging station or via a backend (i.e. via a server)/telematics connection. Contract certificates are managed in a shared pool (collection) in backends/servers. The certificates are created by the MO and retrieved by the OEM (Original Equipment Manufacturer), for example by the Vehicle manufacturers.
  • a new version of the standard (ISO15118-20) describes a procedure for using multiple certificates. However, this standard requires adjustments to the charging controllers and charging stations and will therefore only be supported by future vehicles. In general, version ISO15118-2 is used in the charging station infrastructure as well as in vehicles. The vehicle and charging station should be able to communicate using the same version of the ISO standard.
  • the present invention is based on the finding that support for multiple charging contracts can be created by storing multiple charging contracts/private keys in a cryptographically secured element (i.e. a "secure element") of the charging control unit of the vehicle instead of storing a single charging contract or a private key of the certificate associated with the charging contract on the charging control unit of the vehicle.
  • a cryptographically secured element i.e. a "secure element”
  • more than one contract certificate can be installed on the vehicle at the same time, for example five certificates.
  • the charging control unit stores information about which of the charging contracts should be used when initiating the charging process (via P&C or comparable procedures).
  • This selection can be made via a user interface control unit (also known as a “head unit”) of the vehicle.
  • the driver of the vehicle has the option of determining which certificates are installed and which certificate is used for the next charging process.
  • the vehicle user interface can give the driver the option of selecting a charging certificate from a list of available certificates (such as the contracts that the customer has already concluded or can conclude).
  • the driver can, for example, install a certain number of charging certificates for use and, if necessary, change the active contract for each charging process. By keeping the certificates in the vehicle, there is no need to download them again when changing. Certificates can be loaded for installation via the vehicle telematics. This makes the installation independent of a charging station.
  • a first aspect of the present disclosure relates to a charging control device for a vehicle.
  • the charging control device comprises at least one interface for communication with a charging infrastructure.
  • the charging control device comprises a cryptographically secured element.
  • the charging control device comprises a control circuit designed to receive a plurality of cryptographically secured charging contracts.
  • the control circuit is designed to store the plurality of charging contracts in the cryptographically secured element.
  • the control circuit is designed to store a selection of a charging contract from the plurality of charging contracts.
  • the control circuit is designed to authenticate the charging control device to the charging infrastructure based on the selected charging contract. This supports the use of a plurality of charging contracts while maintaining compatibility with existing charging infrastructure.
  • the at least one interface comprises an interface for communicating with a user interface controller of the vehicle.
  • the control circuit can be configured to determine metadata about the plurality of cryptographically secured charging contracts and to provide the metadata to the user interface controller of the vehicle. This enables the display of the available charging contracts and the selection of a charging contract by the driver via the user interface controller.
  • the control circuit can be designed to receive a control signal for selecting a charging contract from the user interface controller, and to store the selection based on the control signal. As a result, the selection made by the driver via the user interface controller can be stored and the associated charging contract can be used during the next charging process.
  • the at least one interface can comprise an interface for communicating with a server.
  • the control circuit can be designed to receive the plurality of cryptographically secured charging contracts from the server. This enables the charging contracts to be obtained independently of the charging infrastructure.
  • the charging contracts and communication with the charging infrastructure can be based on the ISO 15118 standard, and in particular ISO 15118-2. This enables the charging infrastructure to be used within the framework of the standard.
  • a further aspect relates to a corresponding method for the charging control device of the vehicle.
  • the method comprises obtaining the plurality of cryptographically secured charging contracts.
  • the method comprises storing the plurality of charging contracts in the cryptographically secured element of the charging control device.
  • the method comprises storing the selection of a charging contract from the plurality of charging contracts.
  • the method comprises authenticating the charging control device to the charging infrastructure based on the selected charging contract.
  • a further aspect relates to a corresponding program with a program code for carrying out the method when the program code is executed on a computer, a processor, a control module or a programmable hardware component, for example on the charging control device.
  • the user interface control device comprises at least one interface for communicating with a charging control device of the vehicle and for communicating with a user interface, such as a user interface of the vehicle or a mobile device of a driver of the vehicle.
  • the user interface control device comprises a control circuit configured to receive metadata about a plurality of charging contracts stored in a cryptographically secured element of the charging controller from the charging controller.
  • the control circuit is configured to display the plurality of charging contracts via the user interface.
  • the control circuit is configured to provide a selection functionality for selecting a charging contract from the plurality of charging contracts via the user interface.
  • the control circuit is configured to provide a control signal for selecting a charging contract for the charging controller based on the selection of the charging contract. This enables the available charging contracts to be displayed and a charging contract to be selected by the driver via the user interface controller.
  • control circuit can be designed to activate or offer the display of the plurality of charging contracts when the vehicle is located at a charging infrastructure. This can make the driver aware that there is a choice between different charging contracts. For example, the driver near a P&C-capable charging station can be informed of the use of P&C on the screen that is displayed when the vehicle is parked and can be given the option of jumping directly to the selection screen.
  • control circuit can be designed to automatically pre-select a charging contract depending on the charging infrastructure and to display the pre-selection together with the majority of charging contracts. This enables the use of a charging contract that is particularly advantageous for the respective charging infrastructure, for example in terms of price. Multiple certificates on the vehicle allow an automated selection of contracts, for example by selecting the cheapest contract at the respective charging station.
  • a further aspect relates to a corresponding method for the user interface control device.
  • the method comprises obtaining the metadata about the plurality of charging contracts stored in the cryptographically secured element of the charging control device from the charging control device.
  • the method comprises displaying the plurality of charging contracts via the user interface of the vehicle.
  • the method comprises providing the selection functionality for selecting a charging contract from the plurality of charging contracts via the user interface.
  • the method comprises providing the Control signal for selecting a charging contract for the charging controller based on the selection of the charging contract.
  • Another aspect relates to a program with a program code for carrying out the method when the program code is executed on a computer, a processor, a control module or a programmable hardware component, such as on the user interface controller.
  • Another aspect of the present disclosure relates to a vehicle comprising the charging controller and the user interface controller.
  • 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 a user interface controller
  • Fig. 2b shows a flowchart of a method for a user interface controller
  • Fig. 3 shows a schematic diagram of a customer perspective on Plug &Charge
  • Fig. 4 shows a schematic diagram of a technical perspective on Plug &Charge
  • Fig. 5 shows a schematic diagram of a Plug and Charge process from the user perspective
  • Fig. 6 shows a schematic representation of the activation and setting of the Plug & Charge function with multiple charging contracts
  • Fig. 7 shows a simplified representation of the technical infrastructure for the use of Plug &Charge; and Figs. 8a and 8b show a menu navigation within the vehicle.
  • Fig. 1a shows a schematic diagram of a charging control device 10 for a vehicle 100, wherein the charging control device 10 is part of the vehicle 100.
  • the charging control device comprises at least one interface 12 for communicating with a charging infrastructure 105 (such as a charging station), for example via powerline communication.
  • the at least one interface 12 comprises an interface for communicating with a user interface control device 20 of the vehicle 100 and/or at least one interface for communicating with a server (not shown), for example via a telematics connection/mobile radio connection.
  • the charging control device 10 comprises a cryptographically secured element 14, such as 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 can be a separate component.
  • the control circuit 16 is designed to receive a plurality of cryptographically secured charging contracts.
  • the control circuit 16 is designed to store the plurality of charging contracts in the cryptographically secured element 14.
  • the control circuit 16 is designed to store a selection of a charging contract from the plurality of charging contracts.
  • the control circuit 16 is designed to authenticate the charging control device 10 to the charging infrastructure 105 based on the selected charging contract.
  • Fig. 1b shows a flow chart of a corresponding method for the charging control device 16.
  • the method includes obtaining 110 the plurality of cryptographically secured charging contracts.
  • the method includes storing 120 the plurality of charging contracts in the cryptographically secured element 14 of the charging control device 10.
  • the method includes storing 130 the selection of a charging contract from the plurality of charging contracts.
  • 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 with reference to the charging control device are described below. Features that are The concepts described in connection with the charging control device can also be applied to the corresponding method or computer program.
  • the proposed concept is based on the fact that not only one cryptographically secured charging contract (i.e. a cryptographically secured certificate of the charging contract, i.e. a contract with a mobility operator or charging infrastructure operator) is stored on the charging control device in the cryptographically secured element 14 of the charging control device, but several. For example, up to a predetermined number (for example up to 4, up to 5, up to 8) charging contracts (i.e. the private keys of the corresponding certificates of the charging contracts) can be stored on the charging control device. At least the private key of the respective certificate of the charging contract is stored within a storage device of the cryptographically secured element.
  • a cryptographically secured certificate of the charging contract i.e. a contract with a mobility operator or charging infrastructure operator
  • NVRAM non-volatile random access memory
  • the charging contracts can be obtained from a server, for example a server of the vehicle manufacturer, or from the charging infrastructure (via powerline communication).
  • the control circuit can be designed to receive the plurality of cryptographically secured charging contracts from the server (for example via the user interface control unit) and/or from the charging infrastructure.
  • the cryptographically secured charging contract is based on a so-called provisioning certificate of the vehicle or the charging control unit.
  • a private part of the provisioning certificate is kept in cryptographically secured element 14, and a public part of the provisioning certificate is made available to the other participants, as shown in Fig. 7, for example via one or more aggregators.
  • the public part can now be used to encrypt the cryptographically secured charging contracts or to restrict their use so that they can only be used using the private part of the provisioning certificate, with commissioning taking place within the cryptographically secured element.
  • the certificate of the charging contract is used to cryptographically secure the communication with the charging infrastructure 105 and to identify the charging control unit to the charging infrastructure.
  • the charging contracts and the communication with the Charging infrastructure should be based on the ISO 15118 standard, and in particular on the ISO 15118-2 standard.
  • the control circuit can thus be designed to determine metadata about the multiple cryptographically secured charging contracts and to provide the metadata for the user interface control device of the vehicle.
  • This metadata can include, for example, an identifier of the charging contract, a validity period of the charging contract, and/or an operator who issued the charging contract. Based on this metadata, the driver of the vehicle can now be enabled to select a charging contract via the user interface control device.
  • the control circuit can receive a control signal for selecting a charging contract from the user interface control device.
  • This control signal can, for example, contain an indicator of which charging contract should be selected.
  • the control circuit can be designed to store the selection based on the control signal. This can be done, for example, by storing a so-called pointer in a data structure, for example within the cryptographically secured element with the aid of the cryptographically secured element or outside the cryptographically secured element.
  • 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 limited to a specific type of processor. limited. Any processor or multiple processors are conceivable for implementation.
  • the control circuit 16 can include the cryptographically secured element 14.
  • 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 user interface control unit 20 (also called “head unit”) for a vehicle.
  • the user interface control device 20 comprises at least one interface 22 for communication with a charging control device 10 (shown in Fig. 1a) of the vehicle and for communication with a user interface, such as a touch-sensitive screen or a combination of screen and haptic input device), of the vehicle (not shown) or outside the vehicle (such as a user interface of a mobile device of a driver of the vehicle, via a mobile application).
  • the user interface control device comprises a control circuit 24 which is coupled to the at least one interface 22.
  • the control circuit 24 is designed to receive metadata about a plurality of charging contracts stored in a cryptographically secured element of the charging control device from the charging control device.
  • the control circuit 24 is designed to display the plurality of charging contracts via the user interface.
  • the control circuit 24 is designed to provide a selection functionality for selecting a charging contract from the plurality of charging contracts via the user interface.
  • the control circuit 24 is designed to provide a control signal for selecting a charging contract for the charging control device based on the selection of the charging contract.
  • Fig. 2b shows a flow chart of a corresponding method for the user interface control device 24.
  • the method includes obtaining 210 the metadata about the plurality of charging contracts stored in the cryptographically secured element of a charging control device from the charging control device.
  • the method includes displaying 220 the plurality of charging contracts via the user interface.
  • the method includes Providing 230 the selection functionality for selecting a charging contract from the plurality of charging contracts via the user interface.
  • the method includes providing 240 the control signal for selecting a charging contract for the charging control device based on the selection of the charging contract.
  • the user interface control device the corresponding method and a corresponding computer program are described with reference to the user interface control device.
  • Features that can be described in connection with the user interface control device can also be applied to the corresponding method or computer program.
  • the user interface controller is used to display and select the existing contracts. This is shown by way of example in Fig. 6 - there, three charging contracts are displayed (DE123456789, DE987654321 and DE555555555), two of which are already installed and one (DE555555555) is available for downloading. Consequently, the control circuit can be designed to display, in addition to the plurality of charging contracts stored in a cryptographically secured element of the charging controller, one or more charging contracts that are available for downloading (for example from a server of the vehicle manufacturer) and to retrieve corresponding information from a server (for example by querying the identifiers of new contract certificates, as shown in Fig. 7, where the user interface controller 710 and the server 740 are shown).
  • the charging contracts that are available on the charging control device can be displayed using the metadata that the user interface control device receives from the charging control device.
  • the control circuit can also retrieve additional information about these charging contracts from the server (740 in Fig. 7), as shown in Fig. 7, for example using the identifiers of the charging contracts.
  • This additional information can include information about the prices of charging processes, e.g. staggered by time, by provider of the charging station, etc., information about the contractual partner of the charging contract, etc.
  • the charging contracts (already installed and possibly also available) are displayed via the user interface.
  • An input modality of the user interface (such as a touch-sensitive screen or a haptic input device) can be used to provide the selection functionality in interaction with the control circuit.
  • the selection functionality can be provided in such a way that the driver can make the selection by tapping or selecting a menu item via the haptic input device. If the user selects a charging contract that is not available on the charging control unit, the control circuit can be designed to retrieve the charging contract as a cryptographically secured charging contract from the server and forward it to the charging control unit.
  • the control circuit can be designed to activate or offer the display of the plurality of charging contracts (for example by requesting or indicating in a screen that is displayed when the driver parks the vehicle) when the vehicle is located at a charging infrastructure.
  • the control circuit can, for example, be designed to recognize that the vehicle is located at a charging infrastructure based on a map with positions of charging infrastructure and based on the position of the vehicle.
  • the control circuit can be designed to recognize that the vehicle is located at a charging infrastructure based on a short-range radio signal that is emitted by the charging infrastructure.
  • the control circuit can be designed to automatically pre-select a charging contract depending on the charging infrastructure and to display the pre-selection together with the majority of charging contracts.
  • Various criteria can be taken into account in the pre-selection, such as the operator of the charging infrastructure, the respective expected price of the respective charging contracts at the charging infrastructure, whether the trip is a private or business trip, etc.
  • the control signal for selecting the charging contract is provided to the charging controller. If a charging contract that has not yet been installed is selected, the control signal may also include the charging contract and/or an instruction for installing and selecting the charging contract.
  • the at least one interface 22 can, for example, have 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 user interface 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.
  • This disclosure relates to the use of multiple contracts (i.e., agreements) in the use of charging infrastructure, such as the “Plug & Charge” charging standard for electric vehicles.
  • Plug & Charge enables drivers of electric vehicles (BEV and PHEV) to automatically authenticate themselves at public charging stations by simply plugging in the charging cable.
  • the feature is based on the ISO standard 15118: charging stations, vehicles and charging contracts that support this standard can offer Plug & Charge. The list of vehicles, charging station operators and contract providers that support Plug & Charge is growing.
  • Plug & Charge comprises three components.
  • Plug & Charge comprises a private contract in which the contract provider charges the customer asks for a specific vehicle identification number (e.g. the vehicle-specific so-called PCID, Provisioning Certificate ID, which can be identical to the VIN, Vehicle Identification Number) to create a digital contract certificate in a backend system.
  • a specific vehicle identification number e.g. the vehicle-specific so-called PCID, Provisioning Certificate ID, which can be identical to the VIN, Vehicle Identification Number
  • the customer can download the charging contract certificate to the vehicle with the corresponding identification number in the vehicle user interface.
  • the vehicle can then be charged using Plug & Charge.
  • the vehicle transmits the contract certificate to the station via so-called powerline communication (i.e. communication via the charging cable).
  • the charging station can now check the contract identifier for charging.
  • vehicles may provide the ability to manage more than one contract: the customer may load multiple contracts onto the vehicle, with one contract being selected in the user interface as the active contract for subsequent loading sessions.
  • Plug & Charge enables a fully automated and secure charging experience through EV-to-charger authentication technology (according to ISO 15118).
  • Fig. 3 shows a schematic diagram of a customer perspective on Plug & Charge. Without Plug & Charge, the charging process includes "plug in”, “authenticate manually” (e.g. via a smart card or mobile application), “wait for charging indicator” and “lock and leave car”. With Plug & Charge, the second point: "authenticate manually” is no longer necessary.
  • Fig. 4 shows a schematic diagram of a technical perspective on Plug & Charge.
  • the vehicle manufacturer shown as OEM in Fig. 4
  • the vehicle user concludes a charging contract with the mobility operator (MO).
  • the vehicle user provides the vehicle identification number (such as the PCID), which can be done by the vehicle manufacturer.
  • 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 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
  • Charging using Plug & Charge and similar protocols offers the advantage that no handling of RFID (radio frequency identification) cards and mobile devices is necessary for the charging process. Nor is handling of the EVSE ID (identification of the supply facility for electric vehicles) or a QR (quick response) code required. Likewise, the use of a smartphone app to start the charging process, which is sometimes common today, is not necessary. The management of several contracts enables the use of the same, and thus the use of different contracts (e.g. via the vehicle manufacturer or other mobility operators).
  • Fig. 5 shows a schematic diagram of a Plug and Charge process from the user perspective.
  • the sections “Setting” (or setup), “Search and find", “Charging session”, “Pay” and “Reset” are distinguished.
  • the “Setting” section includes logging into the charging contract and activating Plug and Charge using a mobile device and activating and setting the function in the vehicle.
  • the “Search and find” section includes searching for a charging station, parking and getting out, plugging in the charging connector, no manual authentication, waiting for the charging indicator, locking and leaving the car and unplugging the charging connector.
  • the "Pay” section includes providing information in payment and charging history on a mobile device.
  • the “Reset” section includes resetting the vehicle. Once the function is set, the customer does not have to perform any authentication activity.
  • the configuration is integrated into existing elements: contract management, charging menu and resetting to factory settings.
  • the setting includes, for example, a Plug & Charge registration process. This can include, for example, logging into a user interface of the vehicle manufacturer (e.g. via an Internet browser) to log in and activate the P&C option.
  • the Plug & Charge settings can be called up via the vehicle management and Plug & Charge can be activated.
  • a contract can be selected so that Plug & Charge is activated.
  • all Plug & Charge capable electric vehicles BEV and PHEV
  • receive a vehicle manufacturer-based charging contract with Plug & Charge functionality A simple check of the vehicle identification number allows the user to check whether the vehicle is Plug & Charge capable.
  • the vehicle manufacturer-based charging contract can be activated for the Plug & Charge functionality when the vehicle is activated.
  • Fig. 6 shows a schematic representation of activating and setting up the Plug & Charge function with multiple charging contracts, and in particular the charging contract activation in the vehicle.
  • Fig. 6 shows three screens that emerge from each other.
  • the main screen of the Plug & Charge contract selection is shown at the top. This includes a switch to activate Plug & Charge, and a display of the available charging contracts, together with an indicator of which charging contract is currently selected.
  • the user interface shows a list of all available contracts (e.g. from the vehicle manufacturer or other sources). In the present case, two installed charging contracts are displayed, of which the top one is selected, and a charging contract that is ready for installation. In the middle, a context menu is also shown that is called up when one of the charging contracts is tapped.
  • buttons include the items Contract details, Activate contract, Download contract (grayed out because the selected contract is already selected), and Delete contract.
  • a screen showing the contract details. This includes a button to delete the contract, as well as an information display with the identification number of the charging contract, information about the expiration date of the contract and information about whether a cost estimate is available for the contract.
  • the user interface enables user-specific installation, activation, selection and configuration of the charging contracts. For example, a distinction can be made between primary and secondary users. Installation, selection and configuration of several Plug & Charge contracts from the vehicle manufacturer or others is possible.
  • FIG. 7 shows a simplified representation of the technical infrastructure for the use of Plug & Charge.
  • Fig. 7 shows a charging control unit 710, which can correspond to the charging control unit 10 of Fig. 1a, a user interface control unit 720, which can correspond to the user interface control unit 20 of Figs.
  • the charging control unit 710 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 commission 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 730 and a public key to the Plug & Charge coordinator 740.
  • the coordinator publishes the commission certificate (i.e. its public key) to the aggregator 750.
  • the commission certificate contains a cryptographically secured identification code for the vehicle (such as the chassis number).
  • a customer signs a charging contract, he provides the vehicle's identification code to the mobility service provider 750 as part of the contract.
  • the mobility service provider creates a new contract certificate.
  • the contract certificate can now be encrypted using the commission certificate (i.e. the public key) so that it can only be decrypted by the vehicle's charging control unit.
  • the appropriate commission certificate is determined using the identification code.
  • the aggregator 750 receives the encrypted contract certificate and informs the Plug & Charge coordinator 740 about it.
  • the coordinator can now receive the contract certificate and provide it to the charging control unit, for example via a telematics connection.
  • the contract certificate can be exchanged via the powerline communication between the charging station 780 and the charging control unit 710.
  • the charging control unit can, as part of a two-way TLS (Transport Layer Security) communication via the Identify contract certificate.
  • the charging station identifies itself using a leaf certificate that is derived from a V2G (vehicle-to-grid) root certificate.
  • the authorization of the charging session takes place between the charging station 780, the operator of the charging station 770 and the aggregator 750, whereby the operator 770 of the charging station can determine the mobility service provider 760 via the aggregator 750. Payment is then made, in accordance with the contract, to the mobility service provider 760 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 710 and receives information about certificates stored there from the charging control unit 710.
  • 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 720 also requests identifiers of new contract certificates (and V2G root certificates) from the Plug & Charge coordinator 740 in order to be able to offer the installation of the contract certificates.
  • the user interface control unit 720 If the installation is initiated, the user interface control unit 720 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 720 and charging control unit 710, for example, diagnostic communication and/or status/configuration communication can be used.
  • the driver will select a charging contract via a user interface on the vehicle.
  • this selection is also possible via a mobile application from the vehicle manufacturer. This can be used as an alternative to the user interface on the vehicle to carry out the configuration and to provide notifications.
  • Figs. 8a and 8b show a menu navigation within the vehicle.
  • Fig. 8a shows the case where Plug & Charge is not supported. In this case, the charging costs are displayed under the "Charging" item in the menu structure. A contract can be selected to estimate the charging costs. This corresponds to the status quo, for example.
  • Fig. 8b shows the case where Plug & Charge is activated. In this case, the item “Plug & Charge” is displayed under the item “Charge” in the menu structure, with the option of selecting a contract for Plug & Charge. This is then used to charge the vehicle.
  • the charger i.e. the charging controller
  • the user interface controller head unit
  • the charging controller provides the user interface controller with metadata of the installed contracts and information about which contract is currently active.
  • the user interface controller provides the charging controller with information about which contract is to be activated. Only the activated contract is transmitted for authentication when plugged into the charging station.
  • the active contract can be selected using various mechanisms via the user interface/user interface controller. This can be done manually by user input, for example, whereby the input remains saved.
  • the user can be informed by the user interface of the possibility of selecting a contract.
  • the selection can, for example, be partially automated using rules defined by the user, such as location/GPS (Global Positioning System)-based or dependent on the operator of the charging station, or fully automated, for example in which the user interface control unit uses a database to determine which installed contracts are compatible with the corresponding charging station (roaming) or which contract is the cheapest when the vehicle is parked.
  • rules defined by the user such as location/GPS (Global Positioning System)-based or dependent on the operator of the charging station, or fully automated, for example in which the user interface control unit uses a database to determine which installed contracts are compatible with the corresponding charging station (roaming) or which contract is the cheapest when the vehicle is parked.
  • 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 therefore also be carried out by programmed computers, Processors or other programmable hardware components. Examples may also cover program storage devices, e.g., digital data storage media, that 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, e.g., 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Power Engineering (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Charge And Discharge Circuits For Batteries Or The Like (AREA)
  • Electric Propulsion And Braking For Vehicles (AREA)

Abstract

Die Erfindung bezieht sich auf ein Ladesteuergerät, ein Benutzerschnittstellensteuergerät, ein Fahrzeug mit einem Ladesteuergerät und einem Benutzerschnittstellensteuergerät, sowie auf entsprechende Verfahren und Computerprogramme. Das Ladesteuergerät umfasst zumindest eine Schnittstelle zur Kommunikation mit einer Ladeinfrastruktur. Das Ladesteuergerät umfasst ein kryptografisch gesichertes Element. Das Ladesteuergerät umfasst eine Steuerungsschaltung, ausgebildet zum Erhalten von mehreren kryptografisch gesicherten Ladekontrakten. Die Steuerungsschaltung ist ausgebildet zum Speichern der mehreren Ladekontrakte in dem kryptografisch gesicherten Element. Die Steuerungsschaltung ist ausgebildet zum Speichern einer Auswahl eines Ladekontraktes der mehreren Ladekontrakte. Die Steuerungsschaltung ist ausgebildet zum Authentifizieren des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt.

Description

Ladesteuergerät, Benutzerschnittstellensteuergerät, Fahrzeug und entsprechende Verfahren und Computerprogramme
Technisches Gebiet
Die Erfindung bezieht sich auf ein Ladesteuergerät, ein Benutzerschnittstellensteuergerät, ein Fahrzeug mit einem Ladesteuergerät und einem Benutzerschnittstellensteuergerä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 (P&C im Folgenden) 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 Ladesä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. Das Zertifikat wird gemäß Norm i.d.R. auf dem Ladegerät gespeichert. Zertifikate können dabei entweder über PLC (Kommunikation über Ladekabel) von der Ladesäule installiert werden oder über eine Backend (d.h. über einen Server) /Telematik-Verbindung. Vertragszertifikate werden in einem gemeinsam genutzten Pool (Sammlung) in Backends/Ser- vern verwaltet. Dabei erfolgt die Erstellung der Zertifikate durch den MO, und der Abruf durch den OEM (Original Equipment Manufacturer, Hersteller der Erstausrüstung), etwa durch den Fahrzeughersteller. Ein neuer Stand der Norm (ISO15118-20) beschreibt ein Verfahren zur Nutzung mehrerer Zertifikate. Jedoch benötigt diese Norm Anpassungen an den Ladecontrollern und an den Ladestationen und wird daher erst von zukünftigen Fahrzeugen unterstützt. Im Allgemeinen wird in der Ladesäulen-Infrastruktur als auch in Fahrzeugen die Version ISO15118-2 verwendet. Dabei sollen Fahrzeug und Ladesäule in der Lage sein, über dieselbe Version der ISO-Norm zu kommunizieren.
In einer Veröffentlichung von Hubject (einem Aggregator) und Volkswagen „Plug&Charge Multi -Contract Handling“ wird auf die Nutzung mehrerer Kontrakte eingegangen. Dabei wird vorgeschlagen, dass Kunden das (einzige) installierte Zertifikat durch ein anderes, gewünschtem Zertifikat austauschen können. Durch die Limitierung der Zertifikatsanzahl ist der Kunde in der Wahl des Ladedienstanbieters (der das Zertifikat ausstellt) eingeschränkt. So funktioniert P&C heute ausschließlich mit den Angeboten der Fahrzeughersteller. Dadurch wird nicht nur der Kunde eingeschränkt (etwa bezüglich der abwechselndem Nutzung eines privaten Vertrags und eines geschäftlichen Vertrags), sondern auch der Wettbewerb bzgl. P&C eingeschränkt. Dies hindert möglicherweise Ladenetzwerke daran, selbst P&C anzubieten und schadet damit der Verbreitung und Akzeptanz dieser Bezahlmethode.
Es besteht der Bedarf nach einem verbesserten Konzept zur technischen Sicherung eines Ladevorgangs von Elektrofahrzeugen.
Zusammenfassung
Die vorliegende Erfindung basiert auf der Erkenntnis, dass eine Unterstützung für mehrere Ladekontrakte dadurch geschaffen werden kann, dass, anstelle der Speicherung eines einzelnen Ladekontrakts, bzw. eines privaten Schlüssels des mit dem Ladekontrakt verbundenen Zertifikats, auf dem Lade Steuergerät des Fahrzeugs, mehrere Ladekontrakte/private Schlüssel in einem kryptografisch gesicherten Element (d.h. einem „Sicheren Element“, Secure Element) des Ladesteuergeräts gespeichert werden kann. In anderen Worten kann auf dem Fahrzeug mehr als ein Vertragszertifikat gleichzeitig installiert werden, etwa fünf Zertifikate. Während der private Schlüssel des jeweiligen Zertifikats/Ladekontrakts in dem kryptografisch gesicherten Element gespeichert wird können das eigentliche Zertifikat, und Metadaten über das Zertifikat, beispielsweise aus Speicherplatzgründen außerhalb des kryptografisch gesicherten Elements gespeichert werden. Zusätzlich dazu speichert das Ladesteuergerät eine Information darüber, welches der Ladekontrakte bei Initiierung des Ladevorgangs (über P&C oder vergleichbare Verfahren) verwendet werden soll. Diese Auswahl kann durch ein Benutzerschnittstellensteuergerät (auch „Head Unit“, Kopfeinheit) des Fahrzeugs getätigt werden. Der Fahrer des Fahrzeugs hat die Möglichkeit, zu bestimmen, welche Zertifikate installiert werden und welches Zertifikat für den nächsten Ladevorgang verwendet wird. Über die Fahrzeug-Bedienoberfläche kann dem Fahrer die Möglichkeit gegeben werden, ein Ladezertifikat aus einer Liste der verfügbaren Zertifikate (etwa der Verträge, die der Kunde bereits abgeschlossen hat, oder abschließen kann) auszuwählen. Der Fahrer kann beispielsweise eine bestimmte Anzahl von Ladezertifikaten zur Nutzung installieren und für jeden Ladevorgang, bei Bedarf, den aktiven Vertrag wechseln. Durch den Vorhalt der Zertifikate im Fahrzeug entfällt ein erneutes Herunterladen beim Wechsel. Zertifikate können dabei über die Fahrzeugtelematik zur Installation geladen werden. Dadurch ist die Installation unabhängig von eine Ladesäule.
Ein erster Aspekt der vorliegenden Offenbarung bezieht sich auf ein Ladesteuergerät für ein Fahrzeug. Das Ladesteuergerät umfasst zumindest eine Schnittstelle zur Kommunikation mit einer Ladeinfrastruktur. Das Ladesteuergerät umfasst ein kryptografisch gesichertes Element. Das Ladesteuergerät umfasst eine Steuerungsschaltung, ausgebildet zum Erhalten von mehreren kryptografisch gesicherten Ladekontrakten. Die Steuerungsschaltung ist ausgebildet zum Speichern der mehreren Ladekontrakte in dem kryptografisch gesicherten Element. Die Steuerungsschaltung ist ausgebildet zum Speichern einer Auswahl eines Ladekontraktes der mehreren Ladekontrakte. Die Steuerungs Schaltung ist ausgebildet zum Authentifizieren des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt. Hierdurch wird die Nutzung mehrerer Ladekontrakte unterstützt, unter Wahrung der Kompatibilität mit existierender Ladeinfrastruktur.
In manchen Beispielen umfasst die zumindest eine Schnittstelle eine Schnittstelle zur Kommunikation mit einem Benutzerschnittstellensteuergerät des Fahrzeugs. Die Steuerungs Schaltung kann ausgebildet sein zum Bestimmen Metadaten über die mehreren kryptografisch gesicherten Ladekontrakte, und zum Bereitstellen der Metadaten für das Benutzerschnittstellensteuergerät des Fahrzeugs. Dies ermöglicht die Darstellung der verfügbaren Ladekontrakte sowie die Auswahl eines Ladekontrakts durch den Fahrer über das Benutzerschnittstellensteuergerät. Beispielsweise kann die Steuerungsschaltung ausgebildet sein zum Erhalten eines Steuersignals zur Auswahl eines Ladekontraktes von dem Benutzerschnittstellensteuergerät, und zum Speichern der Auswahl basierend auf dem Steuersignal. Hierdurch kann die Auswahl, die der Fahrer über das Benutzerschnittstellensteuergerät getroffen wird, gespeichert werden und der dazugehörige Ladekontrakt beim nächsten Ladevorgang verwendet werden.
Neben der Möglichkeit, Ladekontrakte über die Ladesäule zu beziehen wird in zumindest einigen Beispielen der vorliegenden Offenbarung die Möglichkeit genutzt, die Ladekontrakte über einen Server zu beziehen. Beispielsweise kann die zumindest eine Schnittstelle eine Schnittstelle zur Kommunikation mit einem Server umfassen. Die Steuerungsschaltung kann ausgebildet sein zum Erhalten der mehreren kryptografisch gesicherten Ladekontrakten von dem Server. Dies ermöglich das Beziehen der Ladekontrakte unabhängig von der Ladeinfrastruktur.
Beispielsweise können die Ladekontrakte und eine Kommunikation mit der Ladeinfrastruktur auf dem Standard ISO 15118, und insbesondere ISO 15118-2, basieren. Dies ermöglicht eine Nutzung der Ladeinfrastruktur im Rahmen des Standards.
Ein weiterer Aspekt bezieht sich auf ein entsprechendes Verfahren für das Ladesteuergerät des Fahrzeugs. Das Verfahren umfasst ein Erhalten der mehreren kryptografisch gesicherten Ladekontrakte. Das Verfahren umfasst ein Speichern der mehreren Ladekontrakte in dem kryptografisch gesicherten Element des Ladesteuergeräts. Das Verfahren umfasst ein Speichern der Auswahl eines Ladekontraktes der mehreren Ladekontrakte. Das Verfahren umfasst ein Authentifizieren des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt. Ein weiterer Aspekt bezieht sich auf ein entsprechendes Programm mit einem Programmcode zum Durchführen des Verfahrens, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird, etwa auf dem Ladesteuergerät.
Ein weiterer Aspekt der vorliegenden Offenbarung bezieht sich auf ein Benutzerschnittstellensteuergerät für ein Fahrzeug. Das Benutzerschnittstellensteuergerät umfasst zumindest eine Schnittstelle zur Kommunikation mit einem Ladesteuergerät des Fahrzeugs und zur Kommunikation mit einer Benutzerschnittstelle, etwa eine Benutzerschnittstelle des Fahrzeugs oder ein Mobilgerät eines Fahrers des Fahrzeugs. Das Benutzerschnittstellensteuergerät umfasst eine Steuerungs Schaltung, ausgebildet zum Erhalten von Metadaten über eine Mehrzahl von Ladekontrakten, die in einem kryptografisch gesicherten Element des Ladesteuergeräts gespeichert sind, von dem Ladesteuergerät. Die Steuerungs Schaltung ist ausgebildet zum Anzeigen der Mehrzahl von Ladekontrakte über die Benutzerschnittstelle. Die Steuerungsschaltung ist ausgebildet zum Bereitstellen einer Auswahlfunktionalität zur Auswahl eines Ladekontrakts aus der Mehrzahl von Ladekontrakten über die Benutzerschnittstelle. Die Steuerungsschaltung ist ausgebildet zum Bereitstellen eines Steuersignals zur Auswahl eines Ladekontraktes für das Ladesteuergerät basierend auf der Auswahl des Ladekontrakts. Dies ermöglicht die Darstellung der verfügbaren Ladekontrakte sowie die Auswahl eines Ladekontrakts durch den Fahrer über das Benutzerschnittstellensteuergerät.
Beispielsweise kann die Steuerungsschaltung ausgebildet sein, das Anzeigen der Mehrzahl von Ladekontrakte zu aktivieren oder anzubieten, wenn sich das Fahrzeug an einer Ladeinfrastruktur befindet. Hierdurch kann der Fahrer darauf aufmerksam gemacht werden, dass die Auswahl zwischen verschiedenen Ladekontrakten besteht. Beispielsweise kann der Fahrer in der Nähe einer P&C-fähigen Ladestation im Bildschirm, der bei Abstellen des Fahrzeugs angezeigt wird, auf die Nutzung von P&C hingewiesen werden und direkt die Möglichkeit erhalten, in den Auswahlbildschirm zu springen.
In manchen Beispielen kann die Steuerungsschaltung ausgebildet sein, abhängig von der Ladeinfrastruktur automatisch eine Vorauswahl eines Ladekontrakts durchzuführen und die Vorauswahl zusammen mit der Mehrzahl von Ladekontrakten anzuzeigen. Dies ermöglicht die Nutzung eines Ladekontrakts, der für die jeweilige Ladeinfrastruktur besonders vorteilhaft ist, etwa in Bezug auf den Preis. Mehrere Zertifikate auf dem Fahrzeug erlauben etwa eine automatisierte Auswahl von Verträgen, etwa durch Auswahl des günstigsten Vertrags bei der jeweiligen Ladestation.
Ein weiterer Aspekt bezieht sich auf ein entsprechendes Verfahren für das Benutzerschnittstellensteuergerät. Das Verfahren umfasst ein Erhalten der Metadaten über die Mehrzahl von Ladekontrakten, die in dem kryptografisch gesicherten Element des Ladesteuergeräts gespeichert sind, von dem Ladesteuergerät. Das Verfahren umfasst ein Anzeigen der Mehrzahl von Ladekontrakte über die Benutzerschnittstelle des Fahrzeugs. Das Verfahren umfasst ein Bereitstellen der Auswahlfunktionalität zur Auswahl eines Ladekontrakts aus der Mehrzahl on Ladekontrakten über die Benutzerschnittstelle. Das Verfahren umfasst ein Bereitstellen des Steuersignals zur Auswahl eines Ladekontraktes für das Ladesteuergerät basierend auf der Auswahl des Ladekontrakts. Ein weiterer Aspekt bezieht sich auf ein Programm mit einem Programmcode zum Durchführen des Verfahrens, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird, etwa auf dem Benutzerschnittstellensteuergerät.
Ein weiterer Aspekt der vorliegenden Offenbarung bezieht sich auf ein Fahrzeug, umfassend das Ladesteuergerät und das Benutzerschnittstellensteuergerät.
Figurenkurzbeschreibung
Einige Beispiele von Vorrichtungen und/oder Verfahren werden nachfolgend bezugnehmend auf die beiliegenden Figuren lediglich beispielhaft 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 eines Benutzerschnittstellensteuergeräts;
Fig. 2b zeigt ein Flussdiagramm eines Verfahrens für ein Benutzerschnittstellensteuergerät;
Fig. 3 zeigt ein schematisches Diagramm einer Kundenperspektive auf Plug & Charge;
Fig. 4 zeigt ein schematisches Diagramm einer technischen Perspektive auf Plug & Charge;
Fig. 5 zeigt ein schematisches Diagramm eines Ablaufs von Plug and Charge aus der Anwenderperspektive;
Fig. 6 zeigt eine schematische Darstellung des Aktivieren und Einstellen der Plug & Charge- Funktion mit mehreren Ladekontrakten;
Fig. 7 zeigt eine vereinfachte Darstellung der technischen Infrastruktur für die Nutzung von Plug & Charge; und Fign. 8a und 8b und zeigen eine Menüführung innerhalb des Fahrzeugs.
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 „auf- weisend“ 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 Ladesteuergerät umfasst zumindest eine Schnittstelle 12 zur Kommunikation mit einer Ladeinfrastruktur 105 (etwa einer Ladesäule), etwa über eine Powerline-Kommunikation. In manchen Beispielen umfasst die zumindest eine Schnittstelle 12 eine Schnittstelle zur Kommunikation mit einem Benutzerschnittstellensteuergerät 20 des Fahrzeugs 100 und/oder zumindest eine Schnittstelle zur Kommunikation mit einem Server (nicht gezeigt), etwa über eine Telematikverbindung/Mo- bilfunkverbindung. Das Ladesteuergerät 10 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. Die Steuerungsschaltung 16 ist ausgebildet zum Erhalten von mehreren kryptografisch gesicherten Ladekontrakten. Die Steuerungsschaltung 16 ist ausgebildet zum Speichern der mehreren Ladekontrakte in dem kryptografisch gesicherten Element 14. Die Steuerungsschaltung 16 ist ausgebildet zum Speichern einer Auswahl eines Ladekontraktes der mehreren Ladekontrakte. Die Steuerungsschaltung 16 ist ausgebildet zum Authentifizieren des Ladesteuergeräts 10 gegenüber der Ladeinfrastruktur 105 basierend auf dem ausgewählten Ladekontrakt.
Fig. 1b zeigt ein Flussdiagramm eines entsprechenden Verfahrens für das Ladesteuergerät 16. Das Verfahren umfasst ein Erhalten 110 der mehreren kryptografisch gesicherten Ladekontrakte. Das Verfahren umfasst ein Speichern 120 der mehreren Ladekontrakte in dem kryptografisch gesicherten Element 14 des Ladesteuergeräts 10. Das Verfahren umfasst ein Speichern 130 der Auswahl eines Ladekontraktes der mehreren Ladekontrakte. Das Verfahren umfasst ein Authentifizieren 140 des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt.
Im Folgenden wird das Ladesteuergerä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.
Das vorgeschlagene Konzept basiert darauf, dass auf dem Ladesteuergerät nicht nur ein kryptografisch gesicherter Ladekontrakt (d.h. ein kryptografisch gesichertes Zertifikat des Ladekontrakts, also eines Vertrags mit einem Mobilitätsoperator oder Ladeinfrastrukturbetreiber) in dem kryptografisch gesicherten Element 14 des Ladesteuergeräts gespeichert wird, sondern mehrere. Beispielsweise kann bis zu eine vorgegebene Anzahl (etwa bis zu 4, bis zu 5, bis zu 8) Ladekontrakte (d.h. die privaten Schlüssel der entsprechenden Zertifikate der Ladekontrakte) auf dem Ladesteuergerät gespeichert werden. Dabei wird zumindest der private Schlüssel des jeweiligen Zertifikats des Ladekontrakts innerhalb einer Speichereinrichtung des kryptografisch gesicherten Elements gespeichert. Übrige Bestandteile des jeweiligen Zertifikats des Ladekontrakts können, etwa zusammen mit Metadaten, innerhalb der Speichereinrichtung des kryptografisch gesicherten Elements oder außerhalb des kryptografisch gesicherten Elements gespeichert werden, etwa in einem sogenannten NVRAM (Non-Volatile Randam-Ac- cess Memory, nichtflüchtiger Direktzugriffsspeicher) des Ladesteuergeräts . Die Ladekontrakte können etwa von einem Server bezogen werden, etwa einem Server des Fahrzeugherstellers, oder von der Ladeinfrastruktur (über die Powerline-Kommunikation). In anderen Worten kann die Steuerungs Schaltung ausgebildet sein zum Erhalten der mehreren kryptografisch gesicherten Ladekontrakten von dem Server (etwa über das Benutzerschnittstellensteuergerät) und/oder von der Ladeinfrastruktur.
Der kryptografisch gesicherte Ladekontrakt basiert auf einem sogenannten Provisionierungs- zertifikat des Fahrzeugs oder des Ladesteuergeräts. Ein privater Teil des Provisionierungszer- tifikat wird in kryptografisch gesicherten Element 14 vorgehalten, und ein öffentlicher Teil des Provisionierungszertifikats wird, wie in Fig. 7 dargestellt, den übrigen Teilnehmern bereitgestellt, etwa über ein oder mehrere Aggregatoren. Der öffentliche Teil kann nun genutzt werden, um die kryptografisch gesicherten Ladekontrakte zu verschlüsseln oder ihre Nutzung einzuschränken, so dass sie nur unter Nutzung des privaten Teils des Provisionierungszertifi- kat genutzt werden können, wobei die Inbetriebnahme innerhalb des kryptografisch gesicherten Elements geschieht. Während der Authentifizierung des Ladesteuergeräts wird nun zumindest das Zertifikat des Ladekontrakts genutzt, um die Kommunikation mit der Ladeinfrastruktur 105 kryptografisch abzusichem und das Ladesteuergerät gegenüber der Ladeinfrastruktur zu identifizieren. Dabei können die Ladekontrakte und die Kommunikation mit der Ladeinfrastruktur auf dem Standard ISO 15118, und insbesondere auf dem Standard ISO 15118-2, basieren.
Welches der Ladekontrakte (d.h. welches der Zertifikate) dafür verwendet wird, kommt auf die Auswahl des Ladekontrakts an. Standardmäßig kann eine Vorauswahl getroffen sein, etwa eine Auswahl des zuerst installierten Ladekontrakts. Diese Vorauswahl kann dann über das Benutzerschnittstellengerät geändert werden. So kann die Steuerungsschaltung ausgebildet sein zum Bestimmen von Metadaten über die mehreren kryptografisch gesicherten Ladekontrakte, und zum Bereitstellen der Metadaten für das Benutzerschnittstellensteuergerät des Fahrzeugs. Diese Metadaten können beispielsweise einen Identifikator des Ladekontrakts, eine Gültigkeitsdauer des Ladekontrakts, und/oder einen Betreiber, der den Ladekontrakt ausgestellt hat, umfassen. Auf Basis dieser Metadaten kann dem Fahrer des Fahrzeugs nun, über das Benutzerschnittstellensteuergerät, die Auswahl eines Ladekontrakts ermöglicht werden. Als Reaktion auf die bereitgestellten Metadaten kann die Steuerungs Schaltung ein Steuersignal zur Auswahl eines Ladekontraktes von dem Benutzerschnittstellensteuergerät erhalten. Dieses Steuersignal kann beispielsweise einen Indikator enthalten, welcher Ladekontrakt ausgewählt werden soll. Die Steuerungsschaltung kann ausgebildet sein zum Speichern der Auswahl basierend auf dem Steuersignal. Dies kann etwa durch Speichern eines sogenannten Pointers (Verweises) in einer Datenstruktur geschehen, etwa innerhalb des kryptografisch gesicherten Elements unter Zuhilfenahme des kryptografisch gesicherten Elements oder außerhalb des kryptografisch gesicherten Elements.
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 Steuerungs Schaltung 16 das kryptografisch gesicherte Element 14 umfassen.
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. 2 bis 8b) 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 eines Benutzerschnittstellensteuergeräts 20 (auch „Head Unit“, Kopfeinheit, genannt) für ein Fahrzeug. Das Benutzerschnittstellensteuergerät 20 umfasst zumindest eine Schnittstelle 22 zur Kommunikation mit einem Ladesteuergerät 10 (in Fig. la gezeigt) des Fahrzeugs und zur Kommunikation mit einer Benutzerschnittstelle, etwa eines berührungsempfindlichen Bildschirms oder einer Kombination aus Bildschirm und haptischem Eingabegerät), des Fahrzeugs (nicht gezeigt) oder außerhalb des Fahrzeugs (etwa eine Benutzerschnittstelle eines Mobilgeräts eines Fahrers des Fahrzeugs, über eine mobile Applikation=. Das Benutzerschnittstellensteuergerät umfasst eine Steuerungsschaltung 24, die mit der zumindest einen Schnittstelle 22 gekoppelt ist. Die Steuerungsschaltung 24 ist ausgebildet zum Erhalten von Metadaten über eine Mehrzahl von Ladekontrakten, die in einem kryptografisch gesicherten Element des Ladesteuergeräts gespeichert sind, von dem Ladesteuergerät. Die Steuerungsschaltung 24 ist ausgebildet zum Anzeigen der Mehrzahl von Ladekontrakte über die Benutzerschnittstelle. Die Steuerungsschaltung 24 ist ausgebildet zum Bereitstellen einer Auswahlfunktionalität zur Auswahl eines Ladekontrakts aus der Mehrzahl von Ladekontrakten über die Benutzerschnittstelle. Die Steuerungsschaltung 24 ist ausgebildet zum Bereitstellen eines Steuersignals zur Auswahl eines Ladekontraktes für das Ladesteuergerät basierend auf der Auswahl des Ladekontrakts.
Fig. 2b zeigt ein Flussdiagramm eines entsprechenden Verfahrens für das Benutzerschnittstellensteuergerät 24. Das Verfahren umfasst ein Erhalten 210 der Metadaten über die Mehrzahl von Ladekontrakten, die in dem kryptografisch gesicherten Element eines Ladesteuergeräts gespeichert sind, von dem Ladesteuergerät. Das Verfahren umfasst ein Anzeigen 220 der Mehrzahl von Ladekontrakte über die Benutzerschnittstelle. Das Verfahren umfasst ein Bereitstellen 230 der Auswahlfunktionalität zur Auswahl eines Ladekontrakts aus der Mehrzahl von Ladekontrakten über die Benutzerschnittstelle. Das Verfahren umfasst ein Bereitstellen 240 des Steuersignals zur Auswahl eines Ladekontraktes für das Ladesteuergerät basierend auf der Auswahl des Ladekontrakts.
Im Folgenden wird das Benutzerschnittstellensteuergerät, das entsprechende Verfahren sowie ein entsprechendes Computerprogramm mit Bezug auf das Benutzerschnittstellensteuergerät beschrieben. Merkmale, die im Zusammenhang mit dem Benutzerschnittstellensteuergerät beschrieben werden können, gleichfalls auf das entsprechende Verfahren oder Computerprogramm angewandt werden.
Im vorgeschlagenen Konzept wird das Benutzerschnittstellensteuergerät für die Anzeige und die Auswahl der vorhandenen Kontrakte genutzt. Dies ist beispielhaft etwa in Fig. 6 gezeigt - dort werden drei Ladekontrakte angezeigte (DE123456789, DE987654321 und DE555555555), wovon zwei bereits installiert sind und einer (DE555555555) zum Herunterladen bereitsteht. Folglich kann die Steuerungsschaltung ausgebildet sein, um, neben der Mehrzahl von Ladekontrakten, die in einem kryptografisch gesicherten Element des Ladesteuergeräts gespeichert sind, auch ein oder mehrere Ladekontrakte anzuzeigen, die zum Herunterladen (etwa von einem Server des Fahrzeugherstellers) verfügbar sein, und um entsprechende Informationen von einem Server abzurufen (etwa durch Abfragen der Identifikatoren von neuen Kontraktzertifikaten, wie in Fig. 7 gezeigt, wo das Benutzerschnittstellensteuergerät 710 und der Server 740 gezeigt sind). Die Ladekontrakte, die auf dem Ladesteuergerät verfügbar sind, können anhand der Metadaten angezeigt werden, die das Benutzerschnittstellensteuergerät von dem Ladesteuergerät erhält. Zusätzliche Informationen über diese Ladekontrakte kann die Steuerungsschaltung ebenfalls, wie etwa in Fig. 7 gezeigt, von dem Server (740 in Fig. 7) abrufen, etwa anhand der Identifikatoren der Ladekontrakte. Diese zusätzlichen Informationen können etwa Informationen über die Preise von Ladevorgängen, etwa gestaffelt nach Zeit, nach Anbieter der Ladesäule etc., Informationen über den Vertragspartner des Ladekontrakts etc. umfassen
Die Ladekontrakte (bereits installierte und ggf. auch verfügbare) werden mittels der Benutzerschnittstelle angezeigt. Eine Eingabemodalität der Benutzerschnittstelle (etwa ein berührungsempfindlicher Bildschirm oder ein haptisches Eingabegerät) kann genutzt werden, um die Auswahlfunktionalität im Zusammenspiel mit der Steuerungsschaltung bereitzustellen. Beispielweise kann die Auswahlfunktionalität so bereitgestellt werden, dass der Fahrer die Auswahl durch Antippen oder Auswählen eines Menüpunkts über das haptische Eingabegerät treffen kann. Wählt der Benutzer einen Ladekontrakt aus, der nicht auf dem Ladesteuergerät verfügbar ist, so kann die Steuerungsschaltung ausgebildet sein, um den Ladekontrakt als kryptografisch gesicherten Ladekontrakt von dem Server abzurufen und dem Ladesteuergerät weiterzuleiten.
Verschiedene Maßnahmen können ergriffen werden, um die Auswahl des Ladekontrakts zu unterstützen. So kann die Steuerungs Schaltung beispielsweise ausgebildet sein, um das Anzeigen der Mehrzahl von Ladekontrakte zu aktivieren oder anzubieten (etwa durch Aufforderung oder Hinweis in einem Bildschirm, der angezeigt wird, wenn der Fahrer das Fahrzeug abstellt), wenn sich das Fahrzeug an einer Ladeinfrastruktur befindet. Dazu kann die Steuerungsschaltung beispielsweise ausgebildet sein, zu erkennen, dass sich das Fahrzeug an einer Ladeinfrastruktur befindet, anhand einer Karte mit Positionen von Ladeinfrastruktur sowie anhand der Position des Fahrzeugs. Alternativ oder zusätzlich kann die Steuerungsschaltung ausgebildet sein, zu erkennen, dass sich das Fahrzeug an einer Ladeinfrastruktur befindet, anhand eines Nahbereichsfunksignals, das von der Ladeinfrastruktur ausgesendet wird.
Doch auch die eigentliche Auswahl kann unterstützt werden. So kann die Steuerungsschaltung ausgebildet sein, um abhängig von der Ladeinfrastruktur automatisch eine Vorauswahl eines Ladekontrakts durchzuführen und die Vorauswahl zusammen mit der Mehrzahl von Ladekontrakten anzuzeigen. Dabei können bei der Vorauswahl verschiedene Kriterien beachtet werden, wie etwa der Betreiber der Ladeinfrastruktur, der jeweilige zu erwartende Preis der jeweiligen Ladekontrakte an der Ladeinfrastruktur, ob die Fahrt eine private oder dienstliche Fahrt ist etc.
Ist die Auswahl getroffen (oder wird eine Auswahl getroffen, die von der bisher getroffenen Auswahl abweicht), dann wird das Steuersignals zur Auswahl des Ladekontraktes für das Ladesteuergerät bereitgestellt. Wird ein Ladekontrakt ausgewählt, der bisher noch nicht installiert ist, dann kann das Steuersignal auch den Ladekontrakt und/oder eine Anweisung zum Installieren und Auswählen des Ladekontrakts umfassen.
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 des Benutzerschnittstellensteuergeräts, 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 8b) beschrieben werden. Das Benutzerschnittstellensteuergerä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.
Die vorliegende Offenbarung bezieht sich auf die Nutzung mehrerer Kontrakte (d.h. Verträge) bei der Nutzung von Ladeinfrastruktur, etwa gemäß des „Plug & Charge“ (Einstecken und Laden)-Ladestandards für Elektroautos.
Plug & Charge ermöglicht es Fahrern von Elektrofahrzeugen (BEV und PHEV), sich an öffentlichen Ladestationen automatisch zu authentifizieren, indem sie einfach das Ladekabel einstecken. Die Funktion basiert auf dem ISO-Standard 15118: Ladestationen, Fahrzeuge und Ladeverträge, die diesen Standard unterstützen Standard unterstützen, können Plug & Charge anbieten. Die Liste der Fahrzeuge, Betreiber von Ladestationen und Vertragsanbietem, die Plug & Charge unterstützen, wächst.
In einer vereinfachten Darstellung umfasst Plug & Charge drei Komponenten. Zuerst umfasst Plug & Charge einen privaten Vertrag (Kontrakt), bei dem der Vertragsanbieter den Kunden nach einer spezifischen Fahrzeug-Identifikationsnummer frägt (etwa die fahrzeugspezifische sogenannte PCID, Provisioning Certificate ID, Provisionierunszertifikatsidentifikator, die mit der VIN, Vehicle Identification Number, identisch sein kann), um ein digitales Vertragszertifikat in einem Backend-System zu erstellen. Es folgt das Herunterladen und Aktivieren des Vertrags. Dabei kann der Kunde das Zertifikat des Ladevertrags auf das Fahrzeug herunterladen, mit der entsprechenden Identifikationsnummer in der Fahrzeugbedienoberfläche. Danach kann das Fahrzeug mittels Plug & Charge aufgeladen werden. Wenn das Fahrzeug das nächste Mal an einer kompatiblen Ladestation eingesteckt wird, überträgt das Fahrzeug das Vertragszertifikat über eine sogenannte Powerline-Kommunikation (d.h. Kommunikation über das Ladekabel) an die Station. Die Ladestation kann nun die Vertragskennung für das Laden prüfen.
Gemäß der vorliegenden Offenbarung können Fahrzeuge die Möglichkeit bieten, mehr als einen Vertrag (Kontrakt) zu verwalten: Der Kunde kann mehrere Verträge auf das Fahrzeug laden. Dabei wird ein Vertrag in der Benutzeroberfläche als aktiver Vertrag für die nächsten Ladevorgänge ausgewählt.
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 Kundenperspektive auf Plug & Charge. Ohne Plug & Charge umfasst der Ladevorgang „Einstecken“, „Händisch authentifizieren“ (etwa über eine Smartcard oder eine mobile Applikation), „Auf Ladeindikator warten“ und „Abschließen und Auto zurücklassen“. Mit Plug & Charge entfällt der zweite Punkt: „Händisch authentifizieren“.
Fig. 4 zeigt ein schematisches Diagramm einer technischen Perspektive auf Plug & Charge. Zuerst (1.) stellt der Fahrzeughersteller (als OEM in Fig. 4 dargestellt) ein Provisionierungs- zertifikat einem Aggregator bereit. 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.
Das Laden mittels Plug & Charge und ähnlicher Protokolle bietet den Vorteil, dass keine Handhabung von RFID (Radiofrequenz-Identifikation)-Karten und Mobilgeräten für den Ladevorgang notwendig ist. Auch ist keine Handhabung der EVSE ID (Kennung der Versorgungseinrichtung für Elektrofahrzeuge) oder eines QR (Quick Response, schnelle Reaktion- Kode erforderlich. Ebenso ist die heute teilweise übliche Nutzung einer Smartphone app zum starten des Ladevorgangs nicht nötig. Die Verwaltung mehrerer Kontrakte ermöglicht die Nutzung derselben, und damit die Nutzung verschiedener Verträge (etwa über den Fahrzeughersteller oder andere Mobilitätsoperatoren).
Fig. 5 zeigt ein schematisches Diagramm eines Ablaufs von Plug and Charge aus der Anwenderperspektive. Es werden die Abschnitte „Einstellen“ (oder Einrichtung), „Suchen und Finden“, „Ladesitzung“, „Bezahlen“ und „Zurücksetzen“ unterschieden. Der Abschnitt „Einstellen“ umfasst anmelden am Lade-Kontrakt und Plug-and-Charge aktivieren mittels eines Mobilgeräts und aktivieren und Funktion einstellen in Fahrzeug. Der Abschnitt „Suchen und Finden“ umfasst nach Ladestation suchen, parken und aussteigen, einstecken des Ladestutzen, kein händisches authentifizieren, auf Ladeindikator warten, abschließen und Auto zurücklassen und ausstecken des Ladestutzen. Der Abschnitt „Bezahlen“ umfasst ein Bereitstellen von Informationen in Bezahl- und Ladehistorie auf einem Mobilgerät. Der Abschnitt „Zurücksetzen“ umfasst ein Zurücksetzen des Fahrzeugs. Wenn die Funktion einmal eingestellt ist, muss der Kunde keine Aktivität zur Authentifizierung durchführen. Die Konfiguration ist in bestehende Elemente integriert: Vertragsmanagement, Lademenü sowie zurücksetzen auf Werkseinstellungen.
Das Einstellen umfasst beispielsweise einen Plug & Charge Registrierungsprozess. Dieser kann beispielsweise ein Anmelden an einer Benutzeroberfläche des Fahrzeugherstellers (etwa über einen Intemetbrowser) um sich anzumelden und die P&C-Option zu aktivieren umfassen. Dort können über die Fahrzeugverwaltung beispielsweise die Plug & Charge-Einstellungen aufgerufen werden und Plug & Charge aktiviert werden. Zudem kann ein Vertrag ausgewählt werden, so dass Plug & Charge aktiviert wird. Beispielsweise können alle Plug & Charge- fähigen Elektrofahrzeuge (BEV und PHEV) einen fahrzeugherstellerbasierten Ladevertrag mit Plug & Charge-Funktionalität erhalten. Eine einfache Überprüfung der Fahrzeugidentifikationsnummer ermöglicht es dem Nutzer zu prüfen, ob das Fahrzeug Plug & Charge— fähig ist. Der fahrzeugherstellerbasierte Ladevertrag kann für die Plug & Charge-Funktionalität aktiviert werden, wenn das Fahrzeug freigeschaltet ist.
Fig. 6 zeigt eine schematische Darstellung des Aktivieren und Einstellen der Plug & Charge- Funktion mit mehreren Ladekontrakten, und insbesondere die Ladekontraktaktivierung im Fahrzeug. In Fig. 6 sind drei Bildschirme gezeigt, die auseinander hervorgehen. Oben ist der Hauptbildschirm der Plug & Charge-Kontraktauswahl gezeigt. Dieser umfasst einen Schalter zur Aktivierung von Plug & Charge, und eine Anzeige der verfügbaren Ladekontrakte, zusammen mit einem Indikator, welcher Ladekontrakt derzeit ausgewählt wird. Beispielsweise zeigt die Benutzeroberfläche eine Liste aller verfügbaren Verträge (etwa des Fahrzeugherstellers oder anderer Quellen). Im vorliegenden Fall werden zwei installierte Ladekontrakte angezeigt, von denen der obere ausgewählt ist, und ein Ladekontrakt, der zur Installation bereit ist. In der Mitte ist zusätzlich ein Kontextmenü gezeigt, das aufgerufen wird, wenn einer der Ladekontrakte angetippt wird. Dieses zeigt eine Identifikationsnummer des Ladekontrakts sowie Knöpfe, um zu weiteren Bildschirmen zu gelangen. Die Knöpfe umfassen die Punkte Kontraktdetails, Kontrakt aktivieren, Kontrakt herunterladen (ausgegraut, da der ausgewählte Kontrakt bereits ausgewählt ist), sowie Kontrakt Löschen. Unten ist ein Bildschirm mit einer Anzeige der Kontraktdetails gezeigt. Diese umfasst einen Knopf zum Löschen des Kontrakts, sowie eine Informationsanzeige mit der Identifikationsnummer des Ladekontrakts, einer Information über ein Ablaufdatum des Kontrakts sowie eine Information darüber, ob eine Kostenschätzung für den Kontrakt verfügbar ist. Die Benutzerführung ermöglicht eine benutzerspezifische Installation, Aktivierung, Auswahl und Konfiguration der Ladekontrakte. Dabei kann beispielsweise zwischen Primär- und Sekundärnutzer unterschieden werden. Eine Installation, Auswahl und Konfiguration von mehreren Plug & Charge Verträgen des Fahrzeugherstellers oder anderer ist möglich.
Plug & Charge wird mittels sogenannter Aggregatoren angeboten, wobei die Aggregatoren dafür sorgen, dass ein Kontrakt in mehreren Ländern genutzt werden kann, bzw. mehrere Kontrakte pro Land genutzt werden können. In China wird mit Easy Charge ein ähnlicher Ansatz verfolgt. Die vorliegende Erfindung ist dabei angepasst auch mit Easy Charge verwendbar. In Fig. 7 ist eine vereinfachte Darstellung der technischen Infrastruktur für die Nutzung von Plug & Charge gezeigt. Fig. 7 zeigt ein Ladesteuergerät 710, das dem Ladesteuergerät 10 von Fig. la entsprechen kann, ein Benutzerschnittstellensteuergerät 720, das dem Benutzerschnittstellensteuergerät 20 der Fign. la und 1b entsprechen kann, einen Intermediär 730 (der im Fahrzeug oder bei der Fertigung des Fahrzeugs genutzt werden kann), ein Plug & Charge- Koordinator 740 (seitens des Fahrzeugherstellers), einen Aggregator 750, einen Mobilitätsdienstleister 760, einen Betreiber der Ladestation 770, sowie die Ladestation 780. Das Ladesteuergerät 710ist 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 Provisionszertifikate 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 740 durchgeführt. Dieser erhält einen Certificate Signing Request (CSR, Zertifikatssignierungsanfrage) von dem Ladesteuergerät, und stellt einen privaten Schlüssel des Zertifikats dem Ladesteuergerät 730 bereit und einen öffentlichen Schlüssel dem Plug & Charge-Koordinator 740. Dieser veröffentlich das Provisionszertifikat (d.h. den öffentlichen Schlüssel davon) bei dem Aggregator 750. 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 750 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 dem Ladesteuergerät des Fahrzeugs entschlüsselt werden kann. Das passende Provisionszertifikat wird mittels der Identifikationskennung ermittelt. Der Aggregator 750 erhält das verschlüsselte Kontrakt- Zertifikat und informiert den Plug & Charge-Koordinator 740 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 780 und Ladesteuergerät 710 ausgetauscht werden. Verfügt das Ladesteuergerät über ein entsprechendes Kontraktzertifikat, so kann es sich, im Rahmen einer zweiseitigen TLS (Transport Layer Security, Transportschichtsicherheit)-Kommunikation über das Kontraktzertifikat identifizieren. Die Ladestation identifiziert sich über ein Blattzertifikat, das von einem V2G (Vehicle-to-Grid, Fahrzeug-zu-Netz)-Wurzelzertifikat abgeleitet ist. Die Autorisierung der Ladesitzung erfolgt zwischen Ladestation 780, Betreiber der Ladestation 770 und Aggregator 750, wobei der Betreiber 770 der Ladestation den Mobilitätsdienstleister 760 über den Aggregator 750 ermitteln kann. Die Bezahlung erfolgt dann, gemäß Kontrakt, über einen E-Mobilitäts-Identifikator an den Mobilitätsdienstleister 760.
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 Ladesteuergerät 710 und erhält Informationen über dort gespeicherte Zertifikate von dem Ladesteuergerät 710. Ü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 720 fragt zudem Identifikatoren von neuen Kontraktzertifikaten (und V2G-Wurzelzertifika- ten) am Plug & Charge-Koordinator 740 an, um die Installation der Kontraktzertifikate anbieten zu können. Wird die Installation veranlasst, dann fragt das Benutzerschnittstellensteuergerät 720 die jeweiligen Zertifikate zur Installation von dem Plug & Charge-Koordinator an. Diese werden dann an das Ladesteuergerät weitergegeben. Für die Kommunikation zwischen Benutzerschnittstellensteuergerät 720 und Ladesteuergerät 710 kann dabei beispielsweise eine Diagnose-Kommunikation und/oder eine Stauts/Konfigurations-Kommunikation verwendet werden.
In vielen Fällen wird der Fahrer die Auswahl eines Ladekontrakts über eine Benutzerschnittstelle des Fahrzeugs durchführen. Alternativ oder zusätzlich ist diese Auswahl auch über eine mobile Applikation des Fahrzeugherstellers möglich. Diese kann als Alternative zur Benutzerschnittsteller des Fahrzeugs genutzt werden, um die Konfiguration durchzuführen und um B enachri chtigungen b ereitzustell en .
Die Fign. 8a und 8b zeigen eine Menüführung innerhalb des Fahrzeugs. In Fig. 8a ist der Fall gezeigt, dass kein Plug & Charge unterstützt wird. In diesem Fall werden unter dem Punkt „Laden“ der Menüstruktur die Ladenkosten angezeigt. Dabei kann ein Kontrakt ausgewählt werden, um die Ladekosten zu schätzen. Dies entspricht beispielsweise dem Status Quo. In Fig. 8b ist der Fall gezeigt, dass Plug & Charge aktiviert ist. In diesem Fall wird unter dem Punkt „Laden“ der Menüstruktur der Punkt „Plug & Charge“ angezeigt, mit der Möglichkeit, einen Kontrakt für Plug & Charge auszuwählen. Dieser wird dann für das Laden des Fahrzeugs verwendet.
In der vorliegenden Erfindung tauschen das Ladegerät (d.h. das Ladesteuergerät) und das Benutzerschnittstellensteuergerät (Head Unit) grundsätzlich folgende Informationen aus. Das Ladesteuergerät stellt dem Benutzerschnittstellensteuergerät Metadaten der installierten Verträge und eine Information darüber, welcher Vertrag aktuell aktiv ist, bereit. Das Benutzerschnittstellensteuergerät stellt dem Ladesteuergerät Information darüber bereit, welcher Vertrag aktiviert werden soll. Nur der aktivierte Vertrag wird beim Anstecken an die Ladesäule zur Authentifizierung übermittelt. Die Auswahl des aktiven Vertrages kann durch verschiedene Mechanismen über die Benutzerschnittstelle / Benutzerschnittstellensteuergerät erfolgen. Dies kann beispielsweise manuell durch Nutzereingabe geschehen, wobei die Eingabe gespeichert bleibt. Beim Abstellen des Fahrzeugs an einer Plug & Charge Ladesäule kann der Nutzer von der Benutzeroberfläche auf die Möglichkeit einer Vertragsauswahl hingewiesen werden. Die Auswahl kann beispielsweise teilautomatisiert über vom Nutzer definierte Regeln erfolgen, etwa Standort-/GPS (Globales Positionierungs-System)-basiert oder abhängig vom Betreiber der Ladesäule, oder vollautomatisiert, etwa in dem das Benutzerschnittstellensteuergerät beim Abstellen des Fahrzeugs bereits über eine Datenbank ermittelt, welche Installierten Verträge mit der entsprechenden Ladesäule kompatibel sind (Roaming) oder welcher Vertrag der günstigste ist.
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. Schritte, 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 Magnetplatten und Magnetbänder, Festplattenlaufwerke 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), fei d -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 Schritte der oben beschriebenen Verfahren programmiert sind.
Es versteht sich ferner, dass die Offenbarung mehrerer, in der Beschreibung oder den Ansprüchen offenbarter Schritte, 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 Schritten oder Funktionen nicht auf eine bestimmte Reihenfolge begrenzt. Ferner kann bei weiteren Beispielen ein einzelner Schritt, 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ängi- gen Anspruch eingeschlossen sein, selbst wenn dieser Anspruch nicht direkt als abhängig von diesem anderen unabhängigen Anspruch definiert ist.

Claims

Patentansprüche
1. Ein Ladesteuergerät für ein Fahrzeug, das Ladesteuergerät umfassend: zumindest eine Schnittstelle zur Kommunikation mit einer Ladeinfrastruktur; ein kryptografisch gesichertes Element; und eine Steuerungsschaltung, ausgebildet zum:
Erhalten von mehreren kryptografisch gesicherten Ladekontrakten,
Speichern der mehreren Ladekontrakte in dem kryptografisch gesicherten Element, Speichern einer Auswahl eines Ladekontraktes der mehreren Ladekontrakte, und Authentifizieren des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt.
2. Das Ladesteuergerät gemäß Anspruch 1, wobei die zumindest eine Schnittstelle eine Schnittstelle zur Kommunikation mit einem Benutzerschnittstellensteuergerät des Fahrzeugs umfasst, wobei die Steuerungsschaltung ausgebildet ist zum Bestimmen von Metadaten über die mehreren kryptografisch gesicherten Ladekontrakte, und zum Bereitstellen der Metadaten für das Benutzerschnittstellensteuergerät des Fahrzeugs.
3. Das Ladesteuergerät gemäß Anspruch 2, wobei die Steuerungsschaltung ausgebildet ist zum Erhalten eines Steuersignals zur Auswahl eines Ladekontraktes von dem Benutzerschnittstellensteuergerät, und zum Speichern der Auswahl basierend auf dem Steuersignal.
4. Das Ladesteuergerät gemäß einem der Ansprüche 1 bis 3, wobei die zumindest eine Schnittstelle eine Schnittstelle zur Kommunikation mit einem Server umfasst, wobei die Steuerungsschaltung ausgebildet ist zum Erhalten der mehreren kryptografisch gesicherten Ladekontrakten von dem Server.
5. Das Ladesteuergerät gemäß einem der Ansprüche 1 bis 4, wobei die Ladekontrakte und eine Kommunikation mit der Ladeinfrastruktur auf dem Standard ISO 15118 basiert.
6. Ein Benutzerschnittstellensteuergerät für ein Fahrzeug, umfassend: zumindest eine Schnittstelle zur Kommunikation mit einem Ladesteuergerät des Fahrzeugs und zur Kommunikation mit einer Benutzerschnittstelle; eine Steuerungsschaltung, ausgebildet zum:
Erhalten von Metadaten über eine Mehrzahl von Ladekontrakten, die in einem kryptografisch gesicherten Element des Ladesteuergeräts gespeichert sind, von dem Ladesteuergerät;
Anzeigen der Mehrzahl von Ladekontrakte über die Benutzerschnittstelle;
Bereitstellen einer Auswahlfunktionalität zur Auswahl eines Ladekontrakts aus der Mehrzahl von Ladekontrakten über die Benutzerschnittstelle; und
Bereitstellen eines Steuersignals zur Auswahl eines Ladekontraktes für das Ladesteuergerät basierend auf der Auswahl des Ladekontrakts.
7. Das Benutzerschnittstellensteuergerät gemäß Anspruch 6, wobei die Steuerungsschaltung ausgebildet ist, das Anzeigen der Mehrzahl von Ladekontrakte zu aktivieren oder anzubieten, wenn sich das Fahrzeug an einer Ladeinfrastruktur befindet.
8. Das Benutzerschnittstellensteuergerät gemäß Anspruch 7, wobei die Steuerungsschaltung ausgebildet ist, abhängig von der Ladeinfrastruktur automatisch eine Vorauswahl eines Ladekontrakts durchzuführen und die Vorauswahl zusammen mit der Mehrzahl von Ladekontrakten anzuzeigen.
9. Ein Fahrzeug, umfassend das Ladesteuergerät gemäß einem der Ansprüche 1 bis 5 und das Benutzerschnittstellensteuergerät gemäß einem der Ansprüche 6 bis 8.
10. Ein Verfahren für ein Ladesteuergerät eines Fahrzeugs, das Verfahren umfassend: Erhalten von mehreren kryptografisch gesicherten Ladekontrakten;
Speichern der mehreren Ladekontrakte in einem kryptografisch gesicherten Element des Ladesteuergeräts;
Speichern einer Auswahl eines Ladekontraktes der mehreren Ladekontrakte; und Authentifizieren des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem ausgewählten Ladekontrakt.
11. Ein Verfahren für ein Benutzerschnittstellensteuergerät für ein Fahrzeug, umfassend: Erhalten von Metadaten über eine Mehrzahl von Ladekontrakten, die in einem kryptografisch gesicherten Element eines Ladesteuergeräts gespeichert sind, von dem Ladesteuergerät;
Anzeigen der Mehrzahl von Ladekontrakte über eine Benutzerschnittstelle; Bereitstellen einer Auswahlfunktionalität zur Auswahl eines Ladekontrakts aus der
Mehrzahl von Ladekontrakten über die Benutzerschnittstelle; und
Bereitstellen eines Steuersignals zur Auswahl eines Ladekontraktes für das Ladesteuergerät basierend auf der Auswahl des Ladekontrakts.
12. Programm mit einem Programmcode zum Durchführen des Verfahrens gemäß Anspruch 10 oder des Verfahrens von Anspruch 11, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird.
EP23789620.4A 2023-01-31 2023-10-11 Ladesteuergerät, benutzerschnittstellensteuergerät, fahrzeug und entsprechende verfahren und computerprogramme Pending EP4658528A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102023102287.3A DE102023102287A1 (de) 2023-01-31 2023-01-31 Ladesteuergerät, Benutzerschnittstellensteuergerät, Fahrzeug und entsprechende Verfahren und Computerprogramme
PCT/EP2023/078236 WO2024160395A1 (de) 2023-01-31 2023-10-11 Ladesteuergerät, benutzerschnittstellensteuergerät, fahrzeug und entsprechende verfahren und computerprogramme

Publications (1)

Publication Number Publication Date
EP4658528A1 true EP4658528A1 (de) 2025-12-10

Family

ID=88412122

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23789620.4A Pending EP4658528A1 (de) 2023-01-31 2023-10-11 Ladesteuergerät, benutzerschnittstellensteuergerät, fahrzeug und entsprechende verfahren und computerprogramme

Country Status (4)

Country Link
EP (1) EP4658528A1 (de)
CN (1) CN120603729A (de)
DE (1) DE102023102287A1 (de)
WO (1) WO2024160395A1 (de)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2704918A2 (de) * 2011-05-04 2014-03-12 ELMOS Semiconductor AG Verfahren zur erfassung eines von einer ersten einheit zu einer zweiten einheit transferierbaren, mengenmässig bestimmbaren mediums
DE102011101535A1 (de) * 2011-05-14 2012-02-02 Daimler Ag System und Verfahren zum Aufladen von Batterien von Fahrzeugen
DE102017008669A1 (de) * 2017-09-14 2018-06-07 Daimler Ag Verfahren zum Laden eines elektrochemischen Energiespeichers eines Fahrzeugs
DE102020205022B4 (de) * 2020-04-21 2024-01-04 Siemens Aktiengesellschaft Verfahren, Authentifikationsmittel und Autorisierungseinrichtung zur Autorisierung eines Ladevorgangs

Also Published As

Publication number Publication date
CN120603729A (zh) 2025-09-05
DE102023102287A1 (de) 2024-08-01
WO2024160395A1 (de) 2024-08-08

Similar Documents

Publication Publication Date Title
EP3807121B1 (de) Ladesystem zur dynamischen aufladung von elektrofahrzeugen
DE102013222428B4 (de) Berechtigungsnachweisprüfung und Autorisierungslösung zur Personenfahrzeugvermietung
DE102021100329A1 (de) Stellvertreterfahrzeug-ota-aktualisierung durch v2x
DE102020100593A1 (de) Fahrzeug-zu-fahrzeug-dateifreigabesystem und -verfahren
DE102017209716A1 (de) Verfahren zum Steuern eines Ladevorganges einer Energiespeichereinrichtung eines Kraftfahrzeugs, Steuereinrichtung, Lademanagementeinrichtung, Servervorrichtung, und Kraftfahrzeug
DE102019135012A1 (de) Auf richtlinie und token basierender autorisierungsrahmen für konnektivität
DE102017206106A1 (de) Steuerungsvorrichtung und Verfahren zur Steuerung einer Ladesäule
DE102019101110A1 (de) System und verfahren zum warten eines fahrzeugs
DE102014223663A1 (de) Verfahren zur Authentifizierung einer Berechtigung eines Benutzers eines Kraftfahrzeuges, Kraftfahrzeug und Computerprogramm
DE102020104551A1 (de) Sicherung und wiederherstellung einer fahrzeugsteuerungskonfiguration unter verwendung von datenschnappschüssen
DE102019122259A1 (de) Intelligente fahrzeugverbindung
WO2015062971A1 (de) Verfahren zur personenbezogenen nutzung eines kraftfahrzeuges
DE102013219545A1 (de) Verfahren, Fahrzeug und Anordnung
DE112013005761B4 (de) System und Verfahren zum Verwenden eines Autoradios zum Steuern der Lieferung von Premiuminhalt an ein Smartphone
DE102019115419A1 (de) Energieübertragungssysteme und -verfahren
EP3723322A2 (de) Verfahren zur authentifizierung eines fahrzeugs, authentifizierungseinheit, diensteinheit und fahrzeugexterne zentrale recheneinheit
DE102017119450A1 (de) Systeme und Verfahren zum Betanken eines Fahrzeugs mit einem Kraftstofflieferdienst
DE102023110395A1 (de) Neuverteilen des energieverbrauchs von elektrofahrzeugen
DE102022131693A1 (de) System und verfahren zum aufladen eines elektrofahrzeugs einschliesslich batterie
DE102021131515A1 (de) Verfahren, Fortbewegungsmittel, Server und Ladesäule zum Autorisieren eines Ladevorgangs
EP3355249B1 (de) Verfahren zum zuordnen eines fahrzeugs zu einem parkplatz, datenverarbeitungsanlage und fahrzeug
DE102021124838A1 (de) Ladestationsinformationssystem und Verfahren zum dynamischen Bereitstellen von Informationen über Ladestationen
EP4658528A1 (de) Ladesteuergerät, benutzerschnittstellensteuergerät, fahrzeug und entsprechende verfahren und computerprogramme
DE102016123395A1 (de) Verfahren und Vorrichtung für drahtlose Parkuhrzahlung
DE102017209069A1 (de) System und Verfahren zum Ermöglichen eines Ladevorgangs eines elektrischen Energiespeichers eines Kraftfahrzeugs an einer Ladesäule

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

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