Emerson Exchange 365

• Not Answered

Insert Custom Data into Batch Historian

Hello,

I have a customer who currently uses Aspen Batch and is considering moving away from it to something else. One of the options for consideration is the DeltaV Batch Historian. In an effort to map out the pro's and con's, I am considering the methods of data entry into the Batch Historian outside that of the report parameters in a phase.

In the particular system architecture I'm looking at, there are batch related items that execute outside of the traditional phase/unit structure that we don't capture with OAR's. A couple of examples would be: Tank sticking and Operator PIN entry. In our case, we use external control modules that the batch and the operator interfaces with to enter that particular data. 

What I would like to do is have some mechanism to transfer data from those external modules into the Batch Historian for that batch. In Aspen (and probably every other external batch historian) that data and an associated trigger is monitored for collection. Can the Batch Historian do something like this? Everything I've read seems to indicate that the answer is "No."

This would be in DeltaV 14.3.LTS.

Thank you,

Dave

• batch
• DeltaV

dave_marshall

• 25 May 2021 1:50 PM
• Cancel

5 Replies

• Steven Estes

  

  • 3 Jun 2021 12:48 PM

  You could use the actions running in modules outside of the batch to trigger LOGEVENT functions that write string messages into the Event Chronicle. You could include the batch number in those string messages. The runeventview of the batch historian contains all the data from the event chronicle. If you use a tool to generate batch reports such as Infobatch you should be able to query the runeventview of the batch historian to pull this information in to the batch reports.
  
  As far as getting these events into the batch event journal with the associated batch I do not know of any way to do that.

  • Cancel
• gamella

  

  • 4 Jun 2021 5:21 AM

  I would say don't touch Batch Historian database. One of the reasons is to say compliant with CFR Part 11 and even if this is not needed, you may should consider potential issues (big issues) when upgrading/rebuilding DeltaV system.
  "there are batch related items that execute outside of the traditional phase/unit structure that we don't capture with OAR's. ", I think this is the root cause for your need. Batch items implemented outside DeltaV Batch, those will be better implemented into DeltaV Batch to have them under DeltaV Batch umbrella. So "natural" mechanism should be executing a DeltaV Batch phase that reads those values and creates Report parameter values.
  The hard part will be how to activate that phase, from executing recipe or standalone but automatically because for each use case it could be needed to implement a different solution.

  • Cancel
• gamella

  

  • 4 Jun 2021 5:43 AM

  In reply to gamella:

  Just a possible generic solution:
  - Create a EVENT buffer module containing a set of STRING type parameters. This will act as a buffer of outside Batch events you want into Batch historian so, you need to define maximum number of string parameters as buffer capacity.
  - From external control modules you can write EVENT data into those string parameters. You need to provide mechanisms to identify empty string parameter slot, to avoid overwriting events pending to be stored into batch historian, and dealing with concurrency to avoid two of those modules writing into same non empty string parameter.
  - Add ALIAS or module block into Batch Unit Class and bind an instance of that EVENT buffer control module
  - Create a PHASE that accesses EVENT buffer control module, generate Report Parameter Values using non empty string parameter values and then clear string parameter values.
  - Add this phase into recipes. I will suggest creating a new OPERATION (and eventually a new Unit Procedure). You may add this OPERATION/Unit Procedure as last step of recipe; acting as a non batch EVENT collector.
  
  NOTES:
  1-Solution is far to be perfect. In example, ABORTING will make that PHASE to not be executed and EVENTS generated before aborting will be not stored into Batch Historian.
  2-You may use Unit Parameters for string parameters buffer instead of a control module
  3-You may insert this Phase OPERATION/Unit Procedure at any step into Recipe to make EVENT be stored into batch historian as close as possible to the time the events has been generated

  • Cancel
• dave_marshall

  

  • 8 Jun 2021 9:03 PM

  In reply to gamella:

  Hi Gamella,
  
  I see what you are suggesting here, taking the event buffer idea and extending it so that it executes in a stricter environment. I agree that the challenge is to get these RP's to be sent up on any kind of regular and reliable basis. It's not like you can dynamically execute phases, unless you execute this phase in parallel with every other phase out there that you run.
  
  In our scenario, we switched to a philosophy of using EM's to execute common control items, such as header control, commodity additions, operator PIN confirmations, and so on. Sometimes it is hard to collect the data that one of the subordinate items produces.
  
  Thanks!
  Dave

  • Cancel
• gamella

  

  • 9 Jun 2021 5:50 AM

  In reply to dave_marshall:

  I see, the EM's approach it is becoming more and more popular. However it may create some issues, as this one you describe into this post.

  • Cancel