Virtualization - consolidate corporate and process/factory IT

Hi All,

We are in a phase where we need to renew our server infrastructure on corporate/admin IT and Delta-V/factory side for all our worldwide plants.

To optimize day to day operations and avoid double cost we are looking into the option to provide a converged infrastructure that can host corporate/admin (print, file, AD, etc.) and Delta-V/factory functionalities.

Of course the needed security and redundancy will be put in place for both environments.

I can't find any reference case of shared/converged infrastructure for both functionalities, does anyone has experience or feedback?

Thanks for your feedback.

6 Replies

  • Ok, I'll guess you are talking about using the same hardware to run both IT and Plant control networks together - if not, then what I'm about to write is complete rubbish!

    We have looked at this but ran away from it for a number of reasons:
    1. how do you slice up who is responsible for what in terms of switches, firewalls, gateways, etc. Can get messy if 2 people from different ends (IT or DeltaV) want to edit switch configuration at the same time - who takes precedence?
    2. How do you maintain your cyber security profile? Very challenging if equipment (switches, etc) are used by both networks.
    3. Some equipment can only be used for DeltaV applications - I think the DeltaV smartswitches fall into this category (although I'm prepared to be put right on this).
    4. Who takes care of patching, software updates, planned maintenance? If a switch goes down at night, who gets the call?

    What national guidelines have you got to follow? I know our USA plants have to follow the Dept. of Homeland security guidelines which places a lot of restrictions/guidelines on how the networks can be connected.

    I'm not saying don't do it, as I have known businesses in the past which have implemented shared equipment resourcing, but it was on very small sites with a small control system, with very limited business/environmental/production risk if there was a security breach across the 2 systems (or even from outside the company networks, i.e. internet).

    Hope the above helps.

    Col
  • In reply to Colin Welsh:

    Antony,

    Colin brought up several good points. I would also like to add that the Emerson supported hardware will almost assuredly not be the same as your corporate IT standard hardware. Not only does Emerson (and other DCS Vendors) specify the Server / Workstation brands, but also the models down to supported motherboard, video and NIC boards as well as the drivers used.

    You do not want to be in a situation where you call Emerson for support and they are not able to assist because they have no experience running their software on your selected hardware.

    I would highly recommend to keep your IT hardware and networks completely separated from your process control system hardware and networks.

    Michael
  • In reply to Michael Moody:

    Hi Michael, Colin,

    Thanks for your feedback.

    Regarding hardware we would be using the supported/recommended DeltaV/Emerson converged infrastructure (Dell VRTX family).
    So that shouldn't be a problem.

    Regarding roles and responsibilities, I agree that clear guidelines are crucial.
    We are not a big organization, idea is that Global IT is in charge of providing the infrastructure/platform layer, where DeltaV team is in control of the application layer.
  • In reply to Antony.Poppe:

    Antony,

    Realize that any hardware used for the DeltaV in an actual production system should be purchased through Emerson, not through Dell. This is the only way to ensure correct hardware, firmware, and drivers are used throughout.

    From an Automation Security standpoint, I would still strongly recommend against.

    Michael
  • Your discussion appears to be focused on using virtualization infrastructure. DeltaV is supported on the Emerson approved virtual host servers running Hyper V. This support requires that you also use the supported version of Microsoft Server OS, which is currently Windows SErver 2012, but has been announced recently to be moving to Server 2016, skipping Server 2012 R2. As Michael points out, using unsupported hardware or OS, or say VMWare as your virtualization infrastructure puts you in a unique combination of these that Emerson does not have, and is therefore unable to investigate issues you may experience. If the same issue is not manifested on the supported hardware software combination, it would not make sense to attempt to resolve this issue and create risk to systems running the supported software.

    It is generally stated that the VM environment shouldn't matter. The fact is that all IT departments restrict the hardware and software they allow on their systems in order to control the beast that is Commercially Off the Shelf technology. Everyone revs their hardware and software and every combination introduces a unique set of variables. Once the IT department has identified a stable combination, they support that and only that. Emerson is no different, and has the responsibility of providing a 24/7 application that can't be "interrupted at 2 am for a software roll out". This is not an Email server.

    I can say that you can most likely install any virtualization environment and successfully load DeltaV software on the right version of OS, and interconnect these VMs to talk to DeltaV controllers. The issue is who troubleshoots this system and what is the consequence if something fails. I've met a few very smart people that insist they can do this and do not need Emerson to provide a supported solution. If they move on, who will be left to administer and run this system? What happens when the Virtualization software and hardware need to be updated? Who will perform migration testing or develop procedures for updating the software. The consequence of an issue in a combined infrastructure could mean huge losses in production. Is this really an economic decision?

    As for the DeltaV Network, Emerson has taken ownership of this with DeltaV Smart Switches that come with special OS and features that deliver increased cyber security of the DeltaV system. Removing these to use a common infrastructure undermines the inherent protection built into the system. Also, future enhancements to the system will be developed on the assumption that DeltaV Smart Switches are installed. Installing non-DeltaV approved gear on your network complicates your cyber security for the system, and fundamentally reduces the layers of protection that are accepted best practice in this space.

    I don't see any upside to rolling your own infrastructure designed to accommodate both IT and Operations. I would not do it.

    Andre Dicaire

  • Well, I can't speak from a virtualized Delta-V stand point but I have developed virtualization for other DCS platforms and they worked rather well.

    For the network issue, it would still be best to establish some form of physical separation from your business and control network. This way the IT guys can do whatever they want with the IT switch and vice versa for the DCS guys. Depending on your virtualization software, you can do the same virtually with virtual switches as well.

    Firewalls and routers that lead out to your corporate or internet can be shared. However, firewalls/routers between your control systems should be dedicated like your switches.

    This is a mixed solution that would help make both your IT and Controls groups more comfortable. Slightly more expensive than a full on shared everything with hardware, but easier to maintain for the individual groups and limits the finger-pointing when things go wrong.