Я инженер АСУ ТП. Много лет искал Modbus Tester, о котором мечтал — удобный, бесплатный, работающий везде. Не находил. В итоге мы вместе с ИИ-ассистентом сделали его сами — за один день.
Что не устраивало в существующих
Настольные программы глючат и зависают в самый неподходящий момент.
Бесплатные версии режут функционал: то тегов мало, то экспорт только в Pro.
Только Windows — а у меня Linux, у коллеги macOS.
На чужом ноутбуке ничего не поставить — политика безопасности, и ты сидишь без тестера.
Нужные функции разбросаны по пяти разным утилитам.
Что получилось
Веб-тестер, который работает прямо в браузере. Chrome, Edge, Opera. Ничего не устанавливать. Windows, Linux, macOS — одинаково. И главное — не глючит и не зависает. Открыл, подключил USB-RS485, работаешь. Хоть час, хоть сутки. Настройки сохраняются, соединение не отваливается, ничего не надо перезапускать.
Что умеет
Чтение и запись — все функции Modbus: 01, 02, 03, 04, 05, 06, 15, 16. До 125 регистров одной командой. Перед отправкой видно HEX-кадр запроса.
Сканирование Slave ID — находит устройства в линии 1–247 за пару минут. Не надо перебирать вручную.
Brute-force адресов регистров — перебирает диапазон и показывает рабочие адреса. Спасение, когда нет документации.
График в реальном времени — до 100 000 точек на линию, несколько параметров одновременно, свои имена и цвета тегов, автошкала или ручная шкала.
Математика на графике — считает формулы прямо по регистрам: #0 - #1, avg(#0..#4), if(#3 > 100, 1, 0). Перепад давления, среднее по датчикам, пороговые сигналы — без Excel.
Визир с прилипанием — навёл мышь на график, видишь точные значения всех линий в этот момент времени.
Звуковая сигнализация — пищит при обрыве связи. Порог, повтор, тип сигнала — настраивается. Фон страницы меняет цвет: зелёный — связь есть, жёлтый — ошибки, красный — обрыв. Видно издалека.
Мониторинг с HEX-логом — каждый запрос и ответ в HEX, с метками TX/RX и временными штампами.
Экспорт в CSV — скачать или дозаписывать в тот же файл каждые 500 опросов. Данные не потеряются.
Статистика связи — счётчики отправленных, полученных, ошибок. Сразу видно качество линии.
Плюс мелочи: тёмная тема, сохранение тегов и цветов в браузере, автоопрос, калькулятор глубины записи, скрытие линий кликом по легенде.
Честно о минусах
Работает только в Chrome, Edge и Opera — Safari и Firefox пока не поддерживают Web Serial API. Только RTU и ASCII — Modbus TCP в планах.
Но все минусы временные. Плюсы — фундаментальные.
Как сделали
Я не программист. Писал задачу по-русски, ИИ генерировал код, я тестировал на реальном железе и говорил «не работает — вот ошибка». Через пару итераций — работало.
Утро — первое чтение регистра. День — таблица, запись, мониторинг, лог. Вечер — график, имена тегов, звук. Ночь — тесты на датчиках и ПЛК. Основа была готова за один день.
Booz Allen проверила две передовые модели на изолированном стенде, имитирующем предприятие. Без исходного кода и инженерной документации агенты достигли поставленных целей во всех восьми сценариях. В одном испытании от первоначального доступа до систем промышленного управления прошло чуть больше 16 минут; в другом за несколько минут удалось заставить двигаться роботизированную руку.
Это была лабораторная имитация, а не взлом действующего завода. Кроме того, оператор-человек подтверждал каждый эксплойт и действия с физическим эффектом.
Может ли оборудование сообщить о проблеме ещё до возникновения отказа?
Введение
Одновременно с этим энергетика переживает ещё одно изменение. Объём эксплуатационных данных растёт быстрее, чем когда-либо раньше. SCADA-системы, цифровые подстанции, системы мониторинга оборудования и средства телеметрии ежедневно формируют огромные массивы информации о работе энергосистемы.
Возникает закономерный вопрос: могут ли эти данные сами подсказывать приближающиеся проблемы ещё до того, как они станут заметны персоналу или специализированным системам диагностики?
Разберёмся.
Как традиционно диагностируют оборудование
На протяжении десятилетий диагностика энергетического оборудования строилась вокруг нескольких основных подходов.
Первый — периодические осмотры и регламентное техническое обслуживание.
Инженеры проверяют состояние оборудования по установленному графику, выполняют измерения, проводят испытания и оценивают степень износа.
Второй подход связан со специализированными системами мониторинга состояния оборудования.
Для трансформаторов это могут быть системы контроля растворённых газов в масле, для высоковольтного оборудования — контроль частичных разрядов, для вращающихся машин — системы вибродиагностики.
Третий подход — системы непрерывного мониторинга состояния оборудования (Condition Monitoring Systems, CMS).
Они позволяют получать информацию в режиме, близком к реальному времени, и отслеживать изменение параметров оборудования между плановыми осмотрами.
Все эти методы доказали свою эффективность и остаются важнейшей частью современной эксплуатации.
Однако у них есть и ограничения.
Дополнительные датчики требуют установки, обслуживания и затрат. Кроме того, невозможно контролировать каждый потенциальный параметр каждого объекта энергетической инфраструктуры.
Поэтому отрасль всё чаще задаётся вопросом: можно ли извлечь дополнительную информацию из тех данных, которые уже собираются в процессе эксплуатации?
Откуда берутся эксплуатационные данные
Современная энергосистема ежедневно генерирует огромный объём информации.
Одним из основных источников остаются SCADA-системы (системы диспетчерского управления и сбора данных).
Они собирают данные о:
- токах и напряжениях;
- нагрузке оборудования;
- переключениях коммутационных аппаратов;
- режимах работы сети;
- аварийных событиях;
- технологических параметрах оборудования.
Дополнительные данные поступают из:
- цифровых подстанций;
- автоматизированных систем управления технологическими процессами;
- систем мониторинга трансформаторов;
- ветровых электростанций;
- солнечных электростанций;
- интеллектуальных приборов учёта;
- архивов эксплуатации оборудования.
Важно отметить, что большая часть этих данных уже существует в архивах SCADA-систем, систем мониторинга и телеметрии независимо от наличия проектов по искусственному интеллекту.
Фактически энергетические компании накопили многолетние архивы информации о работе оборудования в различных режимах и условиях эксплуатации.
Именно это создаёт основу для новых методов анализа.
Что может обнаружить анализ данных
Когда говорят об использовании искусственного интеллекта в диагностике оборудования, часто возникает впечатление, будто речь идёт о системе, способной предсказывать будущее.
На практике задача выглядит значительно более приземлённо.
Методы анализа данных и машинного обучения анализируют большие объёмы исторических и текущих данных и пытаются обнаружить закономерности, которые сложно заметить человеку при ручном анализе.
По данным исследований Fraunhofer IEE, EPRI и многочисленных публикаций IEEE по диагностике энергетического оборудования, особый интерес представляют методы выявления аномалий и отклонений от нормального режима работы.
Принцип работы можно объяснить на простом примере.
Если трансформатор на протяжении нескольких лет работает в определённом диапазоне параметров, система постепенно формирует представление о его нормальном режиме.
Когда отдельные показатели начинают систематически отклоняться от привычного поведения, алгоритм может обратить на это внимание раньше, чем отклонение станет очевидным для персонала.
Подобный подход может использоваться для выявления:
- аномалий в работе оборудования;
- постепенной деградации отдельных узлов;
- необычных режимов работы;
- изменения характеристик оборудования;
- признаков приближающейся неисправности.
Важно понимать, что речь идёт не о гарантированном прогнозировании отказов.
Алгоритмы выявляют статистические закономерности и подозрительные изменения, а окончательные выводы по-прежнему остаются за инженерами.
Причинная цепочка новой диагностики
Логику работы таких систем можно представить в виде последовательной цепочки.
Эксплуатационные данные
↓
Накопление исторической информации
↓
Поиск повторяющихся закономерностей
↓
Выявление аномалий
↓
Раннее предупреждение персонала
↓
Проверка оборудования
↓
Снижение риска аварии или отказа
Как анализ данных помогает обнаруживать потенциальные проблемы
Главная идея заключается в том, что система пытается обнаружить проблему не в момент отказа оборудования, а значительно раньше.
По сути, энергетика постепенно движется от поиска уже произошедших неисправностей к поиску признаков их возможного возникновения.
Именно поэтому такие технологии всё чаще называют инструментами прогнозной или предиктивной диагностики.
Где такие технологии уже применяются
Одной из первых отраслей, активно внедряющих анализ эксплуатационных данных, стала ветроэнергетика.
Современные ветроустановки оснащены большим количеством датчиков и систем мониторинга. Это позволяет анализировать состояние редукторов, генераторов, систем управления и других узлов на основе накопленных данных эксплуатации.
Подобные подходы применяются и для силовых трансформаторов.
Исследовательские организации и производители оборудования изучают возможности раннего выявления отклонений на основе анализа эксплуатационных параметров, архивов работы и данных специализированных систем мониторинга.
Отдельное направление связано с подстанциями и сетевым оборудованием.
Здесь анализируются:
- параметры режимов работы;
- коммутационные операции;
- события релейной защиты;
- телеметрия оборудования;
- архивы аварийных ситуаций.
Также растёт интерес к использованию анализа данных на крупных объектах генерации, где даже небольшое повышение доступности оборудования может иметь заметный экономический эффект.
Ограничения и сложности
Несмотря на высокий интерес к технологиям анализа данных, существует ряд ограничений.
Первое — качество исходной информации.
Алгоритм не способен компенсировать отсутствие достоверных данных или ошибки измерений.
Второе — необходимость обучения моделей.
Для поиска закономерностей требуется большой объём исторических данных, а сами модели нуждаются в настройке и проверке.
Третье — риск ложных сигналов.
Система может обнаружить отклонение, которое в реальности не связано с развитием неисправности.
Если подобных предупреждений становится слишком много, доверие персонала к системе начинает снижаться.
Четвёртое ограничение связано с инженерной интерпретацией результатов.
Даже самая совершенная аналитическая система не обладает практическим опытом эксплуатации оборудования.
Поэтому окончательное решение о состоянии объекта и необходимых действиях остаётся за специалистами.
Именно поэтому большинство отраслевых организаций рассматривают искусственный интеллект не как замену инженеров, а как дополнительный инструмент поддержки принятия решений.
Не все признаки неисправности видны при обычном осмотре
Заключение
Это не означает отказ от датчиков, мониторинга состояния оборудования или инженерной экспертизы.
Скорее речь идёт о появлении ещё одного уровня диагностики, основанного на более эффективном использовании уже существующих данных.
Один из важных трендов современной энергетики заключается в постепенном переходе от обслуживания исключительно по графику и реагирования на отказы к более раннему выявлению проблем на основе анализа эксплуатационной информации.
Источники
1. Fraunhofer IEE — Research on AI-based Condition Monitoring and Grid Analytics
Если сегодня инженер открывает SCADA и видит насосную станцию “как на ладони”, легко забыть, что когда-то на месте трендов и алармов были телефонные звонки, обходы и толстые журналы показаний. Логика была простой и жесткой: чтобы понять, что происходит на объекте, надо быть рядом. А если объект далеко, погодные условия плохие, персонал ограничен, а авария развивается быстро, “быть рядом” превращается в дорогую роскошь.
SCADA родилась не из моды на цифровизацию, а из необходимости. Промышленность и инфраструктура десятилетиями искали способ видеть удаленный процесс, получать измерения в реальном времени и иметь возможность вмешаться, не отправляя человека на место. По сути, вся мировая история SCADA – это история борьбы с расстоянием, неопределенностью и ценой реакции.
До SCADA: телеметрия как первый шаг к “удаленному глазу”
Раннее “супервизорное управление” появлялось в отраслях, где объекты распределены географически: энергетика, нефтегазовые магистрали, водоснабжение, транспортные узлы. Сначала это были разрозненные решения: дистанционные переключения, релейные схемы, телефония, первые каналы передачи измерений. В источниках по эволюции SCADA отмечается, что к концу 1950-х появились первые системы, которые уже можно считать предтечами SCADA, построенные на доступной на тот момент телеметрии и телефонных линиях.
В 1960-е телеметрия оформляется как практика: измерения и состояния начинают собираться автоматически и передаваться в диспетчерские пункты, чтобы принимать решения быстрее и надежнее, чем при ручных обходах. Важно понимать, что здесь не было “красивых интерфейсов”. Было главное: данные приходят сами, а не вместе с человеком.
Первые поколения SCADA: централизованный мозг и закрытые экосистемы
Первые SCADA в привычном смысле росли на вычислительной технике своего времени. Это была эпоха центральных машин и дорогих, часто выделенных каналов связи. Архитектура выглядела монолитной: один центр обработки, к нему подключены удаленные терминалы, обмен данными идет по ограниченным протоколам, а железо и программное обеспечение часто поставлялись “одним пакетом”.
Такой подход был логичен. Он давал предсказуемость и управляемость. Но одновременно формировал зависимость от поставщика и тяжелую модернизацию: заменить кусок системы без эффекта домино было сложно. Именно поэтому старые диспетчерские комплексы нередко живут десятилетиями: они надежны, пока их не пытаются “аккуратно обновить”.
В научных обзорах эволюции SCADA подчеркивают, что переход от простых supervisory-систем к SCADA был связан с развитием телеметрии, каналов связи и элементной базы, а далее архитектуры начинали усложняться по мере появления более доступных и компактных электронных устройств.
RTU и распределение функций: когда “поле” стало умнее
Следующий крупный шаг в мире SCADA связан с ростом роли полевых устройств. Появляются и развиваются RTU (remote terminal unit), а также специализированные устройства автоматики и защиты в энергетике. Идея проста: не обязательно тащить всю интеллектуальность в центр. Часть функций может жить ближе к объекту, особенно если канал связи нестабилен или дорог.
Это изменение особенно ярко видно в энергетике и инфраструктурных сетях, где возникла потребность в межвендорной совместимости. Так появляются и закрепляются телемеханические стандарты. Например, IEC 60870-5-101 как “companion standard” для базовых задач телемеханики опубликован в 1995 году и прямо нацелен на совместимость оборудования в задачах мониторинга и управления распределенными процессами.
В Северной Америке похожую роль занял DNP3. На сайте DNP Users Group описано, что в ноябре 1993 года ответственность за спецификации и развитие DNP3 была передана в сообщество пользователей и вендоров, а позднее протокол был принят как IEEE Std 1815. Это важно не только как “историческая дата”, а как признак зрелости: отрасль хотела не уникальные решения под каждого оператора сети, а общий язык для удаленных объектов.
PC и Windows: момент, когда SCADA стала массовой и визуальной
Дальше рынок автоматизации подхватил то, что обычно подхватывает: массовые вычислительные платформы. Появление и удешевление ПК, распространение Windows и графических интерфейсов резко изменили HMI/SCADA. Диспетчерская перестала быть закрытым миром дорогих терминалов и превратилась в привычную картинку с мнемосхемами, трендами и журналами событий.
Этот этап часто вспоминают как “демократизацию” SCADA: визуализация стала доступнее, внедрение быстрее, интеграция с офисной инфраструктурой проще. Но вместе с этим пришли и новые риски: обновления, драйверы, совместимость, а позднее и киберугрозы. Впрочем, именно PC-эпоха сделала SCADA тем, чем большинство инженеров ее помнят: системой, где оператор видит процесс в реальном времени и быстро управляет им.
Modbus и “общие слова” между устройствами: почему простота победила
В параллельной линии истории происходило не менее важное: стандартизация общения между устройствами. Если ранние системы строились на закрытых протоколах и “родных” интерфейсах, то рост числа устройств и производителей создал реальную боль интеграции.
Modbus стал одним из символов этой простоты. Schneider Electric в своем справочном материале прямо пишет, что Modbus был опубликован Modicon в 1979 году для ПЛК. Почему он выжил десятилетиями? Потому что он открыт, понятен и “достаточно хорош” для огромного числа задач. В результате Modbus стал одним из типовых мостов между RTU/ПЛК и SCADA, особенно в распределенных инфраструктурах.
В историческом смысле это важный момент: индустрия начала ценить не только функциональность, но и предсказуемость интеграции. Если протокол понятен и широко поддерживается, стоимость владения системой падает, а модернизация становится реальнее.
OPC: как индустрия перестала утопать в драйверах
К 1990-м стало ясно, что “драйвер на каждое устройство” не масштабируется. Разные ПЛК, разные протоколы, разные поставщики – и каждая SCADA вынуждена решать одну и ту же задачу: переводить десятки языков в общую модель данных. Именно на этом фоне появляется OPC.
OPC Foundation объясняет это максимально прямо: когда стандарт впервые выпустили в 1996 году, его задача была абстрагировать PLC-специфичные протоколы и дать SCADA/HMI унифицированный интерфейс через “middle-man”. Это стало поворотной точкой: SCADA начала отделяться от конкретного железа и превращаться в более модульную систему. Интеграция стала меньше зависеть от того, кто именно производитель контроллера, а больше – от того, как устроена модель данных и инфраструктура обмена.
Дальше OPC эволюционировал, но исторический смысл именно в “первом прыжке”: индустрия признала, что совместимость – это ценность уровня архитектуры.
Web-SCADA и платформа данных: диспетчерская выходит за стены завода
Следующий виток связан с сетевой эпохой. Сначала SCADA стала клиент-серверной внутри предприятия, затем появились web-клиенты, а позже – подход, где SCADA рассматривается не только как “экран оператора”, а как платформа данных для многих потребителей: эксплуатации, энергетиков, качества, техслужбы, аналитиков.
На уровне примеров новой волны часто упоминают Ignition, который был выпущен в январе 2010 года и позиционировался как интегрированная платформа, опирающаяся на OPC UA и серверную архитектуру. Важно даже не название, а сдвиг мышления: SCADA перестает быть “толстым клиентом на операторской машине” и все больше становится центральным узлом, где данные собираются, нормализуются, архивируются и раздаются по ролям.
Кибербезопасность как исторический перелом: после 2010 “изолированная сеть” перестала быть аргументом
Если попросить инженеров назвать событие, после которого разговоры о безопасности стали серьезными, многие вспомнят Stuxnet. В описаниях Stuxnet подчеркивают, что червь был связан с атакой на промышленную инфраструктуру и может рассматриваться как платформа для атак на современные SCADA/PLC-системы. Даже если не уходить в детали, важен итог: промышленность увидела, что цифровая атака может иметь физические последствия, и что “у нас технологическая сеть” больше не гарантирует спокойствия.
Параллельно оформляется стандартизация безопасности для промышленных систем. В истории IEC 62443 указывается, что в 2002 году ISA создала комитет ISA99, который начал выпускать документы по кибербезопасности систем автоматизации, а затем произошло сближение с IEC и развитие серии стандартов. Этот этап тоже часть истории SCADA, потому что современная SCADA – это почти всегда сеть, удаленный доступ, интеграции и, следовательно, необходимость проектировать безопасность так же инженерно, как питание или резервирование.
Что менялось на самом деле: не “картинка”, а доверие к данным
Если смотреть на историю SCADA без романтики, она сводится к одной линии: росту доверия к данным при росте сложности среды.
Сначала задача была просто “получить показания удаленно”. Потом “управлять удаленно”. Потом “сделать так, чтобы это работало между разными устройствами и поставщиками”. Потом “дать доступ большему числу ролей и систем”. Потом “сделать это безопасно”. И на каждом шаге индустрия упиралась в одно и то же: данные имеют ценность только тогда, когда понятны их происхождение, качество, контекст и ответственность за изменения.
Поэтому современная SCADA все чаще воспринимается как слой, который соединяет физику процесса и управленческие решения. И чем больше на этот слой опираются производство, учет и аналитика, тем важнее становятся дисциплины, которые в ранних системах могли быть вторичными: управление событиями, журналирование, контроль изменений, киберустойчивость, воспроизводимость.
Итог
Мировая история SCADA – это не история “одной технологии”. Это история эволюции инженерного ответа на удаленность и сложность: от телеметрии и телефонных линий к стандартам телемеханики, от монолитных центров к распределенным RTU, от закрытых драйверов к OPC, от локальных диспетчерских к web-платформам и экосистемам данных, и от наивной “изоляции” к зрелой кибербезопасности.
И если вынести из этой истории один практический вывод, он будет скучным, но полезным: SCADA становится лучше не тогда, когда на экране красивее, а тогда, когда системе можно доверять под нагрузкой – технической, организационной и внешней.
Будем считать, что у вас всё установлено. По установкам ПО можно найти документацию и мануалы.
Настройки в ПЛК с CODESYS 3.5
Суть следующая - нам нужно сделать ПЛК с Modbus TCP Slave. В моем случае ПЛК200 использует оба порта Ethernet. 1 опрашивает модуль - является мастером. 2 порт работает в режиме Slave. Для того чтобы работал 2 порт в режиме LAN нужто зайти в его веб-настройки и отконфигурировать.
Дальше добавляем модуль Ethernet.
Нужно связаться с ПЛК и выбрать по какому порту ему отдавать.
Выбираем преднастроенный порт.
Добавляем устройство.
Выбираем TCP Slave.
Далее залезаем в его настройки, вводим количество регистром и ставим галочку на запись, если нужно read\write.
Во вкладке соотнесение входов выходов вносим переменную. Переходим на следующий этап.
Настройки в SCADA SimpLight 5
Далее работаем со SCADA. Будем считать, что она скачана, установлена и запущена Среда разработки.
Список различных драйверов. Выбираем напрямую Modbus Драйвер, заходим в настройки.
Настраиваем Узел. В моем случае IP 192.168.1.10.
Вносим тег. У ПЛК 200 в режиме TCP Slave адресация начинается с 0.
Перетаскиваем теги в Проект.
Прежде чем запускать сервак. Нужно для него создать профиль и нажать птичку, что именно этот сервер мы используем.
После этого сохраняем проект и запускаем сервер.
Ставим маленькие галочки - чего опрашивать, зеленую стрелочку Пуск. И наблюдаем ТРИ топора, и что вообще чё то включено.
Готовлю мега-тестирование. STM32F407 (ARM) vs CH32v307( RISC V) vs ESP32 в выполнении LD программ для АСУ ТП (скорость выполнения инструкций в разных режимах) на разработаной IDE. А так же сравню с ПЛК брендов - Rockwell и Siemens.
Многие встречали разные проекты под мкрокоетроллеры: мигание светодиодов, домашние сервера, умные дома и прочее.
Но как себя эти МК поведут если захотите стать предпринимателем, и на их (да и на любых других МК) базе создавать Промышленные контроллеры с топовой функциональностью? Замена кода отдельных задач в режиме реального времени без пепезагрузки ПЛК, и прочее, теперь с моей IDE все этр будет реально на обычных дешевых МК
Мы занимаемся разработкой Scada-системы и для отладки коммуникации с Modbus-устройствами написали небольшую утилиту: PultModbusTester
Утилита бесплатная и без ограничений. Очень простой и удобный интерфейс. Поддержка Modbus TCP, Modbus RTU и Modbus RTU-Over-TCP. Интерпретация значений в форматах INT16, INT32 и Float (с любым порядком байтов). Утилита имеет подробный и наглядный лог, с подсветкой ошибочных байтов - здорово помогает в решении проблем с Modbus-устройствами.
Будем рады, если утилита окажется полезной коллегам-автоматчикам, также будем благодарны за обратную связь по функционалу.
Решил написать свой первый настоящий пост на Пикабу. Даже не представлял, как получается написать такие объёмные тексты. Но тут товарищ прислал одну статейку про новых программистов и реальную автоматизацию на заводах))) И тут вспышка 📸, ничего не помню и выходит текст из памяти!) Добро пожаловать под кат!)
Приходит как-то молодой IT-специалист со свежим стеком из Docker’ов, микросервисов и К8s на завод. В цеху сверкают панели управления, гудят моторы, а он пытается подключиться к этому промышленному добру. И, внезапно (нет), оказывается, что привычный IT-стек здесь не работает — у заводчан свои протоколы, свои легенды и свои правила. Годами. Десятилетиями. Из уст в уста, от конунга к сыну и т. д. и т. п. Айтишник достаёт ноутбук, спрашивает, какая тут точка доступа, а в ответ — тишина. Только матёрый усатый автоматчик (спец по работе с автоматизированными системами на заводах) медленно поднимает глаза, откашливается и с лёгкой тоской в голосе говорит: — Тут, сынок, Modbus по RS-485. Без TLS. Без DHCP. И если что, мы это на Delphi писали, в 2004-м. И это ещё повезло, что на Delphi в 2004-м :) А могло быть написанно в другой стране (году этак в 1990-м) на паскале или фортране. Так и живут некоторые заводы, где вместо YAML — скрипты на паскале, вместо DevOps — старая добрая флешка с патчами, а вместо облачных масштабируемых серверов — шкаф с вентиляцией (в лучшем случае) и приклеенным на скотч листом: «Работает — не трожь!»
Шёл 2011 год. У меня на первом заводе, где тогда работал, была 3-зонная методическая печь по нагреву металла, автоматизирована какими-то ПЛК (я тогда ещё слова такого не знал), программа была написана на Pascal. Помню, приехал программист делать доработки. Мы, молодые КИПовцы, специально остались, задержались (нас мастер уговорил, мол, посмотрите, учитесь). Он строки переписывает, меняет какие-то цифры (теперь уже знаю, что это были коэффициенты ПИД), и оно оживает (горелки переходят в другой режим работы) и начинает работать по-другому. Скада, если её можно так назвать (им же нарисована в каком-то редакторе), меняет форму, изменяет значения. Но🫣 тут же ниже на этом шкафу стоит 3 переключателя на 3 положения с фиксацией (вроде бы кулачковых) и ещё 3 обычных 3-позиционных без фиксации. Первые изменяют источник задания на газовые заслонки (1 — ПЛК, 2 — ручное управление, 3 — ещё одно🙂). Программист заканчивает настройку, говорит: «У вас будет всё хорошо». Уходит. Нашему мастеру категорически не понравилось, как работает регулирование. И как только программист уходит, переводит эти кулачковые переклички в то самое 3е положение. И горелками начинает управлять что? Правильно! Старые добрые КСП3 с круговыми диаграммами, которые мы меняли каждые 24 часа))) Говорит, так будет лучше, и уходит, говоря: «Собирайтесь домой». Мы ещё задерживаемся минут на 10 в этом помещении. Всё это время с нами был «печник», который следит за режимом работы печи. Тот, что был на смене, тут же, как наш мастер вышел, переводит кулачковые переключатели в какое положение?) Правильно! В ручное!)😂 И говорит: «Так будет надёжнее!) 😁».
Вот тебе и стеки и TLS и DHCP и 485. А подача 220 на МЭО импульсами надёжнее для конечного пользователя)) ☝️ Но это ещё не всё. Печники, когда лень идти в помещение с этим щитом управления, просто подходят к МЭО и что? Тоже правильно! Просто крутят его с помощью маховика))) Вот тебе и автоматизация)))💡 МЭО было примерно как на фото) Ну и схематически печь)
