2.1-2.9 Batch Robustness

Section 2.1-2.
9 – Batch Executive Enhancements

Wyeth Advanced Training 2008
Section 2.1 – 2.9 Batch Executive

Robustness Enhancements
Page 1 of 32
COMPANY CONFIDENTIAL / Do Not Reproduce © Emerson Process Management, 2008. All Rights Reserved
Section 2.1-2.9 – Batch Executive Enhancements
Page 2 of 32
©2008 Emerson Process Management all rights reserved.
Emerson Process Management – SureService Technology, 2008. Printed in U.S.A.

While this information is presented in good faith and believed to be accurate, Emerson Process
Management – SureService Technology does not guarantee satisfactory results from reliance upon
such information. Nothing contained herein is to be construed as a warranty or guarantee, expressed
or implied, regarding the performance, merchantability, fitness or any other matter with respect to the
products, nor as a recommendation to use any product or process in conflict with any patent. Emerson
Process Management – SureService Technology reserves the right, without notice, to alter or improve
the designs or specifications of the products described herein. The training material contained in this
manual was developed by Emerson Process Management – SureService Technology for their
exclusive use. This manual and the material contained herein may not be copied, reproduced, sold,
given or disclosed to third parties, or otherwise used in whole or in part without the prior written
permission of the Director of Emerson Process Management – SureService Technology
Page 3 of 32
Table of Contents
2.1 Drivers for redesign of BEX………………………………………………………5

2.2 DeltaV v8.4.1 New Batch Executive Architecture…………………………….5
2.3 New Components of Architecture……………………………………………….6
2.3.1 The Batch Manager Service………………………………………………………6
2.3.2 The Batch Runtime Server………………………………………………………..6
2.3.3 Runner Application…………………………………………………………………
6
2.3.4 Benefits of the New Architecture………………………………………………..7
2.4 New Features Introduced in DeltaV
v8.4.1……………………………………..7
2.4.1 New Dialogs, States and Statuses………………………………………………7
2.5 Area Model Changes……………………………………………………………..14
2.5.1 New Scenarios for Area Model Changes……………………………………..14
2.6 OPC A&E events from Batch Software………………………………………..17
2.7 New Batch Logs…………………………………………………………………...19
2.8 Batch Executive Registry adjustments……………………………………….23
2.9 Changes in DeltaV Batch Executive behavior:………………………………27
Page 4 of 32
This page intentionally left blank.
Page 5 of 32
1 Drivers for redesign of BEX

 Robustness: Any issue with a recipe potentially impacts all running recipes.
BEX failure impacts all batch production.
 Scalability: Single Windows process Address Space limit of 2 Gig can limit
number of recipes loaded concurrently.
 Flexibility: Area Model changes require a stop and restart of the BEX,
impacting all running batches.
 Usability: Unable to implement new features within monolithic structure due
to limited resources of single Process
2 DeltaV v8.4.1 New Batch Executive Architecture
Figure 2.2-1 – Changes to BEX Architecture

Notes
Page 6 of 32
3 New Components of Architecture

2.3.1 The Batch Manager Service
 Responsible for managing arbitration and individual batch runners.
 Sends runtime information from the runners to clients such as Batch Operator
Interface, the Campaign manager server, and IFIX Batch Controls.
2.3.2 The Batch Runtime Server

 Provides runtime interfacing and download services to all the batch
applications. Security, Equipment, and Recipe information are examples of tasks
managed by the runtime server.
 Allows the Batch Manager to pickup Area model changes “on the fly” without
a restart.
2.3.3 Runner Application

 Coordinates all activity for a specific\single batch.
 Communicates to the Batch Manager for arbitration and prompting.
Notes
Page 7 of 32
2.3.4 Benefits of the New Architecture

 Eliminates monolithic architecture of single Batch Executive process.
 Provides ability to implement Area Model Changes for new recipes without
stopping running batches
 Robustness is improved with each batch running in its own process space.
 Removes limit on total number of recipe steps, allowing for more large recipes
to run concurrently
4 New Features Introduced in DeltaV v8.4.1

 Force Transition: Allows Operator to progress recipe through transition
 Active Step Change: Verification algorithm has been optimized and now
completes large recipe verifications in a matter of seconds
 New Active X controls: New controls for Batch list, Command Toolbar, and
Batch Comments provide greater integration of Batch operations into DeltaV Operate
environment
2.4.1 New Dialogs, States and Statuses

Batch Operator Interface - Batch Information
 Recipe State shows RUNNING instead of worst case state of a Step.
 Summary column shows number of steps in each of the possible states.
Figure 2.4-1 – BOI Batch List View
Page 8 of 32
Loading/Unloading status for a batch
Figure 2.4-2 – Batch States

Notes
Page 9 of 32
Connecting/Disconnecting Status
Figure 2.4-3 – PFC View

Notes
Page 10 of 32
Page 11 of 32
New Batch States

 Loading - Loading the batch to the Batch Executive. Occurs when creating
the batch.
 Load_Failed - Batch creation failed. To view the reason, right click the batch.
 Lost - The batch has been forced to shut down from the Batch Application
Manager or has otherwise lost communication with the Batch Executive.
 Unloading - Unloading the batch from the Batch Executive. Occurs when the
batch is removed from the batch list.
 Recovering - The batch is attempting to recover to its previous state (either
from Lost or after a Batch Executive warm restart).
 Recover_Failed - Recovery of batch failed. To view the reason, right click the
batch.
 ASC_Pending - Pending the start of an Active Step Change.
 ASC_Working - The execution of an Active Step Change is in progress.
 ASC_Failed - The execution of an Active Step Change failed
New Step States
 ASC_Pending - Pending the start of an Active Step Change.
 ASC_Working - The execution of an Active Step Change is in progress.
 ASC_Failed - The execution of an Active Step Change failed.
 Connecting - The step is in the process of connecting to the phase(s) or
step(s) it controls.
 Connected - The step successfully connected to the phase(s) or step(s) it
controls.
 Connect_Failed - The step attempted to connect to the phase(s) or step(s) it
controls but failed.
 Disconnecting - The step is in the process of disconnecting from the
phase(s) or step(s) it controls.
 Disconnected - The step successfully disconnected from the phase(s) or
step(s) it controls.
 Disconnect_Failed - The step attempted to disconnect from the phase(s) or
step(s) it controls but failed.
Notes
Page 12 of 32
Page 13 of 32
Additional states supported only by phase step

 Idle - No phase operation sequence is currently in progress.
 Held_NC - The step has been disconnected from its phase.
 Stopped_NC - The step was stopped while disconnected from its phase.
 Aborted_NC - The step was aborted while disconnected from its phase
Force Transition to progress recipe instead of Active Step Change
Figure 2-4-4 Force Transition

In order to achieve an equivalent action in the old architecture the following procedure was
used:
1. Recipe was placed in Manual mode.
2. A Stop\Abort was issued to the current active recipe step.
3. The Active Step Change menu was accessed.
4. The current step was then deactivated (minus icon).
5. The next recipe step was activated (plus icon).
6. The Active Step change was performed.
7. A Start command was then issued to the newly activated step.
8. Recipe was then placed back into Auto mode.
Page 14 of 32
Lost Batch
Lost Batch: If a batch runner process ends unexpectedly, the Batch manager shows this
batch as LOST. From this state, the user can:
1. Remove the batch and release all acquired resources
2. Restart the batch with a Warm Restart, recovering to the last point of execution.
Figure 2-4-5 Restart Selection

Notes
Page 15 of 32
Shutting down of a Batch\Runner
Figure 2-4-6 Force Shutdown
Note: All phases will go into HELD assuming the runner is down for 60
seconds and the default expression for the Watchdog timer is present in
the Failure Monitor.
Force Shutdown - This command shuts down the selected batch, forcing it to the lost state,
from which it can be restarted or removed from the Batch List. This command is only available
from the Administer Batches tab on the Batch Application Manager Advanced dialog.
Notes
Page 16 of 32
5 Area Model Changes

 Previous BEX Required a Restart to pickup any changes to the Area Model.
 New BEX picks up changes for new Batches when they are created.
 Changing the Area Model requires a download to the BEX and a download to
the affected Unit or Setup data.
 Unit definition, including assigned Phases and defined parameters.
 Changes to Phases such as addition/removal of Batch Input and Report
parameters. (Logic changes to SFC actions does not impact Area Model)
 Area Model includes Named Set data.
Order of downloads impacts behavior of BEX.
 Changing Phase and Unit Class objects that are used by running recipes can
still create operational issues because the Area Model of the running batch was
defined prior to the change in the controller.
 Generally, adding items to an Area Model has minimal impact to running
recipes.
 Deleting items from the Area Model can impact validated procedures as
failures may occur, or report data could be missing.
2.5.1 New Scenarios for Area Model Changes

 Batch Executive knows of a change that has yet to be downloaded to the
controller
 Controller knows of a change that has yet to be downloaded to the Batch
Executive
 Batch Executive and Controller are aware of a change
Notes
Page 17 of 32
Page 18 of 32
Batch Executive knows of a change that has yet to be downloaded to the controller
 Phase Class parameter is added
 Recipe is created/modified to use a new parameter
 BEX is downloaded but controller is not.
 The Old Batch Executive would not allow the recipe to load because it used a
parameter that was unknown to the Area Model and required a restart of the BEX.
 The New Executive picks up the new parameter in the Area Model when the Recipe is
created and the following message is generated to allow Operator to proceed or
address issue by downloading modified Phase.
Figure 2.5-1 – Operator Prompt

Controller knows of a change that has yet to be downloaded to the Batch Executive
 A Phase class is modified to use a new parameter.
 Phase is downloaded but BEX is not.
 Recipe does not reference the new parameter.
There is no prompt for this situation. The Parameter will remain at its default value. The
consequence of this depends on the Phase logic and use of the parameter.
Even if BEX were downloaded so that new parameter appears in Area Model, if no Operation
references the parameter, it will remain at its default value.
Notes
Page 19 of 32
Batch Executive and Controller are aware of a change

 Parameter is added to Phase logic and downloaded
 Recipe is modified to defer parameter and set via Formula
 BEX is downloaded
New recipe picks up new parameter in Area Model and references to parameter are
successful. All other Batches continue to run without need for warm restart.
Existing Batches that may call upon the same Phase Class will not be aware of the
change. Adding parameter will not impact existing recipe. Deleting a parameter
results in prompt indicating parameter does not exist.
The following changes should not be downloaded while a recipe is running or
on the batch list. Doing so may cause undesirable results.
 Deleting process cells or units that are being used by batches currently in the
Batch List
 Renaming equipment, phase classes, unit class parameters, or phase class
parameters
 Redefining unit class or phase class parameters
 Changing equipment arbitration IDs
 Adding or deleting phase class input or report parameters
Notes
Page 20 of 32
6 OPC A&E events from Batch Software

Batch Executive Events
The Batch Executive creates an entry in the Event Chronicle when significant batch
events occur. These events are available to client applications through the DeltaV
OPC Alarms and Events server.
Enable Journaling of Batch Executive events, using the Batch Application Manager.
Click the Advanced button to open the Batch Executive Advanced dialog.
The following significant Batch Executive events generate messages to the Event Journal
1. Batch Load (batch created in the batch list)
2. Batch Remove (batch removed from the batch list)
3. Procedure Started
4. Procedure Finished
5. Unit procedure Started
6. Unit procedure Finished
7. Operation Started
8. Operation Finished
9. Phase Started
10. Phase Finished
11. Resource Acquired by Recipe
12. Resource Released by Recipe
13. Mode change for any recipe in a batch
Notes
Page 21 of 32
OPC A&E events from Batch Historian

The Batch Historian creates an entry in the Event Chronicle when significant batch events
occur. These events are available to client applications through the DeltaV OPC Alarms and
Events server.
To enable Batch Historian events, set "Log=True" in the Batch Historian configuration file,
DVHExecutive.ini as shown in the following example:
[RemoteAccessHistory]
Log=True
[DBAllocation 1]
Path=D:\DVBatchHistory
Size=50
[Server 1]
ServerID=BEX_NODE_NAME
ServerType=DVBJournal
[Server 2]
ServerID=BEX_NODE_NAME
ServerType=DVBCampaign
 The Batch Historian creates an entry in the Event Chronicle for the following
significant Batch Historian events. Refer to the Process History View application's
online help for information on the contents of event records.
 Batch history started
 Batch history complete
 Procedure history started
 Procedure history complete
 Unit procedure history started
 Unit procedure history completed
 Operation history started
 Operation history completed
 Phase history started
 Phase history completed
 Campaign history started
 Campaign history complete
Notes
Page 22 of 32
7 New Batch Logs

The new Batch Executive architecture also brings a new log file structure. Since the
application is now implemented across multiple processes, additional log files are used to
capture messages from specific processes. The following tables relate the log files to their
host process and provide a brief explanation of the application in question.
These logs are not intended for the DeltaV User, but rather for Emerson developers to identify
the state of the executive and its components when investigating an abnormal event. The
content of the log files is not discussed in detail. By understanding the use and knowing the
location of the files, users will be able to quickly collect pertinent information for an
investigation of a Batch Executive issue.
The log files are designed to roll over when they reach a size of 9 MB. The current file is
renamed with a suffix of _1 to the file name and a new file is implemented. This gives up to 18
MB of log data for each application. Each configuration is different and the number of days
kept in each log must be determined by the user. It is recommended that a backup of these
logs be made to permit investigations at a later time.
Note that these new logs, except for DVBClient, use the Local Time to timestamp the log
entries. This local time simplifies correlation of log messages to the detail description of the
issue observed by the customer, without the confusion of time zone adjustments. Journals
*.evt files still log batch data in UTC format to be compatible with other DeltaV Data storage.
Logs Folder:
The table below shows the possible logs located in the DVDATA/Batch/Logs folder. Not all
these logs are present on every workstation as they depend on what applications have
actually run on those stations. For instance, the DVBClient and dvbctrlxxxxxx logs are related
to the BOI and OPERATE Active X controls used in operating the Batch software. These may
not be called on the servers and even some operator stations. Also the DVBExecutiveMgr log
only appears on the Batch Executive Node(s).
Application Log File Purpose

Batch Access server Dvbaccess.log Interfaces client applications to the batch
executive. This runs on every node servicing
BOI, Active X controls, Campaign Manager
Campaign Manager DVBCampaingMgr.log Application that schedules batches based
on defined campaigns.
Batch Operator DVBClient.log The primary Batch user interface. This is
Interface (BOI) a client application used to create, start
and operate user defined recipes in the
Batch environment.
DeltaV OPERATE Dvbctrlbatchlist.log Displays the Batch List information within
Active X control DeltaV Operate displays
DeltaV OPERATE Dvbctrlbatchtoolbar.log Displays the Batch Toolbar within DeltaV
Active X control Operate displays and allows operators to
control Batch Operation
DeltaV OPERATE Dvbctrlcomments.log Provides mechanism for Operators to add
Active X control comments to running batches from within
DeltaV Operate displays
Page 23 of 32
Application Log File Purpose

DeltaV OPERATE DVBCtrlHierarchy.log Provides mechanism for Operators to
Active X control browse the batch equipment hierarchy.
DeltaV OPERATE DVBCtrlPFC.log Displays the graphical view of the
Active X control selected recipe procedures within DeltaV
Operate displays
DeltaV OPERATE Dvbctrlpromptlist.log Provides access to Batch Prompts within
Active X control DeltaV Operate displays
DeltaV OPERATE DVBCtrlStepList.log Displays list of recipe steps for the
Active X control selected batch within DeltaV Operate
Displays.
Batch Application DVBExecutiveMgr.log Used to launch the Batch Executive and
manager manage the Advanced settings.
Batch Executive Dvbmanager.log Batch manager process controls the
Manager creation of batches, equipment arbitration,
and communication to clients.
Batch OPC Server Dvbopcsvr.log Dedicated OPC Server used by Batch
processes to communicate to Unit
Modules and their phases. This interfaces
between the DVBRunner, Batch
Executive processes and the ROC layer
of DeltaV
DeltaV Runtime Server Dvbruntime.log This process interfaces between the
DeltaV download folder and the Batch
Executive manager. Downloads to the
BEX are processed by this server,
including the parsing of the AreaModel
file.
DeltaV Recipe Dvbsim.log DeltaV Recipe Simulator allows Batch
Simulator Recipe procedures to be tested with out
the need for downloaded phases.
Softphase server Dvbsps.log DeltaV Softphase Server provides
mechanism for user defined Phase logic
written in VB or C++ to be integrated into
Batch recipes, allowing third party
integration directly into the Recipe
environment.
Remote Applications Ram.log This application is used to monitor the
Monitor health of remote services, such as the
Batch Manager from Operator Stations.
Table 2.7-1 Batch Logs folder
Page 24 of 32
Backup Folder:
In addition to these general logs, each DVBRunner process created for each batch has a set of
runtime files created within the DVDATA/Batch/Backup folder, under a folder named by the Unique
Batch ID. These files include persistence information used if the Batch must be warm-restarted. The
following files appear under the Backup folder in a subfolder named with the unique Batch ID.
File Name Purpose

Dvbrunner.log Created when Batch DVBRunner.exe process is created
to run Batch. The file persists until the batch is removed
from the Batch List and the user defined period of time
has expired, (default is 1 day) This log contains result
codes for Batch software interactions and is useful in
troubleshooting.
rrtAreaModelAndRecipeInfo.xml A snapshot of the Area Model is made when the batch is
created to allow the batch to warm-restart with the same
AreaModel information.
rrtEnvironment.xml Contains the Batch creation information, including Batch
Name, unique ID, Procedure, user, etc.
rrtpersistrc_Recipe.xml This file describes the number of steps in the Recipe,
each step representing a Unit Procedure.
rrtpersistrc_Recipe$UP.xml Each Unit Procedure that is run will cause one of these to
be created, describing each step in the Unit Procedure
rrtpersistrc_Recipe$UP$Operation.xml Each Operation that is run will cause one of these to be
created, describing each step in the Operation
rrtpersist_Report[phase_path].xml Each Phase that is run will generate this Report file to
store the result of the Phase Batch Report parameters.
This persistence is needed because the Recipe
procedures can use Phase Batch Report parameters in
transitions to control dynamically which path the recipe will
take.
rrtpersist_Bindings.xml This file lists the UP steps that are bound to equipment as
well as showing the current state of the binding for use on
a Warm Restart.
rrtpersist_parameters.xml This file shows the recipe parameters defined for the
recipe and sub-procedures.
Table 2.7-2 Batch Backup folder
Page 25 of 32
BMPersist Folder:
The Batch manager also maintains persistence information for purposes of restoring batch operation
through a Warm Restart.
File Name Purpose

Dvbbatchlist.xml Maintains current list of batches in the Batch
List.
Dvbarbitrationinfo.xml Lists all equipment that is currently owned or
arbitrated in the system.
Dvbbatch_@unique_batch_id.xml This file maintains current running time
information and process ID of the Batch’s
DVBRunner Process.
Dvbrsrc_batch_object.xml For each arbitrated object, a resource file is
maintained that shows what objects own this
one, and what objects are owned by it.
Table 2.7-3 - Batch BMPersist folder
Download Folder:
The DVData/Batch/Download folder stores XML versions of the downloaded recipe objects. The
DVBRuntime process processes the downloaded DeltaV Script files (*.SCR and Batch procedure
scripts) into XML files formatted for the new DVBatch Manager. This includes parsing the
AreaModel.scr file. While processing these files, the BOI clients are told that a download is in progress
and new batches cannot be created until this processing is complete. Otherwise, existing batches can
be acted upon by the operator.
Journals Folder:
The Journals folder behaves the same way as previous Batch Executive, storing the batch EVT files
and tracking the Eventdir.txt file for batches that should be removed from this directory. Note that EVT
file names use the “@” character as a prefix in v8.4.1.
Logs for Batch Troubleshooting
When investigating an issue with the Batch Executive or one of its client applications, Product
Engineering recommends taking a capture of the Batch LOGS, BMPersist and BACKUP folders as
soon as possible. These should be made available to Technical support upon request, along with the
Windows Event Viewer logs for those nodes involved. Other possible logs may include the
Ejournal.MDB database or an export of all events leading up to and during the anomalous behavior.
Sometimes, an issue may not be discovered until validation reviews turn up an exception in the
GMP data. If the associated logs are no longer available, the investigation may not be conclusive.
Therefore, it may be worth while to include the Batch Logs and DVBRunner directories in regular
backups to support these potential activities.
Page 26 of 32
8 Batch Executive Registry Adjustments

The DeltaV Batch Application Manager is used to manage the Batch Executive and Campaign
manager applications. The Advanced Button under the Batch Executive tab allows the user to perform
a forced shutdown of a batch runner, and to adjust certain configurable parameters.
Figure 2.8-1 Batch Application Manager Dialog
Selecting the Advanced Button displays the Batch Executive Advanced dialog. The user can select
the Batch, confirm its state and associated Process ID number, and choose to shutdown the runner.
This kills the Windows DVDBRunner.exe process but leaves the batch persistence data intact. The
batch will still be in the batch list and can be warm-restarted.
Figure 2.8-2 Advanced - Administer Batches tab
Page 27 of 32
The second tab in this dialog displays a set of configuration parameters that can be used to
alter/customize the behavior of the Batch Executive environment.
Figure 2.8-3 Advanced – Configuration Settings tab
These configuration settings are stored in a series of registry hives under the DeltaV hive. If the value
has never been modified, the registry key may not exist and the default behavior is understood. When
value is changed, its registry Key is created and is used to persist the setting.
Page 28 of 32
The following table provides an explanation for each of these settings:
Configuration Description
Setting
Purge Length of time (ms) the Runner directories are preserved in
Removed “\DVData\Batch\Backup\” after the batch is removed from BOI.
Runner Default = I day (in ms)
Directories [HKEY_LOCAL_MACHINE\SOFTWARE\FRSI\DeltaV\CurrentVersion\Batch\D
VBManager]
"PurgeRunnerDirectoriesTimeout"=dword:0a4cb800
Launching Length of time (ms) the Batch Manager will wait for a runner to come up in
runner Failed READY before assuming it never will and setting it to LOAD_FAILED.
Timeout Default = 90 seconds (in ms)
[HKEY_LOCAL_MACHINE\SOFTWARE\FRSI\DeltaV\CurrentVersion\Batch\D
VBManager]
"LaunchingRunnerFailedTimeout"=dword:00016378
Auto Launch Setting to determine if the Batch Manager will re-launch the Runtime Server if it
Runtime Server detects it is no longer present.
if it Stops Default = Yes
Execution [HKEY_LOCAL_MACHINE\SOFTWARE\FRSI\DeltaV\CurrentVersion\Batch\D
VBManager]
"RelaunchRuntimeServer"=dword:00000001
No Equipment If the option is set to Yes, it specifies that all operator actions on batches with
Acquired no active equipment will still require the corresponding security privilege in
Security Check AREA_A. If option is set to No, then no security check is required for batches
without active equipment.
Default = No
VBManager]
"NoEquipmentAcquiredSecurityCheck"=dword:00000001
Prompt Specifies whether the operator should be prompted with a choice to continue or
Operator on not if there are phase configuration mismatches between the controller and the
Apparent Batch Executive. If set to No, batches with mismatches will be put in the Held
Config Errors state.
Default = Yes
VBRunner]
"PromptOperatorOnApparentConfigErrors"=dword:00000000
Confirm Config Setting to determine if a confirmer is required for configuration error prompts.
Error Prompts Default = No
VBRunner]
"ConfirmationRequiredForConfigErrorPrompts"=dword:00000001
Page 29 of 32
Configuration Description
Setting
Verify Config Setting to determine if a verifier is required for configuration error prompts.
Error Prompts Default = No
VBRunner]
"VerificationRequiredForConfigErrorPrompts"=dword:00000000
Check Phases Runner checks to see if BSTATUS is good for all phases in recipe upon load.
on Batch load Default = No
VBRunner]
"CheckPhaseOnBatchLoad"=dword:00000001
Enable Alarm Specifies whether the Batch Executive should create an entry in the Event
and Events Chronicle for significant Batch Executive events (additional information in BOL
Journaling – Batch Executive Events topic).
Default = No
VBRunner]
"EnableAlarmsAndEventsJournaling"=dword:00000001
Enforce Batch Specifies whether a check should be done on the size of the batch. (If set to
Size Check No, created batches can be scaled to exceed the maximum "batch size"
defined in the recipe.)
Default = Yes
VBManager]
"EnforceBatchSizeCheck"=dword:00000000
Check Failed Rescans for the initially unresolved or unassigned equipment when only a
Control recipe-related change is present and the Batch Executive download is
Network Items performed. The default is No (that is no rescanning when only a recipe-related
on Download change is present and the Batch Executive download is performed). If an
equipment-related change is downloaded, the rescan will occur automatically,
regardless of this setting.
If this option is set to No and the following option (Check on Verify Phases) is
set to No, the Batch Executive will not attempt to rescan for the initially
unresolved or unassigned equipment unless an equipment-related change has
been downloaded.
Default = No
VBManager]
"CheckFailedItemsOnDownload"=dword:00000001
Check Failed Rescans for initially unresolved or unassigned equipment when the Verify
Control Phases button is clicked. The default is No (that is no rescanning for initially
Network Items unresolved or unassigned equipment occurs when the Verify Phases button is
When Verify clicked).
Phases Default = No
VBManager]
"CheckFailedItemsOnVerifyPhases"=dword:00000001
Page 30 of 32
9 Changes in DeltaV Batch Executive behavior:

Apart from new functionality introduced with the redesign of the Batch Executive, there have been a
number of subtle changes in behavior that were encountered by customers following their upgrade to
DeltaV. These are listed here. Some have or will be restored to previous behavior as noted.
 Step states in Recipe have different transitory states. The final state of the recipe Step is no
longer Ready, but Unloaded. The Step transitions to Complete and remains there until the
following transition fires and the recipe moves on. When this occurs, the Step state goes to
Unloading, then Unloaded. Previously the state went to Idle and then Ready. A Transition
Expression that evaluates a Step state that is not directly connected to the transition may
need to be modified to use either a Unit parameter or a Report parameter to trap the required
condition.
The following is a complete list of the regular recipe step states (i.e. not an initial step,
terminal step, or phase step) in order of occurrence, under normal operating conditions:
LOADING (transitory)
LOADED
BINDING (transitory)
BOUND
SELECTING (only if UP step with Acquire Before checked)
ACQUIRING
ACQUIRED (transitory)
READY
STARTING
RUNNING
COMPLETE
IDLE
DISCONNECTING (transitory)
DISCONNECTED
UNLOADING (transitory)
UNLOADED
The following list documents a phase step under normal operating conditions:
LOADING (transitory)
LOADED
BINDING (transitory)
BOUND
ACQUIRING
ACQUIRED (transitory)
CONNECTING
CONNECTED (transitory)
READY
STARTING
RUNNING
COMPLETE
RESETTING
IDLE
DISCONNECTING
DISCONNECTED
UNLOADING (transitory)
UNLOADED
Page 31 of 32
 Unit parameter displaying Batch Information clears after each Phase as part of the Phase
Unloading process, and is reset when the next phase loads. When the last phase completes,
the parameter is cleared and remains so, even though the Unit may remain acquired by the
recipe.
This is being investigated to restore previous behavior.
 Unit Aliasing is not working as expected in v8.4.1. Units bound to an Alias in the Recipe are
not being acquired properly. Track 78138 has been filed and this is to be corrected in v8.4.1
hotfix.
 Recipe Transition expressions require a valid operand. Previous version evaluated a single
variable expression for true or false condition such as ‘BOOL_VAR.CV’. New executive fails to
load recipe with such an expression, requiring a change to ‘BOOL_VAR.CV’ = TRUE to get
the desired result. This is track 78253 and is corrected in v8.4.1 hotfix.
 Active Step Change is not possible when procedure is on first step with first transition
evaluating to false. The previous executive allowed this to occur. If an Operation for example
evaluated a process variable in the first transition before proceeding to load the first Phase,
the ASC cannot be applied, and neither can a Force Transition. The user must consider:
 Performing the Active Step change at the Unit Procedure level
 Forcing the Process condition to satisfy the transition, once past this point, an ASC
can be performed. (This approach depends on whether it is acceptable to load the
phase(s) the ASC may have been intended to bypass)
 Modify the procedure to place a null step such that the procedure waits on the second
transition for the process condition.
Track 79535 has been logged against this issue. Current resolution is to allow Force
Transition to facilitate moving the procedure to a point where ASC can be performed.
 ASC is no longer permitted from the COMPLETE state. Previous version allowed this. ASC is
only allowed when the recipe is in one of the other terminal states or when initially loaded but
not run.
 Range enforcement of deferred parameters is now applied at run time. During the design of
recipes, deferred parameters were required to have a valid range equal to or smaller than the
source, with the Phase level range defining the maximum range for the value. However, this
was not enforced at run time and if recipe was downloaded anyway, a recipe could write a
value that fell outside the design limits of the Phase. The new executive will fail to load the
recipe if the ranges are inconsistent.
 The Force Transition feature uses the Stop Logic of the phase. In previous releases, an ASC
was required to move through a transition, requiring the user to bring the recipe to a terminal
state, either Stopped, Held or Aborted. As a result, the user chose what phase logic would be
run as part of the ASC. With Force Transition, the user must know that the STOP logic is
used on the Phase/Step(s) preceding the forced transition. The Force will load the next
Step(s) and issue the Stop command to the previous steps, and wait for these steps to be
Stopped. If the Stop logic fails to complete and the phase(s) remain in STOPPING state, the
force transition will not proceed.
Page 32 of 32

2.1-2.9 Batch Robustness

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2.1-2.9 Batch Robustness

Uploaded by

Copyright:

Available Formats

Section 2.1-2.

9 – Batch Executive Enhancements

Section 2.1 – 2.9 Batch Executive

©2008 Emerson Process Management all rights reserved.

Emerson Process Management – SureService Technology, 2008. Printed in U.S.A.

2.1 Drivers for redesign of BEX………………………………………………………5

This page intentionally left blank.

1 Drivers for redesign of BEX

2 DeltaV v8.4.1 New Batch Executive Architecture

Figure 2.2-1 – Changes to BEX Architecture

3 New Components of Architecture

2.3.2 The Batch Runtime Server

2.3.3 Runner Application

2.3.4 Benefits of the New Architecture

4 New Features Introduced in DeltaV v8.4.1

2.4.1 New Dialogs, States and Statuses

Figure 2.4-1 – BOI Batch List View

Loading/Unloading status for a batch

Figure 2.4-2 – Batch States

Figure 2.4-3 – PFC View

New Batch States

Additional states supported only by phase step

Figure 2-4-4 Force Transition

Figure 2-4-5 Restart Selection

Shutting down of a Batch\Runner

Figure 2-4-6 Force Shutdown

5 Area Model Changes

2.5.1 New Scenarios for Area Model Changes

Figure 2.5-1 – Operator Prompt

Batch Executive and Controller are aware of a change

6 OPC A&E events from Batch Software

OPC A&E events from Batch Historian

7 New Batch Logs

Application Log File Purpose

Application Log File Purpose

Table 2.7-1 Batch Logs folder

File Name Purpose

Table 2.7-2 Batch Backup folder

File Name Purpose

Table 2.7-3 - Batch BMPersist folder

Logs for Batch Troubleshooting

8 Batch Executive Registry Adjustments

Figure 2.8-1 Batch Application Manager Dialog

Figure 2.8-2 Advanced - Administer Batches tab

Figure 2.8-3 Advanced – Configuration Settings tab

The following table provides an explanation for each of these settings:

9 Changes in DeltaV Batch Executive behavior:

You might also like