Pull to refresh

Comments 19

Осталось неясным где тут некий "двойник"?
Вижу только модель и генератор тестовых сигналов и нет никаких признаков двойников.
Может термин "двойник" здесь все же неуместен?

Судя по всему, там есть какой-то генератор изменений нагрузки, режимов работы генераторов, коротких замыканий в сети и т.п., моделирующий «реальный» поток данных.

Для статьи была создана виртуальная физическая модель в ПО для физического моделирования объектов, эта модель была развернута на машине реального времени КПМ РИТМ. Машина реального времени, по сути, это промышленный компьютер, который обеспечивает работу нашей физической модели энергосистемы в жестком реальном времени, а также в реальном времени выдавать измерения с этой модели в виде SV-потока в данном случае. А сама модель энергосистемы может быть построена из различных элементов: электрические машины, трансформаторы, ЛЭП, нагрузки, источники возобновляемой энергии, силовая электроника и т.д.

Технический вопрос:

Данные внутри у вас организованы в соответствии с ГОСТами 58651.x?

Учитывая, что они ещё не все вышли, как планируете производить реорганизацию данных при выходе все новых ГОСТов этой серии?

Мы не использовали указанный вами ГОСТ для формирования данных

В статье приводится разбор деталей того, как работает одна из систем для релейной защиты. В реальном цифровом двойнике она будет являться одной из составляющих. Цифровой двойник полностью дублирует существующий электроэнергетический объект и даже получает от реальных систем (SCMS/АСКУЭ/SCADA) данные на вход для моделирования.

Здесь вопрос в том, что называть "цифровым двойником" на практике. Вот есть приложение+БД, которые каждую секунду получают параметры тока и напряжения из какого-то количества точек реальной подстанции или части сети, энергоузла и т.п.

Если измерениями охвачено только небольшая часть всех возможных точек, а остальное досчитывается/моделируется, это цифровой двойник. Но есть противоположный взгляд - это не двойник, поскольку он может сильно различаться с оригиналом.

Если же мы получаем практически полную картинку (для наших нужд), и ничего принципиально важного не досчитывем/не моделируем, то это скорее НЕ цифровой двойник, а просто автоматизированная система измерений, собирающая максимум данных для анализа. Но есть другое понимание - что это как раз цифровой двойник, поскольку максимально близок к оригиналу.

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

Поэтому грань между тем, что считать цифровым двойником в реальности, несколько расплывчата и субъективна. Например, вопрос "при каких характеристиках умный дом становится цифровым двойником реального дома?" весьма не прост и вызовет массу споров.

Согласны, все зависит от цели моделирования. В нашем случае ключевое значение имеют потоки информации, поступающие с измерителей в модели.  SV-потоки с машины реального времени дают нам полную картину того, что происходило бы на живой цифровой подстанции, поэтому мы здесь используем термин “двойник”.

По сути машина реального времени передает измерения с имитационной модели, учитывающей физику реальных процессов (в данном случае измерения с ЛЭП), которые могут быть доступны релейной защите и другим вторичным системам, принимающим SV-потоки (АСКУЭ, УСВИ,ПА и др.). При необходимости имитационная модель может быть достроена до решения, описанного вами. У нас есть инструмент, который позволяет уточнять параметры модели, отталкиваясь от текущих измерений с реального объекта.

На машину реального времени (это не генератор тестовых сигналов) мы загрузили верифицированную физическую модель электроэнергетической сети. Получился черный ящик с моделью, к которому можно подключить, например, токовую защиту, которая будет чувствовать и реагировать на поступающие из ящика SV-потоки с измерениями, будто она сейчас установлена на реальной подстанции. В свою очередь защита может выдавать управляющее воздействие, которое может принять машина реального времени и отключить, например, поврежденную ЛЭП, при этом произойдет изменений режима в сети, что отразится и в SV-потоке. Выходит, что комбинация верифицированная модель + жесткое реальное время + SV-потоки  и дает “двойник”. То есть получается имитация потоков данных с реального объекта.

Ну как же не генератор если генератор. Генерирует пакеты данных.
Данные же не берутся с реального объекта, а генерируются моделью, и начало генерации не реальным объектом вызывается, а оператором ПК.
Ну да, еще к генератору есть обратная связь, сильно нелинейная и цифровая, но это принципиально картину не меняет.
Т.е. нет двух главных признаков двойника: обратная связь по объекту подражания и синхронность с объектом подражания.
По прежнему думаю что применение к вашей системе слова двойник несколько поспешно.

Ваше понимание цифрового двойника предполагает наличие каналов связи с реальным объектом и корректировку модели под его текущий режим. Мы же предполагаем более простое определение для цифрового двойника в текущей реализации. Двойник это цифровая копия физического объекта, помогающая точнее воспроизводить всевозможные режимы его работы для улучшения качества разработки и производства вторичного оборудования цифровых подстанций. Важно заметить, что при наличии каналов связи мы вполне легко добавляем механизм уточнения модели по измерениям с реального объекта  по цепям host-target. Модель в процессе своей работы управляема (в нашем случае с ПК) по любым своим параметрам.

UFO just landed and posted this here

Checksum длиной 4 байта со значением контрольной суммы для проверки целостности данных при передаче. Кадр удаляется, если обнаружится ошибка.

Можно ли смоделировать процесс, чтобы при анализе дампа в wire shark, можно было видеть checksum, чтобы быть на 100% уверенным в корректности передачи?

Да, в целом это возможно.
Первый способ: настроить сетевую карту так, чтобы она не удаляла checksum. Ведь контрольная сумма кадра обрабатывается сетевой картой на аппаратном уровне до того, как кадр будет передан в Wireshark.
Второй способ проще: добавить в кадр отдельное поле для checksum, которая рассчитывается "вручную". То есть нужно добавить кусок кода в блок-отправитель, который рассчитывает checksum. Аналогично сделать в блоке-приемнике. Это дополнительное поле точно не будет отбрасывать сетевая карта.

Подскажите пожалуйста, каким образом возможно внести в кадр эту инфу по второму способу? То есть в cid файл дописать, что то...? Правильно я вашу идею понимаю

А может кто-то объяснить, либо ткнуть носом если уже все давно объяснено, как должна реагировать релейная защита, если пакет SV потерялся (не дошел то есть по той или иной причине, помеха прошла например, пакет дропнулся ибо чексумма не совпала)? Ведь выпадает отсчет синусоиды, что должны делать алгоритмы, восстанавливать его по следующему отсчету, который дойдет?

В традиционной релейной защите (РЗ) существуют функции контроля неисправности измерительных цепей. Например, БНН - функция блокировки при нарушениях во вторичных цепях измерительного трансформатора напряжения. Для РЗ, принимающей SV, реализуется дополнительная функция контроля качества SV потока. В её обязанности, в том числе, входит реакция на выпадание выборки в процессе приёма. Разные производители по разному реализуют такую функцию. Найти подробности можно в специальном файле от конкретного производителя цифровой РЗ: PIXIT (Protocol Implementation Cоnformance Extra Information For Testing) либо в руководстве по эксплуатации.

Из опыта, который смоделировали: при передаче sv потока и пропаже одного из пакетов на уровне коммутатора, при этом наблюдаем, что на работу рза, как в общем на качество синусоиды не влияет.

Sign up to leave a comment.