Hallam-ICS Blog

Upgrading Control Systems when Near Zero Downtime is Required

Written by Allan Stier | Jun 19, 2025 2:30:00 PM

One of the most significant factors when planning and executing a control system upgrade is the amount of time that the system can be down during the upgrade. In manufacturing environments, one can often plan for a period that a production process or packaging line can be taken offline. This period could come from alternate process paths or lines being utilized, material inventory buildup or a planned annual maintenance shutdown period. During a downtime period, the entire control panel(s) may be replaced and the system restarted and commissioned with all the new equipment.

In the case of municipal water or wastewater treatment, the allowable process downtime is near zero. The time is often measured in hours for water where gravity fed storage is utilized and minutes for wastewater systems where flows are continuous. Even with redundancies built into the equipment, the control system is a critical component for the entire facility and can’t be taken offline.

In the typical case where an obsolete 20 or 30+ year old control system is to be upgraded to a modern system, the project plan must provide for near continuous operation while changing over multiple components such as SCADA/HMI operator interface display hardware and software, communication networks, programmable logic controllers (PLCs), physical input and output (IO) hardware and IO wire terminations. Often, the process consists of multiple physical areas where controls are distributed such as influent pump stations, wet wells, filter units, chemical rooms, aeration tanks, clarifier tanks and effluent pump stations. Data from one area may be required for control of another area. As an example, residual chlorine may be measured at the effluent and used to trim the chlorine injection that is primarily controlled as a ratio of flow measured at the influent. Therefore, equipment controlled in mid-process is dependent on data provided by instrumentation / PLC IO at the beginning and end of the process. This exchange of data must be considered when staging a complete control system upgrade.

The following scenario is an example of a plan to perform a complete control system upgrade with near zero downtime.

The existing obsolete control system consisted of:

  • A single Texas Instruments TI545 PLC rack with IO cards.
  • Five TI505 Remote Base Controllers in IO racks with IO cards.
  • TI TIWAY communications connection to a SCADA PC.
  • TI RIO network to Remote Base Controllers in 4 separate buildings.
  • A single Wonderware Intouch SCADA system operator interface.

The upgraded control system consisted of:

  • A single Allen Bradley ControlLogix PLC CPU with only network ports (no IO cards).
  • Six Allen Bradley ControlLogix and CompactLogix remote IO racks with IO cards
  • Ethernet IP communications connections to three SCADA PCs.
  • Ethernet IP network to the AB Remote IO racks in 4 separate buildings
  • Three upgraded Wonderware Intouch SCADA system operator interfaces.

Migration Plan for Near-Zero Downtime

The key elements of this plan are:

  • The ability of the Allen Bradley ControlLogix PLC to connect simultaneously with the Texas Instruments TI505 IO bases via an RS485 TIWAY RBC gateway device and the new Allen Bradley Logix IO racks via Ethernet IP (both networks remain active during migration).
  • The ability to mount the new IO rack within the existing panel (or temporarily locate on a subpanel next to the existing) while the IO wires are moved from the old IO terminals to the new IO terminals.
  • Having a fallback plan for each critical step.

During the wiring migration, the new AB PLC code will utilize IO mapping from both TI and AB IO to the controller IO tags. This allows the PLC IO tag to link to either TI505 IO or AB IO and is separate from the control logic. To accomplish this task, the mapping code is developed as follows:

  • Discrete and Analog Outputs are written to BOTH IO racks simultaneously (equipment control can be performed from either existing or new IO point).
  • Discrete Inputs are read from BOTH IO racks in parallel (either point can trigger a discrete high signal).
  • Analog Inputs (4-20ma) are read from BOTH IO racks in parallel with only the signal that is above 3 ma being utilized for the IO tag update (open wire is ignored).

Utilizing the mapping code, the equipment signal is lost only for the time it takes to move the wire from the old IO terminal to the new IO terminal. Downtime meets the near zero requirement.

Migration Preparation

  1. Prepare new equipment for the migration
    1. Convert PLC code from TI to AB, install new code in the AB PLC CPU in a test bench environment.
    2. Configure the Allen Bradley Ethernet IP / TI RS485 RBC protocol gateway device and prove operation (AB PLC CPU connection to a TI 505 RBC) in the test bench environment.
    3. Upgrade the SCADA to the new hardware & software and prove operations with new AB PLC in a test bench environment.
  2. Prepare site for the migration
    1. Install a new panel with the ControlLogix PLC CPU
    2. Install the new Ethernet network infrastructure to connect the new equipment in parallel with the existing TIWAY network.
    3. Ready the new SCADA system in place for connection.

Migration Execution

  1. Transfer plant control from TI 505 CPU to new Allen Bradley ControlLogix CPU
    Within downtime allowed.
    1. Replace the old SCADA with the new SCADA system.
    2. Replace existing TI 545 CPU with a TI RBC (converts the PLC rack to another remote IO)
    3. Connect all TI IO remote bases to the Allen Bradley ControlLogix CPU via the temporary protocol converter gateway device.
    4. Start the new Allen Bradley ControlLogix CPU.
    5. Restart the plant and prove functionality using the new SCADA and AB PLC.
    6. The plant is now running with the new AB PLC connected to the old TI 505 IO.

Fallback plan – if a problem arises that can’t be resolved in allowed time, restore the TI 545 PLC control and reconnect the old SCADA system.

  1. Migrate the IO in each panel from the TI 505 rack to the AB IO rack, one rack at a time, one point at a time. Due to the mapping routines described in the plan, the status and/or control of each point moves with the wire without new programming changes required.
  2. Verify IO functionality with each move.

Fallback plan – if a problem arises that can’t be resolved in allowed time, restore the IO point to the original IO rack.

  1. When each IO point of an entire rack is moved to the new IO rack, the old IO rack can be removed.

With this method the panel work can be completed in partial steps within normal working hours for plant personnel. Scheduling is simplified and migration can take as long as necessary to prove each point. The migration process is less harried so it can be completed with reduced stress and increased confidence. A rack can be partially migrated with the plant operating when a workday is over.

  1. When all IO racks have been completed, the gateway device can be removed. The old plant network infrastructure can be removed or decommissioned in place. The TI505 parallel logic can be removed from the AB PLC IO mapping routines.

The Full Migration Plan is Shown Graphically in the Following 15 Steps:

The four buildings / areas / control panels are indicated as CNTRL, ADMIN, CSO and GRIT

 

Additional Typical Scenarios Considered

Other legacy PLCs and networks:

The migration plan has described upgrading a TI545 PLC & TIWAY Network. This plan can be similarly applied to other legacy PLCs and networks such as old Modicon or SCADAPack PLCs using Modbus or DNP3 networks. The protocol gateway device described has options that connect AB Ethernet IP to many different protocols. Gateways can be purchased from vendors such as Prosoft and HMS Anybus.

Distributed PLC control systems:

In the migration plan described above, status and control data are shared between IO racks during migration because the single PLC CPU can communicate with all the existing and all the new IO racks simultaneously. A similar migration plan can be applied to the more complicated case of distributed PLC control. In this scenario, multiple protocol gateway devices may be utilized. All the new AB PLC CPUs and Gateways would be installed in the first step. All the existing PLCs would become IO racks for the new AB PLC CPUs to start the migration process. To make the existing PLCs IO for the new PLCs, all the existing PLC programs are replaced with a program that simply maps the communications data to/from IO points. As each panel is migrated, the new AB IO is installed along with the old IO. Operation continues as wires are moved. After an entire rack is migrated to the new PLC IO, the old PLC rack and gateway device can be removed from the panel. Fallback Plan: If there is a problem, re-install the original Modbus PLC programs and reconnect existing SCADA until the problem is resolved.

Migration Plan for Distributed PLCs is Shown Graphically:

For a distributed PLC system, the steps of migration would be similar with the remote IO scenario.

Safety Note:

When working in live panels, always utilize appropriate personal protective equipment (PPE).

 

About the author

Allan Stier isa Lead Controls Engineer for Hallam-ICS in our South Burlington, Vermont office.

Read  My Hallam Story  

About Hallam-ICS

Hallam-ICS is an engineering and automation company that designs MEP systems for facilities and plants, engineers control and automation solutions, and ensures safety and regulatory compliance through arc flash studies, commissioning, and validation. Our offices are located in MassachusettsConnecticutNew YorkVermont and North CarolinaTexas and Florida and our projects take us world-wide.