Workflow

This workflow describes the process for designing and validating policies. Policies can be used to automate GE Digital APM workflows by generating email alerts, as well as creating, deleting, or updating records used in the other workflows based on the input values and policy logic.

Blue text in a shape indicates that a description is provided for that step in the following sections. For more information, refer to the topic Interpreting the Workflow Diagrams.

Persona: Analyst (Strategy)

During implementation of an Asset Strategy, the Strategy Analyst may identify policies needed to address Strategy Actions. For example, policies can calculate health indicators, create event logs, and/or provide automated decision support. Actions may be implemented as policy instances or health indicators that are updated by a policy.

Persona: Analyst (Strategy)

Determine whether you can modify instances associated with an existing policy to address strategy actions, or if you must create a new policy or modify a policy model or execution settings.

Persona: Various

Policies may use content that is produced in other APM workflows:

• Queries to access data for analysis.

• R Scripts for custom calculations.

• Rules to implement custom actions.

• Lookup or conversion tables created in GE Digital APM (especially where a mathematical function defining the values to use is unavailable, for eaxmple, derived empirically; defined in regulations; looked up from manufacturer data such as a pump curve, etc.).

Persona: Solution Administrator (Policy)

Once the required policy logic is outlined and required inputs from other GE Digital APM workflows are defined, design the policy by adding nodes and links to the policy design canvas and configuring them appropriately. Where a policy will take action such as creating a recommendation or sending an email alert, consideration should be given to whether the policy instance needs to be deactivated once the action is taken, to avoid duplicate requests and alerts.

Persona: Solution Administrator (Policy)

Validate the policy using Ad Hoc inputs to verify that all of the required inputs to each node are configured and that the policy returns the correct values for a simple use case. After this is verified, proceed to verify that the policy handles more complex edge cases (for example, if a query used in the policy returns no rows, dividing by zero, etc.).

To facilitate Ad Hoc validation, you can set up a policy instance and use the Copy to Ad Hoc feature to use instance values as a starting point. You can then edit the values as needed to test various scenarios. This approach is necessary in certain scenarios, as some nodes (for example, the AMS Asset input node) do not feature complete Ad Hoc validation capability. In these cases, you must use an Instance to access test records in the database (for example, example event records).

Persona: Solution Administrator (Policy)

Configure the policy to be executed automatically (when a change occurs in a policy instance input that is set to trigger the policy) or according to a predefined schedule. It is also possible to set a policy to execute both automatically and on a schedule, but the use cases where this is required are rare.

Persona: Solution Administrator (Policy)

Once the policy and its instances have been thoroughly validated, activate the policy so that the active policy instances associated with the policy will be executed according to the defined execution settings.

Persona: Analyst (Policy)

Add policy instance(s) to associate a set of existing, related records in the database with the policy.

Typically, each instance of a policy would represent a different asset on which the policy will operate. In some cases, a policy could have multiple instances per asset, where each instance is related to a different input data source (for example, Measurement Location or Health Indicator).

Persona:  Analyst (Policy)

Validate each instance to ensure that the correct records are specified and that the expected results are returned. If you are adding a large numbers of instances, at least a significant sample of them should be validated.

Persona:  Analyst (Policy)

Activate the instances that you want to be executed (according to the policy's defined execution settings).

In some policies, not all instances may be active at all times. For example, you may deactivate instances related to assets that are out of service or undergoing testing or maintenance. Or, an instance may be deactivated by a Deactivate This Instance node included in the policy design to prevent repeated alerts or recommendations being generated.

Persona: Automated Process

The policy is executed according to the execution settings.

Go to the Execute Policy workflow.

Persona:  Analyst (Policy)

Periodically review policy execution history to ensure that policies are functioning as expected. This review may reveal policy instances that need to be reactivated, edge cases that were not considered during policy design, policy execution settings that are inappropriate for the dynamics of the process being monitored, etc.

This workflow describes the automated policy execution process. Depending on the input values and policy logic, policy execution may generate email alerts, as well as create, delete, or update records used in other GE Digital APM workflows.

Blue text in a shape indicates that a description is provided for that step in the following sections. For more information, refer to the topic Interpreting the Workflow Diagrams.

Persona: Automated Process

For policies configured for scheduled execution, the policy is executed when the schedule is due (i.e., date and time configured in a policy schedule is reached).

For policies configured for automatic execution, the policy is executed when a policy trigger occurs (i.e., a change occurs in an active policy instance input that is set to trigger the policy).

Persona: Automated Process

When a policy schedule is due or a policy trigger occurs, a message is added to the policy trigger queue. The policy trigger queue processes each message and packages policy executions.

Persona: Automated Process

The Policy Trigger Service monitors the policy trigger queue and sends messages to an appropriate policy execution queue.

These messages contain information about the trigger time and relevant trigger values (if applicable), so that all changes to the same policy input are captured and processed in order.

Persona: Automated Process

The Policy Execution Service monitors a corresponding policy execution queue and executes the policies that are added to it.

Messages are processed in order, but note that policy execution is a multi-thread operation and may be distributed across multiple GE Digital APM servers. Therefore, it is possible for a given policy execution to end after another execution that was after it in the queue.

Persona: Automated Process

If the policy is operating on a schedule, all policy instances will be checked to determine whether they are active, and then processed in turn. If an instance is inactive, it will be skipped.

Persona: Automated Process

The input data needed for each instance execution is retrieved from the database.

Persona: Automated Process

Depending on the policy design, the policy instance execution may create, update, or delete records in the GE Digital APM database or it may send email alerts. In addition, the policy instance may be deactivated after execution to prevent generation of multiple email messages, events, or recommendations in response to a continuing asset condition.

For each instance execution, a policy execution record is created and server log messages may be added (these messages are written according to the settings in the Policy Execution Service configuration settings and their level of detail may vary).

Persona: Automated Process

Policies can create, update, or delete records used in any other GE Digital APM workflow.

Persona: Various

The results from a policy execution may be used in, or trigger, any other GE Digital APM workflow.