IEC driver details

Type identification

The type identification octet specifies the structure, type and format of the information object.

Type identification UI [1...8]<1..255>

<1..127>: compatible range for standard specifications

<128..135>: reserved for message routing ("private" range)

<136..255>: for special applications ("private" range)

Please see the section on Compatibility for details on the type identifications used in WinCC OA.

Variable structure qualifier

The variable structure qualifier contains the number of information objects or elements and the SQ bit ("Single"/"Sequence") that specifies the address type of the following information objects or elements.

Structure qualifier octet:

• Number: UI7[1..7]<0..127>: 0 means no information object contained, <1..127> the number of information objects.

• SQ: BS1[8]<0..1> Single/Sequence

  <0>: Address of a single element or combination of elements from a number of information objects of the same type.

  <1>: Address of a sequence of information elements in a single object of an ASDU.

  SQ<0> and N<0..127>: Number of information objects

  SQ<1> and N<0..127>: Number of information elements in a single object of an ASDU.

The variable structure qualifier is set/interpreted by the driver. That means that there is no need to configure it and so it is irrelevant for the user.

Cause of transmission

The ASDU forwards the cause of transmission (spontaneous, periodical, etc.) to a specific application task (program) for further processing. The octet contains the cause, job confirmation (positive, negative), a test bit (to check transfer without influencing the process) and the originator address:

• Cause: UI6 [1..6]<0..63>; 0 undefined, <1..63> cause identification, <1..47> for the compatible range (as per standard), <48..63> private range for special use

• P/N: BS[7]<0..1>; 0 positive confirmation, 1 negative confirmation

• T: BS[8]<0..1>; 0 no test, 1 test

• Originator address: UI8[9..16]><0..255>; <0> not specified, <1..255> number of originator address

Please refer to the Compatibility section for details on the compatible range. Please see the standard for a detailed description of causes of transmission.

The cause of transmission is either defined by the driver automatically or set by the user. The standard behavior is implemented as follows:

A cause of transmission 6 (activation) is used when the driver sends commands (C_* messages). When the driver sends messages (M_* messages) the cause of transmission is 3 (spontaneous).

The input-sided cause of transmission is implemented as follows:

20 <= COT <= 36 ... Message because of GA (the GA bit in PARA panel is set)

COT == 5 ... Message because of a single query (EA bit in PARA panel is set)

other COT ... spontaneous Message or another reason (no bit is set).

In order to distinguish between the messages (M_* messages) that are normally sent by WinCC OA (this means cause of transmission spontaneous = 3) and messages that are sent as a result of a IGQ (Inverse General Query)there is the config entry useCOTGQ (see also possible config entries of the IEC driver). When the value of the config entry is "Yes" (default is "No") the COT (= Cause of Transmission) 20 (queried cia GA) is used for all messages that are sent because of an IGQ, the COT 37 (queried via general counter query) is used for counter messages. Normally the Cause of transmission is 3.

There exist two possibilities fore mapping the COT manually:

The usage of user bytes

The usage of a COT address has the drawback that a additional data point element incl. a special COT peripheral address is required (see address type in Panel for defining the peripheral addresses of the IEC driver).

The COT address

Since the WinCC OA release 3.8 it is possible to map the "Cause Of Transmission" (COT) on user bytes. This new method should be preferred to the COT address in the future.

In order to map input-sided the COT and the origin address on WinCC OA, the config entries UserByteCOT and UserByteOrigin have to be set on the number of the used user byte. By default the value is "0" and no mapping occurs. With the following config entries the COT is mapped on the user byte 3 and the origin address on the user byte 4.

UserByteCOT = 3

UserByteOrigin = 4

In order that the user byte values will be integrated in the telegram out-sided, the config entries ConnUserByteCOT and ConnUserByteOrigin have to be set on the number of the used user byte. Like mapping via ConnUserByteQ it applies also here that every change of the corresponding user byte (or of the contained user bit) triggers a hotlink and sends the value to the peripheral address. In order to avoid multiple telegrams the _original.._value and the corresponding _original.._userbyte<x> have to be set in a dpSet() for every application. That means that if the value, COT and the origin address shall be changed at the same time, this must be done using dpSet() in order to avoid telegrams with intermediate states.

Compatibility of COT addresses in the user byte variant

Input-sided:

Up to now it was possible to configure for each COT and each origin address a "COT peripheral address". This have the continuing ability, even if UserByteCOT or UserByteOrigin are unequally 0, however, it makes no sense to combine these to variations in a new project.

Output-sided:

Up to now there were also "COT peripheral addresses" on the output side. They continue working, when ConnUserByteCOT and ConnUserByteOrigin are set to 0. If an entry is unequally 0, so only the information from the user byte will be integrated in a telegram.

If the user byte for the COT set to 0, so the default COT from the driver will be used.

Common address of ASDU = region, component

The common address is common to all objects in an ASDU. The global address is an address sent to all stations of a particular system.

Common address: UI8[1..16]<0...65535>

<0>: not used

<1...65534>: station address

<65535>: global address

ASDU with an "address to all" in control direction must be answered in monitor direction with ASDU that contain the specified common address (station address).

Information objects = Information Object Address

The address of the information object (1, 2 or 3 octets) is used as the destination address in control direction and as source address in monitor direction. Depending on the number of octets the address of the information objects is:

UI [1...8]<1...255>: HB

UI [1-16]<1...65535>: MB

UI [1-24]<1...16777215>: LB

Please refer to the IEC 60870-5-104 standard for a detailed description.

Number of ports and re-establishing the connection

In theory the number of ports (serial interfaces), which can be handle by the IEC 101 driver, is depending on the possible serial interfaces of the corresponding operating system. For Windows the number of ports (serial interfaces) is limited to 255.

The theoretical number of slaved in a unbalanced mode is defined by the maximum value of the link address.

The specification is "theoretical", because in most cases a maximum number has a bad influence on the performance.

In case of disconnection to the peripheral address, the driver tries periodically to re-establish the connection.

General query

Automatic general query at driver start or redundancy switch IEC

The properties of the general query can be specified with the config autoGQ entry (for details see chapter Possible IEC driver config entries). The behaviors of the IEC driver 104 and 101 are identically. An execution of a general query requires that the common object addresses in the local/global list are explicitly defined, i.e. there a no wildcards present.

Access to different frame types via subindex

The table shown below contains the information of the existing frame types and frame fields that you can access via subindex. In this context note the following points:

Quality Information

The quality information in the command direction (C_* as well as M_* frame types can be sent to the command direction) is built for some frames as OR relation of the value that is specified via the subindex. The value is built with the value from the address (e.g. M_SP_NA_1 or C_SC_NA_1). This is the case if the data or a part of the data and the quality information are included in the same byte. In case of other diagrams the value can only be built from the address via the Quality Information (e.g. M_BO_NA_1 or C_SE_NA_1).

When the quality information is input-sided mapped on user bits, then the user bits will be set on all relevant subindices.

DPE type

The DPE type does not have to be set like shown in the table because a type conversion is also made. This way you can use e.g. the type int instead of bool. The int can get the values 0 or 1. In case of incompatible types an error message is shown during the transformation. You should of course use the types of the table unless there are some other reasons against the use.

Special subindices

For some frame types there are special subindices that facilitate the access to data. This way it is e.g. possible to access the DPI field as "unsigned int" via the subindex 8 in case of the M_DP_NA_1 telegram. This means that you do not have to define two DPEs for DPI bit 0 and DPI bit 1.

The user byte value from a data point element with lowest subindex is written output-sided on the data point elements with higher subindices.

When defining the peripheral address you have to configure the direction "Output (group)" for the following frame types (listed in the table)!

Private frame types

The frame type 135 belongs to the private types. I.e. the content of a BLOB DPE is transmitted and no interpretation of the data takes place. This is valid for the IEC 101 and 104 driver.

This frame type functions only with DPEs from type blob. Additionally you have to set the Information Object Address to 0.0.135.

Consistency check of frames

IEC 101

The following is being checked:

1. Consistent frame header

2. Checksum

In the event of an error the connection is reinitialized as a consequence.

IEC 104

The following is being checked:

1. Consistent frame header

In the event of an error the connection is reinitialized as a consequence.

If the calculation of the checksum fails, the connection will be initialized newly. In this case an normal error message is shown, that the connection is lost. With the debug level "-dbg 27" you can have a closer look whether the checksum causes the error.

Optimization of the data throughput

Telegrams are packed into one telegram when they are sent. The system checks whether TYP, COT (= Cause of Transmission) and COA (Common Object Address) of the last telegram match these of the current telegram. If they match, the information object is added to the last telegram in the queue, if this is possible when the length is considered. It will be tried to add the IOA on the last telegram in the queue, in order to secure that one telegram does not pass another.

Possible error messages when using the IEC driver

WCCOAiec (1), 2005.02.26 17:27:25.622, PARAM,SEVERE, 54, Unexpected

state, IecResources, DP-Element does not exist , _Iec_1.FileTransfer.Command:_original.._value

WCCOAiec (1), 2005.02.26 17:27:25.623, PARAM,SEVERE, 54, Unexpected state, IecResources, DP-Element does not exist , _Iec_1.FileTransfer.Status:_original.._value

These messages indicate that there is an inconsistency between the driver version and the internal data points or data point types.

WCCOAiec (1), 2005.02.27 16:27:19.990, PARAM,WARNING, 54, Unexpected state, IecTgLayer, generalQuery, Check format of local/global list entry, COA not correctly specified *.*.*.*.*

*.*.*.*.* is specified in the gloabal/local IEC list. The log message is a warning. A GQ via the internal data point or via the config entry autoGQ > 0 is not possible. To execute a GQ, both entries (Region + Component) have to be unequal to "*".