Archive for the ‘Lonworks’ Category

LonWorks® 2.0 – A complete platform for smart controls

Wednesday, March 24th, 2010

Echelon has dramatically improved its pioneering LonWorks platform. LonWorks® 2.0 is a complete platform that lets OEM product manufacturers and system integrators create and implement controls and smart energy management solutions.

  • Faster, smaller and more cost-effective
  • Add LonWorks networks to more devices
  • No credit fee = lower solutions costsCreate more powerful and flexible devices

LonWorks 2.0 Replaces RS485 Technology
With the introduction of the new LonWorks 2.0 FT 5000 Smart Transceiver, manufacturers can get nearly a four-fold increase in processing power and through put at half the cost of previous designs – eliminating the cost advantages of RS485 base designs. The LonWorks technology extends its superior technological foundation over RS485 based designs while making the installation more robust, field safe and easy.

The Future: Smart networking, LonWorks, the IP network, and open source computing are going to drive a different world

Wednesday, June 24th, 2009


At Apple co-founder Mike Markulla’s Venetian Hotel-styled private theater in this posh Palo Alto suburb, the chairman of Sun Microsystems, makers of Java, and CEO of Duke Energy, makers of 36,000 megawatts of electricity in coal and nuclear plants, shared the stage.

The CEOs found common ground pushing a vision of the future where light switches are superfluous and any device that uses power is networked, easily automated, and far more energy efficient. Holding up a standard Sun identification card, Sun Chairman of the Board Scott McNealy noted that it was faster than an Apple II computer.

“We can connect anything that is more than a dollar in value,” he said.

But McNealy’s declaration that he was “over” the network was the real highlight of the hour-long event to celebrate the twentieth anniversary of Markulla’s post-Apple endeavor, Echelon, which makes sensors and controls for all types of devices.

“I want my stuff to be on the network”   said McNealy.

Coming from the CEO of a company that once had the tagline, “The network is the computer,” the comment drew laughs from the small crowd. McNealy admitted that his statement probably was “not the best marketing thing.”


Beyond his glib distaste for social networking, McNealy and Jim Rogers, Duke Energy’s CEO, presented a serious case that the future of networking lies with your toaster, lights and curtains. By turning “dumb” devices into nodes on a smart network, the businessmen said that the entire economy could be restructured to use energy more efficiently.

“I believe the most energy efficient economy is going to be the one that provides the greatest standard of living for its people,” Rogers said.

Rogers also noted that utilities would have to redefine their businesses away from commodity power and start making money by helping their customers control, not just use, their electricity.

“I see embedded in every customer six to eight networks and on each network there’s three to five applications,” he said. “What if I create value by optimizing those networks and those applications?”

That’s a major change in thinking for utilities that previously considered their job finished when the electricity hit your meter.

Though they painted grand visions of what the future could hold, both executives said there were many challenges to be met in creating the network of things.

“There’s a lot of work to be done,” McNealy said. “There’s a lot of work to take the complexity out of client devices and to take the cost out of client devices.”


Cost and complexity have slowed the adoption of home automation systems, but all three companies clearly see an opportunity to capitalize on the high cost of energy and increasing concern over carbon emissions.

McNealy even dropped Echelon’s protocol LonWorks into his solution for the future.

LonWorks, the IP network, and open source computing are going to drive a different world where per capita energy usage can plummet as green becomes the new black”, he said “And I mean black in terms of making money.”

Rogers’ vision was equally amibitious and showed that the North Carolina-based CEO knew his big-thinking Silicon Valley audience.

“At the end of the day, what I’m gonna provide is universal access to energy efficiency the way we provided universal access to electricity in the last century.”

Images: Jim Merithew. Top: Scott McNealy speaks to the crowd. Middle: The crowd is bathed in green LED light during a demo of the room’s fancy lighting system. Bottom: Duke Energy CEO Jim Rogers lays out his plan for the future of a smarter electrical grid.

Myths of LonWorks™ and BACnet™

Saturday, June 13th, 2009

Building owners and facility managers have long awaited the means to break the proprietary lock of the building control manufacturers. BACnet and LonWorks are two protocols that are competing to be the key that unlocks the lock.

Not everyone is enthusiastic about LonWorks and BACnet. There are some who want one to win at the expense of the other, and there are a few who are still hoping against hope that both will somehow disappear. So, amidst the hype and the claims there is also accusation and confusion.

 “First they ignore you, then they ridicule you, then they fight you, then you win.”

  —  Mahatma Gandh

This article represents a view of what is real and what is not.

Myth #1: It’s a duel to the death – only one will be left standing.

Not so. This myth often cites as supporting evidence the Betamax vs VHS knockout that occurred. But the comparison is flawed because Betamax and VHS were mutually exclusive products, whereas BACnet and LonWorks products can interoperate in the same system.

LonWorks and BACnet are competitors, yes; but they both have a place in the industry, and they both have a critical mass of customers.

There are even some building control manufacturers who are purposefully designing their product lines with a hybrid of BACnet and LonWorks as their standard offering.

Consider the four configurations below.

A. The legacy proprietary system
This is a design from yesterday with an attempt to adapt to the industry standard, but not adopt it.
This system is still proprietary, and over time will fade from the scene, or will be relegated to speciality niche market applications where interoperability is not an issue.

B. Lonworks system with gateway to LAN networks to PC workstation to the BACNet link

Configuration B is maybe better, maybe worse. It seems to have been dreamed up by a marketing department.

It allows the marketeers to claim “we have adopted LonWorks to allow you, the customer, to mix and match different manufacturer’s components.”

Sounds good, but what is left unsaid is that the customer is still not free to mix and match different manufacturer’s systems. In other words, if the customer wants to contract for an addition to an existing system, he can only entertain a bid from a competitor if he agrees to use the original supplier’s proprietary workstation, and agrees to pay the original supplier’s price to reconfigure it for the new addition.

Lets consider this arrangement, with the original supplier’s proprietary grip still in place …thanks a lot!

C. Lonworks network, LON conponents controlled via  LON controllers, talking through a gateway direct to a BACNets network and components.

Configuration C begins to address the needs of the customer. The customer can now interoperate different manufacturer’s systems without being locked into a particular supplier, and can mix and match different supplier’s components (although at the component level, it may not be as cost effective as it sounds).

D. Lonworks network, LON conponents controlled via  LON controllers, talking through a gateway direct to a BACNets network and controllers and components.

Configuration D also addresses the needs of the customer. The customer can interoperate different systems, and can mix and match components (again, it may not be cost effective at the component level).

Why would some manufacturers choose configuration C, while others choose D?
There are as many reasons as there are engineers designing them, but from the customer’s point of view, it probably matters little.

So, LonWorks is not going away because some manufacturers are designing LonWorks components into their product line, and it is very costly to change later on. BACnet is not going away because it is the protocol of choice at the system level – A number of top building control manufacturers have chosen LonWorks for this purpose, but they don’t want to you to know that its based on Lonwork system. If they are embracing interoperability, as in configurations C or D, they are choosing BACnet to do it.

Myth #2: It’s a lovefest – they are working together in perfect harmony.
No, it is not a lovefest – they are competitors, remember? Yes, they are both chasing the same goal, interoperability.
But within each group there are a few who still believe in Myth #1, and want their side to win. Pointed jabs in the ads and hype are not uncommon.

The vast majority of the members of the LonMark and BACnet groups, however, see the fallacy of Myth #1, and understand the need for both groups to work together. A working relationship exists today between the two groups, and it is getting better as the reality sets in.

Myth #3: One is expensive, the other is affordable.
Claims for cost effectiveness abound, but the bottom line is there is no significant difference in the cost of manufacturing controls based on a proprietary protocol, the LonWorks protocol, or the BACnet protocol. If
there is a difference, it will be lost as a rounding error on bid day.

If cost is the primary criterion, compare the life cycle cost of configurations C and D versus configurations A and B. That’s where the big bucks are.

Myth #4: One is complicated, the other is simple.
Here we go again. Some folks spend their time on this type of argument because they still believe in Myth #1.
LonWorks and BACnet are both like an Internet browser – they are complicated if you want to know how they work; they are simple if you want to know how to use them.

Myth #5: Specifying either one is a nightmare.
Sure, if you are trying to force a controls manufacturer to interoperate with a competitor through the specification process, when the manufacturer is not committed (or when they are covertly opposed to it), then it is indeed very, very difficult and will likely result in a nightmare. On the other hand, if a controls manufacturer is committed to interoperability, and some are, then the specification process is simpler than it has ever been.

If you want interoperability, first spend your time determining which controls manufacturers are committed and which ones are not. Then, use the specification process to spell out your performance and functional requirements.

It works.

Lonworks – Control Network for Building Automation

Saturday, June 13th, 2009

 An introduction to Lonworks

Lonworks networks really describe a complete solution to the problem of control systems. Like the computer industry, the control industry was, and in many cases is, creating centralized control solutions based on point-to-point wiring and hierarchical logic systems. This meant that you had a “master” controller, like a computer or programmable logic controller, physically wired to individual control, monitoring and sensing points, or “slaves.” The net result worked, but was expensive and difficult to maintain, expand, and service. It was also very expensive to install.

Lonworks networks started out with some very simple notions – control systems are fundamentally the same regardless of application; a networked control system is significantly more powerful, flexible, and scaleable than a non-networked control system; and businesses can save and make more money building control networks over the long term than they can with non-networked control systems.

Where and how is Lonworks used?
Lonworks networks can be found in all key building automation sub-systems including heating, ventilating, and air conditioning, lighting, boilers, air handlers, security, elevators, fire detection, access control, energy monitoring, irrigation control, and window blinds. In factories, Lonworks technology can be found performing a multitude of industrial tasks — from running wastewater treatment plants to checking paint colors to monitoring the arrival of parts at assembly stations. Lonworks is supported by Echelon.


LonMark is a proprietary protocol developed by the Echelon Corporation in conjunction with Motorola in the early 1990s. The LonMark standard is based on the proprietary communications protocol called LonTalk. The LonTalk protocol establishes a set of rules to manage communications within a network of cooperating devices. To simplify implementation of the protocol, Echelon chose to work with Motorola to develop a specialized communications microprocessor called the Neuron. Through the use of this chip and its supporting software, the protocol establishes how information is exchanged between devices. Because much of the communications protocol is contained on the chip, system designers and installers can focus on other aspects of the system.

While LonTalk addresses the issue of how devices communicate, it does not consider the content of the communication. A second protocol, known as LonWorks, defines the content and structure of the information that is exchanged. LonWorks is a distributed control system that operates on a peer-to-peer basis, meaning any device can communicate with any other device on the network or use a master-slave configuration to communicate between intelligent devices. The LonWorks platform supports a wide range of communications media.

LonWorks-compatible devices communicate with each other through what is known as a Standard Network Variable Type or SNVT. While a SNVT defines a device just as an object does for BACnet, its approach is somewhat different. For a SNVT to function, both the sending and the receiving devices must have detailed knowledge of what the SNVT structure is. Therefore each SNVT is identified by a code number that allows the receiving device to properly interpret the transmitting data.

Initially, LonWorks did not define what a particular SNVT code meant. This resulted in confusion between vendors who used the same code to mean different things. To eliminate the confusion and to standardize SNVT codes, the LonMark Interoperability Association was formed in 1994. Made up of hundreds of manufacturers and integrators, one of its primary goals was to lay out standard methods for implementing the LonWorks technology.

To ensure that any device installed in a LonMark system will work properly with other devices, LonMark requires that in order to carry the LonMark logo, products must have been verified to conform to the LonMark protocol. LonMark uses a Web-based tool to reduce the time and cost for certifying devices.

One of the more recent innovations made by LonMark is the network profile. The idea behind the network profile is that no matter who makes a particular device used in a building system, such as a variable speed drive, all like devices will perform a similar function. To ease and speed system installation, LonMark then defines how a particular device should function on the network, from the points included to how they are named. This predefined network profile is the minimum profile for any connected devices. Manufacturers can add additional items to the predefined profile based on their particular product, giving them flexibility while maintaining simplicity and interoperability.

LonWorks has been accepted and adopted by the international standards organizations (ANSI/CEA 709.1 and IEEE 1473-L).

The Convergence of Building Controls, IT (IIT)

Friday, June 12th, 2009

Varying perspectives of usefulness of increasingly common practices

For more than a decade, many in the buildings industry have been envisioning a day when building-automation systems (BAS) would become fully integrated with communication and human-interface practices and standards widely employed for information-technology (IT) networks. With the number of those individuals growing and their dream coming closer to reality, five-question survey with the intent of gathering the varying perspectives of a control-system designer, a controls manufacturer, a controls integrator, and an advanced controls user on practices becoming increasingly common in development BAS.

The Survey Participants

A senior partner of New York-based Lehr Consultants International and a member of HPAC Engineering‘s Editorial Advisory Board, Valentine A. Lehr, PE, FASHRAE, is noted for innovation in high-rise construction, hotel design, and master planning of complex projects. He has led design efforts for numerous award-winning environmental projects.

The vice president of sales and marketing for Reliable Controls Corp., the Victoria, British Columbia-based designer and manufacturer of Internet-connected building controls and green building-automation controls, Tom Zaban, P.Eng., has a degree in mechanical engineering from the University of Waterloo and a family-business background in electronics manufacturing.

As the vice president of sales and marketing for Delta Controls Inc., the Surrey, British Columbia-based developer and manufacturer of building-automation systems, Brian Dutt is responsible for the company’s product-strategy, marketing-services, and global-sales teams. He has an MBA from Simon Fraser University and a diploma of technology in electronic engineering.

H. Michael Newman manages the energy-management-and-control system at Cornell University in Ithaca, N.Y. The system extends to some 150 major buildings, includes equipment and communication protocols from more than 10 suppliers, and incorporates several thousand field devices and hundreds of thousands of sensors, actuators, and data points.

Following are the questions and the responses they elicited.

1. In this age of universal graphical user interfaces (GUI), is there any reason to continue using a BAS manufacturer’s graphics instead of Web-browser-type operator interfaces?

“In general, no,” the survey’s designer participant, Valentine A. Lehr, PE, FASHRAE, a senior partner of New York-based Lehr Consultants International and a member of HPAC Engineering‘s Editorial Advisory Board, said.“There is no reason for the manufacturer’s graphics.”

The survey’s advanced-user participant, H. Michael Newman, manager of the Utilities Computer Section at Cornell University in Ithaca, N.Y., agreed: “If by ‘manufacturer’s graphics’ you mean a client GUI application used for the run-time operation of a BAS that must be installed and maintained on every potential workstation, as opposed to an application used for BAS setup, configuration, or commissioning, then the answer clearly is no. The software tools available to GUI designers for BAS, such as JavaScript and other scripting languages, supplement HTML (HyperText Markup Language) display technology to permit controls, such as buttons, scroll bars, sliders, and other user-input devices, to be displayed and actuated, thus, allowing operators to interact with the BAS through a Web browser with nearly the same look and feel of traditional client GUI.”

One should not be so quick to dismiss the value of manufacturers’ graphics, the survey’s manufacturer participant, Tom Zaban, P.Eng., vice president of sales and marketing for Reliable Controls Corp., said.

“Just because browser-based technology is ubiquitous does not mean that content (i.e., graphics) no longer is needed …, Zaban said. “The more people go online, the higher their expectation for quality information becomes.”

As the survey’s controls-integrator participant, Brian Dutt, vice president of sales and marketing for Delta Controls Inc., explained: “Manufacturers often create higher-quality interfaces for use with their products. It is quite simple for a manufacturer to create additional properties and functionality within their controllers that go beyond those defined by open standards. This added functionality … is available to the end user only when utilizing the manufacturer’s software interface.”

One could argue, Zaban said, that: “Theoretically, there are enough image assets on the Web to make any manufacturer’s library redundant …, and maybe in time that could become true, but good luck. Try putting that into practice today. You would have to cope with the lack of images and the inconsistency in colour, texture, camera angle, and resolution — all necessary to deliver a professional-looking end product. I would expect for the time you would spend piecing together a functional public-domain library you could hire a team of pimply faced kids to make a new library from scratch and do it cheaper with a better result. Then, you will need the animations. Forget it — game over.

“There is an intimate tie-in to each manufacturer’s product and the behavior of any animation of modest complexity,” Zaban continued. “The frames of the animation are ‘coded’ to behave according to the bits set within the object, which, in turn, are based on values/states measured and/or calculated by the controller or derived by direct operator input. There is no consistent standard in the industry describing that relationship that I am aware of. … The nature of animations is just too creative to nail down to a standard that would cover a wide variety of cases.”

Summary. There seems to be agreement among the survey participants that the industry is moving toward browser-based graphics. Because such graphics require special objects and support features developed by direct digital control (DDC) system manufacturers, the creation of generic graphics is seen as expensive.

2. Is there a good reason not to consider using multiple vendors’ products in a single system?

“There are several reasons to avoid mixing and matching, although the technical barriers essentially have been eliminated in recent years through the development and widespread adoption of standard networking protocols …,” advanced user Newman, who chaired the American Society of Heating, Refrigerating and Air-Conditioning Engineers’ BACnet committee from 1987 to 2000, said. “The most significant impediment would be the need to become proficient with the configuration, programming, commissioning, operation, and maintenance of equipment from different manufacturers. This involves training, documentation, the need to have spare parts for each system, and so on.”

That does more than increase cost, controls integrator Dutt said.

“Developing intimate knowledge of a single manufacturer’s product is spread across multiple individuals within a value-added reseller’s (VAR’s) technical team,” Dutt said. “If the VAR chooses to support multiple manufacturers, it typically will develop knowledge specialists for each product family. This increases the risk to the organization should the specialist choose to leave the organization. It also causes risk to the service and support of the project longer term.”

Varying perspectives of usefulness of increasingly common practices

In the absence of operation-and-maintenance personnel with the requisite level of knowledge and skill, “You would need to be sure that you have the necessary support from the different suppliers to avoid finger-pointing in the event the systems don’t cooperate as expected and required,” Newman said.

Summary. Despite improved capabilities for developing multivendor networks, the survey participants urge caution.

3. Is it practical to remove GUI development from a controls contract and employ someone who specializes in developing GUI using standard server-based tools?

“Yes, that is the preferred approach …,” designer Lehr said. “We are using it on larger projects.”

Controls integrator Dutt sees it as practical only in situations in which an owner is seeking competitive bids.

“If the owner is happy with the current solution they have, then it is better to leave the interface and controls to be supplied from a single vendor,” Dutt said. “In my experience, most building managers are looking to work with controls contractors they can trust to do a good job.”

Manufacturer Zaban said he can think of only one case in which it would be practical: “A university has multiple vendors supplying various automation systems to its campus. The contracts call for basic graphics to be created and commissioned. Then, after the job is done, the university retains a different company that re-uses the graphic annotations of the base contract, but slides in a completely new graphic and gussies things up using the tools of that specific vendor so that the final graphics are very consistent with all of the previously completed buildings on campus. The university gets the value it wanted in the graphic (a relatively intuitive collection of dynamic data on one screen), but tosses out the base image because it is not worth the money and time fighting the original contractor because they used the wrong shade of gray.”

The tools used to create the content of interactive Web-accessible displays are almost entirely manufacturer-specific, advanced user Newman said.

“Some suppliers use commonly available software, such as Microsoft Visio, (Lonworks) to develop their system graphics, while others use entirely proprietary applications,” Newman said. “Even if the format of the graphic is ‘standard,’ the display of real-time data, archival trend data, or other database information requires manufacturer-specific ‘callback’ routines to collect the data and present it to the server. If, as is common, the graphic is stored in a proprietary format, it is the job of the manufacturer’s server to interpret the graphic file, render it into Web-displayable form, and ship it to the browser. All of this is not to say that there are not contractors who are competent with vendor XYZ’s GUI-development tools. If your server is from XYZ, you certainly do have the option of hiring a third-party contractor to develop or extend the GUI.”

Summary. The survey participants have mixed opinions as to whether it is preferable to have the manufacturer supplying the controls for a project also provide the graphics because proprietary display-development tools will have to be employed no matter how a graphical interface is procured. The opinion appears to be that there is rough equivalency among the capabilities of various manufacturers’ graphics software.

4. How far down into control-system architecture should designers push to replace specialized HVAC control components with more-standard general-purpose IT products?

“There is some argument to say the marketplace should determine this issue,” designer Lehr said. “However, in response to the question, if pushed, it should be down to the router (Ethernet) level.”

Because of current building practices, replacing specialized HVAC components with more-standard general-purpose IT products is practical only to the building-controller level, controls integrator Dutt said.

“Most application controllers are required to be commissioned before the end of a project,” Dutt explained. “This makes it difficult to cost-effectively deploy IT-based controls at the application level. If the owner of the project is a stakeholder in the IT-based solution, then it is possible, but it will take a significant amount of effort to ensure the design survives the construction phase. Currently, it is cost-effective to deploy IT networks to the building-controller level, as this network typically can be installed during construction and can be used during system commissioning.”

Manufacturer Zaban believes: “We’re already ‘all the way down’ from an architecture perspective. … Most designers just don’t know it yet.

“Now that we have a decent standard open protocol — ‘decent’ meaning well-defined, popular, and, most importantly, extensible — we can go ahead and write BIM (building information modelling) algorithms that would fully specify all aspects of building controls,” Zaban explained. “That means controller profile, network, sequence, interoperability, database, alarm, commissioning, wiring, documentation, service information, and even part numbers.”

A BIM BAS model is a “pet project” Zaban said he has been “threatening to do … just to shake up the industry a bit. …

Varying perspectives of usefulness of increasingly common practices

“It would represent the Holy Grail of DDC implementation …,” Zaban said. “It also would put a lot of frustrated consultants out of their misery because it would minimize their exposure to the technology. … The means already is there; you don’t need to ‘push’ any further. … We have general programmable controllers that can be applied to highly specialized applications, and the protocol provides deep integration into IT models.”

Summary. It appears there are no restrictions as to where a BAS network can be connected to a larger building or campus IT network. Indeed, on some projects, a stand-alone BAS network is connected to an IT network for local- and remote-operator oversight, while on others, components down to terminal-unit controllers are connected directly to a standard IT network. How a BAS network is configured in association with an IT network largely is determined by physical access, bandwidth, and network integrity/responsibility.

5. Should designers promote Web-enabled access for multiple buildings?

“Yes, this is an excellent approach …,” designer Lehr said. “The only limitation is reluctance to add cost.”

In the building-management industry, an increasing number of people are being asked to do more with less, manufacturer Zaban said.

“For example, one health-care manager I know who is doing a great job at tracking his facilities’ energy performance is facing a significant expansion of the hospital, but there is no budget to hire additional resources to keep up with the additional paperwork,” Zaban said. “Another property manager I know who is responsible for several large properties in downtown Vancouver is happy his company is growing. But they just acquired a new significant property downtown, and he does not have additional staff to delegate fuel purchases, energy tracking, and comfort-tracking reports to.”

The bottom line, Zaban continued, is that, “Property managers must become more efficient and organized to cope with their expanding workload, and we need to be there to help them.”

That may not necessarily be through a Web-accessible control system (WACS), controls integrator Dutt said.

“The designer should first understand the true needs of the building owner and then, based on his past experience, make a recommendation that will suit that particular situation,” Dutt said. “While most facilities can easily justify a WACS, there may be situations in which individual platforms and operators make business sense.”

Advanced user Newman sounded a word of caution regarding Web-enabled access for multiple buildings: “If the GUI servers are from different manufacturers, the operator will end up being in different operational environments for each system. That means the operator will have to learn different ways of performing the same function on each of the systems. The steps to access and change a temperature set point, for example, may be very different from one system to the next. Still, having to maintain only one operating system and browser at each operator site is a big advantage over the old days.”

Summary. The survey participants seem to agree that multiple-building access is a reasonable expectation, although it must serve a basic need and employ a common interface platform to be truly useful.


The responses of the four experts surveyed for this article indicate that the future of BAS lies in building-system components with on-board digital controls integrated into WACS with standard network connections. There are differences, however, about how open or selective the platforms used to integrate building-system components will be. Whatever developments occur, the buildings industry generally seems to have embraced standards employed in IT networks to the point multi-manufacturer digital control networks can be supported. What happens next, as one of the survey’s participants noted, is a matter for the market to determine.

The question of operator interfaces continues to vex many in the industry. That problem may be solved with building-system components with not only on-board controls, but on-board graphics, trends, and other features that can be integrated into standard Web front ends. If, however, data required for day-to-day operations need to be stored in servers, then, as another of the survey’s participants pointed out, the different operational features and environments could make such networks unmanageable.

In any case, the march toward standardization appears more robust than ever. Not long ago, building-automation graphical interfaces employed almost no Web-browser techniques and technologies; now, Web approaches are the basis of many such packages. How close we are to a complete convergence of BAS and IT is difficult to tell, but it is not too much of a stretch to say that when the convergence is complete, there may be nothing to distinguish one from the other.

Smart Buildings, Intelligent Enterprise – IIT

Saturday, June 6th, 2009

How smart are your buildings?

Smart enough to assist you in making critical business decisions at the enterprise level?

The world of building control automation has certainly come a long way in recent years. During the past several years, building control automation has been a key component in helping you manage lighting, HVAC (heating, ventilation, and air conditioning), safety and security, and access control in your facilities. The development of open communication standards like BACnet and LonWorks, and the advent of Web-based technology most recently has taken this investment a step further, allowing data drawn from these disparate systems to be consolidated and accessible from any Internet connection.

Without a doubt, this has laid the groundwork for developing what the industry has termed smart buildings. But in order to truly leverage the advantages produced by smart buildings, the next step needs to be taken in the form of making this data an active part of your business enterprise.

Many believe this step involves the convergence of building control automation with enterprise IT (information technology) systems. The idea is taking data mined from your smart building portfolio and integrating it with such systems as accounting, or ERP (enterprise resource planning), or business intelligence applications. For example, perhaps your enterprise accounting application could tap into realtime figures from an energy management system in your buildings, allowing you to see the true cost impact of energy expenses across your entire business.

The possibilities are many, as this data can assist in developing and benchmarking sustainability initiatives within facilities, comparing and contrasting design and construction methods employed, or even helping negotiate with energy suppliers on rates (per the example above).

The convergence of building automation with enterprise IT is an objective that will continue to substantiate your investment in building control automation for years to come. In a recently published reports, analysts describe this process as using the networking and computing infrastructure of your enterprise as an integral part of your building control automation infrastructure.

As opposed to the typical model of having the components of building control being entirely self-contained, integrating them with enterprise IT allows field devices to be networked on the same Ethernet or IP (Internet protocol) backbone as your IT systems and hardware. In the same manner, software used to manage building control would operate on the same computing platform as key enterprise applications.

This, holds numerous benefits, namely in the form of cost reduction. By re-using existing networking and computing resources owners reduce the need for multiple technology infrastructures—one at the enterprise level and one at the building control level. This subsequently leads to a reduction in staff required to manage multiple infrastructures.

By in large, though, this pure level of integration between building automation and IT is not occurring with great regularity. This is due in large part to the lack of alignment between facilities management and corporate IT groups within many large corporate owner organizations.

While many corporate owners have yet to achieve this pure integration, they are turning towards third-party services that facilitate communication between their building automation level and their enterprise level.

Current Options
Ron Zimmer, president and CEO, CABA (Continental Automated Buildings Assn.),, Ottawa, Ont., sees a myriad of factors impeding widespread convergence of IT and building control automation. In particular, is the fact many owner/operators do not see the full lifecycle value of mining data tapped from building control systems.

Yet the biggest deterrent he sees is the fact many owners/operators do not possess the in-house expertise to review the data and make the best decisions. In most cases, the person at the building control level does not have access to enterprise data and/or does not possess the authority to make a decision with regards to that level. This has created an opportunity for third-party companies to provide a bit of assistance.

Davmark provides a service to owners in which the company connects to existing building automation systems—primarily energy management—and, using BACnet as an information model, mines data over a WAN (wide area network) to a large database. Within that database Davmark runs a series of algorithms, based on mechanical, electrical, and energy consuming systems, in order to show owners savings on energy, maintenance, operations, regulatory issues, and comfort in what it calls an ongoing commissioning fashion. The company says it can connect with building control systems from all the leading providers.

“By connecting to these systems and running this fault diagnostic detection and optimization technology, we can find basically 15% or more in hard energy savings,” says David Slade, Director of Davmark Group. “That 15% is 15% of the HVAC energy-spend for the building. We can save that money without capital investment.”

Many top universities, including Harvard, Yale, University of Michigan, University of Florida, and Michigan State, as users of similar systems. In addition, this technology is in use at many prominent government buildings and life science facilities across the country.

“Our original vision was to have the system bring the information up to the enterprise, but what we found was that most customers cannot execute on that data,” says David. “Instead it’s a process where our own energy and mechanical engineers look at data and compare it to enterprise data in order to make recommendations to the owner on certain issues.”

The University of North Carolina-Chapel Hill (UNC),, Chapel Hill, N.C., made a similar investment during 2006 using the EnNET framework from GridLogix,, St. Louis, Mo., and installation services from Cyrus Technologies Inc.,, Ft. Lauderdale, Fla. According to GridLogix, UNC required all control systems used within its 140 buildings on campus be integrated with its existing IT network. All disparate building control systems were to be consolidated into a single Web-based user interface with the inherent data communicated to the enterprise.

According to GridLogix, this technology, which leverages XML (extensible markup language) and Web services, aligns directly with converging automation and IT. Property managers are able to connect accounting systems to building management systems to determine energy consumption and develop procedures for cost allocation and control. Building owners can connect asset management systems to building management systems in order to automatically generate work orders, and perform dispatching activities, among other tasks.

Laying the Groundwork
Enterprise processes information and technology can certainly envision the benefit of integrating building control automation with corporate IT systems.

“Davmark don’t really see it being used in the accounting system. More likely for us would be to use (building control data) in some sort of data warehouse or business intelligence system so that analytics could be performed on the data for various uses,” says David Slade. “I can see that sort of data being useful in a variety of ways; trending, future design, sustainability initiatives (LEED / BREEAM), etc.”

Achieving that level of integration would weigh heavily on how the automation systems are set up. Ton says, “Depending upon the database structures used in the building monitoring systems I could see it being ODBC connections, or if need be some sort of XML integration using middleware or other integration tools.”

Davmark are still in the primary stages of developing its core building automation strategy it offers. Engaged in the development, construction, acquisition, management, and ownership of commercial real estate which can be adopted for any large project in such sectors as healthcare, retail, office, and industrial.

Given this growing nationwide presence, David recently implemented technology that allows it to tap into building information from many disparate systems across its multiple locations. Technology, integrates building control systems across multiple properties and makes key data available via the Web.

David says one of the goals is to develop a set of standards, not only for building controls, but also for the technology within the building from an IT perspective. This includes the type of connectivity each building requires, how data is being tied together, and how that same data is brought back to central spot. These standards in place will make the process described earlier by Ton more realistic, as the enterprise systems would be drawing on accurate and consistent data.

“From the property management perspective, our value to the organization is to be able to develop benchmarks in how we do what we do, (examine) our operating costs locally, regionally, and nationally and be able to translate that into usable data,”

“As we develop properties, we can take that information and get it into the hands of our leasing and development clients, so that as we structure deals, not only for development of properties, but also for the leasing of properties, they will have some good solid market info when it comes to operating expenses and cost to do business.”

This technology integration will play a major role as the company continues to successfully develop, build, lease, and operate facilities.

“A lot of times IT gets tucked into the backoffice supporting the accounting system, but this is a prime opportunity for IT to jump in and be a part of the business.”

“This is where the business of development and construction meets up with IT and where the two technologies start to come together.”  •

NES Benefits

Thursday, June 4th, 2009

NES Benefits Flash

Overview of the complete NES System
Reduce costs, improve operations, and generate new sources of income.

The NES System benefits every aspect of your utility’s operation — from metering and customer services to distribution operations and value-added business. We offer an unparalleled return on investment with a payback period for most utilities ranging from two and five years.
Direct Benefits


The NES System:

* enables completely automated scheduled reads of electric, gas, water, and heat meters
* allows real-time, on-demand reads
* eliminates most meter-reading costs for both scheduled and unscheduled reads, due to wage, insurance, equipment, office space, and vehicular cost savings

Customer Service

The NES system:

  • reduces billing errors, complaints, and inquiries, as well as call center staff and related costs
  • extends the use of flexible tariffs (available to commercial accounts) to residential customers, allowing new tariff structures to be remotely downloaded into meters, such as:
  •   time-of-use pricing
  •   critical peak pricing
  •   real-time pricing
  •   prepayment without card
  • offers remote connect and disconnect features — useful in high-turnover environments such as apartments — that:
  • eliminate costs associated with manually managing service connections
  • increase customer satisfaction through improved response times

Distribution Operation

The NES System’s detailed per-meter supply quality statistics, broad load-profiling capabilities, and extensive provisions for theft detection enable:

  • load-balancing of meters and transformers
  • improved energy forecasting and conservation
  • blackout and brownout prevention
  • comprehensive revenue protection

The system also:

  • rapidly detects outages
  • verifies service restoration while field crews are still in the area


The NES system:

  • eliminates re-bills caused by incorrect reads or data entry errors
  •   eliminates the need for estimated bills
  •   improves cash flow by reducing read-to-bill turnaround and uncollectibles
  • reduces unnecessary services calls and field investigations through remote monitoring
  • enables load shedding to manage peak energy use by controlling the direct load of appliances such as air conditioners, pool pumps, and water heaters


The NES system offers:

  • power quality reporting for any subset of meters or service areas
  • historical as well as on-demand outage and connection reporting for accurate calculation of service quality
  • remotely configurable meter-reading capabilities by time, period, or service area to comply with changing regulations

Value-Added Benefits

Since the NES System is built on open, internationally recognized standards using existing infrastructures, your utility can add new devices over time — anywhere within the electricity network — using the same communication infrastructure already installed for electricity metering.

Products such as thermostats, boilers, appliances, air handlers, lights, and load control modules based on our LonWorks technology — the backbone of the NES system — are available from thousands of manufacturers worldwide. By adding communications and control over these devices, utilities can offer their customers or partners a number of benefits and services, such as:

  • remote monitoring and control of in-premise devices such as thermostats and appliances
  • predictive warranty services
  • consumer use reports

Network Energy System Architecture

Thursday, June 4th, 2009

NES System Architecture

The NES System consists of a tightly integrated set of components that provide the infrastructure to deliver networked energy services to your utility. The system architecture includes:

  • Intelligent, communicating digital electricity meters
  • Powerful IP-connected data concentrators
  • Scalable system software

A True Smart Metering Network

The NES system is designed to let your utility use a variety of communications media within your system to minimize cost and complexity, and maximize reliability and security. At the core of this flexibility are data concentrators, which provide the connectivity infrastructure between meters at customer sites and the NES System Software at the utility’s central office.

Data concentrators connect to the secondary side of a distribution transformer and securely communicate with and supervise meters attached to the secondary side of a given transformer. They can be installed adjacent to or collocated with one of the meters at a customer site or collocated with the transformer itself, which may be on utility poles, in underground substations, or in above-ground enclosures.

Data concentrators communicate with meters over the low-voltage power line network. Communication between data concentrators and the NES System Software (which usually resides in the utility’s data center) occurs over any IP-enabled WAN. Because our flexible data concentrators can use any convenient WAN technology — such as GPRS, CDMA, GSM, PSTN, and broadband — utilities can take advantage of today’s diverse range of wide area communication possibilities, as well as new options offered in the future.

The hybrid RF/PLC/IP architecture of the NES System cost-effectively serves both the IEC and ANSI markets for a variety of geographic terrains — from densely populated urban and suburban areas to thinly populated, distant rural locations — while retaining all of its functionality.

Advanced Metering

Echelon's NES System Meters

Meters are a utility’s most important asset: They must provide uncompromising quality, accuracy, and reliability. Our internationally certified NES meters offer the industry’s best value for a digital communicating meter, turning each metering point into a wealth of readily available information that can be used not only to generate bills — as in a traditional AMR system — but also to monitor network health, reduce or eliminate on-site visits, improve customer service, and optimize the distribution network.

Since NES provides a complete, always-on, two-way network, each meter is remotely accessible at any time for both data reading and, with proper authorization, remote configuration and control. And because our meters have no serviceable parts, you may never need to send personnel to the field again.

Our NES meters offer a number of features and benefits, including:

  • Support for multiple tariffs, which automatically adapt for holiday, weekend, and seasonal changes
  • Integrated, automatic gas and water meter reading, which expands the value of the network beyond electricity
  • Power quality information — such as power outages, sags, swells, and frequency measurements — which enable predictive repairs and optimizations
  • Extensive load-profiling capabilities to understand customer consumption
  • Real-time scheduled or remote load control to prevent brownouts or blackouts
  • Remote disconnect of main load, for managing vacant or high-turnover premises (such as vacation homes or apartments) without on-site visits
  • Superior tamper and fraud detection, which increase compliance and revenue
  • Full remote configuration capabilities, which eliminate the need to visit meters to change tariff schedule, display, or load control
  • Standard digital meter installation — no special skills or tools required

Networked Energy Services (NES) System

Thursday, June 4th, 2009

The NES System is the cornerstone of the smart grid

Echelon’s Networked Energy Services System is the first, fundamental step for utilities seeking to update their metering infrastructure. The NES System provides utilities with:

  • A metering infrastructure that delivers core services such as:
    • Automated meter reading
    • Outage detection
    • Theft and tampering detection
    • Very accurate data collection
    • The industry’s highest level of reliability
    • Extensibility from 10,000s to millions of customers
  • An open service infrastructure with an ecosystem of software, hardware, project management, and service companies with expertise in extending the NES System to meet any existing or future competitive or regulatory need.
  • Future-proof hardware and remote firmware upgradability built into the meters.
  • The ability to use any existing WAN backhaul including GPRS modem, WiMAX, BPL, and others.
  • A smart grid backbone for:
    • Residential and light commercial demand response
    • Seamless connection to the home area network (HAN)
    • Wired or wireless (such as Zigbee or 6LoWPAN) connectivity to energy-aware products

Elegant System Architecture

The NES system consists of a tightly integrated set of components that provide the infrastructure to deliver networked energy services to your utility. The system architecture includes intelligent, communicating digital electricity meters; powerful IP-connected data concentrators; and scalable system software.