At the next level of system integration, you can use Ethernet and, in some cases, OPC and XML technologies, which are supported by both BMS and process OEMs. Most manufacturers of BMS and PCS supervisory devices communicate via Ethernet, which provides a common, open protocol for communication. However, many of these same devices use proprietary packages to send data via Ethernet connections, making communication with other devices challenging. Knowing that both systems support Ethernet communications does not ensure easy integration. In our example of supervisory controller integration, the network port passes data between the BMS and PCS. It must be noted that this is a vendor-specific solution, but it is probably the most reliable and effective one for this task.

With ELPCI, the BMS alarm data can be sent to the operator workstation, transferred to the PCS workstation, and then routed back down to the appropriate controller to affect the warning or shutdown. Workstation-to-workstation integration is typically performed through OPC or XML, industry standards supported by all reputable system manufacturers. This is a longer path, but it can be a reliable and predictable solution.

Record Retention This integration is only required if the BMS is a separate system without its own data historian. Utilizing the PCS data historian for all GxP data is a common approach. It allows the owner to maintain only one historian for both major systems while ensuring environmental data are matched to production data for internal and external audits. Supervisory-level, enterprise-level, and database-level integration are possible solutions.

Supervisory-level integration involves sending data from the BMS supervisory controller via a common protocol to either a supervisory controller on the PCS or to a PCS workstation (typically via OPC or XML). Not all BMS solution providers support this approach. Be certain to verify that your BMS vendor has a network port that can send data to the PCS in a language and protocol the PCS can understand.

Enterprise-level integration involves sending raw data from the BMS operator workstation or network controller using a common protocol such as OPC or XML. These data are then gathered in the PCS database for eventual transfer to the data historian. The advantage of this approach is the availability of the data from both processes at the PCS workstation. As a bonus, only one database must be maintained.

Database integration is probably the best solution for this application. The BMS will always send the control data to a database for its own use. A good BMS should offer a non-proprietary, albeit secure, database. As mentioned earlier, ODBC is typically used to share data between relational databases. Assuming that both the BMS and the historian support ODBC, this is a reasonable setup. The only disadvantage is the need to maintain two databases.

CAVEAT EMPTOR From the owner's perspective, integration is a tool to be used only when needed to enhance control, ensure data acquisition, reduce operation costs, or assist in validation boundary definitions. However, successful integration can generate fabulous results and create a unique, showcase atmosphere that builds team pride. It also can be fraught with danger and expense. Many integration projects turn into funded science projects, so buyers must be cautious. Knowledge of integration options is the best way to protect yourself from dishonest or uninformed system integrators.

Addressing the following points can help ensure a successful integration project:

• Define the need. Why? What's the benefit?
• Prove the technology. Can it be done with existing, proven technology?
• Establish the budget. How much is it worth to my company?
• Evaluate the system integrator. Who can provide this for me?
• Prototype the solution. Make them show you.
• Execute the successful prototype. Look, it worked again!
• Verify the success. Is it working like I expected?
• Document for future use. Can we use this again?

Good luck and happy integrations.

Jeffrey Bredeson is business development director for Johnson Controls Life Sciences Group , 1255 N. Senate Ave., Indianapolis, IN 46202, 317.917.5172, fax 317.638.6146, jeffrey.s.bredeson@jci.com
.

Dario Sala is director of system solutions - Europe for Johnson Controls Life Sciences Group, Via Monfalcone 15 Milano, Italy 20132, 011.39.02.28042.304, fax 011.39.02.28042.221, dario.sala@jci.com
.

Greg Weddle is manager of global critical environments for Johnson Controls Life Sciences Group, 1255 N. Senate Ave., Indianapolis, IN 46202, 317.917.5170, fax 317.638.6146, gregory.b.weddle@jci.com
.