When an organization considers migrating its legacy control system, the management will give the control engineers the task of developing a migration plan. The migration plan should consider all aspects of the migration, from risk management to cost limits and shout-down time.
To construct such a plan, one must understand the control system in depth and the options available.
Let’s get right into it
To understand the migration of a control system, we must start with the basic scenario, i.e., standalone controller migration.
Why migrates a legacy PLC?
The reasons to migrate a legacy PLC are:
- The old hardware is failing more and more
- The old serial industrial networks are too slow for today’s data rate requirements
- You need to expand the controller IOs, and the controller can’t deal with the extra load.
- The hardware spare parts stock is becoming very expensive or impossible to buy.
- Microsoft does not support the operating system of the engineering station.
- You just want to be updated with the current technology.
- It’s one of many tasks performed as part of A long-term preventive maintenance strategy
Most control engineers are afraid of this kind of migration and usually stick to the phrase, “If it’s working, don’t touch it.” This is, of course, wrong thinking; the control engineer of the organization needs to embrace this kind of opportunity to make his system much more robust, and therefore in the long term, it will make his life easier.
Local rack controller migration
We will start with the simplest case where there is one main rack with CPU and IO without peripheral devices (like Remote IO or VFD), There is SCADA or HMI, but we don’t want to migrate the SCADA.
The first thing we must do is decide on the new, most suitable PLC. For easy and fast migration, it’s better to:
- Migrate to the same vendor hardware since most vendors have fast and efficient migration tools.
- Choose hardware (IO modules, chassis, etc.) according to the legacy hardware. With the same number of points and the same electrical properties (voltage, current). This way, the electric design will be more straightforward, and you will be able to use the existing wires, power supply, and more electric components in the PLC panel.
- Migrate the PLC program AS IS, meaning the code will be copied to the new PLC program without changes. This way, it’s possible to use the vendor migration tools.
When choosing hardware, you should consider future expansion to the system; there for you should:
- Pick a PLC CPU with a lot more memory and capabilities than the legacy PLC, today’s applications need a lot of processing power and memory to deal with the communication networks and the higher systems like SCADA or MES.
- Pick a controller that can support many IOs, much more than the legacy PLC.
After choosing the hardware and constructing a BOM (Bill of materials) for the new system, it’s time to proceed to the electric design. The electric design must be perfect since we will probably have only a few hours of shout-down to finish the replacement, and there is no room for errors.
Prepare a migration plan that will specify every step of the process, including tasks, dates, and who is responsible for performing this task. Don’t keep this plan to yourself; share it with everyone involved in the project, from your manager to the IT department, maintenance team, and operators.
Gather as much information from the system as possible before starting working on the project; you should have the following:
- Legacy PLC program backup
- Legacy SCADA program backup
- The old Electric design
- The old network topology and backups
- Passwords and privileges to the old system
- IO list
- Instrument list
- Motor list
- Recipes list
- Alarm list
- Legacy system SOO (Sequence of operation)
- Legacy system P&ID
Also recommended is to talk to the operators and the process engineer of the machine/system to understand the process and ask them for things they would like to change or improve. This way, they will feel part of the project and will help in further procedures like the startup or IO testing.
In this simplest case, we decided to migrate the PLC program AS-IS without changes; this means we will copy the old code without modifications, it has the disadvantage of keeping old errors in the new system, but on the other hand, it will reduce the risk and the downtime significantly.
The SCADA migration will be discussed in detail in the following chapters, but in this case, we decided not to migrate the HMI or SCADA system, and still, we have some work to do regarding the SCADA:
- Update the HMI tag database according to the tags names of the new PLC.
- Make sure the new controller supports the communication network for the legacy HMI. Old HMI and SCADA systems like RS232 DF1 or RS485 Modbus RTU can work with serial communication.
- All the testing should include the SCADA testing since we changed all the tag address
Migration to the same PLC vendor or another vendor
There is a big difference if the PLC migration is to a PLC from the same vendor as the legacy PLC and that’s why:
- The vendor wants you to migrate your PLC and not replace it with a different vendor, so the vendors create tools for fast and automatic conversion.
- The vendors will give you a discount for the hardware and software licenses if you will keep using them.
- In the past there were a lot of vendor specific communication networks like Siemens Profibus or Rockwell DH+, If you decide on different vendor, make sure you give solution to those protocols.
For example, migrate Siemens S7-300 to S7-1500 with Step7 to TIA Portal automatic conversion:
Or Rockwell’s PLC5 to ControlLogix with RSlogix5 to Studio5000 conversion tool:
One Step vs multi-step PLC migration
Instead of replacing the local chassis with a new local chassis together with all the IO, Another Option is to replace only the CPU and convert the legacy PLC IO to remote IO. This will reduce costs significantly and the risk (since we don’t need to rewire the IO modules).
This is possible only if the new controller supports the legacy network.
The old PLC CPU should be replaced by a communication module.
Here we will also introduce the multi-step PLC migration, where we can do only CPU migration (When the old IO is converted to remote IO) in the first step and the replacement of the IO in a later opportunity.
The multi-step migration is good from a risk point of view since, in every step, we are performing testing on one part of the system instead of testing all the systems at once. Also, the go-back time of every step will be reduced.
The migration can be split into more than two steps in a more complex control system with many components and a complex HMI.
For example:
- Step1 – Only the PLC CPU migration – including the PLC program – in this step, we are testing only the PLC program conversion.
- Step2 – IOs and Peripheral devices migration – in this step, we are testing only the hardware – IO testing
- Step3 – SCADA Migration – in this step, we are testing only the SCADA
Some manufacturers schedule a planned shout down every month, quarter, or year, you can use those shout downs for performing the multi-step migration.
Peripheral devices migration
Peripheral devices can be:
- Remote IO
- VFDs or soft starters connected by a network (If hardwired, then it’s like every IO in the system)
- HMIs
- Network adaptors like Prosoft, Moxa, and others
- Other control systems and controllers.
If there are peripheral devices in your control system, then they must be considered. There are two scenarios:
- PLC migration without peripheral devices replacement – Replace the main PLC rack, but you must take care of the peripheral device’s legacy communication. There are plenty of communication models to support the old legacy networks
- PLC and peripheral devices replacement – Here, we can take the one-step or the multi-step approaches, meaning we can replace the main controller in the first step (and make sure to address all legacy networks) and replace the peripheral devices in another or a few more steps.
Remember that the peripheral devices are essential to the control system and should be cared for like hardwired IO.
When planning the migration, it’s essential to get the network topology with all devices and addresses (example: IP address if ethernet or Node ID if Modbus RTU); that way, you will not be surprised in the startup.
Testing and simulation
One of the most critical steps in the migration process is the testing and simulation before and after the startup.
Pre-Startup
Hardware testing:
- When the new hardware component is supplied, it will be beneficial to connect the new rack “on the table,” insert all parts to the chassis, and power up to see that there is no faulty module.
- A fast IO check can be performed in this stage to make sure there is no faulty channel.
Program testing:
- In this testing phase, we also want to check the new PLC program; we will download the program to the controller and check for program errors or faults.
- If possible, make a program simulation to test critical interlocks and sequences.
SCADA testing:
- In the testing phase, you can create a clone of the HMI with the updated tag database to check the tag database is correctly updated. It’s also possible to read the inputs from the old PLC to the new PLC and then look at the cloned HMI to check for errors
Post-Startup
IO testing:
- Testing all hardwired IOs if replaced
- If possible, check the IO from the field to the HMI (For example, change the valve manually and check the feedback inputs).
- If it’s not possible to check from the field, then inject current to the inputs clamps and measure the current from output clamps.
SCADA testing:
- After startup it I crucial to check again the HMI/SCADA screens and look for errors or mismatches.
In each scenario and for different system it is possible to find more ways to test simulate the system, be creative.
Solutions for migrations
There is a solution for every obstacle!
There are numerous products in the market that will make your migration much more efficient and can save you a lot of money.
Solutions for hardware migrations:
- Prewired cables – some vendors sales prewired cables from the old IO module terminal block to the new IO module and this way you can skip the IO wiring phase, that is a risky phase.
- Conversion kits – like the prewired cables, here they also include the chassis, cables, terminals and more.
- Communication modules support legacy networks – can be used in the pre-startup testing but also to communicate with some legacy peripheral devices as discussed earlier.
Solutions for software migrations:
- Automatic conversion tool – as discussed, some vendors will give you a free automatic conversion tool to keep you with their products.
- Excel – In most PLC software’s you can export and import tags and code in to excel, it is very useful and reduce the engineering working hours.
OPC – in some situations you can use OPC in the testing phase to read data from the legacy system and inject it to the new processor, this way you can check part of the program conversion.
PLC Migration process
So, after discussing all aspect of the PLC migration, lets summery the migration process for a single standalone legacy PLC:
Pre-Startup
- Create a solid migration plan
- Chose new hardware according to legacy controller hardware and with the help of selection tools.
- Create BOM (Bill of materials) for hardware and software licenses.
- Electric design – update old electric drawings if exist or create new.
- Order BOM – only after electric design update.
- PLC program upgrade, hopefully with a vendor conversion tool.
- HMI/SCADA tag database update according to new addresses.
- On arrival, connect the hardware ‘on the table’ and test the hardware and software.
- Testing and simulation
Startup
- Disconnect the terminal block from the old modules, this way the old terminals and wires are hanging in the air.
- Disassemble old hardware and assemble the new one
- Rewire the new terminals
- Power up the system.
Post-Startup
- Full IO check from field to HMI, if possible; if not possible, then perform IO check from the clamps to the HMI (by injecting current to the clamps and checking the IO in the PLC software or on the HMI)
- Check HMI screens for errors or faults.
Ask the operators to start the process and accompany them in the process, if there are problems, analyze them and fix them immediately.
Conclusions
After reading this post you now have the foundation to properly create a migration plan for a fairly simple control system.
There are many more considerations in a more complex migration like the PLC program migration, communication networks migration, SCADA migration, and more. In a future post we will discuss those topics.
