iccp - transpower · iccp does not directly control the device, rather it communicates a client‟s...

VOLUME 3 of TP.DC 29.02 Issue 1 draft 5

Nov 2011

Telemetry, data management and presentation standard Volume 3: Protocols and performance

Appendix I – ICCP

T R A N S P O W E R D R A F T S T A N D A R D

Implementation date: XXXX 2011

C O P Y R I G H T © 2 0 1 1 T R A N S P O W E R N E W Z E A L A N D L I M I T E D . A L L R I G H T S R E S E R V E D .

This document is protected by copyright vested in Transpower New Zealand Limited (“Transpower”). No part of the document may be

reproduced or transmitted in any form by any means including, without limitation, electronic, photocopying, recording or otherwise, without the prior written permission of Transpower. No information embodied in the documents which is not already in the public domain shall be

communicated in any manner whatsoever to any third party without the prior written consent of Transpower.

Any breach of the above obligations may be restrained by legal proceedings seeking remedies including injunctions, damages and costs.


May 2011

© 2011 - Transpower New Zealand Limited 2


Nov 2011


PREFACE

This document is Volume 3 of a four volume Standard that defines SCADA and telemetry data management practises in Transpower. The intent of the Standard is to ensure consistency of data acquisition, naming, modelling and presentation of SCADA data from source in substations through National SCADA and to archiving. The Standard also serves as a reference catalogue listing data objects available from primary plant, secondary systems and other related services at substations.

The parent document of the set contains common information applicable to the Standard as a whole and includes a brief outline of the outcomes intended of each volume. This volume defines the standard protocols to be used and the data performance requirements.

Keywords

ICCP protocol scaling

C O N T A C T

This document is the responsibility of Stations Working Group,

Transpower New Zealand Limited, Wellington. If you have any queries please contact the National Grid Asset Manager.

If you would like to make suggestions to improve this document,

please use the “Controlled Document Feedback Form” located at the rear of this document or online via the Controlled

Documentation homepage of the Transpower website at

www.transpower.co.nz

C O N F I D E N T I A L I T Y

All information disclosed in this document that is not general public

knowledge must be treated as strictly confidential and may not be

used or disclosed except for the purpose of developing

documentation for the benefit of Transpower.

L I M I T A T I O N O F L I A B I L I T Y A N D D I S C L A I M E R O F W A R R A N T Y

Transpower New Zealand Limited makes no representation or warranties with respect to the accuracy or completeness of the

information contained in the document. Unless it is not lawfully

permitted to do so, Transpower specifically disclaims any implied warranties of merchantability or fitness for any particular purpose

and shall in no event be liable for, any loss of profit or any other

commercial damage, including, but not limited to, special, incidental, consequential or other damages.

M I N I M U M R E Q U I R E M E N T S

The requirements set out in Transpower’s standards are minimum

requirements that must be complied with by Transpower personnel,

contractors and consultants as applicable. All personnel are

expected to implement any practices which may not be stated but which can reasonably be regarded as good practices relevant to the

purpose of this standard. Transpower expects all personnel to

improve upon these minimum requirements where possible and to integrate these improvements into their procedures and quality

assurance plans.

http://www.transpower.co.nz/


Nov 2011


CONTENTS

PREFACE .............................................................................................................................. 3

A ICCP TO CUSTOMERS ........................................................................................... 5 A1 Introduction to ICCP........................................................................................................ 5 A2 ICCP System Configuration ............................................................................................ 5 A3 System Availability and Redundancy.............................................................................. 5 A4 ICCP Security ................................................................................................................. 6 A5 ICCP Scope .................................................................................................................... 6 A6 ICCP Blocks .................................................................................................................... 6 A7 Data Item Representation ............................................................................................... 7 A8 Data Item Naming Rules ...............................................................................................13 A9 Data Items to be Exchanged ........................................................................................14 A10 Point Documentation Tables .........................................................................................15 A11 ICCP Association Information Exchange ......................................................................16

B CONTROLLED DOCUMENT FEEDBACK FORM ................................................. 21

APPENDIX I VOLUME 3 of TP.DC 29.02 Issue 1 draft 5

Nov 2011


A ICCP TO CUSTOMERS

Note that the ICCP details which follow are specific to the implementation of ICCP between Transpower and its customers. ICCP features and function not being used over these connections are not included in this document.

A1 Introduction to ICCP

ICCP – Inter Control Center Protocol (also known as Telecontrol Application Service Element – TASE.2) has been standardized under the IEC 60870-6 specifications and allows for data exchange over WANs between utility control centres. The ICCP protocol runs over the MMS (Manufacturing Message Specification – ISO/IEC 9506) protocol.

ICCP provides for the exchange of real time power system information including status and control data, and measured values.

A2 ICCP System Configuration

A typical ICCP connection is illustrated in the following diagram. Note that the Customer‟s ICCP gateway may consist of single or redundant servers, or may be an application that resides on the SCADA servers.

The ICCP link will be over TCP/IP. The WAN connection between the Transpower and Customer‟s system will be provided and managed by Transpower, and will terminate in an edge router (or routers) located at the Customer‟s premises. (Note that the physical design of the network, location and configuration of firewalls, etc. is not included in the scope of this document).

Customer Premises

Transpower Premises

RTU

RTUs

SCADA Frontends

e-terracontrol

SCADA Master Station

e-terraplatform

ICCP Gateway

e-terracomm

ICCP Gateway

Server(s)

RTUs, PLCs, etc

SCADA Master

Station

Transpower

Wide Area

Network

Transpower

Edge Router(s)

ICC

P (

TA

SE

.2)

A3 System Availability and Redundancy

The Transpower ICCP solution provides at least n-1 redundancy at both the transport and application tiers (i.e. the network, ICCP servers, and the SCADA system behind them are all fully redundant). The target service availability, from the Transpower SCADA to the demarcation point, is 99.9% or better.

The intention of Transpower‟s ICCP system is that it meets the data transmission requirements of the Electricity Industry Participation Code Schedule 8.3, Technical Code C, Schedule 6, Parts 2 and 3 and provides both the primary and backup means of data


Nov 2011


communication. It will provide an inherently resilient service that delivers both primary and backup without differentiation between the two (part 3c allows for this via the statement “or otherwise with the agreement of the system operator”)

The availability and redundancy of the Customer‟s ICCP system is not included in this specification. It is left to the Customer to implement a system which meets their availability and redundancy needs.

A4 ICCP Security

The ICCP implementation between Transpower and its customers shall be Secure ICCP.

Transpower‟s MMS and OSI stack supports secure ICCP via the MMS Security Toolkit. This provides two distinct and independent facilities:

The MMS Application Certificate Exchange (MACE) protocol for application authentication. This provides positive identification of the application as well as anti-replay for non-SSL/TLS connections.

SSL/TLS as secure transport layer. This provides positive identification of the remote node (bi-directional certificate exchange) and SSL/TLS data encryption.

The MMS Security Toolkit makes use of X.509 Certificates at both the SSL/TLS and MACE levels for authenticating remote nodes and passing public keys. Operating system specific tools handle the management of the certificates and keys.

The security certificates will be generated and managed by Transpower (refer to the separate “ICCP Certificate Management Process” documentation), and issued to the Customer for implementation of secure ICCP.

A5 ICCP Scope

ICCP defines the Virtual Control Centre concept to represent an abstraction of a real-world control center that acts like an ICCP wrapper to the Control Center. Information may be defined to have global scope (VCC scope) or a domain scope (ICC Scope).

For the implementation of ICCP between Transpower and its customers the ICCP scope shall be as follows:

Data Items: Transpower uses global data scope (VCC scope).

Data Sets: Data Sets are specific to a remote and must have ICC scope. Note that Transpower‟s ICCP system does not support VCC scope for Data Sets. For Transpower to receive data from a customer, the customer‟s ICCP solution MUST support ICC scope in their ICCP implementation.

A6 ICCP Blocks

ICCP has been designed to be modular. Its functionality is specified by a series of “Conformance Blocks”, where each block represents a specific function or set of functions that can be implemented.

Block 1 is mandatory in all ICCP implementations. The other blocks are optional, depending on the functionality required.

The ICCP implementation between Transpower and its customers shall use the following block types (additional block types may be used by mutual agreement).

A6.1 Block 1 (Basic Services, Periodic Power System Data)

This block contains the following:

Association Establishment Services (initiate, conclude and abort), for the overall operation of the link.

Data Value Objects, which provide for the periodic transfer of power system data, specifically:

Status Points

Analog Points.


Nov 2011


Data Set Objects

Data Set Transfer Set Object (interval time-out and operator request conditions only)

Note that block 1 uses a strict interval and does not support report by exception.

A6.2 Block 2 (Extended Data Set Condition Monitoring)

This block provides a report by exception capability for transfer of power system data.

Block 2 is supported on the Transpower ICCP link, however, due to the nature of the interface between the Transpower ICCP and SCADA servers, it may not offer any significant advantage for relatively small point counts.

A6.3 Block 5 (Device Control)

This block provides a mechanism for transferring a „request to operate a device‟ from one ICCP implementation to another. ICCP does not directly control the device, rather it communicates a client‟s request to operate a device to the server.

On the Transpower ICCP link, this block is used where controls and/or setpoints are required (e.g. Transpower has delegated control of a circuit breaker to a customer).

A7 Data Item Representation

A7.1 Analog Value Scaling

ICCP transmits analog values as 32 bit IEEE floating point values (IEEE 754). Therefore, the actual engineering value can be sent over ICCP, and there is no need for scaling.

The values sent and received over the Transpower ICCP link shall be the engineering values, sent as 32 bit IEEE floating point values.

The values sent and received shall be as per the units defined in the following table:

Measurement Units Value of 1.0 equals Normal Resolution

Current Amps 1.0 amps 1 amp (i.e. no decimal places)

Voltage kV 1.0 kV 0.1 kV (i.e. one decimal place)

Real Power MW 1.0 MW 0.1 MW (i.e. one decimal place)

Reactive Power Mvar 1.0 Mvar 0.1 Mvar (i.e. one decimal place)

Total Power MVA 1.0 MVA 0.1 MVA (i.e. one decimal place)

Frequency Hz 1.0 Hz 0.01 Hz (i.e. two decimal places)

Distance to Fault % 1.0 % 0.1 % (i.e. one decimal place)

Tap Position Tap Tap 1 1 (i.e. no decimal places)

Setting Group Group Group 1 1 (i.e. no decimal places)

Note that, where appropriate, other units may be used, but only by mutual agreement between Transpower and the customer.

All analog values sent and received are to be documented in the point documentation tables, refer section I8.

A7.2 Analog Value Direction (Sign)

ICCP has no native convention for direction of power flow. For those values where the sign indicates the direction of power flow (MW, Mvar and MVA), the sign on the value sent over ICCP shall comply with the following diagram:


Nov 2011


STN A

STN B

STNA-STN B CCT

Load Generator and

Capacitors

Reactors

+

+

++

+

+

+

-

A7.3 Status Points

ICCP provides two methods of transferring status points, as follows:

STATE – Uses two bits to describe up to a maximum of four states for each device.

DISCRETE – Uses a 32 bit integer where each value can represent a different state.

The status points sent and received over the Transpower ICCP link shall be transferred as follows:

All single and double bit status points shall be transferred using STATE. The DISCRETE type shall not be used.

Single and double bit status points shall be transferred using the standard ICCP representation (as detailed below).

The standard ICCP representation of status points transferred using STATE is as follows:

Point Type ICCP STATE Value

00 (decimal 0) 01 (decimal 1) 10 (decimal 2) 11 (decimal 3)

Single Bit

Invalid Off state of single bit point

On state of single bit point

Invalid

Double Bit (e.g. switchgear

status)

Between (In-transit,

Mid-position)

Open Closed Invalid (Indication

error)

All status values sent and received are to be documented in the point documentation tables, refer section I7.

A7.4 Controls and Setpoints

ICCP provides a means for controls to be sent to the plant (Transpower can control Customer plant, and the Customer can control Transpower plant). ICCP doesn‟t issue controls directly to the device, it sends a “request to operate” and then the SCADA carries out the normal control process.


Nov 2011


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

COMMAND – Device operation.

SETPOINT – Numeric value.

Control and setpoint requests can be select before operate or direct operate, as follows:

Select Before Operate (SBO) – A two stage select-before-operate process with confirmation following the select.

Direct Operate (DO) – A single stage direct operate process with no select-before-operate stage.

Controls and setpoints sent over the Transpower ICCP link shall be transferred as follows:

All controls shall be Select Before Operate (i.e. all ICCP COMMAND objects shall use the SBO request type).

All setpoints shall be Direct Operate (i.e. all ICCP SETPOINT objects shall use the DO request type).

ICCP allows two possible control actions for each control point, namely Open and Close. The mapping of these actions to the real device controls shall be specified in the point documentation table.

An ICCP Check Back Name is required for all Select Before Operate controls. This name is an arbitrary number, agreed upon by the ICCP partners, that the ICCP server returns to the client as a result of a Select operation. The range is 1 to 32767. Note that the number used must be unique on all systems that use it, and therefore the part of the range used for each Customer will need to be agreed by negotiation.

ICCP setpoints may be floating point or integer values. Setpoint values sent over the Transpower ICCP link shall be the floating point engineering values.

All controls and setpoints are to be documented in the point documentation tables, refer section A10.

An example of the INTERLOCKED control process is as follows:

Station ABCTranspower

SCADA

Customer

SCADA

(Abbr=CUST)

Station RTU

Device:

CB123

ICCP

Connection


Nov 2011


Operator executes

CB132 Open

Control

SCADA checks

that control is

available

Select Successful

SCADA sends

control to RTU

Control Request

(Checkback name, e.g. 1001)

Operate Request

End

Write Confirmation

(Success or Failure)

Transpower SCADA Customer SCADAICCP Link

(CUST_ABC_132_OPEN)

Read Confirmation


Operate

SuccessfulDevice Operation

Complete Device Operation


A7.5 Data Sets

Data sets are groups of data items (status points, analogs, controls and setpoints), used to split the list of data items into manageable pieces. It is not necessary to co-ordinate the data sets between the two ends of an ICCP link, as this is carried out automatically by the ICCP protocol.

When configuring data sets, the number of data items in each set is limited by the maximum MMS PDU size, and it is recommended that data sets be limited to a maximum of 800 data items, and to:

Keep the data item names as short as possible

Maximise the number of data items using VCC scope (as these only require the exchange of the data item name, and not the domain name)

Transpower will normally define a single data set for each customer, and this data set will contain all data items from that customer. Note that a customer connection is not limited to a single data set, and additional data sets will be defined if required.

A7.6 Data Attributes

ICCP data items can have a number of data attributes included to provide additional information, including:

Quality (refer to section A7.7)

Timestamp

Millisecond resolution on timestamp (ICCP 2000-08 only)

COV (multiple change indication)

The Transpower ICCP implementation will only use the State and Real data items, and the attributes enabled on each type shall be as follows:

Data Item Attribute

Quality Timestamp Milliseconds COV


Nov 2011


State Y Y By Agreement N

Real Y Y N N

A7.7 Data Item Quality Information

ICCP provides quality codes to indicate the data quality, and these are transferred with each data item. The quality codes are derived from the SCADA system‟s reliability information for the status, analog and accumulator points stored in its database.

Note that the mapping of a SCADA system‟s data reliability information into the ICCP quality codes is a local implementation issue, as each SCADA system has its own symbols for displaying data quality.

The ICCP data item quality information provided is as follows:

Data item status or validity. This attribute is the individual data item‟s quality, and it can have one of the following states:

Valid (Good)

Invalid (Bad)

Held (Point has been out of scan or otherwise removed from service. The value may be the last good value obtained or a value that has been substituted by the Operator.)

Suspect (Old value due to telemetry failure or failure to acquire a new value within the scan time, or otherwise considered suspect by the data owner.).

Data item source. This attribute indicates where a data item‟s value is sourced from (which can change at any time), and can have any one of the following states:

Telemetered

Calculated

Estimated

Manual.

Normal state. This attribute indicates whether the data item‟s state is considered to be normal, or off-normal, and can have either of the following states:

Normal

Abnormal (off-normal).

The following table details the ICCP quality codes supported by the Transpower ICCP gateway.

Status Source State ICCP Code


Good Telemetered Normal 00 Suspect Telemetered Normal 20

Good Telemetered Abnormal 02 Suspect Telemetered Abnormal 22

Good Calculated Normal 04 Suspect Calculated Normal 24

Good Calculated Abnormal 06 Suspect Calculated Abnormal 26

Good Manual Normal 08 Suspect Manual Normal 28

Good Manual Abnormal 0A Suspect Manual Abnormal 2A

Good Estimated Normal 0C Suspect Estimated Normal 2C

Good Estimated Abnormal 0E Suspect Estimated Abnormal 2E


Nov 2011




Held Telemetered Normal 10 Bad Telemetered Normal 30

Held Telemetered Abnormal 12 Bad Telemetered Abnormal 32

Held Calculated Normal 14 Bad Calculated Normal 34

Held Calculated Abnormal 16 Bad Calculated Abnormal 36

Held Manual Normal 18 Bad Manual Normal 38

Held Manual Abnormal 1A Bad Manual Abnormal 3A

Held Estimated Normal 1C Bad Estimated Normal 3C

Held Estimated Abnormal 1E Bad Estimated Abnormal 3E

Note that the validity of the indicated data quality is dependent on where the associated data point is sourced from. In the case of telemetered data, the ICCP data quality flags reflect the quality of the data all the way through the telemetry chain back to its source at the substation equipment. However, this does not apply to data sourced from high level SCADA applications, where it is necessary to examine the time stamp of the point in order to determine its quality (refer to section A7.8 for details).

A7.8 Determining Data Quality by Time Stamp Evaluation

For data sourced from high-level SCADA network applications, the ICCP data quality flags only indicate the quality of the transport through ICCP back to the source of the data in the network application database (which does not itself have quality flags). Whether the data in this database can be relied upon depends on how recently the application ran and successfully solved. There are many reasons why a network application‟s database may be old, including:-

Failing to solve. These applications may fail to converge/solve at any time; this can happen due to power network conditions going outside certain ranges, or other IT reasons. When this happens data‟s timestamp will freeze until the problem is resolved and the application solves successfully.

After a failover. Although the telemetry values come back to Good quality very rapidly after a failover, the network applications may take much longer before the timestamp indicates they have a current solution. This is due to the most recent automatic savecase first having to be copied across to the new master before the application can then run to get a new solution.

Updating the model. Whenever a new model has to be introduced to a network application (eg. to match new equipment being commissioned) it is done by loading a new savecase into the on-line system. The values and timestamps in this savecase will be from when the new off-line model was created (which may be many days prior) and will not be updated until the real-time application runs and successfully produces a new solution with valid data.

In the case of data points from network applications, the indication of when the data was last updated is provided by the point timestamp. To determine the quality of such points it is necessary to examine both the point timestamp and the ICCP data quality attributes.

If the timestamp is not within an acceptable range from current time, or if the data quality is not “GOOD”, then the data should not be used.

Note that Transpower can‟t make data available to customers that is any better that the data available to its own system coordinators, who must also take account of whether the application has successfully solved sufficiently recently before deciding to use the data.


Nov 2011


When checking the timestamp, it is up to the customer to determine how wide a time window from present time should be allowed when deciding if the data can be relied on. This window should be related to the interval at which the Transpower application generating the data runs. Transpower‟s analysts will provide this information when setting up the ICCP data transfer.

Note that the timestamp provided is in the form of seconds since 1 January 1979 UTC.

A8 Data Item Naming Rules

All data items (status points, analogs, controls and setpoints) transferred over ICCP require a unique name. The ICCP data item name is sent over the ICCP link, therefore the ICCP data item name must be identical at each end. ICCP data item names must be in the format specified by the ICCP protocol. The present SCADA names will require mapping to ICCP data item names within the ICCP gateway application to meet the ICCP data item name rules. This is illustrated in the following diagram:

Transpower

SCADA

Point Name

Customer SCADA

Point Name

ICCP

Data Item Name

ICCP

Data Item NameICCP Data Transfer

Transpower SCADA/ICCP Gateway Customer SCADA/ICCP Gateway

(includes ICCP data item

name)

The rules for ICCP data item names are as follows:

Upper case letters (A…Z), the ten digits (0…9), and underscore.

No embedded blanks.

Must begin with a letter.

Maximum length of 32 characters (for performance, the shorter an ICCP point name the better).

The ICCP data item names to be used will be assigned by Transpower, and will be in the following format:

CCC_SSS_DDDDDDDDDDDDDDDDDDD_NNNN

Where:

CCC = Customer abbreviation (from TP.AG 10.11 Appendix B). Fixed length, 3 characters. Note that this is to be the Power System Customer abbreviation from TP.AG 10.11, and not a substation, power station or communications site abbreviation. The ICCP name is to indicate the connected company and not the site at which the connection occurs. Additional Power System Customer abbreviations are to be added to TP.AG 10.11 (via the Controlled Document Feedback form) as necessary.

SSS = Station/site three letter abbreviation (from TP.AG. 10.11 Appendix B). Fixed length, 3 characters.


Nov 2011


D…D = Device or GIP/GXP identifier (e.g. 112, T6, etc.). Variable length, 19 characters maximum, except for Controls, where the maximum length is 11 characters (see note below).

N…N = Point/measurement/control name (e.g. POS, MW, OPEN, etc.). Variable length, 4 characters maximum.

Please note that:

The customer‟s name is always to be the name of the party connecting to Transpower, regardless of whether the data item is being sent by Transpower or to Transpower, except in cases where the same data item is being shared with multiple parties. When this occurs the name will simply be prefixed with TP (e.g. the TP_HEARTBEAT signal).

The underscore character (_) shall only be used for delineating between the four fields. It shall not be used to separate parts of the name in the device identifier (e.g. BUS A shall be BUSA and not BUS_A).

While the dollar sign ($) is a permitted delimiter in ICCP, it shall not be used in data item names.

While lower case letters are permitted in the data item name by ICCP, in Transpower‟s ICCP system these are automatically switched to upper case letters, therefore, to avoid subsequent confusion, only upper case letters shall be used.

The Point/measurement/control name field shall never have trailing underscore or dollar characters.

The total length of the ICCP name for a control data item cannot exceed 24 characters where select-before-operate is used. This is because the ICCP link has to build a name such as <ICCP control data item name>_success (i.e. a concatenation of up to 8 characters).

The data item names are to be documented in the point documentation tables, refer sectionA10.

A9 Data Items to be Exchanged

The data items to be exchanged between Transpower and the Customer over ICCP will include:

Generator and grid information (as applicable), as required by Electricity Industry Participation Code 2010, Schedule 8.3, Technical Code C, Appendix A.

Feeder information, as detailed in TP.GC 29.01 Customer SCADA interconnection policy.

The heartbeat analog values (used for diagnostic purposes), as detailed in clause A10.1.

Other data items as agreed, by mutual agreement between Transpower, the ICCP connected Customer, and the owner of the equipment (where this is another party, e.g. in the case of embedded generation).


Nov 2011


A10 Point Documentation Tables

A point documentation Excel spreadsheet is to be completed for all points being transferred over the ICCP link. The data from Transpower shall be in a separate worksheet (or worksheets) to the data from the Customer (e.g. “Analog Points from Transpower” and “Analog Points from Customer” shall be in separate worksheets). The following tables identify the required items to be included for each data type.

A10.1 Analog Points

To be completed by Transpower To be completed by Customer

To be completed by data item owner (i.e. sending party)

Point No.

Transpower SCADA Analog Name ICCP Data Item Name Customer SCADA Analog Name

Eng Units

Eng Min

Eng Max

Precision

1 SUBSTN.BEN.BUS.220KV_BUS.TLM.HZ TP_HEARTBEAT Hz 45 55 0.01

Note that it is a Transpower requirement that a heartbeat analog value is provided in each direction. Any analog value that changes frequently may be used. Transpower will provide a grid frequency value as a heartbeat.

A10.2 Status Points


To be completed by data item owner (i.e. sending party)

Point No.

Transpower SCADA Status Point Name

ICCP Data Item Name Customer SCADA Status Point Name

ICCP States

00 01 10 11

A10.3 Controls


To be completed by data item owner (i.e. receiving party)

Point No.

Transpower SCADA Control Name ICCP Data Item Name ICCP Check Back Name

Customer SCADA Control Name

Open Control Close Control

The ICCP Check Back Name is required for all select-before-operate Controls. This name is an arbitrary number (range 1 to 32767). Refer to clause I5.4.


Nov 2011


A10.4 Setpoints


To be completed by data item owner (i.e. receiving party)

Point No.

Transpower SCADA Setpoint Name ICCP Data Item Name Customer SCADA Setpoint Name

Eng Units

Eng Min. Eng Max.

A11 ICCP Association Information Exchange

To facilitate ICCP associations between ICCP nodes, the following form is to be completed by both Transpower and the Customer (refer document ICCP Data Exchange (Transpower – Client) available from Market Systems & Transmission Applications Group.

The entries are marked (via the required column) as follows:

Mandatory (M). This information is required in order to create an ICCP association.

Recommended (R). This information should be provided if applicable.

Optional (O). This information helps with troubleshooting if connection or data transmission errors occur.

There is some flexibility with some of the items in this table, and the table entries are to be mutually agreed between Transpower and the Customer. Each Transpower – Customer ICCP connection may have to be configured slightly differently, as there may be constraints with some ICCP implementations that enforce this. This will likely affect the following table entries in particular:

ICCP Version. The Transpower gateway supports ICCP version 1996-08 or version 2000-08, with version 2000-08 preferred. Note that both ends of an ICCP link must be configured to use the same version. There is no interoperability between versions.

The various time settings, retries and PDU size may need to be negotiated in order to get a stable connection.

Some systems impose constraints on the AP Title, AE Qualifier, Presentation Selector (PSEL), Session Selector (SSEL), and Transport Selector (TSEL) entries.

The values in the table below are indicative for information only, and the actual values to be used will be agreed with each customer at the time of implementation.


Nov 2011


Item Description Required Transpower Details Customer Details Notes

Company-wide / Server independent information

ICCP vendor and platform M Alstom Grid e-terraComm

Version 2.5.0

Windows Server 2003 SP2

HP ProLiant DL380 G5

The name of the ICCP vendor, vendor software version. The operating system and hardware platform used for the ICCP servers.

Number of possible ICCP servers

R 4 total

2 Pre-production

2 Production

This is the total number of ICCP servers that may be available to associate with. Include backup servers if they have unique addresses.

Domain name M TPNZ CCC This is the domain name which is used to access data on the other party‟s ICCP node. It is to be the 3 character customer abbreviation as described in subsection A8.

Bilateral table ID M BLT1 The bilateral table name used when accessing the other party‟s data.

Supported ICCP services M Blocks 1, 2, 4, 5, 7 & 8 (8 only with version 1996-08)

A list of the conformance blocks supported by the server (e.g. Blocks 1,2).

ICCP version M TASE.2 Version 2000-08 preferred (1996-08 also supported)

The version of ICCP running on the server (e.g. TASE.2 Version 1996-08). Both ends must use the same version.

Shortest periodic interval O 10 seconds Time in seconds at which the data is being updated in the ICCP server by SCADA. This is essentially the minimum polling speed for obtaining periodic data, as polling at a faster rate will not result in any additional changes.

IP address of the WAN port

R To be determined Either a fully qualified domain name or a 12 integer number delimited with periods.


Nov 2011



Transport Layer Ack. Time O Setting on present link is 1 second, see Notes.

The maximum time in seconds that can elapse between receipt of a TPDU by Transport from the network layer and the transmission of the corresponding acknowledgment. Typically 5 seconds. Will need to be tuned for each link in order to get a stable connection.

Transport Layer Retransmission Time

O Setting on present link is 1 second, see Notes.

The maximum time in seconds Transport will wait for an acknowledgment before retransmitting a TPDU. Will need to be tuned for each link in order to get a stable connection.

Transport Layer Window Time

O Setting on present link is 10 seconds, see Notes.

The maximum time in seconds that Transport will wait before retransmitting up-to-date window information. Typically 10 seconds. Will need to be tuned for each link in order to get a stable connection.

Number of Retries O 6 The maximum number of attempts to retransmit a TPDU before issuing a Disconnect Request. Typically 6.

Maximum MMS PDU size O The minimum size for ICCP with security is1024, see notes.

Size in bytes, of the maximum MMS protocol data unit. The PDU size may need to be tuned for each link in order to get a stable connection. The allowed range, for ICCP with security, is 1024 to 8192.

ICCP Server specific information


Nov 2011



Server name O POAG1 and POAG2 for production servers (full names are HNRT-POAG1 and WNRT-POAG2).

PPOA1 and PPOA2 for pre-production servers (full names are WNDT-PPOA1 and HNDT-PPOA2).

The name by which the servers is referred to. This field is not electronically transmitted during any ICCP transactions, but is here to facilitate verbal communication between the parties.

(Note that OAG is simply the former Alstom abbreviation for what is now the e-terracomm ICCP gateway product).

Server number R The two production servers are peers. Either may be the active server.

The two pre-production servers are peers. Either may be the active server.

“1” if this is the primary server, “2” if this is the first backup, etc.

IP network address R Will be advised at time of implementation

The IP address for this ICCP server.

AP Title R POAG1: 1 1 1 1 POAG2: 1 1 1 2 PPOA1: 1 1 1 3 PPOA2: 1 1 1 4

Optional object identifier representing the Application Process Title given to this application.

AE Qualifier O 1 A long integer (32 bit signed) used to qualify the application entity.

Presentation Selector (PSEL)

R 00 00 00 01 2 or 4 byte number used to select the correct instance of the presentation layer. Typically 00 09 or 00 00 00 09.

Session Selector (SSEL) R 00 01 2 or 4 byte number used to select the correct instance of the session layer. Typically 00 09 or 00 00 00 09.


Nov 2011



Transport Selector (TSEL) R 00 01 2 or 4 byte number used to select the correct instance of the session layer. Typically 00 09 or 00 00 00 09.

Association Type R Dual direction Client-Server (where supported by Customer‟s ICCP implementation)

Dual direction Client-Server (where supported by Customer‟s ICCP implementation)

Typically “Dual direction Client-Server”, where the ICCP nodes act as Client and Server over one association and information can be sent in either direction per association.

The alternative is “Single direction Client-Server”, if the ICCP nodes act as either Client or Server over one association, and information can be sent in only one direction per association.

Association Initiation R Transpower Transpower Used if the association type is “Dual direction Client-Server” and indicates which ICCP node shall initiate the association.

APPENDIX M VOLUME 3 of TP.DC 29.02 Issue 1 draft 5

Nov 2011

© 2011 - Transpower New Zealand Limited (last page) 21

B CONTROLLED DOCUMENT FEEDBACK FORM

If you would like to submit any feedback or suggestions to Transpower to improve this document, there are two ways you can do this. You can either complete the form below and fax it to: Controlled Documentation Services, Transpower New Zealand Ltd, on 04 495 7100; or you can submit a form online – just look for the Controlled Document Feedback Form on the Contractors/Consultants section on our website at www.transpower.co.nz.

Content change request No:

Date: Initiator's name/title:

Company: Phone: Fax:

Email:

Controlled document number: TP.

Controlled document title:

Affected section or clause number(s):

Present clause:

Proposed change:

Reason for change:

If you are including supporting information or attachments, please list here, e.g. photos:

http://www.transpower.co.nz/

iccp - transpower · iccp does not directly control the device, rather it communicates a client‟s...

Documents