Как добиться максимальной скорости обмена SCADA с ПЛК? — АСУ ТП: сообщество инженеров

Как добиться максимальной скорости обмена SCADA с ПЛК?

О чём видео

Разбор влияния групповых запросов на скорость обмена SCADA с ПЛК. На примере двух проектов показано, как организация источников и каналов с групповыми запросами обеспечивает корректный опрос 650 регистров при цикле 10 мс, а отключение групповых запросов приводит к росту трафика и потере данных.

Что разбирается
  1. 00:05 Постановка задачи: два подхода к проекту
  2. 01:00 Ограничения протокола на групповые запросы
  3. 06:42 Настройка эмуляции устройств в приложении
  4. 08:02 Структура источников и каналов в проекте
  5. 12:10 Анализ трафика и времени транзакций
  6. 14:15 Проект без групповых запросов: результаты
  7. 17:09 Выводы и рекомендации по организации обмена
Оборудование и ПО
  • SCADA
  • ПЛК

Кому полезно: Инженерам АСУ ТП, занимающимся настройкой обмена SCADA с ПЛК

Описание составлено автоматически по расшифровке речи в ролике.

Расшифровка видео

0:05 Добрый день, почему у некоторых разработчиков 3 смот 7 летает, а на других тормозит, причем при прочих равных условиях давайте разбираться, предположим. Что проект делают 2 инженера принцип 1? Сначала думать, потом делать, а 2 лишь бы заработала. Инженеры делают быстрого сатапер жестким циклом. Пересчета 10 Миллисекунд, остальные условия таковы опрашивается 650 регистров разных типов период изменения контрольных параметров 1 секунда. Ну и параметры последовательного порта 115 200 м 8 1 оба работают. В идеальных условиях аппаратура расположена близко, количество запрашиваемых. Данных сравнительно небольшое протокол обмена данными стандартной проверенной, однако есть нюансик Кип и ПК настраивали смежники и об удобстве. Наших инженеров не думали, поэтому отдельная ПЛК запрограммированы в разнобой адреса переменных плК расположены не в смежных регистрах и. Хаотично в проекте есть непрограммируемые устройства, например, серийные регуляторы жесткой неизменяемой конфигурации регистров, но и часть тусов. Принципиально не поддерживает групповые запросы, знакомая ситуация. Пусть оба инженера используют самый популярный протокол Макбаз Рт Улетиссипи. Без разницы, но для наглядности используем рту так, как он менее производителем и негативные последствия бездумного подхода на нем проявятся. Быстрее напоминаем, что протокол Мадбас позволяет формировать групповые запросы как на чтение, так и на запись, причем максимальное количество. Считываемых 1 транзакции инто траджесторс или холдинг Реджистерс ограничен 125 штуками максимальное количество щита находной транзакции дискрет. Инкуэлс ограничено 2000 штук, максимальное количество записываемых 1 транзакции холдинг Реджистерс ограничено 120 5 штуками, но для койлс 1968. Единственное требование, считываемые или записываемые данные, должны располагаться исключительно в смежных регистрах, и так оба инженера берутся. За работу 2 действует в лоб, не задумываясь, создает источники и привязывает к имеющимся каналам, а вот 1 тратит усилия для организации источников. Данных и создает групповые запросы, результат выражается, метафоры выведены на экран. Ну или более тосы технически выглядит, будет так полка. Будем амулировать в приложении Максим 32 по протоколам от баср, то посмотрим результат деятельности нашего 1 инженера. Смотрите, 10 миллиардекунд!

2:54 Цикл выдерживается счетчики, они чуть позже, скажем, работают отлично, выведены 1 и последний койл, и 1, и последний интут статус. Это контрольный сигнал, период формирования на секунду великолепно. Да вот 1 вот последний, вот 1, ну и там последний.

3:16 А вот посмотрим трафик обмена. Обратите внимание, групповые запросы исключительно вернем картинку. Замечательно, а это результат работы нашего 2 деятеля без групповых запросов.

3:37 Не работают. Мелдра мы не видим. Вот 1 вот последний это Койл, и вот они отсутствуют. Ну, как говорится, результат налицо. Можно констатировать, что у 2 инженера проект не взлетел, почему? Теперь самое время выполнить разбор несостоявшегося полета, и тут внимание будем рассматривать все под микроскопом. Вообще скадутеры смолод 7 стремится. Максимально помогать даже ленивым разработчикам, в ней встроена поддержка создания групповых запросов. Так, например, по умолчанию при формировании базы. Граждан инструментальной системе сканируются настройки каналов, и если обращение к регистрам усо с адресами по возрастанию и без промежутков выполняется от. Граждан с уникальными идентификаторами, это атрибут Айди 118 также идущими по возрастанию и также без промежутков то автоматически будет сформирован. Групповой запрос и все каналы получат, это суд, данные из соответствующих регистров в 1 транзакцию, то есть максимально быстро, таким образом, при использовании. Механизмов создания источников по шаблону и создания каналов с помощью автопостроения, групповые запросы в необходимом количестве будут формироваться. Автоматически с учетом описанных выше ограничений по числу запрашиваемых или записываемых регистров с учетом их типа предусмотрен также и альтернативный. Вариант формирования групповых запросов с помощью канала класса Кол типа вызова Ченнел групп Реквест. В этом случае к такому каналу нужно выполнить привязку. Стартового регистра, описанного в источниках, а количество и тип данных аргументов определяют объем запрашиваемых, записываемых регистров в транзакции. Но тут уж сам разработчик должен учитывать имеющийся в протоколе ограничения. Жадничать нельзя, таким образом используя способ формирования групповых запросов. По умолчанию или создавая их вручную разработчик. Ну как, наш 1 инженер оптимальным образом строит обращение к Усо, но и тут стоит учитывать настройки. Последовательного порта, установленную скорость обмена величину тайм аута и скорость реакции усо на получаемые от монитора реального времени запрос, поскольку. Реального полка с нужным количеством и типами регистров и возможностью наблюдения за трафиком обмена. У нас под рукой не оказалось, мы воспользовались. Приложением Максим, 32 для которого были созданы 4 устройства, 01% и2, ты03. И 4 так устройство номер 1 содержит 200 регистров с текущими состояниями. Дискретных выходов Койл статус, причем 1 и последний в группе настроены на симуляцию Меандра с периодом формирования 1 секунда, а вот последний аналогично.

6:42 Далее устройство номер 2 содержит 200 регистров с текущим состоянием дискретных входов, и у них аналогичным образом настроены 1. И последний регистр. 1 Секунда. Устройство номер 3 содержит 125 входных регистров холдинг Реджистерс. У них настройки 1 и последнего регистра это пила с периодом формирования 1 секунда от 0 до 100 шаг единички. Аналогично, последний. Ну и наконец 4 устройство содержит 125 выходных регистров с аналогичными настройками, таким образом сформированное нами адресное. Пространство в приложении Максим 32 соответствует мощности Среднего полка, да и наше приложение Максим 32 подключено к последовательному. Порту ком 1 нашего компьютера с параметрами скорости 115 200 н 8 1 для начала обратимся к проекту нашего 1 персонажа именно в нем. Были созданы по альтернативному варианту групповые запросы на чтение всех регистров из всех 4 устройств, обратимся к слою источники.

8:02 Протоколы на террас, вот это вот группа для работы скоил статус. Да, содержит диагностический компонент для определения состояния обмена с устройством и описан 1 стартовый регистр аналогичным образом. Для Инпод статус для холдинг и для интуроражиста слой системы создан узел РПМ. С периодом пересчета 10 миллиардекунд, диагностические компоненты сведены в группу диагностика и сервис, а чтение из регистров было создано в группе Мацин 32 с подгруппами для чтения. Каждых компонентов для реализации чтения в каждой группе был создан канал Класс Сокол. Степан вызвал челленгруп Рексвест, у которого в привязке указан 1 стартовый компонент А.

9:01 На аргументах с определенным типом данных указаны входные значения созданных автопостроением каналов, которые так и называются кол статус 0 0 0 1 и так до. 199 Аналогичным образом для чтения Интут статус групповой запрос аналогичной структуры для холдинг регистров. И входных регистров выполнено аналогично в группе диагностикой сервис. Кроме этого, были созданы каналы класса кол по системным переменным 14. 0 6 И 14:13 Эти компоненты позволят контролировать обмен со всеми устройствами и период пересчета узла со всеми необходимыми подробностями. Группа ком порты содержит описание последовательного порта с указанными настройками. Заметим, что Максим 32 и Трэсмоут запускается на 1. Компьютере, чьи оба порта ком 1 и ком 2 соединены, ну и модемным кабелем. Для наблюдения за процессом были разработаны графические экраны.

10:14 Общий экран, который дает общее представление о происходящем. И отдельные для каждого устройства. Это экран Койл статус, всплывающий экран диагностики управления инпут статус холдинг. Ну и так далее упомянутые на экране счетчики имеется ввиду на экране 1 общем предназначены для визуального контроля за динамикой изменения формируемых меандров для Койл. Статус и им под статус с помощью программы Колонтер она очень простая, обычный счетчик. Работу нашего проекта 1 инженера мы с вами уже наблюдали. Ну давайте посмотрим еще разок.

11:06 Итак, счетчики работают замечательно. Считают положенные импульсы. Цикл практически выдерживается, ну потому что с этого экрана еще мы и выполняем создание фильма, который вы смотрите вот экран койлов. Отлично, смотрите, как формируется мямрик, вот это вот инпод статус. Вот это вот холдинг Регистра. Это вот диагностика и управление обменом, ну и наконец последний экран. Это энпутерофистас, обратите внимание, все идет четко. Общая картина такова замечательно. Ну а теперь желательно посмотреть и на трафик обмена. Для этого мы обратимся к нашему приложению, Максим, к 32 и откроем трафик.

12:10 Ну понятно, что перед глазами мельчится, но, по сути дела, мы наблюдаем с вами формирование 4 групповых запрос на чтение всех на чтение содержимого регистров всех 4 устройств. Ну а теперь немножко арифметики. Запрос данных по каждому из 4 устройств это 8 Байтов. Ответ от устройств 1 и 2 по 30 Байтов от устройств 3, 4 по 255 итого полный трафик обмена с устройствами 602 Байта. Причем время транзакции вопрос. Ответ без учета предусмотренных по протоколу задержек между посылками и с учетом настроенной скорости последовательного порта составляет порядка 40 45 миллиардекунд. Что с учетом заданной величины тайм? Аута 300 Миллисекунд будет корректно принята и записана в соответствующий канал. Ну, таков смысл асинхронного обмена данными. Ну а теперь остановим данный проект и загрузим проект предположительно 2 нашего. Инженера в проекте, ну как и следует из его названия групповых запросов и в помине нет. Это означает, что за содержимым каждого из 650 регистров монитор реального времени будет формировать индивидуальный. Запрос, конечно, такой в реальной жизни создать будет трудновато, хотя энтузиасты. Глядишь, отыщется для того, чтобы понять, как это намеренно было сделано. Обратимся к Слою источник протокола на террасу, Максим. Кол, статус 200 штук в рамках каждой группы создан либо 201. Ну, 200 регистров, + диагностический компонент или 126 125 описание регистров и 1 групповой компонент для холдингов и для импортов, но для того. Чтобы преднамеренно не создавать групповой запрос для каждого из источника, была создана вот такая, вернее, назначена такая галочка. Отключить групповой запрос по компонентам автопостроением созданы каналы.

14:15 Но, но обратите внимание, что структура полностью соответствует структуре ранее рассмотренного проекта. Вот, но, как мы понимаем, никаких. Групповых запросов здесь не будет, да более ничем наш проект 2 инженера от 1 не отличается. Давайте запустим счетчики, практически не работают.

14:41 Цикл выдерживается, мол, с оговорками на снятие видеосигнала. Какой он статус, что то происходит, но это не соответствует тому, что реально происходит в приложении Максим 32 период. 1 Секунду мы помним это пол клеточки. Вариантов все подключено, все работает далее. Вот им тут статус. Аналогично. Это вот холдинг регистры, которые должны пилить. Но что то происходит, но, как мы понимаем, опять таки несоответствие с реальным и входной регистр аналогично?

15:27 Давайте посмотрим на трафик обмена, как мы. Как мы видим групповых запросов, нет строго индивидуальная картина, жутко для разгадки происходящего. Нам вновь придется обратиться к арифметике и так у нас. По каждому регистру будет формироваться индивидуальный запрос, а это напоминаю 8 Байтов на регистр. Ответы также будут индивидуальными, от Койл статус и инпот. Статус по 6 Байтов от холдинг и интут регистров по 7 и того полный трафик вырастает аж до более чем 9000 Байтов. Во время транзакции вопрос ответ опять таки без. учета, предусмотренных по протоколу задержек между посылками, хотя в данном случае это уже становится влияющим фактором, а также с учетом настроенной скорости. Последовательного порта получается, ну никак не меньше 800. Миллисекунд, оценивая полученный результат, точнее его полное отсутствие, приходим к неутешительному выводу. В рамках заданных выше условий, использованный 2 инженером, подход никогда не позволит корректно считывать данные из регистров заданным периодом их изменения. 1 Секунда чтение состояния дискретных сигналов у 2 инженера абсолютно не соответствует их текущим состояниям. Про их суммарный подсчет вообще не говорим, а вот. Что касается как бы аналоговых сигналов холдинг Реджистерс и Инплтора Джестерс, то в проекте 2 инженера мы будем видеть лишь каждое 10 или 15 их изменение.

17:09 Но отметка времени изменения при этом точно не определена таким образом. Пренебрежение созданием явным или неявным способом групповых запросов вкуса. Ведет к совершенно фееричной картине полного кошмара. Итак, 1 инженер потратил время на организацию источников, использовал групповые запросы и получил. Получил великолепный результат, корректный опрос 650 источников при цикле опроса 10 Миллисекунд. И у вас это полетает, вот 2 поленился, и вас это вообще не дает корректных данных. Он видит это как эффект торможения, что неправильно, не будем же уподобляться. Неудачнику и при разработке проекта придерживаться следующих правил 1. Требуйте от смежников предоставить ПЛК с упорядоченной картой регистров. Если значение параметров записывается в регистр с произвольно заданными адресами, а тем более с промежутками. То на это необходимо смежникам указать и добиться исправления 2. И если вы работаете только с не программированными устройствами у со фиксированным полем адресов регистров, то используйте утилиты массового ввода карт сигналов, которые смогут 7 с. Авто построения, как это показано в нашем раннем ролике, 3 и если массовый ввод по каким то причинам не сделан и приходится действовать вручную, то приглядитесь внимательно. Карте регистров ПЛК или усо выстроены ли, запрашиваем регистра по ранжиру, нет. Ли между адресами промежутков, и если эти условия выполняются, то приступайте к пункту. 4 А если для каких то регистров условия выполнены не могут, то в источниках их необходимо описывать отдельно и в дальнейшем создавать каналы автопостроения 4 В. Инструментальной системе Скада Трисмоута в источниках выполните описание стартовых регистров, а затем с помощью каналов кол с типом, вызвав челнгруппы. Квест создайте необходимые групповые запросы с учетом имеющихся в манбас ограничений 5 по аргументам. Граждан Класс Сокол, типа, мызла Ченл групп Рексвест с помощью авто построения. Создайте каналы и выполните их тонкую настройку, если это, конечно, требуется. Ну, наконец, 6 используйте диагностические каналы для контроля обмена с ПЛК и системные, например, с 14. 0 6 И с 14:13 Для контроля за циклом пересчетов помните, что эти простые действия могут ускорить вашу АСУ ТП в сотни раз, а их отсутствие, соответственно, замедлить будем стремиться к хорошему. Вот на этом мы, ролик, наш завершаем вам спасибо за внимание.

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

Оставьте комментарий

Войти

Зарегистрироваться

Сбросить пароль

Пожалуйста, введите ваше имя пользователя или эл. адрес, вы получите письмо со ссылкой для сброса пароля.

Прокрутить вверх