This post originally appear in Automation World’s CSIA Guest Blog.
As Rockwell Automation’s Process Solutions Users Group Meeting 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 currently in the midst of four new PlantPAx projects using VMWare ESXi. One client is going to FTBatch 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.
While 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 going on 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 as you would read about in the PlantPAx Virtualization guidelines. This is a major leap forward from the home grown 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 since 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 controls 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 controls 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 controls engineers 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 and the Rockwell Automation Fair® in Atlanta in a few weeks or send an email to mike.triassi@optimation.us. Hope to see you there. Here is a link the registration for your convenience.
