Emerson Exchange 365

DeltaV Objectivity Database Limitations - Number of Class-Based Control Modules / DB Size and Performance

I have a question for the DeltaV experts regarding limitations related to the objectivity database size and performance.  I have not been able to find anything that specifically addresses this topic in BOL.  I’m trying to understand impacts to the database associated with class modules.  There are two approaches to class-based design currently being discussed for our system as follows: 

• The first approach is to create a unique control module class for each device type within a unit or sub-system. This approach gives us the ability to pre-configure things like interlocks, transmitter ranges, etc… at the class level, and minimizes the need for bulk editing and instance configuration during commissioning.  The downside of this design approach is the database will have more than 1000 control module classes.

• The second approach is to use very generic class modules, and rely on bulk edit to instance configure the majority of the specifics such as interlocks, ranges, etc… From what I have gathered this appears to be the standard design approach taken for most systems.  I don’t have a good count for the expected number of class-based control modules with this approach, however I expect it will be less than 100.

 

I’m not looking for a debate on the merits of either approach. I just want to understand how this will impact the performance of the objectivity database.  If there is an order of magnitude increase in class-based control modules, does this create database performance issues?  I don’t know how the database functions on the backend, but one potential area of concern is cross references between instances and class-based modules.  For example, if there are 10,000 control module instances, and 1,000 control module classes being referenced with one approach vs. 100 classes referenced, does this have an appreciable impact to database performance?  Any insight is appreciated.

Jesse Delanoy

• 15 Aug 2024 5:19 PM
• Cancel

4 Replies

• Andre Dicaire

  

  • 15 Aug 2024 7:04 PM

  Dang, no debate? Where's the fun in that.
  
  You might want to look at using Module templates between your Classes and Instances. You could use a multiple templates tied to a common class, and in each template set up specific parameters and such for the application. A Level Loop template vs a Pressure loop template both based on a PID class.
  
  Bulk edit requires templates and it provides project level execution efficiencies. Bulk edit allows for managing parameters of the configured instances. Bypassing Templates and creating modules directly from classes means no Bulk Edits in the future. Hmm.
  
  As for database performance, you can expect that having more classes would increase database verifications and such, but whether it would perceptively impact performance I can't say. What I can say is that one of the reasons for keeping all instances linked to their class module is that future broad changes can be deployed more easily. If you have many almost identical classes and want/need to make that type of change, you have to update all those classes. Fewer classes is easier to manage. Otherwise, don't use classes at all.

  Andre Dicaire

  • Cancel
• Jesse Delanoy

  

  • 15 Aug 2024 8:58 PM

  In reply to Andre Dicaire:

  Thanks for humoring me on the no debate request. :)
  
  It appears I need to review BOL to improve my understanding of templates. I have been creating templates based on the class modules to support bulk editing, but I wasn't aware templates could be used in the manner you described above.
  
  I appreciate the concern regarding broad reaching changes and the additional work associated with multiple similar classes. This was discussed and something I initially felt was acceptable if the multi-class path was selected. It definitely creates the potential to miss a change and drive difference in configuration from area to area.
  
  At this point I am just trying to determine what path is the most intuitive for future commissioning work. Bulk editing is a powerful tool, but in my limited experience it requires good documentation / knowledge to make the connection between the bulk edit sheet and format specification file. I haven't found an elegant way to make a more generic format specification file that covers a broad range of module types. The more specific class approach reduces the bulk edit work down to alarms (for specific alarm descriptions), primary displays, DST / IO linkage. Just trying to weigh the pro's and con's of each approach.
  
  I actually started the latest project using the more generic class approach so I can better understand the specific configuration details to assess pro's and con's. Database performance is the wildcard that is somewhat concerning. The current database is only has a fraction of what it will be at full build out, and I'm already seeing sluggish performance with more complex equipment modules. I don't have enough experience with the system to know if this typical with equipment modules and many nested layers, or the result of the multi-class approach taken up to this point.

  • Cancel
• Andre Dicaire

  

  • 15 Aug 2024 10:21 PM

  In reply to Jesse Delanoy:

  What version of DeltaV are you working with? there was a KBA last year I think that identified a couple of database performance issues that were resolved in later v14 hotfix. One was exacerbated by enabling simulation on IO and so was not seen in production systems. Active database configuration has long been something that requires regular Database Cleans to defragment the Objectivity files, which consolidates the objects. Are you performing the Clean/Extended clean tasks regularly (Daily). If not, doing so may address the sluggish performance.

  Andre Dicaire

  • Cancel
• Jesse Delanoy

  

  • 15 Aug 2024 10:50 PM

  In reply to Andre Dicaire:

  The system is v14, with the latest hotfix 36 installed. I run the extended clean at least daily, some times more frequently.
  
  Can you clarify what you mean by enabling simulation on IO? You are not referring to function block simulation are you?

  • Cancel