IT Infrastructure for Providing Energy-as-a-Service to Electric Vehicles

1. IT Infrastructure for Providing Energy-as-a-Service to Electric Vehicles Smruti R. Sarangi, Partha Dutta, and Komal Jalan IEEE TRANSACTIONS ON SMART GRID, VOL. 3, NO. 2, JUNE 2012 Prepared for SG Subgroup Meeting, UW Presented by David (Bong Jun) Choi 2012-06-07

2. Contents • Overview • System Model • Problem Formulation • Proposed System • Evaluation • Conclusion

3. Overview • Challenges • Charging and discharging a large number of PHEVs • Supply and demand should closely match • Lower supply: outage • Higher supply: waste • Intermittent source of sustainable energy sources

4. Overview • Contribution • “token”: currency of energy • gt: generation token • ct: consumption token • Attributes: ID, type, gen/con, power level, duration, start and expiration time, status • Energy = power *duration • Token entitles owner to produce or consume a certain amount of electrical energy • How to schedule tokens? • LM: Creates and Modifies tokens • TMS: “Admit and Schedule“ or “Reject” tokens Token Management System (TMS)Local Module (LM)

5. Research Objective • Goal: Maximize utilization • Utilization = total consumption / total generation • Token Utilization = total energy of the selected consTokens / total energy of the genTokens • Application-Level communication protocol

6. Problem Formulation • (1) maximizes the average utilization • = total energy of the selected consTokens / total energy of the genTokens. • (2) for every point in the activation time of a genToken, the sum of the power levels of the packed consToken instances is less than the power level of the genToken. • (3) at most one instance of each consToken is activatedto genToken (no splitting) • (4) binary decision variable for genToken being packed power time

7. Proposed Token Management System • Formulated Problem • Packing Problem  NP-Complete • Not feasible to handle a large number of PHEVs • Proposed • Heuristic algorithm • Token (1) batching, (2) prioritization, and (3) splitting • My Opinion: “Greedy algorithm based on Priority?” • Schedule based on set priority • If cannot be scheduled, split and schedule again

8. Gen-Token Queue - Prioritization -MAX_GEN_ACTIVE - Ex) FIFO, round-robin on power source, expiration times, power levels Dispatcher - Packs CT in GT - Packing depend on the scheduling scheme • Scheduling Scheme • (active genToken) • endTime • freeEnergy • - random • - utilization Cons-Token Queue - FIFO Cons-Token Batches - Based on start time and duration - MAX_BATCH_SIZE - Reduce computation load

9. Dispatcher Functions • consBatchActivation • Packing consumption batch (cb) to genToken • Conditions: • Powerlevel (consBatch) < Power Level (genToken) • + constraint (2) • Activation period (consBatch) < validity period (genToken) • Otherwise, reject • genToken Replacement • If • utility above a certain threshold • no. of rejected tokens above a certain threshold • Then • genToken replaced with a token with the highest priority

10. Dispatcher Functions • Splitting of consBatch • Previously • consBatch cannot split • i.e., One consBatch fit into one genToken • Difficult to achieve utilization close to 1 • Now • consBatch can split • i.e., different parts of consBatch fit into multiple genTokens • First, schedule consBatch as a whole. If not possible, split and schedule smaller consBatches • Proposes three different schemes

11. Splitting of ConsBatch (Scheme 1) • 1-D split on time axis • consBatch is split into two smaller batches on the time axis • ½ duration and validity period • Same power level

12. Splitting of ConsBatch (Scheme 2) • 1-D split on power axis • consBatch is split into two smaller batches on the power axis • ½ power level • Same duration and validity period

13. Splitting of ConsBatch (Scheme 3)

14. Effect of Token Splitting • Theorem • Opt (2D split) at least better than Opt (1D power split)or Opt (1D time split) • Above are at least better than Opt (no split)

15. Evaluation • Setup • Vehicles • Number: 0 ~ 7 million • Power • Trace: Australian Power Grid supply (5 years) • 10% available for PHEVs • Vehicle • Connectivity: following previous references • Capacity: 10-15 kWh • Charging Speed: 25 kW (20-30 min charging) • Token • duration(genToken) = 8 h (no frequent on/off) • duration(consToken) = 24 min • consBatch Size = 100

16. Evaluation • Effect of consToken duration • 2% best / 100% worst • Smaller fragments give better utilization

17. Evaluation Effect of Splitting Algorithm Small consTokens (5%) Effect of Splitting Algorithm Large consTokens (30%) improvement

18. Evaluation • Other results • Scheduling • Small no. of PHEVs • Deadline based prioritization performs best • Large no. of PHEVs • Power level based prioritization performs best • Large number of consTokens • Contention between consTokens for packing • Larger power helps to pack better

19. Evaluation • Other results • Validity Period • Longer consToken use duration increases utilization • More flexible start time (more slots) increases utilization

20. Conclusion • First work to propose an IT infrastructure for implementing energy-as-a-service for PHEVs • Presented token management system (TMS) for managing a large number of PHEVs • Presented several scheduling schemes • Simulation with a large number of vehicles (several million) and real supply traces