html5-img
1 / 13

UtilityAMI HAN Task Force

UtilityAMI HAN Task Force. May 10, 2007. Agenda. SCE Contribution on HAN Vision Technology Discussion Identify TF Deliverables. Technology Summary. None of the technologies have standardized application layer information models – must be developed

kathygray
Télécharger la présentation

UtilityAMI HAN Task Force

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UtilityAMI HAN Task Force May 10, 2007

  2. Agenda • SCE Contribution on HAN Vision • Technology Discussion • Identify TF Deliverables

  3. Technology Summary • None of the technologies have standardized application layer information models – must be developed • PLC ruled out as sole interface due to need to reach thermostat and other devices not reachable by PLC (e.g. gas meter) • All ISM band based devices subject to interference • Testing and applications in home environments confirm ability of MAC and application layers to effectively mitigate interference between ZigBee and WiFi

  4. Interference Concerns in Unlicensed 2.4 GHz Band • WiFi and ZigBee share that same frequency range, their transmissions can collide and cause interference • Interference issues arise in any unlicensed band where any number of proprietary solutions (cordless phones, meter reading systems, proprietary control systems, etc.) exist. • Both WiFi and ZigBee protocols are by design intended to share the channel among multiple users (vs. constant transmission), collisions do no always occur and may occur only infrequently • Both WiFi and ZigBee support multiple channels (one of which has no overlap at all) which further facilitates interference management • Both protocols by design effectively accommodate collision events to deliver reliable network operation. • Significant anecdotal data supports ability of WiFi and ZigBee to co-exist (e.g. Control 4 products with both protocols in same home environment device, Ember test facility)

  5. ZigBee Specific Test Results • The interference effect at the PHY layer, when there is 100% guaranteed (worse case) packet collision between WLAN and ZigBee packets, can reduce the effective range of the ZigBee packet transmission, sometimes dramatically, but does not completely impair the ZigBee link. Of course, when the packets do not collide, there is no interference effect at all. • As would be expected, the effect of packet collisions is strongest when the operating channels directly overlap, and is still present for nearby channels, though the effect is reduced. Interference effects can be avoided altogether on non-overlapping channels. • The 802.15.4 / ZigBee MAC layer detection and retry mechanisms are able to mitigate the interference effects of any WLAN/ZigBee packet collisions. . • An increase in ZigBee network latency due to extensive MAC-layer retry activity was only seen under very high WLAN interference scenarios. While increased latency and lower throughput could be measured in these scenarios, overall network reliability was not impacted.

  6. ZigBee Specific Test Results • Of the WLAN scenarios tested, including use of 802.11b and g, multimedia streaming, and large file FTP transfers, the worst case interference occurs with large FTP transfers over 802.11b. This scenario creates the greatest chance of packet collisions. • The use of the higher-speed 802.11g actually causes significantly fewer interference effects due to the shorter packet “on-air” time compared with lower speed (/b) WLANs. Similar results can be expected for 802.11n. • ZigBee network capacity between two nodes in a network may be significantly reduced in high-interference scenarios, however the reduced capacity still exceeds even the link capacity of Z-Wave networks. • The use of NWK layer retries, a ZigBee-compliant option available in some ZigBee stacks, can have a positive effect on overall ZigBee network capacity and reliability in the face of worst-case interference.

  7. Adverse Scenario Mitigation • The following adverse scenarios were evaluated • Interface technology versions quickly • Interface technology becomes obsolete in general marketplace • Interface technology becomes compromised due to increasing interference • Interface technology becomes compromised from a security perspective • Mitigation • Firmware upgrade capability handles scenario 1 • Market power could facilitate long term support by third parties of a specific version freeze and mitigate scenarios 1 and 2 (discussed at UtilityAMI HAN meeting) • Adding a utility or third party provided gateway mitigates scenario 2 • The ability to remotely disable the meter interface and utilize third party networks and gateways mitigates scenarios 3 and 4

  8. Going Forward • Select best wireless technology to support utility applications over at least a 5 year time horizon – ZigBee is the leading candidate • Consider possibility of PLC interface in meter gateway in addition to wireless – supports concept of keeping simply, slower to change technologies on the utility side of the interface. Decision must be made soon and there is a cost impact. • Plan to support information exchange (1 way – e.g. digital KYZ) with third party in home gateways through published information models • Ensure back office architecture can support third party communication channels and gateways to implement load control use cases in event of meter gateway interface technology obsolescence • Ensure that cost of meter gateway interface technology is minimal so that stranding it does not adversely impact overall business value (similar to RDS in thermostat)

  9. TF Deliverables • Use Cases • RF reach scenarios • High rise scenario • User scenarios • Customer moving from one utility to another? • Common Requirements • To give vendors guidance • For other organizations to develop details • Derivative work from UtilityAMI requirements • Overarching Framework / Architecture

  10. Use Cases • AMI System communicates with Customer devices securely • Load control - PCT • Customer display • Other devices • Definitions – use terminology that does not specify a device where the interface function exists – use UtilityAMI name – Home Area Network Gateway

  11. Use Cases • Should ensure we focus on logical functional definitions – and not devices • Actors • AMI System • Includes meter, collectors, • Meter data source? • Utility Home Area Network Gateway • Utility HAN versus Customer HAN • Customer Home Area network Gateway • Loads • Communicating • Energy Management System – e.g. HomeSeer • Display devices • Human user • Back office – represents source of pricing signals and other info • Bad actor – for security assessment

  12. Use Cases • SCE and SDG&E will submit use cases • User to display device interaction scenario – C2, C3 • Prepay, service request/info, usage display • AMI system to EMS scenario • Reliability response scenario – D1 • No opt-in / opt-out • Price response scenario – C1 • Opt-in / opt-out – California -> must be part of a program • Override button scenario • HAN management – Derivation of I2 – and Title24 • Device provisioning - – initial and update • Security credential establishment • Heartbeat, Diagnostics • Firmware upgrade – I1 • New piece for HAN • Customer HAN evolution management • Customer generation scenarios • Net metering, EV interface, PV, etc. – V2G • Security threat scenarios – Title 24 work

  13. Process • 1 week to contribute • 1 week to review and comment • 2 weeks to synthesize the contributions into something we can vote on

More Related