ICD Documents for programmable and modular IEDs

If you have a modular 61850 product that can be shipped with a variable number of I/O cards, this may have a number of consequences:

1. The number of LNs this product can support depends on the hardware configuration.
2. LNs use shared resources, so if the user adds an LN of one type, he may not be able to add an LN of another type.

Be aware: everything is limited!

These tradeoffs are complex. If you produced an ICD file with the maximum number of LNs of every type your IED supports, for the maximum hardware configuration, the resulting file would be ridiculously large and unwieldy.

How to solve this issue?

All IEDs with a fixed functionality have definitely an easy to build icd file.

IEDs that are programmable or that are modular with one or more I/O cards are different. When the IED comes from the factory, you do not know what the application will be – so you do not know the information model and therefore you cannot provide an icd file for an application running on an IED.

What you could do is to provide an icd file that specifies the communication capabilities (services) and the DataTypeTemplates with all LNTypes that can be instantiated in that IED.

Once it is decided which functions (and LNs) will be running on a particular IED (with one, two, … or five I/O cards), then the IED Configurator (as a manufacturer-specific tool) can create the “final” ICD file for a particular function.

The icd must have exactly one IED section. I would put the LN instances of LLN0 and LPHD in the IED section. The other (functional LNs) would be added be the IED Configurator later … when the number of I/O cards etc are known and selected.