Русский
Русский
English
Статистика
Реклама

Scada

Автоматизация и промышленная электроника когда одним Arduino сыт не будешь

19.05.2021 12:19:31 | Автор: admin
Если играться с контроллерами, то почему с маленькими?

Очень часто, когда речь заходит об автоматизации чего-либо, то в разговоре всплывает Arduino, его производные или же Raspberry PI и прочие одноплатники. Но есть отличие от домашних поделок, где можно пользоваться чем угодно ради экономии и потому, что это простое и доступное решение. В сфере автоматизации/модернизации объектов, связанных с промышленностью, речь идёт исключительно о специализированных промышленных контроллерах и системах визуализации, диспетчеризации/удалённого управления и все это исключительно с сертификатами соответствия и лицензиями.
Решений такого класса море и порой сложно в них разобраться. Разумеется, все возможные варианты разобрать невозможно, но мы с коллегами уже несколько лет работаем в этой сфере и потому какое-то количество опыта набралось. Мы поделимся своим и если вам есть, что сказать просим писать комментарии.

Попробуем разложить по порядку, как же происходит пресловутая автоматизация/модернизация. Всего есть несколько стадий от задумки до реализации проекта. Работает над ней несколько разных человек, желательно чтобы они были из одной компании, либо имели возможность постоянно общаться с друг другом и вносить коррективы. В отличии от простого программирования, которое в нашей сфере выглядит неким сферическим конём в вакууме, приходится предусмотреть огромное количество нюансов и на каждой стадии может случиться прокол, который ведёт к материальным потерям.

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

Самая маленькая команда должна включать в себя:

  • проектанта
  • опытного инженера в области промышленной электроники
  • электромонтеров/электромехаников
  • программиста

Если же компания постоянно развивается и работает в этой области, то она неуклонно растёт, так как несколько объектов делается одновременно и все они находятся на разной стадии.

Стадия подготовки к тендеру


О начале тендера, на выполнение чего-то, мы не всегда узнаем заранее. Иногда информация запаздывает, тендер ожидается на днях, или долго шли подготовительные работы, чтобы принять участие. Но это не меняет сути: нужно посчитать стоимость автоматизации объекта, к примеру. Сначала изучается планируемый объем и срок работ (если, конечно, сроки внятно прописаны) и принимается решение о выполнимости своими силами, либо с привлечением подрядчиков.
Часто в нагрузку к системам автоматики докидывают смежные (в понимании заказчика/инвестора) вещи. Нам постоянно навязывают обычную электрику, вплоть до внешнего освещения, локальные сети и телефонные линии в промышленных и административных помещениях, электрические сети низкого напряжения и понижающие трансформаторные подстанции. И вот хотелось бы иметь только автоматику в чистом виде, да нет её. Так как для инвесторов, что электроника, что электрика одного поля ягоды. Попутно нужно понимать, что компания, занимающаяся автоматизацией, заканчивает объект последней. Именно она будет связывать воедино разрозненные структуры пожарные системы, контроли доступа, видео наблюдение, связь с серверной и оптическими линиями, диспетчеризацию и удалённый доступ. Если же технологический процесс объекта содержит в себе независимые самоуправляемые системы или машины (автоматические линии, вентиляционные централи, сигнализацию, запасной генератор, солнечные панели и преобразователи к ним и т.д.), то задача усложняется ещё и необходимостью соединить между собой оборудование разных производителей, порой с совсем разными протоколами промышленной связи.
Вооружившись знаниями за все предыдущие годы и выполненные объекты, можно попробовать посчитать общую себестоимость работ (включая материалы, покупку оборудования, количество человеко-часов, стоимость всех выездов на объект для проведения монтажа, пуско-наладки и последующих сервисных выездов в течении гарантийных 5-7 лет).
Q: На основании чего производится расчёт?
Пожеланий инвестора и приблизительных догадок об общем бюджете объекта. Всегда можно воспользоваться открытой информацией. Оттуда можно выудить сколько процентов от общей суммы пойдёт на данную сферу. Грубо говоря, если объект будет стоить 10 млн евро, то системы автоматизации плюс электрика это около 1,5-2 млн.
Хорошо, когда есть возможность пообщаться с генеральным подрядчиком, который координирует весь ход работ, от выравнивания территории под фундаменты и дороги, до капитального строительства и озеленения территории. Всегда есть кто-то, кто пытается, не выходя за рамки первичного бюджета, построить объект и сдать его срок. Не завидуем им совсем, но пытаемся сотрудничать на всех этапах реализации. Это действительно упрощает жизнь в дальнейшем.
Итак, получаем информацию от генерального подрядчика, что общая квота от этого бюджета на автоматику и электрику не сможет превысить тех же 2 млн. Теперь начинается самое интересное в тендере участвует минимум 3 компании на каждую сферу работ. А значит мы встретимся ещё, как минимум, с двумя предложениями от других компаний, что претендуют выполнить этот же объем работ, что и мы. Нужно предложить на тендере сумму меньше них (а мы, разумеется не знаем сколько они заявят), ну и не остаться без прибыли, тем более не уйти в минус.
Q: Что мы используем и почему?
Зависит от возможностей оборудования и пожеланий заказчика. Из контроллеров это Siemens s1200-s1500 и его аналоги. Панели к ним Weintek и Astraada. Реле, пускатели, клеммные колодки Eaton и т.д. Частотных преобразователи Danfoss, Mitsubishi, LS IS. Коммуникация Modbus RTU, Modbus TCP, Ethernet, Profibus и оптика. Подробнее о подборе оборудования будет в следующей статье относительно проектирования.

Пример просчёта при участии в тендере. Подрядчики не увидели в ТЗ постройку кабельной линии, установку кабельных колодцев и подключение к действующей сети. Теперь, когда все солнечные панели смонтированы, им предстоит вручную копать трассы и укладывать кабеля и монтировать кабельные колодцы. Это фиаско. Но ничего не сделать контракт уже заключён.

Сначала изучается ТЗ.Как известно без внятного ТЗ получается непонятно что. Инвестор не будет пояснять расплывчатые формулировки и нужно готовиться ко всему. Подводные камни ждут в каждом предложении и нужно уметь их находить. К примеру, если пишется, что необходимо выполнить систему автоматизации и удалённого управления с возможностью работы при кратковременных пропаданиях питания от сети, то это означает, что всего лишь необходимо доложить по одному блоку бесперебойного питания либо аккумуляторы в каждых шкаф управления техпроцессом и обычный UPS, через который запитана серверная стойка или компьютер диспетчера с системой управления. Задача поддержать работу всех контролёров, во всех шкафах управления и всех роутеров и модемов, чтобы собрать все статусы ошибок различных устройств, автоматических линий и машин, записать все это в логи и передать на сервер/компьютер с системой удалённого управления, который через SMS-шлюз сообщит наружу подготовленному списку номеров, что пропало напряжение сети и все оборудование остановилось.
Как можно понять из требований, это достаточно недорогое удовольствие обойдётся в несколько сотен евро, и его легко учесть на стадии проектирования. Однако формулировка может быть несколько иной выполнить систему автоматизации с возможностью продолжения работы объекта при пропадании питания от сети, до момента её появления. И вот это уже совсем другое. Здесь хотят иметь либо вторую линию резервного питания со своим понижающим трансформатором и шкаф автоматического переключения нагрузки с одного источника питания на другой с анализаторами параметров сети. Либо, что встречается гораздо чаще заказчик хочет иметь резервный источник питания в виде дизельного генератора, который сможет поддержать работу объекта в течении нескольких часов. Подобные генераторы стоят десятки тысяч евро. И не забываем про шкаф переключения нагрузки, благо в большинстве случаев современные дизельные генераторы имеют свои неплохие контроллеры с внешним LCD экраном и возможностью отслеживания параметров сети сразу по нескольким параметрам и управлением силовыми контакторами, что переключают нагрузку от одного источника (сети) на другой (генератор) и наоборот при восстановлении нормальной работы первичного источника.
К примеру, генераторы фирмы FOGO, Elem Power или их аналоги, с контроллером, к примеру, datacom-d500-lite или inteli lite amf 25. Тут шкаф переключения нагрузки (AVR) будет состоять всего из 2х силовых контакторов с дополнительными контактами, чтобы снимать состояние, какой из них включён и сделать их одновременно включение взаимоисключающим.

Фото панели управления генератором

После прочтения ТЗ все обычные работы:прокладка кабельных трасс, монтаж кабельных лотков, монтаж наружного освещения, заземления, громоотвода и молниезащиты (если есть в требованиях), изготовление шкафов управления (их мы делаем сами), всё калькулируется по нормам. В нашем случае эти нормы европейские. Потом прикидывается общая стоимость всех возможных шкафов управления с их наполнением в виде контроллеров и их обвязки, частотных преобразователей или устройств плавного пуска, серверных стоек, компьютеров и телевизоров (это относительная новинка, так как стали отказываться от синоптических таблиц и предпочитают иметь выведенную систему визуализации техпроцесса на 4-6 телевизоров по 50-55", склеенных в мульти-экран), считается за сколько рабоче-часов будет изготовлено, смонтировано. Сюда же добавляется прибыль. Есть несколько быстрых шаблонов по подсчёту стоимости к примеру, в конечную стоимость одного шкафа управления, включена оплата работы проектанта, стоимость сборки шкафа и стоимость программирования контроллера и панели HMI. Чтобы быстро считать многие вещи упрощаются. Итоговая стоимость шкафа управления будет = себестоимость всех компонентов * 1,5(2). Разумеется, сам по себе шкаф ничего не делает. Его ещё нужно привезти на объект, смонтировать на своём месте, проложить к нему кабельные линии и трассы, уложить питающие и управляющие кабеля, подключить это все и запустить. Приблизительно можно подсчитать общую длину будущих кабельных линий, учесть проколы под дорогами (это дорого), посмотреть требования к силовым линиям (медные или алюминиевые), подумать на счёт трансформаторной подстанции и генератора. Многие вещи сразу умножаются на 2, чтобы избежать нехватки средств в будущем. К примеру, тот же генератор весит 3-5 тонн. Значит нужно организовать выгрузку с помощью крана и прочный фундамент, соответственно ещё и заземление. Внимательно изучаются расположения разных технологических зданий внутри объекта. По современным нормам уже никто не хочет связывать отдалённые здания витой парой хоть 5й, хоть 6й категории. Только оптика, только хардкор. Считаем и стоимость укладки, сварки оптики и оборудования для соединения между собой разных зданий. Внутри зданий и на малых расстояниях, для экономии, используем utp категории 5е/6e.

Готовый шкаф управления. Запуск ещё идёт, но большая часть техпроцесса уже налажена

После того, как мы все посчитали, оказывается что мы как обычно не вписываемся в ожидаемые рамки бюджета. В ход идут оптовые закупки оборудования напрямую у производителя и соответственно скидки за многолетнюю лояльность. Иногда скидки могут достигать десятков процентов. Это ничего не значит, если вы покупаете на объект 1 контроллер за тысячу евро и один частотный преобразователь за пару сотен. Но когда суммарно на объекте несколько десятков частотных преобразователей, несколько контроллеров и несколько шкафов, то экономия получается порядочной. Это наша подушка безопасности. Если что-то упущено на стадии подготовки к тендеру, то мы используем сэкономленные средства на это. Если же все хорошо, то это плюс к нашей прибыли. В конечном счёте, никто из нас не альтруист и все мы здесь за этим. Хотя есть ещё и моральное удовольствие от хорошо выполненной работы. Но это уже невозможно посчитать)

Фото запущенного объекта на память)

Вот, пожалуй, и все, что можно в нескольких словах сказать о подготовке к тендеру и подводных камнях на этом этапе. Большие объекты, вроде Amazon, Volkswagen, АЭС (да, в нашей практике и такое было) строятся не быстро, но и бюджеты отнюдь не маленькие.
В одной статье описать все стадии автоматизации невозможно, далее планирую затронуть стадии проектирования, программирования и запуска оборудования. Пожалуй, больше всего интересного происходит во время запуска. Именно там встречается масса проблем и находятся решения.


Подробнее..

Возможные способы организации атак на киберфизические системы

28.12.2020 12:07:24 | Автор: admin

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

История инцидентов киберфизической безопасности

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

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

До недавнего времени опасные для жизни системные сбои в секторе здравоохранения были вопросом техники безопасности. Например, отказы компьютеризированных аппаратов лучевой терапии Therac-25, которые привели к четырем смертям в 1980-х годах, были результатом плохого проектирование программного обеспечения. Его разработчики не дублировали в программном обеспечении все механизмы безопасности, которые предыдущие менее компьютеризированные версии машины обеспечивали в аппаратном обеспечении. В результате несколько раз аппарат выходил из строя и доставлял пациентам смертельные дозы радиации. В течение следующих двух десятилетий киберфизические инциденты в секторе здравоохранения по-прежнему были результатом ошибок в программном обеспечении или неправильной конфигурации медицинского оборудования, а не преднамеренных атак.

Первый заметный инцидент в водном секторе произошел в 1994 году, когда хакер с помощью коммутируемого модема получил доступ к компьютерной сети проекта Солт-Ривер в Аризоне. Вторжение включало по меньшей мере один 5-часовой сеанс, где хакер имел доступ к данным мониторинга воды и электроэнергии. Этот инцидент часто неправильно сообщают и связывают с предполагаемым инцидентом взлома плотины Рузвельта в Аризоне, но расследование пришло к выводу, что не было никакой угрозы для каких-либо плотин, и вообще не было никаких признаков какого-либо намерения, кроме хвастовства или удовлетворения, которое дает успешный взлом. Согласно отчету Национальной лаборатории штата Айдахо, преступник был профильным хакером, который считал, что он имеет право добиваться своей интеллектуальной свободы посредством своей хакерской деятельности.

В 1998 году подросток из Массачусетса стал первым несовершеннолетним в Соединенных Штатах, которому в Федеральном суде было предъявлено обвинение в хакерстве. Годом ранее он ворвался в сеть телефонной компании и вызвал аварию, которая вывела из строя системы Digital loop carrier (DLC) в региональном аэропорту Вустера. Эти системы используются для интеграции передачи голоса и данных с нескольких телефонных линий для цифровой передачи по одному кабелю высокой емкости. Это намного эффективнее, чем иметь сотни линий из каждой части инфраструктуры аэропорта отдельно подключен к диспетчерской вышке, но если DLC отключен, то все связанные с ним коммуникации тоже отключены. Конкретные DLC были доступны для внешних модемов, так что технические специалисты компании могли поддерживать обслуживание удаленно. Подросток определил их телефонные номера и подключился к ним с помощью модема своего персонального компьютера. Затем он отключил передатчик, отвечающий за включение огней взлетно-посадочной полосы, а также связь с диспетчерской вышкой, пожарной службой, Службой безопасности аэропорта и метеорологической службой в течение 6 часов. Хотя отключение не вызвало каких-либо серьезных проблем, Секретная служба США рассматривала инцидент как вопрос национальной безопасности.

В 1999 году трубопровод в Беллингхеме, штат Вашингтон, разорвался из-за замедления системы SCADA, управляющей им [1]. До этого подрядчик нанес внешнее повреждение трубопроводу, устанавливая поперек него водопроводные линии. Из-за этого повреждения и неправильной конфигурации некоторых недавно установленных клапанов давление начало расти. Обычно это обнаруживалось и смягчалось с помощью системы SCADA, но последняя перестала реагировать. Хотя он был настроен на сбор последних данных от удаленных терминальных блоков (RTU) каждые несколько секунд, HMI оператора не будет отображать обновление в течение нескольких минут. Более позднее расследование показало, что в то время системный администратор программировал новые программы. Отчеты по базе данных системы SCADA без предварительного тестирования их в автономном режиме. Еще одна ошибка заключалась в том, что для всех пользователей существовала одна учетная запись входа, и это была учетная запись администратора с настройкой приоритета, которая позволяла назначать ей все доступные вычислительные ресурсы. В результате ошибка программирования может не только непосредственно повлиять на работу системы SCADA, но и поглотить все ее ресурсы. Поскольку он не реагировал, контроллеры не могли управлять насосами удаленно, чтобы вовремя смягчить воздействие повышения давления. Последовавшее за этим возгорание бензина привело к гибели трех человек и нанесло значительный ущерб окружающей среде.

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

В 2000 году произошел подтвержденный инцидент в Австралии, явно связанный со злым умыслом. Сегодня он известен как атака Маручи. Район природной красоты с несколькими водными каналами, парками и примерно 120 000 жителей. В 2000 году его совет только недавно установил комплексную SCADA-инфраструктуру для управления своими 880 километрами канализационных коллекторов и 142 насосными станциями, когда его инженеры начали замечать необычное поведение. О неисправностях оборудования не всегда сообщали вовремя, насосы не реагировали на удаленные команды, а связь с центральным управлением часто терялась. Поначалу считалось, что это временные проблемы новой инфраструктуры, но постепенно она стала разрушаться. Стало очевидно, что здесь, должно быть, есть какое-то человеческое участие. Даже после того, как все программное обеспечение было переустановлено, конфигурация насосов неожиданно менялась таким образом, который мог быть приписан только человеку-пользователю. Подозрения подтвердились, когда инженер, вызванный для расследования, обнаружил неизвестное беспроводное оборудование, подключенное к системе.

Инженер пришел к выводу, что пользователь подключается к насосы с ноутбуком, быстро перемещающиеся от станции к станции. Нападения продолжались два с половиной месяца, пока полиция не остановила мужчину за нарушение правил дорожного движения возле одной из насосных станций и не арестовала его после того, как в его автомобиле было обнаружено подозрительное компьютерное и радиосвязное оборудование. Задержанным оказался Витэк Боден, ранее работавший внештатным подрядчиком в качестве начальника участка по монтажу коммуникационной инфраструктуры проекта Maroochi SCADA. Уйдя в отставку с этого поста, Боден искал работу в Совете графства Маручи, но ему дважды отказывали. Именно тогда начали наблюдать необычное поведение SCADA системы. Имея специальные знания и опыт работы с внешним подрядчиком, Витэк Боден был инсайдером. Он имел доступ к специализированному программному обеспечению, используемому для управления насосами, знал, как подключиться к насосным станциям, и хорошо понимал процедуры, связанные с управлением сточными водами на основе SCADA.Основываясь главным образом на доказательствах, найденных в его ноутбуке, он был приговорен к 2 годам тюремного заключения за то, что вызвал выброс 800 000 литров неочищенных сточных вод в парки, общественные водные пути и территорию отеля.

Исключением стал необычный случай порчи веб-сайта некоммерческого фонда по борьбе с эпилепсией в 2008 году. Хакеры заменили часть контента веб-сайта мигающими анимациями, выбранными для того, чтобы вызвать мигрень или припадок у посетителей, страдающих эпилепсией. По крайней мере, некоторые из посетителей действительно пострадали. Этот инцидент имеет большое значение для демонстрации возможности захвата веб-сайта таким образом, что он может физически повлиять на человека.

Ещё одна авария Сан-Бруно, Калифорния, в 2010 году. Взрыв трубопровода природного газа, в результате которого погибли восемь человек и еще 60 получили ранения, также частично объяснялся ошибочными и недоступными показаниями давления SCADA. Сбой питания привел к ошибочному сообщению значений низкого давления, что в свою очередь привело к полному открытию регулирующих клапанов и повышению давления в трубопроводе.Системы управления также могут быть затронуты вредоносными программами, и таких примеров в энергетическом секторе предостаточно.

Киберфизические атаки на промышленные системы управления

Наиболее часто обсуждаемыми угрозами для промышленных систем управления таких систем и связанных с угрозами безопасности (первый раздел, SCADA-системы), самое главное реальный пример на сегодняшний день (Следующий раздел, "Стакснет"), и целевой, который повсеместно рассматривается как Святой Грааль, спонсируемые государством, нападения (в последнем разделе, электрической сети).

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

С тех пор системы SCADA приняли распределенную архитектуру (второе поколение, рисунок 2), включающую несколько серверов, каждый из которых отвечает за свой аспект системы. Переход от проприетарных протоколов конкретных производителей к открытым протоколам, которые позволяют использовать компоненты COTS(готовые аппаратные и программные технологии открытого типа) способствует смене архитектуры (третье поколение, рисунок 1). Связь системы посредством локальных сетей позволило работать на больших географических территориях и в разнообразных сетевых инфраструктурах, включая глобальные сети и Интернет. В четвертом поколении (рисунок 1) систем SCADA делается упор на взаимосвязанность и взаимодействие различных технологий. Для контроля отображается полноценная сетевая среда устройств, отправляющие отчеты напрямую через Интернет и без необходимости в RTU и человеко-машинных интерфейсах (HMI), которые не ограничены центральным местом, но доступны из любого места через мобильные устройства

Рисунок 1 - Поколения SCADA и их архитектура

Этапы киберфизической атаки

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

Исследование - предварительный этап атаки, во время которого пытаемся узнать полезную информацию о цели. Это может быть IP-адреса, топология сетевой инфраструктуры, типы и версии используемого программного и аппаратного обеспечения и т. д. Обычно это начинается с поиска любой общедоступной информации о цели в Интернете.

Источники информации:

  • сайт поставщиков ПО или оборудования поможет узнать оборудование, используемое в киберфизических системах организации;

  • объявления о вакансиях могут раскрыть программное обеспечение, оборудование и сетевые технологии, используемые при листинге желаемые навыки и опыт, ожидаемые от претендентов;

  • инструкции по установке веб-сайте компании, которые могут включать имена пользователей и пароли по умолчанию, которые часто остаются неизменными операторами.

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

Социальная инженерия - распространенный механизм разведка киберфизических систем и особенно промышленных системы пробного контроля. Даже самые сильные технические средства защиты могут быть обойдены, если пользователя системы заставить ввести пароли или нажать вредоносную web-ссылку. Конфиденциальную информацию содержат выбрасываемые в мусор ненужные банковские выписки, USB-накопители, черновики проектных предложений, письма и другие материалы (метод dumpster diving). Крайняя форма dumpster diving - это покупка утилизированных копировальных аппаратов организации, чтобы получить их внутренние жесткие диски[2]. Их владельцы часто не протирают их, хотя они содержат отсканированные документы за многие годы.

Социальная инженерия может быть нетехнической. Это может начаться с поддельного удостоверения личности или простой телефонный звонок. Можно представиться представителем из отдела поддержки, поставщика программного обеспечения или назвать коллегу или авторитетного лица.

В последнее время социальная инженерия становится все более техническим и предполагает использование человеко-машинный интерфейс. К инженеру киберфизической системы отправляется поддельное электронное письмом от лица финансового отдела с просьбой проверить приложенный файл к письму. Письмо составлено так что не вызывает подозрения, но вложенный документ может быть запрограммирован на запись нажатия клавиш инженера или, возможно, разрешение удаленного доступа к киберфизической системе. Этот тип атаки известен как Fishing.

Watering Hole - стратегия атаки, при которой злоумышленник наблюдает или угадывает какой веб-сайт посещает конкретная цель часто, а затем внедряет вредоносное ПО на этот веб-сайт [3]. Последствие: несанкционированное получение важной информации, включая учетные данные для входа / пароля, а также передача вредоносного ПО, которое облегчит атаку.

После получения некоторой предварительной информации о цели,злоумышленник пытается расширить эту информацию путем сканирования на предмет конкретных уязвимостей. Три самых популярных инструмента для сканирования сети используются Nmap [4], Несс [5] и Wireshark [6]. В совокупности они могут определить работающую операционную систему у цели, прослушивать сетевой трафик и сканировать на предмет открытых сетевые портов, неправильная конфигурация, пароли по умолчанию и т.п..

Всем пользователям известны такие поисковые системы как Google, Яндекс, Рамблер, Yahoo, Bing и можно перечислять еще множество как отечественных, так и зарубежных поисковиков. Такие поисковые службы ищут в сети веб-страницы, картинки, видео, документы и новости. Но в узких кругах, например служб специализирующихся на разведке, кибербезопасности и кибератаках пользуются Shodan.

В основе Shodan лежит поисковый робот, который накапливает технические сведения обо всех узлах сети, откликнувшихся хотя бы на один запрос. Персональные компьютеры и мобильные гаджеты конечных пользователей обычно маскирует файрвол, поэтому гораздо чаще в поле зрения Shodan попадают всевозможные сетевые устройства, формирующие так называемый интернет вещей. Поисковик Shodan позволяет заглянуть в скрытый от глаз мир интернета вещей. С его помощью можно увидеть малоизученную сторону глобальной сети, понять ее структуру, обнаружить уязвимые места и провести множество других практических исследований [7].

Через сканирование уязвимостей злоумышленник может узнать о потенциальных уязвимостях целевой системы. В отличие от обычных компьютерных систем, где опубликованные уязвимости исправляются с помощью регулярных обновлений, уязвимости в промышленных системах управления и встроенных системах могут оставаться не обновленными в течение длительного времени.

Глушение связи (communication jamming)

Преднамеренное создание помех, затрудняющих прием сигнала. В простейшей форме, когда пользователь A общается с пользователем B по беспроводному каналу, злоумышленник должен находиться поблизости от A или B и передавать достаточно сильный беспроводной сигнал в том же диапазоне частот. Глушители беспроводного сигнала. недорогие и относительно простые в использовании. Блокирование может быть проактивным, и в этом случае злоумышленник блокирует беспроводной канал непрерывно, или реактивным, и в этом случае злоумышленник перехватывает беспроводной канал и блокирует его только при обнаружении законной связи. Данный метод нарушает связь, которое, в свою очередь, может повлиять на физический процесс. Происходит задержка или предотвращение срабатывания физических процессов, требующих беспроводной связи. В зависимости от конструкции системы также возможно неправильное / несанкционированное срабатывание. Например, потеря беспроводной связи с центром управления может вызвать автоматическое действие, такое как переход БПЛА в режим возврата на базу.

Подача команд (command injection)

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

Ввод ложных данных (false data injection)

False data injection - интеллектуальная сеть и в целом любая киберфизическая система, которая полагается на данные датчиков, полученные через уязвимый канал связи. Злоумышленник взламывает канал связи, используемый для сообщения измерений датчиков, блокирует правильные и вместо этого передает ложные данные. Если связь осуществляется по сети, злоумышленник может добиться этого, взяв промежуточный узел, используемый для передачи данных в центр управления. Киберсистемам нарушает целостность данных, вызывающее неправильное срабатывание физического оборудования.

Атака посредника (man-in-the-middle)

Противник соединяется независимо с двумя компьютерами с целью ретрансляции любых отправленных сообщений между ними. Два компьютера считают, что они общаются напрямую и конфиденциально, но в действительности противник может активно подслушивать их общение и вводить или управлять сообщениями (Рисунок 2).Обычный подход состоит в том, чтобы сначала взломать существующий узел или подключить мошеннический узел к сети целевых компьютеров, а затем использовать слабые места используемого механизма коммуникации. Самый простой и один из наиболее эффективных методов является протокол разрешения адресов (ARP), при котором злоумышленник рассылает ложные ответы на запросы ARP о физическом адресе легитимного узла, заставляя другие узлы в сети полагать, что он имеет адрес мошеннический узел. Данный метод нацелен на нарушение конфиденциальности, подлинности и целостности. По сути, неавторизованный пользователь маскируется под авторизованный. Нарушение доступности также возможно, если злоумышленник выборочно отбрасывает сообщения, которыми обмениваются два компьютера. Возможны все формы физического воздействия.

Рисунок 2 - Атака типа "man-in-the-middle"

Повторная атака (replay attack)

Противник наблюдает и записывает коммуникационную последовательность, чтобы воспроизвести ее позже. При воспроизведении сообщений, содержащих измерения датчиков, это атака обмана, которая влияет на актуальность данных, от которых зависит киберфизическая система. Stuxnet широко использовал такую атаку, чтобы не дать диспетчерам ядерной установки замечать аномальное состояние системы. Если воспроизводится коммуникация, содержащая управляющие команды, такие как close the valve, deliver insulin, unlock the door, повторная атака эффективно позволяет управлять исполнительными механизмами киберфизической системы без необходимости полного понимания того, как каждый сетевой пакет и каждая команда структурирована, в этом и заключается большое преимущество. Это не требует детального знания внутренней работы целевой системы; только наблюдение, что за определенной коммуникационной последовательностью следует конкретное действие. Его недостатком является то, что он не может производить измерение датчика или команду управления, которая не была передана и захвачена ранее.

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

Внедрение кода / модификация прошивки (Code injection/firmware modification)

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

Злоумышленник расширяет предполагаемую работу компьютерной программы, вводя дополнительные инструкции в ее код со злым умыслом. Самая известная атака с внедрением кода - это SQL-инъекция, которая использует типичные недостатки проектирования веб-сайтов, управляемых базами данных, для обеспечения неограниченного доступа к базе данных. Поскольку промышленные сети управления во многом полагаются на базы данных и часто имеют доступ к Интернету, защита от внедрения кода SQL имеет большое значение.

Атака несёт нарушение конфиденциальности и целостности. Для хорошо известных атак путем внедрения кода наиболее эффективной защитой является устранение уязвимостей путем исправления соответствующих недостатков конструкции.

Заражение вредоносным ПО (malware infection)

Термин вредоносное ПО используется совместно для обозначения вирусов, логических бомб, червей, троянских коней, руткитов,регистраторов ключей и любого другого программного обеспечения, которое выполняет намеренно вредоносные намерения злоумышленника [8], например несанкционированный доступ, повреждение или нарушение работы системы и кража данных.

Вирусы - это программы-паразиты, которые заражают другие программы вредоносным кодом и активируются только тогда, когда пользователи запускают эти зараженные хост-программы. Они также распространяются только в результате действий человека (например, прикрепляются к электронному письму, передаются по сети, переносятся на USB-накопитель и т. д.).

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

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

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

Сеть ботов (botnet), который они затем могут сдать в аренду другим киберпреступникам. Сеть ботов из примерно 10 000 ботов, которого достаточно, чтобы нарушить работу крупного веб-сайта с помощью атаки типа DoS, можно арендовать всего за 200 долларов в день. [9]

Руткиты - это наборы программных инструментов, которые в основном направлены на сокрытие присутствия злоумышленника, который уже взломал систему.

Помимо того, что Stuxnet был первым червем, специально разработанным для сети SCADA, он также нес первый руткит, специально разработанный для ПЛК. Регистраторы ключей записывают нажатия клавиш на компьютерах, на которых они установлены.

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

Все вышесказанное - вредоносные программы настроены на нарушение целостности системы с последующим потенциальным нарушением всех других свойств в зависимости от типа вредоносного ПО.

Отказ в обслуживании (denial of service)

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

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

К 2013 году самая крупная атака уже достигла 400 Гбит / с. Чтобы скрыть свою личность и затруднить защиту, злоумышленники обычно подделывают свой исходный адрес, указывая поддельный адрес в заголовках сетевых пакетов атаки. Как правило, получателю очень сложно установить истинный источник поддельного сетевого пакета. Это становится еще более трудным при атаке отражения, когда боты не отправляют трафик прямо к своей цели. Вместо этого они отправляют запросы на подключение легитимным компьютерам.

Атака DoS увеличивает нагрузки сети , приводящее к потере доступности сети. Как правило, это задерживает или полностью предотвращает срабатывание, нарушая передачу инструкций исполнительным механизмам или данных, собранных с датчиков. Задержки связи с датчиками также могут косвенно вызвать неправильное срабатывание, поскольку это будет основано на старых данных датчика.

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

Глушение GPS (GPS Jamming)

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

Чёрная дыра (black hole)

Тип атаки на интеллектуальную сеть. Вместо того, чтобы наводнять сеть большими объемами трафика, злоумышленник может повлиять на доступность данных, скомпрометировав сетевой узел и просто отбросив любые сетевые пакеты, проходящие через него. Если в результате атаки отбрасываются все пакеты, это называется атакой черная дыра. Во многих случаях может быть предпочтительнее отбрасывать пакеты выборочно, а не все, возможно, чтобы избежать обнаружения. Это известно как атака серая дыры. Например, рассмотрим сеть SCADA, в которой работает протокол DNP3. Кибервоздействие - нарушение целостности сетевой системы на скомпрометированных узлах и потеря доступности сети. Физическое воздействие - аналогично атаке отказа в обслуживании. Задержка или полная невозможность срабатывания из-за нарушения передачи инструкций исполнительным механизмам или данных, собранных с датчиков. Опять же, задержки связи с датчиками также могут косвенно вызвать неправильное срабатывание, потому что это будет основано на старых данных датчика. Сложность: умеренная защита: механизмы аутентификации, системы обнаружения вторжений, резервирование сети с разнообразием.

Мошеннический узел (Rogue Node)

Тип атаки на интеллектуальную сеть, автомобильные сети, домашную автоматизаци. и другие сети контроллеров или датчиков. Используя совместимое проводное или беспроводное оборудование, злоумышленник вводит мошенническое устройство в сеть, представляющуюся законным узлом. В случае автомобиля это можно сделать, физически подключившись к порту OBD (порт компьютерной диагностики автомобиля). Узел-мошенник может читать все сообщения в сети и генерировать свои собственные сообщения, включая команды для исполнительных механизмов. Атака нарушает целостность системы. Введение мошеннического узла - это предварительный шаг, который упрощает другие атаки, такие как DoS, атака посредником, внедрение команд, перехват пакетов и т. д.

Изоляция сети (Network Isolation)

Сложный тип атак на крупномасштабные киберфизические системы, такие как интеллектуальные сети и системы управления светофорами. Атака направлена на изоляцию определенной физической географической области от сети [10]. Никакого особого подхода не требуется, но один из способов достижения этого - компрометация сетевых узлов, которые окружают целевую область, выборочное отбрасывание или задержка сетевых пакетов от них и к ним. На практике это скоординированная атака черная дыра, при которой цели выбираются в зависимости от физического географического района, который они обслуживают. Злоумышленник должен хорошо знать географическое покрытие сети и координировать атаки на большое количество сетевых узлов. Это потенциальная угроза для интеллектуальной сети, поскольку сильное воздействие может оправдать вложения злоумышленника в детальную разведку сети и выявление уязвимостей, которые могут потребоваться. Атака вызывает нарушение целостности сетевой системы на скомпрометированных узлах и потеря доступности сети. Физическое воздействие атаки то же, что и атака черная дыра, но сосредоточено на датчиках и исполнительных механизмах конкретной географической области

Рассмотрим точки входа для атак на разные системы (таблица 1). Точки входа для атак на системы умного дома описаны в таблице 2.

Таблица 1 - Точки входа для атак систем SCADA

Описание точки входа

Вероятные атаки

Радиосвязь между RTU/PLC и датчики/исполнительные механизмы

Глушение связи, подача команд,ввод ложных данных

RTU / PLC и связь с серверами SCADA

Внедрение кода / модификация прошивки, заражение вредоносным ПО, отказ в обслуживании, глушение, повторная атака, внедрение команды, введение ложных данных, черная дыра / серая дыра, изоляция сети, мошеннический узел

Сеть управления, включая серверы SCADA и рабочие места инженеров

Заражение вредоносным ПО, отказ в обслуживании, посредник

Коммуникационный шлюз / канал между системой управления и корпоративной сетью (например, соединение между первичным и вторичным архиватором)

Отказ в обслуживании, введение ложных данных (на основе базы данных)

Корпоративная сеть

Заражение вредоносным ПО, социальная инженерия

Интернет и сети партнеров

Веб-атаки (вредоносное ПО, SQL-инъекции и т. д.), Социальная инженерия

Таблица 2 - Точки входа для атак на системы умного дома

Описание точки входа

Вероятные атаки

Сеть Wi-Fi и маршрутизатор Wi-Fi

Взлом паролей для Wi-Fi роутера, сниффинг пакетов, отказ в обслуживании, мошеннический узел, глушение связи

Приложение для смартфона или ПК для управления через Интернет

Взлом паролей приложений для смартфонов или ПК, вредоносное ПО на смартфоне или ПК

Stuxnet

Хотя компьютерные системы SCADA широко использовались для удаленного мониторинга и управления оборудованием с 1960-х годов, только в последние годы их киберугрозы привлекли значительное внимание. Исследователи склонны сосредотачиваться на конкретных уязвимостях, вносимых Modbus, DNP3 и другими протоколами связи промышленного управления, большинство из которых изначально были разработаны для простоты и эффективности, а не безопасности. Тем не менее, на практике наиболее часто используемые уязвимости имеют мало общего с конкретными протоколами и в значительной степени такие же, как и в обычных компьютерных системах, начиная от программных ошибок и заканчивая неправильными паролями. Разница заключается в последствиях их эксплуатации, поскольку нарушение безопасности может напрямую повлиять на общественную безопасность. Кроме того, обеспечение безопасности системы SCADA может быть очень сложной задачей из-за ее строгого характера в реальном времени, требования к непрерывной доступности, ошибочного представления о том, что устаревшие технологии SCADA по своей сути безопасны просто из-за того, что они не ясны, все чаще используются компоненты COTS и взаимосвязь с другими. сети, такие как корпоративные сети и даже Интернет.

Самым значительным из реальных инцидентов, связанных с промышленными системами управления, была атака Stuxnet на завод по обогащению урана в Натанзе, Иран. Пример исключительно продвинутого вредоносного ПО, нацеленного в первую очередь на причинение физического ущерба, Stuxnet нацелился на определенные типы ПЛК, контролирующих различные аспекты процесса обогащения урана. Ранний вариант Stuxnet, который должен был прекратить работу в 2009 году, был предназначен для предохранительных клапанов; наиболее известный вариант был направлен на повреждение центрифуг путем изменения скорости вращения. Stuxnet использовал украденные цифровые сертификаты, четыре уязвимости нулевого дня и множество инновационных методов, чтобы проникнуть в закрытую сеть ПЛК предприятия. Масштаб воздействия атаки неясен, но влияние на стратегическое мышление, тенденции атак и понимание людьми потенциала киберфизических атак было огромным.

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

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

Механизмы защиты и принципы безопасного проектирования

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

Таблица 3 - Отличия между обычными компьютерными системами и киберфизическими системами

Меры защиты

Обычная компьютерная безопасность

Кибер-физическая безопасность

Аутентификация

В большинстве случаев наиболее практичными являются аутентификация на основе пароля / парольной фразы или токенов.

Биометрия, близость и местоположение

аутентификация может быть особенно подходящей.

Контроль доступа

Большинство подходов сосредоточены в первую очередь на конфиденциальности и целостности.

Фокус может быть расширен до доступности киберфизических систем в реальном времени с помощью управления доступом на основе атрибутов с атрибутами, значения которых могут зависеть от времени.

Обнаружения вторжений

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

Использует как виртуальные, так и физические функции ввода. Подходы, основанные на поведении и особенно на его спецификации, очень многообещающие. Частота истинных положительных результатов и задержка обнаружения (сколько времени требуется для обнаружения угрозы) особенно важны.

Межсетевой экран

Используется в большинстве компьютерных сетей.

Жизненно важен для защиты промышленных сетей управления, подключенных к корпоративным сетям или Интернету, но менее распространенных в других киберфизических системах.

Антивредоносное ПО

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

Может быть слишком требовательным для систем с ограниченными ресурсами. Обновления в системах реального времени применяются только тогда, когда они находятся в автономном режиме и обновления уже были опробованы в резервной системе.

Белый список приложений

Все более популярны, но несколько непрактичны, если важна гибкость.

Естественно подходит для киберфизических систем из-за низких требований к ресурсам и короткого списка необходимых приложений.

Белый список потока

Непрактично в большинстве сред, основанных на Интернете и работающих с серверами, из-за большого количества возможных легитимных потоков трафика.

Естественно подходит, поскольку потоки сетевого трафика обычно повторяются и предсказуемы, а их количество управляемо.

Криптография

Первичный механизм защиты конфиденциальности, целостности и подлинности. Обеспечивая безопасность связи и онлайн-транзакций, криптография является технологией, позволяющей использовать Интернет.

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

Интеграция специализированных аппаратных криптографических модулей позволяет устранить ограничения в режиме реального времени и обработки.

Проверка целостности

Аппаратная аттестация с использованием TPM широко используется на ПК уже несколько лет.

TPM не так широко используется, как на ПК. Программные механизмы могут лучше подходить для встраиваемых систем с ограниченными ресурсами.

Живучесть

Акцент чаще всего делается на избыточном хранении данных и предотвращении повреждения и потери данных.

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

В отличие от обычных компьютерных систем, где конфиденциальность является основной задачей, кибер-физическая безопасность системы делает упор на доступность и целостность. Устройства с ограниченными ресурсами являются сложной задачей, когда дело доходит до реализации криптографической защиты, брандмауэров и приложений для защиты от вредоносных программ на основе черного списка. С другой стороны, шаблоны сетевого трафика и необходимые приложения предсказуемы и могут быть указаны в белых списках, которые значительно менее требовательны с точки зрения ресурсов. Кроме того, биометрические характеристики, близость, местоположение и другие измеримые характеристики, происходящие из физического пространства, очень важны для использования механизмами аутентификации и контроля доступа. Аналогичным образом, обнаружение вторжений может выиграть от учета не только кибер-входных функций, но и физических входных функций, таких как подозрительные изменения в энергопотреблении, уровне воды, мобильности и т. д.

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

Библиографический список

1. Ким Зеттер. Отчёт к нулевому дню [электронный ресурс] режим доступа: https://clck.ru/SbttK

2. Dumpster Diving - Security Through Education [электронный ресурс] режим доступа: https://clck.ru/Sc3FU

3. Security Strategies for Hindering Watering Hole Cyber Crime Attack - ScienceDirect [электронный ресурс] режим доступа: https://clck.ru/Sc3GR

4. Nmap: the Network Mapper - Free Security Scanner [электронный ресурс] режим доступа: https://nmap.org/

5. Tenable - The Cyber Exposure Company [электронный ресурс] режим доступа: https://www.tenable.com

6. Wireshark Go Deep. [электронный ресурс] режим доступа: https://www.wireshark.org/

7. Белая шляпа для Shodan. Как легально использовать поисковик по IoT Хакер (xakep.ru) [электронный ресурс] режим доступа: https://xakep.ru/2015/11/25/shodan-howto/

8. Types of Malware | Internet Security Threats | Kaspersky [электронный ресурс] режим доступа: https://www.kaspersky.com.au/resource-center/threats/malware-classifications

9. Distributed Denial-of-Service, DDoS (отказ от обслуживания) [электронный ресурс] режим доступа: https://clck.ru/Sc3L3

10. Shin, D. H., Koo, J., Yang, L., Lin, X., Bagchi, S., and Zhang, J. (2013). Lowcomplexity secure protocols to defend cyber-physical systems against network isolation attacks. In Conference on Communications and Network Security (CNS), pp. 9199, IEEE, October 2013.

11. George Loukas. Cyber-physical attacks: a growing invisible threat. Butterworth-Heinemann (Elsevier), 2015.

Подробнее..

Как атаковали промышленную инфраструктуру на The Standoff анализ трафика с помощью PT ISIM

25.02.2021 18:11:56 | Автор: admin

На прошедшем The Standoff эксперты PT Expert Security Center, в данном случае представляющие команду глобального SOC киберполигона, мониторили действия команд атакующих и защитников цифровой копии мегаполиса FF, противостояние проходило в режиме реального времени и длилось 123 часа. Ранее мы писали о том, как глобальный SOC следил за всем происходящим в инфраструктуре виртуального города, как отдел обнаружения вредоносного ПО вылавливал и исследовал троянские программы редтимеров с помощью песочницы PT Sandbox и как мы следили за всеми веб-ресурсами киберполигона с помощью PT Application Firewall. Теперь поговорим о защищенности технологических сетей объектов виртуального города и результатах мониторинга, проведенного с помощью системы глубокого анализа технологического трафика PT Industrial Security Incident Manager (PT ISIM).

В этой статье мы расскажем о том, какие атаки на технологический сегмент сети объектов города детектировала система, и отметим, насколько эти угрозы соответствуют реальному уровню защищенности промышленных систем.

Что атаковали на The Standoff

Макет города на киберполигоне The Standoff включал в себя цифровые копии объектов инфраструктуры, управляемые настоящими SCADA-системами и ПЛК: точно такие же устанавливают на реальных предприятиях. Вот элементы и объекты, которые могли атаковать участники соревнований от read teams:

  • системы управления стрелками и шлагбаумами на железной дороге,

  • багажная лента в аэропорту,

  • телескопический трап в аэропорту,

  • кран в морском порту,

  • HVAC делового центра,

  • колесо обозрения в парке развлечений,

  • светофоры в деловом центре,

  • уличное освещение,

  • подстанция (электричество всего города),

  • задвижки автоматизированной газораспределительной станции,

  • турбина ТЭЦ,

  • шкаф пожарной автоматики ТЭЦ,

  • ветрогенераторные установки на электростанции,

  • системы управления производством на нефтехимическом заводе,

  • системы управления добычей нефти.

Теперь рассмотрим самые интересные, как нам кажется, атаки, которые глобальный SOC The Standoff детектировал с помощью PT ISIM.

Остановка добычи нефти

Команды Back2oaz и Сodeby смогли успешно атаковать компанию Nuft, которая в рамках модели города управляла нефтедобывающим месторождением. Участники red teams получили доступ к серверу SCADA и отправили команды по специализированному промышленному протоколу, что привело к аварии остановке процесса добычи нефти. В реальности реализация такого бизнес-риска привела бы к репутационному ущербу, недополучению прибыли и падению рыночной стоимости компании.

Цепочка развития атаки выглядела так:

  1. Неавторизованное подключение по RDP от узла из сегмента серверов 172.20.61.2 к серверу SCADA 172.20.22.11 (время 01:30). На данном этапе был получен доступ к SCADA-системе.

  1. Подача команды управления по протоколу CIP от сервера SCADA 172.20.22.11 к ПЛК 172.20.23.11 (09:02). На данном этапе выполнялся перебор различных команд управления (команды подавались в разные области, в том числе в проприетарные: 0x349, 0x68 (SFC Forces), 0x6b (SymbolObject)). Это может говорить о том, что атака выполнялась с помощью инженерного или специализированного атакующего ПО.

Подключение по RDPПодключение по RDPПеребор команд CIPПеребор команд CIPИнцидент об управляющем воздействииИнцидент об управляющем воздействии

В данном случае имело место управляющее воздействие по протоколу CIP. При этом атакующие, судя по всему, подбирали команды вслепую. Защитники в этой ситуации должны были предпринимать активные действия уже на предыдущих, ранних этапах атаки, которые были обнаружены с помощью MaxPatrol SIEM, PT Sandbox, PT NAD и PT ISIM. Естественно, по условиям учений производилось только наблюдение. После проникновения в сегмент АСУ ТП у защитников было очень мало времени для реакции на данную атаку, потому что со стороны наблюдателя все выглядело вполне легитимно: с управляющего АРМ или со SCADA-сервера подается легитимная команда на остановку или на изменение уставки.

В данном случае можно было бы рассчитывать на механизм белых списков команд протокола, при использовании которого подбор команд злоумышленниками был бы обнаружен. Опять же, если нарушитель владеет данными об атакуемом объекте, то он не будет заниматься перебором, а сразу отдаст опасную команду. В реальной жизни пока чаще встречаются сбои в работе систем и, как следствие, прохождение в сети опасных команд или данных, что удается выявить с помощью систем непрерывного анализа технологического трафика и уже упомянутых белых списков.

Запредельные обороты колеса обозрения

Была в городе FF и компания 25 Hours, которая по сценарию владела парком развлечений. Ей пришлось столкнуться с атакой команды Back2oaz, в ходе которой был осуществлен удаленный доступ к серверу SCADA и отправлены команды по специализированному промышленному протоколу. Это позволило спровоцировать аварийную ситуацию атакующие получили доступ к системе управления колесом обозрения и увеличили скорость вращения аттракциона до максимальной, что привело к падению колеса.

Атака развивалась следующим образом:

  1. Неавторизованное соединение TCP от узла 172.17.61.17 к серверу SCADA 172.17.22.11 (03:29). Вероятнее всего, это была разведка.

  2. Неавторизованное соединение по протоколу SMB от узла 172.17.61.17 к серверу SCADA 172.17.22.11 (06:06). Поиск файлов на общем ресурсе с целью найти чувствительную информацию или подсказки по дальнейшему подключению. Кроме того, на этом этапе может оставляться полезная нагрузка для дальнейшей эксплуатации.

  3. Неавторизованное подключение RDP от узла 172.17.61.17 к серверу SCADA 172.17.22.11 (08:07). Получен доступ к SCADA-системе.

  4. Изменение параметров или подача управляющего воздействия на мнемосхеме, вызвавшая отправку команды управления от сервера SCADA 172.17.22.11 к ПЛК 172.17.23.11 (08:25). Эта часть атаки могла при условии проникновения на сервер SCADA быть выполнена довольно простым способом путем подачи команды напрямую с мнемосхемы. Тем не менее атакующие серьезно исследовали систему, выявили управляющие теги и провели осмысленную атаку с помощью инженерного или специального ПО. В данном случае SCADA-система и ПЛК не имели защитных механизмов, призванных не допустить опасных ситуаций. Важно отметить, что с точки зрения NTA отправленная команда является абсолютно легитимной (если не учитывать контекст технологического процесса, который возможно заложить на уровне PT ISIM proView Sensor).

Вот как эта атака отражалась в интерфейсе PT ISIM.

Сводка взаимодействий с сервером SCADAСводка взаимодействий с сервером SCADA

Атакующие смогли провести опасную атаку, поскольку после проникновения в технологическую сеть исследовали инфраструктуру объекта. Им удалось получить доступ к инженерному ПО, выяснить управляющие теги и отправить их на ПЛК. Как и в описанном выше кейсе, защитникам следовало предпринимать активные действия уже на предыдущих этапах атаки, которые были обнаружены с помощью MaxPatrol SIEM, PT Sandbox, PT NAD и PT ISIM. После проникновения в сегмент АСУ ТП в данном случае у защитников было достаточно возможностей для реакции в реальном времени, но в реальных условиях было бы недостаточно. Во время учений, когда каждый инцидент на виду, у нападающих есть в распоряжении несколько часов, чтобы довести атаку до завершения. А в реальных условиях у киберпреступников может быть гораздо больше времени и на исследование инфраструктуры, и на проведение самой атаки. Подобную атаку на финальном ее этапе возможно выявить с помощью глубокого разбора промышленного протокола с анализом конфигурации и выявлением опасных действий оператора, таких как превышение допустимой мощности вращения колеса или несанкционированная остановка.

Нарушение и остановка процесса производства химических веществ

Упомянутая выше компания Nuft владела еще одним важным объектом в городе нефтехимическим заводом. До его технологической сети тоже добралась команда нападающих Back2oaz. Им удалось осуществить вход на сервер SCADA RDP, а также нарушить работу ПЛК с помощью специализированного инженерного ПО, в итоге был реализован бизнес-риск нарушение и остановка производства. Возможными последствиями подобных атак в реальной жизни могут быть отзыв лицензии, падение капитализации компании, отставка руководства, травмы сотрудников предприятия, жертвы среди населения города, техногенная авария и экологическая катастрофа.

Цепочка развития атаки выглядела так:

  1. Неавторизованное соединение по RDP от 172.20.61.17 к серверу SCADA 172.20.22.10 (19:30). Получен доступ к SCADA-системе.

  2. Команда на перезагрузку в сервисный режим по проприетарному протоколу, переданная с помощью инженерного ПО от сервера SCADA 172.20.22.10 к ПЛК 172.20.23.10 (01:51 на следующий день). Для реализации данного риска атакующие использовали специализированное ПО для работы с ПЛК, штатно применяемое для данного технологического процесса. Перевод в сервисный режим означает фактическую остановку выполнения основного кода и прерывание технологического процесса. В условиях отсутствия резервирования и защитных механизмов на контроллерах нижнего уровня это может привести к серьезной аварии, в частности к перегреву, нарушению процесса производства и в итоге к остановке производства полностью.

PT ISIM детектировал каждый шаг атакующих.

Подключение по RDPПодключение по RDPКоманда на перевод ПЛК в сервисный режим Команда на перевод ПЛК в сервисный режим Информационный обмен между сервером SCADA и ПЛКИнформационный обмен между сервером SCADA и ПЛК

Киберполигоны и реальность

На The Standoff, конечно, существовали некоторые условия, которые облегчают жизнь атакующим и не должны встречаться на реальных промышленных объектах. Например, инженерное ПО на управляющих АРМ или дефолтные пароли для доступа в различные системы. Однако на практике оказывается, что их все же можно встретить в инфраструктуре промышленных компаний. Нередки случаи подключения промышленной сети к корпоративной, имеющей выход в интернет. В таких условиях крайне важно использование систем глубокого анализа технологического трафика в связке с другими инструментами SIEM-системами, решениями для управления уязвимостями; это позволяет выявлять атаки на промышленные объекты и своевременно реагировать на возникающие угрозы.

Автор: Сергей Петров, руководитель отдела экспертизы промышленных систем Positive Technologies

Подробнее..

Мобильная Установка Доказательства Актуальности Контроля Изменений. Часть 1. Хороший человек идет на войну

28.12.2020 06:15:07 | Автор: admin

Итак, надоело! Даже, не так, ДОСТАЛО! А точнее, за.... Впрочем, не буду прибегать к ненормативной лексике. Квартира, купленная 2.5 года назад - это не квартира, а какое-то вечное испытание. Да такое, что Форт Баярд отдыхает. Кроме того, в конце игры Баярда можно нехило поднять золотишка, а чем тут все закончится - я еще не знаю. Недостаточная (ниже норм, утвержденных Правительством РФ, а эти нормы, скажем так, разрабатывались моржами) температура воздуха в помещении, отсутствие горячей воды по утрам, а ежедневное принятие душа превращается в соревнование "кто быстрей", ибо вода неожиданно может стать кипятком. Или, наоборот, льдом. Бездействие управляющей компании, сбор инициативной группы, объявления по подъездам, коллективная жалоба... это и многие другие веселые подробности останутся за рамками повествования.

Итак, если какой-то параметр, будь то температура или давление, не устраивает, то этот параметр надо для начала измерить. Желательно, в автоматическом режиме, непрерывно и с сохранением всех значений. И тут на помощь приходят средства промышленной автоматизации - датчик давления, датчик температуры, и программируемый логический контроллер с модулем аналоговых входов и поддержкой протокола HART. Почему именно они? Во-первых, я АСУшник, а не электронщик. Во-вторых, я исполняю обязанности руководителя технической группы Управления "Цифровое производство" уральского филиала компании ООО "Сименс". А, стало быть, все эти игрушки у меня есть. Этого оказалось вполне достаточно, чтобы продумать, собрать на коленке и запрограммировать систему, которой я дал замысловатое название Мобильная Установка Доказательства Актуальности Контроля Измерений (весь смысл замысловатости заключается в получившейся аббревиатуре... настолько я огорчен сложившейся ситуацией).

В качестве датчика, измеряющего давление, выступает Siemens Sitrans P DS3 с диапазоном измерения от 0 до 16 бар, выходом 4..20 мА и, что немаловажно, поддержкой цифрового протокола HART. HART означает Highway Addressable Remote Transducer. По сути, это цифровой протокол обмена данными между системой управления и датчиком. Обмен данными двухсторонний. Для кодирования нулей и единичек цифрового обмена используется частотная модуляция, которая накладывается прямо поверх аналогового сигнала 4..20 мА. Поддержка HART сильно играет мне на руку, поскольку позволяет избежать дополнительного аналого-цифрового преобразования на стороне ПЛК и, скажем откровенно, "забить" на "землю" (боюсь, что после этих слов мне коллеги руки не подадут). На фотографии этот красавец уже подключен к домашнему водопроводу.

Датчик температуры - тоже Siemens, тоже с HART'ом. Вторичка - Sitrans TH300, первичка - обычный Pt100 в толстой гильзе. Именно из-за гильзы он не подошел для замеров температуры воздуха - просто огромная инерция измерений.

В качестве CPU применяется S7-1510 (он же ET200SP CPU), заказной номер 6ES7 510-1DJ01-0AB0, версия прошивки 2.8. К CPU справа подключен четырехканальный модуль аналоговых входов с поддержкой HART, заказной номер 6ES7 134-6TD00-0CA1. Блок питания слева от контроллера, весьма большой и очень избыточный по мощности в моем случае.

Для визуализации измеряемых параметров и, что немаловажно, для их архивации взял базовую операторскую панель второго поколения, KTP400 Basic, 6AV2 123-2DB03-0AX0, прошивка обновлена до 16.0. Причина для такого выбора простая - мобильных панелей у меня под рукой нет, а "немобильные", стандартные версии предназначены для врезки в дверь шкафа управления, но никак не для того, чтобы держать их в руках. Маленькую четырехдюймовую панель на весу удержать можно без проблем, а вот семидюймовую Comfort или Unified одной рукой не удержишь. Разбивать подотчетное оборудование и попадать на 1200 евро её листовой стоимости не хочется никак, поэтому лучше маленькую и легкую, чем большую, тяжелую, но функциональную.

Для обвязки применяется обычный провод сечением 0.5 мм2 и НШВИ 0.5х8. Техническая эстетика не соблюдается никак. Корпуса нет. Заземляющих проводников нет. Все обвязано, абы как. Прикладное ПО далеко не универсально, уставок от оператора нет, даже константы не применяются, все тупо в лоб. В общем, это ни в коем случае не готовое решение, которое можно сертифицировать и вносить в реестр СИ. Я напишу про это тут один раз, дабы избежать войн в комментариях, да, со всеми этими замечаниями я согласен.

Датчики подключаем к каналам 0 и 1 аналогового модуля в соответствии с документацией.

У нас используется вариант (1) - двухпроводное подключение датчика. Под "двухпроводностью" подразумевается, что к датчику в общем случае идет всего два провода, "+" и "-" непосредственно от аналогового модуля. Отдельного питания на датчик не требуется, он запитывается от модуля AI. Электроника модуля получает энергию по внутренней шине контроллера, а "силовая" часть подается на отдельные клеммы. В итоге, первый датчик (датчик давления) садим на контакты 9 и 13 (нулевой канал), датчик температуры - 10 и 14 (первый канал).

Для программирования и конфигурирования этой системы применяем среду разработки TIA Portal V16 (+update 3), в составе Step 7 Professional (контроллер) и WinCC Basic (операторская панель). После создания проекта в первую очередь создаем и конфигурируем ПЛК.

Включаем System and Clock Memory, пригодится.

Задаем IP адрес CPU - 192.168.43.205. Конфигурируем аналоговый модуль. Второй и третий каналы отключаем, на нулевом и первом включаем HART и активируем всю диагностику (диагностика совсем необязательна в моем простом случае).

Обзор настройки каналов модуляОбзор настройки каналов модуляНастройка нулевого (и первого тоже) каналаНастройка нулевого (и первого тоже) канала

Поскольку в данном случае задействовано всего 2 канала, а от функционала HART требуется всего лишь передача значения измеряемой величины, то можно поступить просто и забирать первичную переменную HART обоих датчиков через пространство ввода/вывода аналогового модуля. Тем самым избавляемся от необходимости осуществлять системный вызов в программе PLC.

Из этой таблицы видно, что нам надо забрать две переменные с адресов ID8 и ID13. Первичные переменные HART будут поступать нам, как готовые вещественные величины. Пропишем эти адреса в Tag Table. Так же я еще прописал все четыре аналоговых канала модуля, но в программе они никак не используются... просто привычка объявлять переменные по каналам, которые есть в проекте.

Посмотрим, что я начудил в программе контроллера. Вообще, в ПЛК можно обойтись без какой-либо программы вообще. Информация с датчиков и так автоматически поступает в переменные с именами CH0_HART (давление) и CH1_HART (температура). Однако, установка изначально разрабатывалась, как универсальная - она замеряет и Т воздуха, и Т воды, и давление воды, да еще и в нескольких местах (воздух в разных комнатах, например). Если обойтись одним трендом, то можно уже через день запутаться, что, где и когда измерял. Поэтому программа контроллеру тут носит больше "организационный" характер.

Все необходимые переменные сведены в один блок данных.

Вся программа написана в "главном" огранизационном блоке. Расписывать ее нет необходимости, можно ознакомиться с комментариями в коде.

"Data".CurrentPress := "Ch0_HART" / 10.0; //давление перевести из бар в МПа"Data".CurrentTemp := "Ch1_HART"; //текущая температураIF "Data".MeasP THEN //если включен (с панели) замер давления        //допускается всего 4 места измерения давления - в ванной (ХВС, ГВС) и на кухне    IF "Data".WaterSelector <= 0 OR "Data".WaterSelector > 4 THEN         "Data".WaterSelector := 1;    END_IF;        //создать для панели сообщение "идет замер давления в/на <место замера и выбранная труба">    CASE "Data".WaterSelector OF        1: //ХВС в ванной            "Data".WaterMessage := W#2#0000000000000001;        2: //ГВС в ванной            "Data".WaterMessage := W#2#0000000000000010;        3: //ХВС на кузне            "Data".WaterMessage := W#2#0000000000000100;        4: //ГВС на кухне            "Data".WaterMessage := W#2#0000000000001000;    END_CASE;        //тнекщее давление в МПа скопировать в отдельную переменную для тренда    "Data".CurrentPress_M := "Data".CurrentPress;        //если замер только что включили, сбросить минимальное и максимальное зафиксированное значение    IF (NOT "Data".MeasP_prv) THEN        "Data".MinPress_M := "Data".CurrentPress_M;        "Data".MaxPress_M := "Data".CurrentPress_M;    END_IF;        //зафиксировать при необходимости минимальное значение    IF "Data".CurrentPress_M < "Data".MinPress_M THEN        "Data".MinPress_M := "Data".CurrentPress_M;    END_IF;        //зафиксировать максимальное значение давления во время этого замера    IF "Data".CurrentPress_M > "Data".MaxPress_M THEN        "Data".MaxPress_M := "Data".CurrentPress_M;    END_IF;        //выставить аварийные и предупредительные сообщения    "Data".P003Alarm_M := "Data".CurrentPress_M < 0.03;    "Data".P01Alarm_M := "Data".CurrentPress_M < 0.1;    "Data".P02Alarm_M := "Data".CurrentPress_M < 0.2;ELSE //если замер давления не ведется    "Data".CurrentPress_M := 0.0; //обнулить переменную для тренад давления    "Data".WaterMessage := W#2#0000000000000000; //сбросить "место проведения давления"    "Data".P003Alarm_M := FALSE; //сбросить флаги алармов и сообщений    "Data".P01Alarm_M := FALSE;;    "Data".P02Alarm_M := FALSE;;END_IF;IF "Data".MeasTair THEN //аналогично для температуры воздуха        IF "Data".PlaceSelector <= 0 OR "Data".PlaceSelector > 7 THEN        "Data".PlaceSelector := 7;    END_IF;        CASE "Data".PlaceSelector OF        1: //спальня            "Data".PlaceMessage := W#2#0000000000000001;        2: //детская            "Data".PlaceMessage := W#2#0000000000000010;        3: //зал            "Data".PlaceMessage := W#2#0000000000000100;        4: //кухня            "Data".PlaceMessage := W#2#0000000000001000;        5: //ванная            "Data".PlaceMessage := W#2#0000000000010000;        6: //туалет            "Data".PlaceMessage := W#2#0000000000100000;        7: //прочее            "Data".PlaceMessage := W#2#0000000001000000;    END_CASE;        "Data".CurrentTemp_Mair := "Data".CurrentTemp;        IF (NOT "Data".MeasTair_prv) THEN        "Data".MinTemp_Mair := "Data".CurrentTemp_Mair;        "Data".MaxTemp_Mair := "Data".CurrentTemp_Mair;        "Data".MeasTwater := false;    END_IF;        IF "Data".CurrentTemp_Mair < "Data".MinTemp_Mair THEN        "Data".MinTemp_Mair := "Data".CurrentTemp_Mair;    END_IF;        IF "Data".CurrentTemp_Mair > "Data".MaxTemp_Mair THEN        "Data".MaxTemp_Mair := "Data".CurrentTemp_Mair;    END_IF;        "Data".T18Alarm_M := "Data".CurrentTemp < 18;    "Data".T20Alarm_M := "Data".CurrentTemp < 20;    "Data".T22Alarm_M := "Data".CurrentTemp < 22;ELSE    "Data".CurrentTemp_Mair := 0.0;    "Data".PlaceMessage := W#2#0000000000000000;    "Data".T18Alarm_M := FALSE;    "Data".T20Alarm_M := FALSE;    "Data".T22Alarm_M := FALSE;END_IF;//аналогично для температуры водыIF "Data".MeasTwater THEN    "Data".CurrentTemp_Mwater := "Data".CurrentTemp;        IF (NOT "Data".MeasTwater_prv) THEN        "Data".MinTemp_Mwater := "Data".CurrentTemp_Mwater;        "Data".MaxTemp_Mwater := "Data".CurrentTemp_Mwater;        "Data".MeasTair := false;    END_IF;        IF "Data".CurrentTemp_Mwater < "Data".MinTemp_Mwater THEN        "Data".MinTemp_Mwater := "Data".CurrentTemp_Mwater;    END_IF;        IF "Data".CurrentTemp_Mwater > "Data".MaxTemp_Mwater THEN        "Data".MaxTemp_Mwater := "Data".CurrentTemp_Mwater;    END_IF;        "Data".T40Alarm_M := "Data".CurrentTemp < 40;    "Data".T55Alarm_M := "Data".CurrentTemp < 55;    "Data".T57Alarm_M := "Data".CurrentTemp < 57;    "Data".T60Alarm_M := "Data".CurrentTemp < 60;ELSE    "Data".CurrentTemp_Mwater := 0.0;    "Data".T40Alarm_M := FALSE;    "Data".T55Alarm_M := FALSE;    "Data".T57Alarm_M := FALSE;    "Data".T60Alarm_M := FALSE;END_IF;//при первом запуске контроллера сбросить зафисированные мин и макс "общих" (не замерных) величин"tonFirstScan".TOF(IN:=NOT "FirstScan",                   PT:=T#1s);IF "tonFirstScan".Q THEN    IF "Data".CurrentPress < "Data".MinPress THEN        "Data".MinPress := "Data".CurrentPress;    END_IF;        IF "Data".CurrentPress > "Data".MaxPress THEN        "Data".MaxPress := "Data".CurrentPress;    END_IF;        IF "Data".CurrentTemp < "Data".MinTemp THEN        "Data".MinTemp := "Data".CurrentTemp;    END_IF;        IF "Data".CurrentTemp > "Data".MaxTemp THEN        "Data".MaxTemp := "Data".CurrentTemp;    END_IF;END_IF;//сбросить мин и макс по запросу с панелиIF "Data".ResetPressStat THEN    "Data".MinPress := "Data".CurrentPress;    "Data".MaxPress := "Data".CurrentPress;    "Data".ResetPressStat := FALSE;END_IF;IF "Data".ResetTempStat THEN    "Data".MinTemp := "Data".CurrentTemp;    "Data".MaxTemp := "Data".CurrentTemp;    "Data".ResetTempStat := FALSE;END_IF;//выставить обобщенный флаг "идет замер""Data".Meas := "Data".MeasP OR "Data".MeasTair OR "Data".MeasTwater;//для определения фронтов"Data".MeasP_prv := "Data".MeasP;"Data".MeasTair_prv := "Data".MeasTair;"Data".MeasTwater_prv := "Data".MeasTwater;//сообщения для панели оператора"Data".Alarms.%X0 := "Data".MeasP;"Data".Alarms.%X1 := "Data".MeasTair;"Data".Alarms.%X2 := "Data".MeasTwater;"Data".Alarms.%X3 := "Data".T18Alarm_M;"Data".Alarms.%X4 := "Data".T20Alarm_M;"Data".Alarms.%X5 := "Data".T40Alarm_M;"Data".Alarms.%X6 := "Data".P003Alarm_M;"Data".Alarms.%X7 := "Data".P01Alarm_M;"Data".Alarms.%X8 := "Data".P02Alarm_M;"Data".Alarms.%X9 := "Data".T22Alarm_M;"Data".Alarms.%X10 := "Data".T55Alarm_M;"Data".Alarms.%X11 := "Data".T57Alarm_M;"Data".Alarms.%X12 := "Data".T60Alarm_M;

Перейдем к конфигурирования прикладного программного обеспечения операторской панели. Добавим ее в общий проект и зададим ip адрес.

Добавим некоторые настройки рантайма - выбор бита для списков и цвет алармов в зависимости от их класса.

Создадим соединение с контроллером и вытащим необходимые тэги (все это делается автоматически при вытаскивании тэга с ПЛК на любой экран панели). Выставим минимально возможное время опроса переменных в 100 мс.

Все тэги берем с блока данных 1 ПЛКВсе тэги берем с блока данных 1 ПЛК

Для тэгов Data_Alarms, DataWaterMessage и Data_PlaceMessage создадим сообщения.

Создадим Alarm Log для сообщений панели на максимальное количество записей, 500000. Весь лог будет храниться в текстовом виде на USB-флэшке, подключенной к панельке. Журнал циклический, по достижению предельного количества записей, старые будут затираться.

В настройках классов сообщений укажем, алармы каких классов будут сохраняться на фдэшке

Аналогично создадим хранилище для исторических трендов, которое будет так же храниться на флэшке в виде текстового файла. "Трендировать" будем три переменных - значение давление, температуры воздуха и температуры воды во время измерения (не на постоянной основе). Запись значений будет производиться только при изменении переменной, а не на постоянной основе. В противном случае журнал начнет весьма быстро перезатираться.

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

Кнопкой F1 листаем экраны замеров. Остановися только на экране давления, два других аналогичны. На этом экране отображается текущее мгновенное значение давления при идущем замере, эксремумы давления, выбор места проведения измерения и график с историческими данными. Кнопкой F3 начинаем замер давления, кнопкой F4 останавливаем,

На любом экране кнопкой F2 открывается журнал событий.

Дополнительно для собственного удобство я сделал копию этой панели и изменил ее тип на PC Station с одиночной SCADA-системой WinCC RT Advanced. На 4дюймовом экране очень неудобно смотреть графики.

Зато, на 24 дюймах смотреть удобно

Установка находится в работе с 21 декабря. За это время мне стало изместно время пикового вечернего разбора воды, это в районе 22 часов местного времени. Ситуация удручающая, давление падает ниже установленных норм (0.03МПа) и падает влоть до нуля. Да и в целом давление не постоянное, оно может за секунду упасть с трех килограммов до одного, а потом за 5 секунд подняться до 2.5 килограмм.

В настоящий момент система полностью локальна. Все данные сохраняются в панельке, на фэшке переносятся на ПК и изучаются на нем.

Следующим шагом будет установка к линейку ПЛК WiFi модуля, настройка WiFi-моста и создание полноценного операторского интерфейса на базе WinCC OA под управлением Linux Debian (Buster).

Подробнее..

Строим и автоматизируем вентиляцию Спас-на-Крови

14.05.2021 12:21:34 | Автор: admin

На Хабре часто пишут о квартирной вентиляции и её автоматизации. Такие кейсы интересны необходимостью достигать результатов, используя достаточно простые и не затратные компоненты. А в данной статье хотелось бы рассказать о другом конце спектра климатики и автоматизации - построении системы отопления в сильно-историческом здании. Работе, которая начиналась даже не с проектирования, а с математического моделирования...

Собор "Спас на крови" имеет тяжелую судьбу. И хотя после окончания долгой реставрации, воспетой в песнях, его жизнь наладилась, но время шло. А так как собор - это не только стены, но и различные системы жизнеобеспечения, то смонтированные во время реставрации инженерные системы ветшали и постепенно заменялись на современные. Так пришло время замены и системы отопления.

Спас-на-Крови (Собор Воскресения Христова на Крови)Спас-на-Крови (Собор Воскресения Христова на Крови)

Существовавшая система отопления была сделана в советские годы хоть и основательно, но очень громоздко. Оборудование воздушного отопления занимало практически весь подвал. Было настолько тесно, что в некоторые помещения вообще можно было пройти только боком. В целом система отопления со своими задачами справлялась, но, как когда-то говорилось, были отдельные недостатки: сквозняки и холод у входных дверей (а ведь это постоянные рабочие места сотрудников собора-музея); низкая температура воздуха в алтаре; отсутствие организованной вентиляции в подвале. Охлаждение в существовавшей системе вентиляции предусмотрено не было. Как следствие, летом собор сильно прогревался, и температура воздуха внутри значительно превышала комфортную. Очевидно, что большой разброс температур также не способствовал сохранности мозаик, росписей и других культурных ценностей.

Разумеется, в историческом соборе никто бы не дал прокладывать воздуховоды "под потолком" :)
Поэтому проработка решения началась не со стандартного инженерного проектирования, а математического моделирования движения воздушных масс и распределения температур внутри собора. Расчёты показали и низкие температуры со сквозняком у входных дверей; и низкую температуру воздуха в алтаре; и эффект стекания холодного воздуха из алтаря. Таким образом, было объективно подтверждено то, что ранее ощущалось просто как недостаток комфорта. Для исправления ситуации было предложено установить более мощные воздушно-тепловые завесы на входе и рассчитано дополнительное количество тепла для алтаря. Моделирование охлаждения собора в летний период показало, что при подаче охлажденного воздуха, в нижней части основного объема собора образуется холодная воздушная подушка. Воздушная подушка оказалась склонна к вытеканию из собора через открытые двери, для предотвращения этого было рекомендовано использовать воздушно-тепловые завесы в режиме отсечки. Кроме того, была проработана технология использования "воздуховодов 19 века", проложенных внутри кирпичных стен во время строительства собора.

Для отопления основного объема собора заложено четыре приточно-рециркуляционные установки, при этом для полноценного отопления собора достаточно трех, поэтому любая из четырех машин является запасной. Подача воздуха организована через многочисленные внутристенные каналы, выходящие в подоконниках окон, забор воздуха на рециркуляцию происходит через каналы, выведенные под лавки.

Была поставлена задача обеспечить охлаждение воздуха в летнее время. При выборе холодильных машин возникла проблема с размещением конденсационных блоков ставить их оказалось просто некуда. Применить холодильные машины с воздушным охлаждением тоже не получалось они требовали большое количество наружного воздуха, которое не обеспечивал приточный воздуховод, да и требовали такое количество электроэнергии, которое не обеспечивал ГРЩ собора. Была мысль применить водяное охлаждение ведь сбор стоит на канале Грибоедова, но организация водозабора нарушила бы целостность гидроизоляции фундамента собора, а в то, чтобы надежно гидроизолировать фундамент были вложены огромные усилия как при строительстве собора, так и при его реставрации.

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

При подсоединении к внутристенным каналам произошло несколько курьезов, связанных с тем, что каналы идут в стенах в два ряда, причем многие из них идут под наклоном. Соответственно, некоторые каналы, показанные на исторических чертежах на нулевой отметке, выходят в подвале совсем в другом месте, при этом вместо них выходят каналы из другого ряда. Полностью восстановить схему каналов в стенах нам так и не удалось, но со второго раза все же получилось подсоединить воздуховоды правильно.

Еще одно решение вызвано спецификой расположения собора. Дело в том, что наиболее холодный северо-восточный ветер дополнительно усиливается вдоль канала Грибоедова и с большим напором влетает во входную дверь. Для тепловой завесы на входе было предложено необычное решение - завеса на входе состоит из трех отдельных завес: двух вертикальных высотой 1,5м и одной горизонтальной, работающих одновременно. Вертикальные завесы создают двойную отсечку воздуха в нижней зоне, а мощная горизонтальная завеса в верхней.

Для контроля параметров воздушной среды в наиболее характерных местах установлены датчики температуры и влажности: четыре датчика по углам основного объема собора, два в алтаре, по одному у входов и еще два на самом верху, на барабане собора.

Четыре приточно-рециркуляционные установки и приточно-вытяжная установка подвальных помещений оборудованы щитами управления, каждая со своим контроллером автоматики, тепловые завесы и конвекторы в алтаре управляются еще двумя щитами, также установлен щит управления в ИТП. Контроллеры в щитах автоматики и контроллеры холодильных машин соединены сетью Bacnet/IP со SCADA системой на 5000 точек данных.

Один из экранов SCADA системыОдин из экранов SCADA системы

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

Прошедшая зима показала правильность модели и выполненных на ее основе теплотехнических расчетов. В сложном историческом здании собора поддерживается желаемая температура воздуха. Причем это произошло без привлечения дополнительных энергоресурсов, потребляемая собором тепловая мощность даже несколько снизилась.

Авторы: Аржаников Ростислав, к.т.н.; Осовский Кирилл

Подробнее..

Zabbix OPC DA

25.05.2021 00:13:35 | Автор: admin

В последних релизах Zabbix "из коробки" стал поддерживать некоторые популярные протоколы промышленного оборудования. Имея поддержку Modbus и MQTT, его использование с системами промышленной автоматизации стало чуточку проще. Но подобный подход к мониторингу такого рода оборудования не всегда возможен.

Как правило, на предприятиях используется большое количество устройств промышленной автоматики разных лет и от разных производителей, поддерживающих разные протоколы обмена. OPC серверы являются универсальным инструментом обмена данными с такими устройствами. Информация на тему интеграции Zabbix и OPC DA в сети практически отсутствует. Возможно, мой небольшой опыт в этом направлении окажется полезен.

Для чего нам Zabbix

В нашем сценарии использования Zabbix последний не является заменой имеющейся SCADA-системе. Параллельное развертывание системы мониторинга позволит иметь возможность гибкой настройки триггеров и своевременного получения оповещений о нештатных ситуациях на оборудовании. Также мы сможем создавать дополнительные информационные панели с графиками, которые смогут давать быстрое представление о ходе тех. процессов.

Взаимодействие с OPC серверами

Самой сложной задачей, которая стоит перед нами, является организация взаимодействия с OPC-серверами. В ходе поисков готового решения такого взаимодействия стало понятно, что подходящих нам вариантов не так много. Из того, что было найдено, наиболее пригодным к использованию оказался консольный клиент OpenOPC.

Установка OpenOPC

Как было сказано ранее, речь идет о стандарте OPC DA, а значит, о технологии DCOM и, соответственно, ОС Windows. В нашем случае установка OpenOPC производилась на машину с Windows XP, где и находится проприетарный OPC сервер. После завершения установки необходимо добавить путь до opc.exe в системную переменную среды PATH.

Проверим работу утилиты. Для начала выведем в консоль список доступных OPC серверов:

C:\Users\Администратор> opc.exe -qMerz.OPC_SAIA_S-BUS.1C:\Users\Администратор>

Теперь попробуем получить теги в удобном нам формате - csv:

C:\Users\Администратор>opc.exe -o csv -s Merz.OPC_SAIA_S-BUS.1 ATP.Register.OAT ATP.Register.OAT,197,Good,05/24/21 07:16:15C:\Users\Администратор>opc.exe -o csv -s Merz.OPC_SAIA_S-BUS.1 ATP.Register.OAT ATP5.Register.T_inlet ATP5.Register.T_outletATP.Register.OAT,198,Good,05/24/21 07:16:41ATP5.Register.T_inlet,627,Good,05/24/21 07:16:41ATP5.Register.T_outlet,654,Good,05/24/21 07:16:41C:\Users\Администратор>

Если что-то пошло не так

В ходе экспериментов с opc.exe выяснились некоторые моменты. Первое: каждый OPC клиент запускал новую копию OPC сервера, а их параллельная работа невозможна. Так как запустить используемый нами OPC сервер как службу не получилось, то через DCOM был настроен запуск OPC сервера от определенного пользователя. Все OPC клиенты - SCADA и агент Zabbix - были также настроены на запуск от этого пользователя. Второе: выявлены некоторые недостатки в работе самого OpenOPC. Например, клиент не вычитывает теги, в названии которых присутствуют символы, отличающиеся от латинских. С этим пока пришлось смириться и решать такие проблемы путем переименования тегов в OPC сервере.

Установка Zabbix агента

На ту же машину установим Zabbix агент, который сможет работать под Windows XP, например, zabbix_agent-5.2.0-windows-i386-openssl.msi. Агент будет выполнять активные проверки. Чтобы облегчить дальнейшую конфигурация агента, во время установки заполним следующие поля:

  • Ноst name - уникальное имя хоста, совпадающее с именем узла сети на Zabbix сервере.

  • Zabbix server IP/DNS - IP-адреса Zabbix сервера.

  • Server or Proxy for active checks - IP-адрес Zabbix сервера для активных проверок.

Конфигурирование Zabbix агента

В конфигурационный файл C:\Program Files\Zabbix Agent\zabbix_agentd.conf были внесены некоторые изменения.

  1. Увеличено время выполнения скрипта.

    ### Option: Timeout#Spend no more than Timeout seconds on processing.## Mandatory: no# Range: 1-30# Default:# Timeout=3Timeout=30
    
  2. Создан параметр для мониторинга.

    #User-defined parameter to monitor. There can be several user-defined parameters.#Format: UserParameter=<key>,<shell command>## Mandatory: no# Default:# UserParameter=UserParameter=opc[*],opc.exe -o csv -s $1 $2
    

Узел сети и элементы данных на сервере Zabbix

На Zabbix сервере создадим узел сети. Имя узла сети должно совпадать с Ноst name, указанном при установке агента, интерфейс - IP-адрес агента.

Далее к созданному узлу сети добавим элемент данных c типом Zabbix агент (активный). Ключом должна являться конструкция типа: opc[<ИМЯ OPC СЕРВЕРА>, <ЗАПРАШИВАЕМЕ ТЕГИ ЧЕРЕЗ ПРОБЕЛ>].

Значениями элемента данных будут строки, разделенные запятыми:

ATP2.Register.OAT,273,Good,05/24/21 15:21:33ATP2.Register.GVS.T_inlet_W,501,Good,05/24/21 15:21:33ATP2.Register.GVS.T_outlet_W,445,Good,05/24/21 15:21:33ATP2.Register.T_outlet_w_com,404,Good,05/24/21 15:21:33ATP2.Register.RAD.T_outlet_W,256,Good,05/24/21 15:21:33ATP2.Register.P_in_W_com,39,Good,05/24/21 15:21:33ATP2.Register.P_out_W_com,36,Good,05/24/21 15:21:33ATP2.Register.RAD.P_outlet_W,43,Good,05/24/21 15:21:33ATP2.Register.FIRE.P_gidrant,68,Good,05/24/21 15:21:33

Зависимые элементы данных

Создадим зависимые элементы данных для того, чтобы распарсить CVS, полученный в самом элементе.

В предобработке используем JavaScript, который получит необходимую нам строку в CVS, проверит качество тега и вернет результат.

function (value){    var nr_line = 4;    var lines = value.split('\n');    var fields = lines[nr_line].split(',');    if(typeof fields[2] != "undefined" &&  fields[2] == "Good"){    return (typeof fields[1] != "undefined") ? fields[1] : null;    }    return null;}

Пример визуализации полученных данных:

Заключение

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

Подробнее..

Моя эволюция интерфейсов систем диспетчеризации

30.05.2021 20:12:29 | Автор: admin

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

Я уже больше 10 лет занимаюсь автоматизацией и диспетчеризацией инженерных систем, у меня небольшая команда специалистов, и так сложилось, что мы уделяем большое внимание не только тому, как системы работают внутри, но и как с ними будет взаимодействовать персонал.

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

В этой статье я не буду акцентировать внимание на производителях оборудования и софта, так как это имеет второстепенное значение. Интерфейс разрабатывается в графическом редакторе под нужное разрешение и размер экрана, и уже после интегрируется в нужный софт. Хотя по многим скриншотам можно узнать производителя, в этом плане мы довольно консервативны и привыкли работать с тем, что уже знаем вдоль и поперек.

Лонгрид!

2014

Главное окно с мнемосхемой на сенсорной панеле управления 7 дюймовГлавное окно с мнемосхемой на сенсорной панеле управления 7 дюймовОсновное меню с настройками на сенсорной панеле управления 7 дюймовОсновное меню с настройками на сенсорной панеле управления 7 дюймовОкно диспетчеризации, можно открыть на любом устройстве под управлением WindowsОкно диспетчеризации, можно открыть на любом устройстве под управлением Windows

Это индивидуальный тепловой пункт одного из павильонов ВДНХ в Москве, первый самостоятельный объект, где можно было проявить творческий подход. В помещении ИТП на шкафу управления установлена 7 дюймовая сенсорная панель для локального управления и облачная система диспетчеризации. Несмотря на то, что в этом интерфейсе довольно все криво и сыро, здесь есть много элементов и правил, которым мы придерживаемся до сих пор.

С самого первого объекта я начал применять темный интерфейс. У специализированных программ (AutoCad, Photoshop), был темно-серый интерфейс, в нем было комфортно работать долгое время и я решил придерживаться их идеологии. К тому же, помещение ИТП было без освещения и очень темным, делать яркий светлый фон на панеле просто издевательство над эксплуатацией. Хотя сейчас у нас в портфолио есть кейсы со светлой темой, все равно, на сегодняшний день предпочтение отдается именно темной.

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

Наименьшим изменениям за все время подверглось меню панели управления. Сейчас мы точно так же размещаем в левой колонке пункты меню, а в правой содержимое вкладки.

Все элементы интерфейса: статика и переменные, собирались внутри программного обеспечения производителя панелей или диспетчеризация. В них крайне неудобно выравнивать объекты, не удобная сетка, от этого все гуляет и сами интерфейсы могут сильно отличаться друг от друга.

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

2015

Приточно-вытяжная установка с гликолевым рекуператором. Панель оператора 10 дюймов.Приточно-вытяжная установка с гликолевым рекуператором. Панель оператора 10 дюймов.

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

Синий цвет здесь по-прежнему использовался без назначения, от этого не понятно, с чем возможно взаимодействовать, а что просто статичный элемент.

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

2016

Станция ВЗУ коттеджного поселка. Панель оператора 10 дюймов.Станция ВЗУ коттеджного поселка. Панель оператора 10 дюймов.

В 2016 году я продолжил использовать трехмерные картинки, синий цвет и добавил еще больше обводок. В целом интерфейсы получались симпатичными и достаточно удобными для персонала. И он уже выглядит значительно лучше, чем предыдущий.

На объектах, где есть технология, возникают проблемы в отрисовке из-за использования трехмерной графики. Одно дело показать насосы, клапан, фильтры и заслонки, другое дело показать технологическое оборудование. Найти в интернете подходящие картинки ультрафиолетовых ламп и фильтров очистки крайне сложно, не говоря уже о более сложном оборудовании: флотаторы, жироловки, обезвоживатели и так далее. Это одна из причин, почему мы отказались от 3Д в дальнейшем.

Структура меню не изменилась, изменился немного дизайн. Добавились иконки в пунктах меню. Иконки декоративные, какой-то пользы они не несут, скорее просто иконки ради иконок. Здесь они крупные, выполнены в стиле Flat, занимают прилично место на экране. В дальнейшем от иконок мы не отказывались, они стали меньше и аккуратнее и лучше вписываются в общую стилистику. Стоит применять иконки или нет в пунктах меню ответить однозначно сложно. Думаю, что так же как и с 3Д картинками, не под все пункты меню можно подобрать подходящие по стилю и смыслу иконки. Если есть возможность добавить аккуратные иконки, не уменьшая полезную площадь подписей, то лучше их добавить, они разбавят табличную структуру меню.

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

2017

Производственно-складской комплекс, МО, обзорная схема, 27 дюймовПроизводственно-складской комплекс, МО, обзорная схема, 27 дюймовПроизводственно-складской комплекс, МО, под экран планшета и ноутбукаПроизводственно-складской комплекс, МО, под экран планшета и ноутбука

В начале года был довольно крупный объект, комплексная диспетчеризация производственно-складского комплекса. Этот клиент дал много опыта с точки зрения инженерных систем и алгоритмов управления, но сделать что-то принципиально новое в интерфейсе на тот год не вышло. В этом интерфейсе применяли все уже предыдущие наработки, немного дорабатывая и улучшая. Здесь уже есть какое-то выравнивание. Отступы гуляют по-прежнему, но, в целом, сетка объектов прослеживается, от этого интерфейс выглядит чище и строже. Переменные индикации отличаются визуально от уставок. Кнопки и тумблеры не наши, они стандартные от Scada и их изменить было нельзя.

2018

Это крупный логистический центр в Московской Области, оснащенный разными системами, за работой которых нужно следить, управлять и анализировать. Этот клиент дал мощный толчок в развитие, в том числе и с точки зрения пользовательского интерфейса, мы по сей день проводим здесь много работ, применяя новые алгоритмы управления и аналитики. К этому объекту я еще буду возвращаться в этой статье, но пока о том, как он повлиял на разработку интерфейса.

Основное отличие подхода к разработке этого интерфейса от предыдущих, это то, как рисуется вся статика. До этого интерфейс собирался по частям в среде разработки для панелей и в Scada системе, это очень усложняет процесс, особенно, выравнивание объектов. Здесь же вся статика делается в графическом редакторе и подгружается одной картинкой PNG на экран. Сверху накладываются только переменные и анимация. Это сразу убивает несколько зайцев: выравнивать и делать отступы можно с большой точностью, скорость загрузки страниц увеличивается, так как нужно меньше информации подгружать из памяти, уменьшается нагрузка на процессор.

С точки зрения дизайна, тут появилось много нового. Появился не стандартный шрифт GothamPro, цвета теперь не рандомные, а подобраны из палитр Material Design, появились кратные отступы и сетка. Объекты теперь выровнены все относительны друг друга. Поля индикации и ввода значения уже стали существенно различаться, к этому быстро привыкаешь и пользоваться становится удобно.

Что осталось от прежних интерфейсов? Структура меню, она не поменялась, иконки стали меньше и аккуратнее, теперь они гармонично вписались в общую стилистику. Иконки на главном окне с мнемосхемой остались прежние, но сама мнемосхема слегка упростилась и стала чуть более плоской. Это был последний год использования этих иконок и 3Д элементов в целом.

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

Первое видео было с панели оператора 7 дюймов, которая установлена на дверце шкафа управления, разработка дизайна интерфейса началась с нее, дальше будут экраны с мониторов системы диспетчеризации.

Приточно-вытяжная вентиляция, экран с диспетчерской, 25 дюймовПриточно-вытяжная вентиляция, экран с диспетчерской, 25 дюймовПринципиальная схема котельной, монитор с диспетчерской 25 дюймовПринципиальная схема котельной, монитор с диспетчерской 25 дюймовОбзорная схема инженерных систем логистического центра, 25 дюймовОбзорная схема инженерных систем логистического центра, 25 дюймов

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

Что касается главного экрана, то здесь реализован "карточный" интерфейс. Смысл его в том, чтобы структурировать информацию по системам, на каждую сделать свою карточку и разместить ее на схеме здания. Если систем много, можно разделить их по нескольким экранам, если не много, то можно все показать на одном экране и отделить разные схемы цветами. На карточке нужно отображать только самые основные параметры, которые влияют на работоспособность установки и которые можно сравнивать между собой. Для вентиляции наиболее важными параметрами являются: статус работы, наличие аварий, режим зима/лето, температура канала, помещения и обратной воды. Дополнительно стараемся отображать обороты вентилятора, процент открытия клапана и задание уставки температуры. Эти значения позволяют быстро оценить стабильность работы вентсистем и теплоснабжения установок, не переходя к схемам каждой системы отдельно. Очень удобно на одном экране сравнивать параметры работы разных систем. Если, например, наблюдается недогрев по многим системам, значит есть проблемы с теплоснабжением из котельной.

У нас есть объекты, которые имеют один этаж и там удобно все карточки систем размещать на планировке здания, привязывая к их реальному местоположению на плане. Есть объекты в 4-5 этажей, и здесь становится сложнее структурировать карточки. Можно разделить экран на 4 равных части и на каждом отобразить свой этаж с системами. Можно сделать 4 экрана, на каждом свой этаж с нанесенным на нем системами, но здесь могут быть нюансы, как правило, большая часть систем располагается на -1 этаже и на последнем или кровле, что приводит к сильному дисбалансу. Мы пробовали разные варианты, расскажу об этом чуть дальше в статье.

2019

Приточно-вытяжная установка, панель оператора 7 дюймовПриточно-вытяжная установка, панель оператора 7 дюймовМенюшка, панель 7 дюймовМенюшка, панель 7 дюймов

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

Здесь мы опять решили пересмотреть дизайн интерфейса и внести что-то новое. Наконец-то полностью ушли от 3Д, теперь у нас все плоское. Идея была уйти от 3Д, тем самым убрать лишние не информативные элементы со схемы, освободить ценное место и структурировать информацию не по графическим элементам, а по карточкам. Раньше, чтобы показать информацию о теплоснабжение установки (работа насоса, клапана, температура обратной воды) нужно было нарисовать целый узел с трубами, насосом, перемычками и прочим, это занимает много места и несет мало информации. Теперь вся эта информация находится в карточке "нагрев", точно так же структурированы и другие карточки систем. Такая структура дает унификацию интерфейса, если появится система, например, с дополнительным увлажнением или ступенью нагрева, то мы просто добавим новую карточку с нужной информацией, при этом интерфейс будет выглядеть одинаково преемственно на разных устройствах и разрешениях. Точно так же легко унифицируются и различные системы, вентиляция, отопление, освещение, энергетика, водоснабжение и так далее, все это легко приводится к одному стандарту и упрощает взаимодействие пользователя.

Менюшка не поменялась, переходит из года в год без изменений. Цвета стали более темными, вернулась обводка некоторых элементов, цвет акцента остался синим, поменяв немного оттенок. Переменные больше не обрамляются прямоугольником или обводкой, без рамок они стали просторнее.

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

  1. Освобождаем интерфейс от всего лишнего, уменьшаем количество статических элементов, убираем все 3Д. Структурируем содержание по карточкам или вкладкам, оставляем больше места для динамических значение.

  2. Наводим порядок в цветах для удобства взаимодействия пользователя с интерфейсом. Оттенки темного цвета используются для фона, полей и заголовков, серым обозначаются подписи и весь текст в целом. Белый это переменные и все динамические значения. Яркий синий это цвет акцента, им обозначаются все элементы, с которыми пользователь может взаимодействовать, кнопки и уставки. И стандартные цвета: зеленый, желтый и красный, отвечают за состояние и индикацию.

Диспетчеризация торгово-развлекательного центра, окно вентустановки, монитор 32 дюймаДиспетчеризация торгово-развлекательного центра, окно вентустановки, монитор 32 дюймаСводное окно венткамеры, монитор 32 дюймаСводное окно венткамеры, монитор 32 дюймаГлавный экран с обзорной схемой вентустановок, монитор 32 дюйма.Главный экран с обзорной схемой вентустановок, монитор 32 дюйма.

В этом же году реализовали одну из самых масштабных задач с точки зрения количества передаваемой информации. Это торгово-развлекательный центр в Московской Области, оснащенной большим количеством инженерных систем. Остановлюсь только на интерфейсе систем вентиляции.

В этот интерфейс перетекли почти все наработки из предыдущего примера, но при этом я считаю этот интерфейс один из самых гармоничных и удачных. Здесь опытным путем нащупал палитру оттенков темно-синего цвета, который наиболее комфортный для глаз, эту палитру используем по сей день, она не меняется. Цвета стали лучше, ушли полностью тени, обводка стала более аккуратной, за счет этого интерфейс стал выглядеть лучше.

Здесь очень удачно планировка ТЦ вписалась в разрешение Scada системы примерно 1920 х 980 рх., это позволило расположить максимум полезной информации с привязкой к физическому местоположению. Так как систем много (около 150 штук) то лучший вариант разбить их по венткамерам, где находятся щиты управления, отобразить системы как название и подкрашивать его в зависимости от состояния. Серый выведен из эксплуатации, белый стоянка, зеленая работает, желтая требует обслуживания, красный авария. Дальше архитектура строится так: при клике на венткамеру открывается табличный вид связанных систем с их основными параметрами. При клике на название системы уже откроется мнемосхема со всеми доступными параметрами и настройками.

Хотя здесь есть некоторые не доработанные моменты: кнопки сброса, индикаторы аварии, зима/лето, все равно это один из самых удачных результатов работ за все время работы. На этом объекте мы провели много дней и ночей и все это время пользовались своей же работой, и по своим субъективным ощущениям, эксплуатировать технологические системы в этом интерфейсе максимально комфортно.

2020

Приточно-вытяжная установка с увлажнением, монитор 25 дюймовПриточно-вытяжная установка с увлажнением, монитор 25 дюймовПриточно-вытяжная установка с увлажнением, монитор 25 дюймовПриточно-вытяжная установка с увлажнением, монитор 25 дюймовОбзорная схема системы диспетчеризации, медицинский центр, монитор 23 дюймаОбзорная схема системы диспетчеризации, медицинский центр, монитор 23 дюймаОбзорная схема системы диспетчеризации ТРЦ Рассвет, Москва, монитор 23 дюймаОбзорная схема системы диспетчеризации ТРЦ Рассвет, Москва, монитор 23 дюймаМнемосхема приточно-вытяжной установки.Мнемосхема приточно-вытяжной установки.

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

Квадратные закругленные плашки на мнемосхеме превратились в круг. Если проследить за этими плашками, то можно увидеть, как они из квадрата медленно превращаются в круг. Круглый элемент выглядит на схеме лучше, он визуально освобождает больше пространства на самой схеме, делает ее лаконичнее, но при этом вылезает сразу несколько проблем. Рассмотрим водяной калорифер. У него есть несколько параметров, которые обязательно нужно показать на схеме: температура обратной воды, процент открытия клапана, статус работы насоса. Желательно еще показать статус термостата защиты от разморозки и разместить какую-то иконку, чтобы отличить узел нагрева от узла охлаждения. Как все это поместить в круг, чтобы при этом информация считывалась и не рушилась вся концепция придумать на этом этапе я не смог. Поэтому, на примерах сверху было два решения. Первое, убрать часть информации в нижнюю плашку меню или в другое место. Второе, просто сделать подложку под нагрев значительно больше, чем другие круглые элементы схемы и разместить все в ней. Оба варианта не самые лучшие, но иначе сделать не получалось. При этом все равно круглые элементы выглядят лучше и перспективнее прямоугольных.

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

Если вы дочитали до этого места, то скорее всего обратили внимание, что впервые появился светлый интерфейс =). Появилась очень интересная идея сделать универсальный интерфейс с темной и светлой темой и переключать его либо автоматически от времени суток, либо вручную. Реализовали эту идею так: подложки на 95 процентов прозрачные с небольшим оттенком серого, статические элементы имеют цвета не сильно контрастирующие на темном и светлом фоне, переменные имеют подобранный серый цвет, больше контрастирующий на темном и светлом фоне. По сути, мы только меняем цвет фона с белого на темно серый, а все элементы остаются без изменения. С точки зрения работы Scada системы процесс максимально простой, подмена одного фона на другой, без замены других элементов, это не перегружает процесс работы и отрисовки. У такого решения есть минус, сложно подобрать цвета одинаково правильно отображающиеся тут и там, от этого переменные немного теряются на общем фоне. Есть вариант вместе с фоном менять скриптами и цвета переменных и других элементов, но не понятно насколько это может загрузить процесс отрисовки.

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

2021

Главное окно системы диспетчеризации, логистический центр, МОГлавное окно системы диспетчеризации, логистический центр, МОМнемосхема приточно-вытяжной установкиМнемосхема приточно-вытяжной установкиЭкран работы вентустановки воздушного отопленияЭкран работы вентустановки воздушного отопленияОбзорная схема работы котельнойОбзорная схема работы котельной

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

В водяном нагревателе, как ранее уже писал нужно показать температуру обратной воды, процент открытия клапана, статус работы насоса и аварийный сигнал. Процент открытия клапан нагрева наиболее важное значение, поэтому я поместил его в центр и сделал большим шрифтом. Помимо самого значения, вокруг круглой плашки есть заполняющая его линия по кругу, она двигается по часовой стрелке и заполняет обводку круга пропорционально значению от 0 до 100. Температура обратной воды показан в круге, но уже меньшим шрифтом, и она поменяет свой цвет, если значение будет слишком низким. Если произойдет авария по термостату или по низкой температуре обратной воды, то вся обводка круга загорится красным цветом, инженеру будет понятно, что авария пришла именно с нагрева. Помимо этого добавил еще один режим "прогрев", в момент запуска вентиляции в зимнем режиме, перед пуском установки открывается клапан и прогревается до заданной температуры, в этот момент обводка плавно мерцает рыжим цветом. В стоянке в зимнем режиме обводка окрашена в белый цвет, означает, что насос работает, зимний режим включен, клапан поддерживает заданную температуру обратки. В летний период обводка становится серой и "выключается", тем самым мы понимаем, что водяной нагрев не активен.

С вентилятором ситуация аналогичная, внутри плашки мы можем показать текущую скорость в герцах или процентах, включен автоматический режим или ручной, можем показать состояние реле перепада давления, если оно есть. Обводка здесь состоит из двух секторов, они вращаются по часовой стрелке (против часовой на вытяжке), если вентилятор работает. Скорость вращения пропорциональная текущим герцам. Если с вентилятора приходит авария, то сектора окрасятся в красный цвет. В стоянке сектора имеют белый цвет.

С точки зрения Scada системы, мы имеем набор кадров (в нагревателе больше 100 кадров), которые меняются в зависимости от условий. Никаких GIF анимаций и наложенных слоев, отрисовка и реакция происходит мгновенно.

В остальном изменений мало и все они носят косметический характер. Изменился тумблер, доработаны иконки на обзорной схеме, изменились заголовки окошек меню, раньше у них была полоска контрастного цвета с надписью, теперь остался только текст за пределами подложки. Меню стали просторнее, отступы стали больше. Острых углов почти не осталось, все, что можно было скруглить - скруглили. Уделили внимание подписям и подсказкам, обозначения везде корректные и переменные уже не перепутать.

За все время работы я старался создать пользовательский интерфейс максимально удобный для клиента. Интерфейс должен быть не перегружен информацией, простой и удобный, современный и стильный. По итогу, на сегодняшний день, считаю, что с этой задачей мы справились.

2022

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

Надеюсь, вы нашли в статье что-то полезное для себя. Буду рад, если оставите свою критику и комментарии, напишите, какой интерфейс больше понравился вам и почему.

Подробнее..

Умный особняк

04.06.2021 10:04:57 | Автор: admin

Внутренности, скрывающиеся под измочаленными за последние годы стараниями маркетологов словами "умный дом" могут быть очень сильно разные. Как, например, под словом печь может подразумеваться и печь-буржуйка, так и доменная печь.

И если в предыдущей статье мы писали о построении вентиляции в историческом здании (Храме Спас-на-Крови), то в этот раз хочется рассказать о особенностях умного дома в большом особняке, а также о проблемах, которые приходилось решать при создании и автоматизации климатики в этом современном здании. Площадью под 3000 квадратов, с бассейном и СПА зоной.

Какие задачи стояли

По итогам формализации пожеланий заказчика мы договорились, что нами, как инженерами, в данном проекте должны быть решены следующие задачи:

  1. Поддерживать точный климат температуру и влажность во всех жилых помещениях.

  2. Обеспечить единое управление всем и вся с графического интерфейса

  3. Построить слаботочные и ИТ системы. В частности WiFi, который работает везде :)

Как решали климат и его автоматика

Поддерживать влажность - это достаточно сложно. Экспоненциально сложно, если сравнить с бытовым кондеем, висящим на стеночке. И требует много инженерки. Чтобы получить точную влажность и температуру в помещениях была запроектирована вентмашина о четырёх секциях. Первая секция умеющая нагревать воздух, вторая - увлажнять, третья - охлаждать, а четвертая - снова догревать...

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

Для доведения температуры до желаемой в отдельном помещении установлены радиаторы - для обогрева. И холодные потолки - для охлаждения без резких потоков воздуха. Плюс - тёплые полы - дабы было комфортно ходить босиком.

Система управления ("умный дом", или, если угодно - "умный особняк") в этом проекте была разделена на бэкенд (классическая система автоматизации/диспетчеризации на контроллерах Sauter) и фронт-енд (графический пользовательский интерфейс на базе ориентированных под это контроллеров Crestron; плюс сюда же задачи по управлению мультимедией). Общаются бэкенд и фроненд по сети по протоколу Bacnet/IP.

Более 600 датчиков (температуры, влажности, давления воздуха, движения); порядка 650 устройств, подключенных к выводам контроллеров (реле, приводов, клапанов, ...). Около 1600 переменных в SCADA системе. 53 контроллера автоматики и парочка контроллеров умного дома.

Немножко труб - тепловой пункт (БТП) живьём.Немножко труб - тепловой пункт (БТП) живьём.

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

скучные технические подробности :)

В составе системы автоматики были развёрнуты:

1. Комнатная автоматика, которая осуществляет:

- поддержание желаемой температуры воздуха путем управления отопительными приборами и холодными потолками;

- поддержание необходимой температуры теплого пола;

- контроль температуры, влажности воздуха;

- регулирование воздухообмена в комнатах, где предусмотрено курение;

- управление освещением, в том числе с димированием,

- управление шторами.

2. Автоматизация системы вентиляции, предусматривающая управление и контроль состояния:

- центральных кондиционеров дома (2 ед.) и СПА (2 ед.), выполняющих функции нагрева, охлаждения, увлажнения и осушения с целью круглогодичного поддержания заданной температуры и влажности приточного воздуха;

- вытяжных вентиляторов.

3. Автоматизация системы отопления предусматривает управление и контроль состояния:

- котельной;

- ИТП дома и ИТП СПА.

4. Автоматизация системы холодоснабжения, которая предусматривает:

- диспетчеризацию двух чиллеров;

- управление и контроль состояния двух узлов приготовления холодоносителя для холодных потолков.

5. Для управления и контроля состояния инженерного оборудования было предусмотрено:

- развёрнута Web-SCADA система;

- установлен диспетчерский компьютер;

- установлена панель в помещении охраны для отображения критичных аварий котельной и других систем;

- подключено мобильное устройство лица, ответственного за эксплуатацию, с выводом на данное мобильное устройство информации в объеме аналогичном диспетчерскому компьютеру.

И БТП в SCADA системе.И БТП в SCADA системе.

Умный дом

Что же касается фронтенда, то визуально для пользователя он выглядит как iPad'ы, установленные в ключевых помещениях на беспроводных зарядных док-станциях, позволяющих одним движением снять планшет.

Управление всем набором запроектированных дизайнером светильников в гостинойУправление всем набором запроектированных дизайнером светильников в гостиной

iPad'ы в режиме киоска с установленным ПО, обеспечивающим управление климатом, освещением и мультимедией комнаты с единого интерфейса. Также можно переключать сценарии освещения, димировать заданные группы освещения, управлять шторами, управлять аудио-видеооборудованием, наружной подсветкой дома, освещением сада и многое другое.

Также управление освещением продублировано с настенных выключателей. Особое внимание было уделено отказоустойчивости системы включение/выключение света будет возможно даже при выходе из строя контроллеров автоматики.

Дополнительной вишенкой на торте является система позиционирования, позволяющая в автоматическом режиме определять, в каком помещение находиться хозяин дома с главным, Master iPadом и выводить на экран планшета соответствующую страницу меню управления. С точки зрения техники, данный функционал реализован на Bluetooth BLE маячках (BLE PinPoint beacons), установленных по дому. При появления iPad в поле их действия, софт на iPadе сигнализирует о событии центральному контроллеру и получает команды на определенные действия. Никакие датчики в пользователя не встраиваются ;)

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

ИТ системы

Для обеспечения доступа хозяев дома в интернет, а также для работы системы управления во всём комплексе зданий развёрнута единая сеть WiFi, позволяющая перемещаться по помещениям, сохраняя соединение. В том числе не прерывая разговора по голосовым мессенджерам. Учитывая сложную радиообстановку (толстые стены, крайне высокое затухание сигнала), сеть создана на базе аппаратного контроллера WiFi и нескольких десятков WiFi точек доступа. Штукатурная сетка, появившаяся после радиопланирования и радиообследования объекта - добавила сложностей. Но в итоге всё кончилось хорошо - нас не расстреляли :)

Также на объекте создана проводная сеть Ethernet, обеспечивающая подсоединение всего оборудования: контроллеров автоматики, точек доступа WiFi, аудио-видео оборудования, камер видеонаблюдения. Для увеличения надёжности система разбита на сегменты VLAN.

Система фонового озвучивания обеспечивает простое воспроизведение музыки как с устройств Apple (через беспроводное Wi-Fi подключение, с использованием технологии AirPlay), так и воспроизведение интернет радио, CD, MP3 в зонах бассейна, SPA и веранды.

Что можно было бы сделать лучше.

По итогам эксплуатации считаю, что надо было настоять на использовании специализированных тач-панелей от производителя системы управления. Используемые в качестве сенсорных пультов управления выделенные iPad'ы в долговременной перспективе требуют к себе больше внимания, чем хотелось бы. То, несмотря на все настройки, обновляться соберутся, то ещё что-нибудь придумают :)

И да, замечания к дизайну SCADA, полученные в комментариях к прошлой статье, мы приняли с благодарностью. Но этот проект был реализован немножко раньше предыдущей статьи и учесть в нём замечания не представлялось возможным ;)

Заключение

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

Автор Кирилл Осовский, komrus@yandex.ru

Подробнее..

Кейс аналитика системы освещения в логистическом центре

17.06.2021 20:21:19 | Автор: admin

Поделюсь одним интересным кейсом, как мы сделали пилотный проект системы контроля освещением и что из этого получилось.

Клиент: крупный логистический центр в Московской Области, с которым мы работаем с 2016 года. За это время мы провели уже много работ по диспетчеризации инженерных систем, вывели в единую BMS вентиляцию, котельную, энергетику, отопление, энергоучет и много чего еще. А в этом году решили добавить еще и диспетчеризацию освещения в общую систему.

Что имеем? Установлен силовой шкаф управления освещением на 45 линий: складские ряды, коридоры, мезонин. На каждой линии установлен автомат защиты и модульный контактор. Помимо силового щита есть щит управления с ручным и автоматическим управлением. Автоматическое управление подразумевает включение и выключение линии по датчику движения, которые установлены в рядах, где двигается техника. Некоторые линии находятся в ручной режиме и постоянно включены, а некоторые, наоборот выключены. Задачу нам поставили следующую: отслеживать работу каждой линии, отслеживать залипание контакторов, оповещать о неисправностях и получать аналитику по наработке. Можно было бы полностью заменить шкафы, сделать дистанционное управление, расписание и много чего еще, но это было бы очень сильное удорожание проекта, а нас попросили именно вписаться в небольшой бюджет не меняя того, что и так работает стабильно.

Задача поставлена, начинаем реализацию. Есть несколько способов отследить работу линии освещения. Самый простой способ это использовать свободный или дополнительный контакт модульного контактора. Но конкретно в нашем случае эта схема не сработает, так как питание катушки контактора идет от общего автомата и возможна ситуация, когда на линии освещения контактор будет замкнут, а автомат выключен и питания на линии не будет. Этот способ будет работать только если питание катушки контактора идет из под автомата этого же контактора. Можно было бы поставить дополнительные контакты положения и сработки к автоматам, это даст более полную картину, но в нашем случае места в шкафу не было от слова совсем и раздвинуть автоматы для дополнительных контактов просто не было возможности. Решили пойти самым надежным путем, взять непосредственно фазу, идущую на питание линии и завести ее на контроллер. Так как у нас большая часть автоматики на объекте сделана на отечественных Контарах, то мы просто взяли модули расширения, которые воспринимают 220 вольт на входе. Это не частая опция у контроллеров, поэтому, если бы стоял другой производитель, пришлось бы ставить 45 промежуточных реле. Получился аккуратный и не большой шкаф диспетчеризации, мы повесили его рядом с силовым шкафом и обвязали все аккуратно многожильным кабелем. Расключение шкафа и отключение света согласовали заранее, а на все работы ушло около 1,5 часов.

Подключаем сигнальные линииПодключаем сигнальные линии

С физикой все просто и понятно, после всех работ мы имеем 45 булевых переменных, которые мы добавили в скаду, настроили им архивацию и оставили это все работать на неделю.

Силовой шкаф до расключенияСиловой шкаф до расключения

Дальше разрабатываем интерфейс пользователя.

Основное окно секции освещения Основное окно секции освещения

Здесь 46 линий разбитые на 2 экрана. Порядковый номер, состояние линии (включена, выключена, неисправна) и комментарий. Внизу есть оперативный график, можно посмотреть, как менялось состояние линии за последний час. Линии можно переключать, на скриншоте выбрана 16 линия.

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

Окно с настройкамиОкно с настройками

В этом окне мы вывели гибкую возможность настроек оповещения о залипании линии. Есть скрипт, который срабатывает по изменению переменной, в нашем случае булевой переменной с контроллера. Скрипт сравнивает новое значение с предыдущим, и если переменная изменила свое значение, то происходит сброс таймера наработки этой линии. Сравнение переменной нужно для того, чтобы если связь с ОРС не устойчивая, то не происходил сброс всех переменных одновременно.

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

Временные трендыВременные тренды

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

Отчет за выбранное времяОтчет за выбранное время

Дальше переходим к отчетам. Отчет можно сформировать за выбранный промежуток времени, за сутки или по часам. В отчете формируются данные по наработке и простою каждой линии, а также количество включений. Эта информация оказалась очень полезной для бизнеса предприятия, так как есть статистика по использованию и контролю производственного освещения. В отчете отлично видно, что ряд К17 используется намного чаще, чем другие ряды. При этом ряд К11 не выключался за эти дни вообще.

Отчет за выбранное времяОтчет за выбранное время

Вторая страница отчета выводит ту же информацию, но в виде диаграмм.

По итогу нашего проекта мы смогли создать систему диспетчеризации и аналитики освещения без какого-либо вмешательство в текущую работу системы освещения. Мы преследовали цель в первую очередь отслеживать состояния контакторов и автоматических выключателей, выявлять неисправности силовой части и своевременно оповещать эксплуатацию об этом. Но, в дополнение к основной задаче мы получили еще и очень полезную информацию для бизнеса и логистики.

Подробнее..

Заказная разработка контроллеров для IIoT

04.12.2020 20:21:06 | Автор: admin
В большинстве проектов промышленного Интернета вещей (IIoT) заказчики используют контроллеры, с которыми работали раньше или рекомендованные поставщиками систем верхнего уровня. При этом счет IIoT контроллеров на рынке, из которых можно выбирать, идет на тысячи.


Не всем известна опция разработки оборудования на заказ. Для большинства промышленных контроллеров не нужен дальний космос в виде уникального функционала или дизайнерского корпуса. При удачном выборе подрядчика, имеющего необходимые наработки, за 2-3 месяца можно сделать опытные образцы, а еще через пару месяцев начать серийное производство. Разработка может окупиться за счет использования недорогой элементной базы и реализации нужного количества функций под конкретный проект. Комплекс оборудования на объекте будет состоять из минимального количества устройств (часто одного), а значит будет меньше работ по сборке, установке и пуско-наладке.

Заказная разработка железа давно не является уделом избранных заказчиков с огромными бюджетами. Однако, имеется ряд особенностей, с которыми лучше ознакомиться на собственном чужом опыте до начала проекта.


Шаг 1. А есть ли готовое?


Можно серьезно сэкономить, подобрав оборудование под проект, например, на этом сервисе.

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

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

Шаг 2. Выбор подрядчика: КогдаСколькоПочем и защита от итальянской забастовки


Если решено разработать собственное оборудование и под боком нет исполнителей, пора искать подрядчика. Оптимально начать с компаний, уже выпускающих то, что нужно. Важно понять, нужны ли права на разработку, исходники конструкторской документации (КД) и встроенного программного обеспечения (ВПО), либо достаточно иметь эксклюзив (на территорию внедрения, дизайн, ). Компании-разработчики могут отказаться от работы на условиях, интересующих заказчика, либо предложить заградительные цены. Самым дешевым вариантом может оказаться не полноценная разработка, а доработка или OEM поставка оборудования под вашим брендом. Однако, и этот вариант несет в себе риск можно вырастить себе конкурента.

Если договориться не получилось, надо искать подрядчика по рекомендациям, либо в Сети по запросу контрактная разработка электроники. В помощь к работе с кандидатами вопросы из чек-листа ниже.

Для предварительно выбранного подрядчика(ов) надо сформулировать первичные требования к оборудованию. Чем детальнее будут требования, тем проще будет определить стоимость работ и время разработки образцов. Также можно показать подрядчику(ам) интересующие примеры готового оборудования.

Со встречи с потенциальным партнером надо уходить с ответом на вопрос когдасколькопочем?. Об этом часто забывают. Ожидания заказчика (цены, сроки) могут оказаться сильно меньше запросов подрядчика. Если в итоге их удалось синхронизировать, можно переходить к согласованию:

  • тезисной концепции: ТЗ крупными мазками, сроки, стоимость разработки,
  • цен на изделия в партиях, сроков поставки,
  • условий договора (права, исходники, эксклюзив).

Не все можно зафиксировать в договоре. Подрядчик может объявить итальянскую забастовку, за которую его нельзя будет наказать. Также могут возникнуть непредвиденные сложности или новые требования, по которым придется работать больше, чем договаривались. Для того, чтобы защититься от перечисленных проблем, можно использовать простые принципы:

  • При выборе подрядчика обязателен человеческий контакт. Идеальных заказчиков и подрядчиков не бывает, но совершенно реально найти партнера с которым будет комфортно работать именно вам.
  • Отлично, если подрядчик проявляет инициативу и искренне болеет за дело (можно понять по ответу на вопрос как решали серьезные проблемы в прошлом?).
  • Подрядчик должен быть управляемым. Соответственно, он должен слушать и слышать заказчика, а не только себя.

Чек-лист выбора подрядчика


Требование Оценка
Предварительное попадание в сроки и бюджет
Человеческий контакт достигнута ли синергия с заказчиком или постоянно на разных волнах
Готовность предоставления исходников (КД, тексты ПО), прав, эксклюзива по продаже (по необходимости)
Соответствие портфолио / услуг (опыта подрядчика) задаче
Наличие достойных примеров борьбы с проблемами
Наличие необходимых специалистов в команде
Наличие шаблонов документов (договор, ТЗ, руководства, )
Увлеченность делом: интересные идеи, инициативность, ответственность
Желание разобраться в специфике, умение слушать

Шаг 3. Согласование ТЗ на IIoT контроллер


Только полное соответствие результата разработки ТЗ является основанием для приемки работ и окончательной оплаты. Внесение изменений в требования после заключения договора может быть болезненным, поэтому очень важно ответственно поработать над текстом ТЗ с обеих сторон. Цена ошибки на последующих этапах будет существенно выше.

Согласование типа конструктива


Как известно, устройство должно работать не в принципе, а в корпусе. Старт обсуждения ТЗ с корпуса, позволит обеим сторонам представить с первых минут, что за устройство получится в итоге.

Для каждого применения и проекта оптимален свой форм-фактор:

  • Для энергетики, промышленной автоматики и учета ресурсов используют корпуса на DIN рейку 35мм. Пожалуй, это самый популярный формат для промышленного IoT, однако, не является серебряной пулей для всех случаев;
  • Для систем связи используют модули в 19 стойку. Они бывают различной высоты, которую измеряют в U (44,45 мм).
  • В 19 стойку также могут устанавливать крейты (или кассеты). В них вставляют нужное количество модулей, конструктив которых объединяют понятием Евромеханика.
  • Для контроля доступа и размещения отдельно стоящих компактных устройств применяют корпуса в настольном и/или настенном исполнении,
  • Существует специализированные корпуса, в том числе: антивандальные, защищенные от воды и пыли (по международным кодам IP), приборные и т.п.
  • Наконец, бывают устройства без корпуса, устанавливаемые внутрь бОльших устройств, либо устройства, состоящие из платы и передней панели (в частности, модули Евромеханики).


Часто конструктив выбирают по аналогии с готовыми устройствами (с рынка). В некоторых случаях это является ошибкой, поскольку дорогой фирменный корпус (с обработкой, маркировкой, системой соединителей и пр.) может стоить до 50% от себестоимости изделия. Для справки: аналогичная доля для бюджетного корпуса может составлять менее 5%.

Выбор процессорного ядра


В бюджетных устройствах обычно используют однокристальные микроконтроллеры (MCU), с оперативной памятью (RAM) и ПЗУ (Flash) в одном корпусе. Большинство устройств тянет компактную операционную систему (ОС) типа FreeRTOS или TNKernel, а может работать и без ОС. Будем называть их RTOS контроллерами.

В более мощных контроллерах используется процессор (CPU) с внешними микросхемами RAM и Flash. Большинство таких устройств использует различные версии ОС Linux (Linux контроллеры) или менее распространенные ОС типа VхWorks или Windows CE (здесь не рассматриваем). Сделать плату на современном процессоре не так просто: на плате от 4-х до 10-ми слоев нужно расположить несколько BGA корпусов с достаточно строгими требованиями к питанию, геометрии и длинам дорожек. Для упрощения жизни разработчиков предлагаются сотни процессорных модулей, которые могут быть выполнены в виде дочерней платы с разъемами или краевыми контактами под пайку (см. ниже).


Также на рынке появляются микросхемы System on chip (SoC), содержащие процессор и память большого объема, достаточную для работы Linux. Разводка SoC значительного проще, чем набора CPU+RAM+FLASH. Кроме этого, SoC-и могут быть очень бюджетными.

Ниже приведены типовые характеристики и цены для нескольких примеров процессорных ядер от ARM, которые могут быть использованы в IIoT контроллерах.


Часто оправдано использование в одном контроллере двух процессоров: мощного для ресурсоемких приложений и небольшого однокристального для простых приложений реального времени.


Согласование требований к системе питания


В зависимости от типа объектов определяются требования к блоку питания, который может быть, как внешним, так и встроенным в устройство:

  • домашнее/офисное применение, энергетика ~220/380В,
  • телеком 3672В (станционное питание) и PoE,
  • промышленная автоматизация 18...36В,

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

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


Для всех российских устройств необходимы сертификаты ЕАС на электробезопасность и электромагнитную совместимость. Для прохождения испытаний нужно уметь проектировать фильтры и топологию плат, а также правильно выбирать компоненты.

Порты связи


Распространенные интерфейсы, используемые в IIoT контроллерах, показаны в таблице ниже. Выбор типов и количеств под задачу и бюджет.

Для связи через IP сеть Для связи через промежуточный HUB Для локальной связи на объекте
*Wired Ethernet *RS485 / 422 RS232
Cell 2G/GPRS 4G/LTE *CAN USB
Optical Ethernet PLC (G3, Prime) 1-wire, s-wire (для цифровых датчиков)
Optical GPON Radio: LoRA, NB-Fi (Rus), UNB Radio: Zigbee, 6loWPAN, ISM 433/868/2400 Mhz

* может использоваться и для локальной связи c оборудованием на объекте

Входы и выходы


Для подключения датчиков контроллеры оснащаются дискретными, счетными и аналоговыми входами. Аналоговые входы могут быть потенциальными (например, на 0..10VDC или изолированными на 220VAC), либо токовыми (4..20mA, NAMUR, пожарными). Для реализации выходов используют реле (обычные и полупроводниковые, например, оптосимисторы), а также транзисторы, включенные по схеме открытый коллектор (ОК).

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

Для уменьшения габаритов и экономии разъемов используют универсальные порты, выполняющие разные функции в зависимости от настроек, и использующие одни и те же контакты. Например, дискретный вход с функцией выхода ОК.

Индикация


Продолжительное время в IIoT устройствах было достаточно использовать несколько светодиодов. В более продвинутых контроллерах использовали телевизоры линейки семисегментных LED индикаторов, электролюминесцентные, текстовые или графические LCD индикаторы. Но от телевизоров чаще все-таки отказывались из-за их дороговизны и небольшой пользы при эксплуатации.

Сегодня телевизоры стали модными буквально везде: от автомобилей до умных домов. Появляется все больше конкурсов, в которых наличие экрана обязательно и для IIoT устройств.


Хорошая новость в том, что стоимость LCD или OLED индикаторов уменьшается, а мощность процессоров, необходимая для графического вывода, растет. По этой причине телевизор перестает быть дорогой опцией.

Модельный ряд


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

Советую добавить этот пункт в ТЗ.

Требования к встроенному программному обеспечению


Разработка ВПО может занимать до 80% от времени реализации всего проекта. Поскольку данный пост про железо, ограничусь перечислением основных функций, которые должны быть реализованы практически в любом IIoT контроллере:

  • Обмен данными с системой верхнего уровня, в том числе, передача экстренных оповещений;
  • Обмен данными с нижестоящими устройствами и датчиками;
  • Управление исполнительными механизмами;
  • Обновление ВПО с защитой от перебоев питания и связи;
  • Хранение настроек и их восстановление;
  • Администрирование устройства с защитой от несанкционированного доступа;
  • Ведение журналов событий;
  • Анализ данных и формирования воздействий и событий (Edge логика);
  • Синхронизация системного времени;

Проектная работа с подрядчиком


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

Разработка нового IIoT контроллера это сравнительно небольшой проект, для успеха которого, тем не менее, нужна слаженная работа сотрудников заказчика и исполнителя. Со стороны заказчика сразу нужен руководитель проекта, а позже инженер(ы) тестирования (без независимого тестирования продукта не сделать). Более того, обычно разработка передается на условиях As is. После подписания актов и оплаты работ доказать необходимость исправления по гарантии сложно.

Про проектное управление написаны сотни книг. В разрезе разработки контроллеров я выделяю следующие обязательные моменты:

  • В начале работ нужен устав проекта (цели, проектная команда, деньги, сроки, ), и календарный план;
  • В процессе реализации необходим периодический контроль календарного плана и его корректировка;
  • Если в процессе работ внедряются хорошие идеи или новые требования, которых не было в ТЗ, то их надо вносить в реестр изменений. Ценность таких идей может значительно превышать дополнительную стоимость (обычно до 10% от первоначальной стоимости работ).
  • По результатам испытаний нужны протоколы, которые будут использоваться, как основание для доработок и оплат.
  • Хорошей практикой является подведение итога по проекту после его завершения. Часто этот момент пропускают, хотя итоговый отчет прекрасная страховка от граблей в будущих аналогичных проектах, а также основание для наказания невиновных награждения героев.

Хорошие формы документов по проектному управлению здесь.

Заключение


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


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

  • анализ рынка,
  • выбор подрядчика (например, нас),
  • согласование ТЗ.

Далее предстоит работа с выбранным подрядчиком: разработка опытных образцов, производство и поддержка. Цены на заказные контроллеры, их монтаж и пуско-наладку могут быть значительно ниже по сравнению с использованием готового оборудования. Дополнительными ценностями для заказчика будут:

  • развитие собственного бренда,
  • реализация специфического набора аппаратных функций и
  • получение статуса отечественного производителя (актуально для участия в конкурсах).
Подробнее..

CodeSys на RaspberryPi 3 model B для реальных целейMS SQL. Расчет метража продукции, произведенной на гофроагрегате

22.01.2021 12:16:53 | Автор: admin

Оглавление

  1. Расчет метража и площади произведенной продукции (немного матриц)

  2. Затраты

  3. Выгрузка данных с помощью PyODBC

  4. Выгрузка данных с помощью MsSQL Library SL

Расчет метража и площади произведенной продукции (немного матриц)

Матрица метража произведенной продукции по профилям и по форматам представляет собой двумерный массив А 6*6, который подразделяется на двумерный массив В p*f, где p=5 профиль гофры, f=5 формат, и одномерные Zp сумма произведенных метров по профилям гофры и Zf - сумма произведенных метров по форматам. Соответственно матрица Zp одномерная матрица из 5-ти элементов, предстваляет собой сумму столбцов матрицы А, Zf одномерная матрица из 5-ти элементов, предстваляет собой сумму строк матрицы А. Остается один не заполненный элемент a66, эта ячейка будет общей длиной произведенной продукции.

Так же потребовалось еще 2 одномерные матрицы: Sp площадь произведенной продукции по профилям и Sf площадь произведенной продукции по форматам и матрица- константа F одномерная матрица из 5-ти элементов перечень форматов сырья.

Разобрались с заполнением! Теперь начинается алгебра.

Сумма по форматам и по профилям рассчитывается путем сложения строк и столбцов, соответственно, исходной матрицы А.

Расчет площадей по форматам очень прост, мы просто перемножаем 2 матрицы А и F

или

Площадь по профилям гофры:

Листинг функционального блока
FUNCTION_BLOCK Format_mathVAR_INPUT    EN:BOOL;    imp:BOOL;END_VARVAR_INPUT RETAIN    f:INT := 1;    p:INT := 1;END_VARVAR_INPUT    l_roll:REAL;    k_imp:INT;    res:BOOL;    res_month:BOOL;END_VARVAR_OUTPUT    // массив [f,p], f=6 - сумма по профилям, p=6 - сумма по форматам    length_f:ARRAY[1..6, 1..6] OF REAL;    wS_f:ARRAY [1..5] OF WORD;    wS_p:ARRAY [1..5] OF WORD;END_VARVAR_OUTPUT RETAIN    S_f:ARRAY [1..5] OF REAL;    S_p:ARRAY [1..5] OF REAL;END_VARVAR_OUTPUT    S_f_month:ARRAY [1..5] OF REAL;    S_p_month:ARRAY [1..5] OF REAL;END_VARVAR    imp_old:BOOL;    f_b: ARRAY [1..5] OF BOOL;    p_b: ARRAY [1..5] OF BOOL;    length_f_old:ARRAY[1..6, 1..6] OF REAL;    i:BYTE;    j: BYTE;    k:REAL;END_VARBEGIN  k:=l_roll/(k_imp*1000);  IF EN AND not imp AND imp_old THEN      length_f[f,p]:=length_f[f,p]+k;      //length_p[p]:=length_p[p]+(l_roll/(k_imp*1000));  END_IF  FOR i:=1 TO 5 DO       length_f[i,6]:=0;      length_f[6,i]:=0;      FOR j:=1 TO 5 DO           length_f[i,6]:=length_f[i,6]+length_f[i,j];          length_f[6,i]:=length_f[6,i]+length_f[j,i];      END_FOR   END_FOR  CASE f OF          1: S_f[f]:=length_f[f,6]*1.050/1000;          2: S_f[f]:=length_f[f,6]*1.250/1000;          3: S_f[f]:=length_f[f,6]*1.400/1000;          4: S_f[f]:=length_f[f,6]*1.575/1000;          5: S_f[f]:=length_f[f,6]*1.600/1000;  END_CASE  FOR i:=1 TO 5 DO       S_p[i]:=length_f[1,i]*1.05/1000+length_f[2,i]*1.25/1000+length_f[3,i]*1.4/1000+length_f[4,i]*1.575/1000+length_f[5,i]*1.6/1000;      wS_p[i]:=REAL_TO_WORD(S_p[i]*10);      wS_f[i]:=REAL_TO_WORD(S_f[i]*10);  END_FOR  IF res THEN      FOR i:=1 TO 6 DO           FOR j:=1 TO 6 DO               length_f_old[i,j]:=length_f[i,j];              length_f[i,j]:=0;          END_FOR       END_FOR      FOR i:=1 TO 5 DO          S_f_month[i]:=S_f_month[i]+S_f[i];          S_f[i]:=0;          S_p_month[i]:=S_p_month[i]+S_p[i];          S_p[i]:=0;      END_FOR  END_IF  IF res_month THEN      FOR i:=1 TO 5 DO           S_f_month[i]:=0;          S_p_month[i]:=0;      END_FOR  END_IF  FOR i:=1 TO 5 DO f_b[i]:=0; END_FOR  FOR i:=1 TO 5 DO p_b[i]:=0; END_FOR  f_b[f]:=TRUE;  p_b[p]:=TRUE;  imp_old:=imp;END

Затраты

  • RPI 3 model B за 4 тысячи рублей (на AliExpress 3 тыс. руб.). Можно было обойтись и более дешевой RPI zero (2 тыс. руб.), но рамки системы изначально были размыты несуществующим ТЗ (давай сперва сделаем так, а потом посмотрим, нужно еще то то и то);

  • Плата с опторазвязками 24/5В на AliExpress 300 руб. (в России не нашел уже готовой платы);

  • CODESYS Control for Raspberry Pi SL 50 евро. В демо-режиме работает в RealTime 2 часа, после необходима перезагрузка;

Выгрузка данных с помощью PyODBC

Установка ODBC на Raspberry

Организуем доступ в интернет и прописываем пару команд:

pi@raspberrypi:~ $ sudo apt-get install python3-dev unixodbc-dev gitpi@raspberrypi:~ $ git clone https://github.com/mkleehammer/pyodbcpi@raspberrypi:~ $ cd pythodbcpi@raspberrypi:~ $ import pyodbcpi@raspberrypi:~ $ python3 setup.pypi@raspberrypi:~ $ cd /home/pi/pyodbcpi@raspberrypi:~ $ sudo python3 setup.py buildpi@raspberrypi:~ $ sudo apt-get updatepi@raspberrypi:~ $ sudo apt-get install g++pi@raspberrypi:~ $ sudo apt-get install unixodbc-devpi@raspberrypi:~ $ pip install pyodbcpi@raspberrypi:~ $ odbcinst -jpi@raspberrypi:~ $ cat /etc/odbcinst.ini[FreeTDS]Description=FreeTDS Driver v0.91Driver=/usr/lib/arm-linux-gnueabihf/odbc/libtdsodbc.soSetup=/usr/lib/arm-linux-gnueabihf/odbc/libtdsS.sofileusage=1dontdlclose=1UsageCount=1pi@raspberrypi:~ $ cat /etc/odbc.iniDriver = FreeTDSDescription = My Test ServerTrace = NoServerName = mssql#Port = portinstance = MSSQLSERVER #(whatever is the service u r runningcould be SQLEXPRESS)Database = database_nameTDS_Version = 4.2pi@raspberrypi:~ $ sudo nano /etc/freetds/freetds.conf[egServer70]        host = ntmachine.domain.com        port = 1433        tds version = 7.0[mssql]        host = server_ip_adress        instance = MSSQLSERVER        #Port = port         tds version = 4.2

Проверяем доступ к нашей базе данных.

pi@raspberrypi:~ $ sudo python3>>> server = '192.168.1.2'>>> port = '1433'>>> database = 'GA' >>> username = 'plc' >>> password = '123456' >>> cnxn = pyodbc.connect('DRIVER={FreeTDS};SERVER='+server+';PORT='+port+';DATABASE='+database+';UID='+username+';PWD='+ password)>>> cursor = cnxn.cursor()>>> cursor.execute('select top 10 ID,Val,Date_Time from tbl_Val')#cursor.execute('INSERT INTO tbl_Val (ID, Val) VALUES (15, 20)')>>> rows=cursor.fetchall()>>> for row in rows: print(row.ID, row.Val)

В репозитории /home/pi/pyodbc/ необходимо создать файлquery.py. Здесь будет код, для вызова из нашей подпрограммы.

import pyodbcimport syscnxn = pyodbc.connect('DRIVER={FreeTDS};SERVER='+sys.argv[1]+';PORT='+sys.argv[2]+                      ';DATABASE='+sys.argv[3]+';UID='+sys.argv[4]+';PWD='                      + sys.argv[5])cursor = cnxn.cursor()cursor.execute('INSERT INTO [Py_Tbl] ([ID], [Val]) VALUES ('+sys.argv[6]+','               +sys.argv[7]+')')cnxn.commit()

Вышеизложенный скрипт имеет 5 параметров подключения и 2 аргумента, подлежащие записи в БД:

  • Сетевое имя или IP адрес сервера;

  • Порт подключения (у MSSQL стандартный порт 1433);

  • Имя базы данных;

  • Логин;

  • Пароль;

  • ID значения;

  • Значение.

Далее в функциональном блоке SQL_Insert программы ПЛК формируем строку запуска скрипта с перечислением в ней всех параметров и аргументов

Листинг функционального блока
FUNCTION_BLOCK SQL_InsertVAR_INPUTxExecuteScript: BOOL;Server:STRING := '192.168.1.2';PORT:INT := 1433;DB_Name:STRING := 'GA';login:STRING := 'plc';password:STRING := '123456';ID: INT;Val: REAL;END_VARVARpResult: POINTER TO SysProcess.SysTypes.RTS_IEC_RESULT;Text: string;END_VARBEGIN  IF xExecuteScript THEN    text:='sudo python /home/pi/pyodbc/query.py ';    text:=concat(text,Server);    text:=concat(text,' ');    text:=concat(text,INT_TO_STRING(Port));    text:=concat(text,' ');    text:=concat(text,DB_Name);    text:=concat(text,' ');    text:=concat(text,login);    text:=concat(text,' ');    text:=concat(text,password);    text:=concat(text,' ');    text:=concat(text,INT_TO_STRING(id));    text:=concat(text,' ');    text:=concat(text,REAL_TO_STRING(Val));    SysProcess.SysProcessExecuteCommand(text,pResult);    xExecuteScript:=FALSE;  END_IFEND

По сути программа ПЛК формирует строку запуска query.py и посылает в него аргументы. Это равносильно следующему запросу:

pi@raspberrypi:~ $ sudo python /home/pi/pyodbc/query.py server port DB_name login pass id Value

В функциональном блоке DB_send задается период отправки данных, формируются массивы ID из 10 ячеек типа integer и Val из 10 ячеек типа real.

Листинг функционального блока
FUNCTION_BLOCK DB_SendVAR_INPUTid:ARRAY[1..10] OF INT;val:ARRAY[1..10] OF REAL;Time_send:TIME :=T#60S;END_VARVARSQL_Ins: SQL_Insert;TONInst: TON;i: int;END_VARBEGIN  TONInst(IN := NOT(TONInst.Q), PT:= Time_send);IF  TONinst.Q THENFOR i:=1 TO 10 DOIF id[i]<>0 THENsql_ins(xExecuteScript:=true, ID:=id[i], val:=val[i]);END_IFEND_FOREND_IFEND

Как все это работает? Каждый цикл программы в DB_Send из остальных ФБ перекладываются данные, по истечению заданного времени, сопоставляются ID->Val и отправляются в SQL_Inset для формирования строки вызова Python скрипта. Методом pyodbc.connect подключаемся к базе данных и cursor.execute отправляет SQL-запрос INSERT Данные в базе.

Выгрузка данных с помощью MsSQL Library SL

Еще один способ выгрузки данных в БД является готовый инструмент от 3S-Smart Software Solutions GmbH MsSQL Library SL это закрытый и дорогой (200) набор инструментов для прямого подключения ПЛК, чтения и записи данных в БД MsSQL без использования OPC-сервера. Использует TDS протокол. В демо-режиме работает 2 часа, забегая на перед, скажу, что работает крайне нестабильно, полные 2 часа не отработала, подключение с БД регулярно пропадало, не идет ни в какое сравнение со стабильностью работы бесплатной PyODBC.

Поддерживаемые команды:

  • SELECT

  • INSERT

  • UPDATE

  • DELETE

  • Execute Stored procedures

Эта библиотека содержит 5 функций для преобразования данных из типов данных SQL в IEC:

  • BOOL

  • DINT

  • REAL

  • STRING

  • DATETIME

Состоит из 4-х функциональных блоков:

  • fbMsSQL_compact для компактного соединения и связи с базой данных

  • fbMsSQL для связи с базой данных

  • fbPing для проверки доступности удаленного хоста

  • fbFIFOQuery для обработки большего количества запросов SQL во времени

Имеет 4 default-шаблона визуализации

  • учетные данные для входа

  • процедура входа

  • окно запроса

  • окно ответа

В store.codesys.com скачиваем и устанавливаем пакет. После установки пакета MsSQL Library SL в директории ..\CODESYS MsSQL SL Library\V1.4.0.5\Examples\Raspberry Pi target распаковывается наглядный пример использования библиотеки.

Страница подключения к БД и отображения данных.

Подробнее..

Веселые уроки WinCC OA. Установка WinCC OA под Debian и перенос прикладного проекта

30.12.2020 08:08:41 | Автор: admin

Скачивая недавно с сайта winccoa.com установщик последнего патча версии 3.17, с некоторым удивлением, постепенно перешедшим в ликование, обнаружил, что список поддерживаемых дистрибутивов Linux расширился и до Debian. Дело в том, что посмотреть на работу системы в ОС, отличной от Windows, мне хотелось давно, но из всех дистрибутивов Linux я более-менее понимаю только Debian, а привыкать к новому ради баловства откровенно не хотелось. Собственно, и под Debian установка проходит не сильно гладко.

Итак, по порядку. Считаем, что дистрибутив уже скачен с сайта. Лицензия у меня установлена на виндовую машину, да она особо и не нужна. В домашней директории пользователя (он должен находится в группе sudoers'ов) создаю директорию winccoadist, куда распаковываю содержимое скаченного архива.

Запускаю терминал (как обычно, нажатием CTRL+ALT+T) и перехожу в свою директорию с дистрибутивами. Смотрю список файлов.

В связи с тем, что никаких репозиториев тут нет, пакеты являются файлами, необходимо провести установку в правильной последовательности. Вначале установить пакет системы лицензирования codemeter, потом базовый пакет WinCC OA, а далее опциональные пакеты, среди которых мне интересны демо-проекты (Applications), справка на русском и английском (Help) и драйвер S7Plus. Как это частенько бывает в чудесном мире бесплатного линукса некоторые вещи сделаны через такое место, которое в приличном обществе все или почти все называют задницей. Касается это как самих дистрибутивов, так и поставщиков ПО под них. Предвижу ворчание со стороны опытных *nix'оидов, однако с обывательской точки зрения вот так... а я простой обыватель, поймите правильно Для установки пакетов в Debian обычно применяются команда apt, которая сама умеет проверять зависимости пакетов. Поэтому первые два ставим через apt. Для этого в терминале вводим команду

sudo apt install ./codemeter_7.10.4196.501_amd64.deb

и ждем ее завершения.

Далее устанавливаем базовый пакет WinCC OA, который содержит основную инсталляцию все менеджеры, ядро и т.д.

sudo apt install ./WinCC_OA_3.17.9-Base-debian.x86_64.deb

Установка так же завершается успешно. Можно даже посмотреть и убедиться, что система установилась, и ее можно запускать. Правда, в моем случае мне потребовалось вначале закрыть текушую сессию пользователя и залогиниться в систему заново.

Пока что все неплохо, тот же Project Administrator успешно запустился.

А вот с дополнительными пакетами все сложнее. Команда apt по непонятным мне причинам находит неразрешенную зависимость и отказывается ее устанавливать. Причем, ругается на, якобы, неустановленный базовый пакет WinCC OA. Складывается ощущение, что apt проверяет зависимости с учетом регистра. А вот команда dpkg не учитывает регистр при проверке. Поэтому далее нужные мне опции я устанавливаю командой dpkg

sudo dpkg -i ./WinCC_OA_3.17.9-Applications-debian.x86_64.deb

Аналогично устанавливаю справку и драйвер S7plus

sudo dpkg -i ./WinCC_OA_3.17.9-Help_EN-debian.x86_64.deb

sudo dpkg -i ./WinCC_OA_3.17.9-Help_RU-debian.x86_64.deb

sudo dpkg -i ./WinCC_OA_3.17.9-S7Plus-debian.x86_64.deb

Вся система и демо-проекты установились успешно в директорию /opt/WinCC_OA/3.17

Теперь я хочу перенести сюда прикладной проект, получившийся в результате моего базового учебного курса (https://vk.com/wall183956096_8006) и запустить его.

Копирую всю папку с проектом Workshop в свою домашнюю директорию в Debian. Убеждаюсь в том, что я являюсь владельцем (owner) директории Workshop и всех вложенных файлов и директорий. Теперь необходимо скорректировать вручную конфиг-файл проекта. Открываю файл /home/earl/Workshop/config/config

Необходимо скорректировать пути pvss_path (путь к установке WinCC OA) и proj_path (путь к самому проекту WinCC OA). Изменяем эти пути.

Запустим Project Administrator и зарегистрируем в системе мой проект.

Проект запускается, данные с ПЛК читаются, модель клапанов работает.

Если начнутся проблемы с запуском менеджеров архивов в Linux, то способ решения приведен по ссылке:https://www.winccoa.com/knowledge-base/detail/can-a-wincc-oa-project-be-copied-from-windows-to-linux.html

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

Подробнее..

Самоучитель по WinCC OA. Часть 2. Знакомство с графическим редактором gedi и функцией dpConnect

27.11.2020 06:05:27 | Автор: admin

В прошлый раз мы закончили на создании типа точки данных (DPT Flap) и трех экземпляров точки данных (DPs Flap1, Flap2, Flap3). Пора переходить к визуальной составляющей операторского интерфейса. Открываем модуль gedi. В gedi мы видим название нашего проекта в дереве и его составные части. Нас сейчас интересуют панели, поэтому разворачиваем их.

Определенная структура панелей в проекте уже имеется, но для упрощения мы будем работать в корне. Создадим новую панель, для чего необходимо выполнить правый клик мышкой и нажать пункт меню Add new panel.

Зададим имя панели Flap.pnl, после чего панель появляется в структуре проекта.

Все панели в проекте это тоже текстовые файлы, только они бывают двух типов: pnl или xml. Xml в силу своей структурированности использовать в боевых проектах гораздо удобнее (это же заявляют и люди, работающие с WinCC OA профессионально), его удобнее редактировать в сторонних редакторах. Мы же в рамках базы работаем только в gedi, по этой причине нам достаточно и базового формата. Для изменения формата панели необходимо выполнить save as (сохранить как пункт в меню, потом надо выбрать другой формат данных). Привожу скриншот содержимого пустой панели Flap.pnl:

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

В верхней части редактора gedi есть графические примитивы, выбираем и рисуем на панели прямоугольник.

Обратите внимание на окно свойств и событий графического объекта, находящееся слева от самой панели, оно нам понадобится. К примеру, для изменения цвета фона объекта необходимо найти свойство Background color.

При двойном клике на этом свойстве появляется таблица цветов.

Система, к сожалению, не позволяет задавать цвет явно в формате RGB, а только лишь выбирать из готового списка цветов. Для создания своего цвета необходимо будет открыть палитру цветов, задать цвет и его имя, после чего этот он появится в проекте. Работать с цветом можно только через его имя. Ограничимся лишь выбором цвета blue.

Сделаем копи-паст одной трубы

Сделаем еще один копи-паст. Это будет сама задвижка (первые два прямоугольника это труба).

Этот третий объект необходимо повернить вертикально (считается, что задвижка в нормальном положении закрыта). Тут появляется еще один нюанс. Начало системы координат графического объекта на панели определяется т.н. реперной точкой (reference point). По умолчанию в нашем случае эта точка располагается в верхнем левом углу (на скриншоте она обозначена, как едва заметный желтый круг). Если прямо сейчас найти свойство Rotation и задать угол 90, то мы получим следующее изображение.

Как видно, реперная точка теперь находится в левом нижнем углу (на самом деле референсная точка осталась на своем месте, а относительно нее и произошло вращение). Обнулю свойство Rotation и перенесу реперную точку в середину прямоугольника. Сдвигать reference point необходимо в окне свойств объекта, непосредственно мышью перемещать эту точки нельзя.

Теперь можно спокойно задать свойство Rotation. И немного скорректировать размер задвижки, чтобы она помещалась в трубу.

Рядом с кнопкой Save есть кнопка Save and run, нажмем ее и увидим графическое изображение нашей задвижки в режиме исполнения.

Приступим к динамизации изображения пусть задвижка вращается в зависимости от DPE Position нашей DP Flap. Выберем графический примитив задвижка, найдем в списках событий (под графическими свойствами) событие Initialize и ждем кнопку Open property wizard этого события.

Выбираем Rotate object

Выберем DPE Flap1.Inputs.Position, зададим значения минимум и максимум, нажмем Next, а в следующем окне Finish

Нажмем Save and run и понаблюдаем поворот задвижки. В моем случае еще с прошлого раза значение DPE Flap1.Inputs.Position было равно 11, что мы и наблюдаем сейчас визуально.

Если открыть сейчас модуль para и для конфига Flap1.Inputs.Position._original дать значение 90, задвижка полностью откроется

Теперь давайте вернемся к событию Initialize для графического примитива задвижка. Только в этот раз нажмем кнопку Open script editor:

// SimpleCtrlScriptStart {valid}main(){  EP_setRotation();}void EP_setRotation(){  dyn_errClass err;  if( !dpExists( "System1:Flap1.Inputs.Position:_online.._value") )  {    setValue("", "color", "_dpdoesnotexist");    return;  }  dpConnect("EP_setRotationCB",            "System1:Flap1.Inputs.Position:_online.._value");  err = getLastError();  if (dynlen(err) > 0)    setValue("", "color", "_dpdoesnotexist");}void EP_setRotationCB(string dp1, int iNewValue){  float MIN_VALUE = 0;  float MAX_VALUE = 90;  float MIN_ROTATION = 0;  float MAX_ROTATION = 90;  float fRotation;  fRotation = ( 1.0 * (MAX_ROTATION - MIN_ROTATION) / (MAX_VALUE - MIN_VALUE)) *               (iNewValue - MIN_VALUE) + MIN_ROTATION;  if (fRotation > MAX_ROTATION) fRotation = MAX_ROTATION;  else if (fRotation < MIN_ROTATION) fRotation = MIN_ROTATION;  setValue("", "rotation", fRotation);}// SimpleCtrlScript {EP_setRotation}// DP {System1:Flap1.Inputs.Position}// DPConfig {:_online.._value}// DPType {int}// PVSSRange {0}// Min {0}// Max {90}// MinRotation {0}// MaxRotation {90}// SimpleCtrlScriptEnd {EP_setRotation}

Собственно, как я и угрожал везде текстовые файлы. В данном случае мы видим скрипт, который был создан автоматически средствами Wizard. Да, визарды есть в системе WinCC OA, но по сути их назначение вызов шаблона, рыбы, которую мы в дальнейшем будем править руками. Как видно скрипт написан на языке, очень похожем на C. В WinCC OA встроенный язык называется Control.

Давайте разберем и попробуем понять это скрипт. В первую очередь, присутствует функция main(), это точка входа в программу, исполнение всегда начинается с нее.

main(){  EP_setRotation();}

Функция main() содержит единственную строчку вызов функции EP_SetRotation(). Посмотрим на ее содержимое.

void EP_setRotation(){  dyn_errClass err;  if( !dpExists( "System1:Flap1.Inputs.Position:_online.._value") )  {    setValue("", "color", "_dpdoesnotexist");    return;  }  dpConnect("EP_setRotationCB",            "System1:Flap1.Inputs.Position:_online.._value");  err = getLastError();  if (dynlen(err) > 0)    setValue("", "color", "_dpdoesnotexist");}

В первую очередь эта функция выполняет проверку, существует ли в системе точки данных. Если точки данных (точнее, DPE) не существует, то функция прекращает свою работу и выставляет цвет с именем точкаданныхнесуществует. Далее идет вызов dpConnect. Нет, не так

ДАЛЕЕ ИДЕТ ВЗОВ ФУНКЦИИ dpConnect!!!

Я намеренно выделяю эту мысль. Функция dpConnect и сам механизм подписки основопологающий механизм всей системы WinCC OA. В обязательном порядке необходимо понять действие этого механизма, и правильно им пользоваться. В неумелых руках, при недальновидности, при глупости или при лени у вас получится не нормальный программный продукт в виде легкой и надежной операторской системы, а одно огромное разочарование, состоящее из глюков, тормозов и костылей. И виной тому будет не среда разработки WinCC OA, а чьи-то кривые руки. Запомните, я предупрежал!

Что же делает функция dpConnect в нашем случае?

dpConnect("EP_setRotationCB", "System1:Flap1.Inputs.Position:_online.._value");

Во-первых, эта функция сообщает системе о наличии Callback-функции EP_setRotationCB (она описана ниже). Во-вторых, вызов колбэк-функции EP_setRotationCB осуществляется по событию System1:Flap1.Inputs.Position:_online.._value, то есть, по изменению элемента точки данных. Ответственным за раздачу сообщений об изменении точки данных у нас, как вы помните, является менеджер событий (EV). Таким образом, изменение угла наклона прямоугольника у нас происходит тогда и только тогда, когда DPE Position точки данных Flap1 меняет свое значение. Как я говорил ранее, постоянного поллинга данных у нас нет, вся система событийная.

Можно провести некую аналогию с протоколом MQTT, работу которого я недавно разбирал на примере S7-1200. Менеджер событий у нас является брокером в этой аналогии. Драйвер связи с контроллером является издателем. А пользовательский интерфейс подписчиком. Драйвер подключается к брокеру и публикует сообщение. UI подписывается на изменение точки данных (при помощи функции dpConnect). И как только это изменение произошло, вызывает обработчик этого события в виде callback-функции. В обычном состоянии подписчик не опрашивает брокера постоянно, а лишь слушает его в фоновом режиме, что и обеспечивает событийность любой обработки. Поскольку вся визуализация только тем и занимается, что меняет цвета, картинки, положение и т.д. в зависимости от значений переменных (тэгов), то этих вызовов dpConnect у вас будет очень много.

Причем, обратите внимание. Функция main состоит только из вызова функции EP_SetRotation. После этого вызова работа функции main прекращается. А вот функция EP_SetRotation, в свою очередь, осуществляет привязку изменений DPE к другой функции, и тоже прекращает свою работу. Возникает закономерный вопрос а кто работать-то будет? Ответ на этот вопрос простой dpConnect создает отдельный поток (подпроцесс) на компьютере, который и будет обрабатывать изменение графического элемента, и это в-третьих. В нормальном режиме, как я уже говорил, этот подпроцесс спит и ничего не делает, включаясь только по событию. Из этого делаем вывод, что программирование в WinCC OA это многопоточное программирование, и это тоже надо иметь в виду. В реальной работе при таком подходе потребуются механизмы разделения, такие, как семафоры, или иные методы синхронизации.

Посмотрим саму callback-функцию

void EP_setRotationCB(string dp1, int iNewValue){  float MIN_VALUE = 0;  float MAX_VALUE = 90;  float MIN_ROTATION = 0;  float MAX_ROTATION = 90;  float fRotation;  fRotation = ( 1.0 * (MAX_ROTATION - MIN_ROTATION) / (MAX_VALUE - MIN_VALUE)) *               (iNewValue - MIN_VALUE) + MIN_ROTATION;  if (fRotation > MAX_ROTATION) fRotation = MAX_ROTATION;  else if (fRotation < MIN_ROTATION) fRotation = MIN_ROTATION;  setValue("", "rotation", fRotation);}

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

Кроме проверки значений параметров эта функция содержит вызов setValue. Ее параметры:

первый (у нас пустой) имя объекта, значение которого мы меняем. В данном случае пустое имя подразумевает текущий объект (наш прямоугольник);

второй (rotation) имя свойства, которое мы меняем, а меняем мы угол наклона, это имя свойства берется из документации и из графического редактора свойств объекта только программное имя свойства и графическое далеко не всегда совпадает (программисты классического WinCC меня поймут);

третий (fRotation) значение свойства.

Возможно так же работать со свойствами в объектно-ориентированной нотификации, создавая объект типа Shape, привязываясь к существующему объекту (GetShape) и так далее. Это уже продвинутый уровень.

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

Добавим еще на панель пару кнопок открыть и закрыть. В настоящий момент мы работаем исключительно в WinCC OA, поэтому реакцию системы на команды реализуем тоже средствами этой системы. Перетаскиваем элемент Push Button на экран и меняем его свойство Button label

Далее необходимо запрограммировать нажатие кнопки Open. Для этого в списке событий выбираем Clicked и вызываем Script Editor. В редакторе я набираю вызов функции dpSet, это еще одна очень полезная функция, которая нам сильно пригодится в работе:

Параметры этой функции вначале имя DPE, далее идет значение DPE. В меню ToolsDatapoint Selector есть возможность вызвать список всех точек данных проекта.

Выбираю там Flap1.Inputs.Position. Это делается осознанно, в качестве самого примитивного примера, далее проект будем улучшать. Значение положения в открытом состоянии 90 (в соответствии с нашей мощной моделью данных). Редактор скриптов ловит только самые грубые синтаксические ошибки. Ошибки семантики не определяются. Например, очень распространенная ошибка некорректная точка данных не будет определена на этом этапе. Вывод? Не забываем про отлов ошибок в самом скрипте. В этом скрипте мы ошибки не ловим никак, и это неправильно, в реальных проектах надо, как минимум, выполнить проверку dpExists.

Аналогично описываем обработчик события нажатия кнопки Close. С одной лишь разницей в DPE Position записываем не 90, а 0. Теперь можно нажать на кнопку Save and run и проверить работу панели.

Нажали "Закрыть"Нажали "Закрыть"Нажали "Открыть"Нажали "Открыть"

Сейчас необходимо обратить внимание на разумное использование dpSet. Эта функция, по сути, выполняет операцию присвоения. Смысл вызова

dpSet("System1:Flap1.Inputs.Position", 90);

заключается в (привожу аналог)

System1:Flap1.Inputs.Position:= 90;

Но теперь давайте вспомним структуру системы. Сам скрипт присвоения выполнятся в менеджере ui. Значение DPE расположено в EV. Взаимодействие между ui и EV осуществляется по протоколу TCP/IP. Один вызов dpSet это одно событие, передающееся от ui в EV. Один вызов (одно присвоение) это ерунда. А если присвоений будет существенно больше? Например, два? ("Саша, существенно больше" (с) День Радио). Два миллиона? Или двести тысяч? Что произойдет в этом случае? А в этом случае от ui в сторону EV полетит не одно сообщение, а двести тысяч сообщений. Или два миллиона. И это может легко привести к переполнению очереди событий. От чего система гарантированно умрет. Вообще, как уже было замечено выше, WinCC OA в ленивых руках становится опасной, но при грамотном вдумчивом уважительном подходе способна на очень многое.

Как же поступать правильно? Правильно отправлять множество присвоений путем одного вызова функции dpSet. Например, вместо трех вызовов:

dpSet("System1:Flap1.Inputs.Position", 90);

dpSet("System1:Flap2.Inputs.Position", 90);

dpSet("System1:Flap3.Inputs.Position", 90);

делать один вызов

dpSet("System1:Flap1.Inputs.Position", 90, "System1:Flap2.Inputs.Position", 90, "System1:Flap3.Inputs.Position", 90);

Подробнее..

Самоучитель по WinCC OA. Часть 3. Глобальные скрипты (control scripts)

30.11.2020 14:07:23 | Автор: admin

Запрограммированое в предыдущей части поведение задвижки нелогично. В обработчике нажатия кнопки Открыть или Закрыть мы непосредственно задавали значение элемента под названием Position. При том, что в самом DPT у нас уже предусмотрены команды Открыть и Закрыть.

Datapoint type FlapDatapoint type Flap

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

Но для начала изменим обработчик нажатия на кнопки Открыть и Закрыть.

Скрипт на нажатие кнопки OpenСкрипт на нажатие кнопки Open

Меняем на

main(mapping event){  dpSet("System1:Flap1.Commands.Open", 1, "System1:Flap1.Commands.Close", 0);}
Измененный скрипт кнопки OpenИзмененный скрипт кнопки Open

Обратите внимание, что этот скрипт задает значение двум DPE, но, как было сказано в конце прошлой части, это выполняется одним сообщением. Выставляется команда Открыть и сбрасывается команда Закрыть, это своего рода защита от дурака (которая, в принципе, должна и так быть в прикладной программе контроллера, но мы перестраховываемся).

Аналогично поступаем со скриптом кнопки Close

Проверим выполнение скрипта нажатия кнопок, меняются ли переменные команд в модуле Para

Нажатие кнопки OpenНажатие кнопки OpenНажатие кнопки CloseНажатие кнопки Close

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

Для создания скрипта мы должны в gedi найти в дереве проекта Scripts, нажать правую кнопку мыши и выбрать Add New CTRL Script

Дадим осмысленное имя файла скрипта, я его назвал Model

После нажатия ОК скрипт появляется в дереве проекта

Далее двойным кликом на файле открываем скрипт для редактирования. Теперь необходимо продумать поведение модели и структуру самого скрипта. С учетом ярко-выраженного событийного поведения всей системы WinCC OA, этот скрипт должен вызывает функцию dpConnect, завязанную на одну из переменных команд управления задвижкой. Разберемся по шагам.

  1. Вызываем dpConnect на изменение значения переменной команды. В данном случае у нас очень упрощенная модель, защита от дурака реализована в скриптах нажатия кнопки, поэтому достаточно будет привязаться и к одной команде.

  2. Создаем callback функцию на изменение значения команды в рамках модели поведения.

Другие варианты поведения модели неверны с точки зрения идеалогии WinCC OA. Если в самом глобальном скрипте вызывать dpGet для чтения значения переменной команды, то этот скрипт надо вызывать постоянно, с определенной периодичностью.

Напоминаю, что у функции dpConnect есть два аргумента. Первый аргумент имя callback-функции (я назвал ее OnOpen_CB), второй имя точки данных, на которую происходит подписка. Итого, в упрощенном виде, без каких-либо проверок функция main скрипта Model выглядит так:

main(){dpConnect("OnOpen_CB", "System1:Flap1.Commands.Open");}

Далее напишем саму callback-функцию. У нее тоже два аргумента имя точки данных (тип данных string) и новое значение этой точки данных (должно соответствовать типу данных исходной точки). Получается вот такая заготовка.

void OnOpen_CB(string dp1, bool bNewValue){;}

Дописываем обработчик, он очень простой. Если значение команды открыть равно истина, то задаем положение задвижки, равное 90. Если значение равно ложь, то значение 0.

void OnOpen_CB(string dp1, bool bNewValue){if (bNewValue) {dpSet("System1:Flap1.Inputs.Position", 90);} else {dpSet("System1:Flap1.Inputs.Position", 0);}}

Теперь этот созданный скрипт необходимо как-то вызвать. Для исполнения глобальных скриптов используется Control Manager. Следовательно, требуется добавить в список менеджеров системы вызов еще одного менеджера (Control), где в качестве параметра задается имя исполняемого скрипта. В системе есть уже один вызов Control. И его трогать не следует во избежание нехороших последствий. Разве что, вы работаете с системой на уровне эксперта, но тогда зачем вам читать эти заметки?

Существующий список менеджеровСуществующий список менеджеров

В консоли WinCC OA нажимаем кнопку Append new manager, выбираем в появившемся окне менеджер Control. Для первого запуска свежесозданного скрипта имеет смысл выбрать режим запуска (Start mode) ручной (manual), чтобы не наблюдать попытки перезапуска в случае ошибок в самом скрипте. В качестве параметров вызова менеджера необходимо указать его номер в системе. В нашем случае это будет номер 2. Почему 2? Потому что менеджер с номером 1 в системе уже существует. Менеджеры одного типа в системе должны запускаться со своим уникальным номером. Именно одного типа. Это значит, что в системе может быть ui с номером 1 и ctrl с номером 1, а вот два ui (или ctrl) с одним и тем же номером быть не должны. Поэтому в качестве агрумента запуска я указываю строку -num 2. Кроме того, требуется передать имя исполняемого скрипта. Вызов нового менеджера выглядит следующим образом:

Свойства Control менеджера для симуляции задвижкиСвойства Control менеджера для симуляции задвижки

Остается нажать кнопку ОК и запустить менеджер вручную кнопкой Manager Start либо мышью через вспывающее меню (новый менеджер при этом должен быть выделен в списке). Если все сделано правильно, то добавленный менеджер позеленеет и примет статус 2.

Скрипт симуляции успешно запущенСкрипт симуляции успешно запущен

Теперь остается проверить работу симуляции.

По нажатию кнопки Open визуализируется открытиеПо нажатию кнопки Open визуализируется открытиеКнопка Close визуализирует закрытиеКнопка Close визуализирует закрытие

Следует обратить внимание на то, что Control Manager запускает скрипт (точнее, свою функцию main) один раз при старте. После выполнения функции main() необходимые callback функции продолжают находится в памяти ПК, они исполняются при выполнении условий, указанных в dpConnect (по изменению значения переменной). Однако, если в сам скрипт были внесены изменения, то необходимо вручную остановить соответствующий экземпляр control-менеджера и запустить его заново. Без останова-запуска изменения не будут приняты.

Сам control manager при запуске создает свой отдельный процесс. Его функция main выполняется в отдельной нитке (потоке, thread). Callback функция (в нашем случае OnOpen_CB) так же запускается в отдельном потоке. После выполнения функция main перестает работать, но callback продолжает находится в памяти ПК (в своем потоке) и вызывается при изменениях подписанной переменной.

Подробнее..

Самоучитель по WinCC OA. Часть 4. Повторное использование объектов. -параметры

02.12.2020 06:07:25 | Автор: admin

В предыдущей части мы завершили создание визуализиции задвижки и создали простейший скрипт, имитирующий ее поведение.

У нас есть одна панель под названием Flap, которая отображает и шлет команды для одной задвижки Flap1. Именно такая точка данных указана во всех скриптах этой панели. Возникает закономерный вопрос что делать, если задвижек не одна? И даже не две. А несколько десятков, сотен и даже тысяч (для распределенной системы WinCC OA и несколько миллионов сигналов не помеха, смотрим на Большой Андронный Коллайдер, где применяется именно это система, и завидуем).

Очевидный вариант создать несколько десятков, сотен и тысяч панелей, где каждая точки данных приведена явно, отметаем долго, хлопотно и грозит огромными трудозатратами в случае малейших изменений, неизбежных во время ПНР.

Другой вариант, но не единственный, создание шаблона на основе имеющейся панели. Создадим копию имеющейся панели Flap, для чего выберем пункт меню Panel Save Panel As. Зададим имя Panel_ref.pnl (окончание _ref подразумевает reference, т.е. ссылку, или, если будет угодно, шаблон)

Откроем панель Flap_ref (она и так должна быть открытой после сохранения). Отредактируем скрипты панели, выбрав в меню Edit Edit Panel Scripts. Откроется окно, содержащее все скрипты всех графических примитивов данной панели.

Для задвижки у нас создан собственный тип точки данных, и такие вещи, как положение или команда открытия в любом скрипте будут одинаковыми для всех задвижек. Различаться будут только имена задвижек, т.е. имена точек данных: Flap1, Flap2 и Flap3 в нашем простом случае. Для того, чтобы создать шаблон необходимо заменить имя задвижки, Flap1 на конструкцию, содержащую $-параметр (он так и называется в документации доллар-параметр). Проще все замены выполнять посредством Find&Replace в редакторе. Скрипты теперь выглядят так.

// [RECTANGLE3] [3] - [Initialize]// SimpleCtrlScriptStart {invalid}main(){  EP_setRotation();}void EP_setRotation(){  dyn_errClass err;  if( !dpExists( "System1:" + $dp + ".Inputs.Position:_online.._value") )  {    setValue("", "color", "_dpdoesnotexist");    return;  }  dpConnect("EP_setRotationCB",            "System1:" + $dp + ".Inputs.Position:_online.._value");  err = getLastError();  if (dynlen(err) > 0)    setValue("", "color", "_dpdoesnotexist");}void EP_setRotationCB(string dp1, int iNewValue){  float MIN_VALUE = 0;  float MAX_VALUE = 90;  float MIN_ROTATION = 0;  float MAX_ROTATION = 90;  float fRotation;  fRotation = ( 1.0 * (MAX_ROTATION - MIN_ROTATION) / (MAX_VALUE - MIN_VALUE)) *              (iNewValue - MIN_VALUE) + MIN_ROTATION;  if (fRotation > MAX_ROTATION) fRotation = MAX_ROTATION;  else if (fRotation < MIN_ROTATION) fRotation = MIN_ROTATION;  setValue("", "rotation", fRotation);}// SimpleCtrlScript {EP_setRotation}// DP {System1:" + $dp + ".Inputs.Position}// DPConfig {:_online.._value}// DPType {int}// PVSSRange {0}// Min {0}// Max {90}// MinRotation {0}// MaxRotation {90}// SimpleCtrlScriptEnd {EP_setRotation}// [PUSH_BUTTON1] [4] - [Clicked]main(mapping event){  dpSet("System1:" + $dp + ".Commands.Open", 1, "System1:" + $dp + ".Commands.Close", 0);}// [PUSH_BUTTON2] [5] - [Clicked]main(mapping event){  dpSet("System1:" + $dp + ".Commands.Open", 0, "System1:" + $dp + ".Commands.Close", 1);}

Было:

System1:Flap1.Inputs.Position:online..value

Стало

System1:" + $dp + ".Inputs.Position:online..value

Строка, которая ранее содержала непосредственно элемент точки данных, теперь формируется из первой постоянной части (System1), к которой добавляется $dp, после чего добавляется вторая постоянная часть, которая так же не зависит от точки данных, т.е. от конкретной задвижки. Знак + подразумевает объединение строк. Сами строки в данном случае заключены в кавычки. В явном виде такую панель использовать, разумеется, не получится. Необходимо задать подстановку для $dp (Flap2, например) при вызове этой панели.

Используя метод аналогии, можно сравнить $-параметры с формальными и фактическими параметрами функции в любом языке программирования. При вызове функции мы всегда должны задавать фактические параметры, значения которых заменят формальные, и функция отработает.

Теперь создадим новую панель. Пусть она называется Flaps. Сделаем новую панель чуть побольше.

Далее необходимо перетащить мышью из дерева проекта панель Flap_ref на рабочее поле открытой панели Flaps. При этом система автоматически определит присутствие $-параметров и предложит подставить вместо формального значения фактическое.

Drag'n'dropDrag'n'drop

Зададим имя клапана, вместо $dp укажем Flap1. Нажмем на кнопку Save and Run in QuickTest Mode и убедимся, что клапан 1 реагирует на нажатия кнопок Open и Close то есть, открывается или закрывается. Если клапан вдруг не реагирует на команды, посмотрите состояние контрол-менеджера, добавленного в предыдущей части, он может быть остановлен (тогда его надо, разумеется, запустить, или просто перевести режим запуска из ручного в автоматический, чтобы каждый раз не отвлекаться).

Все работаетВсе работает

Добавим точно так же панель для Flap2

Проверяем. Первый клапан работает (управляется), второй- не работает. Почему? Все просто, созданная вчера модель (в виде скрипта) управляет всего лишь одним клапаном Flap1. Остальные клапаны в модели не описаны.

Второй клапан не работаетВторой клапан не работает

Доработаем имеющуюся модель для того, чтобы она управляла и вторым клапаном тоже. Модифицируем быстро, но неправильно, путем копи-паста. Создаем еще две функции dpConnect и две разных callback-функции, переименовываем первую callback-функцию. В итоге получается такой код.

Не забываем перезапустить Control Manager этого скрипта (тот, что с опцией -num 2). После модификации модели проверяем изменения и видим, что оба клапана управляются независимо.

В связи с тем, что на DPE Position у нас натравлен конфиг с функцией, третий клапан на экран пока не выносим (собственно, я его и в модель-то напрасно внес).

Подробнее..

Самоучитель по WinCC OA. Часть 5. Работа с журналом тревог

04.12.2020 04:07:31 | Автор: admin

(* Начиная с этой части я перешел на версию WinCC OA 3.17. Никаких отличий в масштабах базового курса не будет. Изменятся лишь надписи на скриншотах.*)

При создании типа точки данных Flap мы уже предусмотрели битовый DPE для аварии Момент (FlapAlarmsTorque). Однако в настоящий момент для всех трех точек данных (Flap1, Flap2, Flap3) это всего лишь элемент, переменная. Для того, чтобы изменение этой переменной фиксировалось в подсистеме сообщений, необходимо повесить на этот DPE соответствующий конфиг. Для этого открываем модуль para и ищем наши точки данных.

Добавляем к DPE Torque точки данных Flap1 конфиг Alert Handling

Открываем настройки добавленного конфига. Обратите внимание, что внешний вид настройки Alert Handling зависит от типа переменной, к которой относится сам аларм. В настоящий момент мы работаем с типом данных bool, внешний вид окна следующий.

Good range касается значения самое переменной какое из значений является плохим (т.е. при каком значении считаем, что аларм сработал), а какое хорошим (аларма нет). Так же задаем текст при появлении аларма и его исчезновению. Зададим этот текст, как came (пришло) и went (ушло). За хорошее значение будем считать битовое значение ложь, т.е. аларма нет.

Класс аларма весьма важный параметр. Он определяет многие аспекты отображения сигнализации: какой будет цвет, задействовано ли мерцание, будет ли звуковое уведомление, требуется ли квитирование и т.д. Выбираем класс S7_Alarm и ставим галочку рядом со словом Active. После выставления аларма активным все настройки становятся недоступны. Обратите внимание, что настройки активного аларма недоступны для редактирования не только на визуальной форме, но и средствами скриптов (а скриптами в WinCC OA можно много чего сделать, включая и динамическую работу с алармами). Настройки допускается менять только для неактивных алармов.

Перейдем в модуле para на конфиг original, посмотрим текущее значение и поменяем его на истину.

Текущее значение переменной FALSE, аларм неактивенТекущее значение переменной FALSE, аларм неактивенТекущее значение переменной TRUE, аларм активен, текст мигает очень быстроТекущее значение переменной TRUE, аларм активен, текст мигает очень быстро

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

Данный класс алармов подразумевает необходимость квитирования. Для подтверждения аларма в этом окне необходимо нажать кнопку Acknowledge, после чего все вернется в нормальное состояние.

Возникает вопрос где можно ознакомиться с настройками каждого класса алармов? Как можно модифицировать существующий класс алармов или задать свой класс? Это реализуется через точки данных (вообще любые настройки системы живут либо в точках данных, либо в конфиг-файлах). Ну, а если что-то доступно через точки данных, то это что-то вполне возможно модифицировать через программный код. Правда, сейчас мы этого делать не будем. Лучше посмотрим модуль para и поищем нужные точки данных.

На первый взгляд тут есть много точек данных, но где же DP, ответственные за классы алармов? Выставляем галочку Internal datapoints (внутренние точки данных) и видим, что полку точек данных заметно прибыло.

Ищем точки данных типа _AlertClass, тут и содержатся все классы алармов, которые можно изменить (на свой страх и риск, разумеется), либо создать свой новый класс. Поскольку мы выбрали для нашего единственного аларма класс S7Alarm, смотрим его настройки, развернув соответствующую точку данных.

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

Только что мы смотрели, как работают алармы в модуле para. Это очень интересно и познавательно для разработчика, однако не очень удобно. Ознакомимся еще с одним способом просмотреть список событий. Для этого в меню gedi найдем и нажмем кнопку System Management

Перейдем в Diagnostics

Откроем Alarmscreen

И в появившемся окне нажмем на зеленый треугольник внизу панели

Откроем модуль para, найдем Flap1.Alarms.Torque и поиграем с его значениями

В окне Alarmscreen можно сквитировать алармы. По умолчанию данное окно показывает только текущие тревоги. Если активных алармов нет, а все старые уже сквитированы, то список пуст. Для того, чтобы изменить представление, необходимо нажать кнопку с отверткой и гаечным ключом внизу панели. В этих свойствах очень много закладок и очень много настроек. И все они касаются одних только алармов.

Если задать Time range в Open и выбрать Historical Data, то мы сможем увидеть историю алармов.

В связи с тем, что тема алармов весьма обширная, а это всего лишь первый взгляд, не стоит удивляться некоторым непонятным вещам. Например, мне самому непонятно, почему в этой таблице Alarm text у нас везде состоит из одного слова came (нуууу когда-нибудь, наверное, может быть, если фаза луны сойдется, то разберусь).

Alarmscreen тоже очень интересен. Смотреть на нем алармы куда лучше, чем в модуле para. Однако, мы делаем конечное приложение для конечного пользователя, т.е. для оператора. Удобно ли будет оператору каждый раз открывать через менюшки отдельное окно аварий? Лично я в этом сильно сомневаюсь. Давайте лучше займемся интеграцией окна сообщений в наше приложение пользователя.

Перейдем обратно в редактор gedi и откроем созданную ранее панель Flaps. Далее посмотрим внимательно на левую часть редактора gedi. Кроме нашего проекта (у меня он называется Workshop) есть еще один проект с названием 3.17 (в самом начале этой главы я уже признался, что перешел на новую версию, а так был бы проект с названием 3.16), который мы точно сами не создавали. Его можно развернуть и поизучать, там много всего интересного скриптов, библиотек, панелей и т.д. Пытливые умы потратят немало времени на ознакомление.

По сути, это и есть ядро системы WinCC OA. Этот проект содержит все или почти все, относящееся к самой платформе gedi, para, панель Project Administrator, панель консоли, вся логика. И, вуаля, всем этим можно пользоваться в своих приложениях. Вот, например, я открыл в редакторе gedi панель para. Его можно изменить. И использовать в своих целях измененную копию. Про модификацию стандартных (или системных?) компонент WinCC OA поговорим чуть попозже в этой же части. А сейчас наша задача разместить окно с алармами в окне пользовательского приложения.

Редактировать модуль para пока не будем (хоть и очень хочется)Редактировать модуль para пока не будем (хоть и очень хочется)

Для этого в дереве системного проекта 3.17 ищем панель по следующему пути: 3.17 (версия Вашей копии WinCC OA) Panels vision aes AESRow.pnl. Перетаскиваем ее на свободное место открытой панели Flaps. Система попросит задать значение $-параметра $SCREENTYPE. Цинично проигнорируем эту просьбу, нажав кнопку Cancel.

Внизу у нас появился небольшой элемент отображения

Проверим, работает ли оно вообще, для чего зададим в модуле para значение истина для аварийного сигнала.

Как видно, работаетКак видно, работаетСкрыл модуль para, аларм есть и активно мигает (чего на видно на скриншоте)Скрыл модуль para, аларм есть и активно мигает (чего на видно на скриншоте)

Теперь поговорим немного о модификации стандартных компонент WinCC OA. Например, сейчас я растянул в высоту окно отображения алармов. В нем добавилось строк, однако кнопки и цифры в правой части растянулись в высоту, что плохо влияет на эстетику. Упростим себе задачу и просто уберем эти кнопки.

Для этого в редакторе gedi кликнем правой кнопкой на AESRow и выберем Open panel reference

Откроется оригинальная панель

Удалим некрасивые кнопки и цифры

Нажмем Save и увидим следующее окно

Ответим утвердительно, после чего редактируемая нами панель сохранится в виде копии в структуре нашего проекта Workshop, а не по системному пути. В нашем проекте мы будем работать с этой копией. Теоритечески можно сохранять по системному пути (например, путем подмены файлов), то эти изменения становятся общими для всех проектов WinCC OA, что нежелательно. Особенно негативно сохранение по системному пути, а не в виде локальной копии, может сказаться после установки патчей. Патчи могут корректировать, в том числе, и системный проект, и даже ту панель, которую вы изменили. Вероятность этого всегда отлична от нуля. Соответственно, устанавливая патч, вы рискуете утратить свои изменения, если сохранили их в системный проект.

Есть еще один нюанс, связанный с модификацией системных панелей и патчами. Если вы работаете с локальной сохраненной копией проекта, то натравленный на систему патч исправит только системный проект, но не вашу локальную копию панели.

В общем, модификация ядра это ответственное занятие, требующее внимательности. Не забывайте читать readme патчей, затронуты ли там модифицированные вами панели. У вас в руках очень мощный инструмент, но пользоваться им надо уметь.

После внесения изменений в панель AESRow нашу панель Flaps необходимо переоткрыть, чтобы изменения вложенной панели вступили в силу.

Последний пример в этой части визуализация пиктограмм технологического оборудования, находящегося в аварином состоянии, тем же способом (цвет, мерцание и т.д.), который задан соответствующему классу аварий. Для этой демонстрации разместим на панели Flaps окружность (Circle).

Зададим динамизацию события Initialize через визард, как уже делали ранее для задвижки. Выбираем в визарде Change color

Выбираем Background color и Alert Handling, жмем Next. Выбор Alert Handling позволит системе подтянуть значение цвета от аларма.

Выбираем Datapoint element

Жмем Next, а в следующем окне Finish. Запускаем на проверку и смотрим, что получилось. В настоящий момент аларм у меня активен и не подтвержден, круг быстро моргает серым и красным (как и класс алармов S7_Alarm).

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

Взглянем на полученный скрипт

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

Подробнее..

Самоучитель по WinCC OA. Часть 6. Навигация Открытие новых окон

07.12.2020 10:20:40 | Автор: admin

До настоящего момента весь наш прикладной проект состоял, фактически, из одной экранной формы Flaps (панель Flap можно уже не рассматривать, она неактуальна, а Flap_ref является шаблоном). Реальные боевые проекты содержат, как правильно, (значительно) больше одной мнемосхемы, отображающие целую картину, отдельные технологические участки, настройки, тренды, алармы и т.д. Рассмотрим, каким образом в системе WinCC OA возможно осуществлять переход между экранами.

Создадим еще одну панель в проекте и назовем ее Trends (на будущее), сделаем ее размер сопоставимым с размером панели Flaps и поместим на нее что-нибудь читаемое. Например надпись Это тренды, чтобы быть уверенным наверняка.

Панель TrendsПанель Trends

Для вызова панели Trends из панели Flaps разместим на последней кнопки и назовем ее Panels, для чего изменим имя объекта (Name) и метку (Button label). Разумеется, имя и метка разные вещи, имя идентифицирует объект в проекте, а метка содержит текст, видимый оператору.

Посредством визарда зададим кнопке функцию открытия новой панели. Выбираем кнопку, ищем событие Clicked и выбираем рядом с событием Clicked вызов мастера Property Wizard. В визарде выбираем Panel Functions и жмем Next.

Выбираем Open panel (in new module) и снова жмем Next.

Вдумчиво смотрим на следующее окно визарда

Рассмотрим параметры визарда:

Panel file файл панели, которую мы будем показывать. Выбираем (можно через кнопку справа, только там выбор файла по умолчанию идет по расширению xml, не забудьте его изменить на all files) файл Trends.pnl

Panel name имя экземпляра панели. Очень важный параметр! На этапе повторного использования графических объектов при помощи $-параметра мы убедились, что одну и ту же панель можно вызывать множеством экземпляров. При этом (при множественном использовании панели) каждый вызываемый экземпляр должен быть четко и уникально идентифицирован. Для этого и предназначен этот параметр. Обратите внимание, что за уникальностью имени экземпляра должен следить непосредственно разработчик, система не отслеживает дубли (два или больше разных вызов с одинаковыми именами панели). Наличие таких дублей в системе чревато очень веселыми чудесами, а точнее непредсказуемым поведением окон. Зададим в визарде имя Trends. Никакие параметры в эту панель не передаются (панель содержит одну-единственную надпись), поэтому тут заполнять не требуется.

Жмем Next и смотрим следующие настройки

По умолчанию будет выполнено открытие экрана в дочерней панеле. Добавим еще опцию Panel always on top, поставим эту галочку и нажмем Finish.

Выполним панель Flaps и нажмем кнопку PANELS, появится окно Trends.

Открылось дочернее окно, при этом перейти на родительскую панель или что-нибудь на ней нажать невозможно (из-за выбранной опции modal).

Проверим следующий режим вызова, для чего вернемся к визарду кнопку PANELS. Уберем модальный режим и проверим исполнение. В этом случае родительское окно доступно, хоть и перекрыто дочерним. По крайней мере, можно нажимать кнопки управления задвижками родительского окна.

Открыл клапан 1Открыл клапан 1

При этом, если закрыть родительское окно, то дочернее так же закроется оно существует только в связке с родительским.

Выберем следующий режим открытия панели Root panel in own module

Проверяем.

До нажатия кнопки

После нажатия кнопки

Происходит полное замещение панели: Flaps пропала (все ее объекты стерты из памяти рантмайма), появилась панель Trends. Модуль при этом остался тот же, в нашем случае модуль называется _QuickTest_

Следующий режим открытие в новом модуле

В этом случае создается новый модуль (можно еще назвать его контейнером), в котором уже, в свою очередь, открывается наша панель. Если не задавать имя новому модулю (оставить пустым поле Module name), то этот вызов сводится к предыдущему панель будет открыта в исходном модуле. За уникальностью имени модуля так же необходимо следить самостоятельно. В рамках одного ui система позволяет обратиться к любому графическому элементу. Надо лишь знать его имя. Полное имя объекта складывается из имени модуля, имени панели и имени графического объекта. Пусть новый модуль будет незамысловато называться Module

Жмем Finish и проверяем.

В этом случае у нас получается два полностью независимых окна. Обратите внимание на имена модуля и панели каждого окна все соответствует. При закрытии изначального окна (_QuickTest_) новое окно остается.

Подробнее..

WinCC OA Workshop. Часть 7. Навигация Создание интерфейса АРМ

11.12.2020 08:05:27 | Автор: admin

В прошлый раз мы разбирались с тем, как в WinCC OA можно открывать дополнительные окна. Сейчас давайте приступим к созданию полноценного интерфейса операторской системы. Как правило, в АСУ ТП операторская система состоит из области навигации (переход между мнемосхемами), расположенной в верхней части экрана, основного рабочего поля и области сигнализации, расположенной в нижней части.

Создаем панель Main, в которую будем встраивать остальные компоненты. Ее размер делаем больше размера панели Flaps.

Через Cut и Paste (вырезать/вставить) переносим панель алармов с панели Flaps на панель Main и корректируем размер панели алармов.

Создадим кнопки для открытия панелей Flaps и Trends.

Осталось определить главную рабочую область, где будут находиться основные мнемосхемы. В WinCC OA эта рабочая область называется Embedded Module (можно провести аналогию со Screen Window или Picture Window портальной или классической WinCC). Embedded Module дословно означает Встроенный модуль. Если в предыдущей части создавался некий внешний модуль, то в данном примере модуль, предназначенный для отображения панелей, интегрирован в панель. Embedded Module расположен среди инструментов графического редактора

Разместим его в свободном месте панели Main. Сразу после размещения система предлагает задать анимацию, с которой будут открываться новые окна. Можно задавать, а можно и нет. Давайте пока обойдемся без рюшечек, анимацию не задаем.

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

Ниже привожу скриншот вкладки стардарт. Там указано имя модуля EMBEDDED_MODULE1, и это неправильное имя.

Это неправильное имяЭто неправильное имя

Правильное имя модуля указывается на другой вкладке, и по умолчанию в моем случае равно Vision_1

Давайте переименуем этот встроенный модуль и дадим ему имя Module. Предвидя вопросы, что у нас уже есть модуль с таким именем, отвечу, что по предыдущей схеме с созданием модуля Module в скрипте кнопки мы более работать не будем, хотя, вопрос, конечно же, хороший и правильный.

Теперь необходимо задать действия по нажатию кнопок FLAPS и TRENDS. Задаем событие Clicked, работаем в текстовом режиме (не визардом на этот раз). Нам необходима функция RootPanelOnModule. Можно и нужно использовать автоподстановку. Например, сейчас я набрал текст RootPanel и нажал кнопки CTRL+TAB.

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

Первый параметр этой функции имя панели. У меня это Flaps.pnl. Второй параметр имя панели, пусть будет Flaps. Далее имя модуля, мы его только что задали, Module. Последний параметр функции это параметры, передаваемые непосредственно панели. Тип этой переменной dyn_string, динамический массив строк неопределенной заранее размерности. Сейчас никаких дополнительных параметров мы передавать не будем, однако это значении необходимо указать. Объявим переменную типа dyn_string и укажем ее в вызове функции открытия панели. Получаем следующий код открытия окна

Аналогично выглядит и скрипт кнопки TRENDS

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

Внесем косметические изменения в панели Flaps и Trends, уберем ненужные элементы (панель алармов и кнопку справа), изменим размер панелей.

Запускаем окно Main.pnl на исполнение и проверяем поведение кнопок FLAPS и TRENDS. Все должно работать. Если не работает, ищите ошибки.

Подробнее..

Самоучитель по WinCC OA. Часть 8. Тренды

14.12.2020 08:18:37 | Автор: admin

Оживим уже созданную (но пустую) панель Trends графиком изменения переменной во времени. Однако, перед тем, как смотреть на тренды, их необходимо сконфигурировать и каким-то образом задать значения, чтобы они скопились в базе данных. Необходимо, чтобы в системе была переменная, которая меняла свое значение. Необходимо повесить соответствующий конфиг на эту переменную, чтобы значения складывались в архив. Для типа точек данных Flap у нас есть DPE с названием Flow (расход) и типом int. Этот DPE и будем использовать для ознакомления с трендами. Для имитации поведения системы у нас уже есть созданный control-скрипт Model. Предлагаю его и использовать для иммитации расхода. Откроем скрипт Model

Напомню, что точкой входа в скрипт (как и в языке C) является функция main(). В настоящий момент функция main() исполняется, происходит связывание изменения DPE с его функцией-обработчиком (callback-функцией), после чего main завершает работу, но в памяти остаются сами callback-функции.

Изменяем функцию main следующим образом

main(){  dpConnect("OnOpen_CB1", "System1:Flap1.Commands.Open");  dpConnect("OnOpen_CB2", "System1:Flap2.Commands.Open");  dpConnect("OnOpen_CB3", "System1:Flap3.Commands.Open");  for (;;) {    dpSet("System1:Flap1.Inputs.Flow", rand());    dpSet("System1:Flap2.Inputs.Flow", rand());    delay(1);  }}

Теперь после выполнения связывания DPE с callback у нас стоит бесконечный цикл (при помощи конструкции for(;;)), который задает случайным образом значения расхода для клапанов 1 и 2, после чего ожидает 1 секунду при помощи функции delay. В этом случае функция main не будет завершаться и будет работать, пока запущен ее CTRL-менеджер.

(Кстати, да тут достаточно и одного вызова dpSet, а не двух.. Совершаю ошибки, про которые сам же и говорил ранее)

После перезапуска CTRL-менеджера (в связи с изменением скрипта) нужно убедиться, что модель работает, взглянув на значения расхода в модуле para.

Пришло время визуализировать изменения расхода. Откроем панель Trends. Паренесем на панель графический элемент Trend из палитры инструментов редактора gedi.

Необходимо выбрать режим отображения тренда

Стандартный режим значение по времени. Второй режим Value over value был разработан для специфических требований некоторых заказчиков для сопоставления невременных значений. Например распределение давления по трубопроводу, где по оси X километровая отметка трубы, а по оси Y значение давления на отметке. В нашем случае выбираем первый вариант, расположение горизонтальное, нажимаем ОК. Далее выбираем точку данных для отображения, выбираем расход первого клапана.

Далее через кнопку Append добавляем еще одну кривую расход второго клапана. Итого закладка Curve (кривая) выглядит так

если выбрали график #1_1, и так:

если выбрали (для настроек отображения, конечно же) график с именем #1_2. Нажимаем кнопку Close. Панель Trends в редакторе теперь выглядит так

Сохраняем и закрываем панель Trends и запускаем панель Main, нажимаем в исполнении кнопку TRENDS. После я вижу, что окно с трендами как-то меняется, то есть я вижу динамику, но пока она очень ненаглядна и весьма непонятна.

Связано это с тем, что значение меняется каждую секунду, отображается сейчас текущее значение (архивация еще не настроена), а по умолчанию выбрана временная шкала в два часа. Разумеется, график выглядит очень сжатым. Поиграв колесиком мышки на шкале времени, на шкалах оси X для каждого из трендов, а так же на основном рабочем поле, можно получить более наглядное изображение. Оси можно не только масштабировать колесиком, но и двигать, перемещая мышь с зажатой на оси левой кнопкой. Можно выделить мышью на рабочем поле тренда любую его часть, экран будет масштабирован под выделенное. Если вы что-то нажали, и все сломалось, просто нажмите кнопку 1:1 в верхней части экрана, масштабы вернутся к изначальной конфигурации.

Однакратный щелчок мышью на рабочем поле показывает линейку или ruler

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

Функционал этого окна очень широк и дает гораздо больше возможностей, чем может показаться с первого взгляда. Можно синхронизировать оси. Можно выставлять несколько рулеров. И т.д. Очень много чего можно. На официальных курсах трендам уделяется примерно половина учебного дня из пяти, и это только базовый курс.

В настоящий момент, если полностью закрыть окно тестирования и открыть его заново, то все значения начнут отображаться только с момента открытия окна графиков. Это вполне закономерно, так как на точках данных не размещен конфиг архивации, т.е. данные не пишутся в базу. Вернемся в модуль para. Встанем на элемент точки данных Flap1.Input.Flow и добавим к нему конфиг _archive

Тут необходимо выбрать Archive Settings. Появился конфиг _archive, выберем его.

Тут необходимо выбрать один из шести типов архивов

Если посмотреть на консоль системы, то и менеджеров архива у нас запущено тоже шесть экземпляров

То, что я сейчас рассказываю про тренды (точнее, про архивирование) касается исключительно встроенной файловой базы данных. В WinCC OA есть возможность архивации в базу Oracle. В версии 3.17 появилась возможность использования InfluxDB, которая при создании проекта обозначена, как NextGen архиватор. Сейчас же говорим про классическую файловую базу. В качестве индекса (первичного ключа) в ней выступает метка времени сигнала. Если говорить очень приблизительно, то на все заданные тренды у нас создается одна таблица. А значения сигналов с поля меняются по-своему, но записываются в базу данных по изменению. Если свести все тренды в одну таблицу, то ее использование будет весьма неоптимальным, в таблице будет очень много пробелов. Для оптимизации нам предлагается в рамках одного менеджера архивов (у которого есть свои настройки, и они могут отличаться или отличаются от настроек соседниех архивных менеджеров) хранить переменные, интенсивность изменений которых более-менее одинаковая. Не рекомендуется совмещать в рамках одного архива переменные, которые меняют свои значения с очень разной частотой, например раз в секунду и раз в час. Это очень неточное описание, которое лишь приблизительно объясняет наличие нескольких архивных менеджеров в системе. А при наличии NextGen архиватора на базе InfluxDB, возможно, данное описание вообще теряет смысл, однако в настоящей заметке дублируется оригинальный курс, так что это объяснение сохраняется по соображениям совместимости.

В нашем демонстрационном примере обе переменные, меняющиеся раз в секунду, необходимо архивировать в рамках одного менеджера. Пусть это будет менеджер ValueArchive_0000.

Выбираем Active, нажимаем Apply.

То же самое проделываем для второго клапана. Запускаем снова на исполнение панель Main, открываем тренды, подгоняем масштаб и смотрим, что изменилось

Красной линией рисуется расход первого клапана, синим второго. На этом скриншоте видно, что синяя линия начала рисоваться позже красной. Это связано с тем, что архивные настройки для второго клапана были применены после того, как я настраил архивацию первого клапана. Запись данных началась сразу после выставления Active и нажатия кнопки Apply.

На практике может потребоваться не просто визуально отобразить исторические значения переменной, но и получить их в числовом виде (в виде массива, например) для какой-либо дальнейшей обработки. Универсальным инструментов для этого является старый-добрый SQL-запрос. Для более удобного визуального формирования запроса к базе данных WinCC OA предоставляет отдельный инструмент SQL Query. Чтобы добраться до него необходимо запустить (в том же gedi в меню Module) System Management

Далее открыть Reports

И SQL-Query. Ставим тут галочку напротив слова ALL в рамке Value type (в скриншоте не проставлена, а должна быть).

На вкладке SELECT выбираем те значения DPE, которые необходимо включить в выборку. Система архивирования, на самом деле, запоминает не только пару метка времени значение, но и массу другой информации. Но мы сейчас прочитаем из базы только значение и метку времени originalvalue и originalstime. Для этого из выпадающего списка Configuration выбираем искомое и добавляем его в список Elements of the SELECT Statements при помощи кнопок Append или Insert, расположенных справа от списка. Кнопки не подписаны. К этим кнопкам и этому диалоговому меню необходимо привыкнуть, на первый взгляд там все немного неоднозначно.

На следующей вкладке From мы определяем, из каких точек данных мы хотим вытащить значения.

Тут можно воспользоваться механизмом шаблонов, написать в текстовом поле Flap* и добавить этот текст в список Elements of the FROM statement.

Все остальные параметры пока игнорируем и переходим на вкладку Data

Нажимаем вначале кнопку Create query, после чего кнопку Start query, получаем набор данных.

Попробуем эти же данные получить в программном коде. Скопируем куда-нибудь SQL-запрос. Откроем панель Main и добавим на нее кнопку с меткой EXPORT

Начнем программировать скрипт на событие Click этой кнопки. SQL-запрос, скопированный из окна SQL-query я временно разместил в комментарии к этому коду

Сейчас нам потребуется применить функцию dpQuery. dpQuery отличается от функции dpGet тем, что возвращает массив значений, которые удовлятворяют SQL-запросу, в то время, как dpGet возвращает лишь одно значение. Первый параметр функции запрос SQL. Второй параметр в переводе на русский звучит как двумерный массив неопределенного типа и неопределенной размерности, а в типах данных WinCC OA как dyndynanytype. Объявим в скрипте переменную этого типа. Разбирать полученные данные мы будет, конечно же, имея представление что именно мы запрашиваем. И это представление мы имеем, как авторы запроса.

main(mapping event){  dyn_dyn_anytype Tab;  dpQuery("SELECT ALL '_original.._value', '_original.._stime' FROM 'Flap*'", Tab);}

Результат запроса складывается в Tab, но этот результат необходимо еще куда-то вывести. В качестве примера выводить полученные данные будем Log Viewer при помощи функции DebugN. Данная функция незаменима для дебага во время разработки, тестирования и наладки системы. В качестве параметров допускается приводить несколько строк. Совет из практики указывать дополнительно в DebugN не только отладочную информацию, но и заголовок отладочной информации. Если проект очень большой и над ним работает большой штат, то не помешает так же указывать, кто именно выводит в лог. Причина на то простая разработчиков может быть много, а лог в системе один. Зная, что выводится и кто выводит можно подойти к коллеге и вежливо поинтересоваться, а что тут, собственно, происходит. Зная заголовок вывода можно провести глобальный поиск в проекте и найти этот вызов на тот случай, если вызов DebugN был оставлен после ПНР, его вывод осуществляется далеко не на постоянной основе, сам проект давно в работе, а разработчик давно уволился. Культура разработки, если двумя словами.

В конечном итоге обработчик кнопки EXPORT выглядит следующим образом

main(mapping event){  dyn_dyn_anytype Tab;  dpQuery("SELECT ALL '_original.._value', '_original.._stime' FROM 'Flap*'", Tab);  DebugN("SQL", Tab);}

Сохранив скрипт, запустим снова окно Main на исполнение. Найдем окно Log Viewer (оно открывается всегда автоматически при запуске системы), очистим вывод журнала кнопкой крестик для нашего удобства

Нажмем в рантайме кнопку EXPORT и посмотрим на вывод в журнале

Выгрузка получилась очень большая, и показано далеко не все, о чем LogViewer честно сообщает

Обидно, но логично. Выводить несколько мегабайт текста в журнал не лучший выбор. На практике переменную Tab можно разобрать и натравить на нее свою математику. Можно вывести информацию в таблицу и так далее.

Подробнее..

Самоучитель по WinCC OA. Часть 10. Подключение к живому S7-1200

26.12.2020 12:22:33 | Автор: admin

рамках базового курса в системе WinCC OA используются только внутренние переменные системы. Никаких внешних подключений не предполагается. Однако, слушатели базового курса всегда под завершение учебы просят продемонстрировать, как же считать переменную с настоящего живого ПЛК. Поскольку WinCC OA относится к продуктам компании Siemens, то логичным будет продемонстрировать подключение к контроллеру компании Siemens и чтению с него нескольких переменных. В нашем случае будем подключаться к PLC серии S7-1200.

Набор драйверов WinCC OA включает в себя два вида драйверов для контроллеров Simatic это s7 и s7plus. Разница в них следующая: s7 предназначен для связи с ПЛК классической серии S7-300 / S7-400, а s7plus для современной линейки S7-1200 / S7-1500. Драйвер s7plus указывается при установке отдельно. Он может отсутствовать в вашей системе, если вы его не устанавливали. Вне зависимости от того, какой используется драйвер (хоть iec104), общие принципы сохраняются. Необходимо в консоли добавить соответствующий драйвер. Далее сконфигурировать соединение с устройством и задать этому соединению номер добавленного драйвера, активировать. Так же требуется на DPE навесить конфиг Periphery Address и выполнить настройки, указав корректный адрес переменной.

Для начала необходимо прописать в консоли драйвер. Технически добавление драйвера в систему не отличается от добавления менеджера. Откроем консоль, нажмем в ней Append a new manager

Выберем в списке драйвер S7plus и зададим в опциях -num 2. Это связано с тем, что в системе уже есть драйвер с номером 1, это Simulation Driver, а номер драйвера в системе должен быть уникален. К слову, по словам разработчиков WinCC OA, симуляционный драйвер в реальных проектах не используется.

Теперь новый драйвер добавлен в систему и запущен

Теперь добавленный драйвер с номером 2 в системе необходимо сконфигурировать. Для этого (например через меню редактора gedi) необходимо открыть модуль System Management.

Далее открываем Driver S7

Выбираем S7+ Driver

В настоящий момент в системе нет сконфигурированных соединений. Для создания связи с существующим контроллером нажимаем кнопку Create.

Тут необходимо указать имя для соединения и способ работы с данными либо оффлайновый проект, находящийся во вложенной папке проекта WinCC OA, либо онлайн связь с уже готовым и настроенным ПЛК. В нашем случае S7-1214 с залитой конфигурацией и программой лежит на столе рядом с ПК и доступен по протоколу TCP/IP, так что, работаем онлайн. Указываем номер только что добавленного и запушенного драйвера, это номер 2. Имя соединения далее превратиться в системную точку данных, с которой возможно работать посредством программного кода.

Далее требуется указать тип контроллера, я задам его явно S7-1200, а так же ввести ip-адрес моего ПЛК. Дополнительно, если вы еще не настраивали, требуется вызвать окно настройки сетевой карты компьютера, нажав кнопку Set PC/PG Interface. По нажатию этой кнопки откроется окно, знакомое всем, кто работал с классическим Step 7 или настраивал запуск операторской системы WinCC 7, TIA Portal WinCC и т.д. Если вы незнакомы с этим окном, то там необходимо указать ту сетевую карту, при помощи которой ваш ПК подключен к вашему ПЛК. У меня данный интерфейс давно настроен, и это окно выглядит следующим образом

Моя сетевая карта присутствует тут в трех экземплярах, с окончаниями ISO, TCPIP и TCPIP.Auto. Как правило, применяется последний вариант, TCPIP.Auto. После внесения настроек связи данное окно имеет следующий вид

Ставим галочку напротив Establish Connection и нажимаем кнопку Apply. После чего WinCC OA несколько секунд тратит на установление связи. Eсли все было сделано правильно, окно приобретает следующий вид

Нажимаем кнопку ОК, а после закрываем окно модуля System Management. Далее необходимо связаться с тэгами контроллера, которые в нем уже прописаны. Ограничимся двумя дискретными переменными и одной вещественной. Для работы с точками данных у нас есть модуль para, открываем его. В нем уже есть несколько готовых типов точек данных ExampleDP_bit и ExampleDP_float, их и будем использовать. Создадим точку данных MyBlinker типа ExampleDP_bit

Добавим к точке данных конфиг переферийный адрес.

Выбираем тип драйвера SIMATIC S7PLUS

Конфигурируем

Указываем номер драйвера 2. Указываем направление данных Input, только чтение. Указываем тип преобразования Bool. Вводим способ сбора данных Polling (непрерывный опрос).

Далее нажимаем на кнопку Poll groups, надо создать группу циклического (непрерывного) опроса данных. В следующем окне жмем Create, задаем имя группы и ее настройки. Переменные этой группы будут опрашиваться кажые 100 мс. В соответствии со справкой организовать опрос быстрее таким способом невозможно, любые значения цикла опроса меньше 100 мс будут считаться за 100 мс. Делаем группу активной и жмем ОК.

В графе Reference необходимо указать имя переменной в контроллере. Поскольку ПЛК у меня сконфигурирован и на связи, я могу просматривать его тэги в режиме онлайн. Нажимаем кнопку Selection в верхней части окна.

Открывается окно со всеми живыми тэгами контроллера, доступными для операторской системы. Я выбираю двоичный тэг Clock_1Hz, который меняет свое значение каждую секунду.

Теперь ставим галочку Address active, жмем Apply и можно перейти на конфиг original и посмотреть, меняется ли значение тэга в нашей SCADA.

Да, значение тэга меняется каждую секунду

Точно так же пропишем в системе бит Emulation, находящийся в блоке данных Modes. Действуем по аналогии с предыдущим битом за исключением Направления (Direction), тут ставим режим доступа чтение и запись. Все остальные настройки (кроме, разумаеется, символьного имени тэга ПЛК) аналогичны.

Сейчас значение бита FALSE, бит читается.

Изменим в ПЛК его значение на TRUE

В модуле para его значение так же изменилось

Теперь попробуем поменять его значение на FALSE и посмотрим состояние бита средствами TIA Portal. Выполнить эту операцию средствами para не удается. Скорее всего, это связано с тем, что поллинг переменной идет 10 раз в секунду, в para он обновляется так же быстро, и я просто физически не успеваю внести в Original value значение FALSE, вместо TRUE. Даже выделить значение дабл-кликом или кнопками Ctrl+A не удается. Пробуем изменить DPE кнопками на панели операторской системы. Для этого в верхнюю часть главного экрана Main я размещаю две кнопки Turn On и Turn Off и создаю скрипты для них, соответственно

dpSet("System1:Emulation.:_original.._value", 1);

и

dpSet("System1:Emulation.:_original.._value", 0);

Пробуем теперь отключить тэг.

По нажатию кнопки в модуле para значение изменилось на FALSE

Значение изменилось и в блоке данных контроллера.

Поскольку средствами скриптов операторского интерфейса удается изменить значение тэга, значит со связью все в порядке. Но, все таки, хочется иметь возможность задавать значение и через para. Я рассуждаю следующим образом. Драйвер обновляет значение сигнала принудительно 10 раз в секунду (poll time равен 100 мс). Драйвер ничего не знает про то, изменилось ли значение сигнала или нет он просто поллит заданую переменную и отдает ее в event manager. EV тоже не знает, изменился ли тэг или нет, и точно так же передает любое новое значение туда, где на них существует подписка. 100 мс это очень быстро для человеческой реакции, поэтому в модуле para я просто не успеваю вбить новое значение, оно тут же перезатирается обновленным от драйвера. Значит, необходимо настроить систему таким образом, чтобы сообщения с новым значением тэга летели адресатам только в том случае, когда значение действительно изменилось. Для этих целей на DPE необходимо разместить конфиг Smoothing. Возвращаемся в модуль para и добавляем конфиг на точку данных.

Оставляем его настройки, как есть сравнение старого значения с новым. Не забываем нажать Apply.

Переходим на конфиг original этой точки данных и наблюдаем, что метка времени тэга (как online, там original) перестала меняться, как сумасшедшая. Обращаем внимание и на то, что теперь в модуле para возможно изменить значение бита, и оно доходит на контроллера.

Теперь пропишем вещественную переменную, которая находится в ПЛК по адресу Robicon.SCADAmanSP. Для переменной в WinCC OA воспользуемся готовым типом DP ExampleDP_float. Ее создание и настройка переферийного адреса аналогична предыдущим настройкам, за исключением очевидных деталей имя, адрес, тип данных. Направление зададим, как чтение/запись. На этот раз я не выбирал тэги онлайн, а вбил символьное имя переменной непосредственно в поле ввода Reference. Не забываем добавить конфиг smoothing и для этой DP.

Делаем адрес активным и смотрим конфиг original. Видим, что связь установлена, значение с ПЛК приходит.

Изменение значения так же доходит и до контроллера.

Напоследок отобразим значение этой переменной на мнемосхеме FLAPS (не создавать же новую панель ради одной проверки). Разместим на панели элемент Textfield из палитры.

Визардом на событии Initialization создами скрипт отображения значения DPE (Display value)

Значение с ПЛК отображается

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

Изменим значение сигнала с операторской системы

До блока данных изменения долетели

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru