OPC UA Control Over ICCP Devices

You can use either Select Before Operate (SBO) or Direct Operate (DO) to issue commands and set or clear points on an ICCP peer device.

On this page:

Select Before Operate (SBO) and Direct Operate (DO)

SBO is a two-stage, select-before-operate process with confirmation following the select. Using this process, a client has to select the control object. After selection, the selecting client is the only one allowed to perform control actions. An ICCP Check Back is required for all Select Before Operate controls. A Check Back is identified using an arbitrary number, agreed upon by the local ICCP client and the remote ICCP server; the remote ICCP server returns to the local ICCP client as a result of a Select operation. However, if the Select operation is successful, the application’s OPC UA client is not notified; the OPC UA client is only notified if there is an error returned from the Select operation.

DO is a single-stage direct operate process with no select-before-operate stage. The direct control models provide a simple means to start actions on the LEC Server instance. If multiple clients are trying to perform conflicting control actions, the LEC Server instance will finish one of the operations successfully but will fail and return an error message for any additional operations. If conflict prevention is required, the Select Before Operate process should be used.

Back to Top

Commands and Setpoints

ICCP distinguishes between device operation (commands) and setting and clearing numeric values (setpoints) using the following objects:

COMMAND – ICCP allows 16-bit, integer-based control actions for each control point such as Open (0) and Close (1) or floating-point values. The following table shows some of the integer-based values and their meanings for different devices.

0 1 Device

Trip

Close

Switch

Open

Close

 Switch

Off

On

 Switch

Lower

Raise

Transformer

Note: Boolean values are represented by the integer values 0 and 1.

SETPOINT – ICCP’s setpoint object can hold floating-point numbers or integers.

Back to Top

LEC Flags for SBO and DO Controls

LEC Server has a Flags property for the ControlToIccp and ControlFromIccp templates that allows you to specify the type of control to use for a particular point. Any point defined by one of these templates is a control point. You can specify more than one flag to define a control point by using a bar (I), for example: DISCRETE|SBO.

  • REAL – The control point is a floating-point number. If a control point is a floating-point number, it is a setpoint.
  • DISCRETE – The control point is an integer. If a control point is an integer, it is a setpoint.
  • SBO – The control point supports Select Before Operate (SBO). If SBO is not specified, then the control point does not support SBO and uses Direct Operate (DO), instead.
  • TAGABLE – The control point supports tagging. If TAGABLE is not specified, then the point does not support tagging.

Note: The default type of a control point is a command point. In order to indicate that a point is a command, do not specify either REAL or DISCRETE.

Examples of points that are defined by these flags are described in #Blk5FromIccp and #Blk5ToIccp. For more information on tagging, see the Tagging section.

Back to Top

Issue a Command or Set the Value of a Setpoint Using SBO

The SBO protocol is outlined in the following image. LEC Server has a green overlay, and the OEM application’s OPC UA client has a blue overlay.

Select Before Operate Workflow

The following are steps required to issue a command or set a setpoint using the Select Before Operate protocol with and without Block 7 support.

  1. The application’s OPC UA client’s write request variable to the local OPC UA server. The OPC UA client variable has the following structure: Value, which is a command or a setpoint. The possible value for a command is an integer, specifying one of two possible actions to be taken on a device in the field such as 0 for Open and 1 for Close, or 0 for Off and 1 for On. The possible values for a setpoint are either a floating-point number or an integer.
  2. The local OPC UA server checks the write and sends a write callback if the Write times out or returns an error. If there is no error, then the Local OPC UA server goes to step 3 in the sequence without sending a callback.

    If an error occurs, such as an access right violation, error message or number, or something else, the local OPC UA server stops the sequence and sends a callback message with the result back to an application’s OPC client. This message is returned in the Status field of the OPC client write response variable.

  3. The local OPC UA server sends a Select to the remote ICCP device.
    1. If there is no error, then the local OPC UA server goes to Step 4 without sending a callback.
    2. If there is an error, the local OPC UA server stops the sequence and sends a callback message with result back to the application’s OPC client. The result is returned in the Status field of the OPC UA client variable.
  4. The local OPC UA server sends an Operate (Block 5) to ICCP.
    1. If there is no support for Block 7, the OPC server does not wait for the operation to complete. Instead, local OPC UA server sends the Block 5 response back to the OPC client, which indicates whether or not the ICCP Block 5 Operate was received by the remote ICCP server, but there is no indication whether the Operate succeeded or failed. The result is returned in the Status field of the OPC UA client variable. After the Operate completes, whether it succeeds or fails, the Select is implicitly cleared.
    2. If there is support for Block 7, then the local OPC UA server goes to Step 5 before sending the Block 5 response.
  5. The local OPC UA server waits for the Block 7 event to complete or the local OPC UA server receives a timeout message. If the Block 7 event completes within the configured time period, the local OPC UA server sends a callback with a translated ICCP result (indicating success) to the application’s OPC client.
    1. If Block 7 does not complete within the timeout period or if there is an error, local OPC UA server sends a Write response with the translated ICCP result to the application’s OPC client. The result whether successful or unsuccessful is returned in the Status field of the OPC UA variable.

For a list of possible messages that ICCP returns and how LEC Server translates these messages into OPC UA status codes, see Mapping between Returned ICCP Status Names and OPC UA Status Names for Block 5 Data.

The following image shows a simple illustration of SBO when an OPC UA client issues a Block 5 command without Block 7 support.

Image of a simple illustration of SBO when an OPC UA client issues a Block 5 command without Block 7 support

The following image shows a simple illustration of SBO with Block 7 support.

Image of a a simple illustration of SBO with Block 7 support

Back to Top

Issue a Command or Set the Value of a Setpoint using DO

The following list describes the steps required to issue a command or set a point using the Direct Operate protocol with and without Block 7 support.

  1. The application’s OPC client writes a variable to the local OPC UA server. The OPC UA client write request variable has this structure:
    • Value, which is a command or a setpoint.
      • The possible value for a command is an integer, specifying one of two possible actions to be taken on a device in the field such as 0 for Open and 1 for Close, or 0 for Off and 1 for On.
      • The possible values for a setpoint are either a floating-point number or an integer.
  2. The local OPC UA server checks the write and sends a write callback.
    1. If there is no error, then the local OPC UA server goes to Step 3 in the sequence without sending a callback.
    2. If an error occurs, such as an access right violation, error message or number, or something else, the local OPC UA server stops the sequence and sends a callback message with the result back to the OPC client.
  3. The local OPC UA server sends an Operate (Block 5) to the local ICCP client.
  4. The local ICCP client then sends an Operate (Block 5) to the remote ICCP server.

If Block 7 is not supported, the OPC server does not wait for the operation to complete. Instead, the OPC server waits only for the remote ICCP server to respond to the Operate request. Then the local OPC UA server sends the Block 5 response back to the OPC client in the Status field of the OPC client variable. The returned value indicates whether or not the remote ICCP server received the Block 5 Operate request; it does not report whether the Operate succeeded or failed.

The following shows the DO Block 5 Write Operate and response sequence.

Image of the DO Block 5 Write Operate and response sequence

If there is support for Block 7, the local OPC UA server waits for the Block 7 event to complete or issues a timeout message. If the Block 7 event completes within the time period, the local OPC UA server sends a callback with the result (indicating success) to the application’s OPC client.

If Block 7 does not complete or if there is an error, the local OPC UA server returns a Write response to the OPC client in the Status field of the OPC UA client variable .

The following is an image showing DO Block 5 write to a remote ICCP Server with Block 7 support:

Image showing DO Block 5 write to a remote ICCP Server with Block 7 support

For a list of possible messages that ICCP returns and how LEC Server translates these messages into OPC UA status codes, see Mapping between Returned ICCP Status Names and OPC UA Status Names for Block 5 Data.

Back to Top

Tagging

Tagging is the mechanism through which OPC UA clients can protect utilities technicians and equipment (usually during maintenance) by hanging a red tag (logically, not physically) on a device to prevent the device from running subsequent operations. OPC UA clients can set, clear, and monitor tags in remote ICCP servers. Setting, clearing, and monitoring are all Block 5 operations.

Back to Top

Setting and Clearing Tags

The application’s OPC client can set or clear a tag in the local OPC UA server by writing to the tag variable. A tag kind of 1 or 2 sets a tag, and a tag kind of 0 clears the tag. The local OPC UA server then passes the data in the tag item to a tag in the specified remote ICCP server. The tag state format for write (set) and monitor/read (get) is composed of three comma-separated fields: tag kind, armed, and comment.

The tag is a structure within an OPC UA variable that consists of the following fields:

  • Tag - A ByteString. The tag state format for write (set) and monitor/read (get) is composed of three comma-separated fields: tag kind, armed, and comment as shown in the following table:
    Tag KindNO-TAG=0OPEN-AND-CLOSE-INHIBIT=1CLOSE-ONLY-INHIBIT=2
    ArmedIDLE=0ARMED=1
    CommentOptional unconstrained comment string that can contain commas
  • Status - Usually initialized to 0.
  • Timestamp of the local OPC UA server - Usually initialized to 0.
  • Timestamp of the receiving ICCP server - Usually initialized to 0 (not currently used).

The local OPC UA server then passes the data in the tagged items to corresponding tags in the specified remote ICCP server as outlined in the following image:

Image of OPC UA server then passes the data in the tagged items to corresponding tags in the specified remote ICCP server

Note: Prior to working with tags, you need to understand it is always the remote ICCP server’s view of the tag that is the actual tag state. Even if the OPC client writes to a tag, and it is sent to the ICCP server, the ICCP server can ignore the set tag and consequently will return its view of the tag state in the next get request.

Back to Top

Subscribing to a Tag

(Tagging is not implemented yet, but it will become available in a future release.)

Subscription is the means by which an application’s OPC client learns the status of a tag in a remote ICCP server. An OPC client asks to subscribe to a set of tags in the local OPC UA server as shown in the following image:

Image of An OPC client asking to subscribe to a set of tags in the local OPC UA server

  1. After the LEC Server instance has connected to the remote ICCP server, the OPC UA client can issue subscription requests to a set of Tag items in the LEC Server instance. The LEC Server instance will in turn subscribe to these points in the remote ICCP server.
  2. Going forward, LEC Server will cyclically read these tag values, and push any changed tags to the OPC UA client. The cycle time is configurable. The tag values are read cyclically because the ICCP server can change the tags at the remote site at any time for any reason. The following image outlines this dataflow:

    Image outlining the dataflow of how LEC Server reads tag values

  3. After reading the tagged value, the OPC UA client can be programmed to prevent or allow the issuing of a control directive (Block 5) to the remote ICCP server.

Back to Top