Download ICCP GUIDE PDF

TitleICCP GUIDE
TagsServer (Computing) Scada Communications Protocols Object (Computer Science) Osi Model
File Size297.0 KB
Total Pages57
Table of Contents
                            1. Purpose
2. Abbreviations
3. ICCP Concepts
	3.1 Protocol Architecture
4. Association
	4.1.1 Indication Point Object
	4.1.2 Operator Messages
	4.1.3 Meaning of TAConditions
	4.1.4 Block 9 (Time Series Data).
5. OSI
	5.1 Naming of Data Value Objects
                        
Document Text Contents
Page 28

entered by a dispatcher, operator or program. Because a “conscious” decision has been
made to assign a point its particular value, it is considered “good” or of high quality.

ICCP transfers the quality codes associated with each data point, however, the
assignment of local quality code bits in the receiver’s SCADA/EMS database is a local
implementation issue. Because each SCADA/EMS has its own symbols for displaying
data quality, each user must determine their own hierarchy of processing and mapping
to their own quality symbols.

Time Stamp

A description of the Time Stamp foundation type can be found in 870-6-802 section 6.1.1
as Data_TimeStamp.

The Timestamp attribute is used to assess the currency of the data value being
transferred. Data can be “old” for a number of different reasons: delays in out going
queues at the source SCADA/EMS, delays in transmission across the network, delays
due to congestion and re-transmission within the network and delays in in-coming
queues at the receiving SCADA/EMS. For all of these reasons, the data might need to
be time stamped at the source SCADA/EMS at the earliest time following collection of
that data from the field device. Values that are calculated from other values in the
SCADA/EMS should be time stamped at the time the values is stored in the
SCADA/EMS database.

Change of Value (COV) Counter

A description of the Change of Value foundation type can be found in 870-6-802 section
6.1.1 as COV_Counter.

A periodic information report transferring status and analog values will transfer only the
current value of the data point. A receiving control center might want to know whether
the point had changed and then changed back between information reports. For
example, an auto-reclose operation might easily occur between information reports and
not be recorded at the receiving site. A COV counter is incremented each time the
owner sets a new value for the Indication Point.

Building Complex Data Types

The complex types are created by combining foundation data types. The choice of
which complex data type to use is made by the implementer and is a balance between
efficiency and the extent to which additional information about the value being
transferred is required by the receiving site. For instance, if a client wants to receive
status with quality codes and a time tag, the client would specify the use of the
Data_StateQTimeTag complex type, described in 870-6-503, Section 6.1.1.

Protection Equipment Event Object

The protection equipment event object definition can be found in 870-6-802 Section
5.1.3.

When events occur at the substation, local relay actions may be taken to protect
equipment. These events may be phase-to-phase, phase-to-ground, over current, over
or under voltage, or other protective relaying schemes. In addition to the name of the
event, protection equipment event object reports:

Usguid5.doc October 8, 1996

Page 56

The best practical test of real interoperability is to bring together the developers and in a
controlled environment subject all possible pairs of vendor implementations to a
comprehensive set of well defined inter-operability tests monitored by an impartial
protocol expert.

In February of 1995, the UCSWG (Utility Communications Standards Work Group) held
a series of inter-operability tests between four vendors: Harris, Siemens, ESCA and
NSR. The results of these tests are available from EPRI as the ICCP Inter-Operability
Test Report (see Reference 4). A summary of these tests is presented in the next
subsection. A second interoperability test involving as many as nine separate ICCP
vendors is planned for late 1996.

Summary of Interoperability Tests

In order to test ICCP inter-operability, four levels of interaction between all possible pairs
of ICCP implementers were established. As each pair successfully achieved a given
level as both client and server they proceeded to the next level until all participants had
achieved level four. The four levels were:

Level-1 Network connectivity Physical connection to the network

Level-2 MMS Association Establishment of an MMS association
Level-3 ICCP Association Establishment of an ICCP association including:

exchange of Bilateral Table Ids
exchange of ICCP version numbers
exchange of ICCP negotiated features

Level-4 Block-1 Exchange Periodic exchange of power system data

In all, thirty-two tests were performed between each pair of testers in turn, with each
ICCP implementation acting as client or as server, and then changing roles. In some
tests, outcomes were different depending on whether the system was acting in the client
or the server role.

The results of the test clearly demonstrated that ICCP has achieved its primary goal of
inter-operability across multiple vendor platforms. A second important goal was to
strengthen the ICCP specification that was to go to IEC for international standardization.
This goal was also achieved by the identification of several areas of potential miss-
interpretation or different interpretation.

Version Compatibility

Version control is discussed in 870-6-503 section 7.1.1.1.1, where the client role in
association operation and action is described. The version control object definition can
be found in 8.1.9 as TASE2Version Type.

ICCP will continue to evolve as new objects are added and as new services are
required. ICCP anticipates this requirement and provides for an orderly evolution of the
protocol.

After verifying that the Bilateral Table ids are valid, an ICCP implementation client must
retrieve the TASE2_Version object from the server and compare with the local version
number. If a mismatch is found, the association is immediately terminated via the
Conclude operation. No further association establishment requests are permitted until

Usguid5.doc October 8, 1996

Similer Documents