Computer Implemented Method for Providing a Vehicle Service and Triggering a Process to Pay For the Vehicle Service, Software Program, and System

Abstract

A vehicle service and a process to pay for the vehicle service are provided. A data connection is established between a service point and an electronic control unit of a vehicle. Initial vehicle service data is gathered that includes a timestamp of establishing the data connection, identification data of the vehicle, and, at the time of the timestamp, at least one value of a state of the vehicle indicating a quantity which is to be altered by the provision of the vehicle service. Service provider service data of the completed vehicle service is stored on the blockchain network. The validity of the provision of the vehicle service is checked by comparing the initial and final vehicle service data and the provider service data of the completed vehicle service. When the validity is confirmed, the process to pay for the vehicle service is triggered on the blockchain network.

Claims

1.-15. (canceled)

16. A method for providing a vehicle service and triggering a process to pay for the vehicle service, comprising: establishing a data connection between a service point for providing the vehicle service and an electronic control unit of a vehicle; gathering initial vehicle service data at a start of a provision of the vehicle service in the electronic control unit, wherein the initial vehicle service data comprises: a timestamp of establishing the data connection, identification data of the vehicle, and at least one value of a state of the vehicle indicating a quantity to be altered by the provision of the vehicle service; storing the initial vehicle service data and final vehicle service data gathered in the electronic control unit, which are updated initial vehicle service data upon completion of the provision of the vehicle service, consecutively or along with each other on a blockchain network configured to be resistant to modification of data; storing, on the blockchain network, service provider service data of the completed vehicle service gathered in a service provider connected to the service point; checking, on the blockchain network, a validity of the provision of the vehicle service by comparing at least a first numerical value of the initial and the final vehicle service data of a predetermined unit with at least a second numerical value of the provider service data of the completed vehicle service of the predetermined unit, such that the validity is positive, when the first and second numerical values and/or a third numerical value, which results from the comparing, based on an arithmetical operation using the first and second numerical values, are/is within a predetermined range of numerical values or below/above a predetermined threshold value; and when the validity is positive, triggering on the blockchain network the process to pay for the vehicle service.

17. The method of claim 16, wherein after the step of establishing the data connection between the service point and the electronic control unit and before the step of storing the data of the electronic control unit and the service provider on the blockchain network, the following step occurs: exchanging between the service provider and the electronic control unit a message to initiate a provision of the vehicle service by sending the message from the electronic control unit to the service provider, and when the provision of the vehicle service is completed, a further message indicating that the provision of the vehicle service is completed by sending the further message from the electronic control unit to the service provider.

18. The method of claim 17, wherein the establishing of the data connection is used as a trigger for the exchanging of the message between the service provider and the electronic control unit to initiate the provision of the vehicle service.

19. The method of claim 16, wherein a hash of the initial vehicle service data and a further hash of the final vehicle service data are stored on the blockchain network, and the hash and the further hash are signed by the electronic control unit.

20. The method of claim 16, wherein the vehicle service comprises at least one of: electric charging the vehicle being an electric vehicle or a hybrid vehicle, fueling the vehicle comprising a combustion engine or a hydrogen engine, fueling the vehicle being the hybrid vehicle, parking, paying tolls, using the vehicle for rent, or shopping from within the vehicle.

21. The method of claim 20, wherein the vehicle service is the electric charging, the data connection between the service point in form of an electric vehicle charging station and the electronic control unit is established by plugging a charging cable of the electric vehicle charging station in a charging port of the vehicle, and the comparing of the first numerical value with the second numerical value comprises comparing of a charging duration or a charging consumption.

22. The method of claim 16, wherein depending on the service provider, the process to pay for the vehicle service is executed either on: the blockchain network through a stable coin to prevent a price fluctuation of cryptocurrencies, or using a credit card.

23. The method of claim 16, wherein the storing of the initial and the final vehicle service data on the blockchain network, the checking of the validity of the provision of the vehicle service, and the triggering of the process to pay for the vehicle service occur automatically.

24. The method of claim 16, wherein at least the checking of the validity of the provision of the vehicle service and the triggering of the process to pay for the vehicle service occur by using a smart contract, wherein the smart contract is used as a single smart contract for different kinds of vehicle services.

25. The method of claim 16, wherein the method occurs fully automated such that the method can be executed by the vehicle being an autonomous vehicle.

26. A non-transitory computer-readable medium comprising instructions operable, when executed by one or more computing systems, to perform the method of claim 16.

27. A system for providing a vehicle service and triggering a process to pay for the vehicle service, comprising: a data connection between a service point configured to provide the vehicle service and an electronic control unit of a vehicle, wherein the electronic control unit is configured to gather initial vehicle service data at a start of a provision of the vehicle service in the electronic control unit, and the initial vehicle service data comprises: a timestamp of establishing the data connection, identification data of the vehicle, and at least one value of a state of the vehicle indicating a quantity to be altered by the provision of the vehicle service, and the electronic control unit is configured to store the initial vehicle service data and final vehicle service data gathered in the electronic control unit, which are updated initial vehicle service data upon completion of the provision of the vehicle service, consecutively or along with each other on a blockchain network configured to be resistant to modification of data, a service provider connected to the service point and configured to store, on the blockchain network, service provider service data of the completed provision of the vehicle service gathered in the service provider, a smart contract in the blockchain network for checking, on the blockchain network, a validity of the provision of the vehicle service by comparing at least a first numerical value of the initial and the final vehicle service data of a predetermined unit with at least a second numerical value of the provider service data of the completed vehicle service of the predetermined unit, such that the validity is positive, when the first and second numerical values and/or a third numerical value, which results from the comparing based on an arithmetical operation using the first and second numerical values, are/is within a predetermined range of numerical values or below/above a predetermined threshold value, wherein when the validity is positive, the process to pay for the vehicle service is triggered by the smart contract on the blockchain network.

28. The system of claim 27, wherein the service point and service provider are integrated together.

29. The system of claim 27, wherein the blockchain network is an Ethereum blockchain or an Ethereum main-net.

30. The system of claim 28, wherein a Rinkeby network as an Ethereum test network, a Ropsten network as a further Ethereum test network, or a Tobalaba network as an Ethereum based test network of an Energy Web Chain, is configured to combine the storing of the initial and final vehicle service data on the blockchain network, the checking of the validity of the provision of the vehicle service, and the triggering of the process to pay for the vehicle service.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0037] FIG. 1 is a schematic workflow diagram including functional units of a system for checking a validity of a provision of a vehicle service in form of electric charging an electric car and triggering a process to pay for the vehicle service according to the present subject matter,

[0038] FIG. 2 is a schematic diagram of a sequence of method steps according to the present subject matter, and

[0039] FIG. 3 is a graphic representation of Ethereum transaction latencies using different network configurations of the system for checking the validity of the provision of the vehicle service and triggering the process to pay for the vehicle service according the present subject matter.

DETAILED DESCRIPTION OF THE DRAWINGS

[0040] FIG. 1 shows a workflow diagram including functional units 1, 2, 3, 4, 5, and 6 of a system for checking a validity of a provision of a vehicle service in form of electric charging an electric car 1 and triggering a process to pay for the electric charging. The vehicle 1 in form of the electric car is connected over a data and energy transferring connection 10 in form of a charging cable to a service point 3 embodied as a charging station or charging point. The service point 3 is connected via a first service data connection 13 to a service provider 4 providing the electric charging of the vehicle 1 for transmitting the messages of Start Charging 13a and Stop charging 13b as request and/or acknowledgement messages between the service point 3 and the service provider 4.

[0041] An electronic control unit 2 of the vehicle 1 is represented by a Raspberry Pi comprising an analyzing unit 2a for analyzing vehicle data and vehicle service data when the charging cable 10 is plugged in or unplugged from a charging port of the vehicle 1. The vehicle 1 communicates via a vehicle data connection 11 in form of a vehicle bus initial vehicle service data in form of its vehicle identification 11a, charge level 11b of a battery of the vehicle 1, GPS location data 11c and the cable plugged event 11d along with a timestamp of plugging in the cable 10 (not shown) to the Raspberry Pi 2. The Raspberry Pi 2 then analyses these data 11a-11d using the analyzing unit 2a and triggers the charging process at the service provider 4 by sending a Start Charging message 12a over a first electronic control unit data connection 12. This request gets delivered via the first service data connection 13 by a Start Charging message 13a to the service point 3, which eventually provides electricity to the electric vehicle 1. When the charging started successfully, the Raspberry Pi 2 stores the vehicle service data, including the current timestamp and a sessionId, on a blockchain network 5, e.g., a Rinkeby Ethereum test network as shown in FIG. 1, via a second electronic control unit data connection 20.

[0042] When the cable 10 gets unplugged from the charging part of the vehicle 1, the Raspberry Pi 2 analyses the updated initial vehicle service data as final vehicle service data again by using the analyzing unit 2a. It triggers the Stop Charging event by sending the Stop Charging message 12b and the service point 3 stops to provide electricity upon receiving the Stop Charging message 13b from the service provider unit. The Raspberry Pi 2 then stores the final vehicle service data in form of its identity 20a, updated charge level 20b of the battery of the vehicle 1, updated GPS location data 20c and the duration 20d from the cable 10 plugged to unplugged and/or the cable unplugged event 11d along with an updated timestamp of unplugging the cable 10 via the second electronic control unit data connection 20 on the blockchain 5. The service provider 4 stores service provider service data in form of the charge 24a transferred to the vehicle 1 and a duration 24b from the cable 10 plugged to unplugged of the completed vehicle service gathered in the service provider 4 via a second service data connection 24 on the blockchain 5. A smart contract 6 compares the provided energy 24a of the service point 3 and the consumed energy as the difference between the initial charge level 11b and the updated charge level 20b of the vehicle 1 as charging energy data 25b which data is received by the smart contract 6 over a first blockchain data connection 25. Alternatively or additionally, the smart contract 6 may compare the duration from the cable 10 plugged to unplugged 20d of the electronic control unit 2 with the duration 24b from the cable 10 plugged to unplugged of the completed vehicle service gathered by the service provider 4 as charging duration data 25a. If the comparison is positive a payment 26a on a Tobalaba blockchain is triggered by the smart contract 6 over the first blockchain data connection 25 or a second 26 blockchain data connection and the process terminates. The Rinkeby Ethereum test network, the smart contract 6, and the Tobalaba blockchain are comprised by the blockchain 5.

[0043] With the workflow and functional units 1, 2, 3, 4, 5, and 6 of the system shown in FIG. 1, a native ecosystem is provided for enabling the car 1 to connect to and consume services and to pay for the consumptions. To demonstrate the applicability of the present subject matter, the electric vehicle charging use case has been shown in FIG. 1. A Raspberry Pi is used to represent the Vehicle Engine Control Unit 2 (ECU). The Raspberry Pi 2 connects to the diagnosis interface (OBD2) of the car 1, which allows to work with the real vehicle bus data and to collect the requirements when replacing the Raspberry Pi with the actual in-car ECU 2 since it has similar resource constraints.

[0044] As soon as the charging cable 10 is plugged in, the event is read from the vehicle bus 11. Then, the start charging event is triggered at the service point 3. To record the start of the charging process in a safe and trusted manner, a hash of the vehicle information, including the vehicle identification 11a, timestamp, and state of charge 11b of the battery is stored on the Ethereum blockchain, through a transaction which is signed by the electronic control unit 2. To increase the users' privacy, the user data is stored off-chain, i.e. not on the blockchain 5. Once the charging cable 10 is unplugged, the charging process is terminated through the stop charging event. Consequently, the hash of the updated vehicle data is stored on the Ethereum blockchain.

[0045] To ensure secure payment of the charging process that can be trusted by all involved parties, an Ethereum smart contract 6 is used. This contract 6 allows comparing the data of the service point 3 with the data of the vehicle 1. Depending on the business model of the charge point operator, either the charging duration 25a or the charging consumption 25b are compared. If the respective values lie within a certain threshold, the payment 26a is triggered automatically. Depending on the provider, the payment 26a can be made using blockchain technology (e.g., through a stable coin to prevent a price fluctuation of cryptocurrencies), or using conventional means like a credit card.

[0046] Among different smart contract designs, the most efficient system combines the systems' logic into one smart contract 6 which stores a hash of the vehicle data on the blockchain 5 and automatically compares the consumed energy. Also, using only one smart contract 6 for storing and comparing the data, instead of using several contracts, saves Ethereum Gas costs when deploying the smart contract 6. It also decreases the latency of the execution of the inventive method since it is possible to store the data and compare it using only one transaction. However, the one-contract approach violates the principle of the separation of concerns. Also, the inventive method cuts the number of involved parties to half since many intermediaries (i.e., Charge Point Aggregators or Payment Providers) are not required in the inventive system.

[0047] FIG. 2 shows a sequence of method steps of the inventive method in time from top to bottom. In the initial step S10, the data connection 10 is established a between the service point 3 for providing the vehicle service such as charging the electric vehicle 1 and the electronic control unit 2 of the vehicle 1, and gathering the initial vehicle service data at a start of the provision of the vehicle service in the electronic control unit 2. The initial vehicle service data comprise a timestamp of establishing the data connection 10, identification data 11a of the vehicle 1, and at the time of the timestamp the at least one value 11b of a state of the vehicle 1 indicating a quantity which is to be altered by the provision of the vehicle service, which may be the charging level or the charging duration. Step S12 comprises exchanging between the service provider 4 and the electronic control unit 2 a Start Charging message 12a to initiate a provision of the vehicle service, e.g., by sending the Start Charging message 12a from the electronic control unit 2 to the service provider 4, and, when the provision of the vehicle service is completed, a further message 12b indicating that the provision of the vehicle service is completed, e.g., by sending the further message 12b from the electronic control unit 2 to the service provider 4. The start and stop of the charging could be executed in another way, e.g., by the charging point 3 recognizing directly that the charging should stop, e.g., by monitoring a resistance of the battery of the electric car. Therefore, this step S12 is optional as indicated by dashed lines of the arrow and the rectangle representing this step.

[0048] The next step S20 focuses on storing the initial vehicle service data and final vehicle service data gathered in the electronic control unit 2, which are updated initial vehicle service data at an end of the completion of the provision of the vehicle service, consecutively as indicated by steps 18, 19 or along with each other as indicated as a single step S20 on the blockchain or blockchain network 5 configured to be resistant to modification of data. At the same time as steps 18, 19, 20 or before/after these steps, step S24 indicates storing on the blockchain network 5 service provider service data of the completed vehicle service gathered in the service provider 4, which is connected to the service point 3.

[0049] Subsequently, it is checked in step S25 on the blockchain network 5 the validity of the provision of the vehicle service by comparing at least the first numerical value 20b; 20d of the initial and final vehicle service data of a predetermined unit with at least the second numerical value 24a; 24b of the provider service data of the completed vehicle service of the predetermined unit, i.e. for example the charging duration 20d of the electronic control unit 2 and the charging duration 24b of the service provider 4 or the charging consumption 20b of the electronic control unit 2 and the charging consumption 24a of the service provider 4. The validity is positive, when the first 20b; 20d and second 24a; 24b numerical values and/or a third numerical value, which results from the comparison based on an arithmetical operation using the first 20b; 20d and second 24a; 24b numerical values, are/is within a predetermined range of numerical values or below/above a predetermined threshold value. The third numerical value may be calculated as a difference between the first and second numerical values, and/or as a ratio thereof. When the validity is positive, there is a triggering step S26 executed on the blockchain network 5 to trigger the process of payment 26a to pay for the vehicle service.

[0050] FIG. 3 shows a graphic representation of Ethereum transaction latencies using different network configurations of the system for checking the validity of the provision of the vehicle service and triggering the process to pay for the vehicle service. To evaluate the design, the latency that a user experiences when using the inventive automated system is compared with an existing manual and not-automated platform which authenticates users using an NFC card (NFC: Near field Communication) at the service point 3 and accepts payment 26a using predetermined payment information. It is also compared the cost of running the platform, especially regarding the transaction fees for Ethereum. The inventive method based on the Ethereum test-net blockchain is on average 30% faster than the existing manually-operated platform. The cost of using the inventive system can be reduced by almost 50% at an Ether price of 300$ compared to known solutions.

[0051] An added latency due to blockchain confirmation time is demonstrated in the graph in FIG. 3. It displays the average execution time 30 of all transactions for one charging process of 10 test cases each when charging an electric vehicle. Each charging process is represented by a column of stacked durations for performing the steps S18, S19, S25, and S26 along with an interaction S13a to start the charging (see messages 12a, 13a in FIG. 1) and an interaction S13b to stop the charging (see messages 12b, 13b in FIG. 1).

[0052] Different Gas prices [1 (see 31), 5 (see 32), 10 (see 33) and 100 GWei (see 34)] are compared on a remote node hosted by Infura 31, 32, 33, 34 with a remote node hosted on AWS (Amazon Web Services) 35 and one light node running on the Raspberry Pi 2 on the Rinkeby test network 36 to the non-blockchain solution 41 using API (Application Programming Interface) only. The same configuration has been tested on the Ropsten 37 and Tobalaba 40 test networks. Transaction costs for a Gas price of 1 GWei or 0.000000001 Ether is 65,697 Gas*0.000000001 Ether=0.000065697 Ether. An Ether price of 160.83$ results thus in a transaction fee of 0.01$.

[0053] The Rinkeby network has a block time of 15 seconds. When calling the Store Data function, it is sent to a pool of pending transactions. Since the test network does not have many pending transactions, it gets mined into the next block every time. This is the reason why increasing the transactions Gas price up to 100 GWei does not lead to better performance.

[0054] Ethereum offers different manners to execute a contract function: the standard transactions which have been used so far and contract calls. These calls are executed directly in the VM (Virtual Machine) of the node. This means that they never get sent to the network. Therefore, contract calls cannot change the state of the contract and thus, are read-only. In our case, a contract call for the comparison of the energy consumption or duration comparison methods can be used. These methods take the vehicle energy (charging duration) as a parameter and compare it to the energy (charging duration) of the service point 3. The call does not change the state of the blockchain and therefore does not consume any Gas. It calls the contract function and receives the outcome of the comparison as a return value. Since calling the contract function is done locally, no transaction mining is necessary. This increases the transaction speed by almost a magnitude of 100. The median execution time of the call function is 221 milliseconds on the contrary to 18.298 milliseconds when sending a transaction to the Infura node. This configuration using the remote node hosted by Infura running on the Rinkeby test network is referenced by sign 39. While the latency performance is excellent, the improvement in the execution time compared to the configuration 31 comes at the cost of reduced trust. Calling the method and executing it locally means that it is not written to the blockchain 5. This results in the fact that it is not possible to inspect the input values 25a, 25b for the comparison at a later stage. Eventually, this means that the comparison with the call method is as secure as implementing it directly in JavaScript, circumventing the blockchain 5 entirely. The improvement in convenience and usability thus comes at the cost of reduced trust.

[0055] The call of the storeData method takes up most of the latency time. The data storage S18, S19 and energy or time consumption comparison S25 transactions can be optimized. The storeData method is called within the compareEnergy method to get rid of one additional transaction. This configuration using the remote node hosted by Infura running on the Rinkeby test network is referenced by sign 38. The configuration 38 which combines the transactions for storing S18, S19 and comparing S25 the data (1 GWei 1 Contract Infura Rinkeby) is the one with the best performance on the Rinkeby and Ropsten networks since one additional storage transaction can be avoided.

[0056] The performance is better on the Tobabala network 40 which is an Ethereum based test network of the Energy Web Chain, which is only 10 seconds slower than using the non-blockchain solution 41. The manual process using the NFC card takes significantly longer than the 10 seconds added through the inventive method using blockchain technology.

[0057] According to the present subject matter, a method and system are presented that enable the vehicle to pay for services automatically. Each of the inventive method and the inventive system provides reliable storage for vehicle data, an automated plausibility check of the consumed energy, e.g., through smart contracts, and the option of payment using the blockchain technology. In a fully automated embodiment, autonomous cars are enabled to pay for vehicle services without user interactions.

[0058] A technical feature or several technical features which has/have been disclosed with respect to a singular or several embodiments disclosed herein before, e.g., using a smart contract 6 for the vehicle service of electrically charging the vehicle 1, may be present also in another embodiment, e.g., using the same smart contract for the vehicle service of paying a parking ticket or tolls, except it is/they are specified not to be present or it is impossible for it/them to be present for technical reasons.