General information

Communication Driver NameP: ICCPDual
Current Version: 9.1
Implementation DLLP: T.ProtocolDriver.ICCPDual.dll
ProtocolP: ICCP tase2 Standard protocol
InterfaceP: Custom TCPIP
Description: The ICCPDual communication module implements both forms of use of the ICCP protocol: Client Station for communication with server stations compatible with this protocol, and Server station to meet requests from Client stations. It also allows use as a dual function, including in the same communication channel the two functions.
Protocol Options: Defined functions, log, and TcpIp endpoint mode.
Max number of nodes: Up to two for the same channel, one of which is one of each communication mode
PC Hardware requirements: Standard PC Ethernet interface board;
PC Software requirements: ActionNET system.

Presentation

Also known as ICCP, IEC 60870 part 6 belongs to the IEC 60870 set of standards that are used for remote control, monitoring, and telemetry in electrical system (power) telecommunications networks and power center control applications. The IEC 60870-6 standard is based on functional profile theory. A description of functional profiles, their classification and definition is taken from IEC 60870-6-1.
A profile for telecontrol application service element 2 (TASE.2) is known as ICCP - Inter-Control Center Communications Protocol. TASE.2 in the application layer is defined in the IEC 60870-6-503 standard. This standard defines the application layer protocol to meet the functional cooperation requirements. It also defines the requirements for the presentation and relationship layers that provide TASE.2.
The TASE.2 protocol is based on Manufacturing Message Specification (MMS). The basic functions of the ICCP are specified as a set of so-called "Compliance Blocks".
In this implementation the ICCP protocol supports the functions of blocks 1 2, 4 and 5

1. Periodic system data: status points, analog points, quality flags, date and time record, value change counter. Binding objects to track ICCP sessions.

2. Extended dataset condition monitoring: Provides report by exception capacity for the data types that block 1 can transfer periodically.

3. Transfers of Large Blocks of Data; Not implemented;

4. Information Messages

5. Device Control.- Sending key commands and set points to analog points to the client station

General operation

In the ICCP protocol, the client and server roles are well defined. In this implementation the same module can be used to define a node with the client or server role. You can define for the channel only the client function, or only the server function, or even you can define two nodes, in the same channel to include in the same connection tcp ip the two activities, completely independent of each other.

Server Mode

In this mode of use, by implementing the Server side, the module starts and waits for a client to connect to communication.
During your activity, you get the current real-time data on Action.NET and send it on request or through an unsolicited reporting mechanism.
Among the functions and features included are:

• Definition of data, called indication points

• Device model (commands)

• Datasets (Data Sets, get/set/create/delete/get directory)

• Data Set Transfer Transfers (Range, RBE, ...)

• Information Messages

• Bilateral Tables

• Secure (TLS) or non-secure connections

• Compliance blocks 1, 2, 4 and 5

Client Mode

In Client mode the module attempts to establish a Tcp Ip connection to a server station to initiate data communication with it.
Its main function is to provide the functions to access the data of a specific server.
Implements facilities for requesting data from the server station through periodic read and sampling operations, and either to establish and enable an unsolicited data transfer mode on the server.
Among the main functions and characteristics found in the client are:

• Navigate the server data model (browsing);

• Create the Server Data Model on the client

• Read and write referral points

• Send commands, set points, and tags to devices (Control Points)

• Request the creation of dynamic data sets on the server

• Read datasets (Data Sets)

• Set up transfer sets (DS Transfer Sets)

• Turn instant messaging (IM) on/off sets

• Enable/disable DS transfer sets (Data Sets)

• Receive transfer set reports

ICCP Server Data Model

Data model

The server data model DataModel, is made up of areas Domains, points of indication Indication Points, devices (Control Points), datasets Datasets and transfer sets DS Transfers Sets.
In TASE.2, variables are objects with names (Named Objects) that are part of the server address space. The variables can be system variables (such as "Bilateral_Table_ID", "Supported_Features", ...), indication points, protective equipment, and devices.
Variables can have two "scopes". The scope VDC or a user-defined domain-specific scope (ICC). Scope variables VDC are not part of any TASE.2 domain and are visible to all clients.

Domains

Scope variables VDC are identified only by the variable name. Domain scope variables are identified by the domain name and the name of the variable. Domain and Variable Name.
A TASE.2 domain is represented by a Domain Name. The domain object can contain all types of data points, datasets, and transfer sets.
A domain object is the first thing to create within a data model. In the addressing table Points, towards each tag Action.NET the ICCP address will be included the
<Domínio>/<Variable name>, thus separated by a bar.
For each Data Model (for each communication channel Action.NET ICCP) can only be created one domain.
For the case of variables included in the VCC scope, addressing does not use domain. It's like an empty domain. The address will have the form: <Variable name>.
The following are listed the existing data objects for the ICCP TASE environment.2

Indication points

TASE.2 supports different types of indication points (Indication Points).
The simplest version are simple boolean, integer, or floating (real) values. Optionally, a point of indication can have, in addition to its value or state:

• Quality field consisting of Flags quality indicators

• Date/time field (Timestamp normal or extended) that can represent date/time timestamps in seconds or milliseconds

• Cov field (value change counter, or Change Of Value

The following basic types are supported:

• STATE - State (assuming values 0.1, 2 or 3)

• STATE_SUPPLEMENT - State supplement.

• DISCRET - integer values up to 32bits.

• REAL - Floating-point values at 32 bits.

Device Models (Control Points)

There are three different types of control points:

• Commands – For the control of digital devices, represented by Action.Net tags of writing points such as keys and circuit breakers.

• Sending Device Service Tags - offside/blocking cards

• Discrete adjustment points - set points for integer tags (32bits)

• Real adjustment points - set points for 32-bit double (floating point) tags.

In addition, there are two control classes:

• Select Before Operate (SBO) - Select before operating. In this mode, the client must first send a "selection" message to "arm" the control point. When selected, the client must send an "operate" message before the selected timeout.

• Direct Straight through. In this mode, the control consists of sending a simple "operate" command.

DataSets and DataSets Transfer Sets

Datasets are lists of variables (system variables and data points) that can be read or written with a single read or write request by the client. They are also the basis for unsolicited data set transfer actions.

Data sets can be statically defined on the Server, or they can be created dynamically on the server, at the client's request.

A dataset can contain the following (domain scope) system variables:

• Transfer_Set_Name - The name of the associated transfer set (consists of the domain name and the transfer set name)

• DSConditions_Detected - Conditions that caused the transfer set report

• Event_Code_Detected - The event code of the report

• Transfer_Set_Time_Stamp - The timestamp set by the transfer moment (in seconds)

In the server module implementation, each time a DataSet is declared, these system variables will be included in the dataset.

Information Messages

The information messaging engine consists of an information message transfer (IM) set and information message buffers.
The information message transfer set is a specific mechanism of client-server association that (when enabled by the client) sends information messages from the server to the client. The message transmission is triggered by the server. Information messages can be vcc or ICC domain-specific, defined on the server and client.
Information messages may contain textual data or arbitrary binary data. The length of the information messages is limited by the available information buffers and the maximum size of the MMS PDU.
Informational messages will only be sent to a customer when the Bilateral Table or Bilateral Table allow it. With the bilateral table, information messages are restricted by their parameters of information reference, local reference and scope (ICC or VCC).
A text-Action.Net tag should be set to support the exchange of information messages. See more details in the section on Point addressing.

Bilateral Tables

The two-sided table (BLT) is created by the server, defining a domain and consists of the following elements:

• The ID bilateral Table - A unique name to identify the BLT.

• The application reference customer's (Ap-title and AE-Qualifier) - used for identification between server and client for the creation of a connection. See in the definition of the node stations. On the blt server is created using the one defined as remote ap-title, i.e. the local ap-title of the client.

• A name of Domain Specific TASE.2. The client side can access all objects in the domain included in the table without restrictions.

• A list of data point access control specifications, not included in the domain.

• If a VCC scope data point is not part of this list, it is not accessible to the associated client.
  Bilateral tables are an important part of the access control mechanism.

• If no BLT is defined, access control decisions are based solely on the access rights defined for the data point. These access rights are the same for all clients.

• If bilateral tables are defined, access control decisions are based on the access rights defined for the data point and those defined in the bilateral table for the requesting client.

• If a data point is not part of the two-sided table for the requesting client, the request is denied and an "access to object denied" response is sent to the client.

• If a data point is specified in the BLT for a client, access is only allowed if it is allowed in the data point access control specification and in the access control specification in the BLT.

Operations performed by the Client

The entire task of creating the data model is done in the Server module.

The Client Module browses the Server Data Model and creates lists of variables and data sets from the server data, to use in the read request.
Locally, by reading your table Points creates the matching tables between the Action.NET and the names of ICCP variables received from the server.

Read operations will be performed periodically, according to sampling periodicity times defined in the configuration of the Nodes channel using this protocol. If these periodicity times are set to Zeros, sampling operations are not performed.

Alternatively, the Client can define and parameterize Reports, or Ds Transfer Sets, so that the server sends the data in an unsolicited manner, based on defined criteria. For these transfers you can use statically defined data sets on the server, or dynamically create data sets at run time.

Sample readings

Basically there are three operations of Readings starting from the customer:

• Request to read all digital dots (STATE and STATE_SUPLEMENT)

• Request to read all analog dotss (REAL and DISCRETE)

• Request to read from data sets pre-defined on the server. The content, that is, the variables that will come in each date set are those defined on the server, by the specifications in the Points table of the server.

• Request to the server to create data sets by sending a list of variables, and later requesting reading of these data sets.

Data Sets Transfer Sets

In this protocol is available the functionality of Data Sets Transfer Sets or unsolicited reporting of data.
Through it is made the request by the client, for the configuration on the server, of a DS Transfer Set associated with a data set, and its activation.

The Data set to be used by the Transfer Set can be a pre-defined on the server or it can be a newly created on request of the client (dynamic data set).

The client requests the server for an available Transfer Set, associates it with a data set, and parametrically sets the DS Transfer Set. After this makes the activation of the transfer set. Then the server starts spontaneously sending, according to configured criteria, the data set data defined in the server data model.

The client then spontaneously receives the data from the server, in the form of Reports, without having to perform polling requests.
The Reports are actions of sending a set of variable data contained in the corresponding given set, executed according to the triggercriteria of these actions. Every Report, is identified by a sequence number, a publication date/time, and the cause of its execution.

Commands

The client can send commands to the server. For this they must be configured on the client and on the Control Points server for state commands (open, close, etc.) or for sending set points from analog points. Service Cards can also be sent to offside devices.
The triggering of these commands is done by changing the state or value of the tags Action.NET to the names of these Control Points on the server.

Written in Referral Points

For referral points (not Control Points), the write-on-demand operation is also possible.
In this operation, the indication points for which you want to be written in the corresponding ones on the server must be defined in the points table, in the Client, the Access Type field as Write.
On the server the Access Type must be of the type Read or WriteSlave. These points cannot and should not be defined as belonging to data sets.
The writing will be fired by the client each time there is a change in the state or value of the content of these points.