Archive for the ‘Node controller’ Category

Home automation network (HAN)

Thursday, June 4th, 2009

A basic overview of HAN architecture for AMI

The push for more consumer involvement in smart grid initiatives is slowly becoming more evident as companies and utilities attempt to grasp the overall impact of government mandated deployments of the smart meter. Understanding what the consumer needs and wants is quickly rising in importance with the goals and objectives of the energy industry.

There are various views and opinions as to how the US federal and state mandate translates to practical solutions. Primary as a viable solution is the deployment of smart meter technology. But not all smart meters are the same, hence the need for a more encompassing option. The complicated field of metering with its canopy of applicable hardware and software results in making intelligent decisions a difficult and rocky road for AMI proponents. Some have focused instead on defining what a smart meter is or isn’t. The resulting business models may or may not be implementable as technology changes the landscape or costly if human behavior fails to adjust to and embrace the deployed solution.

One thing is certain, that a smart meter without interaction from the occupants would diminish the gain in energy use reduction and jeopardize the utilities’ attempts at conservation and global warming compliance.

If the solution isn’t found through meter deployments, then it stands to reason that involving the consumer via technology and education makes sound business and good social sense.

This brings us to the need for a home automation network (HAN) – either a simple system or a complex one. Many envision the HAN with the smart meter as the center or focal point for data gathering and exchanging. The smart meter is the gateway through which the rest of the world garners information about the occupant’s electricity consumption. Others would rather have an independent gateway within the premise that is more controlled by the occupants with privileges allocated to the utilities or an AMI service company. The meter then would be just another peripheral device in the network that links the local network with the outside utilities. The internal home gateway would restrict and determine what information is available to external sources. The former is more in line with what the utilities are implementing while the latter favors the telecom, cable, and IT industry approach, which focuses on broadband home networks and less on low power mesh.

Planning a HAN in an uncertain market that is constantly changing and evolving can be daunting to any individual or company considering AMI deployments. Most seek simple solutions that require very little capital or are constrained to limited HAN implementation. Deploying programmable communicating thermostats (PCTs) is one way of semi-automating the home environment for demand response. Using in-home displays that link the external meter to a remote handheld or tabletop unit is another. Whatever the technology used, these early approaches to consumer involvement demonstrate a growing awareness for HAN planning and consideration.

Critical to planning any future HAN system is the communications architecture being considered. The current emphasis on mesh radio technology and the availability of completely different mesh protocols (ZigBee, Z-Wave, OpenRF, and so on) within each of these radio systems creates both opportunity and potential disaster when considering HAN development and deployment. Other networked communications architectures include power line modems, Ethernet, Wi-Fi, Bluetooth, and RS485 – all which add layers of complexity to deploying HAN technology. Coupled to this melee of competing options is the dearth of home networked products that provide meaningful and practical demand response solutions.

Making the right choice of communications backbone may well be defined in the legacy system requirements, the data requirements, the environment in which the HAN is located and how the HAN is to be used by the occupants. Cost and ease of deployment/implementation along with the level of after sales support required are considerations that impact a successful planned launch. Whatever choice is made, the decision to go with one or the other could also limit the availability of peripheral devices that can operate within that chosen communications architecture and by default the functions and features available to the consumer. So choosing wisely is paramount.

The correct solution to determining a HAN configuration is the “backwards” approach. Simply put, deciding what end result the network must accomplish and then determining which technology is best suited to do this. In most instances, a cost analysis report or a business case based on reliable information would suffice in evaluating the technology being considered. In other situations where the technology is not proven or the decision makers are not knowledgeable, a trial or test site may be necessary to familiarize everyone with the option.

As mentioned earlier, the market forces driving HAN development and deployment are directly related to the industry and its perspective of market need. Other drivers such as political and global issues also impact consumer anxiety and perception within the market. Hence developing a strategy for HAN architecture must take into consideration those drivers.

A typical HAN may consist of the following basic functional components:

  1. Node controller/gateway/central controller. A node controller is common within mesh networks for maintaining the communications link and exchanges necessary within the protocol. It may or may not be the gateway. The gateway, on the other hand, is the portal through which multiple conflicting protocols link and talk seamlessly. A central controller can be all three plus a data manger/data logger. It manages the network from a user perspective (such as a home computer or a home media server which can act as the controller).
  2. Peripheral devices. The fingers and hands of the HAN are seen in the sensor devices that gather information or provide levels of control. Such devices, such as a PCT, provide a measure of remote command and control to the premise HVAC system. Internal to these devices is the communications backbone which links the devices to the central element of the network.
  3. Software. There are myriad functions that must be accomplished for a HAN to successfully fulfill its intended design. For example, the mesh protocol software manages the mesh network communications within a low power radio configuration. At the gateway, the different protocols must be translated correctly and the data sent to the correct recipient. Throughout the network, some form of security must be employed – whether through software encryption or access denial methodologies. There is a large amount of embedded code within the peripherals that program the tasks associated with those devices. These command and control codes must be incorporated into a central controller which provides remote interaction with the sensing devices.

External to the HAN is the smart meter which may be the gateway to the utility. The smart meter may also just be a peripheral if the HAN has its own dedicated gateway. A smart meter that is very basic or uses wired access may need a HAN that incorporates a gateway. Shifting the gateway away from the meter may be a better cost solution or a strategic decision based on any number of factors. When deciding on the HAN to meter interfacing, these type decisions need to be considered.

HAN basic

A basic HAN (wired and/or wireless)