fnPrime



Small Steps Can Lead to Big Gains



System integration is a complex process that demands attention to myriad details




An integrated system can bring significant benefits to a facility operation, improving flexibility, comfort and control while saving both time and money. But well-intentioned system integration projects don’t always live up to facility executives’ high expectations. In many cases, those disappointments can be traced back to the failure to take a step-by-step approach from the earliest stages of the project.

One thing that’s easy to overlook is the need to involve a wide range of people in the effort. Input during the initial planning and design phases should come from such diverse groups as tenants, building operations staff, IT support members, the systems integrator, local code officials and the facility executive. Anyone who will be using the system should be represented on this systems integration planning team so that it truly meets their needs and expectations.

“Get all integration stakeholders involved early in the process,” says J. Alberto Rios, chief automation and controls engineer for Kling.

Working with this input, goals and objectives for the integration program need to be set. They may include how open the system needs to be and what types of bridges or gateways may be needed to accomplish integration objectives.

“Technically, we’re at a point in systems integration where the sky’s the limit,” says Karl Decker, associate partner and project manager for Syska Hennessy Group. “So the most fundamental question is what’s really necessary and desired from each building system. How robust the integration needs to be drives how it will be engineered.”

On new projects, Decker often observes that building owners do not have facility executives hired yet. “So they come in late in the process,” he says. “When we’re designing systems integration we need to have in mind who will be operating that system.”

Problems can result when the facility executive is not on the initial planning team. For example, systems that need to be linked may actually be separate systems. Conversely, the integrated system may have features that are not used in operations or management.

When important details are not determined in front of the design, consulting engineers often are forced to over-engineer the project so that it is capable of meeting needs determined later. That adds costs and doesn’t guarantee that the integrated system will be able to perform all the functions it will ultimately be expected to do. Involvement of facility executives early in the process is essential.

“Ownership and facility executive staff members must take an active role in determining the goals and objectives of the integration project,” says George B. Huettel, president of Cyrus Technologies.

He also believes it’s essential to educate the systems integration team on the important criteria and technology. “Knowledge of open systems technology is critical to making the right decisions for an organization,” Huettel says. “Determine the level of openness desired, determine the use of gateways permitted and determine the use of networking standards versus typical building protocols.”

That was the case at the University of Miami. “The first step we took was to decide that using open systems and technologies was the most cost-effective way to look at the future,” says Victor J. Atherton, associate vice president of facilities administration. “An open system delivers control over our future.”

Define Needs, Solutions

During the planning and design phase, a master plan should be developed for the building or campus, as well as a best-practices plan for the system’s implementation. It is essential to have the IT department involved at this stage. Failure to do so can create problems that will show up during the implementation phase.

Some organizations may have systems integrators in house. But many facility executives select an outside consulting engineer at this stage. The consulting engineer or systems integrator then needs to create solid open systems specifications that specify functionality and performance, not features.

One of the ways engineers do that is to learn how the facility operates. “In order to fit the systems together optimally, we need to know whether a group of people tends to work after hours or if many of them actually are out of the office most of the day,” explains Decker.

During the initial phase of system integration, Rios says, “be very specific about what needs to be done. Blanket statements requiring conformance to an open protocol are meaningless and unenforceable.”

Decker agrees. “Even with BACnet and LonWorks protocols there are barriers between systems,” he says. “The basic communication often is not sufficient. You need to tell the systems integrator exactly what will happen on either side to get the information you need and that’s an extremely difficult process.”

In general, Rios believes interoperability needs to be specified by the following:

  1. Point-level interoperability
  2. Control system intranetwork communications
  3. Control system internetwork communications
  4. Specific real-time data visualization, report generation and storage requirements
  5. Specific historical data visualization, report generation and storage requirements

“If help is needed to collect and define these requirements,” says Rios, “hire a consultant that is independent from control-system vendors.”

Atherton agrees. “Get an engineer that specializes in this area and has no preferences as to which protocol is used.”

Jack Althoff, manager of portfolio engineering for Equity Office, assumes that any integration will be Web-based. Given that fact, he suggests system integration designers should be prequalified, making sure they are certified to understand and implement HTML or XML systems, as well as local code requirements.

“Check the references,” says Althoff. “Do your diligence for the type of bridging that was done at a similar building. If you get reports of confusing information or items that do not report properly, rethink your project or your choice of vendors.”

Other integration issues include specifying the standard to be used, says Rios. “For example, XML/SOAP, OPC, BACnet, LonMark in addition to the transport media: RS-485, RS-232, Ethernet and/or TCP/IP.” A complete list of points or objects that will be exchanged in both the building automation system and the third-party equipment controllers needs to be developed.

The points or objects selected for integration need to be chosen based on their intended use. Determine whether they will be used for alarming, supervisory control, or automatic control. Then, Rios says, “identify integration in the control sequence of operations as a performance-based description with specific interoperability and user interface in mind.”

At this stage, network management and security features should be addressed, including the method of backing up subsystems, the configuration of new controllers and software change management control for all subsystems.

Before placing the integration project out for bidding, Rios says, other steps should be taken. “Pre-qualify the integration bidders and specify factory field acceptance tests (FATs) and request a project specific FAT procedure submittal for approval.”

All of these steps take time, but it’s time well spent. “Scope documents, bid documents, drawings and integration drawings that require multiple disciplines must go through a long review process,” notes Althoff. “Everyone must sign off. Every task becomes a line item on the schedule.”

The contract should contain a clause requiring compatibility, says Althoff. That clause should make it clear that any code or operational conflict is the responsibility of the prime contractor. A firm shouldn’t be designated as prime contractor simply because it is responsible for the biggest dollar amount of work. Rather, the prime contractor should be the firm that has to verify communication to the front end. “That would typically be the life safety fire panel contractor or the energy management system contractor,” says Althoff. “A commissioning engineer can also be put in place to ensure compatibility and communication.”

Life Cycle Costing

It’s important for facility executives to remember that system integration is a long-term investment.

“Avoid relaxing the requirements determined to be important during the master planning stage by maintaining a solid commitment to the goals and objectives of the program,” says Huettel. He also recommends supporting open procurement as a standard for open system, enforcing the standard open systems specifications and becoming an educated buyer. “Don’t rely on vendors’ sales pitches,” Huettel says.

“Facility executives should consider analyzing overall life cycle costs and the associated value added during the design phase,” says Rawlson King, communications director for the Continental Automated Buildings Association (CABA).

CABA is developing a life-cycle cost analysis tool that is designed to provide detailed cost models and associated life-cycle costs for commercial offices, educational buildings and government facilities. The analytical tool actually is a set of online cost calculators, hosted and updated by Reed Construction Data/RS Means, which will be available on CABA’s Web site, www.caba.org. The tool is scheduled to launch Nov. 30, 2006. The tool also is expected to use standards determined by the American Society of Testing and Materials (ASTM) Subcommittee E06.81 on Building Economics for developing building life-cycle costs.

Even after the system is up and running, the job of integration is not complete. “Work to develop in-house system integration capabilities,” says Huettel. “The in-house systems integrator is much like the current in-house IT team. Pursue training in the various options and architectures. Seek out and hire new talent, if needed, to increase skill sets. Continuously research all available products and vendors.”

Quality issues also must be considered throughout the life of the system. For example, as components are acquired, the specification created during the planning stage should be enforced.

The test of an integrated system is whether it improves the operation of a facility. If that’s the case, the hard work that went into planning and executing the project pays off. At the University of Miami, careful planning has been rewarded with more efficient operations. “Multiple vendors can bid the installation, and we can buy and stock the parts we need to maintain the system from multiple vendors,” says Atherton. “We can train our staff to maintain the system, or multiple vendors are available. In each case, we can competitively purchase everything and get rid of a non-performing vendor without any hassles.”

THE BIG QUESTION
To Integrate or Not To Integrate?

System integration often makes economic sense. But there are situations when integrating functions simply are not the best use of a facility’s resources. Jack Althoff, manager of portfolio engineering at Equity Office, offers the following series of questions as a starting point. According to Althoff, if any answers to these items are yes, the project should not proceed.

  1. Am I unwilling to convert my systems to a Web-based protocol?
  2. Will the integration cause nuisance operating issues with other building systems?
  3. Will the system lose its Underwriters Laboratories rating or be in conflict with any insurance or code requirements?
  4. Will the work or system change negatively affect my tenants long term?<
  5. Will integration affect servicing or long-term use of the system?
  6. Does integration decrease security, life safety or energy management system performance?

Item 3 can be particularly tricky. “Often facility people do not understand the conflicts that arise within various code authorities in the same city," says Althoff. “The fire department may have internal conflicts with the elevator inspectors. Some areas may want shunt disconnects for elevators, some pre-action systems and some sprinkler systems.” Such conflicts make it more difficult for facility executives to get their arms around potential code problems raised by system integration projects.

— Rita Tatum


Rita Tatum, a contributing editor for Building Operating Management, has more than 25 years of experience covering facility design and technology.



Contact FacilitiesNet Editorial Staff »

  posted on 11/1/2006   Article Use Policy




Related Topics: