General

Points can be inbound or outbound.
The input points for the client, which are distributed by the server by the protocol, are configured basically with three main parameters: The point type, the point name (consisting of a domain name and a variable name), and optionally the data set name if the point belongs to a data set.
The output points, used to send remote controls by the Client and receive them by the Server, have in addition to the type and address some parameters to detail the control operation.
The addresses of the points, that is, the domain/variable name, must be univocal.

Types of points

The ICCP communication module in Server mode implements types of reading points for the client, to:

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

• STATE_SUPPLEMENTAL - State supplement.

• DISCRET - integer values up to 32bits.

• REAL - Floating-point values at 32 bits.

Also points for commands:

• Digital commands

• Discrete adjustment points

• Real adjustment points.

• Tags (Cards) for control points

• Information Messages (IM)

And points for the definition of:

• Data sets and

• Dat sets Transfer sets

The figure shows part of the list displayed when you click the point type in the Address of the table POINTS.

Open

Point types include variations in which they are added in addition to value, or state, quality flags, and timestamp. In the table, ICCP Validity is quality, TimeStamp is the date and time of the last change of value with breakdown of seconds. Extended Time Stamp is the date and time including seconds and milliseconds. COV is the number of times there has been a change of value.

They are therefore as follows:

Adjustments for Values and Quality

In ICCP values, states, and quality follow a standard of their own.
Thus these states and qualities to be defined from the existing states and qualities in the Action.NET standard, need to be gathered when mounting data on the Server for sending to the client with the appropriate encoding in the protocol.

Representation of States
BETWEEN = 0,
OFF = 1,
ON = 2,
INVALID = 3

In the ICCP these are always the states. Even though a given circuit breaker is considered only with open and closed states, when transmitting this information will have to be in the form above.
Even the case of representation of action of a protectio the state should be 1 or 2;
To work around th problem, whenever a point with a state type is set, the module uses the current value of the point as a value if the tag does not have the field Parameter > EnumerationSet.
If the tag has the Parameter > EnumerationSet, will use the current ValueAsString text to set the current value, using the parameter list TextForValues in the ICCPDual file.XML, which can be changed for the project in question.

Data source representation

ICCP Validity Representation

For the definition of the OPC quality used in Action.NET from the ICCP Validity on the CLIENT side the following criteria are used:

For the definition of ICCP Validity in Server mode, the following criteria are used:

Point address

The filling of point addresses is done in the engineering environment, in Edit>Devices>Points.
The field Address to be filled in the point registration includes the point type the variable name in the ICCP and some complementary information, depending on the point type.
As shown in the figure below, a click on the address column row opens a window to select the type and address of the point. A click on the type opens a window with all types of points supported.

Open

Details about filling out this field for each of the various existing cases are listed below.

Indication Points

For this type of entry points, which include State, Discrete, Real and, StateSuplemment. The format of the address is:
<date type>,:<domain>/<Iccp point name>:<dataset Name>
Datatype: - must be chosen from the list by pressing the button to the right of the field.
DataNam: The domain name of the "/" bar and the point name must be typed. These names are treated as case-sensitive, case-sensitive. At the points allocated in the VCC only use the type and name of the point, without the domain.
Complement: On the Client side, the definition of the ICCP data set name is not required on the data set. This setting is made on the server and the Client only receives the data as defined on the server.

Datasets

For the definition of Data Sets will be configured as shown in the following figure:
Datatype choose the acronym DSET.
DataName - Fill in with the domain and name of the date set.
Complemment - In the Customer, it will be used for up to two parameters, separated by ":"

• The acronym for a timer, T1, T2 or T3 - To set the sampling periodicity, in the case of reading data sets by sampling, indicating one of the possible timers, as shown in the Nodes setting. If not set here, the T1 timer is considered.

• Only if the data set is to be created dynamically, the parameter must be included DYN, with an indication:

  • DYN=ANA - In the creation of the data set, a list of all analog variables (REAL and DISCRETE) is sent to the server

  • DYN=DIG - In the creation of the date set, a list of all digital variables (STATE and STATE SUPPLEMENTAL) is sent to the server.

  • DYN= <filter text> - In so that in the creation of the data set, a list of all variables whose ICCP names are appropriate for the filter is sent to the server.
    
    

parts

DataSets Transfer sets

For the definition of Data Sets Transfer Sets will be configured the following:
Datatype chooses the acronym DSTS.
DataName - Fill in with the domain and name of the associated data set, for which it will be used for transfers.
Complemment - Alternatives can optionally be set to the default setting defined by missing on the client. These parameters range from stock times to report generation criteria. See in item Setting up Data Sets Transfer sets, the following in this section.

Device Control Point

On the side of the Server these settings are for the communication module to find the tag Action.NET will be the purpose of the command. On the side Customer these specifications are used for sending the command.
The figure shows the padding of a device control point.

For this type of points, command, CMD. The format of the address is:
CMD:<domain>/<Iccp control point name>:< command parameters>
Datatype: - must be chosen from the list by pressing the button to the right of the field type C MD
DataName: The domain name of the "/" bar and the control point name must be typed. These names are treated as case-sensitive, case-sensitive. At points allocated in the VCC only use the type and name of the point, without the domain, as in DC: DiscreteVcc.
Complemment: the details for the command should be entered in the form:
<DIR/SBO>:<TAG/NOTAG>:<Check num>
Where:
DIR - indicates simple direct command
SBO - Indicates command with Select Before Operate. In execution a SELECT command will be sent by the Client and soon after, if successful in this operation, the command will be sent itself.
TAG/NOTAG – indicates whether it will be included in the creation of this point, the functionality of having a label, such as a offside card, that can be sent for it to be associated with the device. NOTAG indicates that this feature will not be used.
CheckNum- It is a number to distinguish one command from another, the same number for the same point, but different for each point. Anyone can be chosen, but it will be fixed to the point.

Set Points

On the side of the Server these settings are for the communication module to find the tag Action.NET will be the purpose of the command. On the side Customer specifications are used for sending the command.
For this type of points, command, CMD. The format of the address is:

Datatype: - must be chosen from the list by pressing the button to the right of the field one of the DCSP or RLSP types, depending on the value type.
DataName: The domain name of the "/" bar and the name of the output point must be typed. These names are treated as case-sensitive, case-sensitive. At points allocated in the VCC only use the type and name of the point, without the domain, as in DC: DiscreteVcc.
Complemment: the details for the command should be entered in the form:

Where:
TAG/NOTAG - indicates whether a label, such as a offside card, will be included, that can be sent to be associated with the device. NOTAG indicates that this feature will not be used.
CheckNum- It is a number to distinguish one command from another, the same number for the same point, but different for each point.

Tag attributes for devices (control points)

In the name of the ICCP a Tag is a label associated with a control point (such as a deterrent or maintenance card), which this protocol defines. A client can then send a card like this to the server, using the name of the control point. A code with the card type and a free text can be sent with the reason for the impediment (reason). A tag (an object Action.NET must be used to define this point.
For this type of point the address format is:
TAG:<domain>/<Iccp Control point name>
TAG - It's kind of a point label for the ICCP communication module.
Data Name -The domain followed by "/" and the ICCP name of the associated control point.
The tag submission operation is done by the Client as follows and sequenced, from project scripts:

• If Password is used for the command the EstimatedValue field of the Action.NET tag of this tag point must be filled with the Password;

• If you need to send a text with the reason for the label, this text should be placed in another tag with the same tag name defined in POINTS, plus the suffix _RS. This text will be sent by the protocol along with the tag value: example Tag.DEV_CONTROL_OFF, is the tag for command, Tag.DEV_CONTROL_TG is the point that will contain the card number. Tag.DEV_CONTROL_TG_RS, it will contain the text of reason.

• The tag value set in POINTS, should be changed to one of the following codes:

0 = NO_TAG - indicates that the device is not labeled and can be used normally
1 = OPEN_AND_CLOSE_INHIBIT - opening and closing commands are not allowed
2 = CLOSE_ONLY_INHIBIT - a lock is not allowed
3 = INVALID - Invalid tag. May indicate a software problem.

Information Messages

They are text messages or any even binary content, which can be sent from a server to a client. On the Client side you must define a text tag, which will receive the message data buffer.
For this type of data the format of the address is:
IM:<domain>/IM:<complemment>
IM - Type IM should be chosen from the type list
Domain - must be entered the name of the domain followed by bar and fixed name IM. If it is to define VCC scope put only the IM name without domain and without bar.
Complemment - will be formed by two numbers separated by ": " for the identification of the message:
infoRef - reference to the message
localRef - reference to the location from which the message came from.
These numbers can be defined by their own criteria, the important thing is that they are the same on the server and on the client, so that the association between the points of the Action.NET.
The figure shows example of setting points for messages:

Both on the Client and on the Server, you must define two points for each message area that you want to use, for example:

• Tag.ICC1.MSG – Main tag, which will be used to contain, in real time, the identification number of the message, which when changed by the Server, will cause the message to be sent. This is the tag that must be registered in POINTS for the definition of the infoRef and localRef fields.

• Tag.ICC1.MSG_IM – With the same tag name as above, added from the suffix _IM, with text type, which will contain the text of the message. The server places this text in its tag and the client receives it in its Value attribute.

The tag submission operation is done by the Server as follows and order, from project scripts:

• If password is used for the command the EstimatedValue field of the Action.NET tag of this point (e.g. Tag.ICC1.MSG) must be filled with the Password;

• The text to be sent should be placed in the other tag (with the suffix _IM, ex. Tag.ICC!. MSG_IM).

• The tag value set in POINTS, must be changed to a new value, which can be a sequence number of messages. This triggers the shipment.

Setting up Data Sets Transfer sets

Data sets Transfer Sets (DSTS) are the most important and efficient mechanism for sending data from the server to the client. They can be used to send data from the server to the client without the client sending requests.
On the client it is necessary that it use the correct domain name that is assigned by the BLT.
The DS Transfer Set is then created, associated with a data set, and can be configured by adjusting the configuration properties of the transfer set. Transfers will be made from the list of variables of the date set.
Then also other important parameters can be configured.
The following table shows the parameters that can be configured and the choice of parameters that is made automatically by the Client module by default. If all these parameters are acceptable as they are, you do not need to specify parameters for the DS transfer set.

DS Transfer Sets configuration parameters

DS CONDITIONS

The DataSet Conditions control how DSTS is sent. They are configured in the POINTs table in the DS Transfer Set definition line.
There are a few important rules to follow when setting up DS Conditions for a DSTS:

• Interval with RBE off works as Health with RBE on.

• A time value for StartTime of 0 means to send now.

• The Interval Time Out flag controls the Interval Timer.

• The interval is how often the report will be sent. When RBE is set, only points that change in the range are reported by name.

• Health timeout flag controls the health timer.

• Health is how often the entire DataSet is reported.

• The object change flag controls buffertime.

• BufferTime is the time interval for buffer changes before reporting to the TASE.2 client.

• BufferTime begins when the first object change condition occurs.

• If the RBE is turned off, the entire DataSet is reported.

• If RBE is turned on, only the current state of the objects in the dataset that have changed are reported

• If BufferTime is 0, a report is generated for each change.

• If multiple changes occur on the same object during a BufferTime, only the last value is reported.

How to change parameters
In the figure below is shown the definition of two Data Sets Transfer sets in the POINTS table, with settings for changing the configuration parameters.

In the field Complement you must type the Key Words of the parameters you want to change (second column of the table above) followed by the = sign and parameter value, separated by the colon sign: as in
Parametro1=xx : Parametro2=yy : Parametro3=zz
True and false values will be used in English TRUE and FALSE;
In the example shown, we have in Complement:
DSCONDITIONS = ITC:BUFFERTIME=1:ALLCHANGES=TRUE:INTERVAL=20
In this case:

• DSCONDITION = ITC, is changing the default so that only the integrity, TIMEOUT, and CHANGES criteria (changes in states and values) are used for generating this report.

• BUFFERTIME = 1, changing so that the wait time for changes is only 1 s.

• ALLCHANGES=TRUE, is defining All Changes Report, all changes are included in the reports.

• INTERVAL=20, enforces the maximum interval time between reports is 20s.

Access Type

Customer

In mode customer there is a need for some characteristics specific to the parameterization of the field Access Type of the table Points:
For digital and analog points with types that are read: (READ)
The Access Type should be set with:
ReadOnStartup= on
ReadPooling= always;
ReadPoolingRate: 1000
For Control Points and Information Messages command points and for Indication Points for writing (WRITE)
The Access Type should be set with:
ReadPooling = Never;
WriteEvent= Change
WriteEventEnable: on

Server

In server mode there is a need for some characteristics suitable for parameterization of the field Access Type of the table Points:
For STATE and STATE_SUPPLEMENTAR with types that are read:
The Access Type should be set with:
ReadOnStartup= off
ReadPooling= never;
ReadPoolingRate: 0
WriteEvent= Changed;
AccepUnsolictited = On;
For points with measure types, using Analog Samples and command types:
The Access Type should be set with:
ReadPooling = Never;
WriteEnable = disable
WriteEvent= disable;