Emerson Exchange 365

Alternatives to Embedding Module Blocks into Equipment Modules Discussion, Pros and Cons

As per the subject really.

Using PCSD shell Equipment modules would lead you towards embedding Module Blocks into your Equipment Modules, which is fine but is a little limiting as it only allows access to parameters at the top level of the embedded module instances.

Previously I've used Dynamic Reference composites and bespoke external reference composites to overcome this limitation, but each has it's own pros and cons. 

I'd like to throw it open to the community (developers and end users) to discuss the pros and cons and see if there is a consensus on the best approach. Perhaps listing any system performance issues using any of the approaches may have.

Here are some of my initial thoughts on the three options I've considered.

1. Embedded (DEVX) Module Blocks

(as per DeltaV product intent presumably), major downside this only lets EM code reference top level parameters of the embedded Modules, but can check for cross references to a device and us the device IGNORE function and allows for Private/Shared representation and binding withing the control strategy hierarchy (the only method that allows this)

2. Embedded (DEVX) Dynamic References composite that contain sufficient dynamic reference parameters for your purpose that are bound on first download using a single DEVX_ID string parameter containing the module name.

These allow access to any module parameter (not just top level), they can be easily enhanced should you find you need access to further modules parameters. Main con is that you can't check for cross references (in explorer), clients (maintenance/debuggers) don't particularly like this for obvious reasons.

3. Embedded (DEVX) External References composite that contain sufficient external reference parameters for your purpose.

These allow access to any module parameter (not just top level), they can be easily enhanced should you find you need access to further modules parameters. A pro compared to dynamic reference composites is that you can check for cross references (in explorer). The downside compared to dynamic reference composite is that configuration is more tedious where you only need to specify the module tag in a string rather than configuring potentially bundles of reference strings per DEVX composite.

IntuitiveNeil

• 6 Jun 2017 10:11 AM
• Cancel

11 Replies

• Michael Moody

  

  • 6 Jun 2017 2:50 PM

  Neil,
  
  My thoughts on those options are ...
  
  1. Embedded (DEVX) Module Blocks
  
  I like this approach for organizational purposes as it documents which CMs are under the control of a given EM. I agree that the inability to drill down below the first level of parameters is limiting. We would commonly provide parameters on the top level of the CMs for commonly accessed lower level parameters. In other cases, we would add an external reference to the EM that would need configuration on instance level. These work, just not as cleanly as I would like.
  
  Your option 1 is still my preferred method provided I can get to the parameters I need. Maybe Emerson will enhance the capabilities around embedded Module Blocks in the future.
  
  2. Embedded (DEVX) Dynamic References composite that contain sufficient dynamic reference parameters for your purpose that are bound on first download using a single DEVX_ID string parameter containing the module name
  I avoid dynamic references unless there isn’t another good option. I’ve seen issues (v9 & v10) where the EXEC_TIME or an EM increased by a factor of 10 when a dynamic reference in it was not resolved. Since the dynamic reference was used to dynamically reference parameters in other modules on demand, it was very common (over 50% of time) the dynamic reference would not be set. We had to modify to reference a dummy variable when not in use. So, there were ways to work around the issue, but this turned me off to the dynamic references.
  
  3. Embedded (DEVX) External References composite that contain sufficient external reference parameters for your purpose
  I’ve used this method when I didn’t need to (or couldn’t) organize the CM under the given EM (or CM). I found this method more configuration intensive as each parameter reference had to be set.
  emersonexchange365.com/.../6447
  I would love to see the Internal Reference and External Reference parameter types be replaced with a single Reference parameter. The internal / external paths would be determined by the method used to denote the parameter path (just like how it is done in a calc block or action in a sequence). This would be very helpful in class based Ems. We often wanted to reference a dummy variable in an EM or CM when an external parameter didn’t exist.

  • Cancel
• Alfred Pol

  

  • 6 Jun 2017 7:42 PM

  In reply to Michael Moody:

  In reply to the last point in your post, it is possible to browse an internal dummy parameter with an External Reference.

  • Cancel
• Michael Moody

  

  • 6 Jun 2017 8:10 PM

  In reply to Alfred Pol:

  Hi Alfred,
  
  You are correct that it can be done. If I remember correctly, I had to browse the long way around and enter the path as an external parameter that just happened to be located in the same control module. In some cases, it would be beneficial to default to a dummy parameter and then configure as needed on the instance level. This really isn't possible (as far as I know) since the control module name would need to be in the external parameter path. If there is a way to do this otherwise, I would love to know it.

  • Cancel
• Alfred Pol

  

  • 6 Jun 2017 8:35 PM

  In reply to Michael Moody:

  True, you have to configure every External Reference at instance level (or use Aliases in the default reference in the class module).

  • Cancel
• Matt Stoner

  

  • 6 Jun 2017 9:23 PM

  I agree with everything that Michael has stated but there is also another option to consider.

  Equipment Modules along with other modules can be placed under class based unit instances and the logic (EMs, Modules, Interlocks, etc) can use the aliases of the unit instance in their logic.

  • Pros:
    • Any parameter of any block in a module is usable at any time as long as the unit class alias is only resolved to the module name (no massive downloads of module class instances to get to a new parameter needed for a class!).
    • No issues because of parameter differences while importing between the module class used for the module block alias and the resolution of that module block alias to the module instance required for that alias. Module block aliasing is really picky with linkages to module classes for the module blocks (instance resolutions has to match exactly all the parameter structures of what the class used has). An example where a module that was a certain class type that had to change from an AI (Phase 1) to a PID_LOOP on a new EM class (Phase 2), the configuration (EM class, instances and modules) being imported would fail if the module level parameters of the AI and PID_LOOP don't match. When this occurs a lot of manual work has to be done to figure out why it failed and then fix the problem(s) identified with module(s) manually (the error trapping for this isn't very intuitive as to what the real problem is for this case, which for this example would be to manually convert the AI module to a PID_LOOP module).
  • Cons:
    • It does require the Advanced Unit Management license which is counted by the number of class based unit instances used in the current version, while pre-v12 versions was DST based. This is typically considered too costly but some customers have done their own evaluation between previous experiences using module blocks for aliasing and using unit instance aliases and concluded that this expense is well worth it to them.
    • References of a module aren't caught by the tag being used in a Unit instance alias (dynamic reference setups are also not found).

  It would be outstanding if this type of aliasing was somehow a part of the EM itself and didn't require a Class Based Unit instance or module blocks to do the aliasing as this method for aliasing is by far the best solution for both configuration and operations of the plant.

  • Cancel
• Pieter Degier

  

  • 6 Jun 2017 11:00 PM

  Neil,
  
  I agree with all your thoughts and I always using option 3, because option 1 cannot be used if you do have a slightly different class for some modules. By using bulk-edit for creating the external references in the EQM instances I found it quit workable to work around extra amount of work. Another downside of option 1 is that when you change something in one of the modules I noticed that often a download of the whole EQM and all of its modules is required.
  Note that in version 13 you can use #IGNORE for external references and a 'DUMMY' is not required, but the downside of that is that the reference does not get a nice defined value.

  • Cancel
• gamella

  

  • 7 Jun 2017 6:30 AM

  Some points to consider:
  1- Download behavior. Currently command/state-driven EQM parameters dos not retain their value after download. Having a module block rather than a composite hosting EQM is a solution for that. Also note that setting same name in module block as composite eliminates the need to re-code SFCs. I use to replace TP parametrs by a a module, having all TPs, declared as private into EQM class. This also opens a door to implement additional functions as having a dedicated module instance for each EQM instance allows to implement enhanced parameter management (enable/disable, lock/unlock based on process conditions) without worring about EQM classes modification.
  2-Module block bound module provide it's own dynamo, faceplate, detail and primary display. Function block dynamos or faceplates may be used with composites but it's not currently part of PCSD items.
  3-Execution times, module block approach allows setting differen scan rate on underlying modules.
  4-When related modules are deployed into different controller we have the issue that partial download could destroy inter-controller communications the requires download of setup data to be fixed. DeltaV explorer has specific features to handle that when using module blocks, using "download equipment moduls and contained non sis modules" option.

  • Cancel
• IntuitiveNeil

  

  • 7 Jun 2017 7:17 AM

  In reply to Matt Stoner:

  Great stuff Matt, we were trying to avoid AUM, but perhaps the system life cycle costs could be a swaying factor.

  • Cancel
• IntuitiveNeil

  

  • 7 Jun 2017 7:19 AM

  In reply to gamella:

  Some interesting information about download behaviour to consider, thanks

  • Cancel
• IntuitiveNeil

  

  • 7 Jun 2017 7:24 AM

  In reply to Pieter Degier:

  Thanks Pieter, I noticed the new #IGNORE functionality yesterday in a previous post on Dyn Refs and cross referencing issues by Matt Stoner. Which pointed me towards the use of it within PCSD v13 rather than Dyn Refs.

  • Cancel
• IntuitiveNeil

  

  • 7 Jun 2017 7:37 AM

  In reply to Michael Moody:

  Thanks Michael,
  
  Agree CM classes should have all you need at the top level to give that good abstraction layer. But I think we know this is never quite the case and we end up with those annoying external references added outside the module block to prevent big downloads.
  
  I suppose the big downloads for the use of composites could be argued.
  
  Agree throwing in an external reference parameter to access that parameter you need is the quickest least impact W.R.T. size of download. And this is the case for all three options. But it sort of mixes implementation philosophies.
  
  Matt's alias option (option 4) seems to be the only solution that prevents the download "chain reaction" and maintains a consistent implementation approach.

  • Cancel