Download IT Infrastructure for Providing Energy-as-a

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
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
Token Management System (TMS)
Local Module (LM)
• 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
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
power
time
▫ = 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 activated to
genToken (no splitting)
• (4) binary decision variable for
genToken being packed
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
Dispatcher
- Packs CT in GT
- Packing depend on the
scheduling scheme
Scheduling Scheme
(active genToken)
- endTime
- freeEnergy
- random
- utilization
Gen-Token Queue
- Prioritization
-MAX_GEN_ACTIVE
- Ex) FIFO, round-robin
on power source,
expiration times, power
levels
Cons-Token Queue
- FIFO
Cons-Token Batches
- Based on start time
and duration
- MAX_BATCH_SIZE
- Reduce computation
load
9
Dispatcher Functions
• consBatch Activation
▫ Packing consumption batch (cb) to genToken
▫ Conditions:
 Power level (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%)
improvement
Effect of Splitting Algorithm
Large consTokens (30%)
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