AMI Part 4 – The Internet of Things
- May 14, 2018 3:44 pm GMT
The first paper in this series, Roots, can be accessed via the link below.
The second paper in this series, Creating Demand (for AMI), can be found through the link below:
The third paper in the series, AMI Technology Basics, can be found through the link below.
This will be the fourth and last paper in this series.
Until now we have mostly focused on electric, gas and water metering and related functions. At this point we extend "related functions" to include the Internet of Things (IoT). However, this is still related to AMI networks. First of all let's look at a reasonable definition of IoT:
The Internet of Things (IoT) is the network of physical devices, vehicles, home appliances and other items embedded with electronics, software, sensors, actuators, and connectivity which enables these objects to connect and exchange data. Each thing is uniquely identifiable through its embedded computing system but is able to inter-operate within the existing Internet infrastructure.
AMI enabled meters and other devices we have looked at in prior papers are certainly members of this club. Although many assume that the IoT will use WiFi connectivity, and many applications will, I believe that some are more suited for connection through other networks. AMI networks will be candidates for these roles as the rest of this paper explores.
There are two unique features that AMI plus the Zigbee extension offer: security and low-power suitability. We will explore these in the following subsections, and finally explore potential applications for the IoT in the next section.
In researching Zigbee, it seems that "ZigBee" or "Zigbee", are both OK ways to format the name of this network. The Zigbee Alliance and most other modern sources use "b", and I believe the version with "B" was the original spelling by the developers.
Per the Zigbee Alliance, the following are features of Zigbee IP (IEEE 802.15.4-2006, Zigbee):
- Global operation in the 2.4GHz frequency band according to IEEE 802.15.4 (also uses other regional bands)
- Incorporates power saving mechanisms for all device classes
- Supports development of discovery mechanisms with full application confirmation
- Supports development of pairing mechanisms with full application confirmation
- Multiple star topology and inter-personal area network (PAN) communication
- Assigned data rate is 250 kbits/second
- Unicast and multi-cast transmission options
- Security key update mechanism
- Utilizes the industry standard AES-128-CCM security scheme. Also Zigbee IP offers extensive security features, including PANA/EAP based network authentication and admission control, network re-keying, AES-128-CCM based layer 2 encryption, and TLS application layer authentication and encryption.
- Supports Alliance standards or manufacturer specific innovations
The three unique features in the above list are:
- Low power operation
- Has mechanisms for discovery and pairing of new devices
- Reasonably secure (AES-128-CCM is the primary authenticated encryption algorithm, and is designed to provide both authentication and confidentiality. CCM mode is only defined for block ciphers with a block length of 128 bits).
Most AMI networks use TCP/IP (Internet Protocol) to the meter, then the meter has a secondary module that allows IP communication via Zigbee with IoT devices in or near the metered facility.
I would guess that not all meters in a given AMI system would be equipped for Zigbee. Thus the process required for a given IoT vendor to use a given system for two-way communication from devices in/near facilities to the cloud might be:
- Identify the owner of the AMI system
- Approach the owner and define:
- What meters are equipped for Zigbee communication
- The cost for meter replacements
- Service cost for using this network
- Data-types to be sent through the AMI network
Given the probable expense of meter replacement (and coordinating the above process), this would probably only be viable if a critical-mass of applications for a given service area is implemented. Also consider that Zigbee routers are available from Amazon (et al) for as little as $40.
In gaining the above "critical mass", involvement in a project with a local electric utility partnership would definitely help. Even in cases where the electric utility is not the "owner" of the AMI network, they are definitely the primary user, and would strongly influence the cost and contractual terms for any meter exchange.
In the last section (3) of the last paper in the series (Part 3 – Technology Basics) linked above, we reviewed the functions that might be implemented through an AMI network. In subsections 3.1 and 3.2 we covered metering-related and energy-related functions in residences. Although these would probably be at the top of the list in a partnership with an electric utility, we do not need to limit ourselves to these. In the next section below we will review applications that were not covered in the last paper's referenced subsections.
3.Candidate IoT Applications
The applications below are in no particular order.
Healthcare devices in facilities other than health-care (like in residences). Most healthcare facilities already have wireless LANs that meet their requirements. Devices in other facilities would periodically upload data, provide a frequent confirmation signal ("I'm here and operating normally") and would send immediate notification of any urgent events. Thus they could live with the data limits of Zigbee. Many of these devices will be battery powered and thus they will benefit from Zigbee's low-power capabilities.
Security devices in residences and businesses, to include intrusion detection, threat notification, fire alarms and alarms for other life-safety threats. These devices would send a periodic confirmation and notification of urgent events. They would benefit from the low-power capabilities.
Fixed EV Chargers (EVSE) in commercial facilities or residences will need to communicate with the cloud for financial transactions (commercial only), diagnostics and power management.
Smart appliances such as refrigerators, washers, clothes dryers, and HVAC (heating, ventilation and air conditioning) systems. Major appliances could have value-added by linking them to the manufacturer's cloud, adding inexpensive sensors to monitor their operation, and offering extended and/or more-inclusive warranties.
Alert/information devices that might be used for severe weather, industrial air pollution (for facilities near refineries and chemical plants) wildfire, or other health/safety threats.
Industrial devices/sensors that are widely distributed could be provided with communication by a Zigbee network. These could include outer "property-line" boundary security sensors that would be powered by small solar + storage modules.
Speaking of security, everyone is aware that deviations wrought by climate-change have substantially increased the frequency and severity of wildfires in the west. The following devices (which might communicate using WANs or NANs) could greatly help in their mitigation.
- Wild-fire detection devices: There would be two types: (1) specialized smoke detectors and (2) hill-top infrared heat detectors.
- Weather detection devices (wind-speed/direction): These would be low-cost devices mounted on top of power-poles, light standards, etc. They would help provide data for evaluating the inputs from the above smoke-detectors (and assist in fire-fighting). They might also provide higher-resolution data for local weather forecasts.
No discussions yet. Start a discussion below.
Get Published - Build a Following
The Energy Central Power Industry Network is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.
If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.