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.
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.
Each of these integration strategies are operation-critical, since they all involve sending data for proof of validated production
conditions. Therefore, it is imperative that these integrations are robust, dependable, and can be validated.
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.
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, firstname.lastname@example.org
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, email@example.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, firstname.lastname@example.org