CN116669985A - Method and apparatus for providing information about PNC-related service provider - Google Patents

Abstract

Methods and apparatus for providing information about a mobile solution provider or a mobile service provider supporting PnC are disclosed. The method comprises the following steps: receiving an authorization setup request message of a PnC from an Electric Vehicle Communication Controller (EVCC) installed in the EV; generating a list of service providers supporting PnC of a power supply device associated with the EV according to the authorization setup request message; transmitting an authorization setup response message including the service provider list to the EVCC; receiving an authorization request message including a contract certificate issued by a first service provider selected from a service provider list from the EVCC; and transmitting an authorization response message for notifying completion of authorization of the PnC supported by the first service provider to the EVCC based on the contract certificate.

Description

Method and apparatus for providing information about PNC-related service provider

Technical Field

The present disclosure relates to a method of providing service provider information, and more particularly, to a method and apparatus for providing information about a mobile operator or a mobile service provider supporting a plug-in charge/park charge (PnC) service.

Background

Electric Vehicles (EVs) are powered by electric machines with battery power and offer advantages such as reduced air pollutants, such as exhaust gas and noise, fewer malfunctions, longer life, and simplified operation compared to conventional gasoline engine vehicles.

EVs may be classified into Hybrid Electric Vehicles (HEVs), plug-in hybrid electric vehicles (PHEVs), and Electric Vehicles (EVs) based on their power source or propulsion system. HEVs have an engine for primary power and an electric machine for auxiliary power, and PHEVs have an electric machine for primary power and an engine for use when the battery is discharged. On the other hand, EVs are powered only by electric machines and do not have an engine.

An EV charging system may be basically defined as a system that charges a battery installed in an EV using electric power from a commercial electric grid or an energy storage device. The EV charging system may have various forms according to the type of EV. For example, an EV charging system may operate as a conductive charging system including an EV and an EV power supply equipment (EVSE) and using a cable or contactless Wireless Power Transfer (WPT) system. The EVSE may be referred to simply as a "power supply device (SE)".

Some EVSE may start charging after passing a predetermined authorization process for the EV, and such authorization process differs according to the charging infrastructure (briefly, "infrastructure") and the function of the EV. Two representative authorization schemes for EV charging may include: a plug-in charge/park charge (PnC) scheme in which authorization and payment are automatically completed using contract credentials stored in the EV; and schemes in which identification, authorization, and payment are performed using External Identification Means (EIM) such as credit or debit cards, cash, smart phones, web applications, NFC, RFID, phone calls, and the like.

That is, the PnC scheme is an automatic authorization scheme that authorizes the EV charging user using a certificate without any interaction from the user.

Such a PnC scheme is generally classified into a wired charging scheme and a wireless charging scheme. The wired charging scheme refers to a plug and charging scheme that performs service authorization and charging by simply inserting a plug between the EV and the charging station, and the wireless charging scheme refers to a PnC scheme that performs service authorization and charging by simply parking the EV on a charging point of the charging station. When using the PnC scheme, all processes of EV user authentication, charging, and billing are automatically handled when charging the EV.

Meanwhile, an owner of the EV may contract for service usage related to PnC with a Charge Point Operator (CPO), a Mobile Operator (MO), or a mobile service provider (eMSP), install a contract certificate in the EV at the time of initial charging, and then receive the PnC service at a charging station associated with the corresponding CPO, MO, or eMSP.

According to the related art, in order to receive the PnC service, the EV should transmit a contract certificate for authorization to the power Supply Equipment (SE). In this case, the EV may hold different contract credentials for different MOs. During authorization, the EV may not have information about CPOs, MOs, or emsps supported by the corresponding charging stations. Thus, if the EV transmits a contract certificate issued by a CPO, MO or eMSP that is not supported by the charger, the EV should terminate the session and restart the session with another contract certificate.

As described above, in order to make the PnC authorization step efficient and reliable, a method for enabling the EV to know in advance the SE or the MO to which the charger of the SE can authorize is required.

Further, in the case of PnC, an EV may hold a plurality of contract certificates. In this case, when transmitting the authorization request message of PnC, the EV should select one contract certificate from the plurality of contract certificates and transmit it to the SE. If CPO, MO or eMSP does not support SE as provider of contract credentials, then EV should select another contract credential and repeatedly attempt PnC authorization. That is, the EV should repeat the authorization request process until it selects the contract certificate issued by the corresponding CPO, MO, or eMSP, or until it transmits all the contract certificates it owns. This trial-and-error problem is very inefficient in PnC grants.

Disclosure of Invention

[ problem ]

The present invention has been made in view of the above-mentioned needs of the prior art, and an object of the present invention is to provide a method and apparatus for providing PnC related service provider information, for a power Supply Equipment Communication Controller (SECC) to provide information of a mobile operator or a mobile service provider (e.g., mobile service provider (eMSP)) supporting PnC service to an EV communication controller (EVCC).

Another object of the present invention is to provide a method and apparatus for providing PnC service provider information, which can improve reliability and stability of a PnC process by improving the PnC process.

[ technical solution ]

According to an aspect of the present disclosure, a method for PnC-related service provider information, which is performed by a power Supply Equipment Communication Controller (SECC) of a power Supply Equipment (SE) supplying electric power to an Electric Vehicle (EV), for solving the above-described technical problems, may include: receiving an authorization setup request message of a PnC from an EV communication controller (EVCC) installed in the EV; generating a service provider list supporting service providers for PnC of SE associated with EV according to the authorization setup request message; transmitting an authorization setup response message including the service provider list to the EVCC; receiving an authorization request message including service provider information and a contract certificate corresponding to a first service provider selected from a service provider list from the EVCC; and transmitting an authorization response message indicating completion of authorization of the PnC supported by the first service provider to the EVCC based on the service provider information and the contract certificate.

The authorization setup response message may include a PnC authorization setup response identification mode (pncasresidentification mode) parameter having a supported service provider list and an element generating a challenge (GenChallenge).

The supported service provider list may be a list of service providers supporting pncs of SE associated with the EV and may include information or identifiers of mobile operators in contractual relationships supporting pncs for battery charging of the EV.

The supported service provider list (SupportedProviderList) may be a list of service providers supporting pncs of SE associated with the EV, and may include a roaming platform of the mobile operator in a contractual relationship supporting pncs for battery charging of the EV.

The authorization setup response message may further include a response code parameter set to "OK" and an authorization service parameter set to "PnC".

The authorization setup response message may also include a certificate installation service parameter set to "true" or "false".

The method may further comprise: the EVCC is allowed to select one Mobile Operator (MO) from the service provider list based on the service provider list included in the authorization setup response message.

The method may further comprise: the EVCC is allowed to generate an authorization request message including service provider information of the first MO selected from the service provider list and a contract certificate issued by the first MO.

The method may further comprise: allowing the EVCC to release a state associated with the SE based on the service provider list included in the authorization setup response message; or allow the EVCC to output a signal for moving the EV out of the parking area of the SE.

The method may further comprise: allowing the EVCC to select a roaming platform or a roaming service included in the service provider list based on the service provider list; and allowing the EVCC to generate an authorization request message including service provider information set as a roaming platform or a roaming service and a contract certificate issued by the roaming platform or the roaming platform providing the roaming service.

The authorization request message may include a selected authorization service parameter set to "PnC", and may include a generation challenge element and a contract certificate chain element within a PnC request identification mode or PnC request authorization mode parameter, and set the contract certificate chain element as a roaming platform.

According to another aspect of the present disclosure, a method for providing PnC-related service provider information for solving the above-described technical problems performed by an Electric Vehicle Communication Controller (EVCC) of an Electric Vehicle (EV), may include: transmitting an authorization setup request message of the PnC to a power Supply Equipment Communication Controller (SECC) of a power Supply Equipment (SE) supplying power to the EV; receiving an authorization setup response message from the SECC, the authorization setup response message including a service provider list of service providers supporting PnC of SE associated with EV; transmitting an authorization request message including service provider information and a contract certificate corresponding to a first service provider selected from the service provider list to the SECC; and receiving an authorization response message from the SECC indicating completion of authorization of the PnC supported by the first service provider.

The authorization setup response message may include a PnC authorization setup response identification mode (pncasresidentification mode) parameter having a supported service provider list and an element generating a challenge (GenChallenge).

The supported service provider list may be a list of service providers supporting pncs of SE associated with the EV and may include information or identifiers of mobile operators in contractual relationships supporting pncs for battery charging of the EV.

The supported service provider list (SupportedProviderList) may be a list of service providers supporting pncs of SE associated with the EV, and may include a roaming platform through one of the mobile operators in a contractual relationship supporting pncs for battery charging of the EV.

The authorization setup response message may further include a response code parameter set to "OK" and an authorization service parameter set to "PnC".

The authorization setup response message may also include a certificate installation service parameter set to "true" or "false".

The method may further comprise: a Mobile Operator (MO) is selected from the list of service providers based on the list of service providers included in the authorization setup response message.

The method may further comprise: an authorization request message is generated that includes service provider information of the first MO selected from the service provider list and a contract certificate issued by the first MO.

The method may further comprise: releasing the state associated with the SE based on the list of service providers included in the authorization setup response message; or outputs a signal for moving the EV out of the parking area of the SE.

The method may further comprise: selecting a roaming platform or a roaming service included in the service provider list based on the service provider list; and generating an authorization request message including service provider information set as the roaming platform or the roaming service, and a contract certificate issued by the roaming platform or the roaming platform providing the roaming service.

According to still another aspect of the present disclosure, an apparatus for providing PnC-related service provider information, which is an apparatus for providing PnC-related service provider information, includes a power Supply Equipment Communication Controller (SECC) of a power Supply Equipment (SE) supplying power to an Electric Vehicle (EV), may include a processor and a memory storing instructions executable by the processor. When executed by a processor, the instructions are configured to perform: receiving an authorization setup request message of a PnC from an EV communication controller (EVCC) installed in the EV; generating a service provider list supporting service providers of PnC for SE associated with EV according to the authorization setup request message; transmitting an authorization setup response message including the service provider list to the EVCC; receiving an authorization request message including service provider information and a contract certificate corresponding to a first service provider selected from a service provider list from the EVCC; and transmitting an authorization response message indicating completion of authorization of the PnC supported by the first service provider to the EVCC based on the service provider information and the contract certificate.

According to still another aspect of the present disclosure, an apparatus for providing PnC-related service provider information for solving the above-described technical problems, as a PnC-related service provider information providing apparatus including an Electric Vehicle Communication Controller (EVCC) of an Electric Vehicle (EV), may include a processor and a memory storing instructions executable by the processor. When executed by a processor, the instructions are configured to perform: transmitting an authorization setup request message of the PnC to a power Supply Equipment Communication Controller (SECC) of a power Supply Equipment (SE) supplying power to the EV; receiving an authorization setup response message from the SECC, the authorization setup response message including a service provider list of service providers supporting PnC of SE associated with EV; transmitting an authorization request message including service provider information and a contract certificate corresponding to a first service provider selected from the service provider list to the SECC; and receiving an authorization response message from the SECC indicating completion of authorization of the PnC supported by the first service provider.

[ beneficial effects ]

According to the present disclosure, the SECC may provide the EVCC with information about the MO of the charging station or the eMSP supporting the PnC service so that the EV can know in advance that the MO can be authorized by the charger and deliver the contract certificate supported by the MO to the charger. Thus, the authorization in the PnC process can be handled correctly and quickly.

Further, according to the present disclosure, when the EV has a plurality of contract certificates, the EV may receive information on a service provider capable of supporting a charging station or a charger from the SE at the beginning of the PnC process. Thus, when the EV selects a contract certificate to be transmitted through the authority request message of the PnC, the EV can properly select the contract certificate using the SE-supporting CPO, MO or eMSP and provide the selected contract certificate to the SECC, thereby eliminating a trial-and-error (real-and-error) problem in advance.

Further, according to the present disclosure, the reliability and stability of the PnC process can be improved by improving the PnC process for EV charging.

Drawings

Fig. 1 is a conceptual diagram illustrating an overall configuration of a PnC-related service provider information providing system according to an exemplary embodiment of the present disclosure.

FIG. 2 is an exemplary diagram illustrating a PnC architecture to which a PnC-related service provider information providing method according to an exemplary embodiment of the present disclosure is applicable.

FIG. 3 is an exemplary diagram for describing PKI that may be used in the PnC architecture of FIG. 2.

Fig. 4 is a block diagram illustrating message ordering for V2G communication states to describe a PnC-related service provider information providing method according to an exemplary embodiment of the present disclosure.

Fig. 5 is an exemplary diagram for describing a certificate installation method that may be combined with a PnC-related service provider information providing method according to an exemplary embodiment of the present disclosure.

Fig. 6 is a diagram for describing a main procedure of a PnC-related service provider information providing method according to an exemplary embodiment of the present invention.

FIGS. 7a and 7b are scheme diagrams of some configurations of an authorization setup response message that may be used in the PnC-related service provider information providing method of FIG. 6.

Fig. 8 is a diagram for describing a main procedure of a PnC related service provider information providing method according to another exemplary embodiment of the present disclosure.

FIG. 9 is a schematic block diagram of a PnC-related service provider information providing apparatus according to another exemplary embodiment of the present disclosure.

Detailed Description

As the present disclosure is susceptible to various modifications and alternative forms, specific exemplary embodiments have been shown in the drawings and will be described in detail herein. It should be understood, however, that there is no intent to limit the disclosure to the particular exemplary embodiments, but rather, the disclosure is to cover all modifications and alternatives falling within the spirit and scope of the disclosure.

Relational terms such as first, second, and the like may be used to describe various elements, but the elements should not be limited by the terms. These terms are only used to distinguish one element from another element. For example, a first component could be termed a second component, and a second component could be similarly named a first component, without departing from the scope of the present disclosure. The term "and/or" refers to any one or combination of a plurality of related and described items.

When referring to a certain component "coupled" or "connected" to another component, it is to be understood that the certain component is directly "coupled" or "connected" to the other component, or that another component may be disposed therebetween. Conversely, when a component is referred to as being "directly coupled" or "directly connected" to another component, it should be understood that the other component is not disposed therebetween.

The terminology used in the present disclosure is for the purpose of describing particular example embodiments only and is not intended to be limiting of the disclosure. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this disclosure, terms such as "comprises" or "comprising" are intended to specify the presence of stated features, amounts, steps, operations, components, parts, or combinations thereof, but it is to be understood that the terms do not preclude the presence or addition of one or more other features, amounts, steps, operations, components, parts, or combinations thereof.

Unless defined otherwise, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. Terms that are commonly used and already in a dictionary should be interpreted as having meanings that match the contextual meaning in the art. In this specification, unless explicitly defined, terms are not necessarily to be construed as having formal meanings.

Additional terms used in this disclosure are defined as follows.

"Electric Vehicle (EV)" may refer to an automobile defined in code 49 of federal regulation (CFR) 523.3, etc. EVs may be used on highways and driven by electricity supplied from an on-board energy storage device, such as a battery rechargeable from a power source external to the vehicle. The power supply may include a residential, public electricity service, or a generator using on-board fuel. The EVs may be referred to as electric vehicles, electric Road Vehicles (ERVs), plug-in vehicles (PV), plug-in vehicles (xevs), etc., and the xevs may be referred to as or categorized as plug-in all-electric vehicles or Battery Electric Vehicles (BEV), plug-in electric vehicles (PEV), hybrid Electric Vehicles (HEV), hybrid plug-in electric vehicles (HPEV), plug-in hybrid electric vehicles (PHEV), etc.

"plug-in electric vehicle (PEV)" may refer to an EV that charges an on-board main battery by being connected to an electric grid.

"Wireless power charging System (WCS)" may refer to a system for wireless power transfer, alignment and communication between a ground-based transmitting board (GA) and an on-board receiving board (VA).

"Wireless Power Transfer (WPT)" may refer to a technology of transmitting or receiving electric power to or from an EV by a non-contact manner such as electromagnetic induction and resonance from a power source such as a utility, a power grid, an energy storage device, and a fuel cell generator.

"public facilities (availability)": a set of systems that supply electrical energy and may include Customer Information Systems (CIS), advanced Metering Infrastructure (AMI), tariffs and revenue systems, and the like. The utility may provide energy to the EV based on the tariff table and the discrete events. In addition, the utility may provide information regarding authentication of the EV, intervals of power consumption measurements, and billing.

"Intelligent charging": a system in which EVSE and/or PEV communicate with the grid to optimize the charge or discharge ratio of the EV by reflecting grid capacity or usage fees.

"interoperability": a state in which a component of a system interacts with a corresponding component of the system to perform operations aimed at by the system. Further, information interoperability may refer to the ability of two or more networks, systems, devices, applications, or components to effectively share and easily use information without inconveniencing a user.

"inductive charging System": a system transfers energy from a power source to an EV via a two-part gapped core transformer in which two halves of the transformer (i.e., primary and secondary coils) are physically separated from each other. In the present disclosure, the inductive charging system may correspond to an EV power transmission system.

"inductive coupling": magnetic coupling between the two coils. In the present disclosure, coupling is between the GA coil and the VA coil.

"Original Equipment Manufacturer (OEM)": EV manufacturer or server operated by EV manufacturer. It may include a root Certificate Authority (CA) or root certificate server that issues OEM root certificates.

"grid operator (V2G operator)": the primary actor engages in V2G communications using a transport protocol or an entity for initiating a blockchain for automatic authentication of EVs or EV users, creating a smart contract on the blockchain. Which may include at least one trusted authority or trusted authentication server.

"Mobile Operator (MO)": one of the entities within the PnC architecture has a contractual relationship with the owner of the EV regarding charging, approval and payment to enable the EV driver to charge the EV battery at the charging station. It may include at least one authentication authority or authentication server that issues and manages its own certificates. The billing service operator may be referred to as a mobile operator.

"Charging Service Provider (CSP)": an entity responsible for managing and authenticating credentials of EV users and performing the role of providing billing and other value added services to customers. May correspond to a particular type of MO and may be implemented in combination with the MO.

"Charging Station (CS)": a facility or apparatus having one or more EV power supply devices and actually performing charging of an EV.

"Charging Station Operator (CSO)": an entity connected to the grid and managing power to supply the EV-requested power. It may be a term having the same concept as a Charge Point Operator (CPO) or an e-mobile service provider (eMSP), or it may be a term included in or including a concept of a CPO or eMSP. The CSO, CPO, or eMSP may include at least one certificate authority that issues or manages its own certificates.

"e-mobile authentication identifier (eMAID)": the contract certificate is linked to a unique identifier of a payment account of an electric vehicle owner using the electric power. In an exemplary embodiment, the mobile authentication identifier may include an identifier of the EV certificate or an identifier of the provisioning certificate (provisioning certificate). The term eMAID may be replaced with reference to an "e-mobile account identifier" or may be replaced with a contract ID.

"Clearing House (CH)": an entity that handles collaboration matters between MO, CSP, and CSO. It may act as an intermediary to the approval, billing and adjustment process of EV charging services that facilitate roaming between the two parties.

"roaming": information exchange and schemes and provisions between CSPs that allow EV users to access billing services provided by multiple CSPs or CSOs involving multiple e-mobile networks by using a single credential and contract.

"voucher": a physical or digital asset representing the identity of the EV or owner of the EV, and may include a password for verifying the identity, a public and private key pair used in a public key encryption algorithm, a public key certificate issued by a certification authority, information related to a trusted root certification authority.

"certificate": the public key is bound to the electronic document of the ID by digital signature.

"service session": a set of services surrounding a charging point related to charging of an EV assigned to a particular customer with a unique identifier within a particular time frame.

Hereinafter, exemplary embodiments of the present disclosure will be explained in detail with reference to the accompanying drawings.

A method for providing information of a mobile operator or a mobile service provider supporting a PnC service, which will be described in the present exemplary embodiment, is characterized in that the SECC provides information on service providers supporting the PnC service, such as CPO, MO, and eMSP, to the EVCC.

Fig. 1 is a conceptual diagram illustrating an overall configuration of a PnC-related service provider information providing system according to an exemplary embodiment of the present disclosure.

As shown in fig. 1, the SECC of the charging station interworking with at least one of the MO and the CPO may be a type of PnC-related service provider information providing device, and may perform a PnC authorization process of the EV in a state in which the EVCC intended to charge the battery has established a communication channel with a specific EVSE.

For PnC authorization, a user of an EV (i.e., EV user) may first contract a charging with a Provisioning Certificate Identification (PCID) to join an MO, and then transmit a contract certificate to a service provider of a Certificate Provisioning Service (CPS) using contract data generated when joining the MO.

The PCID may be an authentication identifier of the EV certificate. Further, the contract data or contract-related information may include an account identifier corresponding to the PCID, and a validity period and an activity status of the account identifier. The account identifier may be an identifier of the EV user, and the active state may have a value corresponding to "true" when the account identifier is valid, and otherwise the active state may have a value corresponding to "false".

Further, the SECC controlling the EVSE may receive a message requesting payment details related to payment of EV charging from the EVCC, and transmit a response message corresponding to the request message to the EVCC. The response message may include information regarding payment details.

Further, the SECC may receive an authorization request message related to authentication of the EV user from the EVCC, transmit the authorization request message to the CPO, the CPS, etc. to obtain a check result of authorization and revocation associated with a valid account identifier corresponding to the authentication identifier, and transmit a response message regarding PnC authorization to the EVCC based on the check result.

In the case of conductive power transmission, the EVSE described above may include conductors for the respective phases, neutral and protective ground conductors, EV couplers to which plugs are attached, etc., may include other accessories, devices, power outlets, or devices that are mounted to transmit energy to the EV through a wire harness, and may be mounted to enable communication therebetween. In the case of WPT, the EVSE described above may include an SECC and an off-board device including one or more power devices operating under the control of the SECC. In the following description, the EVSE described above may also be simply referred to as a power supply apparatus (SE).

Meanwhile, an authentication process for EV charging will be described below with reference to portions of fig. 2 and 3.

First, when the EV desires to charge the vehicle battery at the EV charging station by autonomous driving or according to an input signal of the driver, the EV may use a manual scheme of an external identification device (EIM) (using a credit card such as an EV user, cash, a membership card, etc.), or transmit a first message to an SECC of the EVSE (hereinafter, simply referred to as a "charger") in order to use an automatic authorization and payment scheme (i.e., plug-in charging/parking charging (PnC)).

The first message may include an authorization setup request message. The grant set-up request message may be a null message.

The EVCC having transmitted the authorization setup request message may receive an authorization setup response message from the SECC, the authorization setup response message including a service provider list of at least one or more service providers for supporting the PnC service of the SE associated with the EV.

The EVCC may then send an authorization request message or a second message to the SECC that includes information or an identifier of one mobile operator selected from the service provider list and a contract certificate issued by the selected mobile operator.

When the eMAID and the contract certificate are transmitted to the charger through the second message, the SECC may transmit a response message including an authorization or revocation confirmation result of the PnC to the EVCC based on the corresponding information.

Then, the EVCC may transmit a message including a parameter (PaymentServiceSelection) for payment service selection to the SECC, or may transmit a payment detail request message (paymentdetails req) requesting information about payment details to the SECC.

More specifically, the contract certificate may be a certificate issued by a subordinate authentication authority (Sub-CA) of a mobile service provider (eMSP) for the EVCC, may be provided to the EV through a SECC and/or a Secondary Actor (SA), and may be used for extensible markup language (XML) signature on the application layer to verify a signature generated by the EVCC.

The secondary actor may use eMAID (which is part of the main field of the contract certificate) to authorize the EV to charge through the Certificate Provisioning Service (CPS) based on a mobile contract linked to the charging service provider. The SA may include CPOs and MOs, or may also include a value added network operator providing a value added network. The SECC may send a Paymentdetails response message (Paymentdetails Res) in response to the Paymentdetails request message to the EVCC of the EV according to the acknowledgement result of the SA.

When the signature generated by the EVCC is not problematic, the SA or the SECC may transmit a challenge text regarding the permission of the charging attempt to the EVCC through a predetermined message. The EVCC may sign the challenge text and send a message including the signed challenge text to the EVSE to continue authorization of the charging process. The message may include an authorization request (authenticationreq) message requesting authorization or approval of the charging. The SECC controlling the EVSE associated with the EV may receive the authorization request message and verify the signature of the EV included in the authorization request message to authenticate the user.

Through the above-described PnC process, the EVCC may prepare for a charging process, connect to a charging device such as an EVSE of a Charging Station (CS) through a wired link or a wireless link, receive electric energy under a charging authorization, and charge a vehicle battery.

The above-described PnC process may be performed through a secure session. In this case, since messages should be transmitted and received based on the certificates of the respective entities, a back-end system for issuing, managing, and updating the certificates of the respective entities may be required.

FIG. 2 is an exemplary diagram illustrating a PnC architecture to which a PnC-related service provider information providing method according to an exemplary embodiment of the present invention is applicable.

As shown in fig. 2, the PnC architecture is used for EV charging services and may include PnC architecture component systems such as OEM, MO or CSP, CPO or CSO, and V2G operators, and may include CPS and Contract Certificate Pools (CCPs) provided by them.

An EV refers to an EV owned by an EV user, and a battery installed in the EV may be charged at a charging station or power may be supplied from the battery to a power grid in a wired or wireless manner. OEM-provided certificates may be installed in EVs during manufacture. The contract certificate may be installed in the EV when the vehicle purchases the contract and the contract with the MO is made. In addition, V2G root certificates of V2G operators may be installed in EVs.

The OEM may include a root certificate authority (root CA) that issues OEM root certificates and operates and maintains its subordinate certificate authorities (OEM Sub-CAs). When manufacturing the EV, the OEM may use the OEM mid-chain certificate (i.e., OEM Sub-CA certificate) to generate an OEM-provided certificate, and install the OEM-provided certificate in the EV through an OEM Registry (RA).

Root CA, child CA, and OEM certificate pool (i.e., cert. Pool). The OEM's RA may connect with the MO's RA (i.e., MO RA), prove the identity of the MO RA or its server, and issue certificates for it.

The MO or CSP is an entity that has a contractual relationship with the EV user for charging, authorizing, and paying so that the EV user can charge the EV battery at a charging station. In order for the EV to receive charging services from the current charging station, the current charging station should belong to a pre-registered MO or support roaming scenarios.

The MO may include a MO root CA that issues MO root certificates and operates and maintains its subordinate authentication authority (i.e., MO Sub-CA). In generating the contract certificate, an MO certificate chain composed of an MO root certificate and an MO intermediate chain certificate issued by its subordinate certification authority is used. Furthermore, MO certificate chains may also be used to verify contract certificates installed in EVs in non-roaming or roaming environments.

The authentication server of the root CA and the subordinate CA of the MO may be connected to a Charging Station Management System (CSMS) of the CPO or the CSO, and may verify the identity of the CSMS and issue a certificate according to the verification result.

In addition, the CSP may authenticate EV users, manage certificate issuance (credentials), and provide charging and other value-added network related services for EV users. CSP may be considered to correspond to a particular type of MO and may be implemented in combination with the MO.

There may be multiple CSPs, each CSP may be associated with one or more CSOs, and the CSPs and one or more CSOs may constitute a charging network. The EV may receive the charging service in the PnC scheme from the CSP or the CSO associated with the MO having the contractual relationship. Roaming is required when it is desired to use a charging service through another CSO without a contractual relationship with the EV or without being associated with an MO having a contractual relationship with the EV. Each CSP may exchange information with other CSPs or CSOs in other networks for roaming, and may also exchange information with a Clearing House (CH).

In installing or updating the contract certificate in the EV, the CPS may provide an encryption key for transmitting and receiving the certificate to the EV client or the MO RA together with the contract authentication chain through the CPS server. The CPS server may operate and maintain a CPS lower level certification authority (Sub-CA) and may be connected to the root CA of the V2G operator through CPS Sub-CA.

The CPS may be equipped with a leaf provisioning certificate (leaf provisioning certificate) and a provisioning mid-chain certificate (i.e., prov Sub-CAcert.). When installing or updating the contract certificate in the EV, the CPS may provide a provisioning service that shares the public key of each MO, diffie Hellman (DH) public key, and eMAID with the contract certificate chain so that the EV can use them to verify the contract certificate chain and verify the integrity and authenticity of the contract certificate.

The CCP may temporarily store a response message for installation or update during a process of installing or updating the contract certificate in the EV. Assuming that the install and update timeouts are very short and strict, the response messages may be pre-stored in the CCP and maintained until the install or update is complete. Since there may be several EVs that install or update the contract certificate, the response message may be maintained in the form of a directory after the reference number is added.

CCP may include a CCP server connected to the CSMS and manage and maintain databases managed by the CCP server and store contract certificates, PCIDs, certificate Identity Registrations (CIRs), and the like.

The V2G operator acts as a root CA related to Public Key Infrastructure (PKI) in the PnC architecture. Thus, the V2G root CA acts as a root trust anchor (trust anchor), and all entities or actors shown in fig. 3 treat the V2G root CA as trusted servers. The V2G root CA may be connected to the CPS sub CA and to the CPO sub CA. The V2G operator may provide directory services to the CSMS.

The CSO or CPO may operate the charging station and manage power to provide the requested charging service. For example, the CSO may be operated by a charging station manufacturer, an EVSE manufacturer, or an electric power provider.

Regarding PKI, the CSO or CPO may operate the CPO sub-CA required to generate the SECC leaf certificates for each charging station. CPO sub-CA can connect to CSMS through CPO RA and handle registration and authentication of CSMS.

The Charging Station (CS) refers to a place where charging is performed on the EV or includes a charging facility installed therein. The CS may have at least one conductive charger and/or wireless charging point. One or more charging stations may be installed in a commercial specific charging facility. Further, the charging station may be located in a different place (such as a parking lot attached to a house of an EV user, a parking area for EV charging at a gas station, a parking area at a shopping mall or workplace, and the like). The charging station may be referred to as a "charging point", "EV charging station", "EV point", and the like.

The Clearinghouse (CH) can handle collaboration events between the MO and CSP. The CH may act as an intermediary for the authorization, charging and settlement processes of EV charging services that facilitate roaming between two settlers or parties. When an EV user wants to charge an EV at a charging station that does not belong to an MO network having a contractual relationship with the EV, the CH may support a roaming service by connecting to the CSO or CSP.

In case roaming is required. The CH may enable the CSO or CSP to sign up with the MO and pass authorization and Charging Detail Records (CDRs) to the MO. CH may be referred to as "Contract Clearing House (CCH)", "Mobile Clearing House (MCH)", "roaming platform", "electronic Mobile clearing house (e-MOCH)", etc.

While the CSO, CPS, MO, CCH and V2G operators described above may be considered to refer to individuals or personal organizations, they may refer to devices or components implemented in hardware, software, and/or combinations thereof throughout the disclosure and claims, and may be functionally given a shorthand designation for readability.

In addition, each of the above components may be a server device implemented as hardware, software, or a combination thereof, and allowing access to other devices through a network such as the internet. Since these components are functionally separated, two or more of them may be installed and executed in one physical device, and may be integrated into one program. In particular, a single entity may act as both CSO and CSP, and another single entity may act as both CPS and CCP. One or more of the above components may be rearranged to have different appearances and names.

Furthermore, CSOs have in common with CPOs in terms of roles and functions, and although they have differences in some functions and nuances, they actually refer to the same entity. Furthermore, CSP has in common with MO in terms of role and function, and CSP and MO may be terms used interchangeably.

FIG. 3 is an exemplary diagram for describing PKI that may be used in the PnC architecture of FIG. 2.

As shown in FIG. 3, the PKI required to operate PnC may provide a framework for verifying the identity of an individual or device, enabling confidential communications, and ensuring controlled access to resources.

Specifically, an EV manufacturer, which is an OEM for EVs, may act as an OEM root CA that issues OEM root CA certificates, and operate OEM sub CA1 and OEM sub CA2.EV manufacturers (hereinafter, referred to as "OEMs") generate OEM Root certificates (OEM Root certificates), and OEM intermediate chain certificates (OEM Sub-CA1 certificates, OEM Sub-CA2 certificates) by signing them with their own private keys.

During manufacture of the EV, a secondary subordinate certification authority (i.e., OEM Sub-CA 2) that is the last certification authority in the intermediate chain of the OEM may use a private key paired with a public key included in the OEM secondary intermediate chain certificate (OEM Sub-CA2 certificate) to generate an OEM provisioning certificate (i.e., OEM pro cert.) and install it in the EV. An OEM provided certificate (OEM pro cert) may be used to verify the signature of the request message during the certificate installation request process for the EV, thereby uniquely identifying the EV throughout its lifecycle.

The MO may act as a Root authentication authority (i.e., MO Root CA) that issues MO Root CA certificates (i.e., MO Root CA). The MO may generate a master mid-chain certificate (i.e., MO Sub-CA1 cert) by adding its own signature to the Identifier (ID) and public key of the master lower authentication authority (i.e., MO Sub-CA 1). The MO primary subordinate authentication authority (i.e., MO Sub-CA 1) may add its signature to the ID and the public key of the secondary subordinate authentication authority (i.e., MO Sub-CA 2) to generate a secondary mid-chain certificate (i.e., MO Sub-CA2 cert).

When the EV is shipped, based on a contract made between the MO and the owner of the EV, a secondary subordinate certification authority of the MO (i.e., MO Sub-CA 2) may generate a contract certificate by using a private key paired with a public key included in a secondary mid-chain certificate of the MO (i.e., MO Sub-CA2 cert), and install the contract certificate in the EV through, for example, a charging station operator that the EV initially accesses. The contract certificate is linked to the payment account of the owner of the EV by a unique identifier called e-mobile authentication identifier (eMAID).

OEM provisioning certificates (i.e., OEM provcert) and contractual certificates may be generated based on Root certificates generated by the OEM and MO itself (e.g., OEM Root CA cert. And MO Root CA cert), respectively, may be generated based on V2G Root certificates or global Root certificates (i.e., V2G Root cert) of V2G Root servers of distribution network operators (hereinafter simply referred to as "global Root servers"), and may be independent of certificates used by other actors.

Meanwhile, the global Root server corresponding to the V2G Root certificate authority may issue OEM provisioning certificates (i.e., OEM pro cert) and contract certificates (see dotted arrow in fig. 3) using V2G Root certificates (i.e., V2G Root CA cert) instead of OEM and MO Root certificates (i.e., OEM Root cap).

Furthermore, the global root server may generate at least two certificate families, i.e. a certificate family for CPOs and charging stations, and a certificate family for providing services.

Specifically, the global root server may add its own signature to the public key of the main subordinate certification authority of the ID and CPO (i.e., CPO Sub-CA 1) to issue a main mid-chain certificate (i.e., CPO Sub-CA1 cert). The primary subordinate certification authority of the CPO (i.e., CPO Sub-CA 1) may add its own signature to the ID and the public key of the secondary subordinate certification authority of the CPO (i.e., CPO Sub-CA 2) to issue a secondary mid-chain certificate (i.e., CPO Sub-CA2 cert).

The secondary subordinate certification authority of the CPO (i.e., CPO Sub-CA 2) may issue the SECC leaf certificate or EVSE leaf certificate using a private key paired with a public key included in the secondary mid-chain certificate of the CPO (i.e., CPO Sub-CA2 cert). That is, the CPO's secondary subordinate certification authority (i.e., CPO Sub-CA 2) may add its own digital signature to the ID and public key of the EVSE received from the EVSE to issue an EVSE leaf certificate or a SECC leaf certificate.

The EVSE leaf certificate may be used by the EV during TLS communication setup to verify whether the EV is communicating with a legitimate charging station and not with a malicious charging station. The certificate may be issued not only to the Charging Station (CS) but also to the backend server of the CSO.

The global root server may add its own signature to the ID and public key of the configuration primary subordinate authentication authority (i.e., prov Sub-CA 1) within the CPO to issue a primary mid-chain certificate (i.e., prov Sub-CA1 cert). Providing a primary subordinate authentication authority (i.e., prov Sub-CA 1) may add its own signature to the ID and public key of the providing secondary subordinate authentication authority (i.e., prov Sub-CA 2) to issue a secondary intermediate chain certificate (i.e., prov Sub-CA2 cert).

The providing secondary intermediate certificate authority (i.e., CPO Sub-CA 2) may issue a leaf provisioning certificate using a private key paired with a public key included in the providing secondary intermediate chain certificate (i.e., pro Sub-CA2 cert) and send it to a Certificate Provisioning Service (CPS) to install it.

Meanwhile, each Root certificate authority (i.e., V2G Root CA, MO Root CA, OEM Root CA) may issue and provide OCSP certificates. In this case, the client may access an OCSP server according to an Online Certificate Status Protocol (OCSP), request revocation/non-revocation status information regarding validity of a certificate, and receive a query result.

In FIG. 3, for simplicity, OCSP certificates are shown as being available only to CPO subordinate certification authorities (i.e., CPO Sub-CA1 and CPO Sub-CA 2), but all Root certification authorities (i.e., V2G RootCA, MO RootCA, OEM RootCA) are able to issue and use OCSP certificates so that the validity of certificates in its own Root certificate family can be queried. In addition, a PE private root of a Private Environment (PE) may install PE TLS certificates in a PE safe.

Meanwhile, in the present exemplary embodiment, the SECC may provide information about the MO or the eMSP supporting the PnC service of the charging station to the EVCC in the form of a list, whereby the EV knows in advance the MO that the charger can authorize, and delivers the contract certificate supported by the corresponding MO to the charger. Thus, a trial-and-error problem can be prevented in the PnC authorization, thereby rapidly and accurately performing the authorization of the PnC process.

Fig. 4 is a block diagram illustrating message ordering for V2G communication states to describe a PnC-related service provider information providing method according to an exemplary embodiment of the present disclosure.

As shown in fig. 4, in a Supported Application Protocol (SAP) configuration state, the EVCC may receive a supported application protocol response message (SupportedAppProcotolReq) corresponding to a supported application protocol request message (SupportedAppProcotolReq) from the SECC, and in a Session Setup (SSU) state, the EVCC may transmit a session setup request message (sessionsetupeq) to the SECC within a preset sequence performance timeout time.

When the EVCC uses Power Line Communication (PLC), the EVCC may receive a session establishment response message (SessionSetupRes) corresponding to the session establishment request message (SessionSetupReq), and then move or transition to an Authorization Setup (ASUP) state 40. Thereafter, the EVCC may transmit an authorization setup request message (authenticationsetup) to the SECC within a preset timeout period.

Further, when the EVCC receives an authorization setup response message (authenticationsetup response) with a response code parameter (ResponseCode) set to "OK" and a credential installation service parameter (authenticationservice) set to "true", the EVCC may transmit a credential installation request message (authenticationreq) to the SECC within a predetermined timeout period in a Credential Installation (CINS) state for installation or update of the contract credentials.

When the EVCC receives an authorization setup response message (authenticationsettings) with the response code parameter value set to "OK" and the credential installation service parameter set to "false", the EVCC may send an authorization request message (authenticationreq) to the SECC within a preset timeout period in an Authorization (AUTH) state 42. In this case, a state transition from the authorized state 42 to the CINS state is possible.

In the above-described ASUP state 40 or AUTH state 42, the SECC may provide the EVCC with a service provider list of at least one or more service providers that support the PnC service of the charging station associated with the EV. Further, the EVCC may provide the SECC with information about one service provider selected from the service provider list and a contract certificate issued by the selected service provider.

Meanwhile, when the EVCC uses the wireless LAN, the EVCC may move or transition to a vehicle location setup (VPS) state 30 after receiving the session setup response message, and transmit a vehicle location setup request message (vectorepa) to the SECC.

In addition, after the EVCC receives a vehicle location establishment response message (vehicle location establishment setup) a second sequence for renegotiation may be performed according to parameters in the vehicle location establishment (VPS) response message.

In the second sequence, a compatible method for positioning or pairing of ACD or WPT may be found based on information included in the VPS response message, and if a compatible method is not present or found, the EVCC may jump from the VPS state to the ASUP state 40 to perform DC charging or AC charging, and transmit an authorization setup request message (authorization setup request) to the SECC within a preset timeout period in the ASUP state 40.

Of course, after receiving the VPS response message, the EVCC may move or transition to the ASUP state by a sequential transition from the VPS state to the vehicle locating state and the pairing state according to another setting of the parameters in the VPS response message.

Further, the EVCC may transition from the authorization state 42 to a Service Discovery (SDI) state after authorization is completed, and may transition from the authorization state 42 to a Service Detail (SDE) state. Here, the SDI state may be converted to a Session Stop (SSP) state, or may be converted from a Power Delivery (PD) state through service renegotiation.

That is, after receiving an authorization response message (authenticationres) with a specific parameter set to "complete" (e.g., evprocessing) and a response code parameter set to "OK", the EVCC may transmit a service discovery request message (servicediscovery req) to the SECC within a preset timeout period. The message sent to the SECC may be delivered by or via the SECC to the target secondary actor.

Further, after receiving a service discovery response message (servicediscover) with a response code parameter set to "OK", the EVCC may transmit a service detail request message (servicedetails res) to the SECC within a preset timeout period.

After receiving a service detail response message (servicedetails) with the response code parameter set to "OK", if an additional service detail request message is required to retrieve detailed information from the SECC, the EVCC may transmit another service detail request message to the SECC within a preset timeout period.

Further, after receiving a service detail response message (servicedetails) in the SDE state, the EVCC may perform a first sequence for renegotiation according to a specific parameter in the service detail response message.

In the first sequence, pre-stored or preset compatibility parameters for DC charging or AC charging may be found based on the service detail response message, and if no compatibility parameters are found, the EVCC may jump or transition from the SDE state to the VPS state for vehicle positioning or pairing of ACD or WPT, and a vehicle positioning setting request (vectoreptionistetupreq) message is transmitted to the SECC in the Vehicle Positioning Setting (VPS) state.

In the above-described ASUP state 40 or authorization state 42, the SECC may provide the EVCC with a service provider list of at least one or more service providers that support the PnC service of the charging station associated with the EV. Further, the EVCC may provide the SECC with information about one service provider selected from the service provider list and a contract certificate issued by the selected service provider.

On the other hand, the EVCC may be configured to keep track of Selected Authorized Services (SAS) that have been used during the current service session, or to keep track of SAD and contract certificate chains so as not to fall into consecutive loops.

Further, the remaining communication state may be processed or converted based on Power Line Communication (PLC), wireless LAN, or the like, such as Service Selection (SSEL), charging Parameter Discovery (CPD), device Positioning (DPOS), device Connection (DCON), cable inspection (CC), precharge (PC), power Delivery (PD), AC charging loop (ACCL), DC charging loop (DCCL), wireless Power Transfer Charging Loop (WPTCL), device Disconnection (DDIS), welding Detection (WDET), session Stop (SSP), or the like. Further, at least some of the communication states may be handled or transitioned according to a process for an AC charging scheme or a DC charging scheme. Furthermore, at least some of the communication states may be handled or converted according to a scheme using WPT or ACD. Since the processing or conversion of these communication states is already well known, a detailed description thereof will be omitted.

Meanwhile, in the above-described PnC authorization establishment process, a specific parameter of the authorization establishment request message, i.e., a parameter of requesting the certificate installation service, may be set to "yes" or "true".

Fig. 5 is an exemplary diagram for describing a certificate installation method that may be combined with a PnC-related service provider information providing method according to an exemplary embodiment of the present disclosure.

As shown in fig. 5, the certificate installation method may include a process of adding a tight-fit certificate private key to a Secondary Actor (SA), such as eMSP 300, to install a Contract Certificate (CC) in an EVCC that does not include a Trusted Platform Module (TPM) 2.0.

That is, in order to minimize distribution routing and communication processing time and simplify structural processing, the SA may generate a key pair for certificates, generate its own certificate using the key pair, and distribute the generated contract certificate and corresponding private key to the EVCC 100. To maintain confidentiality of the contract private key, a security mechanism may be used for secure transmission of the contract certificate private key.

The Contract Certificate (CC) may include a certificate (i.e., sub-CA1 cert) 350 issued by a primary subordinate authentication authority of the eMSP 300 for the EVCC100 and/or a certificate (i.e., sub-CA2 cert) 360 issued by a secondary subordinate authentication authority of the eMSP 300 for the EVCC 1000. The contract certificate may be used for XML signing on the application layer to verify the signature generated by EVCC 100.

When a secondary actor such as the eMSP 300 distributes a contract certificate and a contract private key, a public key (hereinafter, simply referred to as "contract public key") 370 belonging to the contract certificate may be used to encrypt the contract private key for security. That is, encryption of the contract certificate may use a private key paired with a public key (contract public key) 370 included in the second actor's root certificate 312 or the eMSP 300 or included in the eMSP's primary intermediate CA certificate 350 or secondary intermediate CA certificate 360.

In addition, encryption of the contract certificate private key, i.e., the contract private key (K1), may use the contract public key 370 of the contract certificate, the encryption parameter M3 of the OEM supply public key 412 included in the OEM supply certificate 411, and the temporary diffie-hellman public key K2 372. The encrypted data packet (CCDP) of the contract private key K1 may include an eMAID corresponding to the EV user.

In other words, in the Advanced Encryption Standard (AES) with the galois/counter mode (GCM) of authentication ticket, the composite private key 380 may be encrypted based on a shared secret key entered by Elliptic curve Diffie-Hellman (ECDH) from the public key 412 of the OEM provided certificate 411. The ECDH shared secret key may correspond to the encryption parameter M3.

That is, the contract private key K1 combined with the authentication ticket may be encrypted with AES in GCM mode based on the ECDH shared secret key input from the OEM-provided certificate public key 412. The ECDH shared key may include a temporary DH public key K2 and a temporary DH key. The temporary DH secret key or the temporary DH private key corresponding to the temporary DH public key K2 may be prepared separately.

The eMSP 300 may use the root certificate 312 to generate a contract certificate. The root certificate 312 is the root CA certificate of the eMSP, and this root certificate does not exist in the EVCC, but the CPS may need to process the contract certificate according to a preconfigured procedure.

Further, the eMSP300 may generate a contract certificate and generate credentials for the EVCC100, including an encrypted contract certificate private key (i.e., a key specifically encrypted for the EVCC 100). The certificate may be stored in a specific message field (signature data).

In addition, in order to distribute the contract certificate and encrypted private key to the EVCC100 via the online installation path of the SECC200, the eMSP300 may transmit a Contract Certificate Data Packet (CCDP) including CCDP or a certificate installation packet as a Certificate Installation Response (CIR) message to the CPS390 through a pre-configured communication channel of general B2B communication.

CPS390 may use its signature to give the accuracy and reliability of the credential and relay the signed message to SECC200. Here, the SECC200 may compile a Certificate Installation Response (CIR) message and transmit it to the EVCC100. In this case, the CPS is considered to be reliable, and thus the EVCC100 may not need to verify the contract certificate received through the CIR message. For example, the eMSP itself, the EVSE operator, or a completely independent service provider may take on the role of CPS390.

The aforementioned credentials may include information such as a symmetric key previously shared by the eMSP300 and the EVCC100 or an ID that may be used to verify a physical or logical identity of the EVCC100. Further, the aforementioned certificate may include a public key paired with the private key of the EVCC100, or a public key certificate or certificate chain for the public key. The certificate chain may include providing a certificate chain. The provisioning certificate is a certificate for one authentication by the EVCC100, and the CPS leaf certificate is issued and installed after the authentication is completed so that it can be used for later authentication.

Meanwhile, when the eMSP 300 or SA provides a plurality of contract certificates based on different curves defined by standards or regulations, the eMSP 300 or SA needs to transmit a plurality of different signed installation data (signedistilitata) containers to the SECC 200, and the EVCC100 can import and install all the different contract certificates at the EV user's discretion by using a round robin mechanism for certificate installation request (certifyilitationreq) messages.

On the other hand, EVCC100 may sign the body element of the credential installation request message using a private key associated with the EV public key ("objectipublickey") of OEM provisioning certificate 411.

In summary, in the above certificate installation method, a temporary static DH key exchange protocol is used to derive a static session key from the recipient's key. The SA or eMSP may send the private key to the EVCC100 in encrypted form using the derived session key. In a transient static change of the DH protocol, the public key of the recipient (e.g., EVCC 100) is unchanged. That is, it is static and known to the sender (i.e., eMSP 300). However, sender 300 may still use the ephemeral public key sent to the recipient. In the above manner, the sender and the receiver can derive the same session key without the receiver's response message. Because the SA uses the temporary key, the derived session key is different for each instance (distribution) of the secret or private key.

Furthermore, CPS390 may use the signature to assert correctness and authenticity of the certificate and relay the signed message segment P2 to SECC200. The SECC200 may compile a certificate installation response (Certification InformationRes) message received from the CPS390 and send it to the EVCC100. In this case, the CPS is considered trusted, and therefore the EVCC100 does not need to verify the contract certificate received through the certificate-mounting response message.

Fig. 6 is a diagram for describing a main procedure of a PnC-related service provider information providing method according to an exemplary embodiment of the present invention. FIGS. 7a and 7b are scheme diagrams of some configurations of an authorization setup response message that may be used in the PnC-related service provider information providing method of FIG. 6.

As shown in fig. 6, the PnC-related service provider information providing method may be performed in the authorization setup processes S61 and S62 and the authorization processes S63 and S64.

In the PnC-related service provider information providing method, the EVCC of the EV may first transmit an authorization setup request message (authenticationsetupreq) for the PnC to the SECC. The authorization setup request message may be a substantially null message (S61).

Then, the SECC may send an authorization setup response message (AuthorizationSetupRes) to the EVCC of the EV (S62). In particular, the SECC may provide the EVCC with a list of supported eMSPs, MO, or clearing house providers for PnC authorization. That is, the SECC may include a service provider list (SupportedProviderList) supporting PnC in an element of a specific parameter of the authorization setup response message.

For example, the authorization setup response message may include parameters related to the response code, authorization service, credential installation service, and PnC ASUP response identification mode.

The response code in the authorization setup response message may be set to "OK", the authorization service may be set to "PnC", and the certificate installation service may be set to "yes/" "true" or "no"/"false".

Further, in the authorization setup response message, a PnC authorization setup response identification mode (pnc_asresidentification) parameter may include a generation challenge (GenChallenge) element as its type, and may include an element of a supported service provider list (supportproviderlist) (see fig. 7 a). The generation challenge is an element related to allowing a charging attempt, and may be set to allow any person or any person's charging attempt. In addition, the supported service provider list type (SupportedProviderListType) parameter of the supported service provider list parameter may include as many elements for the supported service providers (service providers) as a preset number (e.g., 30) (see fig. 7 b). If the preset number is exceeded, the latest element of the supported service provider list type may be set to indicate that there is an additional service provider list, such as "MORE".

For example, the supported service provider list 62a is a list of service providers that support pncs of SE associated with EVs, and may include information or identifiers of MOs in a contractual relationship that support pncs for battery charging of EVs. For example, the identifiers of MO are "DEINO", "FREDF", "NLELA", and the like.

That is, the supported provider list in which information about supported service providers is stored may include, for example, a first eMSP ("DEINO"), a second eMSP ("FREDF"), and a third eMSP ("NLERA"). The first eMSP is an eMSP from Germany (DE) represented by a provider code called "inogy", the second eMSP is an eMSP from French (FR) represented by a provider code called "EDF", and the third eMSP may be an eMSP from Netherlands (NL) represented by a provider code called "ELA".

As described above, the supported provider list may be configured to insert an identifier of a charging service provider or a roaming service provider as the first 5 characters of the eMAID. The first 5 characters may include 2 characters of a country code and 3 characters of a company code. Of course, identifiers of the charging service provider or the roaming service provider included in the support service provider list may use a coding scheme other than the above-described 5-character scheme.

In addition, the supported service provider list 62a may include a roaming platform ("DETMA") for MOs in a contractual relationship that supports PnC for battery charging of EVs. The roaming platform ("DETMA") may be a roaming platform of germany (DE) with a provider code called "Tagamilong (TMA)".

When using such a roaming platform, an EV or EV user may use a contract certificate issued by a first MO to receive an automatic charging authorization and payment service from a third party SE operating in a PnC scheme supported by a second MO different from the first MO.

The EVCC of the EV may then transmit an authorization request message (authenticationreq) to the SECC. In this case, the EVCC may generate an authorization request message (authenticationreq) including service provider information corresponding to a first service provider selected from the service provider list and a contract certificate issued by the first service provider, and transmit the authorization request message to the SECC (S63).

In the present exemplary embodiment, the authorization request message may include the selected authorization service parameter, and may include a PnC authorization request identification mode parameter or a PnC authorization request authorization mode parameter.

In the authorization request message, a selected authorization service (supplanteproviderlist) parameter may be set to "PnC". In addition, the PnC authorization request authorization mode (pnc_areq authorization mode) or PnC authorization request identification mode (pnc_areq identification mode) parameter may include a generation challenge (GenChallenge) element and a contract certificate chain (contact certificate chain) element. The contract certificate chain element may be set to "pass EDF"63a to indicate that it includes contract certificates issued by a particular eMSP called "EDF" in France (FR).

The SECC may then send the contract certificate issued by the first service provider to the CPS, receive the confirmation result from the CPS, and then send an authorization response message (authenticationres 0 to EVCC of EV (S64).

Fig. 8 is a diagram for describing a main procedure of a PnC related service provider information providing method according to another exemplary embodiment of the present disclosure.

As shown in fig. 8, the EVCC100 may transmit an authorization setup request message (authenticationsetup) of the PnC to the SECC200 of the SE supplying power to the EV (S81).

Then, EVCC100 may receive an authorization setup response message (authenticationsetup) from SECC200, which includes a list of service providers supporting pncs of SE associated with the EV (S82).

Then, the EVCC100 may select one Service Provider (SP) from the service provider list (S83).

Then, the EVCC100 may transmit an authorization request message (authenticationreq) including a contract certificate issued by the selected service provider to the SECC200 (S84).

Then, the EVCC100 may receive an authorization response message (authenticationres) indicating completion of PnC authorization from the SECC200 (S85).

FIG. 9 is a schematic block diagram of a PnC-related service provider information providing apparatus according to another exemplary embodiment of the present disclosure.

As shown in fig. 9, the PnC-related service provider information providing apparatus 200 may be installed on or coupled to an EV or EVCC, and in another implementation, may be installed on or coupled to an EVSE or SECC.

PnC-related service provider information providing apparatus 200 may include at least one processor 210 and memory 220. In addition, the device 200 may also include a storage device 230 and a transceiver 240. Further, the device 200 may include an input interface device 250, an output interface device 260, or an input/output interface device.

Processor 210 may execute program instructions stored in memory 220 and/or storage 230. Processor 210 may be implemented as at least one Central Processing Unit (CPU) or Graphics Processing Unit (GPU) or as other processor capable of performing the PnC related service provider information providing methods according to the present disclosure.

Memory 220 may store program instructions or software modules. Processor 210 may implement the PnC-related service provider information providing method by executing program instructions or software modules stored in memory 220.

In addition, at least some components of the PnC related service provider information providing apparatus (including the processor 210 and the memory 220) may be connected to each other through a bus to exchange signals and data. Processor 210, memory 220, and program instructions to be executed by processor 210 may implement the PnC-related service provider information providing method in an EVCC or a SECC.

The memory 220 may include, for example, volatile memory such as Read Only Memory (ROM) and nonvolatile memory such as Random Access Memory (RAM). Memory 220 may load program instructions stored in storage 230 and provide the loaded program instructions to processor 210 such that processor 210 may execute the program instructions.

The storage device 230 is a recording medium (such as a magnetic medium such as a hard disk, a floppy disk, and a magnetic tape, an optical medium such as a compact disk read-only memory (CD-ROM), a Digital Versatile Disk (DVD), a magneto-optical medium such as a floppy disk, or a semiconductor memory such as a flash memory, an Erasable Programmable ROM (EPROM), or a Solid State Drive (SSD) made based thereon) adapted to store program instructions and data.

The program instructions may be configured to, when executed by the processor 210, perform: receiving an authorization setup request message of a PnC from an EV communication controller (EVCC) installed in the EV; generating a service provider list supporting service providers of PnC for SE associated with EV according to the authorization setup request message; generating an authorization setup response message comprising a list of service providers; transmitting an authorization setup response message to the EVCC; receiving an authorization request message including service provider information and a contract certificate corresponding to a first service provider selected from a service provider list from the EVCC; based on the service provider information and the contract certificate in the authorization request message, authorizing the PnC supported by the first service provider; and sending an authorization response message indicating that authorization is complete.

When executed by the processor 210, the program instructions described above may be loaded into the processor 210 in the form of software modules or software cells. The software modules may include: a transmission unit that transmits a message; a receiving unit that receives a message; a generation unit that generates a message including service provider information; a comparison unit that compares the mobile operator in the service provider information with the previously stored information of the mobile operator; and a selection unit that selects a contract certificate issued by one mobile operator selected based on the comparison result.

In addition, in the service provider information providing apparatus related to the PnC, the transceiver 240 may include a WLAN interface, a PLC module, a point-to-point signaling (P2 PS) controller, a gateway (gav), or a communication subsystem of a combination thereof, and may function to transmit/receive signals and data with at least one external apparatus or transmit signals and data with at least one external apparatus. The WLAN interface may include an interface for Wi-Fi communication.

Meanwhile, the method that has been described in the above exemplary embodiments may be implemented as a computer readable program or code on a computer readable recording medium. The computer readable recording medium may include all types of storage devices in which data readable by a computer system is stored. Furthermore, the computer-readable recording medium may be distributed to computer systems connected through a network so that the computer-readable programs or codes are stored and executed in a distributed manner.

The computer readable recording medium may include hardware devices, such as ROM, RAM, and flash memory, that are specially configured to store and execute program instructions. The program instructions may include high-level language code that can be executed by a computer using an interpreter or the like, as well as machine code generated by a compiler.

Some aspects of the present disclosure have been described above in the context of a device, but methods corresponding thereto may be used to describe some aspects of the present disclosure. Here, the blocks or means correspond to operations of the method or characteristics of operations of the method. Similarly, the aspects of the invention described above in the context of methods may be described using the characteristics of the blocks or items corresponding thereto or the devices corresponding thereto. Some or all of the operations of the method may be performed, for example, by (or using) a hardware device, such as a microprocessor, programmable computer, or electronic circuit. In some embodiments, at least one of the most important operations of the method may be performed by such a device.

In an exemplary embodiment, a programmable logic device (e.g., a field programmable gate array) may be used to perform some or all of the functions of the methods described herein. In an embodiment, a field-programmable gate array (field-programmable gate array) can be operated with a microprocessor to perform one of the methods described herein. In general, the method is preferably performed by some hardware device.

Although the present disclosure has been described above with reference to the embodiments thereof, it will be understood by those of ordinary skill in the art that various changes and modifications may be made without departing from the technical spirit and scope of the present disclosure as defined in the following claims.

Claims (22)

1. A method for providing service provider information related to plug-in charging/park charging (PnC), the method being performed by a power Supply Equipment Communication Controller (SECC) of a power Supply Equipment (SE) supplying electric power to an Electric Vehicle (EV), the method comprising:

receiving an authorization setup request message of plug-in charging/parking charging from an EV communication controller (EVCC) installed in the EV;

generating a service provider list supporting service providers for PnC of SE associated with the EV according to the authorization establishment request message;

transmitting an authorization setup response message including the service provider list to the EVCC;

receiving an authorization request message including service provider information and a contract certificate corresponding to a first service provider selected from the service provider list from the EVCC; and

an authorization response message indicating completion of authorization of the PnC supported by the first service provider is transmitted to the EVCC based on the service provider information and the contract certificate.

2. The method of claim 1, wherein the authorization setup response message includes a PnC authorization setup response identification mode (pnca sresidentification node) parameter having a supported service provider list and an element generating a challenge (GenChallenge).

3. The method of claim 2, wherein the supported service provider list is a list of service providers that support pncs of the SE associated with the EV and includes information or identifiers of mobile operators in contractual relationships that support pncs for battery charging of the EV.

4. The method of claim 2, wherein the supported service provider list (SupportedProviderList) is a list of service providers supporting pncs of the SE associated with the EV and includes a roaming platform for mobile operators in contractual relationships supporting pncs for battery charging of the EV.

5. The method of claim 2, wherein the authorization setup response message further includes a response code parameter set to "OK" and an authorization service parameter set to "PnC".

6. The method of claim 5, wherein the authorization setup response message further includes a certificate installation service parameter set to "true" or "false".

7. The method of claim 1, further comprising: the EVCC is allowed to select one Mobile Operator (MO) from a list of service providers based on the list of service providers included in the authorization setup response message.

8. The method of claim 7, further comprising: the EVCC is allowed to generate an authorization request message including service provider information of a first MO selected from the service provider list and a contract certificate issued by the first MO.

9. The method of claim 1, further comprising:

based on the list of service providers included in the authorization setup response message,

allowing the EVCC to release a state associated with the SE; or alternatively

The EVCC is allowed to output a signal for causing the EV to leave a parking area of the SE.

10. The method of claim 1, further comprising:

allowing the EVCC to select a roaming platform or a roaming service included in the service provider list based on the service provider list; and

the EVCC is allowed to generate an authorization request message including service provider information set to the roaming platform or the roaming service, and a contract certificate issued by the roaming platform or a roaming platform providing the roaming service.

11. The method of claim 10, wherein the authorization request message includes a selected authorization service parameter set to "PnC" and includes a generation challenge element and a contract certificate chain element within a PnC request identification schema or PnC request authorization schema parameter, and the contract certificate chain element is set to the roaming platform.

12. A method for providing service provider information related to plug-in/park charging (PnC), the method being performed by an Electric Vehicle Communication Controller (EVCC) of an Electric Vehicle (EV), the method comprising:

transmitting an authorization setup request message of PnC to a power Supply Equipment Communication Controller (SECC) of a power Supply Equipment (SE) supplying power to the EV;

receiving an authorization setup response message from the SECC, the authorization setup response message including a service provider list of service providers supporting PnC of the SE associated with the EV;

transmitting an authorization request message including service provider information and a contract certificate corresponding to a first service provider selected from the service provider list to the SECC; and

an authorization response message is received from the SECC indicating completion of authorization of the PnC supported by the first service provider.

13. The method of claim 12, wherein the authorization setup response message includes a PnC authorization setup response identification mode (pnca sresidentification node) parameter having a supported service provider list and an element generating a challenge (GenChallenge).

14. The method of claim 13, wherein the supported service provider list is a list of service providers that support pncs of the SE associated with the EV and includes information or identifiers of mobile operators in contractual relationships that support pncs for battery charging of the EV.

15. The method of claim 13, wherein the supported service provider list (SupportedProviderList) is a list of service providers supporting pncs of the SE associated with the EV and includes a roaming platform through one of the mobile operators in a contractual relationship supporting pncs for battery charging of the EV.

16. The method of claim 13, wherein the authorization setup response message further includes a response code parameter set to "OK", and an authorization service parameter set to "PnC".

17. The method of claim 16, wherein the authorization setup response message further includes a certificate installation service parameter set to "true" or "false".

18. The method of claim 12, further comprising: a Mobile Operator (MO) is selected from the list of service providers based on the list of service providers included in the authorization setup response message.

19. The method of claim 18, further comprising: an authorization request message is generated that includes service provider information of a first MO selected from the service provider list and a contract certificate issued by the first MO.

20. The method of claim 12, further comprising: based on the list of service providers included in the authorization setup response message,

releasing a state associated with the SE; or alternatively

A signal for causing the EV to leave a parking area of the SE is output.

21. The method of claim 12, further comprising:

selecting a roaming platform or roaming service included in the service provider list based on the service provider list; and

an authorization request message is generated that includes service provider information set to the roaming platform or roaming service and a contract certificate issued by the roaming platform or a roaming platform providing the roaming service.

22. An apparatus for providing service provider information related to plug-in charging/park charging (PnC), the apparatus comprising a Supply Equipment Communication Controller (SECC) of a Supply Equipment (SE) supplying electric power to an Electric Vehicle (EV), the apparatus comprising:

a processor; and

a memory storing instructions executable by the processor,

wherein the instructions, when executed by the processor, cause a process to perform:

receiving an authorization setup request message of a PnC from a communication controller (EVCC) installed in the EV;

generating a service provider list supporting service providers for PnC of SE associated with the EV according to the authorization establishment request message;

transmitting an authorization setup response message including the service provider list to the EVCC;

receiving an authorization request message including service provider information and a contract certificate corresponding to a first service provider selected from the service provider list from the EVCC; and

an authorization response message indicating completion of authorization of the PnC supported by the first service provider is transmitted to the EVCC based on the service provider information and the contract certificate.