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

• 26 Jun 2018 2:44 PM
• Cancel

21 Replies

• Todd Jaco

  

  • 3 Jul 2018 9:17 PM

  In reply to Stuart Jolley:

  Hi Stuart,
  
  I'm a bit late to the game here, but I can field some of your questions and find someone to answer the rest!
  
  2) A top-level .fhx export of the system is your easiest path forward, assuming you already have both your production and offline systems set up and working. If you are just now preparing your Digital Twin environment there are some advantages to performing a full backup/restore, but note that configuration changes may need to be made to the database to go from production to simulation environments (e.g. flipping block-level flags, changing IP's, etc.).
  
  3) Mimic SIO is licensed in 1,000 tag increments and is consumed only as needed. So if you have a plant with 2,000 I/O but it can be divided for testing purposes into 1,000 I/O or less sections then you can set up the simulation to only require 1,000 SIO. This is really up to your testing protocols and overall size of your system. Note that you can use a similar approach for hardware; if you only need to test the configuration in sections then you don't need necessarily need to procure a full set of hardware (Matt Stoner also mentioned this, but I thought it was worth repeating).
  
  5) If you have a VIM configured as a gateway (i.e. a data highway between a DeltaV controller and an external device) it can not also be a simulation VIM (i.e. tieing Mimic to physical hardware). In that scenario you would need at least two VIM's.
  
  Also, no one has mentioned Virtual Controllers. The fact that Andre and Matt are in here and this has not been brought up makes me think that there is some reason this may not be a viable path forward, but if you could use VC's and VIM's then you could get around part of your physical hardware constraint. Can anyone pro/con this for Stuart?

  • Cancel
• Matt Stoner

  

  • 5 Jul 2018 8:57 PM

  In reply to Todd Jaco:

  I did mention a method with real (or virtual controllers) and not using a VIM but the concern with this is the system doesn't appear exactly the way the real system will look and can't simulate any Hart variables. Which means in some DeltaV configurations that use the Hart variables for control, this type of system is unable to simulate unless using a VIM.
  
  I don't think the limitation is the physical hardware space, I think it's more of the cost of the hardware but if you could use VIM (or OPC) with a virtual controller and solve the problem of simulating hart variables it would help reduce the cost of purchasing the hardware of the real controller. Most customers are "ok" with the abnormal simulation icons being seen but I'm sure they would prefer not to see them and truly have a "digital twin" of the real system, if it doesn't cost too much. :)

  • Cancel
• Andre Dicaire

  

  • 29 Aug 2018 9:37 PM

  In reply to Todd Jaco:

  The virtual controllers have been brought up. The focus of this discussion involves controllers implemented with VIMs. The Virtual Controllers do not support any of the bus cards, including the serial card emulated by the VIM (or the DeviceNet and Profibus cards now available with the VIM). So chatting on about the virtues of the virtual controller (pun intended) was not going to help.
  
  The Digital Plant concept is gaining momentum, and primarily due to the acceptance of virtualization as a whole. We've had OTS and development simulators for a while, but having the entire plant simulated and connected to an emulated control system for realtime analysis and testing of ongoing situations is a big next step for production facilities. Most development systems based on physical controllers had limited scope. The virtualization of the control system makes the twin viable both in cost and footprint. The added cost of DCS hardware, power distribution, networking and ongoing maintenance conspired to limit the scope of the development system.
  
  In my opinion, a Digital Twin does not require carte blanche export and import of the production system on a regular basis. Once instantiated and configured, the Digital Plant runs on the simulated process. MCC and VFD devices can be tweaked to work via OPC Reads/Writes and thus be assigned to the VM controllers. These modules are typically stable. Optimization or problem recreation/investigation don't really care if the simulated value is passed via a VIM or an OPC call. These modules are not the ones that will be modified, tested and rolled out to the production system.
  
  If the Digital Twin is to be connected to a 3rd party PLC, the physical VIM and controller are required, if used in the production system. Looking forward, integration of PLC's is what the EIOC was built fore.The EIOC was introduced in v13 and is available as a VM, where it can be connected to the 3rd party network and function. If the Physical plant has EIOC, then the Digital Twin can have VM EIOC. Also, the PLC may also be available as a VM, with both connected via a virtual switch in the VM host environment. It's a beautiful thing.
  
  In v14, DeltaV introduces the PK family of controllers which have an integrated Ethernet IO network, similar to the EIOC. The PK can be virtualized and still have the Ethernet IO network connected to physical devices, just like the EIOC.
  
  So looking forward, the Digital Twin of the future will be VM based, making a simulation of the entire plant feasible, from both a cost and footprint perspective. For existing hardware like M or S Series controllers with VIM's or bus cards, a choice needs to be made about the use of physical controllers or a one time conversion for these IO references. Both the VM and physical implementations will serve as a Digital Plant with the process simulator.

  Andre Dicaire

  • Cancel
• ha nguyen

  

  • 3 Aug 2022 2:09 PM

  In reply to Andre Dicaire:

  Wonderful description as always, Andre. I do have a quick question on simulation options for CHARMS I/O. Our simulation needs is not complicated. We just need to simulate inputs and see outputs. We will have CHARM I/Os in the field but we do not have them in our development system. I understand that we will need a virtual CHARM I/O Card which I understand is a virtual machine running on a host computer. My question is does this virtual machine itself has an interface that I can see outputs and simulate inputs? I would rather not involve Mimic if I can help it. If this interface is not available on the virtual CHARM I/O Card, is there an alternate option without using Mimic? Our development system has a real SX controller. We are using v14.3.1. Thank you in advance.

  • Cancel
• Andre Dicaire

  

  • 3 Aug 2022 5:29 PM

  In reply to ha nguyen:

  The Virtual Machine CIOC's and physical CIOCs with Simulation enabled can be manipulated using the Charms Simulate application from the DeltaV Engineering group in the Start Menue:

  

  Double click on an Input signal to open the dialog to change value and or status:

  

  From BOL, the Pattern is explained:

  • Pattern - Use this option to turn a waveform pattern (for example, Sawtooth or Square) On or Off for the selected CHARM. The pattern is based on the CHARM's signal type. Note that Pattern must be Off to write a value. When the Pattern is turned on, the CHARM's value increments by 1.

  This will give you what you are asking for.

  On another note, there is a new Mimic license that works with DST's.  You can also define the various Bus cards with DeltaV Virtual Studio v4.  I think this will support Profibus and DeviceNet, but not Foundation Fieldbus.  I have not tried this yet.   I expect the DST license would also work with PK controller Logical Devices.  This covers the vast majority of Digital Twin requirements.  

  Andre Dicaire

  • Cancel
• ha nguyen

  

  • 3 Aug 2022 8:06 PM

  In reply to Andre Dicaire:

  Thank you so much for your help, Andre.

  • Cancel