Emerson Exchange 365

Best Practices for Implementing Operator Training Systems for DeltaV using Mimic Simulation Software

Operator Training Systems are an effective tool for preparing a plant operations staff to use automation systems. The simulated system, also known as a Digital Twin, provides a cost-effective and comprehensive solution for customers. Together, Mimic Simulation Software and the DeltaV Simulate Suite offers:

• Non-intrusive simulation interfaces for conducting Software Acceptance Testing
• Offline systems with realistic process and IO responses for operator training
• Proven methods for testing new control strategies, recipes, products
• Effective methods for testing MES integration and electronic batch records

Implementing a digital twin for operator training has been proven to help customers:

• Reduce & compress their automation project schedule
• Achieve quicker unit startup with better product quality
• Incur less unscheduled downtime
• Ensure compliance with GMP and FDA regulations and that operators meet OSHA and ISO training requirements

The following whitepaper outlines the capabilities and configurations of Mimic and DeltaV Simulate Suite and includes a sample Bill of Materials (BOM) for Operator Training Systems.Virtual Plant Using Mimic For Emerson Process Management DeltaV.pdf

Interested in learning more about simulated Operator Training Systems? Have a best practice of your own to share? Reply below to share your questions with our experts.

• Mimic Software
• DeltaV Simulate
• digital twin
• operator training
• DeltaV

Todd Jaco

24 Replies

• Stuart Jolley

  

  This article is such good timing as I have just recently placed an order with Emerson and are still awaiting for my licenses to arrive, which should be any day now. I contacted my local Emerson office with a requirement to be able to simulate VIM registers. We have a DeltaV v11.3.1 system with our standalone ESD system using VIMs as the interface.
  
  Emerson’s quoted the below items:
  VX2102S01 DeltaV SimulateProfessionalPlus Networked (PPN)
  MM3-1101 Mimic 1000 SIO Tag Base License
  DeltaV Railbus SIO Driver
  
  To date, I have no idea how the system will work and what I need to do to set it up. I’ve googled loads but there doesn’t seem to be much information out there. I’m planning to install mimic on a standalone workstation then to install deltav simulate on another standalone workstation, both connected to the same network switch. I’m assuming this setup is acceptable and will work. Then restore my deltav database that was backed-up on the live deltav system.
  
  I’m concerned at the moment as I don’t know if I will need any deltav hardware to support my objective of simulating VIM registers, I’m really hoping not as Emerson never quoted for any hardware. I’m wanting to write to an existing VIM register from DeltaV operate, then for mimic to process the register and for mimic to write back to deltav operate via a different VIM register.
  I have a SAT to do soon so hope it will all come together without to much effort.
• Vicente

  

  In reply to Stuart Jolley:

  You can install Mimic on a standalone workstation and DeltaV in another one (please notice that you do not need to follow a different procedure when installing DeltaV Simulate, you just need to assign the new license to the station which will be the ProPlus) . You may need to set up some DCOM (same accounts in both machines with same password...)
  
  Regarding simulating VIM, we have some documents to explain how to set it up and configure. I think it would be good to set up a call to go through the details of your objective and to provide you additional information. Would this be an option?
• Stuart Jolley

  

  In reply to Vicente:

  This sounds great, just what I was after. Please provide contact details. Are you an Emerson employee?
• Vicente

  

  In reply to Stuart Jolley:

  Sure. Please find below my contact details. I worked for Emerson based on UK. We talked couple of weeks ago.
  
  vicente.rios@emerson.com
   
• TPatterson

  

  In reply to Stuart Jolley:

  When you mention VIM registers, are you talking about MODBUS registers that are used to interface with a PLC? If so, when you run the FHX utility to convert your DeltaV database to a Mimic database the registers will show up as SIO tags in Mimic that you can then read/write.
  
  Another thing to consider when setting up your system is DeltaV Simulate standalone vs. Simulate multinode. With standalone you won't be able to interface with controllers, so you won't be able to use VIMs. Multinode will give you the ability to connect controllers and VIMs, and more closely simulate your process. It's more expensive, but you get a lot more functionality.
• Stuart Jolley

  

  In reply to TPatterson:

  Yes you are correct, MODBUS registers. As I've not used mimic before I'm uncertain of its full functionality but yes I do want to read/write to Modbus registers.
  
  I'm currently using DeltaV Simulate Standalone but are being upgraded to DeltaV Simulate MultiNode (PSN). I've just spent around £20k upgrading my simulate system based on Emerson's feedback, I just hope I get the functionality that I requested. Unfortunately Emerson's didn't provide an option to 'try before you buy'.
  
  I'm not sure around why I would want to interface with controllers and VIMs? are you talking about virtual controllers or physical controllers connected to the DeltaV Simulate machine? Why would I need physical controllers/VIMs.
• TPatterson

  

  In reply to Stuart Jolley:

  Since you mentioned using VIMs, I believe you'll need physical controllers (but you might be able to use virtual ones, I'm not sure) I'll let the experts handle that one. My system consists of physical controllers, VIMs, a Pro Plus with multinode simulate and several Pro stations so that the engineering staff can make changes as well as for training purposes.
  
  Best wishes.
• Stuart Jolley

  

  In reply to TPatterson:

  sounds like you have a good simulator / development system setup. I'm current in talks with Emerson to further my knowledge. Can i ask you, why do you have a physical controller and a VIMs connected to your simulator and what do you use them for?
• TPatterson

  

  In reply to Stuart Jolley:

  It allows me to copy the configuration from the Production system over without any modifications, and likewise copy any development work to the Production system as well. We also use the system to teach some hardware troubleshooting.
• Stuart Jolley

  

  In reply to TPatterson:

  this is what i want to achieve, copy from production to development and vise versa without any modifications but i still dont understand why you need a physical controller & VIMs if using a simulator environment. how do the controller and VIMs allow you to copy without any modifications. Apologies for all the questions but i am struggling with the concept of using physical controller/VIMs in a simulated environment. I sure the penny will drop soon.....
• Stuart Jolley

  

  In reply to Stuart Jolley:

  so doing a bit more reading, the penny may be dropping. Am i right in thinking the physical controller and VIM connected to your simulator network allows you to emulate the whole IO subsystem on that controller, including all the digital buses? so without the physical controller and VIMs, you cant simulate for example multiple modbus signals into a serial card which is located on a controllers IO subsystem?
  
  if this is the case, do you have a physical controller/VIM on your simulator for each controller with IO on your production system or can one physical controller and VIMs on the simulate system emulate ALL controllers and IO on the production system.
  
  Do you still assign modules to the (PPN) ProPlus workstation or can you keep the assignment to their original production controllers (which would be very beneficial) and reduce configuration effort.
• Vicente

  

  In reply to Stuart Jolley:

  Using physical controller and VIM connected to DeltaV Simulate PPN, you will be able to simulate all the register from the controller using SIO Tags (simulated IO tags). Also you can keep the assignment and configuration as an exact replica of your production system. The modules will be running in the controller.
• Matt Stoner

  

  In reply to Stuart Jolley:

  Using real controllers with VIMs will allow you to have a "digital twin" of the real plant database running without reassigning modules to other nodes. All the IO subsystems attached to the controllers (cards attached to 8-wides) are simulated by the VIM and the controller "thinks" it is talking to the real IO/devices. There are still some things the VIM won't do like replicate everything a fieldbus device does but they will still act like real devices in that you can commission/decommission the devices and have them report PVs, OUTs, etc. You will need to have a real controller and VIM for each controller from the plant system you want to commission at a time.
  
  If your system is divided up such that you don't need to replicate the entire system you could only have a subset of the system running. For example if you have 12 controllers running an entire plant and everything you need for the running of the Reactors area are assigned to four controllers, you could only commission these four controllers, have four VIMs and simulate just that portion of the plant.
  
  This is the best setup to do non-intrusive development/testing as most of your configuration doesn't change from the plant system so you are testing logic exactly what you have or will have in the real system (commissioned nodes/devices should be the only change).
  
  Another option is to still have Multi node simulate, still using real controllers (or can use Virtual ones) and not use VIMs. This would instead use OPC which still allows you to not make module assignment changes to your offline system like the VIM method. This method writes the modules to simulate (might use SUBSTITUTE_IN for fieldbus devices...been too long since used fieldbus with mimic) but may not look exactly like it will in the real plant (i.e. modules in simulate using HCD dynamos show an indication on graphics) but will operate very similar to the VIM method.
  
  Hopefully this helps explain why you want to use controllers to produce a "digital twin" of your real system.
• Andre Dicaire

  

  In reply to Stuart Jolley:

  Drop the penny... Having the physical controller with the VIM allows you to leave all modules assigned to the controller and to leave their IO blocks in their normal state, not in Simulate. The VIM allows you to drive the IO signals directly, and with a simulation package, like MiMiC, you can set up your development system to test and optimize the configuration in a "copy" of the plant. This allows you to import and export configurations consistently.
  
  The PPN and AppStation "simulation controller" is intended for Operator Training simulators, and with the Simulate Pro option, the control execution speed can be increased, decreased, frozen so that during a training scenario, the process can be accelerated or slowed down, and snapshots can be made to create scenario starting points and such. With the Physical controller, these is not possible. So an OTS will be based on the workstation emlulated controller, but a development system like you are trying to build should use physical controllers.
  
  As of v12, you are able to use virtual machine controllers for your development work. This can be a huge savings in physical hardware cost, including the power supplies and networks, not to mention the space. However, the VM controller does not support the Bus cards, only the local IO cards, and of course CHARMS.
  
  If you wish to have 100% of your development system configuration directly mirroring the production so you can import/export any module, you would need physical controllers with VIMs so that all IO references remain unchanged in the development system.
  
  If you don't have any IO Bus cards, the virtual machine controllers are the way to go to save on hardware and space and time. If you can manage the Bus Card IO references being altered to internal parameter references, you can use the Conversion tool to modify these modules. This tool is typically used for OTS configurations assigned to the Pro Plus or App Stn, and it creates a module to parameters that are then used to replace the IO paths in the control modules. You would do this once, and reassign the modules to the VM Controllers. If your optimization efforts are focused on sequences or analog tuning and such, where you will not be exporting these affected modules, that would allow you to realize cost savings.
  
  If you have SIS functions, v12 and earlier only support emulation of the SLS1508 logic solver. If you have CSLS, you have be on v13 to be able to simulate the SZ and associated CSLS logic solvers in a virtual machine environment. You have to manipulate the IO references manually in v13. There is no process simulation for the VM CSLS until v14. So physical logic solvers would require wiring up switches and feedback signals.
  
  SIS logic solvers are not managed within the OTS environment for scenarios and accelerated processing. In most cases OTS does not need the SIS system as they focus on Operator functions and process understanding via the BPCS.
  
  Having physical controllers or VM controllers allows the module assignments to remain on their controllers as the production system is. These are intended to be used for development systems or even for FAT. Typically, redundant controllers are not required so this can save some money. Note that a Simplex controller will show 10 to 20 % more CPU capacity as it does not have to process data for the redundancy link. If you are concerned about loading of controller CPU, a physical redundant controller would reflect actual loading to be expected in the redundant production controller. But in reality, the simplex loading effects can be extrapolated by adding a conservative 20% increase.
  
  The VM controllers and IO are the best value, if the Bus Card limitation is not an issue. Note that if you have MiMic, there is a different SIO driver for the VM controller and CIOC's than the VIM or OPC drivers. OTS systems use the OPC driver to read/write to simulate parameters. The OPC driver is often needed along with either the VIM or the VM Controller/CIOC drivers as you may have some signals you want to set via a parameter.

  Andre Dicaire
• Stuart Jolley

  

  In reply to Andre Dicaire:

  All, many thanks for your comments. I'm getting a better understanding and am sure this discussion will help others. It would be great to have a full 'digital twin' but as we have 9 production nodes, i think it will be very difficult to justify the cost of the hardware.
  
  What i need to do now is to set my system up and to start having a play with it, to fully understand the functionality.
  
  Couple of additional questions if you dont mind...
  
  1) For each production node i want to emulate in my simulated environment, i guess a need 2 physical power supplies, 1 controller, 1 VIMs and 2 back planes / carriers.
  
  2) What is the preferred method to copy production config to development system and vice versa? full fhx export / import or database backup/restore via admin tools?
  
  3) how does the mimic SIO license work, Emerson recommended a 1000 SIO mimic package but our full production system has just over 2000 I/O channels + a few digital bus cards. If i import my fhx into mimic, am i able to select only the channels (SIO) i want to use as part of the license count or would the import fail because my fhx exceeds the SIO license count.
  
  4) Would each modbus register on a digital bus card count as a SIO mimic license point? i.e. Mimic 1000 SIO = 1000 modbus registers?

  5) If i wanted to completed a FAT with another Vendor and their PLC using a link between the two systems (i.e. modbus over tcp/ip) would i be able to physically connect my physical controller and VIM to the 3rd party PLC using an Ethernet cable as you would in the production system?. so can the VIM also be used as a VIM or is my VIM now dedicated to I/O emulation.