Web Safety

State Transitions

State transitions for the safety documents are all configured in the TE State Transition database tables where the app value to each of the tables is set to SF.

Note: See tables te_valid_states, te_status_groups, te_statuses, te_state_transitions, te_state_actions, te_expressions, te_init_state_rules, te_state_callbacks, and te_state_cb_args for more information.

Web Safety supports the following callbacks:

Callback Action Name	Description
check_safety_crew	Determine if a crew has been assigned to the document. This check is optional and can be configured to cause the transition to fail if a crew is not assigned. For Product configuration, we also have a validation rule setup to do the crew check on the client. This is done by calling the validation group CHECK_FOR_DEVICES_AND_CREWS.
check_safety_crew_position	Validate that the crews are in one of the specified VALID_POSITION positions. Also transition them to the NEW_POSITION. An unlimited number of IGNORE_POSITION values can also be configured. These positions will be considered valid and will not be changed to the NEW_POSITION value. None of the arguments are required; they can be used separately.
update_safety_conditions	This action is used to update the status of the conditions associated to the safety document. This action requires an argument called STATUS. The status argument takes a number value. A status value of zero returns the condition back to normal so that it can be manipulated by the Control Tool. The condition cannot be removed when its status is in anything other than status zero. The status value of the condition can be used to change the symbol of the condition within the viewer. An optional argument, TAG_INFO_SCRIPT, can be used to populate the 'safety_info' attribute in the updated conditions. This argument should be set to a JavaScript code fragment that calculates the desired value. This code is passed a copy of the SafetyDocument object as a 'doc' variable.
validate_delegated_devices	Determine if the devices listed in the Delegated Zone (DCZ) document potentially isolate a section of the network.
delegate	Delegate the DCZ document to a crew. Arguments: • CREW_NAME (required) - the field that maps to the crew data. Product uses "crew.crew_id", but other projects may map to an extn field, if this name is to be user-entered. • MUST_ISOLATE_FIRST (default: false) - whether the devices need to be open and isolated for the delegation to succeed.
undelegate	Release the delegated zone.

The following is an example for the Issue state:

INSERT INTO te_state_callbacks

(app, cb_key, state_key, condition, action, abort_on_fail, error_code)

VALUES

('SF', 100, 110, 'PRE_ENTER', 'check_safety_crew', 'Y', -120);

INSERT INTO te_state_callbacks

(app, cb_key, state_key, condition, action, abort_on_fail, error_code)

VALUES

('SF', 110, 110, 'PRE_ENTER', 'update_safety_conditions', 'Y', -100);

INSERT INTO te_state_cb_args

(app, cb_key, arg_key, arg_name, arg_value)

VALUES

('SF', 110, 100, 'STATUS', '1');

INSERT INTO te_state_cb_args

(app, cb_key, arg_key, arg_name, arg_value)

VALUES

('SF', 110, 200, 'TAG_INFO_SCRIPT',

'doc.getDocType() + ''-'' + doc.getDocIdx()');

The error_codes are used to display distinct dialog messages to the user when the action fails. The messages for these error codes are configured in the MessageCode_en_US.properties file. Here is an example for error code "-120", which was referenced in the above te_state_callbacks example.

OmsClientException.SF.STATE.CALLBACK.120 = Safety document has to be assigned to a crew

OmsClientException.SF.STATE.CALLBACK.120.title = State Transition Failed

The STATUS values define what symbols are displayed in the viewer and also define whether the condition can be removed or not. Status values from 1 to 999 will restrict the condition from being able to be removed. In order for this rule to apply, the condition must inherit from parent class safetytag.

The 'safety_info' attribute in conditions associated with a safety document can also be populated by the StateTransitionCommand and SafetyConditionsCommand commands. See the documentation for these commands regarding the 'tag_info_data_source' parameter.

Safety Document Data Fields

Data fields in this case are in reference to the fields found on the safety document that are not being pulled from the associated switching sheet. Data fields can be found anywhere on the safety document.

The following is an example of how to reference these values:

data_source="DS_SAFETY_DOCUMENT_LOCAL.doc.extension.DESCRIPTION"

For more information on the list of available data source values, refer to the DS_SAFETY_DOCUMENT datastore documentation.

Search Safety Document

The Search Safety Document list is populated through the DS_SEARCH_SAFETY_DOCUMENT_LIST, which is populated from the SWMAN_SAFETY_DOCS_LIST database view. The amount of data displayed in this list will be limited to 1000 entries.

The GUI and command calls are configured in file DLG_SEARCH_SAFETY_DIALOG.xml.

The Search Safety Document list is initiated by selecting Safety Document Search... from the Open option in the Web Workspace File menu. The command that requests the search results is SearchSwitchOrSafetyCommand. This command has a parameter called "search_fields" that limits the number of fields to search in within the SWMAN_SAFETY_DOCS_LIST database view. It is strongly advised that your project keep this list to a minimum since the more fields to be searched, the more intensive the query will be on the system.

Configuring Stand Alone Safety Documents

For the most part, stand alone safety uses the existing configuration from the standard safety documents that are associated to switching sheets. There are a few additional configuration items that require additional attention when dealing with stand alone safety documents.

Safety Control Actions

The configuration table SWMAN_SAFETY_TYPE_ACTIONS plays a critical role in distinguishing key aspects that should only pertain to stand alone safety documents and not to regular safety documents associated to switching sheets. The new columns that were added to this configuration table include:

• STAND_ALONE - This indicates whether the action is allowed in a stand alone safety document. If a value other than 'Y' is specified for the action record, then the action will generate an error if the user attempts to paste this type of action into the stand alone safety document. During control tool recording, if the Real Time action being recorded is not found in this list, then no error is generated and the action is sent to the Miscellaneous log. Open and Close actions are prohibited from being associated to stand alone safety documents. Stand alone safety documents do not have event lists and cannot process event related processing.

• ACTION_MAP_NUMBER - This number is used to map key actions when safety documents are copied. For instance when copying a HOLD document as a Clearance document, the CONDADD:hold actions are all replaced with CONDADD:clear actions. This field defines that mapping in how the actions are replaced.

Flagging Safety Modifications

Stand alone safety uses a status flag called SAFETY_EDITED. This flag is defined in the SwmanParameters.properties file under the parameter STAND_ALONE_SAFETY_EDIT_FLAG. This flag determines when the safety documents tab label should be italicized. This flag should be set when a field on the safety document is edited by the user. This can be done like the following: