Excellent question .. even vendors get this wrong!

The ICD

The vendor must be able to supply an IED Capability Description (ICD) file - it is required for the Conformance Testing according to Part 10 (Ed1 and Ed2) clause 5.4.2! i.e. no ICD, no conformance test!

ICD is the generic "ex factory" total capability of the device.

The device(s) as yet has no specific purpose in YOUR system, so one if the key identifying characteristics of ICD files is that it is the ONLY device file with a line (usually within the first 10-20 lines) containing:

Hence the file is named on your computer as something like:
"ACME Model 6519BNJ.icd"
with somewhere in the file, <.iedName = “TEMPLATE”>

That file therefore applies to every device of that type/model they supply.

The CID

Consider buying 10 boxes from this vendor.

You are going to use those 10 boxes in YOUR system with a role according to the Single Line Diagram and its function in the system. You therefore need 10 files individually and respectively with <.iedName = “Inc1”>, “Fdr1”, “Fdr2” .. “Fdr9”.

You “could” take the ICD and “copy & fiddle” to make 10 ‘nominal’ CID files by just changing the file extension from <<.ICD>> to <<.CID>, AND inside each file edit (perhaps with Notepad!!) call them individually and respectively .iedName = Inc1, Fdr1, Fdr2 .. Fdr9. These 10 files would be called CID files .. i.e. 10 individual files with extensions .cid

Inc1.cid with <.iedName = “Inc1”>
Fdr1.cid with <.iedName = “Fdr1”>
Fdr2.cid with <.iedName = “Fdr2”>
...
Fdr9.cid with <.iedName = “Fdr9”>

However, in a “full/proper” CID file, there are various pieces of system information that can only, well at least easily, be created in the System Specification Tool (e.g. single line diagram references) and the System Configuration Tool.

The real intent of Part 6 (where these files are defined and the engineering process) “top-down engineering” is to instantiate the ICD 10 times into the System Configuration Description (SCD) file, configure the communications and then EXPORT the 10 CID files.

Hence CID is supposed to be a SUBSET of the SCD!

CID is a “per physical box” file.

Each “full/proper” CID file not only has its own specific configuration for its allocated role in the substation (Inc1, Fdr1.. Fdr9), but also information about the other devices and their configuration to which it is communicating.

Hence “copy & fiddle” of a ICD file does not create a full CID file content, and of course you are left with a lot of human (error prone) fiddling. I call this “bottom to bottom engineering”.

So what is an IID

IID is similar to a CID in that it is also a “per physical box” file.

Inc1.iid with <.iedName = “Inc1”>
Fdr1.iid with <.iedName = “Fdr1”>
Fdr2.iid with <.iedName = “Fdr2”>
...
Fdr9.iid with <.iedName = “Fdr9”>

However, it makes NO SENSE that in buying “10 boxes”, the vendor supplies you one IID file that has IEDname = “Box1” or another name as that has NO RELEVANCE to the names and roles that each individual box is going to have in YOUR system! There are 10 boxes and as yet they have no assigned purpose in your system and they certainly can’t all be called “Box1”.

The IID is therefore in stark contrast to the ICD file "ACME Model 6519BNJ.icd" which has <.iedName = “TEMPLATE”>

So IID with a specific physical role on a per box basis is definitely NOT a replacement/alternative for a generic ICD file which has no allocated role in YOUR system.

What do you do with an IID?

The IID did not exist in Part 6 Ed1.

It was created after real experience of having created a SCD files where the base model configuration .. not the configured communications .. of an INSTANTIATED device had to be changed.

To explain ..

Consider ACME Model 6519BNJ.icd

It says it can have four PTOC Logical Nodes.

However, when you instantiated that for Fdr2 into your SCD, you only needed to implement two PTOC and create various GOOSE and MMS to/from them.

So if you exported the Fdr2.cid file, there is only PTOC1 and PTOC2.

Sometime later you realise you need three PTOC.

If you reimported the original ICD (with potential four PTOC capability) into the SCD, all that communication configuration you've created in the SCD would be lost.

Enter IID !!

The purpose of the IID is to allow fundamental change to the IED data model, but when you import an IID into the SCD, it is NOT ALLOWED to change any existing communications.

But note ... the IID is NOT the same as the full ICD in three respects

The vendor has no idea what you want to call the device, or what role it serves in your system so they can only supply ICD.
You may have certain parts of the data model not used in the instantiated Fdr2 device, i.e. there may be certain "things" not present compared to the original ICD
This file has a specific ROLE in your system as “iedName=”Fdr2” because you don’t want all 10 instances of the device to be changed .. you just want Fdr2.iid to update the instance of Fdr2 device in the SCD

Bottom line: an IID is specific to a specific box in YOUR system and may be missing various "things" that are described by the complete "ex-factory" box's ICD total capability file.

Browser not supported