Что такое операторский компьютерный интерфейс
Наверняка многие и вас знают или даже видели, каким образом управляются большие автоматизированные объекты, например, атомная станция или завод со множеством технологических линий: основное действо часто происходит в большой комнате, с кучей экранов, лампочек и пультов. Это комплекс управления обычно называется ГЩУ — главный щит управления для контроля за производственным объектом.
Наверняка вам было интересно, как всё это работает с точки зрения аппаратной и программной части, и какие там используются протоколы передачи данных. В этой статье мы разберемся, как различные данные попадают на ГЩУ, как подаются команды на оборудование, и что вообще нужно, чтобы управлять компрессорной станцией, установкой производства пропана, линией сборки автомобиля или даже канализационно-насосной установкой.
Коммуникационные возможности HMI-панелей
Современные HMI-панели обладают широкими коммуникационными возможностями. Сенсорные панели оператора ONI серии ETG оснащены последовательными интерфейсами RS-232/RS-485, Ethernet, портами USB-Host и USB-Slave. В некоторых панелях также есть слот для SD-карты (рис. 16).
Рис. 16. Коммуникационные возможности HMI-панелей
Интерфейс USB-Slave предназначен для загрузки проекта HMI, разработанного в ПО ONI Visual Studio. С помощью USB-Host можно подключить к панели оператора клавиатуру и компьютерную мышь с USB-выходом. Кроме того, к этому порту можно подсоединить внешнее запоминающее устройство USB (USB-флэш-накопитель или жесткий диск). Как было сказано выше, это позволяет расширить объем внутренней памяти ПЗУ (ROM) панели оператора, если в ней планируется хранить большой объем архивных данных. Для загрузки проекта HMI можно также использовать Ethernet-соединение, интерфейс USB-Host или SD-карту.
Сенсорные панели оператора ONI серии ETG поддерживают большое количество протоколов передачи данных различных производителей (рис. 17), а также популярный открытый протокол Modbus (RTU и TCP). Текстовая панель ONI TD-MP-043 предусматривает только протокол Modbus RTU. Такие коммуникационные возможности делают панели универсальным средством создания HMI.
Рис. 17. Окно настройки COM-порта
Чаще всего панель оператора применяют в паре с программируемым логическим контроллером (ПЛК) или группой контроллеров. ПЛК осуществляет контроль и управление исполнительными механизмами согласно заложенному в нем алгоритму, а HMI-панель является средством отображения и ввода данных в ПЛК.
Такие инструменты ONI Visual Studio, как «Рецепт», «Таймер», «Расписание задач» и особенно «Макрос», позволяют реализовать алгоритм контроля и управления в самой HMI-панели. Такая возможность может быть актуальна, если в системе автоматизации отсутствуют ПЛК, но есть исполнительные механизмы и контроллеры с жесткой логикой, поддерживающие протоколы передачи данных. В качестве примера подобного технического решения можно привести систему управления несколькими насосными станциями с частотно-регулируемым приводом. В каждой насосной станции преобразователь частоты с протоколом Modbus RTU управляет насосом, и можно реализовать необходимый алгоритм чередования запуска станций с помощью одной HMI-панели.
Панели оператора ONI серии ETG предлагают еще несколько коммуникационных возможностей, которые может использовать разработчик для создания интересных и высокоэффективных технических решений:
- Работа HMI-панели в режиме «Удаленный НМI». В этом случае HMI-панель может получать доступ к регистрам памяти панели оператора, которая физически удалена (размещена в другом помещении, установлена в другом НКУ и т. д.). Такой режим можно настроить при наличии Ethernet-соединения.
- Используя Ethernet-соединение между двумя удаленными друг от друга HMI-панелями, можно применить еще один режим работы — «Удаленный ПЛК». Его суть заключается в том, что HMI-панель может получить доступ к регистрам контроллера, который подключен к удаленной HMI-панели по COM-порту.
- Встроенный в HMI-панели VNC-сервер позволяет организовать удаленный доступ к пользовательскому интерфейсу при помощи ПК, если они находятся в одной локальной Ethernet-сети (рис. 18). При наличии Wi-Fi-роутера можно обеспечить беспроводное управление с мобильного устройства (смартфона или планшета). Для работы в этом режиме ПК и мобильное устройство должны быть оснащены VNC-клиентом (как правило, распространяется бесплатно).
Рис. 18. Удаленный доступ к HMI-панели по технологии VNC
Больше, чем философия
Кларк называет это философией „ограниченных векторов угроз”. По его словам, идеальной безопасной системой управления является система, которая:
- изолирована от всех угроз, включая корпоративную систему;
- разделяется защищающими от проникновения системами;
- имеет только одну точку входа/выхода;
- содержит все автоматизированные устройства системы в пределах одного безопасного сегмента;
- позволяет каждой проверенной машине в пределах предприятия иметь беспрепятственный, неограниченный доступ к другой безопасной машине.
Компания Microsoft Corp. называет такую модель безопасности „изоляцией домена”. В версии 3.5 программного обеспечения iFIX GE Fanuc предусмотрены встроенные функции защиты с сервисной программой для проверки достоверности „Application Validator Utility”. Такой программный инструмент автоматически фиксирует любые изменения, сделанные в системных файлах или приложениях, сокращая вероятность непреднамеренного или преднамеренного риска.
Пример применения: Безопасность и защита алюминиевого производства на базе системы ЧМИ
Построенное в 1990 году предприятие Alcoa—Aluminerie de Deschambault в Квебеке требовало модернизации. На основном предприятии работает около 550 человек, производится необработанный алюминий, который далее отправляется на формовку и изготовление различной продукции.
Контроль и управление процессами осуществлялись на базе операционной системы DOS, которая не подлежит модернизации. Сбор данных выполнялся посредством собственной системы OpenVMS (VAX). „Нам нужна была система, которую можно модифицировать при минимальном объеме работы», — поясняет Пьер Бо-утин, инженер по прикладным программам на предприятии.
Персоналу компании требовался удобный доступ к данным технологического процесса. Например, команда из более чем 30 человек тесно взаимодействует, но может быть рассредоточена в полукилометровой зоне от установки в любой момент времени. Для любой новой системы требуется обеспечить высоконадежный метод обеспечения доступа авторизованным пользователям к управляющим данным из любой точки в пределах предприятия, но изменение управляющих параметров может производиться только с определенных контрольных мест.
Боутин и его коллеги решают установить устройство контроля и управления, использующее программное обеспечение Cimplicity от GE Fanuc Automation в верхней части существующей инфраструктуры. Процесс электролиза алюминия с целью извлечения металла делится на пять секторов. В каждом секторе находится от 10 до 15 программируемых логических контроллеров (ПЛК) серии 90-70 и несколько ПЛК серии 90-30 GE Fanuc, обеспечивающих резервированные функции контроля и управления. В каждом секторе ПЛК контролируют приблизительно 10000 точек.
Внутри каждого сектора ПЛК и операторские интерфейсы, оснащенные программой Cimplicity, связаны через коммутаторы по звездной топологии Ethernet и подключаются к соседним секторами по стандарту 10Base-T. Каждый сектор, в свою очередь, подключен по опто-волокoнно-му каналу связи Ethernet 100 Мбит/ к департаменту ИТ, где находится управляющий сервер. Клиентская часть располагается в секторах. Персонал ИТ осуществляет поддержку этой системы.
Расположенные на территории операторские интерфейсы, реализованные с помощью программного обеспечения Cimplicity HMI Plant Edition, используют Web-технологию на базе открытой архитектуры клиент-сервер и обеспечивают удаленный доступ пользователям к данным в режиме реального времени через Web-браузеры. В дополнение к встроенным функциям контроля доступа департамент ИТ добавил еще один уровень защиты для обеспечения возможности одновременного просмотра процессов авторизованными пользователями со всех станций, а изменение параметров только с нескольких выделенных станций.
Новая система контроля и управления хорошо себя зарекомендовала, упрощая взаимодействие между сотрудниками ИТ и управления процессом, тогда как рассогласование их действий преобладает на многих других предприятиях. „Коллективная работа двух групп очевидна, -комментирует Боутин, — и она играет основную роль в успешной работе нашей системы контроля и управления».
Операторские интерфейсы, использующие программное обеспечение GE Fanuc Automation Cimplicity, позволяют авторизованным пользователям просматривать данные управления в любой точке производства, но изменить параметры возможно только из выделенных точек доступа
Заключение
Панель оператора является универсальным средством создания HMI в различных системах автоматизации. И сегодня, благодаря широкому функционалу и доступной цене, НMI-панели становятся все более популярными.
ТМ ONI предлагает высококачественное оборудование для автоматизации, включая HMI-панели (табл.), на базе которых можно создать интерфейс, способный удовлетворить даже специфические требования.
Буквально еще несколько лет назад поисковики в ответ на поисковый запрос «Облака» выдавали множество ссылок на детские мультфильмы и статьи в Википедии об атмосферных явлениях. В последние два-три года тенденция изменилась и в топ выдачи стали попадать публикации c описанием облачных вычислений и платформ, а сам термин «Облака» у IT-специалистов теперь вызывает неоднозначные ассоциации: уже далеко не все представляют себе «взвешенные в атмосфере продукты конденсации водяного пара», скорее в сознании «правильного айтишника» возникают образы виртуальных площадок и платформ, различных IaaS, PaaS, SaaS. Виртуализация всего и вся — один из главных трендов десятилетия, множество клиентских сервисов давно переселились в облака, крупные телеком-бизнесы внедряют все новые и новые VAS в дополнение к основным услугам, а зачастую, то, что когда-то было Value Added Service превращается в базовый продукт. Услуги связи в этом смысле не являются исключением и сервис «Облачная АТС» становится просто обязательным пунктом в списке предложений телефонного оператора. О том, как (в том числе и с нашей помощью) быстро и сравнительно непринужденно запустить собственный сервис облачной АТС мы расскажем ниже.
Для простоты определим, что извечный вопрос «быть или не быть новому сервису» решен изначально и ни у кого из уважаемых представителей телекома не вызывает сомнений тот факт, что телефонный бизнес без виртуальных АТС в 2015-м году — это не совсем правильно, вернее неправильно совсем. Рынок в этом сегменте растет до 40% в год и с таким фактом невозможно не считаться. Те из операторов, кто еще не успел запустить в продакшн облачную IP-PBX, почти наверняка задумываются об этом или вот-вот задумаются, вопрос исключительно в методах и сроках.
Глазами клиента
Обрадованный клиент проходит по ссылке в письме, вводит свои учетные данные (страничка авторизации предусмотрительно кастомизированна в корпоративном стиле партнера), ждет пару секунд
и авторизуется в своей, новоиспеченной, облачной АТС, где его ожидает кастомизированный интерфейс с оптимумом кнопок и настроек. Теперь дело за малым: сконфигурировать свою АТС-ку по собственному разумению, но это уже задача самого клиента. Не будем ему мешать.
Минимализм клиентского интерфейса смущать не должен: все необходимое есть, настройки визуализированы, раздел «Статистика» создан с расчетом на пытливый ум рачительного руководителя и отображает все детали по каждому из сотрудников, формирует графики и отчеты. Раздел «Настройки» структурирован и все «фичи» предусмотрительно спрятаны под иконкой «Еще». Кнопка коробочной интеграции с CRM находится на самом видном месте. Подробное описание функционала клиентской части облачной АТС ITooLabs заняло бы еще пару страниц убористого текста. Когда-нибудь мы опишем и его, тем более, что на наш взгляд есть чем похвастаться. Но это уже другая история.
Шесть шагов до первого звонка
Представим, что у нас появился запрос от нового партнера-оператора и пройдем процедуру запуска виртуального облачного телефонного сервиса глазами самого оператора по шагам, с подключением первого конечного клиента.
Для начала запрашиваем и получаем учетную запись суперадминистратора своего сегмента платформы. Как уже говорилось выше — платформа живет в нашем кластере, никаких многодневнных инсталляций и настроек не требуется, по факту все просто: по ТЗ кастомизируется интерфейс, генерится новая учетная запись СисАдмина и отправляется партнеру-оператору. Два-три дня и партнер получает свою учетку и может авторизоваться.
В этом интерфейсе, собственно, и проходит бОльшая часть жизни администратора сервиса: видим виртуальные АТС наших «конечников», можем активировать и деактивировать их, отключать или подключать дополнительные услуги, выставлять лимиты и ограничения, настраивать транки, номера и маршрутизацию. Итак, первая АТС-ка продана и у нас есть запрос первого клиента. Дальше по шагам.
создаем новую клиентскую АТС (понятно, что клиент предварительно сообщил сколько сотрудников он планирует телефонизировать и какие дополнительные сервисы он хотел бы использовать). Генерируем новый субдомен, доступный по веб-адресу, который уважаемый партнер-оператор пожелал использовать для своей новой услуги. Адрес выглядит как: название_клиента.домен_партнера.
Изучив пожелания клиента подключаем ему тот набор сервисов, который он заказал после общения с продавцами или начитавшись маркетинговых описаний на сайте услуги. Все управление только GUI, консоль не требуется совсем. Для желающих можно предоставить доступ ко всем логам платформы.
мы оператор, у нас много стыков с различными вышестоящими провайдерами и мы хотим управлять многочисленными транками, обеспечивая возможность каждому из клиентов звонить по оптимальному маршруту. Для этого создаем то количество шлюзов, которое необходимо (шлюз — он же транк, он же стык, он же гейтвей для входящих и исходящих звонков). Тут же можно подключить биллинг, выставить все необходимые правила для пропуска caller ID, формат трансляции номера и особенности передачи АОН.
прописываем необходимые маршруты и говорим какие вызовы и по каким направлениям будут маршрутизироваться в определенные транки-шлюзы. Оптимизация и еще раз оптимизация. Москву отправляем на московских операторов, а «межнар» в Дюссельдорф или Гамбург. Маршруты могут быть сколь угодно разнообразными.
Шаг четвертый:
создаем диал-планы. Еще со времен СССР в сознании большинства людей старшего поколения любой звонок на междугородные и международные направления должен начинаться с «8», а в сознании поколения X, которое пользуются исключительно смартфонами, правильный набор всегда начинается со знака «+». Упростим жизнь и тем и другим и настроим диал-планы так, чтобы все были довольны. Потом диал-планы «раскидаем» по пользователям.
телефонные номера. Сервис облачной АТС без входящий связи — нонсенс. Поэтому входящая связь должна быть. Мы оператор и у нас есть собственная номерная емкость (или мы получаем номерную емкость по партнерской схеме от вышестоящих провайдеров). Пропишем номера, доступные для пользователей облачных АТС, и сопоставим нужные цифры с нужными клиентами. Теперь на номера можно звонить и все вызовы будут проходить по заранее созданным маршрутам. Сколько входящих номеров доступно «конечнику» решаем только мы простым кликом мышки.
каждому клиенту свой маршрут. Основываемся на собственной бизнес-логике и даем возможность клиентам звонить оптимальным для нас образом. Прикрепляем заранее созданный маршрут к каждой отдельной АТС. Иногда бывает так, что клиент хочет продолжить использовать своего старого оператора. Что ж, можно позволить и такое, настроив определенную АТС для работы через отдельный, специализированный шлюз.
Шесть шагов по настройке первой виртуальной АТС пройдены, наступает момент истины. Нажимаем «Сохранить» и заводим для клиента учетную запись администратора, указываем ФИО, контакты, телефоны, пароли и явки.
Верхний уровень: от гирлянды до целой рабочей станции
Верхним уровнем называют все то, к чему может прикасаться обычный смертный оператор, который управляет технологическим процессом. В простейшем случае верхний уровень представляет собой набор лампочек и кнопочек. Лампочки сигнализируют оператору о неких происходящих событиях в системе, кнопочки служат для подачи команд контроллеру. Такую систему часто называют «гирлянда» или «ёлка», потому что выглядит очень похоже (как можно убедиться по фотографии в начале статьи).
Если оператору повезло больше, то в качестве верхнего уровня ему достанется панель оператора — некий плоскопанельный компьютер, который тем или иным образом получает данные для отображения от контроллера и выводит их на экран. Такая панель обычно монтируется на сам шкаф автоматики, поэтому взаимодействовать с ней приходится, как правило, стоя, что вызывает неудобства, плюс качество и размер изображения — если это малоформатная панелm — оставляет желать лучшего.
Ну и, наконец, аттракцион невиданной щедрости — рабочая станция (а то и несколько дублирующих), представляющая собой обычный персональный компьютер.
Для наглядного отображения информации на рабочих станциях и плоскопанельных компьютерах используют специализированное программное обеспечение — SCADA-системы. На человеческий язык SCADA переводится как система диспетчерского управления и сбора данных. Она включает в себя множество компонентов, таких как человеко-машинный интерфейс, визуализирующий технологические процессы, систему управления этими процессами, систему архивирования параметров и ведение журнала событий, систему управления тревогами и т.д. Всё это дает оператору полноценную картину происходящих на производстве процессов, а также возможность ими управлять и оперативно реагировать на отклонения от технологического процесса.
Оборудование верхнего уровня обязано взаимодействовать неким образом с контроллером (иначе зачем оно нужно?). Для такого взаимодействия используются протоколы верхнего уровня и некая технология передачи, например, Ethernet или UART. В случае с «ёлкой» таких изощрений, конечно, не нужно, лампочки зажигаются с использованием обычных физических линий, никаких мудреных интерфейсов и протоколов там нет.
В общем-то, этот верхний уровень менее интересен, нежели полевая шина, поскольку этого верхнего уровня может вообще не быть (из серии нечего там смотреть оператору, контроллер сам разберется, что и как нужно делать).
HMI-панель в составе НКУ
Панели оператора активно применяют для создания удобного HMI в различных низковольтных комплектных устройствах (НКУ), таких как щиты автоматизации, диспетчеризации, управления, мониторинга и т. д. Это позволяет свести к минимуму физические элементы: светосигнальную арматуру, кнопки, переключатели, стрелочные приборы и т. д.
Как правило, HMI-панель устанавливают на лицевой панели щита, шкафа или пульта управления. На рис. 19 приведен пример применения панели оператора в составе щита автоматизации. На рис. 2 HMI-панель включена в пульт управления.
Рассмотрим порядок установки панели оператора ONI серии ETG. Процесс достаточно прост и состоит из трех основных шагов (рис. 19):
- В том месте корпуса, где планируется разместить HMI-панель, необходимо отметить место выреза будущего монтажного отверстия (его размеры указаны в паспорте и системном руководстве).
- Произвести вырез отверстия по указанным меткам.
- Установить HMI-панель в вырез и закрепить специальными металлическими фиксаторами, входящими в комплект поставки.
Рис. 19. Порядок установки HMI-панели в оболочку НКУ
Все панели оператора ONI оснащены специальным силиконовым уплотнением, которое обеспечивает плотное прилегание панели оператора к корпусу, тем самым позволяя сохранить степень IP-защиты корпуса (рис. 20).
Степень защиты самой HMI-панели определяется через степень защиты фронтальной стороны, которая имеет уровень IP65, и тыльной стороны — IP20.
Рис. 20. Монтажный комплект для крепления HMI-панели
Вместо заключения
Понятно, что идеальных схем в реальной жизни не бывает, так же как и не бывает идеальных способов запустить новый или условно новый бизнес. Каждая из ситуаций индивидуальна и требует вдумчивого подхода и анализа. При этом в телекоме наблюдается четкий тренд: стремление к унификации и тиражируемости продуктов, эдакий «телеком-макдональдс», в котором подключение новых клиентов, их поддержка и обслуживание, поставлены на поток по отработанной технологии. Использование PaaS-платформ — как раз и есть шаг в этом направлении, поскольку клиент становится все более требовательным и капризным и просит все больше любви и внимания. В таких условиях огромное количество ресурсов тратится на удержание, а не только на привлечение. Все, описанное выше, есть лишь один из рецептов «универсального гамбургера» и мы верим в то, что именно такая модель окажется наиболее жизнеспособной в сфере серийных продаж телеком-продуктов для SMB.
Как работают современные промышленные шины и протоколы
А что теперь? К сегодняшнему дню классическая идеология построения автоматизированных систем немного поменялась. Роль сыграли множество факторов, начиная с того, что автоматизировать тоже должно быть удобно, и заканчивая тенденцией на распределенные автоматизированные системы с удаленными друг от друга узлами.
Пожалуй, можно сказать, что основных концепций построения систем автоматизации на сегодняшний день две: локализованные и распределенные автоматизированные системы.
В случае с локализованными системами, где сбор данных и управление централизовано в одном конкретном месте, востребована концепция некоего набора модулей ввода-вывода, соединенных между собой общей быстрой шиной, включая контроллер со своим протоколом обмена. При этом, как правило, модули ввода-вывода включают в себя и преобразователь сигнала и гальваническую развязку (хотя, разумеется, не всегда). То есть конечному потребителю достаточно понять, какие типы датчиков и механизмов будут присутствовать в автоматизированной системе, сосчитать количество требуемых модулей ввода-вывода для разных типов сигналов и соединить их в одну общую линейку с контроллером. В этом случае, как правило, каждый производитель использует свой любимый протокол обмена между модулями ввода-вывода и контроллером, и вариантов тут может быть масса.
В случае распределенных систем справедливо все, что сказано в отношении локализованных систем, кроме этого, важно, чтобы отдельные компоненты, например, набор модулей ввода-вывода плюс устройство сбора и передачи информации — не очень умный контроллер, который стоит где-нибудь в будке в поле, рядом с краном, который перекрывает нефть, — могли взаимодействовать с такими же узлами и с главным контроллером на большом расстоянии с эффективной скоростью обмена.
Как разработчики выбирают протокол для своего проекта? Все современные протоколы обмена обеспечивают довольно высокое быстродействие, поэтому зачастую выбор того или иного производителя обусловлен не скоростью обмена по этой самой промышленной шине. Не так важна и реализация самого протокола, потому что, с точки зрения разработчика системы, это все равно будет черный ящик, который обеспечивает некую внутреннюю структуру обмена и не рассчитан на вмешательство извне. Чаще всего обращают внимание на практические характеристики: производительность вычислителя, удобство применения концепции производителя к поставленной задаче, наличие нужных типов модулей ввода-вывода, возможность горячей замены модулей без разрыва шины и т.д.
Популярные поставщики оборудования предлагают собственные реализации промышленных протоколов: например, всем известная компания Siemens разрабатывает свою серию протоколов Profinet и Profibus, компании B&R — протокол Powerlink, Rockwell Automation — протокол EtherNet/IP. Отечественное решение в этом списке примеров: версия протокола FBUS от российской компании Fastwel.
Есть и более универсальные решения, которые не привязаны к конкретному производителю, такие как EtherCAT и CAN. Мы подробно разберем эти протоколы в продолжении статьи и разберемся, какие из них лучше подходят для конкретных применений: автомобильной и аэрокосмической промышленности, производства электроники, систем позиционирования и робототехники. Оставайтесь на связи!
Операторский интерфейс должен строиться с соблюдением принципа от общего к частному, обеспечивая унификацию общей процедуры анализа ситуации с целью сокращения времени, затрачиваемого оператором на анализ ситуаций. [1]
Операторский интерфейс обеспечивает полный контроль и получение информации с помощью простой в использовании клавиатуры и большого, удобного для чтения, дисплея на жидких кристаллах, Все установки производятся путем выбора из меню и цифрового ввода данных. Не требуется ползунковых потенциометров для настройки. [2]
Операторский интерфейс комплекса Центр-2 построен, в основном, на базе разнородных концентраторов и групповых следящих задат-чиков, обеспечивающих двойное управление: децентрализованное ручное из зоны, где они непосредственно установлены ( зона контроля и управления переходных режимов ЦПУ или местные посты управления, удаленные от ЦПУ на значительное расстояние) и централизованное со стороны оператора с помощью оконечного концентратора, расположенного, как правило, на пульте, или непосредственно от автоматического устройства, например, от ЭЦВМ. [3]
В типовой операторский интерфейс комплекса Центр-1 входят два таких поля. [4]
Развитие операторского интерфейса АСУ ХТК характеризуется качественно новыми тенденциями как с функциональной, так и с аппаратурной точки зрения. [5]
Требуется разработать операторский интерфейс для управления технологическим процессом, протекающим в отстойнике на УГШ. [7]
Так как операторский интерфейс содержит большое количество экранов, при разработке проекта оператору надо обеспечить возможность навигации по экранам. Эта задача может быть решена различными приемами. [8]
Требуется разработать операторский интерфейс для управления технологическим процессом, протекающим в отстойнике на УГШ. [10]
Так как операторский интерфейс содержит большое количество экранов, при разработке проекта оператору надо обеспечить возможность навигации по экранам. Эта задача может быть решена различными приемами. [11]
В составе операторского интерфейса АСУ ХТК используются различные модификации концентраторов типа КЗ. [12]
Усложнение общей структуры операторского интерфейса в зонах К4 и К5 определяется в основном усложнением структуры самих локальных фрагментов. [13]
Основная тенденция развития операторского интерфейса АСУ ХТК в аппаратурном плане заключается в стремлении максимально унифицировать средства связи с оператором на уровне крупных блоков, обеспечивающих индустриальный характер всем основным этапам создания центральных пунктов ( ЦПУ) и местных постов управления ( МПУ) конкретных АСУ. [14]
Многогранное понятие безопасности операторского интерфейса является определяющим фактором оптимизации производительности системы.
На этом фармацевтическом производстве работа начинается, управляется и контролируется операторами с помощью программного обеспечения Wonderware InTouch, которое обеспечивает персонал пошаговыми инструкциями. На рисунке показана производственная линия (слева) и пример системы управления и контроля качества продукции
Безопасность человеко-машинного интерфейса (HMI) — понятие двойственное. С одной стороны, безопасность относится к „способу управления, встроенному в ПЛК и защитную блокировку, — говорит Стивен Гарбрехт, менеджер по программе маркетинга инфраструктурной и платформенной продукции Wonderware. — Безопасность является неотъемлемой частью программ управления”. С другой стороны, вопросы безопасности часто возникают по отношению к людям, которые могут войти в систему управления, чтобы украсть информацию или вызвать повреждение. Эти два аспекта учитываются различными способами. Поэтому, когда речь идет о HMI, эти понятия безопасности взаимосвязаны. Корректная безопасная система управления не позволит оператору выполнить какие-либо действия, которые могут повредить продукт или компонент оборудования, и обеспечит выполнение своевременных действий для предотвращения подобной ситуации. Рассмотрим катастрофу в декабре 1984 года, когда неконтролируемая химическая реакция на установке „Юнион Карбайд» в индийском городе Бхопале привела к утечке нескольких тонн метил-изоцианата, что стало причиной гибели и заболевания тысячи человек. Существует разногласие, сработали ли системы безопасности установки, или положение в „Юнион Карбайд» было таковым, что утечка могла быть причиной хорошо продуманного саботажа. Многие с этим не согласны. Во время аварии в марте 1979 года на атомной электростанции, расположенной на острове Три-Майл (Три-Майл-Айленд), штат Пенсильвания, операторы станции не знали, что жизненно важный предохранительный клапан оставался открытым, несмотря на показание, свидетельствовавшее, что он закрыт. Позднее они получили некорректную информацию об уровне воды в реакторе. В результате последующего расследования вопрос саботажа был исключен, и стало очевидным, что если бы операторы получили корректную информацию, они смогли бы предотвратить выход ситуации из-под контроля.
Пример применения: Программное обеспечение контроля производительности, интерфейсы для оптимизации работы в соответствии с установленными нормами
Недавно компания Roche Diagnostics | GmbH установила новую линию упаков-средств наблюдения и диагностики диабета на объекте в Манхайме, Германия. В соответствии со стандартами Управления по контролю за продуктами питания и медикаментами (США) для повышения эффективности и возможности контроля над процессом, компания внедрила программную систему для управления производительностью Wonderware, подразделение Invensys Systems Inc.
Компания искала систему, которая была бы удобной в использовании и обеспечила бы возможность проверки технологического процесса в соответствии с правилами Управления по контролю за продуктами питания и медикаментами (FDA), 21 CFR Часть 11 (Свод федеральных нормативных актов). Два существенных компонента выбранного программного пакета Wonderware включают программное обеспечение человеко-машинного интерфейса (ЧМИ) и сервер-архиватор IndustrialSQL, который совмещает базу данных с системой реального времени. Обе эти функции позволят компании Roche выполнять поставленные задачи и соответствовать требованиям FDA.
На новой упаковочной линии бутылочки индивидуально отделяются от паллет, сортируются и объединяются в группу для упаковки. Затем эти группы транспортируются на поворотный стол для последующей обработки. К ним приклеиваются этикетки, и камера проверяет корректность и правильное расположение штрихового кода. Затем следующая камера проверяет бутылочки и крышки на соответствие цвету, после чего они направляются на окончательную стадию упаковки. Процесс изготовления начинается и контролируется операторами с помощью программного обеспечения. Система интерфейса выдает пошаговые указания оператору в ходе выполнения всего процесса. Им не надо выбирать из множества экранных опций.
Правила Управления по контролю за продуктами питания и медикаментами (FDA) требуют, чтобы изготовители отслеживали производственные данные. Это означает, что компания должна обосновывать каждый шаг производственного процесса, включая выполнение задачи оператором, и когда было выполнено то или иное действие. Возможности программного обеспечения по управлению пользователями и функции авторизации операционной системы Microsoft Windows 2000 обеспечивают надежную систему безопасности на предприятии, предотвращая несанкционированное вмешательство пользователя.
„Одним из преимуществ использования такого подхода является то, что управление доступом пользователей осуществляется не на автономной части системы, а является системой защиты всего предприятия, — комментирует Оув Дрюкер, управляющий директор Drucker Steuerungssysteme GmbH. — Используя этот метод работы, компания может легко встраивать и использовать профили пользователей существующей операционной системы предприятия. В дополнение, удобные в использовании инструменты управления и совместимые интерфейсы позволяют операторам Манхайма поддерживать оптимальную производительность процессов упаковки продукции. Мы обеспечиваем полную защиту обмена данными с помощью единой системы управления доступом пользователей без использования нескольких дорогостоящих частных решений».
Операторы новой линии процесса упаковки входят в систему после авторизации и получают доступ для выполнения определенных действий в зависимости от их уровней полномочия. Действия, которые выполняются в этом процессе, могут включать повседневные операции, такие как создание или редактирование производственных и технологических данных, инициация процесса, временное прекращение или остановка серии, или редактирование параметров пользователя. Операторы, работающие на этой линии, должны подтверждать свои действия посредством ввода имени пользователя и пароля. Такая технология защиты доступа позволяет компании соответствовать требованиям FDA и защитить процессы изготовления и обработки от несанкционированного вмешательства.
Программа обеспечивает ввод электронных подписей с простановкой меток времени, которые связывают оператора с выполнением определенных действий. Подпись и любые другие соответствующие данные фиксируются в архивной базе данных сервера IndustrialSQL для формирования полных контрольных записей (см. иллюстрацию). Уполномоченные администраторы или менеджеры могут в любое время просматривать и распечатывать эти данные. Информацию и электронные подписи невозможно изменить или удалить — результат сертифицированного FDA хранилища с защитой от несанкционированного вмешательства.
Кроме того на производстве в Манхайме используется система резервирования для повышенной надежности и защиты данных. Физически отделенная от главной системы эта резервная система постоянно синхронизирует данные с главной системой. В случае отказа главной системы такой метод синхронизации с квитированием позволяет отследить момент сбоя и автоматически переключиться в главный режим работы, обеспечивая отказоустойчивость системы. Такая бесшовная интеграция корпоративной сети также обеспечивает доступ ко всем данным предприятия для анализа.
Помимо необходимости удовлетворения требований FDA растущая угроза биотерроризма и фальсификации продукции всегда является критическим аспектом для фармацевтических компаний. Функции защиты, обеспечиваемые программной системой управления, обеспечивают высокий уровень конфиденциальности, позволяя компании отслеживать и поддерживать качество на каждом этапе производства и упаковки.
HMI-панели
Панели оператора используются в разных сферах человеческой деятельности. Их активно применяют для автоматизации отдельных агрегатов, установок или целого технологического процесса в структуре АСУ ТП.
Трехуровневая архитектура современных АСУ ТП (рис. 4) определила комбинированный подход к реализации HMI: на верхнем уровне (диспетчеризации) развернута SCADA-система, а на среднем (контроля и управления) помещены HMI-панели или панельные компьютеры.
Рис. 4. Трехуровневая структура АСУ ТП
Применение панелей оператора на среднем уровне позволяет прежде всего повысить надежность работы автоматизированной системы. Как правило, HMI-панель входит в состав щита или пульта управления отдельной технологической операцией, а то и технологическим процессом в целом. В случае выхода из строя центрального АРМ на базе SCADA-системы оперативный персонал может локально производить настройку и контроль параметров технологического процесса. Использование HMI-панелей также позволяет повысить скорость и эффективность пусконаладочных работ.
Более того, при автоматизации небольших объектов HMI-панель может стать хорошей альтернативой полноценной SCADA-системе и промышленным панельным компьютерам. Это возможно благодаря тому, что современные HMI-панели, такие как панели оператора ТМ ONI, обладают широким функционалом, который сопоставим с работой SCADA-системы.
«Древние» протоколы передачи данных: Modbus и HART
Мало кто знает, но на седьмой день создания мира Бог не отдыхал, а создавал Modbus. Наравне с HART-протоколом, Modbus, пожалуй, самый старый промышленный протокол передачи данных, он появился аж в 1979 году.
В качестве среды для передачи изначально использовался последовательный интерфейс, затем Modbus реализовали поверх TCP/IP. Это синхронный протокол по схеме «мастер-слейв» (главный-подчиненный), в котором используется принцип «запрос-ответ». Протокол довольно тяжеловесный и медленный, скорость обмена зависит от характеристик приемника и передатчика, но обычно счет идет чуть ли не на сотни миллисекунд, особенно в реализации через последовательный интерфейс.
Более того, регистр передачи данных Modbus является 16-битным, что сразу же накладывает ограничения на передачу типов real и double. Они передаются либо по частям, либо с потерей точности. Хотя Modbus до сих пор повсеместно используется в случаях, когда не нужна высокая скорость обмена и потеря передаваемых данных не критична. Многие производители различных устройств любят расширять протокол Modbus своим исключительным и очень оригинальным образом, добавляя нестандартные функции. Поэтому данный протокол имеет множество мутаций и отклонений от нормы, но все же до сих пор успешно живет в современном мире.
Протокол HART тоже существует с восьмидесятых годов, это промышленный протокол обмена поверх двухпроводной линии токовой петли, в которую напрямую включаются датчики 4-20 мА и другие приборы с поддержкой протокола HART.
Для коммутации линий HART используются специальные устройства, так называемые HART-модемы. Также существуют преобразователи, которые на выходе предоставляют пользователю уже, допустим, протокол Modbus.
Примечателен HART, пожалуй, тем, что помимо аналоговых сигналов датчиков 4-20 мА в цепи передается и цифровой сигнал самого протокола, это позволяет соединить цифровую и аналоговую часть в одной кабельной линии. Современные HART-модемы могут подключаться в USB-порт контроллера, соединяться по Bluetooth, либо же старинным способом через последовательный порт. Десяток лет назад по аналогии с Wi-Fi появился и беспроводной стандарт WirelessHART, работающий в диапазоне ISM.
Второе поколение протоколов или не совсем промышленные шины ISA, PCI(e) и VME
На смену протоколам Modbus и HART пришли не совсем промышленные шины, такие как ISA (MicroPC, PC/104) или PCI/PCIe (CompactPCI, CompactPCI Serial, StacPC), а также VME.
Настала эра вычислителей, имеющих в своем распоряжении универсальную шину передачи данных, куда можно подключать различные платы (модули) для обработки некоего унифицированного сигнала. Как правило, в этом случае процессорный модуль (вычислитель) вставляется в так называемый каркас, который обеспечивает взаимодействие по шине с другими устройствами. Каркас, или, как его любят называть трушные автоматизаторы, «крейт», дополняется необходимыми платами ввода-вывода: аналоговыми, дискретными, интерфейсными и т.д., либо все это слепливается в виде бутерброда без каркаса — одна плата над другой. После чего это многообразие на шине (ISA, PCI, etc.) обменивается данными с процессорным модулем, который таким образом получает информацию с датчиков и реализовывает некую логику.
Контроллер и модули ввода-вывода в каркасе PXI на шине PCI. Источник: National Instruments Corporation
Все бы ничего с этими шинами ISA, PCI(e) и VME, особенно для тех времен: и скорость обмена не огорчает, и расположены компоненты системы в едином каркасе, компактно и удобно, горячей замены плат ввода-вывода может и не быть, но пока еще и не очень хочется.
Но есть ложка дегтя, и не одна. Распределенную систему довольно сложно построить в такой конфигурации, шина обмена локальная, нужно что-то придумывать для обмена данными с другими подчиненными или равноправными узлами, тот же Modbus поверх TCP/IP или какой другой протокол, в общем, удобств маловато. Ну и вторая не очень приятная штука: платы ввода-вывода обычно ждут на вход какой-то унифицированный сигнал, и гальванической развязки с полевым оборудованием у них нет, поэтому нужно городить огород из различных модулей преобразования и промежуточной схемотехники, что сильно усложняет элементную базу.
Промежуточные модули преобразования сигнала с гальванической развязкой. Источник: DataForth Corporation
«А что с протоколом обмена по промышленной шине?» — спросите вы. А ничего. Нет его в такой реализации. По кабельным линиям сигнал попадает с датчиков на преобразователи сигналов, преобразователи выдают напряжение на дискретную или аналоговую плату ввода-вывода, а данные с платы уже читаются через порты ввода/вывода, средствами ОС. И никаких специализированных протоколов.
Запускаем свою облачную АТС
Способов запуска телефонного SaaS-сервиса несколько, коротко остановимся на двух наиболее распространенных: запуск облачной АТС как собственной разработки и запуск сервиса на базе White Label платформы одного из вендоров. Если оба способа изобразить наглядно и попытаться описать несколькими словами, то получится вот такая картина:
Собственными силами
Все делаем сами, разрабатываем платформу с нуля или создаем ее на базе существующих опенсорсных (или проприетарных) решений, самостоятельно развиваем и поддерживаем. В этом случае сервис-провайдер получает ощущение независимости и контроля всего и вся, но тратит много времени на запуск и вовлекается ресурсно и финансово, фактически разработка сервиса не прекращается никогда.
По модели PaaS
Пользуемся готовой PaaS-платформой и занимаемся только продажами и маркетингом, оставив технологическому партнеру бОльшую часть околотехнических забот. Сроки внедрения стремятся к минимуму, отпадает необходимость в существенных объемах разработки и поддержки, ресурс требуется только на маркетинг и продажи и чуть-чуть на первый уровень саппорта, можно сфокусироваться на коммерческих аспектах, не отвлекаясь на круглосуточный кодинг, но появляется зависимость от вендора и его бизнес-модели.
Первый путь — предмет целого, отдельного, исследования и мы к нему обязательно вернемся в одной из следующих публикаций, второй же путь нам ближе и понятнее и подробно рассмотрим именно его на примере нашей облачной White Label платформы ITooLabs. Добавим лишь, что при запуске сервиса виртуальной АТС на PaaS-платформе выбор «правильного вендора» — одна из архиважных задач, правильное решение которой может нивелировать главную проблему — зависимость от этого самого вендора.
Разработка ITooLabs Communication Server — история продолжительностью в несколько лет. В основе продукта — собственное коммуникационное ядро, собственные интерфейсы и компоненты, собственное видение того, каким должна быть «правильная» облачная АТС, множество бессонных ночей разработчиков и маркетологов. Серверная часть, или то, что и принято называть PaaS, развернута в собственном же кластере: так спокойнее и нам и нашим партнерам. Мы обеспечиваем функционирование всех сегментов, контролируем и управляем, мониторим и обновляем, поддерживаем и саппортим.
Партнер сервис-провайдер получает доступ к панели администратора после короткой и совершенно не мучительной кастомизации: логотипы, цветовая гамма и графические элементы интерфейса меняются практически на лету. В большинстве случаев запуск — от кастомизации до первого «Алло» — занимает не больше нескольких дней. В придачу даем программный ITooLabs Communicator (тоже кастомизированный) и постоянно обновляемый, актуальный и востребованный, функционал. О возможностях платформы в инфографике:
ITooLabs Communication Server обеспечивает доступ к двум различным видам интерфейса управления: операторский интерфейс (он же интерфейс супер администратора) и клиентский интерфейс. Задача первого — обеспечить максимальный контроль и управляемость сервиса на стороне оператора, задача второго — удобство и простота, именно поэтому под рукой «CисАдмина» множество кнопок и чекбоксов, а в интерфейсе клиента минимум лишних опций и сплошные «красивости». СисАдмин управляет и контролирует, а клиент настраивает переадресации и IVR. Оба интерфейса кастомизируются и настраиваются. Пример «покрашенного» интерфейса клиента можно увидеть на скриншоте ниже.
Интерфейс СисАдмина выглядит чуть иначе, но тоже может быть кастомизирован в стилистике партнера-оператора.
Нижний уровень или полевая шина — то, с чего всё начинается
Этот неясный для непосвященных набор слов используется, когда нужно описать средства общения устройств управления с подведомственным оборудованием, например, модулями ввода-вывода или измерительными устройствами.
Под устройствами управления мы подразумеваем ПЛК, т.е. программируемые логические контроллеры (англ. PLC), или ПКА, т.е. программируемые контроллеры автоматизации (англ. PAC). Между ПЛК и ПКА есть некоторые различия, однако, в рамках данной статьи они не существенны, поэтому для упрощения будем использовать общий термин «контроллер».
В русскоязычном сообществе асушников канал общения между контроллером и другими устройствами обычно называют «полевой шиной», потому что он отвечают за передачу данных, которые приходят с «поля».
«Поле» — это глубокий профессиональный термин, обозначающий тот факт, что некое оборудование (например, датчики или исполнительные механизмы), с которым взаимодействует контроллер, находятся где-то далеко-далеко, на улице, в полях, под покровом ночи. И неважно, что датчик может быть расположен в полуметре от контроллера и измерять, допустим, температуру в шкафу автоматики, все равно считается, что он находится «в поле». Чаще всего сигналы с датчиков, приходящие в модули ввода-вывода все-таки преодолевают расстояния от десятков до сотен метров (а иногда и больше), собирая информацию с удаленных площадок или оборудования. Собственно, поэтому шина обмена, по которой контроллер получает значения с этих самых датчиков, называется обычно полевой шиной или реже шиной нижнего уровня или промышленной шиной.
Тут следует отметить, что в Европе и США полевым уровнем считаются только сами устройства, расположенные «в поле», но не среда передачи данных. В российских реалиях термин «полевая шина» или «шина нижнего уровня», пожалуй, слегка размыт и обозначает способ передачи данных от модулей ввода-вывода к контроллеру и наоборот.
Общая схема автоматизации промышленного объекта
Итак, электрический сигнал от датчика проходит некое расстояние по кабельным линиям (чаще по обычному медному кабелю с некоторым количеством жил), к которым подсоединяются несколько датчиков. Затем сигнал попадает в модуль обработки (модуль ввода-вывода), там он преобразуется в понятный контроллеру цифровой язык. Далее этот сигнал по полевой шине попадает непосредственно в контроллер, где и обрабатывается уже окончательно. На основе таких сигналов и строится логика работы самого контроллера. Существует и обратный путь: от контроллера команда управления по полевой шине попадает в модуль вывода, где преобразуется из цифрового вида в аналоговый и поступает по кабельным линиям к исполнительным механизмам и различным устройствам (на схеме выше не указаны).
Пример применения: Портативный пользовательский интерфейс, интегрированная программа безопасности для управления роботами на базе ПЛК
Переносной операторский интерфейс Bosch-Rexroth VEH30 выглядит как пульт управления роботизированными системами и обеспечивает управление автопогрузчиками
Увеличение точности позиционирования, уменьшение времени цикла обработки, минимальные издержки на содержание оборудования — таковы ключевые достоинства системы Rexroth, установленной в Klocke-Robot-Systeme GmbH (Флозо, Германия). Их автоматические погрузчики и разгрузчики обслуживают загрузку формовочных машин. Система IndraMotion for Handling, дополненная функциями обеспечения безопасности работ, базируется на открытой системе управления IndraLogic, отвечающей стандартам IEC 61131-3 для обеспечения совместимости с уже установленными программными модулями. Система создает ощущение, что ее разработали для управления роботами, но в действительности является системой управления ПЛК.
IndraMotion for Handling включает в себя экранную интерактивную среду на мобильных операционных панелях, таких как мобильный операторский интерфейс Rexroth VEH30. Этот блок имеет 8,4-дюймовой сенсорный экран и функцию „горячей» замены и легко подключается через Ethernet во время работы оборудования. Одно устройство может поддерживать управление несколькими операциями. Пользователь может редактировать перемещения с помощью четырех экранных клавиш на портативном компьютере или вводить фиксированные точки через виртуальную клавиатуру. Интегрированные функции защиты в Rexroth IndraDrive, которые сертифицированы согласно EN-954-1, Категории 3, позволяют соответствовать нормам безопасности, действующим во всей Европе, без дополнительного аппаратного обеспечения.
Люди с самыми лучшими намерениями могут создавать опасные ситуации, предупреждает Джо Квиг, Вице-президент инженерной компании Systek Automated Controls (ранее технический руководитель компании International Automation). „В большинстве своем персонал систем управления не контролируется во время проведения каких-либо изменений, — комментирует Джо Квиг. — Существует проблема неполноты документации, если персонал, осуществляющий модификацию системы, не фиксирует эти изменения, то они остаются неучтенными”. Большинство работающих систем содержат аппаратную релейную логику, „и кто угодно может открыть панель управления и изменить конфигурацию системы управления по различным причинам». „Четко разработанная современная система управления, — продолжает Джо Квиг, — делится на две части: стандартные ежедневные программы управления, которые имеют открытую архитектуру, и безопасная заблокированная от изменений область, которая может привести к угрозе в случае ее изменения. Только определенные люди, знающие пароль и имеющие надлежащую квалификацию, могут фактически изменять ее”.
Функционирование современной автоматизированной системы управления (АСУ) зависит от согласованной работы ее частей. Высокое качество взаимодействия внутри программно-аппаратного комплекса обеспечивают высокопроизводительные вычислительные средства, поддерживающие открытые протоколы обмена данными, и унифицированные сигналы контроля и управления. А должный уровень связи между таким комплексом и оперативным персоналом достигается с помощью средств человеко-машинного интерфейса (Human Machine Interface, HMI). Степень важности HMI переоценить сложно: в АСУ, независимо от степени автоматизации, именно операторы играют ключевую роль. От них зависит штатное функционирование всего автоматизированного технологического комплекса и принятие важных решений.
Сегодня существует три основных способа создания HMI.
Первый и традиционный способ — это применение светосигнальной арматуры (рис. 1) в виде переключателей, кнопок, сигнальных ламп, маячков, колонн и т. д. Преимуществами такого метода являются относительно низкая стоимость реализации, высокая надежность и ремонтопригодность. Он подходит для отдельных технических агрегатов и установок (электродвигатели, насосные агрегаты, вентиляторы и т. д.), на которых реализованы несложные технологические процессы и где используются системы управления на базе релейно-контактных схем.
Рис. 1. Светосигнальная арматура
Второй способ является развитием первого. Дело в том, что для управления сложными технологическими объектами с большим количеством сигналов контроля и управления применение HMI, реализованных только на базе светосигнальной арматуры, будет неэффективным решением. Громоздкие пульты управления с множеством сигнальных ламп, переключателей, тумблеров не способствуют повышению качества взаимодействия с оперативным персоналом. Поэтому второй метод основан на применении таких технический решений, как панельные компьютеры и панели оператора (НMI-панели, рис. 2).
Рис. 2. АРМ на базе HMI-панели
Третий способ — это реализация НMI на базе автоматизированных рабочих мест (АРМ), представляющих собой персональный компьютер (ПК) с развернутой SCADA-системой (рис. 3).
Выбор того или иного способа организации HMI зависит от ряда факторов: сложности и архитектуры автоматизированной системы, целесообразности применения тех или иных технических решений и др.
Рис. 3. АРМ на базе SCADA-системы
Сохранение контроля
Несомненно, нет недостатка в лицах, желающих нанести умышленный вред. Рич Кларк, аналитик информационной безопасности (Infosec) в компании Wonderware, в презентации под названием „Руководство по обеспечению безопасности систем управления» приводит 17 вариантов, начиная с недовольного персонала до организованных преступных группировок, которые организуют умышленные вредительства по отношению к государству и правительству. Существуют объекты, которые он не описывает, „но они подвергаются преднамеренным воздействиям каждый обычный день”. С точки зрения человеко-машинного интерфейса, Гарбрехт определяет три основных сценария. „В первом случае некоторое лицо, не работающее в компании, входит через брандмауэр в производственную сеть и выполняет какие-либо манипуляции с HMI. Во втором случае некоторое лицо, работающее в компании, желает нанести умышленный вред по каким-либо причинам. В третьем сценарии некоторое лицо, работающее в компании, непреднамеренно выполняет определенные действия, которые не следует делать, допускает ошибку или нарушает безопасность системы, а так же создает другие типы проблем”. По мнению Кларка, компании могут столкнуться с неприятностями, делегируя обязанности по защите системы управления подразделению информационных технологий (ИТ). Персонал ИТ пытается обеспечить безопасность, изолируя компьютеры друг от друга, для предотвращения распространения вирусов на предприятии вследствие посещений персоналом зараженных компьютеров из других подразделений предприятия. Этот метод работает в домене ИТ, но он ограничивает связь между машинами и не совместим с работой в режиме реального времени.
Разработка HMI на базе панелей оператора
Современная HMI-панель — это специализированное микропроцессорное устройство с дисплеем, предназначенное для создания HMI. Она поставляется с предустановленными операционной системой и средой исполнения проектов пользовательского HMI. Этим панель оператора отличается от ПК и панельных промышленных компьютеров, на которые необходимо дополнительно устанавливать программные пакеты и другие приложения — как правило, платные.
Рассмотрим ключевые параметры HMI-панелей и особенности их практического применения на примере панелей оператора ТМ ONI.
Сегодня в ассортимент ТМ ONI входит шесть таких устройств: одна текстовая панель TD-MP-043 и пять сенсорных графических панелей серии ETG (рис. 5).
Рис. 5. Панели оператора ТМ ONI
Модели серии ETG оснащены микропроцессором ARM Cortex A8 с тактовой частотой 600 МГц и работают под управлением операционной системы на базе ядра Linux. Разработка проекта HMI осуществляется в программном обеспечении (ПО) ONI Visual Studio (рис. 6).
Рис. 6. Программное обеспечение ONI Visual Studio
Для текстовой панели оператора ONI TD-MP-043 предусмотрено отдельное ПО ONI TD (рис. 7).
Все программное обеспечение распространяется бесплатно и функционирует без ограничений. Актуальную версию можно скачать на сайте компании.
Рис. 7. Программное обеспечение ONI TD
Проект пользовательского HMI представляет собой набор экранов с расположенными на них графическими элементами. При помощи этих элементов осуществляются ввод и отображение информации.
Сенсорные панели оператора ONI серии ETG позволяют выводить информацию в стандартных для систем диспетчеризации формах: мнемосхемах, трендах (текущих и архивных параметров), аналитических отчетах за определенный период, журналах событий и аварий (рис. 8).
Рис. 8. Формы представления информации
Место хранения архивных данных (для их последующей обработки, анализа и вывода на экран) может определить разработчик проекта в зависимости от решаемой задачи и необходимой глубины хранения. Панели оператора ONI серии ETG позволяют хранить данные во внутренней памяти ПЗУ (ROM), но поскольку она ограничена по объему, можно использовать и внешнее запоминающее устройство USB или SD-карту памяти.
Благодаря широкому набору графических компонентов, а также возможности настройки их функций, внешнего вида, свойств и логики отображения можно создать HMI, способный удовлетворить самые разные требования. При этом реализованный в ONI Visual Studio функционал не требует от разработчика специальных навыков программирования.
Порядок разработки проекта можно описать как следующую последовательность шагов:
-
Создание нового проекта в ONI Visual Studio (рис. 9).
Рис. 9. Окно создания проекта HMI
Рис. 10. Окно настройки коммуникационных портов
Рис. 11. Менеджер окон
Рис. 12. Пример пользовательского интерфейса
В зависимости от своей функции графический элемент может отображать или передавать данные. Работа на данном этапе является очень кропотливой и требует большой концентрации внимания от разработчика. Облегчить процесс может инструмент «Библиотека адресных меток» в ONI Visual Studio. Он позволяет предварительно присвоить текстовые метки (tag name) всем адресам памяти внешнего устройства (рис. 13) и впоследствии работать уже с ними, а не с самими адресами.
Рис. 13. Библиотека адресных меток
Как было указано выше, в ONI Visual Studio доступен большой набор инструментов по созданию пользовательского интерфейса: готовые графические элементы, векторные примитивы для рисования, а также загрузка своих рисунков. Библиотеку графических элементов разработчик может пополнять собственными элементами (рис. 14).
Рис. 14. Библиотека графических элементов
Для предварительной отладки НMI можно воспользоваться инструментом «Моделирование в симуляторе», позволяющим скомпилировать и запустить проект на ПК без физического соединения с внешним устройством.
Практически любую задачу, связанную с получением, хранением, отображением и передачей данных в HMI-панели, можно решить стандартными инструментами ONI Visual Studio. Если этого функционала не хватает, можно воспользоваться инструментом «Макрос» — он позволяет решать нестандартные задачи с помощью встроенного языка программирования С (рис. 15).
Рис. 15. Окно создания макроса
Интерфейс ПО ONI Visual Studio полностью русифицирован и интуитивно понятен. Для того чтобы освоить и начать создавать простые HMI-проекты в ONI Visual Studio, в среднем требуется один день.
Читайте также: