Да, конечно можно. По моему мнению это не изящное решение. При этом имеющее пару минусов: лишние элементы в *.icd и *.scd файлах.

Мне кажется оба вариант так себе и мы просто столкнулись с ещё одной недоработкой стандарта

исходя из вашей логики, коллеги, кажется, что не вводимые в работу ступени РЗА в терминалах должны отсутствовать в прошивке, свободных ДВВ тоже быть не должно - терминал должен быть произведён строго под определенный набор используемых в проекте функций и интерфейсов.

В идеале да. Загружаем *.cid файл с нужной конфигурацией и профит

ага. и лишние кристаллы на процессоре отслоились...

Но на практике конечно далеко не так. Поэтому можно разделить ЛУ на выполняющие основные функции устройства, это РЗА и сервисные. Неиспользуемые функции РЗА не исключать, т.к. они основные и их не много. А сервисные, вроде lgos которых может быть 100 и 200 а используется только 5 редуцировать

Вы модель МЭК 61850 уже совсем от функционала оторвали такими рассуждениями

Почему вы так решили?

Чем функции ИЭУ, определенные производителем устройств, отличаются от коммуникационных возможностей ИЭУ, определенных производителем, с точки зрения наличия в модели данных ИЭУ - и там и там производитель заявляет количественные и качественные возможности, модель и описывает их. Функций РЗА немного, если Вы в контексте 6-35 кВ говорите, есть классы напряжения повыше, и функционал там возрастает в разы, а смежных подписок может быть меньше.

Разве количественные ограничения на подписку goose и sv определяются количеством lgos,lsvs? Не для этого ли придуман элемент services в котором можно указать эти возможности иэу?

Мы про контроль состояния

Там тоже можно, да.
Но Icd- то про всё.

Коллеги, возник такой вопрос. Хотелось бы узнать ваше мнение. В обиходе используются термины "GOOSE-сообщение", "MMS-сообщение" и "SV-поток".
Если под "потоком" понимать постоянную с некоторой периодичностью передачу кадров в режиме реального времени, то почему нет "GOOSE-потока"?
Да и термин "SV-сообщение" как-то не в ходу, если привязываться к конкретному кадру.

Это результат чьего-то некорректного перевода или есть какая-то тонкая грань между этими определениями?

GOOSE не является потоком

они спорадические

вроде все логично в этих терминах

GOOSE-сообщения передаются с некоторой периодичностью. Период передачи изменяется при изменении какого-то дискретного параметра в составе сообщения.

периодичность с изменяемым периодом - это уже больше похоже на спорадику, имхо

Т.е. в данном случае идёт совмещение двух моделей передачи данных.