Про запутаться в ЛУ - надеюсь, что от ручной практики мы все-таки стремимся перейти и перейдём на инструменты конфигурирования)
Про память и прочие аппаратные ограничения - есть задокументированный функционал, который должен выполняться в полном заявленном объеме.
Про увеличение времени на обработку - тоже вопрос аппаратный, CID, который передаётся от ICT в IED по стандарту может обрезаться в файл до необходимой информации при передаче в IED.
Если производитель заявил, что принимает N GOOSE, то он наверняка в курсе, что есть ИЭУ на рынке, у которых ICD по 10+ MB весят и на уровне обмена ICT-IED это все решается

Ну и IID никто не отменял, просто не все реализовывают

Вот и пришли ко второму варианту

В предельном случае все файлы могут содержать весь набор ЛУ, что не должно ставить в ступор ни ПО, ни ИЭУ

Последняя часть: да, годно к реализации, но это есть костыль устраняющий следствия порочности подхода

А количество ЛУ? Тоже предельное?

Мы CID вообще видеть не должны и тем более вшивать их в SCD в обход ICT, но приходится

Количество ЛУ у нас в прямой зависимости от заявленного функционала ИЭУ. В случае использования IID для передачи в SCT, при использовании всего заявленного функционала ИЭУ разницы по составу ЛУ между ICD и IID не будет

Вы определитесь, о каком функционале мы ведём речь.

Тут у вас весь набор ЛУ

А тут заявленный функционал

Разговор начался о универсальности метод

Универсальность метода использования модели данных зависит от универсальности требований к ней, @anoshin описал 2 варианта, для типовых решений актуальный первый, поскольку состав задокументирован для массового использования, для нетиповых решений оптимальнее второй вариант, поскольку обычно идёт конкретизация требований под конкретные объекты

В 61850 вроде это краем упоминается. Возможно кто-то из Сименсов и т.п. это поддерживает.

Что вы подразумеваете под типовыми и нетиповыми решениями? Какой состав задокументирован и где?

Терминалы стоят Micom P132 от Schneider Electric

Есть Типовые решения Россети-ФСК, там описаны требования к содержанию модели данных для типовых шкафов в СТО, аттестацию проходят в том числе по этим требованиям, зачем там использовать IID? Исходно требованиями установлено, что должно быть.

Есть требования условного Заказчика на использование определенного функционала, у заказчика нет НТД, включающих какие-либо требования к моделям данных, нет аттестации по требованиям к модели данных, есть лишь требования по функционалу применяемых устройств, который чаще всего меньше исходного функционала ИЭУ, значит там часть функционала не будет использоваться и можно не использовать ЛУ незадействованного функционала, для таких случаев IID будет оптимален с точки зрения объемов файлов.

Так не думается ли вам, что второй метод универсальнее?

На случай, если неожиданно требования поменяются

@fonBarmaley, продолжая вчерашний разговор : ICD -  файл -  это же файл возможностей? Логично в нем описать все возможности,  максимальное количество Lgos, Lsvs. А вот после конфигурирования в ICT получается CID-файл, в нем можно отображать только используемые лу,  в том числе меньшее количество Lgos и Lsvs.