qn430 windows iccp user's guide

Document Number: QN-430

Windows SCADA ICCP Users Guide ____________________________________________

August 2, 2007

This manual describes how to use the Windows SCADA ICCP Master-to-Master data exchange software.

Survalent Technology Corporation Mississauga, Ontario

Copyright 2004 2007 Survalent Technology Corporation All rights reserved QN-430 Windows SCADA ICCP Users Guide

Survalent Technology Corp. 2600 Argentia Road Mississauga, Ontario L5N 5V4 TEL (905) 826 5000 FAX (905) 826 7144 The software described in this document is furnished under license, and may only be used or copied in accordance with the terms of such license. The content of this manual has been carefully checked for accuracy. However, if you find any errors, please notify Survalent Technology Corporation.

Revisions Date Description January 29, 2004 Initial release.

January 30, 2006 Correct Table 5-4 Translation of Windows SCADA States to ICCP States.

August 2, 2007 Support ICCP Version 2000-8.

Add /DeleteDataset option to Client. Add Client capability to Server.

Users Guide Contents Windows SCADA ICCP

i

Contents

1 Introduction 1-1

1.1 Required Reading ........................................................................................................................... 1-1 1.2 Advanced Reading.......................................................................................................................... 1-2 1.3 Abbreviations.................................................................................................................................. 1-2 1.4 Overview ........................................................................................................................................ 1-2 1.5 ICCP Versions ................................................................................................................................ 1-3 1.6 Server.............................................................................................................................................. 1-3 1.7 Client .............................................................................................................................................. 1-4

2 Preparing For ICCP 2-1

2.1 Network Connectivity..................................................................................................................... 2-1 2.2 Bilateral Table Agreement.............................................................................................................. 2-2 2.2.1 Company Information ................................................................................................................. 2-3 2.2.2 Direction Of Data........................................................................................................................ 2-3 2.2.3 Node Independent Information ................................................................................................... 2-3 2.2.4 ICCP Server Specific Information .............................................................................................. 2-3


ii

2.2.5 ICCP Client Specific Information............................................................................................... 2-4 2.2.6 Server Status Points .................................................................................................................... 2-4 2.2.7 Server Analog Points .................................................................................................................. 2-4 2.2.8 Server Control Points.................................................................................................................. 2-5 2.2.9 Server Setpoints .......................................................................................................................... 2-5

3 ICCP Server Quick Start 3-1

3.1 Server Status Point ......................................................................................................................... 3-1 3.2 Local ICCP Nodes.......................................................................................................................... 3-2 3.3 ICCP Server.................................................................................................................................... 3-3 3.4 Dataset ............................................................................................................................................ 3-4 3.5 Status Points ................................................................................................................................... 3-5 3.6 Analog Points ................................................................................................................................. 3-6 3.7 Control Points................................................................................................................................. 3-7 3.8 Setpoints ......................................................................................................................................... 3-8 3.9 Virtual RTU.................................................................................................................................... 3-9 3.10 Start Server ............................................................................................................................... 3-10 3.11 ScanMon ................................................................................................................................... 3-10

4 ICCP Client Quick Start 4-1

4.1 Communication Line Status Point .................................................................................................. 4-1 4.2 Local ICCP Nodes.......................................................................................................................... 4-2 4.3 Remote ICCP Nodes....................................................................................................................... 4-3 4.4 Communication Line ...................................................................................................................... 4-4 4.5 RTU Status Point............................................................................................................................ 4-5 4.6 RTU ................................................................................................................................................ 4-5 4.7 Status Points ................................................................................................................................... 4-6 4.8 Analog Points ................................................................................................................................. 4-8 4.9 Start Scan Task ............................................................................................................................... 4-9 4.10 ScanMon ..................................................................................................................................... 4-9

5 ICCP Data Structures 5-1

5.1 Bilateral Table ................................................................................................................................ 5-1 5.1.1 Server .......................................................................................................................................... 5-1 5.1.2 Client........................................................................................................................................... 5-2 5.2 Data Values .................................................................................................................................... 5-2 5.2.1 Data Value Objects ..................................................................................................................... 5-2 5.2.2 Scope........................................................................................................................................... 5-2 5.2.3 Analog Data Value Types........................................................................................................... 5-3 5.2.4 Analog Quality Codes................................................................................................................. 5-4 5.2.5 Status Data Value Types............................................................................................................. 5-4 5.2.6 Status Quality Codes................................................................................................................... 5-5 5.3 Datasets........................................................................................................................................... 5-6

Ernesto GarciaResaltado






iii

5.3.1 Dataset Objects ........................................................................................................................... 5-6 5.3.2 Scope........................................................................................................................................... 5-6 5.4 Transfer Sets ................................................................................................................................... 5-6 5.4.1 Transfer Set Objects.................................................................................................................... 5-6 5.4.2 Scope........................................................................................................................................... 5-6 5.4.3 Special Transfer Set Variables .................................................................................................... 5-7 5.5 Devices ........................................................................................................................................... 5-7 5.5.1 Device Objects ............................................................................................................................ 5-7 5.5.2 Scope........................................................................................................................................... 5-7 5.5.3 Device Types .............................................................................................................................. 5-7 5.6 Miscellaneous Variables................................................................................................................. 5-8 5.6.1 Bilateral_Table_ID...................................................................................................................... 5-8 5.6.2 Supported_Features..................................................................................................................... 5-8 5.6.3 TASE2_Version.......................................................................................................................... 5-9

6 ICCP Server Data Entry 6-1

6.1 Client Capabilities .......................................................................................................................... 6-2 6.2 Server Editor................................................................................................................................... 6-2 6.2.1 Server Data Fields General Section ......................................................................................... 6-2 6.2.2 Server Data Fields ICCP General Parameters.......................................................................... 6-4 6.2.3 Server Data Fields ICCP Server Parameters ............................................................................ 6-5 6.2.4 Server Data Fields ICCP Client Parameters............................................................................. 6-6 6.3 Virtual RTU.................................................................................................................................... 6-7 6.4 Datasets......................................................................................................................................... 6-11 6.5 Status Points ................................................................................................................................. 6-12 6.6 Analog Points ............................................................................................................................... 6-14 6.7 Accumulator Points ...................................................................................................................... 6-16 6.8 Control Points ............................................................................................................................... 6-16 6.9 Setpoints ....................................................................................................................................... 6-18 6.10 ICCP Nodes .............................................................................................................................. 6-20

7 Operation of ICCP Server 7-1

7.1 Operation as Server ........................................................................................................................ 7-2 7.1.1 Association Control .................................................................................................................... 7-2 7.1.2 Datasets ....................................................................................................................................... 7-4 7.1.3 Transfer Sets ............................................................................................................................... 7-7 7.1.4 Data Values ............................................................................................................................... 7-11 7.1.5 Device Control .......................................................................................................................... 7-13 7.2 Operation as Client ....................................................................................................................... 7-15 7.2.1 Creation of Data Sets and Transfer Sets ................................................................................... 7-15 7.2.2 Information Reports .................................................................................................................. 7-16

8 ICCP Client Data Entry 8-1


iv

8.1 Communication Line ...................................................................................................................... 8-2 8.1.1 Communication Line Data Fields - General Tab ........................................................................ 8-3 8.1.2 Communication Line Data FieldsChannel Tab....................................................................... 8-5 8.1.3 Communication Line Data FieldsICCP Tab ........................................................................... 8-6 8.2 RTU ................................................................................................................................................ 8-8 8.2.1 RTU Data Fields - General ......................................................................................................... 8-8 8.2.2 ICCP: Edit Options ..................................................................................................................... 8-9 8.3 Analog Point................................................................................................................................. 8-12 8.4 Status Point................................................................................................................................... 8-15 8.5 Control Point - Command ............................................................................................................ 8-17 8.6 Control Point - Setpoints .............................................................................................................. 8-19

9 Operation of ICCP Client Scan Task 9-1

9.1 Initialization.................................................................................................................................... 9-1 9.2 Association ..................................................................................................................................... 9-1 9.3 Creation of Data Sets and Transfer Sets ......................................................................................... 9-4 9.4 Information Reports........................................................................................................................ 9-5 9.5 Device Control................................................................................................................................ 9-6 9.6 Deactivation and Reactivation of Points ........................................................................................ 9-9 9.7 Deactivation and Reactivation of RTUs......................................................................................... 9-9 9.8 Deactivation and Reactivation of Communication Lines ............................................................... 9-9

10 ICCP Conformance Summary 10-1

10.1 BLOCK 1 - Basic Services ....................................................................................................... 10-2 10.2 BLOCK 2 - Extended Data Set Condition Monitoring............................................................. 10-3 10.3 BLOCK 3 - Blocked Transfers ................................................................................................. 10-3 10.4 BLOCK 4 - Operator Stations................................................................................................... 10-3 10.5 BLOCK 5 - Device Control ...................................................................................................... 10-4 10.6 BLOCK 6 - Programs ............................................................................................................... 10-4 10.7 BLOCK 7 - Events.................................................................................................................... 10-4 10.8 BLOCK 8 - Accounts................................................................................................................ 10-5 10.9 BLOCK 9 - Time Series ........................................................................................................... 10-5

11 MMS Services Supported 11-1

Users Guide Introduction Windows SCADA ICCP

1-1

1 Introduction

This document describes Windows SCADA ICCP. This package is based on the description of ICCP that is contained in the following documents that were originally published in August 1996 by the Utility Communications Specification Working Group for Version 1996-8 and again in 2002 with amendments in 2005 for Version 2000-8:

Table 1-1 ICCP Documents

Document Number Title IEC 870-6-503 TASE.2 Services and Protocol IEC 870-6-702 TASE.2 Profiles IEC 870-6-802 TASE.2 Object Models

1.1 Required Reading If you are not going to read this document, at least read this and the following chapters. This will give you a basic understanding of ICCP and what is required to configure your system. The rest of this chapter provides an overview of how Windows SCADA ICCP works. Chapter 2, Preparing For ICCP, provides a checklist for everything you will need to prepare your system for ICCP. It also gives suggestions for testing network connectivity. Chapter 3, ICCP Server Quick Start, describes how to quickly configure an ICCP Server. Chapter 4, ICCP Client Quick Start, describes how to quickly configure an ICCP Client.


1-2

1.2 Advanced Reading The remaining chapters provide a more in depth discussion of ICCP configuration and implementation. Chapter 5, ICCP Data Structures, describes how ICCP data structures are implemented in Windows SCADA ICCP. Chapter 6, ICCP Server Data Entry, describes in detail how to configure an ICCP Server. Chapter 7, Operation of ICCP Server, describes how the ICCP Server works. Chapter 8, ICCP Client Data Entry, describes in detail how to configure an ICCP Client. Chapter 9, Operation of ICCP Client Scan Task, describes how the ICCP Client works. Chapter 10, ICCP Conformance Summary, contains the ICCP conformance table for Windows SCADA ICCP. Chapter 11, MMS Services Supported, describes the MMS services used by Windows SCADA ICCP.

1.3 Abbreviations This manual makes use of the following abbreviations and terms: ICCP Inter Control Center Communication Protocol MMS Manufacturing Messaging Specification PDU Program Data Unit RTU Remote Terminal Unit UCA Utilities Communication Architecture

1.4 Overview Windows SCADA ICCP consists of both Client and Server software. The Client software connects to other members on the network to receive point data and forward control requests from operators and application programs. The Server software responds to Client requests by sending the requested data and executing the requested controls. Quality codes, such as manual set and telemetry failed, are transmitted along with the data. In device control operations, tags on the Server system are respected. Any member of the ICCP network can act as either a Client or a Server or both. The relationship between any pair of members may be fully bi-directional. That is, both members may act as both Client


1-3

and Server to each other. Furthermore, any member may act as a Server to multiple Clients, and at the same time act as a Client with multiple Servers. Establishment of the connections is the responsibility of the Client software. The Client and Server software consists of two separate programs. A separate copy of the Server program runs for each remote Client member that it sends data to. Similarly, a separate copy of the Client program runs for each remote Server member that it receives data from. In a bi-directional link between two partners, this means that each partner runs both a Client program and a Server program connected to the other partner. Although polling is possible, data exchange in ICCP is not normally based on polling. Instead, the Client defines a dataset and enables transfer sets in the Server and then just waits for data to arrive from the Server. A transfer set is an entity that specifies a dataset and a set of transmission parameters (conditions for transmitting the dataset). A dataset is a group of status and/or analog points. For each transfer set that is enabled, the Server monitors the conditions that would trigger a transfer. Whenever any of the conditions are true, the Server transmits the dataset. Report by exception, with or without periodic integrity transmissions, is supported.

1.5 ICCP Versions The Client and Server support Versions 1996-8 and 2000-8. ICCP Version 2000-8 does everything that ICCP Version 1996-8 does with the addition of supporting some analog and status data types that have millisecond resolution timestamps and the handling of multiple status changes. The Client can specify in the transmission parameters for the dataset that the Server is to return ALL state changes for points during the interval. See All Changes in section 8.2.2, ICCP: Edit Options. In Version 1996-8, the Server would only check the state of the points at the end of the interval, if the point was in the same state as the last interval it does not detect a change. For example, if a point was in the close position at the end of interval n and a trip/close occurred during the interval, the Server would see the point in the close state at the end of interval n+1 and would not detect a change and therefore would not report the point.

1.6 Server The Data Exchange section of SCADA Explorer defines, for the Server, which points in the SCADA database are accessible to remote Client member systems on the network. Analog, status, accumulator, setpoint and control points are grouped together into Datasets. Each entry in a Dataset specifies a point that a remote Client may access. A Dataset is assigned or mapped to a Server via the Virtual RTU editor. The ICCP Node editor defines the ICCP addresses for both the Client and Server. See section 6.10, ICCP Nodes.


1-4

The Server, Virtual RTU, Dataset and ICCP Node editors in the Data Exchange section of the SCADA Explorer are described in detail in chapter 6, ICCP Server Data Entry. Chapter 7, Operation of ICCP Server, describes how the ICCP Server works.

1.7 Client The Communication Line and RTU sections of SCADA Explorer define, for the Client, the points that are to be retrieved from the remote Server. Analog, status and accumulator points defined on an RTU make up an ICCP dataset. The Client downloads the dataset definition to the remote Server. Then it uses the transmission parameters defined on the ICCP tab of the Edit RTU window to enable a transfer set. The ICCP Node editor defines the ICCP addresses for both the Client and Server. See section 6.10, ICCP Nodes. The Communication Line, RTU, Analog and Status editors of SCADA Explorer are described in detail in chapter 8, ICCP Client Data Entry. Chapter 9, Operation of ICCP Client Scan Task, describes how the ICCP Client works.

Users Guide Preparing For ICCP Windows SCADA ICCP

2-1

2 Preparing For ICCP This chapter describes the information that should be considered when preparing your system for ICCP. The implementation of ICCP requires the coordinated effort of two control centers to successfully exchange data. They must agree upon the network connectivity, what data to exchange and the setting of certain parameters. They must also agree upon who will be sending data and who will be receiving data or if they will both be sending and receiving data.

2.1 Network Connectivity The physical network connection is usually the first item agreed upon, as equipment procurement, installation and configuration may be necessary. Get an early start on this, as it may take weeks before equipment installation is complete. If the connection is going through a router, a route will be required on each SCADA host. Routes are added via the Command Prompt window. For example, presuming the router address is 172.26.1.150, the IP Address 207.68.171.244 can be added in such a way that all addresses that begin with 207.68.171 can be routed through the router with the following command:

route p add 207.68.171.0 mask 255.255.255.0 172.26.1.150 Existing routes can be displayed with the command route print.


2-2

Note that if the connection is going through a firewall, port 102 should be opened, as this is the port ICCP listens for incoming connections. Once the physical network has been installed and configured, you will need to re-visit this section to verify the network connectivity. This may be done in several ways:

From the Command Prompt window, ping the remote node. For example, ping 207.68.171.244. Ping will send a packet to the remote node and expect a response. Verify there is 0% packet loss. Note that ping may not work if a firewall has been installed and pings have been disabled. If a firewall is installed, it is strongly suggested that pings be enabled at least for the connectivity test. If pings cannot be enabled on the firewall, then try the telnet option below to verify network connectivity.

If ping is unable to receive a response from the remote node, trace route may be used to monitor

the routing of the packet as it hops across the network. For example, tracert 207.68.171.244. Trace route will send a ping packet to each node along the route as it hops to the final node. This can be useful in determining if a firewall or router is not forwarding the packet.

Another option is to telnet to port 102 of the remote node. This is a network trick to determine if

anything is listening on the port or if a firewall is blocking the port. Port 102 is the port ICCP uses to listen for incoming connections. However, depending on the program used to telnet, it can be difficult to determine if there actually is connectivity. Using the command prompt with the command telnet 207.68.171.244 102 for example, one of the following scenarios should apply:

1. Telnet connects fairly quickly and stays connected. When you press enter, it does one or

more line feeds with an underscore then disconnects. This implies you have connectivity to the remote node and ICCP is listening on port 102.

2. Telnet displays connecting and within a moment it disconnects and displays the message

Unable to connect to port 102. This implies you may have connectivity to the remote node but ICCP is not listening on port 102. Have the remote node start ICCP to listen for connections and re-try telnet.

3. Telnet displays connecting for some time and when it finally disconnects (times out), it

displays the message Unable to connect to port 102. This implies you do not have connectivity to the remote node or a firewall is blocking port 102.

2.2 Bilateral Table Agreement A document should be created and shared between the two control centers, that at least contains the sections described below. Both control centers should agree on who will create and maintain the document or if this will be a collaborative effort. Once completed, this document is your Bilateral Table Agreement (BTA). For the purpose of the remainder of this discussion, the two control centers will be called Company A and Company B. The following sections describe the information required for Company As ICCP Server to send data to Company Bs ICCP Client. If at a future date, Company Bs ICCP Server is to send data to Company As ICCP Client, then the bilateral table agreement would need to be amended to include similar information as below, but for the direction of data flow from Company B to Company A.


2-3

2.2.1 Company Information This section describes information about the companies and company contacts. It should at least contain the following information:

Company A name and address Company A contact person(s), phone, email, etc. Acronym for Company A. For example, CMPA. Company B name and address Company B contact person(s), phone, email, etc. Acronym for Company B. For example, CMPB.

2.2.2 Direction Of Data This section indicates which direction the data is flowing:

Company As ICCP Server is sending data to Company Bs ICCP Client

2.2.3 Node Independent Information This section describes general information about the ICCP connection that is common to all ICCP node(s). It should at least contain the information listed below. See section 6.2.2, Server Data Fields ICCP for more information on Server data fields.

Company As ICCP Server Domain name which Company Bs ICCP Client will use to access

data at Company As ICCP node(s). This typically takes one of two formats: the acronym of the remote Clients name. For example, CMPB. Or the combination of both companies acronyms with direction of dataflow. For example, CMPA_CMPB with data flowing from Company A Server to Company B Client.)

Company As ICCP Server Bilateral Table ID when Company Bs ICCP Client is accessing data on Company As ICCP node(s). For example, V1.0.

Company As maximum MMS PDU size. Size in bytes of the maximum MMS Protocol Data Unit. Typically 32000 bytes.

Company As version of ICCP. 1996-8 or 2000-8. Company Bs maximum MMS PDU size. Company Bs version of ICCP.

2.2.4 ICCP Server Specific Information This section describes information about the ICCP Server. This section should be repeated for each node running an ICCP Server. It should at least contain the information listed below. See section 6.10, ICCP Nodes, for more information on ICCP addressing (AP Title, etc.).

The name by which Company A refers to this node. This field is not electronically transmitted during any ICCP transactions, but is only here to facilitate verbal communication between Company A and Company B.

Company As TCP/IP network address of this node. Company As ICCP Server AP Title.


2-4

Company As ICCP Server AE Qualifier. Company As ICCP Server Presentation Selector (Psel). Company As ICCP Server Session Selector (Ssel). Company As ICCP Server Transport Selector (Tsel).

2.2.5 ICCP Client Specific Information This section describes information about the ICCP Client. This section should be repeated for each node running an ICCP Client. It should at least contain the information listed below. See section 6.10, ICCP Nodes, for more information on ICCP addressing (AP Title, etc.).

The name by which Company B refers to this node. This field is not electronically transmitted during any ICCP transactions, but is only here to facilitate verbal communication between Company A and Company B.

Company Bs TCP/IP network address of this node. Company Bs ICCP Client AP Title. Company Bs ICCP Client AE Qualifier. Company Bs ICCP Client Psel. Company Bs ICCP Client Ssel. Company Bs ICCP Client Tsel.

2.2.6 Server Status Points This section describes information about the status points that Company As ICCP Server will allow Company Bs ICCP Client to access. It should at least contain the information listed below. See section 6.5, Status Points, for more information on Server status points.

The ICCP data type. For simplicity, all the status points should have the same data type. The most common data type for status points is DataStateQ.

The scope of all the status points, either VMD or Domain. Again, for simplicity, all the status points should have the same scope. The most common scope is VMD.

A list of all the status points. For each point, the list should include the points ICCP variable name and access (Read Only or Read/Write).

2.2.7 Server Analog Points This section describes information about the analog points that Company As ICCP Server will allow Company Bs ICCP Client to access. It should at least contain the information listed below. See section 6.6, Analog Points, for more information on Server analog points.

The ICCP data type. For simplicity, all the analog points should have the same data type. The most common data type for analog points is DataRealQ.

The scope of all the analog points, either VMD or Domain. Again, for simplicity, all the analog points should have the same scope. The most common scope is VMD.

A list of all the analog points. For each point, the list should include the points ICCP variable name and access (Read Only or Read/Write).


2-5

2.2.8 Server Control Points This section describes information about the control points that Company As ICCP Server will allow Company Bs ICCP Client to control. It should at least contain the information listed below. See section 6.8, Control Points, for more information on Server control points.

The scope of all the control points, either VMD or Domain. For simplicity, all the control points should have the same scope. The most common scope is VMD.

A list of all the control points. For each point, the list should include the points ICCP variable name.

2.2.9 Server Setpoints This section describes information about the setpoints that Company As ICCP Server will allow Company Bs ICCP Client to control. It should at least contain the information listed below. See section 6.9, Setpoints, for more information on Server setpoints.

The ICCP data type. For simplicity, all the setpoints should have the same data type. The most common data type for analog points is DataRealQ.

The scope of all the setpoints, either VMD or Domain. Again, for simplicity, all the setpoints should have the same scope. The most common scope is VMD.

A list of all the setpoints. For each point, the list should include the points ICCP variable name.

Users Guide ICCP Server Quick Start Windows SCADA ICCP

3-1

3 ICCP Server Quick Start This chapter describes how to quickly configure an ICCP Server to send data to a remote ICCP Client. A more detailed description is available in chapter 6, ICCP Server Data Entry. As a prerequisite, you should have read chapter 2, Preparing For ICCP and completed the Bilateral Table Agreement (BTA) document, as you will be referencing the BTA to configure your ICCP Server. Although an ICCP Server can have the qualities of both a Server and a Client, only the configuration of a Server is described here. Only in rare cases will it be required to configure Client qualities for a Server. See Chapter 6, ICCP Server Data Entry for Client quality configuration of a Server. The ICCP Server is configured via SCADA Explorer. If the SCADA Explorer is not currently active, then open it now and login.

3.1 Server Status Point Create a new SCADA status point for the Up/Down state of the ICCP Server link to the remote Client. Similar points are used for the Up/Down state of communication lines.


3-2

3.2 Local ICCP Nodes Under Data Exchange, click ICCP Nodes and create a new local ICCP Node. If you have a dual system, one Server ICCP Node will usually be sufficient for both hosts, unless the remote system requires unique addresses for each of your hosts. The required fields are listed below.

AR Name (Must be unique, typically the acronym of the remote company and SV for Server, for example CMPB_SV

Local checked Shared unchecked. AP Title (Must be unique. For example, 1 3 9999 1 100 for the first local Node (Client or

Server), then increment the last number by 1 for each local Node added.) AE Qualifier (Typically the last number of the AP Title. For example, 100) Psel (Must be unique for all local Nodes (Client and Servers) assigned to this host. For

example, 0001. If you have a dual system and you are creating an ICCP Node for each host, the selectors should be the same for both hosts.)

Ssel (See Psel) Tsel (See Psel)

Figure 3-1 Local ICCP Node


3-3

3.3 ICCP Server

Under Data Exchange, click Servers and create a new ICCP Server. The required fields are as follows:

General Section

Server Name (Must be unique) Link Status (Status point created in step 1) Protocol (ICCP) Autostart checked

ICCP General Section

Listen for Connection selected Bilateral Table ID (Enter a text string for the Bilateral Table agreement version. For

example, V1.0) Max PDU Size (Typically 32000 bytes) Life Check Interval (Typically 20 to 30 seconds) Local Server Node (ICCP Node(s) created in step 2). If a dual system, select an

ICCP Node for A and B. If a quad system, select ICCP Nodes for A, B, C and D. (The same Node can be selected for all)

ICCP Server Parameter Section

Domain Name (Typically takes one of two formats: the acronym of the remote Clients name. For example, CMPB. Or the combination of both companies acronyms with direction of dataflow. For example, CMPA_CMPB with data flowing from Company A Server to Company B Client.)

Critical Response Time (Typically not used) Minimum Interval (Typically 4 seconds, ignored if 0)


3-4

Figure 3-2 ICCP Server

3.4 Dataset Under Data Exchange, click Datasets and create a new Dataset. The required fields are as follows:

Dataset Name (must be unique)

Figure 3-3 ICCP Server Dataset


3-5

3.5 Status Points Click the + to expand the tree for the Dataset you created in step 4. Now click Status and create a new mapping to each SCADA status point that the remote Client will have access to. The required fields are as follows:

Point (Select via Drag-n-Drop SCADA Point browser)

Identity (ICCP variable name assign to the point)

Identity Type (ICCP scope, most common scope is VMD. 0=Domain, 1=VMD)

Data Type (Most common status type is 2=DataStateQ)

Figure 3-4 ICCP Server Status Point


3-6

3.6 Analog Points Click on Analog for the Dataset you created in step 4 and create a new mapping to each SCADA analog point that the remote Client will have access to. The required fields are as follows:


Identity (ICCP variable name assigned to the point)


Data Type (Most common analog type is 3=DataRealQ)

Scaling (Default is Use Alternate 1 and 0 to send engineering value)

Figure 3-5 ICCP Server Analog Point


3-7

3.7 Control Points Click on Control for the Dataset you created in step 4 and create a new mapping to each SCADA status point that the remote Client will have control access to. The required fields are as follows:




Select before operate required (Optional but typically selected)

Parameter 2 is checkback value (Typically the ID in the Control section of the dataset)

Figure 3-6 ICCP Server Control Point


3-8

3.8 Setpoints Click on Setpoint for the Dataset you created in step 4 and create a new mapping to each SCADA analog point that the remote Client will have control access to. The required fields are as follows:




Data Type (Most common setpoint type is 1=Real)

Scaling (Default is Use Alternate 1 and 0 to send engineering value)

Select before operate required (Optional but typically selected)

Parameter 2 is checkback value (Typically the ID in the Setpoint section of the dataset)

Figure 3-7 ICCP Server Setpoint


3-9

3.9 Virtual RTU Under Data Exchange, click the + on Servers to expand the tree, then click the ICCP Server you created in step 3. Create a new Virtual RTU that will map the Dataset created in step 4 to the Server created in step 3. The required fields are as follows:

Virtual RTU Name (Must be unique)

Address (Start at 1 and increment for each Virtual RTU added to this Server)

Modify Enable (Optionally check if remote Client has write access)

Control Enable (Optionally check if remote Client has control access)

Server (Select Server created in step 3)

Dataset (select Dataset created in step 4)

Select Output Dataset

Figure 3-8 ICCP Server Virtual RTU


3-10

3.10 Start Server Assuming network connectivity has been established with the remote Client nodes, under Data Exchange, click on Servers and select the Server created in step 3. Click Start Server to activate the ICCP Server and listen for incoming connections from the remote Client. If network connectivity has not been established, see section 2.1, Network Connectivity, before proceeding.

3.11 ScanMon Verify communications by enabling logging with ScanMon. Task name is ICCPSVn, where n is the Server ID. Use Log Type of Default and RTU Address 0.

Users Guide ICCP Client Quick Start Windows SCADA ICCP

4-1

4 ICCP Client Quick Start This chapter describes how to quickly configure an ICCP Client to receive data from a remote ICCP Server. A more detailed description is available in chapter 8, ICCP Client Data Entry. As a prerequisite, you should have read chapter 2, Preparing For ICCP, and completed the Bilateral Table Agreement (BTA) document, as you will be referencing the BTA to configure your ICCP Client. The ICCP Client Scan Task is configured via SCADA Explorer. If the SCADA Explorer is not currently active, then open it now and login.

4.1 Communication Line Status Point Create a new SCADA status point for the Up/Down state of the ICCP Client link to the remote Server.


4-2

4.2 Local ICCP Nodes Under Data Exchange, click ICCP Nodes and create a new local Client ICCP Node. If you have a dual system, one Client ICCP Node will be sufficient for both hosts, unless the remote Server requires unique addresses for each of your hosts. The required fields are as follows:

AR Name (Must be unique, typically the acronym of the Server company plus CL. For example, CMPA_CL)

Local checked

Shared unchecked

AP Title (Must be unique. For example, 1 3 9999 55 222 for the first local Node (Client

and Server), then increment the last number by one for each local Node added.)

AE Qualifier (Typically the last number of the AP Title. For example, 222)

Psel (Must be unique for all local Nodes (Client and Servers) assigned to this host. Typically, Psel, Ssel and Tsel are set to the same value. For example, 0002. If you have a dual or quad system and you are creating an ICCP node for each host, the selectors should be the same for both hosts.)

Ssel (See Psel)

Tsel (See Psel)

Figure 4-1 ICCP Client Local Node


4-3

4.3 Remote ICCP Nodes Create a new remote ICCP Node for each remote Server node that the ICCP Client will be connecting to. The required fields are as follows:

AR Name (Must be unique, typically the acronym of the Server node plus RM and SV.

For example, RM_CMPA_SV.)

Remote checked

Host Name (Name of host if entered in the HOSTS file or an IP Address.)

AP Title (Must be unique. For example, 1 2 8888 3 50)

AE Qualifier (Typically the last number of the AP Title. For example, 50)

Psel (Typically, Psel, Ssel and Tsel are set to the same value. For example, 0001)

Ssel (See Psel)

Tsel (See Psel)

Figure 4-2 ICCP Client Remote Node


4-4

4.4 Communication Line Click Communication Lines and create a new ICCP Client Communication Line. The required fields are as follows:

General Tab

Name (Must be unique) Protocol (ICCP) Autostart checked Status Point (Select point created in step 1)

Channel Tab

Network (TCP/IP) Long response timeout (Typically 10,000 milliseconds) Mode (Poll)

ICCP Tab

Bilateral Table ID (Just text for the Bilateral Table agreement version. For

example, V1.0. Must match remote Server) Domain Name (Typically takes one of two formats: the acronym of the remote

Clients name. For example, CMPB. Or the combination of both companies acronyms with direction of dataflow. For example, CMPA_CMPB with data flowing from Company A Server to Company B Client.)

Max PDU Size (Typically 32000 bytes) Life Check Interval (Typically 20 seconds) Connection Interval (Typically 5 seconds) Connection Retry (Typically 3) Version (1996-8 or 2000-8. Must match the remote Server) Local Client Nodes for A and B (ICCP Node(s) created in step 2. If a dual

system, select an ICCP Node for both A and B. The same Node can be selected for both.)

Remote Server Nodes (ICCP Node(s) created in step 3.)


4-5

Figure 4-3 ICCP Client ICCP Tab

4.5 RTU Status Point Create a new SCADA status point for the Up/Down state of the RTU.

4.6 RTU Click the + on Communication Lines to expand the tree and click the Communication Line created in step 4 and create a new RTU. The required fields are as follows:

General Tab

Name (Must be unique) Comm. Line (Select Communication Line created in step 4) Network (Select Use ComLine) RTU Addr (Start at 1 and increment for each new RTU added to this

Communication Line) Status (Select SCADA status point created in step 5)

ICCP Tab

Interval checked (Typically 4 seconds for status points, 8 seconds for analog) Integrity checked (Typically 120 seconds or more) Report By Exception checked


4-6

Figure 4-4 RTU Transmission Parameters

4.7 Status Points Click the + on the Communication Lines to expand the tree. Click the + for Communication Line created in step 4 to expand the tree. Click the + for the RTU created is step 6 to expand the tree. Then click Status and create a new SCADA status point for each ICCP status point to be received from the remote Server. Survalent suggests that you create only one status point, verify that the point is properly received, and then use that point to model all of the others. The required fields are as follows:

General Tab

Name (Select station and unique point name) User Type Device Class Zone Group Command-State

Telemetry Tab

Address checked (Select RTU created in step 6) A (Start at 1 for the first status point and increment for each new status point) B (302=DataStateQ most common status data type) C=0 D=0 External Name (ICCP variable name assigned to the point by the remote Server) Type (ICCP Scope, most common scope is VMD. 0=Domain, 1=VMD) Format Code (Select entry that corresponds to status format code 1) Control-0 (Optionally checked) A (Checkback value if SBO required. Typically start at 1 for the first control point

and increment for each new control point. Verify with remote Server.) B=400


4-7

C (1=SBO Required, 0=SBO Not Required) D (Command value, usually 1) Control-1 (Optionally checked) A (Checkback value if SBO required. Typically start at 1 for the first control point

and increment for each new control point. Verify with remote Server.) B=400 C (1=SBO Required, 0=SBO Not Required) D (Command value, usually 0) Control External Name (ICCP control variable name assigned to the point by the

remote Server) Type (ICCP Scope, most common scope is VMD. 0=Domain, 1=VMD)

Alarms Tab

Normal State Alarm Format

Figure 4-5 Status Point - Telemetry


4-8

4.8 Analog Points Click the + on the Communication Lines to expand the tree. Click the + for Communication Line created in step 4 to expand the tree. Click the + for the RTU created is step 6 to expand the tree. Then click Analog and create a new SCADA analog point for each ICCP analog point to be received from the remote Server. Survalent suggests creating only one analog point, verifying the point is properly received then use that point to model all the others. The required fields are as follows:

General Tab

Name (Select station and unique point name) User Type Device Class Zone Group Format Code (Select entry that corresponds to analog format code 1) Address checked (Select RTU created in step 6) A (Start at 1 for first point and increment for each new analog point) B (103=DataRealQ most common analog data type) C=0 D=0 External Name (ICCP variable name assigned to the point by the remote Server) Type (ICCP Scope, most common scope is VMD. 0=Domain, 1=VMD)

Figure 4-6 Analog - General


4-9

4.9 Start Scan Task Assuming network connectivity has been established with remote Server nodes, click on Communication Lines and select the Communication Line created in step 4. Click Start Scan Task to activate the ICCP Client and attempt connections to the remote Server. If the Client cannot connect to the remote Server, please see section 2.1, Network Connectivity.

4.10 ScanMon Verify communications with ScanMon. Task name is ICCPn, where n is the Communication Line ID. Use Log Type of Default and RTU Address 0.

Users Guide ICCP Data Structures Windows SCADA ICCP

5-1

5 ICCP Data Structures

5.1 Bilateral Table

5.1.1 Server The Bilateral Table used by the Windows SCADA ICCP Server program is defined largely by the contents of the Virtual RTU and Server editors. These two together specify: the points accessible to each Client, with their

corresponding data types access control (read, modify, control)

configuration parameters

version of the Bilateral Table


5-2

5.1.2 Client The Windows SCADA ICCP Client program is a scan task where the communication line is a network link. A separate Client runs for each link to a remote Server member of the network. The Bilateral Table used by each Client is defined by its Scan Table, which is a Windows SCADA data structure that contains an ordered list of the points telemetered by the Client. The Scan Table is edited and maintained by the SCADA Explorer.

5.2 Data Values

5.2.1 Data Value Objects A Data Value object in a Windows SCADA ICCP Server system corresponds to an entry in the analog, status or accumulator section of the Virtual RTU editor. Each Client can be assigned access to the Virtual RTUs. (The collection of Virtual RTUs assigned to the Client is essentially the Servers instantiation of the Bilateral Table.) The Client may create any number of datasets from each Virtual RTU. Each dataset may contain data values from more than one Virtual RTU. The accumulator objects were designed for use by RTU protocol servers, but can also be used in ICCP. They are treated as regular analog data values. A Data Value object is instantiated and mapped to an actual SCADA point at the Server.

5.2.2 Scope The Windows SCADA Client and Server both support a mix of VMD-specific and Domain-specific data values.


5-3

5.2.3 Analog Data Value Types Both Client and Server support the following ICCP data types for analog points:

Table 5-1 Analog Data Value Types

Data Type Code ICCP Data Type Comment 1 Data_Real 2 Data_Discrete 3 Data_RealQ 4 Data_DiscreteQ 5 Data_RealQTimeTag 6 Data_DiscreteQTimeTag 7 Data_RealExtended 8 Data_DiscreteExtended 9 Data_RealQTimeTagExtended ICCP Version 2000-8 only

10 Data_DiscreteQTimeTagExtended ICCP Version 2000-8 only On the Server side, the data type code of the desired data type must appear in the points Data Type field in the Data Exchange Dataset editor. This specifies to the Server the data type to use when sending the point's value. On the Client side, the data type code of the desired data type is part of the points telemetry address. This code specifies to the Client the data type to use when unpacking and storing the points received value. For analog data types 5 to 10, the Server sets the UTC/GMT TimeStamp component to the time the point was last updated. If the timestamp is invalid, the Client uses the time of the report. The TimeStamp component for analog data types 5 and 6 have resolution to the second. The TimeStamp component for analog data types 9 and 10 have resolution to the millisecond. Neither the Client nor the Server make any use of the COV Counter component of analog data types 7 and 8. The Client ignores the COV counter and the Server sets it to zero.


5-4

5.2.4 Analog Quality Codes The Data_Flags component of transmitted analog data values is prepared by the Server according to the table given below.

Table 5-2 Analog Quality Codes

Windows SCADA Quality ICCP Validity ICCP Current Source NORMAL VALID TELEMETERED TELEMETRY FAILED (OLD) HELD TELEMETERED MANUALLY SET VALID ENTERED CALC FROM MANSET VALID TELEMETERED

The Windows SCADA NORMAL quality code shown in the table above is not the normal state of the point. Its a quality code that means the point is being updated normally. The Server does not use the ICCP CALCULATED current source code. The Server sets the ICCP NormalValue flag to 0 if the points transmitted value is within the point's Windows SCADA alarm limits. The flag is set to 1 if the point is in violation of its pre-emergency, emergency or reasonability limits. If the required data type is discrete (integer), the Server converts the analog points floating point value to integer by truncation. If the result does not fit into the integer, the Server sends a value of zero with a validity code of NOTVALID. In this case, the Windows SCADA ICCP Client will ignore the new value and just set the receiving points quality code to TELEMETRY FAILED (i.e. old).

5.2.5 Status Data Value Types Both Client and Server support the following ICCP data types for status points:

Table 5-3 Status Data Value Types

Data Type Code ICCP Data Type Comment 1 Data_State 2 Data_StateQ 3 Data_StateQTimeTag 4 Data_StateExtended 5 Data_StateQTimeTagExtended ICCP Version 2000-8 only

For status data types 3 to 5, the Server sets the UTC/GMT TimeStamp component to the time the point was last updated. If the timestamp is invalid, the Client uses the time of the report. The TimeStamp component for status data type 3 has resolution to the second.


5-5

The TimeStamp component for status data types 5 has resolution to the millisecond. The translation of Windows SCADA status values to ICCP status values is shown in Table 5-4.

Table 5-4 Translation of Windows SCADA States to ICCP States

Windows SCADA State

Typical Windows SCADA Meaning ICCP State

0 Open 1 1 Closed 2 2 Travel 0 3 Error 3

Neither the Client nor the Server make any use of the COV Counter component of status data type 4. The Client ignores the COV counter and Server sets it to zero.

5.2.6 Status Quality Codes The Validity and Current Source components of transmitted status data values are prepared by the Server according to the table given below.

Table 5-5 Status Quality Codes

Windows SCADA Quality ICCP Validity ICCP Current Source NORMAL VALID TELEMETERED TELEMETRY FAILED (OLD) HELD TELEMETERED MANUALLY SET VALID ENTERED CALC FROM MANSET VALID TELEMETERED

The Windows SCADA NORMAL quality code shown in the table above is not the normal state of the point. Its a quality code that means the point is being updated normally. The Server does not use the ICCP CALCULATED current source code. The Server sets the ICCP NormalValue flag to 0 if the point's transmitted value is the points normal state. Otherwise, the flag is set to 1.


5-6

5.3 Datasets

5.3.1 Dataset Objects The names of the datasets that the Windows SCADA Client creates at the Server are of the form: DomainName_DSn where: DomainName = Name of the Domain-specific work space n = RTU number

5.3.2 Scope The Windows SCADA Server creates dataset objects with the scope requested by the Client. When it requests that datasets be created, the Windows SCADA Client specifies the scope to be Domain-specific.

5.4 Transfer Sets

5.4.1 Transfer Set Objects In a Windows SCADA ICCP Server, the object names of transfer sets are of the form: DomainName_TSn where: DomainName = Name of the Domain-specific work space n = transfer set number (Example: COES_TS5 for transfer set 5) The Server allocates object space for 32N transfer sets for its Client, where N is the number of Virtual RTUs mapped to the Server via the Virtual RTU editor.

5.4.2 Scope Transfer sets and special transfer set variables are Domain-specific.


5-7

5.4.3 Special Transfer Set Variables The following special transfer set variables are used by both the Client and the Server. All of these variables are Domain-specific.

Table 5-6 Special Transfer Set Variables

Variable Name Type Next_DSTransfer_Set MMS ObjectName Transfer_Set_Name MMS ObjectName DSConditions_Detected DSConditions Transfer_Set_Time_Stamp GMTBasedS Transfer_Report_ACK MMS ObjectName Transfer_Report_NACK MMS ObjectName

Only the first of these variables can be read using an MMS Read request. For the others, an MMS Read request is NAKed, with an error code OBJECT-ACCESS-DENIED, error class ACCESS.

5.5 Devices

5.5.1 Device Objects A Device object in a Windows SCADA ICCP Server system corresponds to an entry in the control section of the Virtual RTU editor.

5.5.2 Scope Both the Windows SCADA Client and Server support a mix of VMD-specific and Domain-specific device objects.

5.5.3 Device Types The ControlPointType of an instantiated Device object depends on the type of Windows SCADA point. The ControlPointType is: COMMAND if the Windows SCADA point is a status point SETPOINT if the Windows SCADA point is an analog point In the case of SETPOINT, the SetPointType is determined at the Server by the Data Type code in the Setpoint section of the Dataset editor as shown in the table below:


5-8

Table 5-7 Setpoint Types

Data Type Code Setpoint Type 1 Real 2 Discrete

At the Client, the Setpoint Type is determined by the B field of the points Telemetry Address. See section 8.6 Control Point - Setpoints. The SBO attribute (ICCP DeviceClass) for both control points and setpoints is determined at the Server by the Select before operate required checkbox in the Control and Setpoint sections of the Virtual RTU editor. At the Client, the SBO attribute for both control points and setpoints is determined by the C part of the control address. See sections 8.5, Control Point - Command, and 8.6, Control Point - Setpoints.

5.6 Miscellaneous Variables

5.6.1 Bilateral_Table_ID This is a Domain-specific variable of type Visible-String-32. Valid characters for this are alphanumeric, $, or underscore, but not spaces. The maximum length of this variable is 32 characters.

5.6.2 Supported_Features This is a VMD-specific variable of type SupportedFeatures. When the Client issues a read request for this variable, the Windows SCADA Server returns a 12-bit string as follows:

Table 5-8 Supported Features

Block Description Supported 1 Basic services Yes 2 Extended dataset condition monitoring Yes 3 Blocked transfers No 4 Operator stations No 5 Device control Yes 6 Programs No 7 Events No 8 Accounts No 9 Time series No 10 Undefined No 11 Undefined No 12 Undefined No


5-9

5.6.3 TASE2_Version This is a VMD-specific variable of type TASE2Version. In Windows SCADA ICCP the Client and Server support 1996-8 and 2000-8.

Users Guide ICCP Server Data Entry Windows SCADA ICCP

6-1

6 ICCP Server Data Entry This chapter describes how to use the Data Exchange section of the SCADA Explorer to define Servers, Virtual RTUs, Datasets and ICCP nodes for use by the ICCP Server program. This is not a complete description of Windows SCADA Data Exchange. This presentation is limited to only those data fields that are of interest in an ICCP context. The inter-relationship of the Data Exchange components are displayed in the figure below. The Server is the main component that can have multiple Virtual RTUs mapped to it. A Virtual RTU maps one Data Exchange Dataset to one Server.

Virtual RTU 2 Virtual RTU n

Server ICCP Nodes

Virtual RTU 1

Dataset 1 Dataset 2 Dataset n


6-2

6.1 Client Capabilities The Windows SCADA ICCP Server has the capabilities to also act as an ICCP Client. That is, the Server can send and receive points from the remote system. This type of connection is extremely rare and usually only required when the remote system does not support dual connections and must send and receive points through a single connection. The ICCP Servers capability to act as an ICCP Client is limited to receiving points only. It is not possible to issue controls or setpoints to the remote system. Also, activating a point on a map or a viewer will NOT cause the point to be read from the remote system. For dual or bi-directional connections, Survalent strongly recommends using the Windows SCADA ICCP Client Scan Task (see chapter 8, ICCP Client Data Entry) for receiving data and the Windows SCADA ICCP Server for sending data. If you are in doubt of how you should configure your ICCP Client and Server, please contact Survalent Customer Support for clarification.

6.2 Server Editor The Server editor is used to define a protocol Server that will respond to requests and exchange data with a remote system. The Server contains a collection of points that are grouped into Virtual RTUs. These are the only points that are accessible to the remote system.

6.2.1 Server Data Fields General Section Server Name

A unique name to readily identify the Server. Description

A text string to describe the Server. Link Status

The name of a status point used by the Server to indicate the Connected or Disconnected status of the communication link. The Link Status is required and must already exist in the database. To create the points you could abandon the editing of this Server, and go to the desired station in the SCADA Explorer. But, you may prefer to temporarily start a second copy of SCADA Explorer, and use it to create the point, then quit the second SCADA Explorer as soon as you are done with it.


6-3

Figure 6-1 Server Editor

Protocol

This is the name of the protocol to be used to communicate with the remote system. It specifies which Server will be used. For ICCP, choose the name ICCP.

Auto Start

Set this flag if you want the Server to start automatically when the SCADA system starts or when failover occurs.

Configuration Switches

This field allows you to specify certain command line switches to control the behavior of the Server. The switches that are supported by the ICCP Server are described below. Specify each switch you need by entering /name=value in this field. You do not need to add a space or other punctuation between switches. The switch names or values are not case sensitive.


6-4

/LogPath The LogPath option specifies the folder where the Server is to log communications to a file. If not specified, the Server will use the folder specified when Windows SCADA was installed. The default folder name is C:\Program Files\Quindar\ScadaServer. If this option is specified, it must precede the /Log option and the folder must already exist. /Log The Log option specifies the Server is to log communications to a file. The file will be created in the folder specified when Windows SCADA was installed. The default folder name is C:\Program Files\Quindar\ScadaServer. The file name is comprised of the protocol name, the Server id and the current date. For example, a file name from Server ID 1 on August 2, 2007 would be ICCPSV1-2007-08-2.log. Care should be taken when using this option and should only be enabled for short periods of time, as the file will continue to grow and consume all the free space on the disk. The valid values for this option are as follows:

Default Log all communication.

Start Server

Clicking the Start Server button will cause the Server to start. If the Server was already active, it will exit and then re-start.

Stop Server

Clicking the Stop Server button will cause the Server to exit.

6.2.2 Server Data Fields ICCP General Parameters Listen for Connection / Initiate Connection

Select Listen for Connection, as this is the standard behavior of an ICCP Server. Otherwise, select Initiate Connection for the rare case where the Server will initiate the connection to the remote Client. If initiating the connection then Remote Node(s) must also be selected.

Bilateral Table ID

This is a text string that represents the version of the Bilateral Agreement. Valid characters are alphanumeric, $ and underscore, but not spaces. The maximum length is 32 characters.

Max PDU Size

This is the maximum Program Data Unit or packet size the Server will send or receive. The packet size is negotiated with the remote Client and the lesser of the two will be used. Typically 32,000 bytes.


6-5

Life Check Interval

This is the interval in seconds that the Server checks the health of the connection to the Client. This is useful to determine when a Client may not be responding or to expedite a lost TCP/IP socket connection. Once an association has been established, every interval the Server will issue an Identify request to Client. The Client must respond to this request within the same amount of time or else the Server will abort the association. Typical interval is 20 seconds. If the interval is zero, the Server will NOT check the health of the connection and recovery of a lost TCP/IP socket is left to the operating system to notify the Server. This may take several minutes or even hours before the system notifies the Server.

Version

This is the version of ICCP the Server is to support. The Server and the remote system must agree which ICCP version is to be used. Select the version from the drop down list.

Local Nodes

The local nodes are the AR Names that the Server is to use to register and identify itself on the network. The selectable AR Names in the drop down list are those ICCP Nodes that have been defined as local. In a single master system you only need to select an AR Name for A (HOSTA). In a dual-redundant master system you need to select an AR Name for A (HOSTA) and B (HOSTB). In a quad-redundant master system, you need to select an AR Name for A (HOSTA), B (HOSTB), C (HOSTC) and D (HOSTD). The same AR Name can be selected for all entries.

Remote Nodes The remote nodes are only required when the Server is Initiating the Connection to the remote system. If the Server is Listening for a connection leave the Remote Nodes set to . The Remote Nodes are the AR Names that the Server will attempt to connect to. The selectable AR Names in the drop down list are those ICCP Nodes that have been defined as remote. At startup the Server will attempt to connect to the remote system specified in A. If the Server fails to connect to A, it will then try to connect to B. If the Server fails to connect to B, it will then try to connect to C. If the Server fails to connect to C, it will then try to connect to D. The Server will continue cycling through all the Servers until a connection is made.

6.2.3 Server Data Fields ICCP Server Parameters Domain Name

This is the name of the Domain that Domain-specific entities will be created in for the remote Client. The Server creates the Domain or working space, and then creates and instantiates each Domain-specific variable. The remote Client can access these variables and create datasets in this Domain. Valid characters are alphanumeric, $ and underscore, but not spaces and must begin with an alphabetic character. The maximum length is 32 characters.


6-6

Care should be taken when deciding on the Domain name, as the Domain name will be included in information reports for EVERY Domain-specific point. Survalent recommends use of short Domain names not much more than 6 characters in length. Typically, this takes one of two formats:

1. The acronym of the remote Clients companys name. For example, CMPB. 2. The combination of both companys acronyms with direction of dataflow. For example,

CMPA_CMPB with data flowing from Company A to Company B. Critical Response Time

This is the maximum amount of time in seconds that the Server will wait for an acknowledgement of a critical information report. Typically 30 seconds.

Minimum Interval

This is the minimum allowable interval or integrity value the Client can use for transfer sets. If the Client writes to a transfer set with an interval or integrity value less than the allowable, the Server will not accept (NACK) the write request. Typically 4 seconds. If zero is entered, the Server will allow any interval the Client specifies.

6.2.4 Server Data Fields ICCP Client Parameters These parameters are only required in the rare case where the Server will also be acting as Client. That is, the Server will both be sending and receiving points from the remote system. Leave these fields empty or zero if the Server is NOT acting as a Client. If you want to receive points from the remote system, Survalent recommends configuring a Windows SCADA ICCP Client scan task. See chapter 8 ICCP Client Data Entry. Domain Name

This is the name of the Domain that Domain-specific entities will be created in for the Client at the remote Server. The remote Server creates the Domain or working space, and then creates and instantiates each Domain-specific variable. The Client can access these variables and create datasets in this Domain. Valid characters are alphanumeric, $ and underscore, but not spaces and must begin with an alphabetic character. The maximum length is 32 characters. Care should be taken when deciding on the Domain name, as the Domain name will be included in information reports for EVERY Domain-specific point. Survalent recommends use of short Domain names not much more than 6 characters in length. Typically, this takes one of two formats:

1. The acronym of the your companys name. For example, CMPA. 2. The combination of both companys acronyms with direction of dataflow. For example,

CMPB_CMPA with data flowing from Company B to Company A (your company).


6-7

Connection Interval

This specifies the time delay between re-connect attempts after the first Connection Retry attempts. Typical interval is 5 seconds.

Connection Retry

This specifies the number of immediate re-connect attempts to perform on loss of association. If an association is still not established after this number of attempts, the Client continues to try to connect, but it executes the Connection Interval delay between each attempt. If the remote system has redundant nodes, the Client switches target nodes after each Connection Retry attempts. Typical retry count is 3.

6.3 Virtual RTU The Virtual RTU editor is used to map a Dataset to a Server. In ICCP, usually only one Virtual RTU per Server is sufficient. However, if you are serving more than one Client then you may require multiple Virtual RTUs. One Virtual RTU for points common to all Clients and another Virtual RTU for points only of interest to that Client. A Virtual RTU maps to only one Dataset. For convenience, all the points in the Dataset can be directly accessed under the Virtual RTU tree in the SCADA Explorer.

Figure 6-2 Virtual RTU Editor Output Dataset

Virtual RTU Name

A unique name to readily identify the Virtual RTU.


6-8

Description

A description of the Virtual RTU. Address

This is the station address that uniquely identifies the Virtual RTU on the Server. Even though the concept of an RTU is not present in ICCP, the Data Exchange facility of Windows SCADA requires this field. Simply start with 1 and increment the address for each Virtual RTU added to the Server.

Modify Enable

All analog, accumulator and status points on a Virtual RTU automatically have read access. If you want a Client to have write access to these points you must check this box. By checking this box doesnt mean that the Client has write access to ALL points on the Virtual RTU. Each point must also be individually enabled. This two step approach is done to allow write access by one Client and not another in the event of Datasets being shared with multiple Clients.

Control Enable

Check this box if you want the Client to be able to issue controls and setpoints on your system. All setpoint and control points in the corresponding Dataset will be accessible to the Client.

Server

This drop down menu is a list of all the protocol servers defined in Data Exchange. Select the ICCP Server that this Virtual RTU will be attached to. The Server must be defined before creating the Virtual RTU.

Dataset

This drop down menu is a list of all the Datasets defined in Data Exchange. Select the Dataset that this Virtual RTU maps to. The Dataset must be defined before creating the Virtual RTU. However, the points in the Dataset may be defined at any time.

Output Dataset

Select Output Dataset if the points in the Dataset are to be sent to the remote Client. This is the normal selection. In this case the Transmission Parameters have been disabled as they are not required.

Input Dataset

Select Input Dataset only in the rare case where the Server will be also be acting as Client and this Dataset represents points that will be received from the remote Server. In this case, the Transmission Parameters are also required.


6-9

The Transmission Parameters are only required in the rare case, where the Server will also be acting as Client and Input Dataset is selected.

Figure 6-3 Virtual RTU Editor - Input Dataset

Typical Transmission Parameters configured are Interval, Integrity and Report By Exception. In the example in Figure 6-3, the Remote Server is instructed to check for changes every 4 seconds and only send those points that have changed and every 60 seconds the Remote Server is to send all the points. Interval

This is the time interval in seconds for the Remote Server to send periodic reports. Used if the Interval checkbox is enabled. Typical interval is 4 seconds.

Integrity

This is the time interval, in seconds, that the Remote Server is to send all-data reports. Used if the Integrity checkbox is enabled. Typical interval is 60 seconds.

Time Limit For Execution

This is the time limit within which the Remote Server must report. It is supported by the Client in the sense that it is included in the transfer set requests made to the Remote Server, but the Client does not check whether transfer reports are late. Not typically used, normally set to 0.

Buffer Time


6-10

This is the time, in seconds that the Remote Server is to use for buffering Object Change conditions. If a change is detected, the Remote Server will delay this amount of time before reporting the change. Not typically used, normally set to 0.

Event Condition Requested

This is a code describing an external event that will trigger the Remote Server to send a report. Used if the Other External Event checkbox is enabled. Not typically used, normally set to 0.

Block Data

If this checkbox is enabled, transfer reports are to be blocked (i.e. use a mutually agreed block data reporting format). Not supported by the Client in this implementation of Windows SCADA ICCP, leave this checkbox disabled.

Critical

If this checkbox is enabled, the Client will send an acknowledgement to the Remote Server for each transfer report received. Not typically used, normally unchecked.

Report By Exception

If this checkbox is enabled, the Remote Server is to send only exceptions (points that have changed value or quality), in its transfer reports. However, in the case of integrity timeout, all-data will be included in the transfer report. Typically enabled to reduce the data packet size.

Object Change

If this checkbox is enabled, the Remote Server is to send transfer reports when ANY object in the dataset changes in either value or quality. Actual transmission is delayed by the Buffer Time delay, if specified. The values transmitted are those that are available at the end of the buffer time delay.

If Object Change is enabled, the Remote Server will constantly scan the dataset for changes. This differs from Interval reports that only scan for changes once at the end of each time period. This can create more overhead on the Remote Server and/or more network packets being generated but also allows for instantaneous reporting of changes. Not typically enabled.

Operator Request

If this checkbox is enabled, the Remote Server is to send transfer reports if requested by the operator. Not typically enabled.

Other External Event

If this checkbox is enabled, the Remote Server is to send transfer reports whenever some external event occurs. Not typically enabled.

All Changes

The All Changes option is available for selection when ICCP version 2000-8 is selected on the Server. If this checkbox is enabled, the Remote Server is to send ALL state changes for status points not just the current state. When this option is enabled, Report By Exception, Object Change


6-11

and Buffer Time must also be enabled and Interval must be disabled. Integrity is optional but recommended. See Figure 6-4 for an example.

Figure 6-4 All Changes Settings

6.4 Datasets The Dataset editor creates a definition for a group of analog, accumulator, status, setpoint and control points. The points themselves are edited with their corresponding editor. A Dataset may be mapped to one or more Virtual RTUs.

Figure 6-5 Dataset Editor

Dataset Name

A unique name to readily identify the Dataset. Description

A description of the Dataset. In ICCP, points in a Dataset are referenced by name. The points name is included in most requests and responses with the remote system. If throughput or speed of the connection to the remote system is an issue, you may want to consider using shorter names. You may also want to consider using a scope of VMD-specific or use a short Domain name, as the Domain name for Domain-Specific variables is included FOR EVERY point transmitted. Valid characters are alphanumeric, $ and underscore, but not spaces and must start with an alphabetic character. The maximum length of a variable name in ICCP is 32 characters.


6-12

Survalent recommends using a scope of VMD-specific.

6.5 Status Points The Status section contains the status points that are assigned to the Dataset.

Figure 6-6 Dataset Editor - Status Section

Point

This is the name of a SCADA status point whose state and condition will be monitored and sent to the Client. The status point is selected via the Drag-n-Drop SCADA window. Only status points may be dropped into this location.

Identity

The identity is used to uniquely identify the point within the Dataset. ICCP only supports Name and Use Points External Name to identify a point. All other methods are not supported by ICCP.

Name When selected, the text box contains the ICCP name that the remote Clients will use to access the point. Valid characters are alphanumeric, $ and underscore, but not spaces and must start with an alphabetic character. The maximum length of a variable name in ICCP is 32 characters. If Name is selected then a numeric Type code must also be specified to select the scope of the point. The most common scope is VMD or 1. See Table 6-1 for Type codes.

Table 6-1 ICCP Scope

Type Code Scope 0 Domain 1 VMD


6-13

Use Points External Name When selected, the External Name and Type code defined for the point will be used. This may be useful when the value for this SCADA status point is being received from another system, it is a way to propagate the point name without having to re-enter it.

Parameters

The parameters provide additional criteria for an instance of a point. In ICCP only parameter 1 is used for status points, leave all other parameters set to 0. Parameter 1 Warn on Modify Error If set to 1, the Server will warn the Client if an attempt to modify a data value fails because the point is manually set at the Server. When set to 0, the default behavior, the Server will not update the point and will NOT notify the Client of the error. The purpose of this is to allow point values at the Server to be overridden by the operators without disturbing the Client.

Data Type

The Data Type code specifies how the points value, quality codes and timestamps are formatted for transmission. See Table 6-2 for the Data Type codes for status points. The most common Data Type is Data_StateQ or 2. ICCP Data Types Data_StateQTimeTag and Data_StateExtended use timestamps with second resolution while Data_StateQTimeTagExtended use timestamps with millisecond resolution. The Server sets the TimeStamp component to the time of the last status change in UTC/GMT and sets the TimeStampQuality attribute to VALID.

Table 6-2 Status Point Data Types

Data Type Code ICCP Data Type Comment 1 Data_State 2 Data_StateQ 3 Data_StateQTimeTag 4 Data_StateExtended 5 Data_StateQTimeTagExtended ICCP Version 2000-8 only

Data Format

This field defines how the state of the SCADA status point will be translated. In ICCP this translation has been defined by the protocol and therefore this field is not required. Leave this field set to the default value of Single Bit. The SCADA status state is translated to the ICCP state via the following table.


6-14

Table 6-3 Translation of Windows SCADA States to ICCP States

SCADA State Typical SCADA Meaning ICCP State 0 Open 2 1 Closed 0 2 Travel 1 3 Error 3

Modify Enable

If this box is checked the Client has write access to this point only if the corresponding Virtual RTU also has its Modify Enable box checked.

6.6 Analog Points The Analog section contains the analog points that are assigned to the Dataset. Point

This is the name of a

qn430 windows iccp user's guide

Documents

iccp states

windows scada iccp master

windows scada iccp users

iccp versions

support iccp version

client capability

company information

node independent information