ICCP Operations and Services: The Complete TASE.2 Map

TASE.2 defines its functionality as operations and actions on objects, then maps each one onto an MMS service. That mapping is the Rosetta Stone of ICCP work: vendor documentation speaks TASE.2 (“Start Transfer”), the wire speaks MMS (“Write”), and moving between the two is half of every troubleshooting session. This reference lays out the complete map in both directions, verified against IEC 60870-6-503.

Two terms first, because the standard’s split carries real meaning. An operation is initiated by the client — it asks. An action is performed by the server on its own initiative — it monitors, reports, and enforces. Conclude and Abort can come from either side. Everything ICCP does falls into one of these.

The forward map: TASE.2 → MMS

Association operations

Alongside these sits the first server action: Access Control, mapped to no MMS service at all. The server checks every request against the bilateral table — pure server-side behavior, invisible on the wire except as rejections.

Data value operations

Get Data Value Type deserves a note: it returns the MMS type description, letting a client verify at runtime that a point is the Data_RealQTimeTag it expects rather than the Data_RealQ the server thinks was agreed — the type-mismatch check from the object models article, available as a service.

Data set operations

Get Data Set Element Values doubles as the “initial values” read that every RBE client owes itself at startup — the transfer sets article explains why.

Transfer set operations and actions

Note the elegance and the trap in one design choice: Start Transfer and Stop Transfer are both Writes to the same transfer set variable. What distinguishes them is content — Start carries the parameter block with Status enabled, Stop disables it. In a capture, don’t ask “is this a start or a stop” from the PDU type; read the values.

The Information Message transfer set follows the same trio (Start Transfer, Stop Transfer, Transfer Report) for operator messages, and a Get Next TSTransfer Set operation still appears in the standard’s table for the legacy Time Series mechanism — out of scope since the block removals covered in the conformance blocks article.

Device operations and actions

Those four actions are mapped to EventNotification — an MMS service the current functional profile excludes. The standardized outcome channel exists on paper and can’t fire in a conforming implementation; feedback flows through the associated indication point instead. The device control article covers that gap and the working sequence in full.

The reverse map: what an MMS PDU might mean

This is the direction capture analysis actually runs in. Wireshark shows you the MMS service; the TASE.2 meaning depends entirely on which variable the service touches. The disambiguation table:

A Read is one of five things. Get Data Value (an ordinary point name), Get Data Set Element Values (a variable list name), Get Next DSTransfer Set (the variable Next_DSTransfer_Set), Select (a name ending in _SBO), or Get Tag (a tag variable). The handshake reads of Bilateral_Table_ID, TASE.2_Version, and Supported_Features are Get Data Value in protocol terms, doing version-check duty.

A Write is one of five things. Set Data Value, Set Data Set Element Values, Start Transfer or Stop Transfer (target is a transfer set variable — read the content to know which), Operate (a device variable), or Set Tag.

An InformationReport is a Transfer Report — from a DS transfer set or, on links using block 4, an information message set. The Transfer_Set_Name inside tells you which, as the Wireshark guide shows.

GetNameList, GetVariableAccessAttributes, GetNamedVariableListAttributes are discovery: names of points, a point’s type, a set’s membership.

Initiate, Conclude, Abort are the association trio, one to one.

Memorize the Read and Write lists and raw captures stop being ambiguous: service tells you the verb, variable name tells you the sentence.

The errors that carry the diagnosis

Rejections arrive as MMS error responses, and four codes do most of the talking. OBJECT-NON-EXISTENT: the name doesn’t exist on the server — typically a spelling or scope mismatch between the two configurations. OBJECT-ACCESS-DENIED: it exists, but the bilateral table doesn’t grant this client this operation on it. TEMPORARILY-UNAVAILABLE: valid request, wrong moment — a device armed by another client, a tag in the way, a busy resource. HARDWARE-FAULT: the server reached toward the real world and the real world declined — an unavailable device at Select, a failed command at Operate. The first two point at configuration, the third at state, the fourth past the ICCP server entirely. That’s a triage order worth keeping.

One more response type belongs in the list: the MMS Reject, which isn’t a TASE.2 error at all. It means the peer received a service or object class outside the profile — the correct, mandated answer to anything the current editions exclude, and the expected result of the probe test from the security article.

FAQ

How many operations does TASE.2 actually have? In the current edition: three association operations, four on data values, six on data sets, three transfer set operations plus the allocation read, four device operations, and the information message pair — around twenty client-initiated operations, riding on roughly ten MMS services. The legacy editions had more; the removed blocks took their operations with them.

Why do so many operations share so few MMS services? Deliberate design: TASE.2 puts its meaning in named variables and their structures, not in service variety. That’s what lets the functional profile exclude most of MMS for security without losing any TASE.2 capability — the small service set is the feature.

Is there an operation to browse the bilateral table? No. The client can read the table’s version (Bilateral_Table_ID) and discover what it’s been granted via GetNameList, but the table’s contents are never exposed as a service. Discovery shows you your own permissions, nothing more.

What’s the difference between Conclude and Abort in practice? Conclude is negotiated — either side proposes, outstanding work completes, and a busy peer may refuse it. Abort is unilateral and immediate, via ACSE. Monitoring systems should treat the two very differently: a Conclude is an administrative event, an Abort is a fault symptom.

Which operations does a minimal (block 1) client actually need? Associate, the handshake reads, Get Data Value, the data set reads, Get Next DSTransfer Set, Start and Stop Transfer, and handling of Transfer Reports. That short list is a complete working ICCP client — everything else is capability the agreement adds.