Batch redundancy

Hi,

 

Our plan is to have a redundant pair of batch executives. For now, the plan is that the campaign manager would run on one of them. Most of our recipes will be started by a Pas-X MES sysytem.

In your opinion, is there usually a need to have two campaign managers for redundancy? If yes, how would you do it?

The other question is whether there is a way to ensure redundancy in the batch historian. The data coming from there could be critical as it needs to be forwarded to MES and our historian so we wold not like to have any downtime.

Thanks,

 

Istvan

  • Istvan,  

    redundancy on the Batch historian has been viewed as  less critical because the typical data sources, the .EVT from Batch Executive and the SQL or MDB Alarm Chronicle Events, are essentially buffered for a pretty substantial period of time in their native data source locations, typically.  I've seen batch historians off line for weeks come back without losing any data because the .EVT and chronicle still have all the missed data.  The historian simply picks up where it left off.

    You can have multiple batch historians fed from the same souces, then have your MES aggregate the data from both, and/or build a temporary table in the query  in which a 'distinct'  statement will only get 1 copy of all records.  

    Campaign manager redundancy, just like batch executive redundancy is an available supported option in v11.3.

  • In reply to Youssef.El-Bahtimy:

    Yes, thank you. In the mean time I also got som more info about the campaign manager here: www2.emersonprocess.com/.../PDS_BatchRedundancy.pdf

  • In reply to István Orbán:

    A related question: in the case of redundant batch executives, are the .evt files constantly updated on the standby?

  • In reply to István Orbán:

    Yes.  According to this:

    www3.emersonprocess.com/.../c_batchredundancydatasynchronization.html

    Runtime synchronization commences after the initial update completes and the partner is available (PAVAIL is True). The synchronization data is generated from runtime changes from the batch system (batch loaded, parameter value changed, and so on). The data is synchronized (passed to the standby) only when a change in the persistence data changes.

    The Batch Redundancy Server manages the synchronizing of the following persisted data:

    ....

    •Batch event files

    ....

  • In reply to Youssef.El-Bahtimy:

    Thank you Youssef. Is it documented somewhere, which one does the Batch Historian use as a source?

    I suppose it is always the active one. But how does it know which one is active? Is there a node-level diagnostic parameter which it monitors? I saw an ISACTIVE parameter, but according to BOL that is only for OPC.

    We have a PI historian and we would like to always connect to the active one for the events. How can we determine which one is active and which is the standby?

  • In reply to István Orbán:

    Are you using the PI EVT interface or the PI EMDVB interface?  If using the PI EMDVB you have the option to go to the DeltaV Batch Historian SQL server and avoid that concern (since it handles it for you).

    I don't think either interface affords you failover options, but rather reading both data sources simultaneously and merging the information by batchId into one PI-batch

    cdn.osisoft.com/.../PI_EMDVB_1.0.1.0.doc

    interfaces.osisoft.com/.../PI_EVTIntf.doc

    It really depends on the time dependency needs of your data.  If the primary exec fails to the secondary and pi evt doesn't follow, it will simply finish updating once the primary comes back online and re-sychronizes with the secondary.    Are you doing real-time reporting or analysis that would require the batch data always be present?

  • In reply to Youssef.El-Bahtimy:

    Thanks Youssef. We are using the EVT interface.

    As for my question on how to determine which of them is active if found out the answer: we can do that by monitoring over OPC the winname parameter. DCS01-SV002/WINNAME will change to DCS01-SV002_S if the secondary is active.