Unsupported Operating Systems Force Upgrade to Avoid Potential Failures and Downtime 

A client had a QBMS (Qualified Building Management System) operating on an antiquated version of iFix and was running on an outdated OS (operating system).  At a certain point, they would no longer be able to update either, preventing them from getting the most out of these systems and leaving them with an unsupported OS and HMI system and the potential of increased downtime in the event of a failure.  

Knowing it was only a matter of time before they would start encountering issues that could jeopardize the system’s operation and reliability, they knew it was time to work proactively.   

After evaluating their options, they moved to update and upgrade the QBMS while at the same time enhancing and expanding its capabilities from monitoring building parameters (such as temperature and room differential pressures) and independent equipment (such as freezers, refrigerators, and lab incubators) to also monitoring production equipment and centralizing the historical data collection of all equipment at the facility. 

Overcoming Compatibility Issues and Added Functionality on a Tight Turnaround  

Our team is always up for a challenge, and this project presented no shortage of them. Having to complete a partial upgrade in an existing system can require a bit more analysis and research than starting from scratch.   

Try as you might to ensure as few potential hurdles as possible are overlooked and unrecognized once the work is underway, some can be out of your hands and unavoidable.  

Our team encountered two significant challenges during the project. The client selected the PlantPAx 5.0 architecture, however, some of the equipment to be displayed and monitored was not PlantPAx 5.0 based.   

Certain pieces of equipment didn’t even provide the data from a PLC, but instead from an OPC server which presented its own set of compatibility issues.  

The second challenge was on the QBMS side. The equipment and production areas being monitored by the existing QBMS would only be able to be down for a very short time (preferably less than one working day) to perform the cutover from the old system to the new system.   

It was critical to strategically plan the necessary downtown as to only minimally disrupt their daily operation. 

A Slow and Steady Approach Provided a Methodical and Efficient Execution  

To solve the non-PlantPAx 5.0 equipment problem, a PlantPAx 5.0-based PLC was set up to read the data from the equipment and the data from the OPC server was read by an OPC client which was transmitted to the PlantPAx 5.0 PLC. This PlantPAx 5.0 PLC was then used to display the information on the HMI and from which the Historian gathered its data. 

To migrate the systems from the old QBMS to the new PlantPAx 5.0 QBMS, a combined philosophy of modularity and “you can’t do everything at once” was employed. Trying to disconnect, reconnect, and validate all the I/O points from the control panels would take days.  

Ultimately, the work would be done one panel at a time, one day at a time.  The team converted and tested only one panel per day because that made the number of points being converted completed in manageable pieces, reduced the number of issues that needed to be monitored manually at one time, and limited the downtime of systems not being converted.