Clear Connection

Facility managers of campus environments—universities, school districts, military bases and large office complexes—have had to face unique challenges over the past 30 years in acquiring building automation systems. In cases where the campus owner has procurement freedom, inevitably, that individual ends up dealing with a single proprietary vendor on a negotiated basis, and then incrementally adds to the BAS over time. And if the owner is required to competitively bid out incremental work, the result ends up being a BAS consisting of multiple proprietary systems—often with only marginal success integrating the systems.

Fortunately, open protocol technology now gives campus owners the ability to master plan a campus-wide control system that provides for the natural integration of systems from multiple vendors in a competitive bid environment. At the same time, owners must be cautioned that such a goal almost always brings along unique technical and contractual issues.

The first step involves understanding the system architectures supported by the open protocol being utilized. For purposes of this article, a LonWorks system will be examined. (Editor's note: For a primer on the same subject using BACnet technology, click on "Deep Links" at csemag.com. Next month, CSE will examine the impact the BIBB addendum has had on BACnet-style building automation systems).

In considering the different network architectural possibilities, designers must factor in two key elements: systems integration and building controls. Keep in mind this formula: systems integration should be supplied by a single vendor while building controls can be provided on a building-by-building basis by one or more vendors.

For such projects, it's important to bring in a skilled systems integrator. The contract with this professional primarily covers network services (see "Your Integrator Checklist," p. 57). Furthermore, the owner should solicit and award a multi-year, open-ended contract for a system integrator via a request for qualifications (RFQ) process. The contract should include unit pricing for the work required to add a new building to the system. Unit prices should include the cost of the router, a cost per graphic and a cost per variable that crosses what could be called the "demilitarized zone." To borrow the military term, DMZ is the demarcation where proprietary information shouldn't be allowed to pass either from or to the building control system.

For example, consider the network architecture for two separate buildings. Area "A" would constitute the system architecture—the server, operator workstation (OWS), hubs, routers and area controllers. Area "B" would be constituted of the equipment controllers in the first building, while area "C" would be constituted of the equipment controllers for the second building. Area A should be installed and serviced by the systems integrator, while areas B and C—the separate buildings—represent portions of the systems that can be installed and serviced by the multiple building controls contractors. All data that passes between A and B, A and C, or B and C can use standard LonTalk data formats, but no proprietary communication should be allowed to cross the DMZ.

The cost of the area controller will also be accounted for in the cost per variable, because it depends on the quantity of data to be handled. The owner will need to incorporate a minimum contract cost for the integrator to provide the network engineering, shipping, area controller installation, construction coordination, training and documentation.

An important first task for the integrator should be the development of a campus-wide master integration plan that includes the network topology and building system integration points.

The campus owner can select three to five qualified controls contractors to bid each building's control system. But first, a LON-based HVAC controls specification must be developed to assure the correct products and software programming is provided. It is also important that a system integration specification be provided to coordinate the efforts of the controls contractor and the system integrator.

For each building, the controls contractor has several tasks to implement as part of his or her contract:

• Install the local area LON network.
• Install the process level devices—sensors, actuators and controllers.
• For all application specific devices, configure the fixed application.
• For all programmable devices, create the application program using the controls vendor's application programming tool.
• Configure alarms for analog and digital points, and broadcast to the area controller.

The controls contractor will build a network database for the building using information and tools furnished by the integrator. The systems integrator will specify the integration tool to be used, and the building controls contractor will implement the peer-to-peer bindings to establish data flow from one building control device to another, as required by the sequence of control.

The controls contractor will provide to the systems integrator a list of all the variables and their Standard Network Variable Types (SNVT) for the following building control functions:

• Time schedule, test mode and manual override commands.
• Data from other buildings, such as outside air temperature.
• Alarm data to be sent to the area controller for handling and dispatch.
• Dynamic data to be sent to the systems integrator for monitoring.
• Dynamic data to be sent to the area controller for trend logging.

It is also an option, for consistency, that once a building is handed over to the owner, only the integrator or owner shall be allowed to download new applications or change parameter settings. This is an area that should be defined as part of the operational master plan.

With regards to the operational capabilities of the system itself, after years of development, proprietary control systems now have a great deal of functionality between local controllers, area controllers and the workstations. With open-protocol systems, where the OWS is provided by the systems integrator, and building level controls are provided by other vendors, campus owners must specify the functionality they expect. This is not a difficult task, but one that must not be overlooked (see "Functionality Questions to Ask," above).

It is not recommended that the campus owner bid the systems integration work together with the building controls contract work. The type of work under each component is very different. Further, the integration portion is more of a service contract than a construction contract. The long-term master plan allows for the replacement of the systems integrator at some point in the future, but replacement of the building control elements should not be a planned event until new technology offers significant advantages. While the systems integration vendor may also wish to bid on building controls, it is mandatory that no proprietary links between the integration and the building controls be allowed.

A key disadvantage of utilizing multiple-vendor systems is the introduction of multiple software packages. Physical devices installed by the building controls contractors consist of application-specific and programmable devices. The application-specific or pre-programmed devices, such as VAV controllers or fan coil unit controllers, pose no particular problems, as configuring these devices can be accomplished by most of the standard integration tools. With programmable controllers, however, each vendor uses a different application programming software tool. While many of these tools have become very user-friendly and easy to learn, each one is still unique.

The campus owner's concept of operation will determine the course of action. Will programming changes be accomplished by owner personnel, the systems integrator or by contract to the building controls contractor? If the owner's personnel or the systems integrator are responsible, training must be provided by the building controls vendor, and the software tools must be purchased. Consequently, it is prudent to limit the number of building controls vendors to three or less. This would retain competitive bidding on projects but not create excessive support costs.

A fundamental feature of these types of projects is that the owner has the ability to change the systems integrator without disturbing the building controls. The owner could keep the OWS software platform and network hardware and hire a new integration vendor who utilizes the same platform. With this option, the owner does not incur any replacement costs. The other possibility is for the owner to choose a vendor who uses a different OWS software platform and network hardware. In this case, the owner will incur some costs to replace specific components and costs for some re-engineering, namely:

• Each area controller will have to be replaced.
• The direct digital control operating system software will have to be changed out.
• Graphics will possibly need to be reconstructed.
• Reports will have to be re-created.
• Data flow from the building controls will need to be re-established with the new DDC operating system.

On the other hand, routers can typically remain, and if the PCs still have enough horsepower, they can be reused.

Hiring a new systems integrator is not an insignificant decision, but it will no longer have the high cost implications that have been historically incurred when changing out single vendor proprietary systems for a campus environment.

It used to be the case that owners of campus environments would have to deal with major challenges in working with the DDC industry. But with open protocol technology as a framework, products being produced by several major controls vendors, along with hundreds of smaller highly specialized vendors, have opened the door for campus owners to create a new environment where they can comply with procurement rules and still be in control of the overall system quality, cost and integration. The development of this trend is only expected to continue.