VM
Там 61869, а не 61968
Тьфу. Ваша правда! Не разглядел сослепу.
Size: a a a
2019 October 27
EE
Шо, не опечатка? =)
VM
Я почему-то прочитал как 61968-9 :)
VM
Шо, не опечатка? =)
У Вас все верно. Я перепутал стандарт по измерительным трансформаторам со стандартом по обмену CIM/XML данными со счетчиками.
2019 October 28
IK
Иван, договорились. В части "поженить", к расшифровке предложенной Егором Гороховым, мне нечего добавить, полностью соответствуют моему пониманию
Добрый день!
Файл есть, в нем информация о взаимодействии устройств МТ и ЭКРА. Проблем, насколько мне известно, при его создании не возникло ни у кого.
Файл есть, в нем информация о взаимодействии устройств МТ и ЭКРА. Проблем, насколько мне известно, при его создании не возникло ни у кого.
IK
У меня возник вопрос, а как и какие могут возникнуть проблемы в создании scd файла, при условии, что взаимодействие устройств в реальности выполняется?
Просто не смог такого представить, может у кого есть идеи?
Просто не смог такого представить, может у кого есть идеи?
AG
У меня возник вопрос, а как и какие могут возникнуть проблемы в создании scd файла, при условии, что взаимодействие устройств в реальности выполняется?
Просто не смог такого представить, может у кого есть идеи?
Просто не смог такого представить, может у кого есть идеи?
именно «в создании файла» может возникнуть лишь одна проблема и весьма весомая - такая, что подписки описываются по разному у вендоров и не в соответствии со стандартом. тогда файл нельзя будет создать в одном системном конфигураторе. В таком случае «чехарда» с файлами может привести к тому, что файла, соответствующего фактическому обмену данными, у заказчика не останется.
AG
Заказчик может чувствовать себя полностью осведомленным о своем проекте только в том случае, если он возьмет файл SCD и в этом файле будут описаны все устройства проекта, а также связи между ниими (кто, кому, что и как передает). И этот файл должен соответствовать фактически реализованной системе.
IK
именно «в создании файла» может возникнуть лишь одна проблема и весьма весомая - такая, что подписки описываются по разному у вендоров и не в соответствии со стандартом. тогда файл нельзя будет создать в одном системном конфигураторе. В таком случае «чехарда» с файлами может привести к тому, что файла, соответствующего фактическому обмену данными, у заказчика не останется.
Ну, полагаю, что все реально поставляемые на объекты устройства прошли сертификацию в DNV GL, а значит подписки описаны в соответствии со стандартом, значит и проблем быть не может? Или не значит?
IK
Заказчик может чувствовать себя полностью осведомленным о своем проекте только в том случае, если он возьмет файл SCD и в этом файле будут описаны все устройства проекта, а также связи между ниими (кто, кому, что и как передает). И этот файл должен соответствовать фактически реализованной системе.
Тут ведь есть ещё проблема, у многих заказчиков попросту не инструмента для работы с scl
AG
Ну, полагаю, что все реально поставляемые на объекты устройства прошли сертификацию в DNV GL, а значит подписки описаны в соответствии со стандартом, значит и проблем быть не может? Или не значит?
Нет, не так
AG
Эта отдельная сертификация
AG
Посмотрите главу 10
AG
Вторую редакцию
IK
Посмотрю, спасибо за наводку
AG
Ну, полагаю, что все реально поставляемые на объекты устройства прошли сертификацию в DNV GL, а значит подписки описаны в соответствии со стандартом, значит и проблем быть не может? Или не значит?
Здесь вы говорите про сертификацию сервера (server conformance testing)
AG
А надо смотреть ICT conformance testing (сертификация конфигуратора МЭК 61850)
AG
Тут ведь есть ещё проблема, у многих заказчиков попросту не инструмента для работы с scl
О каком инструменте идёт речь?
IK
О каком инструменте идёт речь?
С помощью которого заказчик имел бы возможность просматривать и редактировать scl файлы
AG
Редактировать файлы он всегда может с помощью конфигуратора вендора если он работает в соответствии со стандартом (см выше про проверки конфигуратора).