ScadaPy Creator для python

    Ускорение процесса создания modbus.py


    Очередной раз хочется поделиться своим опытом и результатами экспериментов в области промышленной автоматизации.


    В настоящий момент мы немного поменяли концепцию построения системы опроса устройств с использованием языка python.

    Большинство модулей SCADA систем строится по принципу связки «исполняемый файл — файл настройки».

    Исполняемый файл — это как правило скомпилированный бинарный файл, который непосредственно занимается опросом подчиненных устройств по определенному протоколу, его еще могут называть «драйвером протокола».

    Параметры опроса (порт, адреса, скорость и т.д.) для драйвера записываются в файл настройки, который бывает разных типов. Это может быть таблица или таблицы в какой-либо СУБД, например, часто используется SQLite или Firebird, может также использоваться файл xml.
    Работая с различными устройствами, мы пришли к выводу, что было бы очень удобно иметь в наличие уже скомпилированный файл драйвера со всеми настройками (переменными) внутри, хорошо было бы еще иметь возможность корректировать драйвер уже на сервере при организации опроса устройств.

    Для подобной цели рассматривался вариант создания приложения, которое на основе конфигурационного файла xml будет создавать драйвер на python.

    Основное условие – программа, формирующая код драйвера, должна обязательно работать и в Windows и в Linux.

    Первоначально решили сделать приложение на PyQt, но откровенно говоря, для нас оказалось довольно сложно писать программу в такой связке, не имея в наличие полноценной визуальной IDE для построения интерфейса пользователя.

    Ранее приходилось часто делать программы на C Builder и Delfi, поэтому обратили свой взор в сторону Lazarus. Попробовали скомпилировать программы на разных ОС – результатом остались довольны.

    Решили попытаться написать приложение на Lazarus IDE 1.8.2., назвали его ScadaPy Creator.
    Все настройки конфигурации сохраняются в одном единственном файле xml.

    image

    После компиляции на выходе мы имеем драйвер modbus, драйвер счетчика Меркурий-230, сервер http Json и файл html в качестве клиента.

    Как это работает


    Запускаем драйвер modbus или Меркурий-230 для опроса устройств.

    Получив ответы согласно описанным переменным, драйвер передает данные по UDP протоколу на порт 64000. Запускаем Json HTTP сервер, который в свою очередь получает данные от драйвера и формирует пакет в формате json для http запросов.

    Запускаем в браузере html файл клиента и видим уже обработанные данные в трех форматах — json, текстовом и в виде SVG картинки.

    Далее можно редактировать и html и SVG под свои нужды.

    image

    Мне, откровенно говоря, достаточно представления данных в виде простой таблицы, а для кого-то лучше информация воспринимается в виде мнемосхемы.

    Подобный вариант использования python скриптов был неоднократно опробован на удаленных подстанциях, где установлены объектовые серверы на базе ОС Linux и доступ туда имелся только по SSH.

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

    Вот типичный вариант, что называется, из последнего.

    Задача:

    Имеется устройство, работающее по протоколу modbus — датчик температуры и влажности Lumel P18.

    image

    Нужно получать значения температуры и влажность каждые пять минут и отображать на экране монитора в любом виде.

    Устройство находится далеко, на расстоянии около 90 км от офиса.

    Для начала создаем проект.

    image

    У Р18 температура берется по двум адресам 7002 и 7003, 32 бит, число с плавающей запятой, а влажность берется по двум адресам 7004 и 7005, 32 бит, число с плавающей запятой.

    image

    Кроме температуры и влажности, имеется возможность отображать и более развернутую информацию на объекте: относительная и абсолютная влажность, точка росы и т.д.

    image

    После генерации, будут созданы два файла modbus.py и jserver.py.

    Отправляем эти файлы на сервер объекта, а на компьютере клиента запускаем jclient.html.

    image

    Можно конечно файл html переместить и на web сервер.

    Вот в принципе и все.

    Проект с примерами можно скачать здесь.

    P.S.

    Приветствуется любая критика, замечания и советы, но конструктивная и по существу.
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 15
    • –1
      дилетантство чистой воды. с изобретением велосипедов.
      «мы сделали поделку — но она работает плохо, почему так?»

      Чтобы не было травли, спрошу пруф утверждению
      Большинство модулей SCADA систем строится по принципу связки «исполняемый файл — файл настройки».

      В каких SCADA'х так сделано?
      • 0
        Очень хороший комментарий, особенно там где о велосипеде.
        Вы лично можете «травить», это нормально.
        Только почему вы сразу решили, что «поделка» работает плохо?
        Приведите пример системы где настройки нигде не хранятся.
        • 0
          Настройки хранятся в единой базе конфигурации. WinCC, Intouch, iFix, RSView, Kepserver.

          Вы сами описываете, что работает плохо — цикл 0,5с, загрузка ЦПУ 100%
          • 0
            Но вы же понимаете — суть не в названии.
            Пусть это будет единая база конфигурации, конфигурационный файл(ы) или таблица конфигурации, физически параметры структуры объекта где-то должны описываться и храниться.
            К тому же проблему с циклом решили, спасибо за подсказку Yak52.

      • 0
        100% ресурсов как правило отбирает простой цикл. Какой период опроса датчика у вас?
        • 0
          От 0.5 до 1 сек

          Здесь код

          Каждый профиль запускается в отдельном thread, в нем цикл установлен и задержка
          time.sleep(float(timeOut[i]))

          Меня еще смущает в конце кода вот это
          ########################### treads block
          modb_4 = threading.Thread(target=Proc_4,args=(1,))
          modb_4.daemon = True
          modb_4.start()
          while True:
          pass


          Может быть проблема в цикле while?
        • +2
          Проблема именно в нем. Создайте скрипт только с таким циклом и получите 100% загрузку процессора. Фактически этот цикл у вас необходим для того что бы создать подобие «демона» или «сервиса». Если вы основную обработку производите в отдельных порожденных потоках, то вам просто необходимо ожидать когда эти потоки завершатся. Посмотрите в сторону метода threading.Thread.join
          • 0
            Спасибо за совет, посмотрел в сторону join — все получилось.
            На виндовс отнимал 25% теперь берет только 0.3-0.4%.
          • +2
            Который раз уже вижу подобное. Программа работает, свои задачи вроде даже выполняет, но код написан как курица лапой (одни только названия компонентов типа Edit2 и Label4, и простыни кода на много экранов в обработчиках событий вида Menu4ItemClick, и самое интересное, что чаще всего этим страдают именно дельфисты), без каких-либо представлений и даже желания узнать о том, как устроен и работает используемый инструмент (один цикл «while True» чего стоит), и прочее, прочее, прочее…
            Вот честно, даже в самой низкопробной аутсорс-галере на код-ревью за такое больно бьют. И больше всего пугает то, что в инженерной и научной сферах подобное встречается очень часто, не смотря на то, что серьезность задач там часто гораздо выше, чем при банальном веб-формошлепстве.
            Не хочу никого задеть или обидеть, но в АСУТП есть народная мудрость: «не давайте электрикам лезть в автоматику». Хочется добавить еще одну, «не давайте инженерам лезть в разработку ПО» :)
            • 0
              А в папке windows почему-то лежат bash-скрипты, да еще и с абсолютными путями. Мда :)
              • 0
                А что в bash-скриптах кроме путей «виндовс» неверно, в linux будут другие пути?
                И чем вам Edit2 и Label4 не понравились?
                По моему вполне информативно, ну можно конечно поменять имена.
                А что касается разработчиков ПО, то за каждый чих им надо платить,
                конечно вы можете сказать, что это их труд и его надо оплачивать.
                Но когда оооочень известная организация начинает внедрять свой софт и он абсолютно не работоспособен по той лишь причине, что на машине АРМ не достаточно оперативной памяти в 4 Гб или это просто новая альфа версия, то приходиться искать свои пути решения поставленной задачи.
                Это, что называется из последнего.
                И приходится «инженерам» лезть в разработку, так как у нас сроки, графики и сметы, а разработчики сидят в кабинетах, у них тарификация другая.
                Неубедительно.
                А скрипты на питоне у меня вот уже с пол года работают и свою задачу выполняют.
                Как то так.
                • 0
                  А что в bash-скриптах кроме путей «виндовс» неверно, в linux будут другие пути?

                  Как минимум, сами по себе абсолютные пути вида F:\dir1\dir2\…
                  На машине без раздела F:, да и вообще, где сами файлы лежат хоть по какому-то другому пути, оно, ясное дело, работать не будет. Более что непонятно, так это зачем тут вообще bash, учитывая, что в Windows из коробки его нет, и надо доустанавливать специально его из Cygwin или MSYS, или использовать WSL из Windows 10 (но в таком случае все равно работать не будет, т.к. там bash чисто linux'овый и пути эти он не поймет).
                  И чем вам Edit2 и Label4 не понравились?
                  По моему вполне информативно,

                  Простите, это вы серьезно сейчас, не шутите? Как минимум это заставляет постоянно держать в мозгу таблицу констант, какой номер какому параметру или действию соответсвует. Вам через несколько лет или вашим коллегам, заглянувшим в код, придется постоянно прыгать между редактором кода и визуальной формой, чтобы понять, что откуда растет. Вот честно, я уже лет 10 не встречал такого.
                  Идентификаторы типа edRtuAddress или lbConnectionStatus вместо автоинкрементных эту проблему полностью решают.
                  Это, что называется из последнего.
                  И приходится «инженерам» лезть в разработку, так как у нас сроки, графики и сметы, а разработчики сидят в кабинетах, у них тарификация другая.

                  Это-то я прекрасно пониманию. Сам с таким сталкивался, и такие проблемы решал.
                  Когда софт пишется «абы как» из-за того что просто нет времени и возможности сделать по-нормальному, производить рефакторинг, и т.д. — это проблема менеджмента, и разработчиков еще хоть как-то можно понять. Когда софт пишется «абы как» из-за того что в принципе в команде нет опытных и знающих людей, которые скажут как надо и как не надо, расскажут про важность соблюдения стандартов кодирования, грамотной архитектуры и оптимизации, это, в принципе, тоже проблема менеджмента, и разработчиков тоже еще хоть как-то можно понять. Гораздо хуже, когда работа так делается сознательно — вида, «мы систему спроектировали, железки произвели, а софт — это фигня, его любой дурак может написать». К чему это приводит в долгосрочной перспективе видел своими глазами, и не я один. Об этом я, собственно, в изначальном комментарии и говорил.
                  • 0
                    1. По bash скриптам я согласен, должен формироваться только при компиляции в Linux.
                    2. С названиями объектов и переменных, тоже соглашусь, для читаемости кода желательно сделать осознанные имена и добавит комментарии, хотя это не тот случай.
                    Но вот с остальным не соглашусь.
                    Вы вот говорите лет 10 не встречал чего там, а я встречаю постоянно, правда на протяжении уже 20 лет.
                    Заказчику, да и мне исполнителю абсолютно феолетово, что там написали «мудрые кодеры» и как читается код.
                    Нас интересует результат и сроки.
                    Когда выполнены все монтажные работы, проложена «физика» и ожидается, что вот приедут «программисты» из подрядной организации, которые «пишут» правильно и все будет запущено, но проект тупо не «стартует», вот здесь спасают ситуацию именно «инженеры-недопрограммисты» с их «говнокодом».
                    Это реальность.
                    От правильных «кодеров», обычно слышу типа «мы логи сняли будем анализировать»,
                    как это объяснить заказчику?
                    Заказчик здесь абсолютно прав, с его стороны мотивация простая, почему он за свои несколько десятков миллионов видит нулевой «выхлоп» и не получает обещанное.
                    Зря вы так реагируете.
                    За критику спасибо.
                    Значит в правильном направлении двигаемся :)
                    • +1
                      Тут проблема в том, что те же стандарты кодирования, паттерны и т.д. — это как нормы оформления конструкторской документации. Можно эскиз намалевать, и на производстве даже поймут, что надо сделать, а можно ЕСКД и ГОСТ оформить. И обычно все-таки требуется второй вариант :)
                      Всё это было придумано не какими-то занудами чтобы на мозги капать, а для двух вполне реальных вещей, причем не для заказчика, а для самих инженеров, которым с этим потом придется работать:
                      упростить понимание и «вникание» в написанное другими людьми (и даже автором спустя долгое время),
                      и уменьшить вероятность возникновения ошибок при разработке.

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

                      Поэтому и придумали стандарты кодирования, паттерны, SOLID, автотесты. И не стоит это игнорировать.
                      То же самое с глубинным пониманием инструментов. Разобравшись поверхностно, можно написать код, и он даже будет работать, но при совпадении каких-то условий на объекте будет падать или работать некорректно. В итоге затраты времени и денег на командировки, разбирательства на месте, подорванный авторитет у заказчика.
                      Поэтому рано или поздно приходит понимание, что лучше сразу писать хорошо, на совесть, и глубоко понимая, что именно мы делаем и как оно работает изнутри. Это экономит время и деньги в долгосрочной перспективе.

                      Возможно, я действительно излишне резко реагирую, извините, но для меня это на самом деле больная тема :) хотя бы потому, что сначала я тоже был инженером АСУТП и тоже часто писал самодельные «затычки», потом посмотрел на все это дело со стороны руководителя проекта и заказчика, а потом поменял специализацию, посмотрел, как все это делается в «большом IT», и хочется рвать себе волосы на голове с мыслями «блин, вернуться бы в то время со всем этим опытом»…
                      • 0
                        Судя по вашим комментариям, вы действительно хорошо разбираетесь в этой сфере и я с вами соглашаюсь полностью.
                        Но вот какая ситуация.
                        В последнем проекте мне пришлось выбирать подрядчика из представленных вариантов и основные критерии были как раз четкое следование стандартам в проектной документации, в ПО и т.д. Конечно репутация организации, отзывы, выполненные проекты играли тоже не последнюю роль.
                        Лично ездил, смотрел, знакомился. И ребята там работают все молодые, грамотные обещали, что будет релиз стабильно работающий, все как хочет заказчик.
                        Но в итоге привозят самую последнюю версию ПО, по их словам, выполненную в соответствии с последними требованиями ФСК, однако проект «не взлетает». По всей видимости это как раз такой случай как вы описываете.
                        Они тоже люди и тоже делают ошибки, а нам приходиться набираться терпения и ждать.
                        А, что касается, наших наработок по созданию скриптов, так мы не претендуем занять какую то нишу в области разработки scada систем.
                        Ни в коем случае!!!
                        Поэтому и относиться к этому надо не столь сурово.
                        А за замечания спасибо.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое