Archive for the ‘BACnet’ Category

BACnet

Saturday, April 10th, 2010

BACnet is “a data communication protocol for building automation and control networks.” A data communication protocol is a set of rules developed by the BACnet committee at ASHRAE governing the exchange of data over a computer network. The rules take the form of a written specification that spells out what is required to conform to the protocol.

There are 5 different options for BACnet, each of which fills a particular niche in terms of the price/performance tradeoff. The first is Ethernet, the fastest at 10 Mbps with 100 Mbps also recently available. (“Mbps” stands for “millions of bits per second.”) Ethernet is also likely to be the most expensive in terms of cost per device.

There are two forms of BACnet for Ethernet. One is called BACnet Ethernet for dedicated BACnet lines and there is also a BACnet for TCP called BACnet IP which can run on a non-dedicated Ethernet line.

For devices with lower requirements in terms of speed, BACnet defines the BACnet MS/TP (master-slave/token-passing) network designed to run at speeds of 1 Mbps or less over twisted pair wiring (RS-485). All of these networks are examples of “local area networks” or LANs. BACnet also defines a dial-up or “point-to-point” protocol called BACnet PTP for use over phone lines or hardwired RS-232 connections. A key point is that BACnet messages can, in principle, be transported by any network technology, if and when it becomes cost-effective to do so and FieldServer Technologies has the drivers available for all forms of BACnet.

BACnet – Introduction

Monday, June 15th, 2009

BACnet® has turned the corner. The industry is no longer playing a wait-and-see game to assess whether the Building Automation and Control networks protocol delivers as promised.

BACnet stands for Building Automation and Control Network. BACnet is the standard that was developed by ASHRAE — in conjunction with building management organizations, system users and building system manufacturers — specifically for building automation and control equipment. In 1995, after years of development and revision, the ASHRAE Board of Directors ratified and published the standard as ASHRAE 135-1995. The standard was submitted to ANSI and, in 1995, it also became an American National Standard, ANSI/ASHRAE 135-1995.

Over the next six years, the standard underwent a number revisions and upgrades. In 2001, ASHRAE released an updated standard, ASHRAE/ANSI 135-2001. In 2003, BACnet became an international standard, ISO-16484-5.

Essentially, BACnet is a set of rules governing the exchange of data over a computer network to facilitate
interoperability of various building systems. The five interoperability areas are:

  • Data sharing
  • Alarm and event management
  • Scheduling
  • Trending
  • Device and network management

As a common communication language, BACnet makes it possible for systems from different manufacturers and/or systems designed for different building automation and control functions to work together. BACnet equipment extends to controllers, gateways, routers and diagnostic tools, and provides a means to send data to a workstation.

Main Benefits for Building Owners
The benefits of interoperability within a BACnet-based facility are obvious. In theory, virtually any automated building control function can be monitored from a single operator workstation, regardless of the control system manufacturer and without the need for gateways that translate data between different systems. This simple, seamless interface levels the playing field between manufacturers and building owners, resulting in more competitive procurement of control systems.

Empowering end users through standardization was the primary motivator for ASHRAE to form a committee that led to BACnet’s creation. The standard is especially beneficial for large facilities and campus environments, where building control and automation is extensive.

BACnet devices are limited in their effectiveness unless they can carry messages over a data network. There are a number of ways that BACnet allows this: Ethernet, Arcnet,
LON,® MS/TP, and RS-232. The BACnet standard was amended in 1997 to include BACnet/IP. To date, BACnet/IP over Ethernet has been the most common choice of BACnet networking between systems from different vendors.

BACnet is a nonproprietary, open protocol communications standard. It can be applied to practically any type of system found in buildings today, including HVAC, lighting, life safety, access control, transportation and maintenance. By design, it can use a wide range of network technologies for communications. It is a written specification that includes everything from what type of cable must be used to how to initiate a particular information request or command. Its rules are specifically designed for building automation and control equipment, covering such tasks as how to request a temperature reading, send a status alarm or establish a fan schedule.

The approach that BACnet developers took when developing the standard was that for a system to be truly interoperable, there must be some standardized agreement covering two major areas: overall system operation and individual system components. They accomplished this by using an object-oriented approach in examining, controlling, modifying and interoperating with information in different devices. The BACnet object-oriented model has two major components: objects and services.

In BACnet, objects are collections of properties, each representing some bit of information. In addition to standard defined properties, objects may include vendor-defined properties as long as they function in accordance with the standard. BACnet also defines the expected behaviour from each property for that object. What makes the object-oriented approach work is that every object and every property as defined by the system is accessible in exactly the same manner.

The process of reading or writing to a property is what BACnet calls a service. Services are the methods used by any BACnet device when it communicates with another BACnet device, including retrieving information, transmitting information or communicating an action. The standard defines a wide range of services for accessing objects and their properties.

To help ensure that products developed by different manufacturers conform to the BACnet standard, a testing laboratory was established. The laboratory tests and certifies any device for conformance with the standard. The laboratory has also developed a complete set of testing procedures that are to be used by manufacturers.

BACnet is “a data communication protocol for Building Automation and Control networks.” This data communication protocol is a set of rules developed by the BACnet committee at ASHRAE governing the exchange of data over a computer network. The rules take the form of a written specification that spells out what is required to conform to the protocol.

There are 5 different options for BACnet, each of which fills a particular niche in terms of the price/performance tradeoff. The first is Ethernet, the fastest at 10 Mbps with 100 Mbps also available. (“Mbps” stands for “millions of bits per second.”) Ethernet is also likely to be the most expensive in terms of cost per device.

There are two forms of BACnet for Ethernet. One is called BACnet Ethernet for dedicated BACnet lines and the other is BACnet for TCP called BACnet/IP which can run on a non-dedicated Ethernet line. Next comes BACnet ARCNET at 2.5 Mbps. Both Ethernet and ARCNET can use a variety of physical media including coaxial cable, twisted pairs, even fibre optic cable.

For devices with lower requirements in terms of speed, BACnet defines the BACnet MS/TP (master-slave/token-passing) network designed to run at speeds of 1 Mbps or less over twisted pair wiring (RS-485). All of these networks are examples of “local area networks” or LANs. BACnet also defines a dial-up or “point-to-point” protocol called BACnet PTP for use over phone lines or hardwired RS-232 connections. A key point is that BACnet messages can, in principle, be transported by any network technology, if and when it becomes cost-effective to do so.

BACnet is Global
BACnet is not just an American phenomenon. It has steadily gained acceptance throughout the world. Recent surveys have revealed that BACnet installations are in nearly 100 countries and on every continent, including Antarctica. That’s because the inherent interoperability of BACnet and the many enhancements over the years have given end users unprecedented freedom to mix and match building control equipment from a growing array of manufacturers.

All recommended modifications to the ASHRAE standard are published openly and anyone can comment. Suggestions for improving BACnet come from professionals throughout the world. BACnet is truly living up to its original promise of making it easier to integrate building systems with diverse functions from different manufacturers. A global network of designers, manufacturers, installers, building owners and operators are more frequently turning to BACnet as a way to make all the unique systems within a building perform as a more cohesive entity. And it is rapidly becoming an international standard that is supported by technical experts from around the world. BACnet has been approved as ISO Standard 16484-5, it is a Korean national standard, and is a European pre-standard. BACnet Interest Groups have formed in Europe, the Middle East, AustralAsia and Russia to market the protocol and resolve
technical issues.

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.

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

THE DESIGNER
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 MANUFACTURER
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.

THE INTEGRATOR
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.

THE ADVANCED USER
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.

CONCLUSION

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.), www.caba.org, 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), www.northcarolina.edu, Chapel Hill, N.C., made a similar investment during 2006 using the EnNET framework from GridLogix, www.gridlogix.com, St. Louis, Mo., and installation services from Cyrus Technologies Inc., www.cyrustechnologies.com, 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.”  •