Nirvana is integrating all building technology systems utilizing similar cabling, one network protocol, standardized system databases, and web tools for system access. The idea of open architectures, interoperability, improved functionality, infrastructure consolidation, and capital and operating costs savings is music to the ears of building owners and facility managers.

[an error occurred while processing this directive]

There are however, issues which could impede the open architecture approach, resulting in the idea being oversold and failing to produce the benefits it is capable of. Here are a couple examples:

• There Can Be Proprietary Implementations Of Open Standard Network Protocols
Once a building owner buys into a system that utilizes a standard industry network protocol, the owner’s expectation is that the system allows other contractors and manufacturers to support or add equipment to the system. However, if the original installer configured a unique or proprietary implementation of the “open” network protocol, the owner may need to rely on the contractor for the support of the devices or network, obviously defeating the owner’s purpose of buying into open networks in the first place. This is somewhat analogous to buying a brand new car that’s been modified by the dealer so that only the dealer can really work on the car.

How can you configure a proprietary implementation of an open protocol? Let’s assume you install an HVAC control network using BACnet or LonWorks and the system must monitor a humidity sensor. The “open” way to implement the system would be to assign the standard network variables, which cover a variety of sensors from different manufacturers. Instead, the installing contractor may configure a smaller more specific set of network variables, because for the contractor it may be easier and take less time. If the owner is unaware of the specific set of network variables, the owner may need to depend on the original contractor for service on the sensor. Even if the proprietary network variables are documented, the original installer may be the only contractor who would want to support such an implementation.

• Every Device In A Building Technology System May Not Necessarily Need to Be Networked
Whether or not technology is deployed or utilized comes down to a business decision. The question for every potential device of a building technology system is “Is the cost of networking the device less than the value of the additional functionality garnered from networking?”

An example may be a thermostat connected to a fan coil. Should we run the thermostat directly to the fan coil as it traditionally has been done, recognizing that the fan coil is the only device the thermostat communicates with? Or do we layer on a network between the thermostat and the fan coil and take on the overhead and cost of communicating through the network? The industry may eventually decide that thermostats need to communicate with fan coils through a network. But those decisions should be based on cost and improved functionality and not simply on having the technical capability to do so.

• The Network May Be Open But The System Application Software May Not Be
If an IP enabled access control or lighting control system is initially installed, can IP-enabled devices such as card readers or photoelectric sensors be added later to the systems in the “plug and play” fashion we’re used to on our personal computers? Will the proprietary nature of the application software associated with the original installation force the creation and use of APIs, drivers or other software interfaces for every device from another manufacturer that is added to the system? Do we lose some of the perceived “openness” if every device has to have code written for it? Is it realistic to expect “plug and play” in a marketplace such as access control marketplace, which is very fragmented?

• Not Every Device May Use Standard Structured Cable
It’s true that standard structured cable can be used for almost all of the cable infrastructure needs of building technology systems. Typically though, it can not be used 100%. It is not even used 100% in a data network. Sure, we use Category 5 or 6 to connect a personal computer to a network, but devices that connect to the PC, such as keyboards and mice, don’t use structured cable to connect to the PC. The same is true in other building technology systems; we can utilize standard structured cable, but as we push down into the network to the end devices on the network, we’ll find that other cabling may be more appropriate.

• Data Rates For Some Devices Are So Tiny That IP Enablement May Be Overkill
Some devices simply don’t have a lot of information to communicate and may do so on an infrequent basis. Will a door position switch that is part of an overall access control system migrate to become a TCP/IP Gig Ethernet device? The door position switch only has two states: the door is open or the door is closed. Many other devices are similar. Is networking these devices analogous to using a fire hydrant to get a drink of water?

[an error occurred while processing this directive] One can specify and procure an open system, but the system needs to be properly installed, configured and documented to produce the “open” benefits. Some lessons in the field:

• Pay attention to the details of an installation to assure an open system is being installed. Follow the adage “you get what you inspect, not what you expect”.

• Approach the networking from a business perspective and realize that not everything may need to be networked, not everything may use structured cable and not every powered device needs a Gig Ethernet connection.

• Openness is more than the use of a standard protocol; you’ll also need open system software applications and databases to manage and integrate the systems.

• Specifications should require certified or laboratory tested products that insure interoperability. Contractor submittals should include information regarding adherence to that requirement.

• Documentation of the installation of building technology systems should be extensive and include programming details and electronic copies of the standard network variables for each device.

Driven by technical advances and compelling financial justification, building technology systems will continue to evolve to open, integrated architectures. Their promise and marketing hype needs to be tempered with installation realities. By setting realistic expectations of open systems for building owners and facility managers, the probability of successful implementations and satisfied owners is greatly increased.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]