Every ICCP link runs on a pair of bilateral tables. They decide who may connect, what they may see, and what they may do. They are also the single most common reason a new ICCP link doesn’t work on day one — not the protocol, not the network, the tables.
This article covers what a bilateral table is, exactly which checks the server performs against it, how it maps onto MMS, and the CIM-based exchange model that IEC 60870-6-503:2014 added so utilities can stop swapping table configurations by spreadsheet. Everything here is verified against that standard.
If you’re new to ICCP itself, start with the ICCP protocol guide and come back.
Table of Contents
From paper to table: the two-layer model
ICCP access control has a legal layer and a technical layer, and the standard is explicit about both.
The legal layer is the bilateral agreement: a document signed by two control centers listing the data and control elements each is willing to transmit to the other. Descriptions like “all state-estimated MW, Mvar, and kV for substations X, Y, and Z.” The list of what Center A grants Center B is distinct from what B grants A. Nothing flows over an ICCP link that isn’t in this document — organizationally, at least.
The technical layer is the bilateral table: the computer representation of that agreement inside the TASE.2 server. The standard defines the table’s required content but deliberately leaves its format open — the representation used is a local matter. One vendor stores it as configuration files, another as database rows, another as an XML export. What matters is that the information exists and the server enforces it.
Three rules in the standard set the frame:
A bilateral table is required if a control center serves any data to any other control center. A server maintains one bilateral table per remote control center. And every data object in the table needs a unique identifier.
That second rule is worth pausing on. If you serve five partners, you hold five bilateral tables, each scoping one relationship. Partner A’s table says nothing about partner B, and neither partner can see the other exists.
What the table contains
The standard defines the bilateral table object model with ten attributes, and each earns its place:
| Attribute | What it does |
|---|---|
| Client Control Centre Designation | Key attribute. Identifies the one remote client this table governs. Maps to an AP-title. |
| Version | Unique version identifier. Any change to the table means a new value. Exposed on the wire as Bilateral_Table_ID. |
| TASE.2 Version | The protocol version the table was built against. Exposed as TASE.2_Version. |
| Domain Name | The TASE.2 domain that scopes this client’s objects on the server. |
| List of Application References | The AE-titles permitted to establish associations, including security credential information. All must belong to the designated client. |
| List of Association Objects | The associations defined for this remote center. |
| List of Data Value Objects + access control | Which points the client may access, and how. |
| List of Data Set Objects + access control | Same, for data sets. |
| List of Transfer Set Objects + access control | Same, for transfer sets. |
| List of Device Objects + access control | Same, for controllable devices — plus the CheckBackID value returned on Select. |
The access control part of those last four lists follows one model: an Access Control Specification keyed by the TASE.2 client name, holding a List of Permitted Access for every object in the server’s VCC. It answers two questions per object: is it visible to this client at all, and which operations may this client perform on it. There is at most one Access Control Specification per client — no stacking, no ambiguity.
One detail engineers often miss: none of this access control machinery is visible on the wire. The standard says outright that the List of Access Control Specification is not mapped to any MMS named variable or type. Its implementation is local. What the client sees is only the outcome: an operation succeeds, or it’s rejected.
The checks, in the order the server runs them
The standard defines a strict sequence. Knowing it turns troubleshooting from guessing into reading.
Check 1 — does an agreement exist? When an association request arrives, the server takes the Client Control Centre Designation from the request and looks for a matching bilateral table. No table, no agreement — the server shall refuse the association. This is the check that fails when someone fat-fingers the AP-title in the client configuration.
Check 2 — is this application reference authorized? The client passed check 1 as an organization. Now the server checks that the specific AE-title in the request is on the List of Application References in that client’s table. Not on the list, refused. This is how a utility distinguishes its partner’s production ICCP server from a test box someone spun up with the same center designation.
Check 3 — the general validity check, forever after. Once the association is up, every operation the client issues is validated: every identifier referenced must be valid and covered under the bilateral agreement. Read a point that isn’t yours, the request is rejected. This applies to all TASE.2 object types, on every request, for the life of the association.
Check 4 — per-object parameter checks. Some object types carry extra conditions beyond visibility:
For Data Value objects, the table holds the method for retrieving the real value behind the identifier, plus parameters defining the maximum exchange rate and security of the object. The server checks that operation parameters — time intervals, for instance — respect the agreed performance limits. A client asking for one-second updates on a point agreed at ten seconds gets refused, by design. This is the mechanism that stops one aggressive partner from loading down your server.
For Device objects, the table holds the mapping to the actual device, the CheckBackID value returned in response to Select, and the Timeout value. The server verifies device operations complete within that timeout. The CheckBackID is a quiet security feature: an arbitrary value fixed in the agreement, echoed to the client on Select so the client can confirm it armed the device it intended.
Data sets, information messages, and transfer sets have no additional access control requirements beyond the general validity check.
One honest caveat the standard itself makes: enforcement depth is partly optional. Implementers may choose to implement only a subset of the access control described without affecting interoperability. What is fixed is how violations are signaled when checking is done. So don’t assume every peer validates everything — and don’t build your security posture on the assumption that theirs does.
How the table shows up in MMS
The table is local, but three pieces surface on the wire, and they’re the pieces you’ll actually use during commissioning.
Each bilateral table is associated with one MMS domain whose name identifies the client. Domain-scope (ICC) objects for that partner live inside it; VCC-scope objects sit at the server level, visible to all authorized partners.
The Version attribute maps to a domain-specific MMS named variable called Bilateral_Table_ID, a Visible-String-32. This is the handshake that matters most in practice: both sides read it and compare against the version they think is deployed. The standard requires a new unique value whenever anything in the table changes, so a match is meaningful.
The TASE.2 Version maps to the VMD-specific variable TASE.2_Version, a structure of major and minor version numbers.
First thing to do on a fresh association, before looking at any data: read Bilateral_Table_ID. If the two ends disagree on table versions, nothing else you observe means anything yet.
The exchange problem, and the CIM answer
Here’s the structural weakness of the whole scheme: TASE.2 defines no protocol for exchanging bilateral tables. Each side builds its own table from the shared paper agreement, independently, in its own vendor’s format. Two engineering teams, two tools, one spreadsheet emailed back and forth — and every typo becomes a mismatched point name discovered during testing.
Edition 3.0 (2014) finally addressed this with an out-of-band information model for exchanging bilateral table configuration, built on CIM.
The design is straightforward. The model integrates with IEC 61970-452 (the CIM static network model profiles), and the exchange format is CIM XML per IEC 61970-552 — the same machinery utilities already use to exchange network models. The profile has its own namespace, http://iec.ch/TC57/2013/profile-ICCPBLT01#.
The driving use case is exactly the tie-line scenario every transmission engineer knows. Utilities A and B model overlapping networks with an X-node boundary. Setting up the data exchange becomes a two-step process: first exchange TASE.2 data value definitions as CIM XML files — including negotiating which measurements each side exposes — then configure the data sets and transfer sets for the live exchange. The point definitions arrive as data, not as a PDF someone retypes.
The classes that do the work
The profile reuses six IEC 61970-452 classes — IdentifiedObject, MeasurementValue, Control, Command, DiscreteCommand, and Setpoint — and adds ICCP-specific ones. The interesting members:
TASE2BilateralTable describes the providing side of the exchange. Its attributes are compact and telling: bilateralTableID (the version being exchanged), calling (a boolean saying whether this provider initiates the TASE.2 connection — settling in data the “who connects to whom” question that’s otherwise agreed verbally), nameOfICC (the domain name the remote uses for ICC-scoped access), and TASE2Version.
ICCPPoint is the abstract generalization of a data value, carrying its scope (ICC or VCC) and its link to one or more bilateral tables. Concrete subtypes mirror the 6-802 object models: ICCPIndicationPoint for monitoring points, with booleans (qualityIncluded, extendedType, supplementalType) that pin down the exact TASE.2 data value type; ICCPCommandPoint and ICCPSetPoint for controls.
Two linkages make the model genuinely useful rather than just descriptive. Each control point carries an association to the ICCPIndicationPoint expected to change when the control operates — machine-readable command feedback mapping. And indication points optionally link to CIM MeasurementValue objects, tying an ICCP point to the exact measurement in the exchanged network model. Optional is the key word: the standard allows the exchange to carry plain bilateral table information with no CIM model attached, so you can adopt the format without adopting full model exchange.
Addressing classes complete the picture, and they encode facts you’d otherwise dig out of vendor manuals. TCP_AccessPoint carries the port — and the standard states here that ICCP and IEC 61850 use the well-known port 102 for non-secured connections and 3782 for TLS-secured communications, both registered with IANA. ISOUpperLayer holds the OSI selectors (TSEL, SSEL, PSEL) and the application addressing (AP title, AE qualifier) — the five values that must match on both ends before an association can even form. A bilateral table may reference multiple access points, which is how redundant server addresses are expressed.
Adoption of this exchange profile is still uneven — plenty of links are configured the old way. But if you’re specifying new ICCP infrastructure or an EMS replacement, ask vendors whether they can import and export ICCPBLT01 CIM XML. It turns partner onboarding from a transcription exercise into a file import.
Where bilateral table problems actually surface
A short field map, from the checks above to the symptoms you see.
Association refused immediately. Check 1 or 2 failing: the AP-title or AE-title the client presents isn’t what the server’s table expects. Compare the full application reference — AP title, AE qualifier, and the OSI selectors below them — character by character on both ends.
Association up, reads rejected. The general validity check. The point name the client asks for isn’t in the table, or is spelled differently. ICCP names are exact strings; SUBST_X_MW and SUBSTX_MW are different objects.
Some points work, one transfer set won’t start. Usually a parameter check: the requested interval violates the agreed exchange rate for one of the data values in the set, or the transfer set object itself isn’t granted.
Everything worked yesterday. Someone changed a table. Read Bilateral_Table_ID on both sides and compare against your records. The standard’s rule that any change forces a new version exists precisely so this comparison settles the argument.
Select succeeds but the CheckBackID looks wrong. The device mapping in the server’s table points at a different device than the agreement intended, or the agreed CheckBackID was updated on one side only. Stop and reconcile before operating anything.
FAQ
Is the bilateral table transmitted over ICCP? No. The standard defines no protocol for exchanging access control information — only for signaling violations. Each server maintains its table locally. The client can read the table’s version (Bilateral_Table_ID) over the link, but never its contents. Configuration exchange happens out of band, ideally as CIM XML per the ICCPBLT01 profile.
Do both control centers need a bilateral table? Each side needs one for every partner it serves data to. On a typical two-way link, both centers act as servers, so both maintain a table for the other. A center that only consumes and never serves would not need one — rare in practice.
Is a bilateral table authentication? No, and this trips people up. The table checks a claimed identity (AP-title, AE-title) against a list. It doesn’t prove the claim. Authentication comes from IEC 62351-4 and TLS, or from network-level controls. Think of the table as authorization: it decides what an identity may do, assuming the identity is genuine.
What happens when we update the bilateral agreement? Both sides update their tables to match, and each generates a new Bilateral_Table_ID. Coordinate the cutover: a client built against the old table talking to a server running the new one is exactly the mismatch the version variable exists to catch. Many utilities schedule table changes like protection setting changes — jointly, with rollback.
Where is the bilateral table format defined? It isn’t. IEC 60870-6-503 defines the required content and leaves the representation to the implementation. The closest thing to a standard format is the ICCPBLT01 CIM XML exchange profile, exchanged per IEC 61970-552.
What are ICC and VCC scope? VCC-scope objects are global on the server, visible to every authorized partner. ICC-scope objects live in one partner’s domain and exist only in that relationship. The bilateral table’s Domain Name attribute — nameOfICC in the CIM model — names that private scope.