Virtualization Best Practices

Four new PlantPAx projects at Optimation show the need for an even more standardized way to configure virtual deployments.

Aw 106277 Miketriassiweb2

As Rockwell Automation’s Process Solutions User Group (PSUG) event draws near, what do you want to learn about your PlantPAx systems? For me, I would like to devise an even more standardized way to configure the virtual deployments.

At Optimation, we are in the midst of four new PlantPAx projects using VMware ESXi. One client is going to FactoryTalk Batch and Material Manager to mix powders for pet food production; one feedstock producer is using the new Sequence Manager functionality; another has a new PlantPAx aggregate mixing process for glass manufacturing; and one is modernizing its power plant with a common user interface and common PLC equipment to replace several obsolete systems.

Though these are vastly different applications and project goals, it is striking how similar each of these installations appears to the other. When you peek at the virtual images using VMware’s vSphere client, there seems to be a lot in common. This is mainly due to that fact that Optimation has been leveraging the Vitalization templates for its projects for the past several years. We have batch, engineering workstation, operator workstation, info system, domain controller, and FT directory images that you read about in the PlantPAx Virtualization guidelines. This is a major leap forward from the homegrown installation approaches of the past, but even more could be done to streamline the initial phases of these projects.

The challenge is that each client’s network topology, firewall system, authentication procedure and backup strategy is unique. As an integrator, there is a fundamental decision to be made: Will you develop offline and then move your application to a live system? Or instead, can you VPN into the client’s domain controller and authenticate to the network that will be used for this application? The latter option is very appealing because it removes the onerous task of reconfiguring a tested system to run in its target environment. Unfortunately, it comes with the headache of trying to take care of these issues in advance.

Virtualization solves the problem of segregating systems and accelerating the installation of systems, but it does not solve the fundamental IT configuration questions. If these requirements are left unattended, they can diminish some of the time savings of a preconfigured environment. Allowing control engineers to design the architecture on their own will surely lead to difficult deployment situations at the end of development. Conversely, waiting for the IT stakeholders to set up the network in advance can delay the whole project days or weeks, waiting to build an approved architecture.

It has become clearer than ever that architecting a standard user login strategy and network topology that can be shared from project to project would be very beneficial. It needs to allow developers to start work earlier while the network details are sorted out. And it cannot come with a lot of reconfiguration later.

We will be looking hard at the issues for both the control team and the IT team and put together a “golden” image that is a known starting point, including authentication, which may then be moved in as a trusted domain or migrated to one on the client’s network without delaying the onset of the project. This will allow each control engineer to know what to expect regardless of what process problems they are tasked to solve.

If these issues are on your mind, look me up at the PSUG meeting in Atlanta next month or send an email to Hope to see you there.

Mike Triassi is business development manager at Optimation, a certified member of the Control System Integrators Association (CSIA). See Optimation’s profile on the Industrial Automation Exchange.


More in Networks