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 incr...

By Carl E. Lundstrom, P.E., Vice President, Facility Services, EMC Engineers, Atlanta May 1, 2003

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.

Implementing a multi-vendor BAS

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 controls contractor

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).

Additional issues

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.

Disadvantages of multiple vendors

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.

In sum

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.

Acknowledgements
Editor’s note: Robert Schulz, P.E., chief engineer with TAC-Americas, Dallas, contributed to this article.

Functionality Questions to Ask

A system should offer a great deal of functionality, but when considering the operational capabilities, ask these questions to be safe:

What are the alarming requirements?

What data must be visible at the workstations?

What data must be trended for reports?

Shall the operator have the ability to override sensor inputs? Manually override outputs? See the status of HOA switches?

What application parameters must be accessible to the operator? Calibration parameters? Tuning parameters? Setpoints?

The campus owner must require the systems integrator and controls contractor to pass LonTalk data across the “demilitarized zone”—the line where proprietary information shouldn’t be allowed to pass to or from the building control system—for each of these specific items. The HVAC controls and integration specifications need to clearly define the variables that will cross the DMZ in either direction.

Your Integrator Checklist

The integrator is responsible for:

Configuring the TCP/IP level of the system.

Installing and configuring the server that collects the data from the TCP/IP network from the buildings.

Installing and configuring workstations that will take data from the server and present it to system operators.

Setting up long-term data collection and periodic reports.

Building the graphical environment for data presentation.

Setting up the alarm handling and routing.

Setting up all time-based control algorithms/time schedules.

Setting up a web server, if required, to publish data to web clients.

Managing the network database containing an image of all of the building controls, their addresses and a map of network data flow.

Installing an IP to LON router in each building.

Installing an area controller in each building to store trend data, execute time schedules and process alarms from the building controls to the operating system.

Control System as Web Server

A growing trend in the last few years is for facility engineers to use a web browser to view pages of live facility data from multiple sites one page at a time. This method works fine for engineers who monitor a single site. It takes very little time to surf to each page, wait for real-time data to be displayed, and move on to the next page, ultimately getting an overall picture of a process or building. The introduction of hardware/firmware-based web servers specifically geared toward the controls industry has made this method easy and cost- effective to implement.

As the number of sites increase, the usability of the single site per page method becomes problematic. The common answer to this problem is to deploy a central computer to collect system status data from each site, store this data and finally, provide the user with the aggregate information from multiple sites on one page. Systems like this can be purchased or outsourced, and for engineers who monitor hundreds of sites, this is an adequate albeit costly solution.

With the very large and very small problems within sight of solutions, a valid question arises: What method best fits the engineer with a dozen sites to monitor?

Web services to the rescue

To address inherent complexities of multi-site control system monitoring, hardware manufacturers are now adding web services to traditional control hardware as well as to more traditional web servers. Web services allow software applications to query a control system over a network and have the data returned formatted in XML. Most will agree that this technology will forever change how control systems and application software interoperate.

Web services build on the proven technologies of HTTP and XML by providing self-describing applications that can be invoked across the Web. Modern software development tools that aid in the creation of Web services and applications that use these services are available for most operating systems and support a considerable lineup of programming languages. The broad adoption of Web services in all types of network applications ensures that developers and users alike are making a safe bet and will not be orphaned by an outdated technology.

Building the application

According to product evangelists, with brand “X” software development tools creation of web service clients is “just a few mouse clicks away.” While novice users will not be writing software to capture control information from the web service enabled devices any time soon, it is clear that it has never been easier for generic application providers to gather data from control systems.