Who is responsible for ICD versus CID? and what about IID?

In the definitions of IEC 61850-6 :

• ICD is produced by an IED Configuration Tool (ICT)
• CID is also produced by an IED Configuration tool (ICT)
• SCD is produced by a System Configuration Tool (SCT)

Who uses those tools is subject to your contractual relationships/project delivery and engineering process and phase of project.

ICD is a “TEMPLATE” – that means EITHER the vendor or the Systems Integrator could produce it using the ICT.
ICD files have the IEDname field which MUST read as:           IEDname= "TEMPLATE"

The vendor would produce a generic ICD file i.e.
The vendor of "x" type device must provide the generic "x.ICD" with    IEDname = "TEMPLATE".
You might then buy 1 or a as many "x" devices as you need but at this stage they remain generic with no specific purpose to fill - i.e. device box (serial number) #1 could be used anywhere on any panel, as could box #2  ...

The vendor of "y" type device must provide the generic "y.ICD" also with      IEDname = "TEMPLATE".

The Systems integrator may decide they want two "preconfigured" versions of the "y" device - one for incomer feeders and one for outgoer feeders (click Figure 1 below)... so the Systems integrator (or the vendor might be nice enough to do it for you) modifies the generic ICD and make two versions "inc.ICD" and "out.ICD", but  since they are still just a generic file that applies to multiple boxes with no prescribed allocation to a particular bay they would both still retain   IEDname = "TEMPLATE".

Then the System Integrator would then use the "x.ICD", "inc.ICD" and "out.ICD" to instantiate as many IEDs in their project as needed …

You can (and is the common case for most vendor’s ICT) take a single ICD and create as many as needed CID files as simple file copies – after all that is just:
renaming the file name from “x.ICD” to “transformer1.CID” and changing the field from IEDname="TEMPLATE” to IEDname="Transformer1_Differential”
and a second "copy" as
“transformer2.CID”with teh field IEDname="Transformer2_Differential”
For all the fanciness of the vendor’s tools, you can easily do that in Notepad or Word or Excel ….!!  ... but as there are many other things to be done, I would not recommend playing around in direct text editing of the XML files!

Then as the project engineering proceeds, the Systems Integrator instantiates 3 incomers and 5 outgoers for the project,

they will generate 3 instances of inc.ICD which will end up being called something like

• inc_1.CID with the field    IEDname ="Incomer1”
• inc_2.CID with the field    IEDname ="Incomer2”
• inc_3.CID with the field    IEDname ="Incomer3”

and use 5 instances of out.ICD as

• out_1.CID with the field     IEDname="Outgoer1”
• out_2.CID with the field     IEDname="Outgoer2”
• out_3.CID with the field     IEDname="Outgoer3”
• out_4.CID with the field     IEDname="Outgoer4”
• out_5.CID with the field     IEDname="Outgoer5”

       
        Figure 1 
        ICD files are not specific to any individual role/box allocation.  It is the base capability to be instantiated one or more times.  They may be preconfigured to reduce subsequent engineering
        CID files are specific to a particular instance of the IED.

However note that it is generally not possible to take all those eight CID files and somehow, magically, combine them to create one collective SCD file. 
As mentioned here:https://ideology.atlassian.net/wiki/x/ewBv , simply put: "a.CID" + "b.CID" + "c.CID" < "abc.SCD"
This is because there is some information in the SCD file which Is not necessarily reflected in the individual CID files, hence if the info doesn’t exist in any of the CID files it cannot be magically created by combining the CID files. 

Equally the other extreme is some info would end up being incorrectly and unnecessarily replicated multiple times in the SCD file. 

More importantly when using individual vendor "X" IED Configurator Tool to directly turn their "x.ICD" into multiple CID, there is a high risk that certain configurations may end up in conflict with other configurations created using the IED Configurator Tool provided by vendor "Y" IEDs.

However if you start by creating the project SCD and importing both vendor X’s respective ICDs and vendor Y’s respective ICDs to instantiate as many as needed ...., THEN engineering the whole system, all the individual CID files can easily be extracted form a SCD file.

The process of extracting CIDs from and SCD can normally be done by either the ICT or the SCT – the ICT simply needs to be able to import an SCD file and have the ability to find individual IED instances to export as a CID (or IID) file

But what is this IID file?

Suppose you have a completed SCD file "my.SCD" comprising instantiations of the three incomers and five outgoers as above.

However you now need to modify the basic datamodel of one IED on Outgoer3 - it needs re-enable a function which had effectively previously been removed in the creation of "out.ICD". 
Consequently the function does not exist in the IED section of "my.SCD".

Or you need to change the settings/parameters of a function such as PTOC.strVal ...

You "could" modify the original "out.ICD" to be "out-a.ICD", and once again starting with IEDName="TEMPLATE".
Then re-instantiate that "out-a.ICD" for Outgoer 3 and recreate all the communications with other IEDs ... all from scratch!

Or ... you could extract the "out_3.CID",
then use the ICT to modify the data model but WITHOUT loosing al the existing communication configuration. 
Now as an IID file "out_3.IID", it will retain its allocated IEDName field i.e. IEDname="Outgoer3” (because that is what "out_3.CID" has in it's file),
This "out_3.IID" can now be re-instantiated into the SCD and only the new communication needs to be established associated with the new data model.
The "my.SCD" file will now include the updated IED section for Outgoer 3.
New CID files can then be extracted. 

      
       Figure 2
       IID are derived from an existing instantiated IED section, i.e. they already have an allocated role in the automation system with communication aspects already configured

So clearly a vendor cannot supply an IID file as a generic file - the IID file MUST have a unique, specific IEDName field relative to its allocation to a particular feeder (unless you give the vendor the list of IEDNames to be set in each IED and then they give you eight individual IID files for the eight individual boxes).

Or to put it another way, if someone claims they have an IID file that still has IEDName="TEMPLATE" is NOT an IID file - it is an ICD file!