Предотвращение потерь данных в распределенных АСУ ТП

0:02 Добрый день наш ролик повествует о применении механизма предотвращения потерь при обмене по сети в распределенных стП на базе Тройс Молота для иллюстрации. Разработаем небольшой проект, где 2 монитора реального времени Трэвис, Мод, ремонт и центр будут обмениваться данными по сети в условиях нестабильности соединения.

0:29 С помощью настроек в инструментальной системе релиза 6 10 и конфигурационных файлов определим механизм накопления данных в специальном буфере узла ремовок при разрыве соединения. И перекачки содержимого буфера в узел центр при восстановлении связи с записью спад архив. Оба МРВ будем запускать на 1 ПК с 2 физическими сетевыми адаптерами, а нестабильные соединения будем провоцировать отключением питания сетевого коммутатора Хаба. Для разработки данного проекта будем пользоваться профессиональной версией инструментальной системы. Треснул, а запуск обоих узлов будем выполнять с помощью профайлеров. С поддержкой графики данная технология также доступна и для инструментальной системы базовой линии. Само описание механизма представлено в нашей документации.

1:30 Расшифровка служебных сообщений по работе механизма описана здесь, у. Нас будет касаться последний раздел справочки. Как устроена работа данного механизма? Ну, это очень просто при запуске узла с условным названием Слэйв, чья данная буферизируется, проверяется, а запрашивает ли какой нибудь узел с условным названием Хост данные. По каналам, которые отмечены флагом регистратор, и если да, то данные реального времени отправляются узлу хост. А если нет, то включается процедура накопления указанных каналов, соответствующий буфер узла слейф.

2:20 При старте узла хост, которому необходимо получить данные по указанным каналам. Формируется запрос на получение данных из буфера, слоев данные с буфера, отправляются запросившему их узлу. Хост тот их принимает и записывает свой архив. Далее происходит штатный обмен данными реального времени. Если вдруг затем, по какой либо причине возникает обрыв связи, то происходит. Следующее 1 на обоих узлах детектируется сам факт разрыва соединений его в Риме. Тут, кстати, надо понимать, что из за асинхронности запуска узлов разбежки часов на узлах и настроек. Широковещательного обмена между узлами те, которые задаются в редакторе узла во вкладке дополнительно. Так вот, зафиксировано на обоих узлах момента времени, как правило, не совпадают.

3:14 2 Узел Слейф включает накопления в буфер, размер которого и время хранения задается в конфигурационном файле. Проходят какое то время, и связь между узлами восстанавливается. Хост формирует запрос Слэйв на данные с момента времени разрыва связи со своей стороны до момента времени. Ее восстановление опять таки по своим часам слейф. Естественно, передает запрашиваемые данные в хост, тот их получает и через какое то время записывает данные в свой архив чудно. Ну а теперь вопрос чисто теоретически. Возможно ли пропуски в полученным узлом хост данных ответ? Безусловно, да как с этим бороться известно как, но полная окончательная победа имеется ввиду. Практической достичь, конечно же, не удастся, вы понимаете? Ну что ж, займемся дело, мы уже загрузили инструментальную систему и создали проект стандартном стиле.

4:23 Слой системы создадим 2 узла РТМ. Соответственно, ремонт и центр. Открой музел ремонт на редактирование. В период пересчета определим в полсекунды айпи адрес. Зададим следующий, выберем на на прием и посылку 1 сетевой адаптер код проекта зададим равно 100. А теперь внимание секции регистратор. При старте укажем выключен. Остальные настройки пока оставим заданными по умолчанию. Далее перемещаемся слой, источники, приемники, создаем группу, генераторы в ней пилу, треугольник и синусоиду с помощью механизма. Дракантроп затащим группу, генераторы в узел, ремонт именно эти каналы и будут передаваться. В штатном режиме узел Центр внештатном накапливаться в буфере узла ремонт для последующей передачи. Для того чтобы все это происходило, необходимо для наших каналов секции архивации указать флаг регистратор.

5:53 При всем при этом никакого узла регистратора в нашем проекте нет и не предвидится. И наконец для Синусовиды то же самое. Теперь займемся узлом, центр откроем редактирование. Узел укажем те же самые полсекунды вперед пересчета, зададим ему. Ай пи адрес. И выберем работу. 2 Физическим сетевым адаптером также не забудем про код проекта, он должен совпадать с кодом проекта для узла ремонт. И так же, как мы и делали для узла лемоут секция регистратор при старте, укажем выключена.

6:55 Далее зайдем во вкладку архивы, зададим имя файла для нашего архива и состояние архива на старте. Укажем труп опять таки все остальные настройки. Нашего узла оставим заданными по умолчанию. Далее перемещаемся в узел ремонт и с помощью механизма дракантроп перетаскиваем группу генератора в центр.

7:23 Именно каналов переименовывать не будем, так их оставим канал 1 2 и 3 соответственно. Это будет пила треугольник и синусоида, но вместе с тем все наши каналы определим в 1 архив ранее нами настроены. Теперь создадим операторский интерфейс для узла центр. В корневой группе нашего узла создаем новый компонент, экран который открываем на редактирование в качестве начальных аргументов нашего. Экрас будет содержимое группы канала, который мы получаем по сети от нашего узла ремонт и так реальное значение канала 1 2 и 3 в.

8:07 В левый верхний угол поместим графический элемент, дата и время. Настроим его на отображение текущего времени. Под ним графический элемент, тренд. Назовем его реального времени. Отключим у него использование архива. Сдадим буфер 5000 точек, зайдем в ось времени и зададим диапазон, отображаемый на тренде по умолчанию 5 минут. Кроме этого, создадим 2 дополнительных аргумента, назовем их фром и ту. Сделаем их двунаправленными с типом данных юда Инд.

9:18 Левую границу нашего тренда привяжем к аргументу Фром правую к аргументу, ту привязку оставим холод под. Ну и наконец выделим 1 3 наших аргумента и закинем на тренд. Все настройки кривых оставим заданными по умолчанию. Под наш тренд, так нам будет удобнее наблюдать, поместим тройно торхивный. Назовем его соответствующим образом. Буфер того же размера. Ось времени те же самые 5 минут. А теперь внимание изменяем тип привязки на импорт и привязываем к левой границе Фромм правый ту, это для того, чтобы позиционируя. Тренд реального времени архивный тренд у нас был синхронизирован с этими движениями, выполненную работу, сохраняем на диск с именем.

10:33 Нью Баферс и. Сохраняем для монитора реального времени. После этого заходим в папочку нашего проекта, забираемся в папочку узла. Ремонт и создаем конфигурационный файл со стандартным именем и расширением ЦНФ, в нем будет написано следующее. Объем буфера под накопление данных, время хранения содержимого, сетевая отладка и вывод служебных сообщений по работе нашего замечательного. Механизма соответственно, да, кстати, значение и буфера, и времени хранения можно было не задавать, поскольку мы указали значение по умолчанию.

11:20 Соответственно, в папочке нашего узла центр мы тоже создали конфигурационный файл, в котором будет лишь запрос отладки взаимодействия по сети. И все тот же самый вывод служебных. Сообщений по работе нашего механизма 1 запустим узел, ремонт выполняем, запуск минимизируем его на экране. Через меню вид открываем панель МРВ на закладке протокол номер 2 закладываем.

11:50 Запускаем сам Профайлер, так появление вот этих вот надписей означает, что наш узел ему и нашел узел центр. Это его партнер по проекту и включил накопление данных. Ну и пусть накапливает, а мы тем временем подготовим запуск для узла центр.

12:20 Также нас будет интересовать закладка протокол номер 2. Ну что, включаем его в работу? Итак, возле друг друга в сети нашли. Да, видно, что за время отсутствия было накоплено 240 значений каналов наших генераторов и момент старта. Узел центр запросил всю информацию за время своего отсутствия у узла ремонта, получил в полном объеме. Сама информация появится в архиве чуть погодя, и мы ее непременно посмотрим, а пока ждем. Ну вот, у нас наконец сдвинулась полоса прокрутки, автоматически мы видим, что. Вот это вот данные, которые были получены узлом центра в момент старта. А вот если оглянуться вниз, то вот этот кусочек это то, что было прислано из буфера узла ремонт.

13:27 Самое время отключить питание у нашего сетевого коммутатора делаем. Прием данных прекратился, внимательно смотрим вот сюда. Итак, узел был потерян в сети и включился опять механизм накопления данных в буфер. Момент пропажи и здесь, и здесь близки, но на секунду отличаются. Это можно определить, как асинхронностью запуска узлов. Какое то время за тем, как происходит. Отсутствие обмена данными прошла минута после того, как было разорвано соединение, но вот уже больше 2 минут.

14:33 Уже дело движется к 3 минутам разрыва соединения. Давайте ка мы это дело теперь имеется, ввиду питание включим. Есть. Итак, через несколько секунд мы видим, что насажили наши сигналы на тренде. Это очень хорошо, а что с перекачкой буфера смотрим за время? Отсутствие связи было накоплено такое, то количество значений они были запрошены узлом центр и в полном объеме опять таки получено.

15:18 Осталось только выяснить, сколько из всего накопленного было записано в архив. Но это мы узнаем спустя какое то время, давайте попробуем. Вот получилось. Итак, мы выровняли границу 15 0 7 15 0 7 вот это. Вот отсутствие данных, отсутствие данных, а это вот те данные, которые были считаны из буфера и которые в реальном времени не были посланы из узла ремот в узел центр. Ну, на архивном тренде провал данных практически, за исключением вот этого, участочка был полностью заполнен.

16:00 Данный участок сравнительно небольшой, по сравнению с вот этим объясняется в меньшей мере не синхронностью запуска наших узлов, а В. Большей временем детектирования отсутствие узла в сети со стороны узла ремонт. Напоминаем, что по умолчанию это 20 секунд теперь, поскольку. Синхронность запуска, особенно нескольких узлов, выдержать достаточно трудно, то для уменьшения. Вот это вот времени, когда у нас данных нет. Необходимо корректировать параметры проверки удаленных узлов, которые находятся в закладке дополнительно каждого бланка редактора узла.

16:41 Также мы использовали параметры по умолчанию как для размера буфера, так и для глубины его заполнения. В случае, когда типовые параметры вас не устраивают, они могут быть откорректированы непосредственно в файлах ТМКом знак, подчеркивание ХХХ. Точка цены уверены, что показанный в нашем ролике механизм предотвращения потерь при обмене данными по сети найдет свое применение в распределенных асу ТП, создаваемых на базе 3 СМУ. На этом мы наш ролик завершаем вам спасибо за внимание.

Расшифровка сделана автоматически (Yandex SpeechKit) и может содержать ошибки в терминах.