Журнал КОНТРРЕВОЛЮЦИОНЕРА (videoelektronic) wrote,
Журнал КОНТРРЕВОЛЮЦИОНЕРА
videoelektronic

Categories:

У нас в компании появился молодой специалист, пишущий статьи технического характера. Значит, растём!

Web и .NET технологии в промышленной автоматизации (ещё один вариант)

Eugene Sidorin
Автор:

С естественным развитием Web-технологий и интеграции технологии .NET, последние стало возможно применять в автоматизации и контроле процесса производства. Цель данной статьи - раскрыть новые возможности применения этих технологий программирования на примере совмещения промышленных сетей с сетями TCP/IP.

Изначально, промышленные сети и сети TCP/IP нельзя было совмещать непосредственно из-за их различающихся скоростей передачи и характеристик электрических сигналов. Вскоре появились сетевые варианты промышленных протоколов, которые могут интегрироваться в TCP/IP, такие как ModBUS TCP и последние версии CAN 2.x, но практика показывает, что производители специализированного промышленного оборудования не сильно спешат отказываться от простых и проверенных решений, скажем на RS-485 (с вариантами связи дуплекс и полудуплекс) или ProfiBUS, т.к. очевидно эти решения хорошо себя зарекомендовали, они просты и дешевы в реализации и в большинстве случаев нет запроса к переходу на более прогрессивные и скоростные интерфейсы. Имея на вооружении современные технологии программирования .NET и Web стало возможным качественно увеличить возможности промышленных сетей и автоматизации.

.Net представляет собой подборку динамических библиотек, разработанную Microsoft и поставляемой с операционной системой Windows. В этих библиотеках есть функции по управлению окнами системы, работы с криптографией, мультимедиа, работы с сетями, Web и т.д. Вместе все эти библиотеки образуют так называемый фреймворк (framework). Эти библиотеки признанны, чтобы уйти от применения в разработках функций WIN API. Изначально эта технология сильно критиковалась в виду того, что приложения, написанные с применением .NET имели плохую переносимость и отказывались запускаться на других Windows-машинах, где отсутствовала соответствующая версия .Net framework. Поддержка библиотек .Net framework была введена на языках C# и Visual Basic в пакете Microsoft Visual Studio.

На самом деле, получать доступ к промышленным сетям из локальных сетей и интернета (спойлер) можно было и раньше, но для этого приходилось устанавливать программное обеспечение сервера (обычно это сервер Apache) и писать отдельно CGI-скрипты на языках C, Perl и т.д. и хранить их в определенной директории. Т.е. при запросе из браузера CGI-программы, на сервере, посредством механизма шлюзования, создавался дочерний поток, который и представлял собой программу (например с расширением exe), управляющую устройствами промышленной сети. Все это выглядело сложно и громоздко, приходилось посылать запросы GET и POST и с обновлением веб-страницы ожидать результата от сервера. С интеграцией языка C#.Net в Web все это упростилось в разы: достаточно просто перенести, скажем кнопку на будущую Web-форму и в обработчике события вводить стандартный код на C#. Например, следующий код получает весь список реальных/виртуальных COM-портов на сервере для связи удаленными устройствами и помещает их в раскрывающийся список (который уже должен быть на веб-форме):

private void button1_Click(object sender, EventArgs e){

object[] avaliable_ports = SerialPort.GetPortNames();                                        this.comboBox1.Items.AddRange(avaliable_ports);

}

Отмечу, что надо не забыть добавить пространство имен

Using System.IO.Ports;

И таким образом можно удаленно получать доступ ко всем ресурсам операционной системы Windows-сервера, например к USB, базам данных и т.д. за исключением, конечно, ресурсов уровня ядра, к которым операционная система ни под каким предлогом не предоставляет доступа, кроме системных драйверов, во избежание краха системы или даже физического вывода из строя процессора (во времена MS-DOS так все и было).

Как уже говорилось, основная идея состоит в том, чтобы посредством Веб-интерфейса любого браузера (кроме текстовых конечно, как в Unix) можно было из сетей TCP/IP получать доступ к промышленных сетям (таким как RS-485/422/CAN и т.д.)  и удаленно управлять всеми устройствами этих сетей. При этом, со стороны компьютера клиента не требуется никаких специальных ресурсов операционной системы, кроме ресурсов оперативной памяти для успешного запуска веб-браузера. При этом все ресурсы и управление сетями переносятся на удаленный сервер, на котором и размещен веб-интерфейс (веб-страница с элементами управления). И конечно же управлять/мониторить устройства становится возможным и через интернет, что практически снимает ограничения по дальности связи от, например, АРМ оператора (автоматизированное рабочее место) до конечного устройства. Ниже, на рисунке показана слегка упрощенная инфраструктура, в которой данная технология выступает посредником:

В правой части рисунка показано некоторое количество машин, которые через любой веб-браузер обращаются к C# веб-странице (или точнее к .aspx странице) размещенной на сервере. Веб-сервер, в свою очередь, подключен к "свичу" с интерфейсными конвертерами, у которых заранее предустановлены свои IP-адреса. По этим конвертерам преобразованные с сервера запросы управляют/мониторят конечными устройствами, будь то роботы, ПЛК (PLC)-контроллеры в рамках SCADA-систем или устройства, разрабатываемые индивидуально.

Таким образом все необходимые ресурсы памяти, вычислений и объектов (в т.ч. и аппаратные узлы) находятся на сервере, а требования к целевым компьютерам сводятся до минимума (причем даже не важно, что за операционная система стоит на компьютере оператора), ограничения по дальности связи практически снимаются и как не смешно бы это звучало, но контролировать все процессы возможно даже с мобильного телефона.

К недостатку такого решения я бы отнес то, что такие системы программируются очень специально и требуют от разработчиков более глубокого понятия о процессах передачи информации, потому как если в TCP/IP доставка сообщения гарантирована на 100%, контрольная сумма подсчитывается автоматически, а конфликты коллизии пакетов так же разрешаются автоматически, то в промышленных сетях часто приходится продумывать дополнительные программные меры по корректной передаче данных. В SCADA системах работа в этих сетях абстрагирована до предела и разработчику ПО под них не приходится думать о таких проблемах. Кстати, в мире SCADA систем недавно появился новый протокол EtherCAT, как альтернатива стандартному Ethernet, но с другой раскадровкой пакетов и специально для промышленности. Хотя его разъем стилизован под 8-пиновый 8p8c, обычные Ethernet-устройства не смогут с ним работать, однако производители микроконтроллеров уже начали выпускать в своих линейках МК с такими периферийными модулями (точно делает Microchip и ATMEL). Вместе с тем, SCADA-системы сильно ограничены по своему функционалу в сравнении с C# и местами их применение не оправдано экономически...

Оригинал статьи здесь:

Tags: креативисты, наука, творчество
Subscribe

promo videoelektronic march 31, 00:19 29
Buy for 40 tokens
Итак, вчера я описал свой взгляд на медицинско-технические проблемы, вызывающие именно такой характер распространения коронавируса, какой мы все наблюдаем. Версия технократа по поводу т.н. "эпидемии COVID-19" Но это лишь один слой проблемы. Взгляд, так сказать, с одного ракурса.…
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments