Почти у каждого инженера по автоматизации есть набор утилит, которые он таскает с собой с объекта на объект. Сканер сети, какой-нибудь Modbus-клиент, пара программ для работы с последовательными портами — и, конечно, папка с дистрибутивами, происхождение некоторых из которых уже никто не помнит.
Когда я работал инженером АСУ ТП в компаниях-интеграторах, мне регулярно приходилось заниматься пусконаладкой. Один из типовых сценариев выглядел так: подключиться к устройству по Modbus, проверить связь, прочитать несколько регистров, попробовать что-нибудь записать и понять, на какой стороне находится проблема.
Не тот адрес? Не тот Unit ID? Перепутан тип регистра? Ошибка в настройках последовательного порта? Или устройство вообще не отвечает?
Приложений для таких задач предостаточно. У каждого есть свои сильные стороны, но почти всегда обнаруживается какое-нибудь «но». Одни работают только под Windows. Другие выглядят так, будто их интерфейс проектировали одновременно с первой версией протокола Modbus. Некоторые давно не обновлялись, некоторые слишком наворочены для простой проверки связи, а некоторые стоят приличных денег.
Мне еще тогда хотелось иметь простой инструмент, в котором было бы собрано именно то, что нужно во время наладки: подключиться, прочитать, записать и посмотреть, что в действительности происходит в обмене.
Но самостоятельно писать такое приложение я не стал. Причины были две.
Во-первых, у меня не было достаточного опыта разработки подобных программ. Во-вторых — и это, пожалуй, даже важнее — мне было просто лень.
Идея, которая дождалась своего времени
Через несколько лет моя работа изменилась. Из инженера АСУ ТП я перешел в системные аналитики и продолжил заниматься близкой предметной областью: программным обеспечением для промышленной автоматизации, SCADA-системами, контроллерами и другими решениями.
К этому времени начали активно развиваться инструменты разработки с ИИ: Cursor, Codex, Claude Code и другие. Порог входа в создание собственного приложения заметно снизился. То, что раньше требовало от меня долгого изучения фреймворков, инфраструктуры и особенностей нескольких платформ, теперь можно было разбирать по частям вместе с ИИ.
Я решил, что пора вернуться к старой идее и наконец собрать Modbus-клиент, который мне самому хотелось бы иметь во время пусконаладки.
Так появился ProtoLink.
Сразу оговорюсь: ИИ не превратил задачу в кнопку «сделать приложение». Он может быстро написать код, предложить архитектуру или собрать интерфейс, но ничего не знает о конкретном инженерном сценарии, пока этот сценарий ему не объяснишь.
Например, красивый экран чтения регистров совершенно бесполезен, если в нем не учтены особенности адресации, типы данных, таймауты, порядок байтов или различия между Modbus TCP и RTU. Более того, ИИ способен весьма уверенно построить красивый интерфейс вокруг неправильных предположений.
Поэтому моя роль состояла не только в том, чтобы писать запросы к модели. Нужно было формулировать требования, разбирать сценарии работы, проверять результат и постоянно возвращать разработку к реальным задачам инженера.
Что я хотел получить
Основная идея ProtoLink довольно простая: приложение должно помогать быстро пройти путь от «где находится устройство?» до «какими данными оно обменивается и почему что-то не работает».
Без создания проекта на двадцать экранов, обязательной регистрации и промежуточных облачных сервисов.
В базовый набор вошли:
Modbus TCP и Modbus RTU;
чтение всех основных областей данных;
одиночная и множественная запись;
периодический опрос;
сетевой сканер;
просмотр фактических запросов и ответов;
понятная диагностика ошибок;
сборки для Windows, Linux и macOS.
В результате получился простой и легкий локальный клиент для проверки устройств и диагностики обмена.
Подключение по TCP и RTU
Для Modbus TCP задаются адрес устройства, TCP-порт и Unit ID. Для RTU можно выбрать доступный COM- или serial-порт, скорость, четность, количество стоповых и информационных битов.
RTU работает напрямую с последовательными портами компьютера. На Windows это привычные COM-порты, на Linux — устройства вроде /dev/ttyUSB0 и /dev/ttyACM0, на macOS — /dev/cu.*.
То есть сценарий остается обычным для пусконаладки: подключаем USB–RS-485, выбираем порт, задаем параметры линии и работаем с устройством.
Регистры, coils и функции Modbus
ProtoLink поддерживает основные функции чтения и записи:
FC01 и FC02 — чтение coils и discrete inputs;
FC03 и FC04 — чтение holding и input registers;
FC05 и FC06 — одиночная запись;
FC15 и FC16 — множественная запись.
Результаты чтения выводятся в таблице с адресами и представлением значений в HEX и DEC. Можно запустить автоматический опрос, чтобы наблюдать за изменениями данных, а для многобайтовых значений настроить порядок байтов и перестановку слов.
Адреса в ProtoLink задаются с нуля — в том виде, в котором они передаются в протоколе. Поэтому если в документации устройства указан регистр 40001, в приложении обычно следует начать с адреса 0 и функции FC03. Думаю, многие инженеры хотя бы раз потратили на эту особенность больше времени, чем хотели бы признать.
Сканер Modbus-TCP
Еще одна функция, которую мне хотелось иметь под рукой, — поиск Modbus TCP-устройств в локальной сети.
Сканеру можно передать один IPv4-адрес, подсеть в формате CIDR или диапазон адресов. Он проверяет указанные порт и Unit ID, показывает найденные узлы и отличает устройство с подтвержденным Modbus от хоста, у которого просто открыт TCP-порт.
Найденный адрес можно сразу перенести в форму Modbus TCP. Само подключение при этом не запускается автоматически: сначала можно проверить параметры и только потом отправлять запросы.
Сканирование ограничено локальными диапазонами IPv4. Это сознательное ограничение: инструмент предназначен для работы внутри своей сети, а не для исследования произвольных адресов в интернете.
Монитор обмена
Когда устройство не отвечает или отвечает не так, как ожидается, одного сообщения «ошибка чтения» обычно недостаточно. Хочется увидеть сам запрос, ответ, направление обмена, код функции и исключение Modbus.
Для этого в ProtoLink есть монитор обмена.
Он показывает фактические операции, которые инициирует приложение:
запросы и ответы Modbus TCP и RTU;
направление TX/RX;
адрес устройства и Unit ID;
код функции;
номер попытки и длительность;
полный ADU в HEX;
ошибки и коды исключений Modbus.
События можно фильтровать по протоколу, направлению, endpoint и коду функции, а журнал — экспортировать в JSONL для последующего анализа.
Это не пассивный анализатор всего трафика в сети и не замена Wireshark. Монитор отображает обмен, который выполняет сам ProtoLink. Для большинства задач проверки устройства этого достаточно, а интерфейс получается существенно проще.
Все работает локально
Внутри ProtoLink используется backend на Python, FastAPI и pymodbus, а интерфейс сделан на React. После запуска приложение поднимает локальный сервис и открывает веб-интерфейс в браузере по адресу 127.0.0.1:8000.
Несмотря на браузерный интерфейс, никакого облака здесь нет. Запросы к устройствам выполняются с компьютера пользователя, там же остаются настройки и диагностические данные.
Готовые пакеты уже содержат необходимые компоненты: отдельно устанавливать Python, Node.js или npm для обычного использования не требуется.
Сейчас доступны сборки для Windows x64, Linux x86_64 и macOS на Apple Silicon. Мне хотелось, чтобы одна и та же утилита могла работать и на рабочем ноутбуке с Windows, и на Linux-машине, и на Mac, без необходимости привыкать к трем разным приложениям.
Что в этой истории сделал ИИ
Для меня ProtoLink стал не только полезной утилитой, но и способом проверить, насколько далеко можно зайти в разработке приложения, если у тебя есть знание предметной области, опыт системного анализа и современные ИИ-инструменты.
ИИ хорошо помогает с типовыми частями проекта: структурой API, компонентами интерфейса, тестами, рефакторингом, сборочными сценариями и документацией. Он позволяет быстро сделать прототип, проверить гипотезу и несколько раз переделать решение без ощущения, что на каждый эксперимент будет потрачена неделя.
Но выбор того, что именно должно делать приложение, остается за человеком. Как должны задаваться адреса? Что показывать при таймауте? Какие параметры RTU действительно нужны на основном экране? Чем открытый порт отличается от подтвержденного Modbus-устройства? Какие данные понадобятся инженеру, когда обмен не работает?
Ответы на эти вопросы приходят не из языковой модели, а из практики.
Наверное, поэтому первым серьезным приложением у меня стал именно Modbus-клиент. Я не пытался найти идею для стартапа — просто вернулся к инструменту, которого мне самому когда-то не хватало.
Что дальше
На текущей версии ProtoLink я останавливаться не планирую. Идей много, и некоторые из них уже складываются в достаточно понятное направление дальнейшей разработки.
Один из следующих больших шагов — режим Modbus Server. Хочется, чтобы с помощью ProtoLink можно было не только подключаться к устройствам, но и имитировать их: принимать запросы от клиента, отвечать на чтение и запись и проверять работу SCADA-систем, контроллеров и другого программного обеспечения без реального устройства под рукой.
Дальше я смотрю в сторону инструментов для работы с IEC 60870-5-104 и IEC 60870-5-101. Эти протоколы регулярно встречаются в энергетике и промышленной автоматизации, а удобных утилит для них не очень много.
В перспективе ProtoLink может превратиться из Modbus-клиента в набор инструментов для инженеров АСУ ТП, наладчиков и разработчиков промышленного ПО. При этом хочется сохранить его первоначальную идею: быстро запустить, задать несколько параметров и сразу перейти к обмену, не продираясь через десятки экранов настроек.
Планы получаются довольно большими, поэтому особенно интересно понять, какие сценарии действительно востребованы. Что полезнее в первую очередь: Modbus Server, IEC 104, IEC 101 или какие-то другие инструменты? Обратная связь здесь вполне может повлиять на порядок дальнейшей разработки.
Где попробовать
ProtoLink продолжает развиваться, и сейчас мне особенно интересна обратная связь от людей, которые работают с реальными устройствами.
Скачать бесплатно приложение и посмотреть инструкции по установке можно на сайте protolink.tech. Там доступны версии для Windows, Linux и macOS.
Если попробуете ProtoLink, напишите, для какого оборудования и сценария вы его использовали, что оказалось удобным, а чего не хватило. Сообщения об ошибках тоже приветствуются — особенно если вместе с ними есть модель устройства, версия ОС и последовательность действий.
Связаться со мной можно по почте: info@protolink.tech.
Кстати, еще у меня есть Telegram-канал «Автоматизаторы». Там я время от времени делюсь историями из своей практики, интересными видео и новостями о промышленной автоматизации, АСУ ТП и роботах. Если вам близки эти темы — буду рад вашей подписке.
